Contenu pirate : ce qui se passe vraiment quand c'est le site lui meme, et non un annonceur, qui est compromis

Le premier signe vient rarement de quelqu'un d'officiel. Ce sont quelques adresses etranges dans Search Console que personne dans l'equipe ne se souvient avoir creees, ou le trafic organique qui chute sans cause visible dans les tableaux de bord habituels, ou un annonceur qui ecrit pour demander pourquoi la page de son annonce redirige vers quelque chose qui n'a rien a voir avec le site. Parfois c'est un visiteur qui signale que son navigateur a refuse d'ouvrir la page. Rien de tout cela ne ressemble a une fraude d'annonceur, et rien ne ressemble au cas de la publicite malveillante qui fait signaler un site sans que son propre code n'y soit pour rien.

C'est l'autre cas, et c'est un probleme different avec une solution differente. Ici, quelque chose a reellement ete ajoute aux fichiers ou a la base de donnees du site sans que personne dans l'equipe ne l'y ait mis. Un annuaire de cette categorie ne peut pas se permettre de paraitre peu fiable, meme une semaine : ni pour Google, ni pour un prestataire de paiement qui traite deja le secteur comme plus risque que la moyenne, ni pour un hebergeur qui n'est peut etre qu'a une plainte de suspendre le compte. Savoir exactement ce qui s'est passe, ce que Google verifie vraiment, et dans quel ordre la solution fonctionne reellement, vaut plus ici que pour le blog d'une petite entreprise ordinaire, parce que le cout d'un mauvais ordre est plus eleve.

Comment un attaquant entre vraiment, et c'est rarement spectaculaire

A ce stade, presque personne ne vise specifiquement un annuaire de petites annonces pour adultes. Le schema habituel est un robot qui balaie le web ouvert a la recherche de n'importe quel site utilisant un logiciel precis avec une faille connue et non corrigee, de la meme facon qu'il balaie les sites de restaurants ou les blogs de cabinets d'avocats. Le site est touche parce qu'il utilise le meme CMS, le meme plugin ou la meme bibliotheque obsolete qu'un million d'autres sites, pas parce que quelqu'un l'a observe et a juge que cela valait l'effort.

Les logiciels obsoletes sont un facteur reel et courant, mais ce n'est pas toute l'histoire, et les traiter comme si c'etait le cas laisse la moitie des points d'entree reels sans protection. Le rapport sur les sites pirates de Sucuri, portant sur les sites nettoyes en 2023, a montre que 39,1% des installations CMS compromises faisaient tourner un logiciel obsolete au moment de l'infection, en baisse par rapport a 50,58% l'annee precedente. Le meme rapport a montre que seulement environ 14% de ces sites avaient encore un plugin ou un theme vulnerable identifiable une fois que Sucuri avait examine de pres la remediation. Autrement dit, la plupart des sites nettoyes n'avaient pas ete pirates via la faille logicielle qu'un operateur s'attendrait a devoir corriger en premier.

L'autre moitie du tableau, ce sont les identifiants. Le rapport Data Breach Investigations 2025 de Verizon, qui regarde tous les secteurs qu'il suit et pas seulement les sites web, a trouve les identifiants voles ou devines legerement devant les vulnerabilites logicielles exploitees comme moyen pour les attaquants d'obtenir leur premier point d'appui : 22% des violations contre 20%. Ce n'est pas un chiffre construit uniquement a partir de sites de petites annonces, mais cela correspond a ce que Sucuri observe dans les nettoyages specifiquement sur les plateformes CMS. Un mot de passe administrateur reutilise depuis un compte email personnel qui a fuite dans une violation sans rapport des annees plus tot est, en pratique, une voie d'entree a peu pres aussi probable qu'un plugin non corrige.

La consequence pratique, c'est que securiser un site est un travail sur deux fronts de poids a peu pres egal, pas un seul. Un calendrier de correctifs ferme la moitie des breches logicielles. Une discipline separee sur qui a un acces, quel est vraiment son mot de passe, et s'il est reutilise ailleurs, ferme l'autre moitie. Un operateur qui se contente de maintenir les plugins a jour a fait la moitie du travail et pourrait ne jamais s'en rendre compte, parce que l'ecran d'avertissement apparait identique quelle que soit la moitie negligee.

