Quand un site WordPress se fait contaminer, le réflexe humain est souvent de “nettoyer”. Le problème, c’est que “nettoyer” veut dire des choses très différentes selon l’attaquant, selon la façon dont il s’est caché, et selon ce que vous remettez en ligne après coup. J’ai vu des nettoyages réussis sur le moment, puis une réinfection quelques jours plus tard, exactement parce que la réinstallation n’avait pas été assez “fermée” autour du point d’entrée.
Le bon objectif n’est pas uniquement d’effacer un fichier malveillant visible. C’est de réinstaller de façon propre et surtout de rompre la chaîne de réinfection. Cela passe par trois chantiers en parallèle: identifier le vecteur initial, remplacer le code de confiance (thème, plugins, cœur WordPress) et verrouiller l’environnement (accès, base de données, fichiers upload, planification, permissions). Vous gagnez en sérénité quand vous faites ces trois choses, dans cet ordre, sans laisser de “coins” non traités.
Les signes qui comptent vraiment, et ceux qui trompent
Un site “cassé” après une attaque peut être évident: redirections vers des domaines louches, contenu injection de spam, trafic SEO qui s’effondre, ou alertes dans des outils de sécurité. Mais certaines contaminations sont plus sournoises, et elles laissent des traces qui ressemblent à d’autres problèmes.
J’ai déjà vu une équipe croire que le site était infecté alors que c’était une combinaison de cache agressif et de plugin de traduction mal configuré. A l’inverse, j’ai vu un cas où la page d’accueil semblait “normale”, mais une porte dérobée était active via un fichier dans un répertoire rarement inspecté, et le spam sortait seulement quand un navigateur précis touchait une URL de test.
Pour rester pragmatique, concentrez-vous sur des indices qui reviennent, par exemple:
- des URLs inconnues ajoutées dans des redirections, des fichiers créés récemment dans des dossiers inattendus, une modification cohérente de thèmes ou plugins même après suppression, l’apparition de comptes administrateurs ou de clés d’API dont vous n’avez pas l’historique.
Même si vous n’avez pas encore trouvé “le” malware, ces signaux vous disent une chose importante: le problème n’est pas seulement un fichier isolé, il y a très probablement un accès ou une persistance quelque part.
Pourquoi réinstaller “proprement” est différent d’un simple nettoyage
Le cœur WordPress est assez simple à remettre en état puisqu’il existe une base de référence officielle, et que vous pouvez le remplacer à l’identique. Là où ça se complique, c’est que les attaques WordPress s’attaquent souvent à la périphérie:
- le thème actif ou un thème “abandonné” mais encore présent, des plugins rarement mis à jour, parfois installés par inadvertance, des scripts dans les uploads, ou des fichiers “poubelle” laissés par un outil automatisé, la base de données, où des options, des champs ou des tables peuvent contenir des charges utiles, des mécanismes de persistance, comme des tâches planifiées, des hooks, ou un accès via un compte créé pendant l’attaque.
Réinstaller, ce n’est pas juste supprimer puis réactiver. C’est reconstruire avec une source de confiance, puis vérifier que les points de sortie (fichiers et base) restent propres.
Le piège classique est de réinstaller le cœur et quelques dossiers, tout en gardant intacte la base de données. Dans beaucoup de cas, la base n’est pas “juste” contaminée, elle est le moteur: redirections, scripts injectés, nouveaux utilisateurs, ou options modifiées pour lancer la charge utile au prochain chargement.
Étape zéro, avant même de toucher aux fichiers: le “plan de retour”
Avant toute suppression, faites-vous une promesse simple: vous devez pouvoir restaurer rapidement sans dépendre de la mémoire.
Dans la pratique, ça veut dire cloner votre installation, même imparfaitement, pour conserver:
- vos fichiers actuels (avec un horodatage), une export de la base de données, une liste des extensions installées et des versions, un inventaire de vos utilisateurs (au moins les admins).
Le but n’est pas d’espérer que l’ancienne version soit “sainable”, mais de ne pas vous retrouver bloqué si vous effacez trop vite ou si la réinfection est plus profonde que prévu. J’ai déjà perdu du temps parce que l’hébergement n’avait gardé aucune sauvegarde exploitable, et l’équipe a dû reconstruire des réglages à la main.
Si vous avez un accès shell, conservez aussi les logs web et, si possible, les logs d’accès aux fichiers. Ce matériau devient précieux pour confirmer le vecteur d’entrée.
Identifier le vecteur d’entrée, sans s’enfermer dans une chasse au fichier
Le malware WordPress suit des logiques récurrentes, même quand il change de signature. La logique la plus utile, c’est celle-ci: comment l’attaquant est arrivé à écrire quelque chose sur votre serveur?
Les causes fréquentes sont:
1) un identifiant compromis (mot de passe réutilisé, phishing, session active), 2) une vulnérabilité dans un plugin ou un thème, 3) une configuration faible (droits d’écriture trop larges, accès FTP trop permissif), 4) des fichiers upload accessibles et instrumentés, 5) une prise de contrôle via un ticket support ou un workflow automatisé.
Vous n’avez pas besoin de deviner parfaitement pour agir correctement. Vous devez surtout constater un fait: il existe une persistance, ou vous n’êtes pas certain de l’éliminer. Dès que vous voyez un compte admin inconnu, ou un fichier PHP ajouté récemment, ou des modifications répétées après tentative de suppression, vous devez traiter le problème comme “vecteur actif”, pas comme un nettoyage ponctuel.
Nettoyage malware WordPress: la méthode qui réduit le risque de réinfection
Voici la séquence qui, dans mon expérience, marche le mieux quand l’objectif est une réinstallation propre, sans réinfecter.
1) Couper la propagation et réduire la surface exposée
Si le site injecte du contenu ou redirige, vous voulez limiter les dégâts. Cela ne doit pas forcément être un arrêt total, mais au minimum:
- désactiver l’accès public temporairement si vous pouvez le faire sans perdre trop de SEO (un mode maintenance est acceptable selon votre activité), arrêter l’exécution côté serveur si vous avez un mécanisme de sécurité disponible, changer les mots de passe administrateur et révoquer les sessions avant de toucher au code, pour empêcher l’attaquant de revenir pendant vos opérations.
Le changement de mots de passe est aussi une façon de vérifier votre hypothèse de compromission. Si le compte “revient” après quelques minutes, ce n’est pas un malware dormant, c’est un mécanisme actif.
2) Passer en “mode reconstruction”: cœur WordPress, thèmes, plugins
Pour réinstaller, vous devez distinguer ce qui est “remplaçable” et ce qui est “à vérifier”.
Le cœur WordPress, lui, doit être remplacé intégralement. Ne vous contentez pas d’un téléchargement partiel ou d’un correctif. Une reinstallation propre signifie que vous écrasez l’ensemble des fichiers de WordPress avec une version officielle correspondant à votre version https://gardewp.fr/ actuelle ou à une version contrôlée (souvent, monter de version est possible, mais uniquement si vous ne cassez pas votre compatibilité plugin).
Pour les thèmes et plugins, j’ai tendance à appliquer une règle simple: soit vous reconstruisez à partir de distributions propres, soit vous supprimez. Les thèmes “custom” nécessitent plus de prudence, mais même là, vous pouvez remplacer tout ce qui n’est pas indispensable et reconstruire le reste à partir de votre dépôt source. Si vous n’avez pas accès au code source du thème, la question devient plus risquée, parce que l’attaquant peut avoir modifié des fichiers “sans que vous le sachiez”.
Dans les scénarios où vous ne pouvez pas valider chaque plugin, la stratégie la plus sûre consiste à repartir avec une sélection minimale, les plugins strictement nécessaires, et les derniers versions stables obtenues via des sources officielles.
3) Ne pas faire semblant sur la base de données
La base est souvent le point de persistance. Vous pouvez remplacer des fichiers, mais si la base contient des scripts injectés, des options modifiées ou des hooks stockés, la charge utile peut réapparaître.
Concrètement, vous devez:
- exporter la base avant modification, comparer certains tables et options avec ce que vous attendiez, supprimer les utilisateurs créés ou modifiés hors de votre contrôle, vérifier les options de redirection et de configuration qui se basent sur des champs modifiés, examiner la présence de champs suspects ou de fragments PHP injectés dans des options.
Même avec de bons outils, il faut un minimum de discernement: certains fragments ressemblent à du code malveillant alors qu’ils proviennent de réglages légitimes (par exemple certains constructeurs de pages) ou de polices et scripts de tracking. Ne supprimez pas aveuglément, documentez, et validez en testant un chargement contrôlé.
4) Traiter les uploads et les fichiers “reflets” de l’attaque
Les uploads sont un terrain de jeu pour les attaques. Selon le vecteur, l’attaquant peut déposer un fichier dans wp-content/uploads, créer un script “caché” sous une extension innocente, ou s’appuyer sur un autre mécanisme (exécution conditionnelle, parsing, ou inclusion).
Le nettoyage ici n’est pas seulement “supprimer les fichiers suspects”. C’est aussi vérifier:
- si des fichiers PHP existent dans des dossiers où vous n’en mettriez jamais, si des fichiers ont des timestamps incohérents, si des répertoires temporaires ont été créés, si certains fichiers sont inclus par des thèmes ou plugins.
Le cas le plus frustrant est quand l’attaquant dépose une charge utile et qu’elle n’apparaît plus parce que votre nettoyage a été trop agressif sur la base ou le code. Dans ces cas, la réinfection arrive par un fichier qui n’a jamais été supprimé, ou par un script dans les uploads que WordPress ignore pour l’instant, mais que le site finit par appeler.
Une checklist courte avant de remettre en ligne
Je vous propose une liste courte, pour éviter les oublis qui coûtent cher. Elle ne remplace pas une investigation, elle sert de garde-fou.
- Remplacer le cœur WordPress par une version officielle contrôlée, sans copier des fichiers de l’ancien dossier. Désactiver ou supprimer tous les plugins non indispensables, puis les réinstaller depuis des sources fiables. Révoquer les sessions et changer tous les mots de passe des rôles admin, y compris sur la partie hébergement. Vérifier la base de données pour les utilisateurs inattendus et les options de redirection ou injection. Inspecter wp-content/uploads et tout fichier récent ou anormalement placé.
Si vous cochez tout ça, vous réduisez drastiquement le risque de réinfection via un point resté vivant.
Les outils peuvent aider, mais ils ne remplacent pas le raisonnement
Des scanners de sécurité peuvent repérer des fichiers connus, des signatures ou des comportements. Ils sont utiles pour accélérer la première passe, surtout quand vous n’avez pas de temps à consacrer à une analyse manuelle.
Mais j’insiste sur un point, parce que c’est là que les équipes se font piéger: un scanner peut ne rien trouver et vous rendre faux sentiment de sécurité. Dans ce genre de situation, votre meilleure arme reste la reconstruction contrôlée: remplacer ce qui doit l’être, puis tester dans un environnement isolé.
Un bon compromis que j’ai utilisé plusieurs fois consiste à combiner:
- une reinstallation de confiance, une comparaison de fichiers (ce qui a été modifié, et quand), une vérification ciblée des mécanismes de persistance (utilisateurs, options, tâches planifiées, injections dans la base).
Vous n’êtes pas obligé de “comprendre” tout le malware pour gagner. Vous devez surtout empêcher sa persistance.
Réinstaller sans réinfecter: le piège des sauvegardes
Le piège le plus courant, c’est de restaurer trop tôt, ou de restaurer la mauvaise chose.
Ne restaurez pas “l’intégralité” sans filtre
Si vous avez une sauvegarde de fichiers et une sauvegarde de base, il faut être sûr qu’elles proviennent d’avant l’infection, ou au moins d’avant la phase de persistance. Sinon, vous réintroduisez le problème à la seconde où vous remettez en service.
Parfois, la sauvegarde est partielle. Vous réinstallez les fichiers, puis vous restaurez la base pour récupérer le contenu. C’est acceptable si vous savez que la base est saine, ou si vous filtrez ce qui est manifestement malveillant. Mais si vous n’avez aucune assurance, votre restauration de base devient le moment le plus risqué.
Utilisez un environnement de test quand c’est possible
Un test local ou sur un sous-domaine interne vous permet de charger la page, d’essayer les actions d’administration, et de vérifier si une injection revient. Si vous voyez un retour rapide, vous ne perdez pas la journée à “chercher dans le vide” sur le serveur de production.
Contrôles de persistance qui reviennent souvent
Selon les attaques rencontrées, il existe quelques endroits où les traces réapparaissent même après un nettoyage initial. Je ne vous propose pas une longue liste, juste les contrôles qui font gagner le plus de temps.
Les utilisateurs WordPress, par exemple: un compte admin créé pendant l’attaque peut rester même si vous nettoyez les fichiers. Une fois que vous restaurez le site, l’attaquant peut utiliser ce compte pour réinjecter.
Les tâches planifiées sont aussi un classique. Une tâche peut appeler un script à intervalles réguliers et re-déposer un fichier. Si votre site semble “propre” et pourtant redonne un signe d’infection au prochain cycle, vérifiez ces mécanismes.
Enfin, l’injection dans la base: des options modifiées, des snippets stockés, ou des redirections construites à partir de champs dynamiques. C’est là que les “réinstallations partielles” échouent. Remplacer le code sans traiter les options, c’est parfois remettre le moteur de l’attaque en service.
Un exemple concret de scénario de réinstallation (sans fiction)
Prenons un cas typique, celui que j’ai le plus vu. Le site injecte du contenu en haut de page, surtout sur les URL de blogs. Le nettoyage initial a supprimé quelques fichiers suspects, mais le lendemain, les mêmes redirections reviennent.
En pratique, voici ce qui a fait la différence:
- Le cœur WordPress a été réinstallé intégralement à partir d’une version contrôlée. Les plugins ont été repartis sur une base minimale, les plus anciens ont été retirés au lieu d’être “nettoyés”. Une inspection des options de la base a révélé des redirections configurées via des valeurs stockées. L’analyse des comptes a mis en évidence un utilisateur admin ajouté pendant l’attaque. Les uploads ont révélé un fichier PHP déposé dans un répertoire non logique, avec un nom “discret”.
Ce n’est pas un seul geste qui a résolu le problème, c’est la combinaison de la reconstruction du code et du traitement des persistance côté base et côté fichiers. L’équipe aurait pu se contenter d’un scanner, mais elle aurait eu une réinfection quasi certaine.
Gérer les thèmes custom et le risque “je n’ai pas le code source”
Le cas des thèmes custom est le plus délicat, parce que vous n’avez pas forcément la copie exacte du code d’origine, ni un dépôt source clean. Si un thème a été modifié pendant l’attaque, vous êtes coincé entre:
- le remplacer et perdre une partie du design ou des fonctionnalités, ou essayer de nettoyer, avec un risque résiduel de laisser une charge utile camouflée.
Ma règle de décision ressemble à ceci: si le thème est custom et que vous n’avez pas un moyen fiable de revenir à une version propre, le remplacement est souvent le meilleur compromis, à condition de pouvoir reconstruire ensuite le style à partir de maquettes ou de captures, ou de récupérer une version précédente.
Quand vous avez un dépôt Git et des tags, c’est beaucoup plus simple: vous revenez au commit connu avant l’incident, puis vous appliquez les mises à jour nécessaires après avoir fermé le vecteur d’entrée.
Durcissement après réinstallation: ce qui évite que ça recommence
Réinstaller proprement, c’est une étape. Le vrai succès, c’est quand l’attaque n’a plus de chemin de retour.
Les actions “souvent oubliées” après une réinstallation:
- supprimer les comptes inutilisés, surtout ceux dont l’usage n’est plus clair, limiter le nombre de rôles admin, pour réduire les risques d’identifiants faibles, activer la protection contre les connexions abusives côté serveur ou via un mécanisme équivalent, surveiller les modifications de fichiers, même basiquement (un système de notification ou au minimum des rapports), verrouiller les permissions et limiter l’écriture là où elle n’est pas nécessaire.
On peut aussi parler de politique de maintenance. Un site qui n’est pas mis à jour devient un buffet pour les attaques. Le compromis, ce n’est pas “tout mettre à jour tous les jours”, c’est “planifier des mises à jour régulières, tester en pré-production, et retirer ce qui n’est plus utile”.
Deux angles d’équipe, selon votre situation
Vous n’êtes pas toujours dans la même posture. Le plan d’action change un peu selon que vous avez accès à la stack complète ou seulement à WordPress.
Si vous contrôlez l’hébergement
Vous pouvez faire mieux sur la partie accès et logs. Vous pouvez vérifier les comptes système, les clés, les scheduled tasks, et les journaux d’exécution. Vous pouvez aussi appliquer des garde-fous sur le stockage et limiter l’exécution des scripts dans certains répertoires.
Si vous dépendez d’un hébergeur géré
Alors vous devez pousser pour obtenir les informations utiles, logs d’accès, historique des déploiements, et éventuellement des mesures de confinement. Le nettoyage doit rester guidé par un principe: ne réinstallez pas en aveugle sur une infrastructure dont vous ne maîtrisez pas les points de persistance.
Dans les deux cas, votre objectif reste identique, casser la chaîne de persistance, pas juste effacer ce qui est visible.
Vérifier que c’est vraiment fini, pas seulement “ça a l’air ok”
Quand vous remettez le site en ligne, faites des tests de base mais sérieux, parce que l’attaque peut se déclencher sur certaines pages ou certains paramètres.
Chargez l’accueil, une page typique de blog, et une page d’administration si possible. Vérifiez les redirections, le rendu, et surtout l’absence de scripts injectés. Si vous voyez un retour rapide, vous n’êtes pas “à côté”, vous êtes en train de confirmer que la persistance existe encore.
C’est aussi le moment de surveiller le trafic et les signaux externes. Une hausse de pages qui n’ont pas de sens, ou des patterns de requêtes étranges dans les logs, vous alertera rapidement. En général, la réinfection se manifeste au moment où le site redémarre sa logique d’injection ou lorsqu’un mécanisme planifié se déclenche.
La règle d’or: traiter la compromission comme un incident, pas comme un fichier
Ce que j’ai appris sur les nettoyages malware WordPress, c’est que l’attaquant laisse rarement un seul “cadeau” propre à supprimer. Il construit une voie d’accès, puis il installe un moyen de revenir. Si vous remplacez seulement le code, mais que la base ou les comptes gardent la porte ouverte, vous nourrissez la réinfection.
Une réinstallation propre réussit quand vous reconstruisez à partir de sources fiables, que vous remplacez ce qui doit l’être, que vous vérifiez la base comme un élément de sécurité à part entière, et que vous fermez les accès.
Si vous devez retenir une seule idée, c’est celle-ci: un nettoyage efficace ne se mesure pas au fait que les symptômes disparaissent une journée. Il se mesure au fait que vous pouvez remettre le site en production, observer, et ne plus jamais revoir le même type de comportement.