Un site WordPress infecté ne “pousse pas juste un message bizarre” et ne se contente pas de laisser une porte ouverte quelque part. Quand un script malveillant a réussi à s’installer, il peut changer la manière dont le site se charge, modifier des pages clés, voler des identifiants, ou rediriger certains visiteurs vers des destinations qui n’ont rien à voir avec votre activité. Et le pire, c’est que tant que vous n’avez pas vérifié l’ensemble des points d’accès, “rebrancher en ligne” peut transformer une crise de sécurité en campagne de diffusion.
Je l’ai vu sur des cas très différents. Un soir, un hébergement a commencé à renvoyer des pages qui n’existaient pas, le lendemain la charge serveur s’est envolée, et le surlendemain des redirections ont été observées uniquement sur mobile. À première vue, tout semblait “rentré” après suppression du fichier suspect. En réalité, la charge venait d’un mécanisme de persistance qui se réinstallait à chaque purge, et les visiteurs étaient encore exposés.
Avant de remettre le site en prod, vous cherchez donc une réponse simple et exigeante à la fois : est-ce que la compromission est terminée, et est-ce que rien ne peut se réactiver ?
Clarifier ce que vous avez réellement “éradiqué”
Le premier piège, c’est de traiter l’incident comme une liste de fichiers à supprimer. Sur WordPress, un attaquant peut se contenter de placer un ou deux composants, puis s’appuyer sur une logique pour survivre au nettoyage. Il peut aussi modifier des paramètres de configuration, créer une tâche planifiée, ou injecter du code au niveau du thème ou d’un plugin.
Avant de rebrancher en ligne, je conseille presque toujours de reformuler l’objectif en termes d’état du système :
- le code malveillant a-t-il disparu des emplacements où WordPress le charge réellement ? les mécanismes d’exécution (tâches planifiées, hooks, templates, chargements de fichiers) sont-ils propres ? les accès utilisés par l’attaque ont-ils été neutralisés (comptes, clés, tokens, fichiers d’installation) ? votre processus de publication peut-il continuer à réinfecter dès qu’un admin se reconnecte, ou dès qu’un plugin se met à jour ?
Si vous ne pouvez pas répondre clairement à ces questions, “rebrancher” reste un pari.
Arrêter de courir après les symptômes, regarder les points de chargement
Sur un site WordPress, la grande majorité des infections finissent par agir sur le flux de rendu. Cela veut dire que vous pouvez retrouver des traces en examinant ce qui est réellement exécuté à l’affichage.
Le cœur de la vérification consiste à contrôler les endroits où WordPress s’appuie pour charger le thème, les extensions, et certaines configurations. Sans tomber dans la paranoïa sur chaque fichier du système, il faut être méthodique sur les couches applicatives.
Commencez par les bases, puis approfondissez selon ce que votre investigation a montré. Par exemple, si vous avez vu des redirections à partir du HTML, regardez l’emplacement où ce HTML est construit, et donc les thèmes, les fichiers de templates, et les hooks. Si votre hébergeur a observé des pics de CPU, pensez à un script qui tourne en tâche planifiée ou à un chargement conditionnel qui s’exécute sur certaines pages.
Je garde souvent en tête un principe pratique : un code malveillant “efficace” essaie rarement de tout casser. Il cherche plutôt à se faire oublier, à s’exécuter seulement dans certains cas, ou à déclencher ses actions après un nombre de visites.
Contrôler la liste d’accès : comptes, rôles et traces d’authentification
Même après suppression des fichiers, un site peut rester infecté si l’attaquant a laissé un accès. C’est fréquent quand l’incident implique des mots de passe faibles, une faille de plugin, ou une session compromise.
Avant la remise en ligne, vérifiez :
- les comptes WordPress créés récemment, surtout ceux avec des rôles élevés les changements de rôles (un compte “éditeur” devenu “administrateur” sans explication) la présence d’utilisateurs fantômes, parfois liés à des e-mails utilisés une seule fois les traces d’authentification côté hébergement si vous y avez accès (journaux, tentatives, IP inhabituelles)
Ce contrôle est aussi un contrôle de “persistance”. Si l’attaquant a un compte, il peut réinjecter du code dès que vous relâchez le site.
Un point concret que j’ai rencontré : sur un site, tous les fichiers modifiés avaient été restaurés, mais un nouvel utilisateur apparaissait toutes les 30 minutes. L’origine venait d’un plugin que l’équipe pensait “sûr” parce qu’il était ancien et très utilisé. L’attaque ne reposait pas sur un fichier unique, mais sur un morceau de code qui re-créait l’accès.
Vérifier les modifications de configuration et de base WordPress
Une compromission ne se limite pas au répertoire /wp-content/. Elle peut aussi toucher wp-config.php, la base de données, ou des options d’installation.
Avant de réouvrir le site, je recommande de vérifier les points suivants, au minimum :
Pour éviter de “faire de la magie” sans preuves, basez-vous sur votre historique d’attaque. Si vous avez un diff de fichiers avant/après, servez-vous en. Si vous n’en avez pas, faites une re-scan et comparez avec une installation WordPress de référence.
Attention aux faux positifs. Un plugin légitime peut contenir des fonctions qui ressemblent à du code réseau, par exemple pour des mises à jour ou des imports. Ce n’est pas la présence d’un motif qui vous intéresse en priorité, c’est l’intention et le contexte. Si du code appelle un domaine externe nouveau, en se déclenchant sur des pages précises, et qu’il n’y a aucune justification, vous avez une piste solide.
Inspecter thèmes et plugins : thèmes enfants, hooks, et “petits ajouts”
Dans les incidents WordPress, la majorité des contaminations sont localisées dans /wp-content/themes/ ou /wp-content/plugins/. Mais ce que les débutants oublient, c’est que l’infection peut être dans un fichier qui ne ressemble pas à une “shell”, au contraire.
Un thème enfant peut être le vecteur parfait. Le code malveillant peut être placé dans functions.php, dans un template chargé pour certaines URLs, ou dans des fichiers “fatals only” qui s’exécutent selon le user agent, la langue, ou l’horloge du serveur. Les attaquants font souvent dans le discret.
Pour les plugins, même logique. Un plugin peut être modifié en profondeur ou seulement patché à un endroit précis. Par exemple :
- inclusion conditionnelle de code quand une URL match un motif ajout d’un hook sur wp head, wpfooter, ou sur le chargement des scripts relecture de fichiers distants ou exécution de code encodé
Sans faire une liste d’actions exhaustive, la méthode pratique consiste à vérifier l’intégrité des thèmes et plugins par rapport à la version attendue. Si vous utilisez des plugins premium, vous devez comparer à la version exacte. Ensuite, ne vous contentez pas d’ouvrir “le fichier suspect” au hasard. Repérez comment il est appelé. C’est là que vous déterminez si vous avez réellement neutralisé la persistance.
Revoir les fichiers “qui ne devraient pas être là” et les répertoires inattendus
Quand un incident a déjà eu lieu, un site WordPress infecté laisse souvent derrière lui des éléments qui ne font pas partie d’une installation normale. Cela peut être :
- un fichier PHP placé dans un dossier inattendu un dossier ajouté avec des noms banals des fichiers chiffrés, souvent avec des extensions trompeuses des scripts temporaires qui se déclenchent à l’affichage
Ce que je fais toujours : contrôler la structure du système de fichiers dans la zone WordPress. Dans la pratique, la comparaison à une installation saine ou à une archive de référence vaut mieux que le jugement “à l’œil”. L’œil repère facilement un gros fichier, mais il rate le détail qui compte, comme un petit fichier ajouté dans une zone que vous ne consultez jamais.
En revanche, il faut garder un peu de prudence : certains hébergeurs ajoutent automatiquement des fichiers (cache, optimisation, scripts de sécurité). Ne supprimez pas au hasard, au risque de casser le site. La clé est la correspondance entre “ce que vous voyez” et “ce qui correspond à l’événement”.
Vérifier le réseau et la persistance applicative
Un site infecté peut chercher la persistance dans des mécanismes applicatifs, pas seulement dans les fichiers. Sur WordPress, deux leviers reviennent souvent :
- les tâches planifiées (WordPress cron ou cron système, selon la config) les hooks ajoutés ou les filtres modifiés qui réinjectent du contenu
Même si vous supprimez le code malveillant, la tâche planifiée peut le redéployer, ou la logique peut réécrire une page à chaque requête.
Donc avant de remettre le site en ligne, cherchez ce qui ressemble à une exécution planifiée ou répétitive. Dans un cas réel, l’équipe avait réinstallé le thème complet, tout était propre à un moment donné, puis l’infection revenait en moins d’une heure. La cause : une tâche planifiée déclenchait un téléchargement et réécrivait un fichier au bon endroit. Tant que la tâche existait, “nettoyer une fois” n’avait aucun sens.
Éviter le piège “c’est propre sur mon poste”
J’ai aussi vu des nettoyages réussis localement qui échouent en prod, parce que l’infection est conditionnelle.
Les attaques conditionnelles ciblent souvent :
- des navigateurs ou user agents spécifiques des pays ou des plages d’IP des pages particulières (checkout, login, résultats de recherche) une fréquence, par exemple une action après un certain nombre de visites
Avant de rebrancher en ligne, testez en conditions réalistes. Si vous pouvez, lancez des vérifications depuis plusieurs environnements : un mobile, un poste de bureau, et idéalement depuis un réseau différent. Le but n’est pas d’être parfait, c’est de réduire le risque de laisser une porte active sur une branche que vous n’avez pas observée.
Ce test est aussi lié à votre réputation et à vos utilisateurs. Si le site redirige certains visiteurs, votre action peut avoir un impact immédiat sur la confiance et sur la détection côté navigateurs ou moteurs.
Contrôler la chaîne de mise à jour : plugins, thèmes, et versions
La tentation après un incident est de restaurer rapidement, puis de remettre en ligne, quitte à “faire la mise à niveau plus tard”. Je ne recommande pas cette approche.
Si le site a été infecté parce qu’un plugin vulnérable a été exploité, vous devez corriger la cause, pas seulement l’effet. Cela implique souvent de :
- mettre à jour WordPress lui-même et les plugins/themes concernés supprimer les plugins inutilisés ou obsolètes vérifier les rôles et paramètres des plugins qui ont touché l’authentification ou la publication
Sur certains sites, un plugin a un cycle de mise à jour lent. Si le correctif n’existe pas, vous devez envisager une suppression, un remplacement ou une mitigation stricte côté serveur. Le compromis est toujours douloureux, mais rester en ligne avec la même surface d’attaque, c’est rejouer la même scène avec une autre victime.
Sécuriser immédiatement : durcir les accès et limiter le risque de réinfection
Un bon nettoyage, c’est aussi une préparation au “prochain jour”. Vous pouvez faire deux choses en parallèle : vérifier l’état du site et réduire la probabilité que quelqu’un réinjecte.
Après un incident, je fais généralement un durcissement minimal, ciblé sur ce qui a du sens pour l’équipe. Par exemple :
- forcer des changements de mots de passe pour tous les comptes vérifier l’authentification à deux facteurs si vous l’avez, l’activer si elle est compatible avec votre process limiter qui peut installer ou modifier des plugins révoquer les sessions ou tokens si votre environnement le permet
Je vous déconseille de vous arrêter au changement de mot de passe “admin”. Les comptes WordPress ne sont pas les seuls, et les accès hébergement peuvent exister via des clés SSH, des consoles, ou des panneaux. S’il y a eu une compromission de l’écosystème, changez aussi les identifiants côté hébergeur.
Préparer la remise en ligne avec une stratégie de test et d’observation
“Rebrancher en ligne” ne devrait pas être un interrupteur unique. Idéalement, vous réactivez le site de manière contrôlée, puis vous observez.
L’idée est simple : vous redonnez accès progressivement, pendant que vous surveillez les signaux faibles. Selon votre infrastructure, cela peut passer par une mise en mode maintenance, un accès limité, ou une restauration partielle des zones sensibles.
Sur le plan opérationnel, prévoyez une fenêtre pendant laquelle vous pouvez regarder les journaux. Si votre hébergeur fournit des logs de requêtes, utilisez-les. Si vous avez un monitoring, activez-le ou renforcez-le. Vous cherchez des patterns, pas des anomalies isolées.
J’ai une règle personnelle : quand on a un site WordPress infecté, je préfère passer une heure de plus à observer la première demi-journée plutôt que de “récupérer vite” et de découvrir deux semaines après que la compromission a continué discrètement.
Cas pratiques : ce que j’ai vu quand on rebranche trop tôt
Sur un site e-commerce, le nettoyage avait été fait en supprimant un thème modifié. Le site est revenu, les pages d’accueil semblaient normales. Mais une zone de connexion restait vulnérable, et l’injection ne se voyait que lorsque quelqu’un arrivait sur la page de login depuis une redirection. Les utilisateurs ont vu des tentatives de capture ou des messages étranges, pas toujours au même moment. Dans ce type de scénario, rebrancher trop tôt signifie que vous laissez l’attaque exploiter la distribution, pas seulement le code.
Sur un autre site, l’équipe avait restauré les fichiers, mais avait gardé une règle serveur modifiée dans .htaccess. Résultat : certains chemins d’URL renvoyaient vers une destination alternative. Le site “global” paraissait sain, mais une poignée de pages étaient mauvaises. Le jour de la remise, tout semblait bon jusqu’à ce que le crawler de vérification du moteur tombe sur un chemin particulier.
Ces exemples montrent la même leçon : la vérification ne doit pas se limiter à “le thème s’affiche”. Elle doit couvrir les comportements, surtout ceux qui ne se manifestent pas sur l’accueil.
Checklist courte avant rebranchage (celle que j’utiliserais en salle de crise)
Je sais que vous voulez une liste, alors je vous donne une checklist courte, utile, et volontairement orientée décision. Pas pour remplacer votre analyse, pour servir de garde-fou quand tout le monde est fatigué.
Pouvez-vous lister précisément ce qui a été modifié, supprimé, ou restauré, et où ? Tous les comptes WordPress et accès d’hébergement à risque ont-ils été vérifiés et sécurisés (rôles, mots de passe, sessions) ? Thèmes, plugins, et fichiers de configuration ont-ils été comparés à l’état attendu, sans “zone grise” ? Les tâches planifiées, hooks, et mécanismes de persistance connus ont-ils été neutralisés ? La phase de remise en ligne s’appuie-t-elle sur des tests réels et une observation des journaux ?Si une de ces réponses est floue, le risque n’est pas théorique.
Plan de revalidation après la remise en ligne
Même une fois en ligne, vous ne passez pas en mode “ok c’est fini”. La révalidation doit continuer un peu, car certaines attaques sont lentes ou déclenchées plus tard.
Sur les jours qui suivent, je recommande de surveiller :
- la disponibilité et les erreurs serveur (codes HTTP, pics de latence) les modifications de fichiers (si vous avez une journalisation ou un système de vérification d’intégrité) les anomalies de comportement (redirections, scripts externes, changements de templates) l’apparition de nouveaux comptes ou de nouveaux changements d’utilisateurs
Vous n’avez pas besoin de surveiller en continu à la seconde près, mais vous devez avoir un rituel. Par exemple, un contrôle manuel des éléments critiques à J+1 et J+3, puis une vérification automatique si possible.
Ce qu’il faut éviter à tout prix
Quand on est sous pression, on peut commettre des erreurs très humaines. Je les résume ici en quelques principes, parce qu’ils reviennent souvent.
Ne réinstallez pas à l’aveugle tout ce que vous avez “en trop”, sans savoir ce qui était lié à l’attaque. Ne copiez pas un dossier “propre” obtenu au hasard, sans vérifier la compatibilité et la version exacte. Et surtout, ne laissez pas des identifiants d’administration partagés, ni des processus de déploiement non contrôlés, après un incident.
Un autre point : le site peut être “techniquement propre” mais non sécurisé. Si vous réactivez sans patcher la cause, l’attaque revient. Dans les incidents WordPress infecté, le retour est souvent la conséquence d’une omission plus que d’une nouvelle intrusion.
Quand faire appel à une aide spécialisée
Vous pouvez gérer beaucoup de choses en interne, mais il y a des signaux qui justifient une expertise externe. Par exemple :
- vous n’avez pas accès aux journaux serveur et vous ne savez pas comment l’infection revient le code semble se réécrire ou se déclencher à des moments difficiles à reproduire plusieurs vecteurs semblent être en jeu, plugins, accès, tâches planifiées, et configuration le site a une taille importante et vous n’êtes pas en mesure de faire une comparaison d’intégrité fiable
L’enjeu n’est pas seulement de “nettoyer”, c’est de comprendre et de fermer. Si vous n’avez pas la visibilité, vous risquez de rouvrir un canal.
Mot de prudence sur la réputation et l’affichage
Quand un site a été infecté, il peut être perçu comme dangereux par des navigateurs ou des services. Même si vous nettoyez, les historiques peuvent prendre du temps à se dissiper selon les systèmes de détection.
Cela ne doit pas vous empêcher de remettre en ligne si vous avez neutralisé la compromission, mais cela explique pourquoi la surveillance doit durer. Vous pouvez aussi envisager de vérifier les signaux disponibles depuis des outils de diagnostic, tant au niveau réseau qu’au niveau des pages indexées.
Le point clé reste : votre action doit être guidée par la preuve que la compromission est terminée, pas par l’impression que “ça marche”.
Finalement, “rebrancher” signifie quoi dans un site WordPress infecté ?
Rebrancher en ligne après une infection, ce n’est pas remettre le DNS ou le mode maintenance. C’est reprendre le contrôle du comportement de WordPress, des accès, et des points d’exécution. La différence entre un site “visible” et un site “sain” tient souvent à la persistance : tâches planifiées, hooks discrets, changements de configuration, ou comptes laissés ouverts.
Si vous faites ces vérifications, que vous testez depuis plusieurs angles, et que vous observez les premières heures, vous réduisez fortement le risque de réinfection immédiate. Et vous transformez une urgence en chantier propre, avec des décisions rationnelles, plutôt qu’avec l’espoir.
Si vous https://gardewp.fr/nettoyage-malware-wordpress/ voulez, décrivez-moi votre contexte, par exemple : ce que l’hébergeur a observé, les plugins récemment mis à jour, et s’il y avait des redirections ou des fichiers inconnus. Je pourrai vous proposer une liste de vérifications plus ciblée pour votre cas, sans vous faire perdre de temps sur des pistes peu probables.