Comment Google appelle vraiment cela, et pourquoi c'est un probleme different d'une publicite malveillante

Un autre type d'avertissement Chrome a deja ete traite ici : celui ou une regie publicitaire sous contrat diffuse une creation trompeuse ou malveillante via les propres emplacements publicitaires du site, et Google signale le site pour un contenu qu'il n'a jamais touche. Ce n'est pas ce cas ici. Ici, quelque chose a ete ajoute aux pages ou a la base de donnees du site a l'insu de l'operateur, ce qui est exactement ce que les regles anti spam de Google definissent comme du contenu pirate : du contenu place sur un site sans l'autorisation du proprietaire, a cause d'une faiblesse dans la securite meme du site.

La documentation de Google distingue trois schemas precis. L'injection de code est du code malveillant, generalement du JavaScript, insere directement dans des pages ou des iframes deja existantes. L'injection de pages, ce sont de nouvelles pages ajoutees au site qui n'existaient pas avant, construites pour manipuler le classement dans les moteurs de recherche ou pour mener une tentative de phishing, tandis que les pages qu'un visiteur connaissait deja ne montrent souvent aucun signe visible que quelque chose cloche. L'injection de contenu est plus subtile encore : du texte ou des liens caches ajoutes aux pages existantes via des astuces CSS ou HTML, visibles par le robot d'un moteur de recherche mais pas par une personne regardant la meme page dans son navigateur.

L'injection de pages est generalement le schema que les operateurs decouvrent en dernier, et il vaut la peine de comprendre pourquoi un attaquant prend cette peine plutot que de simplement construire son propre site jetable. Un domaine qui a deja un historique, des backlinks existants et une position etablie dans les resultats de recherche blanchit le contenu de spam dans le classement bien plus vite que ne le ferait un domaine tout neuf, donc les attaquants preferent emprunter la reputation d'un site existant plutot que d'en construire une a partir de rien. C'est un mecanisme different de l'attaque externe par liens traitee ailleurs : la, l'attaque pointe des liens d'autres sites vers la cible depuis l'exterieur ; ici, les pages de spam sont construites pour vivre sur le propre domaine de la cible, a l'interieur de sa propre structure de fichiers.

Une fois que ce contenu existe sur le site, les consequences s'accumulent. Le rapport Problemes de securite de Search Console signale directement la propriete, certaines pages peuvent etre supprimees des resultats ou remplacees par un avertissement dans la liste, et le Safe Browsing de Chrome peut commencer a montrer aux visiteurs le meme ecran rouge interstitiel deja decrit pour le cas de la regie publicitaire, cette fois declenche parce que le site heberge vraiment du contenu malveillant ou trompeur, et non par une creation defectueuse qui y transite.

Faire lever l'avertissement : l'ordre qui fonctionne vraiment

Les indications de Google sont precises sur l'ordre, et la majeure partie du temps perdu en pratique vient du fait de faire ces etapes dans le mauvais ordre. Le premier travail consiste a trouver et supprimer chaque occurrence du contenu injecte, pas seulement la page echantillon que Search Console a citee comme exemple du probleme. Cette adresse est un echantillon, pas un inventaire, et un nettoyage qui s'arrete apres l'avoir corrigee laisse generalement en place la majeure partie de l'injection reelle.

Le second travail consiste a decouvrir comment l'attaquant est entre et a fermer exactement cette breche, qu'il s'agisse d'un plugin non corrige, d'un identifiant divulgue ou d'une permission mal configuree, parce que supprimer les pages de spam sans corriger le point d'entree remet simplement le compteur a zero jusqu'a ce que le meme attaquant, ou le meme balayage automatise, revienne par la meme porte. La documentation de Google est explicite sur le fait que la correction doit couvrir tout le site, pas seulement la page d'accueil ou la page qu'un visiteur a signalee, et une partie liee de ce meme guide recommande de changer tous les mots de passe lies a un compte ayant un acces administrateur : la connexion au CMS, le panneau de controle de l'hebergement, le FTP ou SFTP, et la base de donnees, precisement parce que le point d'entree est souvent l'un de ceux la plutot que la page ou le symptome est apparu.

