Identifier l’origine d’une infection WordPress avant de nettoyer

Quand un site WordPress tombe malade, la première tentation est de se lancer dans le nettoyage à l’aveugle: changer des mots de passe, supprimer des fichiers “suspects”, réinstaller des thèmes. Ça peut fonctionner, mais ça peut aussi faire perdre du temps et, surtout, masquer la cause. Une infection dont on ne comprend pas l’origine revient souvent, parfois sous une forme plus discrète.

Sur le terrain, j’ai vu des cas où “on a tout nettoyé” en apparence, puis la semaine suivante les mêmes portes dérobées réapparaissent. Dans la plupart des scénarios réalistes, ce n’est pas la reinstallation de WordPress qui manque, c’est l’angle mort: l’accès initial (un compte compromis, un plugin implanté, un script injecté via un fournisseur, un serveur mal configuré) ou le chemin de persistance (comment l’attaquant se réactive).

Identifier l’origine avant de nettoyer, c’est réduire le risque de récidive, éviter de casser des fonctionnalités, et sécuriser le reste du système. Ce n’est pas toujours confortable, mais c’est beaucoup plus efficace.
Le vrai problème: distinguer “symptôme” et “cause”
Une infection WordPress a rarement une seule manifestation. On peut voir du spam dans des pages, des redirections vers des domaines douteux, des fichiers modifiés, des utilisateurs inconnus, des requêtes inhabituelles dans les logs, ou des erreurs 404 qui ne collent pas à l’activité du site.

Le piège, c’est de traiter le symptôme le plus visible. Par exemple, si vous trouvez un fichier PHP ajouté dans un thème, vous le supprimez, vous replacez le thème en état sain, et vous pensez que tout est réglé. Sauf que l’attaquant a peut-être laissé derrière lui un autre mécanisme, comme une tâche cron malveillante, un nouveau compte administrateur, ou un plugin backdoor installé par l’API WordPress. Dans ce cas, le site “re-s’infecte” dès que l’attaquant a de nouveau le contrôle.

Une approche plus saine consiste à relier les éléments entre eux avant toute purge: quelles dates, quels fichiers, quels comportements, quels comptes, quelles sources réseau. Même sans être un laboratoire de forensic, vous pouvez reconstruire une chronologie suffisamment solide.
Commencer par observer: ce que vous pouvez apprendre sans toucher à tout
Avant de modifier quoi que ce soit, prenez des notes et, idéalement, sauvegardez. Ça paraît basique, mais sur un site déjà instable, la perte de données est un classique. L’objectif ici est d’avoir une photographie de l’état initial.

Commencez par vérifier ce que font exactement les pages et quand ça a commencé. Une infection qui ne redirect pas en permanence peut n’être détectée que lors de certaines conditions, par exemple selon le navigateur, la géolocalisation, l’heure du serveur, ou des paramètres d’URL.

Puis regardez la surface technique:
les fichiers qui ont été modifiés récemment (WordPress, thèmes, plugins, uploads, fichiers racine), les utilisateurs WordPress et leurs droits, les traces dans l’interface (plugins nouvellement installés, nouveaux thèmes, modifications de paramètres), et, si vous avez accès, les logs serveur.
Sur beaucoup d’hébergeurs, vous pouvez déjà obtenir des indices dans les logs d’accès Apache ou Nginx, et dans les logs d’erreurs PHP. Même des extraits suffisent pour repérer des schémas: une rafale de requêtes vers un fichier précis, des tentatives de connexion inhabituelles, ou des appels à des endpoints qui ne font pas partie de votre trafic normal.

