Le pharma hack détourne l'autorité de votre nom de domaine. Votre site a de l'ancienneté, des liens entrants, une réputation aux yeux de Google : c'est exactement ce que cherche un vendeur de contrefaçons pharmaceutiques, qui ne peut rien construire de durable sous son propre nom.
Les trois signes qui ne trompent pas
- Le rapport de performances de la Search Console fait apparaître des requêtes de pharmacie sur lesquelles vous n'avez jamais écrit une ligne.
- Une recherche
site:votredomaine.frsuivie d'un nom de médicament renvoie des résultats. - Le nombre de pages indexées dépasse largement le nombre de pages que vous avez publiées.
Un quatrième signe, plus discret, mérite attention : des visiteurs vous signalent une redirection étrange depuis Google uniquement, alors que l'adresse tapée directement fonctionne. Beaucoup de variantes ne se déclenchent que si le visiteur arrive depuis un moteur de recherche, et parfois seulement sur mobile.
Où se cache le code
Le pharma hack est réputé pour sa capacité à se dissimuler à plusieurs endroits à la fois. Sur les interventions que je mène, je le retrouve régulièrement dans :
- un fichier chargé automatiquement avant WordPress, ce qui lui permet de survivre à la suppression de toutes les extensions ;
- une entrée de la table des options, encodée, appelée par un morceau de code d'apparence anodine ;
- le fichier de configuration du serveur, qui redirige selon le référent ou le navigateur annoncé ;
- un fichier du thème, avec une récupération de contenu depuis un domaine distant, ce qui permet à l'attaquant de changer la charge sans jamais retoucher votre site.
C'est ce dernier cas qui explique pourquoi une extension de sécurité peut afficher un site parfaitement sain pendant des mois. Le fichier local ne contient aucun code malveillant : il ne fait qu'aller chercher ailleurs ce qu'il doit afficher.
Pourquoi le nettoyage échoue si souvent
La plupart des nettoyages ratés que je reprends ont un point commun : ils ont traité les fichiers et pas la base, ou l'inverse. Or le pharma hack fonctionne en tandem. Le fichier lit la base, la base alimente le fichier. Retirer l'un des deux laisse le site en apparence propre pendant quelques jours, puis tout revient.
Sur un cas récent, le prestataire précédent avait entièrement refait les fichiers du site, correctement, et facturé son intervention. Le code parasite se trouvait dans la base de données, qui avait été transférée telle quelle. Les traces les plus anciennes remontaient à un an. Ce n'était pas une réinfection : l'infection n'était jamais partie.
La méthode que j'applique
- Vérifier le rendu avec l'identité de Googlebot. C'est la seule façon de voir ce que Google voit. Un site peut paraître irréprochable dans un navigateur et servir des milliers de liens à Googlebot.
- Détecter par structure, pas par mot-clé. Un code fragmenté en petits morceaux concaténés échappe à toute recherche par mot. Je détecte les caractéristiques : longueur des chaînes encodées, densité de séquences d'échappement, nombre de concaténations courtes.
- Balayer tous les sites du même compte. Sur un hébergement mutualisé, tous les sites partagent le même utilisateur système. Une faille sur un site donne accès à tous les autres. Nettoyer un site sans regarder ses voisins, c'est perdre son temps.
- Archiver avant de supprimer. Tout fichier retiré est mis de côté, jamais effacé. Certains fichiers au nom illisible sont parfaitement légitimes, et je préfère pouvoir restaurer que devoir m'excuser.
Après le nettoyage
Le retour dans les résultats prend en général de quelques jours à quelques semaines. Je demande la réindexation des pages légitimes, je vérifie qu'aucune action manuelle n'a été prononcée, et je contrôle le profil de liens entrants : dans certains cas, un réseau de liens a été construit vers les pages parasites, et il faut savoir si un désaveu se justifie. Le plus souvent il ne se justifie pas, et je le dis plutôt que de facturer une prestation inutile.