Reprise après piratage WordPress : nettoyer vs refaire. Le client veut que ça « redevienne comme avant » pour demain. Moi je veux un site dont je peux répondre. Un scan vert après un plugin de ménage ne suffit pas : les portes (admin, XML-RPC, plugin vulnérable, thème piraté (nulled)) sont encore là. Cet article pose les premiers gestes (hors ligne, sauvegarde forensic, mots de passe), quand un nettoyage est honnête, quand une réinstallation + restauration des contenus est plus sage, et comment ne pas être de nouveau piraté à J+10.
🦠 Heure 0 : isoler, copier, ne pas « réparer à chaud »
Mode maintenance ou vhost down. Copie fichiers + base (forensic, pas seulement « pour remettre »). Tourner tous les secrets (WP, FTP, hébergeur, SMTP, caisse). Notifier la CNIL sous 72 h et prévenir les clients si des données personnelles ont pu fuir (RGPD) : ce n'est pas optionnel.
Réinstaller un plugin « malware remover » en prod pendant que la porte dérobée reste ouverte, c'est souvent inutile. On travaille sur la copie.
🧹 Quand nettoyer est tenable
On connaît le point d'entrée (plugin X, mot de passe admin), on a une sauvegarde d'avant, le cœur de WordPress n'a pas été modifié, peu de custom. On restaure la sauvegarde d'avant, on patche, on durcit. Le « nettoyage fichier par fichier » d'un core modifié, je m'en méfie.
Comparer à une copie saine de WordPress + thème officiel. Tout fichier en plus se justifie.
- Entrée identifiée
- Backup antérieur propre
- Durcissement le jour même
- Monitoring 14 jours
🧱 Quand on refait
Plusieurs portes dérobées, thème nulled (piraté), admin créé tout seul, client qui « a déjà nettoyé trois fois ». On pose un WordPress neuf, on importe les contenus, on ne réimporte pas les plugins morts. C'est une mini-refonte de socle. Les URL se gardent.
Plus cher au départ. Moins cher que trois sites défigurés.
✅ Pour ne pas récidiver
2FA, moins d'admins, XML-RPC désactivé, maj, copie de test, sauvegardes qui restaurent. TMA. Sans ça, le plus beau ménage est un intervalle.
Nettoyer vs refaire : je tranche après la copie, pas après le rapport du scanner.
Un scan vert n'est pas une clôture d'incident. C'est un indicateur.
✅ Liste de contrôle après une reprise
Après une reprise, j'écris ce qui a été trouvé, ce qui a été supprimé et ce qui reste à surveiller. La mesure qui compte : aucun fichier modifié inconnu, aucun compte admin en trop et aucune redirection suspecte dans les jours qui suivent.
Sauvegarde saine restaurable, tous les mots de passe changés, 2FA (double authentification) sur wp-admin. Puis le nettoyage ou la reconstruction. Puis 14 jours de surveillance (alertes, Search Console, journaux). Sans ce suivi, on a « nettoyé », mais on n'a pas vérifié que la porte est fermée.
- Inventaire des fichiers modifiés et des comptes admin avant nettoyage
- Copie de test avant de remettre en ligne
- Un changement à la fois, documenté
- Contrôle des fichiers et des redirections pendant les 14 jours qui suivent
📌 Ce que je refuse sur ce sujet
Je refuse de nettoyer un site sans chercher par où le pirate est entré : sans cela, il revient. Je refuse aussi de restaurer une sauvegarde sans savoir si elle date d'avant l'intrusion.
Si le site est trop ancien ou trop modifié pour être nettoyé avec confiance, je vous conseille de le refaire et je vous explique pourquoi.
🧭 Questions fréquentes
Faut-il agir tout de suite ? Oui, tant que le site affiche du contenu douteux, redirige vos visiteurs ailleurs ou envoie des mails à votre place. Une fois le site coupé et sécurisé, la remise en état se planifie sans bâcler, et se juge au risque évité plutôt qu'à l'outil de nettoyage choisi.
Peut-on réparer sans site de test ? Pas après un piratage : on remonte une copie propre, on la vérifie à l'abri, puis on bascule. Voir Tester un site WordPress en local et en préprod pour monter cette copie de test.
Combien de temps ? De quelques heures pour un site simple à plusieurs jours si la base est abîmée et que les accès doivent tous changer. Un devis « une heure, tout compris » ne couvre ni la recherche de la faille ni la surveillance qui suit.