J’ai déjà retrouvé des infections qui “avaient l’air” localisées à un seul fichier, mais les logs montraient un motif récurrent: des requêtes vers une URL interne inconnue, avec une séquence d’identifiants qui semblait correspondre à une tentative d’exécution à distance. Cette concordance a orienté la recherche vers un compte compromis plutôt que vers une vulnérabilité de plugin.
Reconstituer la chronologie: la partie la plus rentable
Une infection laisse des traces dans le temps. WordPress lui-même fournit des éléments: la liste des mises à jour, l’historique des plugins et thèmes, la date de création des utilisateurs. Côté fichiers, un dépôt d’horodatages de modifications aide énormément, même s’il faut rester prudent, car certains outils de déploiement ou de backup modifient aussi les dates.

L’idée est de répondre à des questions simples, par ordre:
Qu’est-ce qui a changé en premier, selon les dates les plus anciennes observées? Est-ce que les changements se concentrent sur un seul composant (un plugin, un thème, le dossier uploads)? Y a-t-il plusieurs points d’entrée plausibles, ou une seule piste dominante?
Si vous constatez que des fichiers “malicieux” dans wp-content/uploads ont été déposés avant toute autre modification, c’est un indice. Si au contraire, vous trouvez un plugin inconnu actif dans wp-content/plugins avec une date de création plus ancienne que les autres altérations, il est probable que le plugin soit le vecteur. Et si vous voyez un utilisateur “admin” créé peu avant le début des redirections, l’origine peut être un identifiant compromis (ou un compte créé via un mécanisme d’import mal protégé).
Comprendre les mécanismes courants d’infection
Sans faire une liste exhaustive, il existe des familles de vecteurs qu’on rencontre souvent. Savoir ce qu’on cherche permet de gagner du temps.
1) Compromission de compte (force brute, fuite d’identifiants, accès laissé ouvert)
Un scénario classique: un attaquant obtient des identifiants, se connecte, installe ou active quelque chose, puis crée un compte persistant. La partie délicate, c’est que les admins légitimes ne voient pas forcément tout. Si la page d’administration n’est pas surveillée, l’ajout d’un compte peut passer inaperçu.

Un indicateur utile: des tentatives de connexion échouées avant l’apparition de la charge malveillante, ou des connexions réussies depuis des IP qui n’ont pas de raison d’être présentes sur votre GardeWP malware WordPress https://gardewp.fr/nettoyage-malware-wordpress/ site.
2) Plugin ou thème compromis
Les attaques via plugin restent fréquentes, surtout si le site utilise des plugins abandonnés, mal mis à jour, ou “nullement vérifiés”. Parfois l’infection est un plugin légitime mais dont une branche a été modifiée par l’attaquant. Parfois c’est carrément un plugin installé en interne après un accès.

L’indice le plus concret: un dossier de plugin ou de thème contenant un code anormal, souvent masqué, avec des fonctions de chargement de fichiers distants ou de base64 décodé à l’exécution. Ce genre de code n’est pas une garantie à lui seul, mais c’est un signal.
3) Injections dans les fichiers WordPress via le thème, ou modifications dans les templates
D’autres infections passent par un “petit bout” de code inséré dans des fichiers de thème, par exemple functions.php ou un template. Les redirections peuvent être conditionnelles, ce qui explique pourquoi certains visiteurs ne voient rien.

Si vous voyez le même fragment de code injecté dans plusieurs fichiers, il est plus probable que l’attaquant ait un outil réutilisable, donc un moyen d’exécution déjà en place.
4) Persistance via cron, webhooks, ou tâches planifiées
Même si vous supprimez les fichiers visibles, une tâche planifiée peut réinjecter le code malveillant. WordPress a des mécanismes de cron internes, mais selon l’hébergement, il peut aussi y avoir des cron système.

J’ai déjà vu des cas où le site semblait “nettoyé”, puis le plugin malveillant réapparaissait après un délai très régulier, pile le temps d’un événement programmé.
5) Compromission côté serveur ou via un outil d’automatisation
Le vecteur n’est pas toujours WordPress. Un dépôt Git compromis, un script de déploiement trop permissif, une clé API exposée, ou des permissions de fichiers trop larges peuvent servir de chemin d’entrée.