La partie que les operateurs inversent le plus souvent, c'est le moment ou demander a Google de verifier a nouveau. Demander une revision avant que le nettoyage decrit ci dessus ne soit reellement termine n'accelere rien ; Google dit clairement que demander une revision alors que le probleme existe encore ne fait que prolonger le temps pendant lequel le site reste signale. Les delais de revision varient selon la categorie : une revision pour malware simple prend generalement quelques jours, une revision pour phishing environ un jour, mais une revision de contenu pirate incluant des pages de spam injectees peut prendre jusqu'a plusieurs semaines, parce que Google traite cette categorie comme pouvant necessiter un examen reellement manuel plutot qu'une reverification automatique.

Un deuxieme episode du meme avertissement apres qu'une revision soit deja passee est generalement le signe que le point d'entree n'a jamais ete reellement ferme la premiere fois, seulement le symptome. Supprimer les pages de spam visibles donne l'impression que le travail est termine, mais si le plugin vulnerable est toujours la ou si le mot de passe divulgue fonctionne toujours, la meme breche est reutilisee, parfois quelques jours seulement apres la levee de l'avertissement.

Ce qui previent vraiment cela, avec un budget que cette activite peut assumer

Rien de tout cela ne necessite d'embaucher une equipe de securite dediee, et les operateurs qui sautent les bases le font generalement parce que la liste semble plus longue qu'elle ne l'est vraiment. Le CMS, son theme et chaque plugin installe ont besoin d'un calendrier de mise a jour fixe, verifie chaque semaine plutot que "quand il y a le temps", et tout ce qui a ete installe une fois puis n'est plus utilise devrait etre carrement supprime plutot que laisse dormant, parce qu'un plugin inactif reste une porte jamais verrouillee.

La discipline des identifiants pese autant que les correctifs, au vu de ce que montrent reellement les chiffres de Sucuri et Verizon cites plus haut. Cela signifie un mot de passe unique pour chaque compte pouvant toucher le site, genere et stocke dans un gestionnaire de mots de passe plutot que memorise, une authentification a deux facteurs activee sur chaque connexion qui la propose, et aucun identifiant partage entre le personnel ou les moderateurs, puisqu'un identifiant partage est aussi un acces qu'on ne peut rattacher a une personne precise quand quelque chose tourne mal.

Les sauvegardes comptent autant que la prevention, parce que c'est ce qui remet un site en ligne en quelques heures au lieu d'attendre une revision de Google qui peut durer des semaines. Une sauvegarde qui vit sur le meme compte d'hebergement que le site qu'elle est censee proteger n'est pas une grande sauvegarde, puisqu'un attaquant avec un acces administrateur peut generalement l'atteindre aussi ; une copie stockee ailleurs, et reellement testee en la restaurant au moins une fois plutot que laissee tourner sans verification, fait la difference entre une mauvaise semaine et un mauvais mois.

Le dernier element consiste simplement a le decouvrir tot. Les alertes par email de Search Console font arriver le rapport Problemes de securite dans une boite de reception que quelqu'un lit vraiment, plutot que de laisser l'operateur decouvrir le probleme via la plainte d'un visiteur ou une lente hemorragie de trafic organique des jours ou des semaines plus tard. Aucune de ces etapes ne coute plus que du temps, et toutes sont moins cheres faites maintenant qu'apres que l'ecran d'avertissement ait deja coute une semaine de trafic pendant que le nettoyage se met en place.

L'ordre, si l'avertissement est deja apparu, est de tout nettoyer d'abord, de fermer la breche precise qui l'a permis, et seulement ensuite de demander a Google de verifier a nouveau, jamais l'inverse. L'ordre, si rien ne s'est encore passe, est de faire quand meme les quatre memes choses sur un calendrier cette semaine : mettre a jour ce qui est installe, changer tous les mots de passe ayant un acces administrateur, activer l'authentification a deux facteurs partout ou elle est proposee, et tester une vraie restauration depuis une sauvegarde. Dans les deux cas, la solution n'a jamais ete une question de juridiction du certificat ni de taille du cabinet d'avocats sous contrat : c'est une question de qui peut se connecter, de l'etat de mise a jour du logiciel, et de savoir si quelqu'un s'en apercevrait a temps.