Nettoyer un WordPress piraté en SSH : purge de masse et réinstallation propre

Il existe des piratages qu’on ne peut pas nettoyer depuis le tableau de bord WordPress. Trop de fichiers infectés, des permissions verrouillées, du code injecté à des endroits que l’interface n’atteint pas — à un certain point, la seule façon de reprendre le contrôle, c’est la ligne de commande. Cet article raconte deux interventions de ce type, où le nettoyage a dû se faire en SSH, au plus près du serveur.

C’est le versant le plus technique du métier. Je le détaille sans jargon inutile, mais sans le simplifier non plus — parce que c’est précisément cette profondeur qui distingue un vrai nettoyage d’un rafistolage de surface.

Quand un piratage déborde l’interface

Premier cas : à la suite de la compromission de plusieurs sites hébergés sur un même serveur, un répertoire de cache s’était rempli de manière démentielle — des centaines de millions de fichiers. À cette échelle, l’interface WordPress est inutilisable, et même les outils classiques de suppression s’effondrent : une simple commande d’effacement peut tourner pendant des heures, voire épuiser les ressources du serveur avant d’avoir fini.

La solution passe par des techniques de traitement de masse en ligne de commande. D’abord, réattribuer proprement les droits sur cette montagne de fichiers, en traitant les éléments par lots plutôt qu’un par un — sans quoi la commande n’aboutirait jamais. Ensuite, pour la suppression elle-même, une astuce que peu de gens connaissent : plutôt que d’effacer les fichiers directement, on synchronise le dossier surchargé avec un dossier vide. Cette méthode de synchronisation gère un volume massif de fichiers bien plus efficacement qu’une suppression classique, et transforme une intervention qui prendrait des heures en une opération de quelques minutes. La différence entre connaître cette technique et l’ignorer, sur un site en production, c’est la différence entre une coupure d’une matinée et une coupure de quelques minutes.

Anatomie d’un site transformé en outil de phishing

Le second cas était plus grave, parce que le site ne se contentait pas d’être infecté : il avait été transformé en arme.

En surface, il affichait une fausse page « COMING SOON », avec une redirection qui envoyait les visiteurs mobiles vers un site externe malveillant. Sous le capot, plusieurs couches d’attaque se superposaient. Des fichiers critiques avaient été injectés avec du JavaScript volontairement illisible — du code « obfusqué », rendu incompréhensible exprès pour échapper à l’analyse, truffé de redirections conditionnelles qui ne se déclenchaient que dans certaines circonstances.

Plus grave encore, un faux répertoire hébergeait une page de phishing imitant Microsoft 365 — une fausse page de connexion destinée à voler les identifiants de victimes qui n’avaient rien à voir avec le site. Le propriétaire hébergeait, à son insu, une infrastructure d’attaque contre des tiers.

Et pour couronner le tout, le fichier de configuration PHP du serveur avait été modifié pour réautoriser des fonctions dangereuses — celles qui permettent d’exécuter des commandes système directement depuis le web, normalement désactivées précisément pour empêcher ce genre d’abus. L’attaquant s’était rouvert les portes que l’hébergeur avait verrouillées.

La reconstruction : propre, sans rien perdre

Face à une infection aussi profonde, nettoyer fichier par fichier ne suffit plus — on ne peut jamais être certain d’avoir tout trouvé. La bonne approche, c’est la réinstallation propre, mais menée de façon à ne rien perdre des données légitimes. C’est un équilibre délicat.

Le travail a commencé par la suppression complète de l’ancien répertoire infecté en SSH, après avoir corrigé les permissions pour éviter les erreurs d’accès. Puis le nettoyage des fichiers de configuration détournés — le .htaccess, le wp-config.php, le fichier de configuration PHP — et la suppression des fichiers suspects.

Vient ensuite l’étape cruciale : préserver les données tout en repartant sur du sain. Sur une boutique en ligne, il est hors de question de perdre les commandes, les paniers et les comptes clients. La méthode consiste à analyser d’abord une sauvegarde saine antérieure à l’intrusion, à la comparer aux sauvegardes de l’hébergeur pour vérifier qu’aucune table critique n’a été altérée — comptes utilisateurs, commandes, contenus — puis à réinstaller un WordPress entièrement neuf que l’on reconnecte à cette base de données vérifiée. Le noyau est propre, les données sont intactes.

La reconstruction s’est poursuivie par la réinstallation manuelle de chaque extension depuis les dépôts officiels — jamais en reprenant les fichiers potentiellement infectés — l’installation du thème depuis sa source officielle sous licence, et la remise en ligne des seuls médias sains.

Le durcissement qui empêche la récidive

Une réinstallation propre sans sécurisation serait recompromise en quelques jours. La dernière phase, la plus importante pour l’avenir, consiste à verrouiller le site.

Cela passe par l’installation et la configuration d’un pare-feu applicatif complet — avec surveillance du trafic en direct, protection contre les attaques par force brute et scan étendu. Et par un .htaccess durci qui pose des barrières précises : blocage de l’accès aux fichiers sensibles, blocage des extensions à vulnérabilités connues, interdiction d’accéder publiquement aux sauvegardes, et surtout interdiction d’exécuter le moindre fichier PHP dans le dossier des téléchargements — un dossier où aucun code ne devrait jamais s’exécuter, et par lequel passent énormément d’attaques.

Avant la remise en ligne, chaque fonction est testée : accès administrateur, page produit, panier, tunnel de commande, e-mails transactionnels, formulaire de contact, navigation mobile. Un site n’est réellement « remis en service » que lorsqu’il est à la fois propre, sécurisé, et pleinement fonctionnel.

La leçon de ces deux cas

Certains piratages ne se règlent pas dans WordPress — ils se règlent en dessous, au niveau du serveur et des fichiers. Savoir purger des millions de fichiers sans faire tomber le serveur, reconnaître du JavaScript obfusqué, repérer un php.ini détourné, réinstaller proprement en préservant une base de données : c’est ce travail invisible qui sépare un nettoyage durable d’un site « réparé » qui rechute la semaine suivante.

Si votre site affiche une page qui n’est pas la vôtre, redirige vos visiteurs, ou se comporte comme s’il ne vous appartenait plus, il est probablement compromis en profondeur. Vous pouvez partir de mon panorama sur les sites WordPress piratés pour comprendre ce qui se passe, ou décrire votre urgence via ma page SOS site piraté.