Un site WordPress chiffré, remplacé par une page de rançon, ou bloqué par des fichiers modifiés, ce n’est pas un scénario théorique. Sur le terrain, ça arrive souvent après une suite de petites négligences: un plugin abandonné, des identifiants réutilisés, un thème jamais mis à jour, ou une console d’administration accessible trop largement. Et quand le ransomware s’installe, l’urgence est réelle, mais la précipitation peut coûter encore plus cher, surtout si vous effacez des preuves ou si vous remettez en ligne avant d’avoir sécurisé la faille.
Je vous propose une approche pragmatique, centrée sur ce que vous pouvez réellement faire pour nettoyer un site WordPress infecté et récupérer votre site sans répéter la catastrophe. Le fil conducteur, c’est simple: contenir, vérifier l’étendue, restaurer proprement, puis durcir.
Comprendre ce que le ransomware a fait (et ce que ça implique)
Dans les cas les plus fréquents, un ransomware WordPress agit en combinant plusieurs actions:
- il obtient un accès (souvent via une vulnérabilité de plugin, un mot de passe faible, une session détournée, ou une page exposée à l’extérieur), il dépose des fichiers malveillants à des endroits “discrets” (souvent dans wp-content, parfois dans des thèmes/enfants de thèmes, ou au niveau de fichiers PHP qui se chargent au démarrage), il modifie des fichiers légitimes pour exécuter une charge utile, il chiffrera ensuite certains contenus, ou affichera une page de rançon, parfois via un script qui intercepte le chargement.
Sur un WordPress, vous pouvez avoir des symptômes très différents: un front office qui affiche un message, une redirection, un backend (wp-admin) inutilisable, un site qui devient lent et qui consomme anormalement CPU ou requêtes externes, ou encore une série de fichiers nouvellement créés dont la date https://gardewp.fr/ colle étrangement au moment de l’incident.
Ce qui surprend souvent, ce n’est pas seulement la présence de fichiers malveillants, mais la façon dont l’attaque peut toucher plusieurs éléments en parallèle. Par exemple, on peut retrouver des shells PHP dans le répertoire uploads, des modifications du fichier wp-config.php, et en même temps des tables MySQL altérées. Si vous ne regardez pas l’étendue avant de restaurer, vous risquez de “réinfecter” le site au moment où vous relancez l’application.
Sécuriser tout de suite, même si vous êtes encore sous choc
Avant de nettoyer, la priorité absolue est de couper l’attaque. Sur un hébergement mutualisé ou géré, vous n’avez pas toujours le contrôle total, mais vous avez presque toujours des leviers.
D’abord, stoppez ce qui peut encore exécuter le code malveillant. Selon votre accès, ça peut passer par la mise en mode maintenance, la désactivation temporaire du site dans le panneau d’hébergement, ou la restriction d’accès à wp-admin via votre pare-feu (si vous en avez un). L’objectif est d’empêcher le ransomware de continuer à écrire, chiffrer, ou exfiltrer.
Ensuite, travaillez en “lecture” sur votre contenu, autant que possible. Si vous devez fouiller dans les fichiers, faites-le à partir de copies. J’ai déjà vu des équipes supprimer directement des dossiers entiers “parce que c’est suspect”, puis découvrir après restauration que le problème venait d’un fichier PHP discret dans wp-content/themes, pas du dossier supprimé. La suppression immédiate peut rendre le diagnostic beaucoup plus pénible.
Enfin, isolez les comptes. Réinitialisez les mots de passe de tous les utilisateurs WordPress, mais aussi ceux du serveur et de votre compte d’hébergement. Si l’attaque a pris le contrôle par une voie d’identifiants, vous voulez réduire la probabilité de retour, même si vous n’avez pas fini le nettoyage.
Évaluer l’étendue sans aggraver la situation
Le point clé ici est de ne pas se contenter d’un “ça a l’air propre”. Sur un WordPress touché par ransomware, vous devez vérifier au moins trois choses: les fichiers, la base de données, et la persistance.
Chercher la persistance dans le code
Commencez par identifier ce qui déclenche la charge malveillante. En pratique, on retrouve souvent:
- des fichiers inconnus dans wp-content/uploads, parfois avec des noms qui ressemblent à des images ou à des scripts, des modifications de fichiers d’amorçage (fichiers PHP chargés au début), des injections dans un thème ou un plugin, des tâches planifiées (cron) qui exécutent du code ou déclenchent des requêtes externes.
Un indice utile: si vous voyez des fichiers créés ou modifiés très récemment, autour de l’heure où le site a basculé, c’est un bon point de départ. Regardez aussi les tailles anormales de fichiers, les caractères illisibles, et les appels à fonctions qui n’ont rien à faire dans votre stack (par exemple, l’exécution système, l’écriture sur disque, des requêtes réseau côté serveur).
Je prends souvent une approche “diff”. Si vous avez des sauvegardes, comparez la version actuelle à une version connue saine. Si vous n’avez pas de sauvegardes, comparez vos fichiers à ceux d’une installation WordPress vierge correspondante, ou à votre thème/plugin de référence (dans la limite du raisonnable).
Vérifier la base MySQL
La base peut être infectée de plusieurs façons. Par exemple, des options WordPress modifiées peuvent créer une redirection, des pages “rançon” peuvent être injectées, des utilisateurs supplémentaires peuvent être créés, ou des scripts peuvent être stockés dans des champs de configuration.
Vérifiez aussi les utilisateurs: certains incidents ajoutent un compte administrateur discret. Et vérifiez la présence de fonctions ou de contenus qui ne devraient pas être là, par exemple du code PHP injecté dans des options ou des champs qui ne devraient contenir que des données.
Si votre accès base est limité, vous pouvez au moins exporter vos tables avant toute restauration, ou créer une sauvegarde de sécurité côté base. Ensuite, vous analyserez les tables suspectes. Le but est de pouvoir restaurer proprement sans perdre l’intégrité.
Inspecter les connexions sortantes et l’activité
Le ransomware peut aussi essayer d’appeler des domaines externes, ou d’envoyer des données. Selon votre hébergeur, vous n’aurez pas de logs détaillés, mais vous pouvez repérer des patterns: pic de requêtes, ressources CPU qui explosent, ou erreurs réseau côté serveur.
Si vous avez accès aux logs web (Nginx/Apache) et aux logs PHP, cherchez les requêtes vers des scripts inconnus, les erreurs “fopen”, “include”, “require” sur des chemins bizarres, ou des URLs de type “/somepath.php?…” qui n’appartiennent pas à votre site.
Ce travail a un avantage indirect: il vous aide à décider quoi restaurer et quoi réparer.
Nettoyer un site WordPress infecté: la méthode robuste
Il existe deux écoles. Une, “tout réinstaller”: c’est souvent la plus sûre. L’autre, “réparer au cas par cas”: elle peut fonctionner, mais elle demande une grande rigueur et des preuves solides. Dans un incident ransomware, la réinstallation contrôlée est généralement plus efficace.
Voici une stratégie que j’ai utilisée plusieurs fois, avec des résultats fiables.
1) Préparer un environnement de restauration
Ne nettoyez pas directement “en production” si vous pouvez l’éviter. Créez un environnement de travail, idéalement un sous-domaine temporaire ou un dossier séparé, où vous restaurerez la base et les fichiers propres. L’objectif est d’empêcher la propagation pendant que vous analysez.
Si vous n’avez qu’un accès direct sur le serveur de production, vous devez quand même préserver des copies. Faites une archive des fichiers et une sauvegarde de la base avant modifications.
2) Restaurer fichiers et base depuis une sauvegarde “saine”
Le meilleur scénario, c’est d’avoir une sauvegarde antérieure à l’incident. Si vous savez quand le site a basculé, regardez la sauvegarde juste avant cette période.
Mais il y a un piège fréquent: une sauvegarde peut elle-même être contaminée si elle date après l’injection. C’est pour ça qu’il faut, quand c’est possible, vérifier la sauvegarde. Ouvrez quelques fichiers suspects dans l’archive, repérez les scripts inconnus, vérifiez les dates et la structure. Ça peut sembler minutieux, mais c’est souvent le seul moyen d’éviter de réinfecter au redémarrage.
Si vous n’avez pas de sauvegarde saine, vous basculez vers une approche “réinstallation depuis sources” (WordPress core) et nettoyage minutieux de vos thèmes et plugins.
3) Réinstaller WordPress core et remettre à zéro les composants
Dans les nettoyages que je recommande, WordPress core est réinstallé proprement. Même si vous pensez que le cœur n’est pas touché, la revalidation réduit énormément le risque.
Concrètement, vous supprimez ou remplacez les fichiers WordPress core, puis vous remettez wp-config.php à partir d’une version saine. Attention à wp-config.php: beaucoup d’attaques ne le “changent” pas massivement, mais certaines tentent de jouer avec des paramètres. Si vous avez une copie saine, utilisez-la.
Pour wp-content, c’est là que ça se complique. La logique est la suivante: tout ce qui n’est pas votre thème ou vos plugins, vous le supprimez et vous le régénérez depuis vos sources. Les uploads, eux, peuvent contenir des fichiers malveillants. La réinstallation des fichiers ne suffit pas si des shells PHP sont cachés dans uploads.
4) Traiter uploads et contenus: le cas le plus délicat
Beaucoup de ransomware laissent derrière eux des fichiers qui ne sont pas forcément des images. Parfois, ils ajoutent des fichiers PHP déguisés ou des “faux” documents. Vous devez donc trier et vérifier.
La façon la plus sûre, c’est de comparer le contenu de wp-content/uploads à un export propre antérieur, ou à la liste des fichiers réellement attendus (ex: vos types de médias habituels). Si vous ne savez pas ce qui est attendu, vous devez faire un nettoyage plus radical.
J’ai déjà vu des équipes garder l’intégralité de uploads “parce que c’est trop long de trier”. C’est un pari risqué. Dans un incident ransomware, le coût d’un tri ou d’une suppression ciblée est souvent inférieur au coût d’une nouvelle infection.
Si vous avez des images importantes, vous pouvez extraire les métadonnées de vos médias (types, extensions), puis supprimer les fichiers qui ont des extensions ou contenus incohérents. Le but est de retirer les pièces maîtresses tout en minimisant la perte.
5) Recréer wp-config.php et réauthentifier proprement
Si des modifications ont été faites à wp-config.php, ou si vous avez un doute raisonnable, utilisez la configuration d’origine, puis générez de nouveau les clés de sécurité WordPress.
Ensuite, réauthentifiez. Même si vous réinitialisez les mots de passe, forcez une vérification complète: suppression des sessions actives côté WordPress, suppression de comptes inconnus, et contrôle des rôles.
C’est aussi le moment de vérifier que votre serveur ne donne pas accès à des répertoires inutiles, et que les droits d’écriture sont cohérents.
Récupérer votre site: remise en ligne sans rechute
Le nettoyage est une chose, la remise en ligne en est une autre. Sur certains ransomwares, des mécanismes restent en place jusqu’à ce que la faille initiale soit fermée. Si vous relancez avant de durcir, vous rejouez la même scène.
Je procède en trois phases: vérification en staging, redémarrage de service, puis surveillance.
Tester en environnement contrôlé
Une fois les fichiers restaurés et la base remise, vérifiez:
- le chargement public du site, le chargement de wp-admin, l’accès au REST API si vous l’utilisez, le comportement des formulaires, plugins actifs, et médias.
Je conseille aussi de tester les pages que le ransomware modifie souvent: page d’accueil, pages de contenu, pages d’erreur, et scripts d’intégration (si vous utilisez des plugins SEO, sécurité, ou caching).
Si vous voyez encore une redirection étrange, une page de rançon, ou des erreurs PHP, stoppez. Ne tentez pas de “faire comme si” en production.
Fermer les portes qui ont permis l’intrusion
La meilleure restauration échoue si la faille reste ouverte. C’est généralement ici que se trouve la vraie différence entre “on a nettoyé” et “on a résolu”.
Les causes typiques sont:
- plugin ou thème non à jour, mot de passe faible, absence de limitation de tentatives, manque d’authentification forte, intégration de fichiers malveillants via un fichier upload vulnérable.
Vous devez donc mettre à jour ce qui a été exploité, mais aussi limiter l’exposition. Si vous avez un pare-feu applicatif, utilisez-le. Si vous avez accès à un WAF côté hébergeur, activez les règles pertinentes. Et si vous pouvez, restreignez l’accès à wp-admin et à wp-login à des IP connues.
Surveiller les signaux pendant les 24 à 72 heures
Les rechutes arrivent souvent vite, et pas toujours sous la même forme. Parfois, l’attaque revient en modifiant de nouveaux fichiers, parfois en re-créant un compte, parfois en redéposant une charge via un cron.
Pendant 2 à 3 jours, surveillez:
- les logs d’erreurs PHP, l’activité cron, les nouveaux fichiers apparus dans des répertoires sensibles, les changements de base de données (au moins des tables clés et des utilisateurs).
Si quelque chose change sans explication, traitez-le comme un signe de persistance.
Un plan d’action concret, si vous devez agir aujourd’hui
Pour éviter de rester bloqué, je vous laisse un plan d’action court. Il n’a rien de magique, mais il suit la logique “contenir, vérifier, restaurer, durcir”.
Checklist d’urgence (courte)
Couper le site ou limiter l’accès à wp-admin le temps de stabiliser. Faire une sauvegarde des fichiers et de la base avant toute modification. Identifier les fichiers et entrées suspectes (créations récentes, injections, cron). Restaurer fichiers et base depuis une sauvegarde probablement saine, ou réinstaller WordPress core. Fermer la cause (mises à jour, mots de passe, durcissement, restriction d’accès).L’étape 3 peut sembler “optionnelle” à l’instant T, mais je la considère indispensable. Sans elle, vous risquez de restaurer une archive contaminée ou de laisser une persistance en place.
Durcir WordPress après ransomware: ce qui évite la deuxième attaque
Après une infection, on a tendance à penser “c’est bon, on a nettoyé”. En réalité, le nettoyage ne sert à rien si l’environnement reste vulnérable. La partie durcissement doit être immédiate, même si vous n’avez pas le temps de tout refactoriser.
Je commence par les bases: mots de passe uniques, suppression des comptes inutiles, et validation des rôles. Ensuite, j’insiste sur la surface d’attaque: mises à jour, réduction de l’exposition, contrôle des plugins.
Minimiser la surface d’attaque
Un WordPress robuste, c’est un WordPress avec moins de composants inutiles. Chaque plugin supplémentaire est un risque supplémentaire, même si la majorité sont sains.
Je fais généralement:
- suppression ou désactivation des plugins non essentiels, mise à jour des plugins critiques uniquement après vérification, remplacement des thèmes custom qui n’ont pas été entretenus.
Cela peut sembler “moins flexible”, mais c’est souvent le moyen le plus rapide de réduire l’aléa.
Sécuriser l’accès à l’administration
Sur les attaques qui visent wp-admin, la réduction du trafic suspect et la vérification des identifiants change tout. Si vous pouvez, activez l’authentification forte. Vérifiez aussi les limites de tentatives, et bloquez les accès manifestement automatisés.
Sur le terrain, on voit souvent le même pattern: une tentative d’accès à wp-login répétée, puis un succès via une paire identifiant-mot de passe. Sans protection, la probabilité de compromis finit par dépasser vos hypothèses.
Mettre en place une surveillance utile, pas décorative
Les logs “en théorie” ne servent à rien si personne ne peut les relire. L’objectif est d’avoir des signaux actionnables. Par exemple, repérer:
- une création de nouvel utilisateur, un changement anormal de fichiers PHP dans wp-content, une requête entrante vers un chemin inconnu, une exécution cron non attendue.
Même des alertes simples peuvent vous sauver. Une surveillance trop sophistiquée qui génère trop de bruit finit ignorée. Le bon équilibre, c’est des alertes rares mais pertinentes.
Cas particuliers et pièges fréquents
“On a restauré, mais le site re-chiffre”
Quand cela arrive, c’est presque toujours une persistance. Le plus courant: un fichier malveillant dans wp-content qui n’a pas été supprimé, un cron oublié, ou une base restaurée qui contient encore des entrées injectées.
La solution est de revenir en arrière: vérifier les fichiers et la base à partir d’un état juste après restauration. Si l’infection réapparaît, vous avez un mécanisme qui s’exécute à nouveau.
“On n’a pas de sauvegarde”
Dans ce cas, l’approche la plus sûre est souvent:
- réinstallation WordPress core, remplacement des thèmes et plugins depuis leurs sources, nettoyage radical de wp-content/uploads en limitant les types attendus, réinitialisation complète des utilisateurs et contrôle de la base.
Vous perdez peut-être du contenu si vous n’avez aucune trace, mais vous gagnez la certitude.
“Les fichiers ont l’air propres, mais le backend reste compromis”
Parfois, les fichiers publics semblent corrects, mais wp-admin est encore accessible via une porte cachée. On retrouve alors des modifications côté base, des options injectées, ou des comptes ajoutés.
Dans ces cas, le test le plus important est l’accès authentifié: vérifiez l’apparition de nouveaux rôles, la présence de comptes inconnus, et la cohérence des menus, plugins installés, et thèmes activés.
“Les plugins de sécurité ont aussi été touchés”
Ne partez pas du principe que “l’outil de sécurité a géré”. Beaucoup d’attaques contournent ces outils, ou se servent d’eux pour masquer l’activité. Vous pouvez utiliser la détection, mais au moment de la restauration, gardez votre logique de base: vous remplacez ce qui doit être remplacé, vous contrôlez ce qui doit être contrôlé.
Si vous devez choisir entre réparation et réinstallation totale
Vous aurez toujours le dilemme: gagner du temps en “réparant”, ou gagner de la certitude en “réinstallant”. En cas de ransomware, je penche vers la réinstallation contrôlée, parce que l’effort de réparation partielle peut être trompeur. Un seul fichier oublié peut suffire.
Je résume ma règle de décision de façon simple: si vous n’êtes pas certain à 100 pour cent de l’origine de la sauvegarde et de l’absence de persistance, réinstallez. Si vous avez des sauvegardes datées, une bonne visibilité des fichiers suspectés, et un plan clair de vérification, la réparation peut être acceptable, mais elle doit être prouvée, pas supposée.
Ce que j’inclus dans mon “rapport d’incident” après nettoyage
Après avoir nettoyé et récupéré, vous voulez éviter que “le même scénario” arrive à une autre personne. Un petit rapport, même minimal, fait gagner un temps énorme la prochaine fois.
Sans entrer dans une paperasse inutile, notez au moins:
- la date approximative de début de l’incident, les vecteurs plausibles (plugin, identifiants, exposition), ce qui a été restauré, depuis quel type de sauvegarde, ce qui a été supprimé ou remplacé (y compris dans wp-content), les changements de sécurité réalisés pour éviter la répétition.
C’est aussi utile si vous contactez votre hébergeur. Beaucoup de techniciens répondent plus vite quand vous fournissez des éléments concrets plutôt qu’un récit flou du “ça a été piraté”.
Nettoyer et récupérer: le moment où l’on reprend le contrôle
Ransomware WordPress et nettoyage site WordPress infecté peuvent sembler synonymes de “bricolage et espoir”. Sur une vraie reprise, on travaille avec de la méthode: on isole, on vérifie l’étendue, on restaure de façon contrôlée, puis on ferme la porte d’entrée. C’est plus long que “réinstaller un plugin”, mais c’est exactement ce qui évite la rechute.
Si vous êtes encore en train de subir l’incident, commencez par stabiliser et sauvegarder. Si vous êtes déjà dans la phase de récupération, l’enjeu n’est pas seulement de remettre le site en ligne, c’est de garantir qu’il ne sera pas réinfecté dans les heures qui suivent.
Si vous voulez, décrivez-moi votre situation en quelques lignes: hébergeur (ou type d’accès), présence d’une page de rançon, plugins récemment mis à jour, et si vous avez des sauvegardes datées avant l’incident. Je pourrai vous proposer un plan de nettoyage et de vérification adapté, en gardant la même logique de fiabilité.