Un nettoyage réussi se juge à un seul critère : le site est-il encore propre trois semaines plus tard. C'est un critère exigeant, et c'est celui qui sépare le retrait de fichiers du vrai travail.
L'ordre compte, et il est contre-intuitif
1. Inventorier avant de toucher à quoi que ce soit
La première commande d'une intervention ne doit rien modifier. Tout déplacement, toute correction de droits, toute suppression réécrit la date de changement des fichiers et détruit la seule chronologie fiable dont vous disposez. On inventorie d'abord, on nettoie ensuite.
Et surtout : ne vous fiez pas à la date de modification affichée. Les kits actuels la falsifient. C'est l'écart entre la date de modification et la date de changement d'inode qui trahit un fichier déposé, parce que le noyau écrit la seconde et qu'aucune commande ne la réécrit.
2. Chercher la persistance avant les symptômes
La question utile n'est pas « où est le code malveillant », c'est « comment revient-il ». Sur une intervention récente, la vraie porte n'était même pas dans le site : c'était un utilitaire réseau lancé depuis le fichier de démarrage du compte, avec des binaires cachés dans des dossiers de configuration et un nom de processus déguisé. Aucune suppression de fichier dans le site n'y aurait changé quoi que ce soit.
3. Vérifier l'intégrité du cœur
La vérification des empreintes du cœur WordPress est l'outil le plus rentable de la méthode : sur un cas récent, elle a révélé 7 434 fichiers étrangers d'un seul coup. Elle a cependant deux angles morts qu'il faut connaître : elle ne couvre ni le fichier de configuration, ni les thèmes et extensions, qui sont justement là où se cache l'essentiel.
4. Détecter par structure, pas par mot-clé
Chercher des mots comme « eval » ou « base64 » ne trouve pas un code fragmenté en dizaines de petits morceaux concaténés. Il faut détecter des caractéristiques : longueur des chaînes encodées, nombre de concaténations courtes, densité de séquences d'échappement. C'est ainsi qu'on trouve ce que les extensions ne voient pas.
5. Nettoyer la base
C'est l'étape la plus souvent oubliée, et celle qui explique la majorité des réinfections apparentes. Le contenu injecté vit souvent en base, dans les articles, les options, les widgets ou les métadonnées. Un nettoyage de fichiers laisse tout cela intact.
6. Vider tous les caches, puis vérifier
Un site continue de servir l'ancien contenu tant que le cache objet n'est pas vidé. Le nettoyage paraît avoir échoué alors qu'il a réussi. Je vérifie ensuite chaque page du plan de site, une par une, en code de réponse.
Les pièges qui coûtent cher
- Supprimer sans lire. Certains dossiers d'extension au nom illisible sont parfaitement légitimes, installés depuis une archive. J'en ai supprimé trois à tort avant d'adopter la règle : on archive systématiquement avant de retirer.
- Croire un garde-fou. Sur une intervention, une ligne modifiée dans une extension conditionnait la faille d'origine à un paramètre secret. L'attaquant avait refermé la porte derrière lui pour s'en réserver l'usage et évincer ses concurrents. Un correctif discret dans une extension figée depuis des années est un signal, pas un soulagement.
- Oublier les listages de dossiers. Sur un site, le dossier de dépôt d'un formulaire renvoyait un listage de 308 liens : 606 CV de candidats téléchargeables par n'importe qui. Cette exposition n'avait aucun rapport avec l'intrusion et existait probablement depuis des années. Au sens du RGPD, elle était plus grave que la compromission elle-même.
- Ne pas tester l'envoi des courriels. Après remise en ligne, un formulaire peut afficher un message de confirmation, enregistrer la demande, ne produire aucune erreur, et pourtant n'envoyer aucun courriel. C'est arrivé sur une intervention : l'adresse d'expéditeur retombait sur une adresse gratuite, et les destinataires écartaient les messages en silence.
Ce qui reste après
Un nettoyage complet se termine par le renouvellement de tous les accès, la rotation des clés de session, la coupure de l'exécution de code dans les dossiers de téléversement, et un rapport écrit qui dit ce qui a été trouvé, où, et depuis quand. Ce rapport n'est pas un document de confort : c'est ce que réclamera votre hébergeur, et c'est ce qui vous permettra de savoir, dans six mois, si un nouvel incident est une rechute ou une nouvelle affaire.