J’ai nettoyé un site WordPress compromis : retour sur une intervention réelle

Un site qui fonctionne n’est pas forcément un site sain

Un site WordPress peut afficher normalement sa page d’accueil tout en hébergeant du code malveillant. C’est ce qui rend certaines infections difficiles à remarquer : il n’y a pas nécessairement de page défigurée, de message d’erreur ou de panne visible.

Lors d’une intervention récente, l’examen des fichiers d’un site vitrine a fait apparaître plusieurs éléments anormaux. Certains scripts PHP étaient placés dans des répertoires où l’on ne s’attend pas à trouver du code exécutable. D’autres portaient des noms qui pouvaient passer pour des fichiers ordinaires du site.

Le constat le plus sérieux venait de leur comportement : certains fichiers récupéraient du contenu depuis une adresse distante et tentaient de l’exécuter sur le serveur. Ce n’était pas simplement du code ancien ou une extension mal configurée. La compromission devait être traitée comme un véritable incident de sécurité.

Première étape : préserver une copie avant de toucher aux fichiers

Ma priorité n’a pas été de supprimer immédiatement tout ce qui semblait suspect. J’ai d’abord cherché à préserver l’état du site et à disposer de copies de la base de données et des fichiers. Même un environnement compromis peut contenir des éléments utiles pour comprendre l’incident ou revenir en arrière si une intervention cause un problème.

J’ai également conservé les traces pertinentes de l’intervention. Un inventaire et des empreintes numériques des fichiers isolés permettent de documenter ce qui a été trouvé sans devoir laisser le code malveillant accessible depuis le Web.

Cette précaution est essentielle : effacer trop vite les indices peut compliquer l’analyse et ne garantit aucunement que l’attaquant a perdu l’accès.

Des fichiers malveillants répartis à plusieurs endroits

Le nettoyage a révélé plus d’une dizaine de fichiers PHP suspects, répartis entre plusieurs emplacements de l’installation : dossiers de contenu, fichiers de thèmes ou d’extensions et autres répertoires du site.

Une partie de ces scripts jouait le rôle de chargeur : le fichier local n’avait pas besoin de contenir l’ensemble du programme malveillant, puisqu’il pouvait aller chercher de nouvelles instructions ailleurs. C’est l’une des raisons pour lesquelles un simple examen de l’apparence du site ne suffit pas.

Plutôt que de détruire les fichiers immédiatement, je les ai déplacés hors du répertoire accessible au public, dans un espace de quarantaine aux permissions restreintes. Ils ne pouvaient ainsi plus être invoqués directement par une requête Web, tout en demeurant disponibles comme éléments de preuve.

J’ai ensuite recherché les mêmes signatures et comportements dans le reste de l’arborescence, y compris les fichiers moins visibles et les éléments générés par certaines extensions. Un cache contenant du code suspect a également été conservé comme preuve avant nettoyage.

Quatre comptes administrateurs qui n’avaient rien à faire là

Les fichiers n’étaient qu’une partie du problème. L’examen des comptes WordPress a aussi mis en évidence quatre comptes administrateurs suspects, qui ont été révoqués.

C’est un point majeur : même après avoir retiré un script malveillant, un compte disposant encore des privilèges d’administration peut permettre de réinstaller du code, de modifier les extensions ou de créer un nouvel accès.

Une remise en sécurité doit donc couvrir les fichiers et les identités : utilisateurs, rôles, sessions, mots de passe, comptes d’hébergement et moyens d’accès au serveur. La réinitialisation des accès légitimes et l’authentification multifacteur font partie des protections à prévoir.

Vérifier l’intégrité, puis moderniser l’installation

Une fois les éléments suspects isolés, j’ai vérifié l’intégrité du cœur de WordPress en comparant ses fichiers aux versions officielles. Cette vérification aide à repérer les modifications anormales, mais elle ne suffit pas à inspecter les extensions, les thèmes, les fichiers téléversés ou la base de données.

L’intervention a aussi nécessité une remise à niveau de l’environnement : WordPress, le thème et des composants tiers ont été réexaminés, et la version de PHP a été modernisée par étapes pour préserver la compatibilité du site.

Ces changements se font avec prudence. Sur un site ancien, une mise à jour trop brusque peut entraîner des erreurs d’affichage ou des fonctions qui ne répondent plus. Les pages importantes et les extensions indispensables ont donc été vérifiées au fur et à mesure.

Les vérifications après le nettoyage

Après la quarantaine et les corrections, des contrôles ont été effectués pour rechercher les signatures malveillantes connues, examiner certains fichiers de configuration, vérifier la cohérence de WordPress et confirmer que le site répondait toujours correctement.

Le fait que la page d’accueil fonctionne et que les signatures recherchées ne soient plus présentes est encourageant. Ce n’est toutefois pas une preuve absolue que toute possibilité de persistance a disparu. Une vérification ponctuelle ne peut pas garantir à elle seule que tous les accès détournés ont été identifiés.

La suite logique est de revoir les journaux disponibles, de vérifier tous les moyens d’accès, de poursuivre les contrôles des extensions et de surveiller les changements inattendus après la remise en service. L’origine exacte de l’intrusion ne doit pas être annoncée tant qu’elle n’est pas établie.

Ce que cette intervention m’a rappelé

La désinfection d’un site WordPress ne consiste pas à installer une extension de sécurité et à cliquer sur « Nettoyer ». C’est une démarche structurée qui demande de protéger les données, d’identifier les éléments suspects, d’isoler les fichiers, de reprendre le contrôle des comptes et de vérifier les composants du site.

Elle rappelle surtout l’importance de l’entretien préventif : versions logicielles à jour, privilèges limités, sauvegardes vérifiées, surveillance et possibilité de restaurer le site dans un environnement sain.

Le vrai objectif n’est pas seulement de remettre la page d’accueil en ligne. C’est de réduire le risque que le même incident se reproduise.

Et si votre site WordPress semble compromis?

Évitez de supprimer des fichiers au hasard ou de lancer une restauration sans conserver de copie. Commencez par documenter les symptômes, protéger les accès et établir un plan de récupération adapté à votre hébergement.

Pour les étapes générales, j’ai aussi publié un guide : Mon site WordPress est piraté : quoi faire, étape par étape.

La documentation officielle WordPress recommande également de documenter l’incident, examiner les accès, sauvegarder avant le nettoyage et rechercher les moyens de persistance.