Si votre équipe déploie fréquemment, et que vous avez un mécanisme automatisé, la question à se poser est: est-ce que la chaîne de déploiement pourrait avoir été modifiée, ou est-ce que l’attaquant a abusé d’un compte de service?
Ce que vous vérifiez en priorité, avant de supprimer
Il faut un ordre de priorité. Si vous commencez par tout supprimer, vous perdez des indices. Voici l’approche que je recommande le plus souvent, parce qu’elle respecte la logique “garder la preuve avant l’action”.
Mettre de l’ordre dans l’accès WordPress
Trouvez tous les comptes existants, repérez les nouveaux, et cherchez ceux qui ne devraient pas être là. Regardez aussi les rôles, pas seulement la liste.

Voici une mini check-list, sans blabla, utile avant toute purge:
Vérifier la liste des utilisateurs et repérer ceux créés récemment Rechercher des plugins, thèmes ou utilisateurs ajoutés après une date précise Contrôler les rôles et vérifier que seul le personnel autorisé a des droits d’édition avancés Désactiver temporairement tout plugin “inconnu” si vous identifiez clairement un vecteur Faire un snapshot de fichiers et une sauvegarde avant modification
Cette étape a un bénéfice immédiat: si votre origine est un compte compromis, vous pouvez casser la persistance en limitant le contrôle de l’attaquant avant même de “nettoyer site WordPress infecté”.
Inspecter la surface fichiers, avec méthode
L’inspection “à l’œil” est lente et peut mener à des erreurs. La meilleure méthode consiste à combiner:
dates de modification, taille et structure, contenu suspect (mécanismes de décodage, chargement dynamique, appels système, écriture de fichiers), et emplacement (ce qui est normal pour WordPress versus ce qui ne l’est pas).
Un détail qui aide: dans WordPress, certains dossiers ont des usages très précis. Les modifications “dans les mauvais endroits” sont rarement accidentelles. Par exemple, des fichiers PHP dans uploads ne devraient pas être là dans un environnement bien configuré, sauf si vous avez volontairement activé des exécutions. Même là, le contenu ne ressemble pas à un plugin standard.

Je me suis retrouvé plusieurs fois à confirmer une infection en repérant un fichier minuscule, très “technique”, qui n’est pas un composant WordPress normal, et qui n’est pas référencé par vos templates. Le fichier peut être petit, mais la présence seule raconte une histoire.
Analyser les traces réseau et la chronologie serveur
Si vous avez accès aux logs, c’est souvent l’élément qui fait basculer une enquête.

Cherchez:
des requêtes vers des fichiers ou endpoints inconnus, des pics d’erreurs 404 sur des chemins non liés à votre navigation, des tentatives d’accès à des ressources sensibles, des tentatives répétées sur wp-login.php (ou d’autres endpoints de connexion), et des patterns d’exécution, par exemple une URL vers un fichier PHP ajouté récemment.
Si vous ne pouvez pas consulter les logs directement, vous pouvez parfois obtenir des indices via des modules de sécurité, des journaux d’hébergement, ou un système de surveillance. L’objectif reste le même: relier des événements à des moments.

Edge case important: certains sites sont infectés mais restent “stables” longtemps, surtout si le contenu malveillant est activé conditionnellement. Dans ce cas, les logs peuvent montrer moins de choses côté visiteurs, mais révéler des appels internes. Parfois l’attaquant utilise des requêtes qui ne causent pas d’erreurs, donc moins visibles. Il faut alors regarder des patterns de requête répétitifs.
Réduire l’incertitude: tester les hypothèses sans aggraver
Une fois que vous avez une piste, vous voulez la tester sans détruire les preuves.

Par exemple, si vous suspectez un plugin, vous pouvez le désactiver si vous êtes certain qu’il est à l’origine du comportement. Mais il faut garder en tête un risque: si vous désactivez trop tôt, vous pourriez empêcher l’attaque de se manifester, donc vous perdez la possibilité d’observer comment elle persiste.

Dans la pratique, on peut trouver un compromis:
Isoler le site (mettre en maintenance si nécessaire). Conserver une copie des fichiers avant modification. Observer pendant un temps court, et revalider ensuite.
Sur un site très exposé, je privilégie souvent la coupure contrôlée, parce que chaque minute non maîtrisée peut favoriser l’exploitation, le déploiement d’une charge supplémentaire, ou l’indexation de pages malveillantes par des moteurs.
Cas fréquents: quand la cause n’est pas ce que vous pensez “J’ai trouvé un malware, donc c’est l’origine”
Pas forcément. Le malware trouvé peut être une conséquence, pas un point de départ. Par exemple, si vous trouvez un script injecté dans un thème, mais que le compte ayant installé le thème était compromis, l’origine est l’accès initial. Le code du thème est la “méthode de nuisance”, mais l’attaque a commencé ailleurs.
“Le plugin était à jour, donc ce n’est pas un plugin”
Un plugin à jour réduit le risque de vulnérabilité connue, mais n’élimine pas un autre scénario: une compromission du compte qui a installé un plugin malveillant déguisé, ou une altération de fichiers via un accès. Il peut aussi arriver que le plugin soit légitime, mais que l’attaquant ait ajouté un code dans ses fichiers en exploitant un autre point d’entrée.
“On a changé les mots de passe, ça devrait aller”
Changement de mots de passe seulement côté utilisateurs, sans vérifier les clés de session, sans invalider les sessions actives, sans regarder les comptes fraîchement ajoutés, c’est parfois insuffisant. Si l’attaquant a déjà persisté via une backdoor dans un fichier, le compte réinitialisé ne suffit pas.

Dans les environnements où WordPress fonctionne avec des intégrations (SSO, logs, API), il faut aussi s’assurer que les jetons ne sont pas compromis.
Stratégie de nettoyage orientée “origine”, pas “symptôme”
Une fois l’origine la plus probable identifiée, le nettoyage doit casser la persistance et restaurer l’état sain. Cela implique souvent une combinaison de mesures, pas seulement supprimer le contenu visible.

Je préfère raisonner en deux couches: restaurer, puis verrouiller.

1) Restaurer les composants modifiés ou suspects, idéalement en remplaçant par des versions propres. 2) Verrouiller l’accès, réduire les possibilités d’entrée, et vérifier les mécanismes de persistance.

Cela inclut de contrôler les permissions de fichiers. Sur WordPress, des permissions trop larges peuvent faciliter l’écriture de fichiers par des processus qui ne devraient pas écrire. Ce n’est pas un remède miracle, mais ça fait partie des garde-fous.
Le test final: comment confirmer que l’infection ne revient pas
Après correction, vous ne confirmez pas seulement que “le site charge”. Vous confirmez que le vecteur identifié ne peut plus se réactiver.

Voici une seconde mini liste, orientée vérification après nettoyage:
Rechercher de nouveaux fichiers ou modifications depuis vos actions de restauration (sur une fenêtre courte, par exemple 24 à 48 heures) Vérifier que la liste des utilisateurs n’a pas changé et que les rôles restent cohérents Contrôler les logs pour des requêtes inhabituelles qui reviennent au même rythme Tester des redirections ou comportements conditionnels depuis plusieurs navigateurs Surveiller les erreurs serveur et les tentatives de connexion pendant la période de post-intervention
Le “bon” test dépend de votre type d’infection. Si l’attaquant redirige uniquement certains visiteurs, vous devrez reproduire les conditions les plus proches possibles. Si l’infection injecte du spam via l’admin, il faut vérifier côté contenu aussi.
Prévenir sans transformer le site en bunker
Après une enquête, la prévention devient plus rationnelle, parce que vous savez quel chemin l’attaquant a suivi. Une bonne prévention attaque le point d’entrée et limite la propagation.

Quelques axes reviennent presque toujours:
Mettre à jour WordPress, thèmes et plugins de manière régulière. Supprimer ce qui n’est pas utilisé, surtout les plugins orphelins. Renforcer la gestion des identifiants (mots de passe, rotation quand nécessaire, limitation des rôles). Surveiller les logs et les alertes d’administration. Vérifier les permissions et la politique de fichiers sur l’hébergement.
Je fais aussi attention à l’équilibre. Trop de verrouillage peut casser des automatisations ou compliquer des mises à jour. Le but n’est pas d’avoir zéro risque, c’est de rendre chaque étape de l’attaque plus coûteuse et plus visible.
Quand vous devez aller plus loin que WordPress
Parfois, l’origine n’est pas dans WordPress lui-même. Si vous constatez une persistance difficile à expliquer, ou si vous trouvez des modifications qui ne correspondent pas à votre activité, vous devez élargir la recherche:
compte d’hébergement ou accès au serveur, scripts de déploiement, clés API utilisées par des plugins ou des intégrations, configuration du web server (exécution PHP dans des dossiers non prévus), compromission d’un poste d’administration, notamment si un outil local a été contaminé.
Ce genre de diagnostic demande souvent du support d’hébergement ou une implication plus “système”. Le nettoyage WordPress seul ne suffit plus, parce que le vecteur est hors de portée de votre CMS.
Distinguer une infection réelle d’un “faux signal”
Il arrive aussi que des alarmes soient trompeuses. Un fichier peut être marqué “suspect” par un outil parce qu’il contient des chaînes codées ou des fonctions qui ressemblent à d’autres charges. Ce n’est pas toujours malveillant.

C’est pour ça que l’identification de l’origine doit s’appuyer sur plusieurs signaux qui convergent. Si vous trouvez un nouveau plugin et un fragment code inconnu, c’est fort. Si vous trouvez un fichier “inconnu” mais aucune trace d’accès, aucune modification récente, et qu’il est cohérent avec votre historique de déploiement, vous devez creuser avant de conclure.

En pratique, c’est là que l’expérience compte: regarder le contexte, les dates, la cohérence structurelle, et la logique du site. Un diagnostic brutal sans recoupement peut mener à supprimer quelque chose de légitime, puis à casser le site. Ce n’est pas seulement un problème technique, c’est aussi un problème de confiance lors de la reprise d’exploitation.
Ce que j’attends d’une “bonne” identification d’origine
À la fin de votre enquête, vous ne cherchez pas à prouver au tribunal. Vous cherchez à pouvoir décider avec un bon niveau de confiance. Une identification utile répond à ceci:
où l’attaque a commencé, comment elle s’est maintenue, ce qui a été modifié en premier, et ce qui doit être restauré pour que ça ne revienne pas.
Quand vous pouvez répondre à ces quatre points, le nettoyage devient une intervention ciblée, pas une loterie.
Se donner les moyens dès maintenant
Si votre site est déjà en difficulté, l’enjeu n’est pas de “parfaitement enquêter” avant toute action. L’enjeu, c’est de faire une enquête rapide mais propre: sauvegarder, isoler, observer, identifier le vecteur le plus probable, puis restaurer et verrouiller.

Un bon réflexe consiste à travailler par étapes: une première passe pour couper la persistance probable, une deuxième passe pour restaurer proprement les fichiers et vérifier les comptes, et une troisième passe pour observer les logs dans la fenêtre de retour.

C’est souvent cette discipline, plus que la suppression d’un fichier, qui empêche l’infection de revenir.

Si vous voulez, décrivez-moi les symptômes que vous voyez (redirections, pages ajoutées, utilisateurs inconnus, plugins installés, traces dans les logs) et votre environnement (hébergeur, accès FTP ou SSH, présence d’un pare-feu). Je peux vous aider à formuler des hypothèses d’origine, dans l’ordre le plus probable, avant même de toucher au nettoyage.