Nettoyage fichiers infectés WordPress : comment trier les modifications récentes

Quand un site WordPress commence à se comporter de façon étrange, le réflexe n’est pas d’effacer “au hasard”. Le bon réflexe, c’est de trier, de dater, et de comprendre ce qui a bougé. Sur beaucoup de sites compromis, l’infection ne se limite pas à un fichier “magique”. Elle se cache dans des modifications récentes, des ajouts silencieux, parfois dans des scripts qui ne font rien tant qu’une condition n’est pas remplie.

Le nettoyage devient alors une enquête. Et, comme dans toute enquête, la première compétence est de savoir ce qui mérite d’être regardé en premier.

J’ai déjà vu des interventions où l’on remplace “tout le thème”, “tous les plugins”, puis on recharge WordPress depuis zéro. Le site revient parfois, mais pas toujours. Pourquoi ? Parce que l’attaque peut avoir modifié un endroit peu visible, ou parce qu’un fichier revient à chaque mise à jour ou à chaque déploiement, exactement parce que la source n’a pas été neutralisée.

Le tri par modifications récentes évite ça. Au lieu de traiter tous les fichiers comme coupables, on commence par ceux qui ont une date et une signature de changement qui collent à la période où le problème a commencé. C’est là que l’on gagne le plus de temps, surtout sur les sites qui contiennent des centaines ou des milliers de fichiers.

Sur un serveur, “modifié” renvoie souvent aux dates de fichiers du système de fichiers (timestamps). WordPress peut aussi refléter des événements via des tables (par exemple une date d’option, une date d’activation de plugin, etc.), mais ce n’est pas toujours fiable pour l’investigation.

Dans la pratique, les dates de fichiers peuvent varier pour plusieurs raisons légitimes :

C’est pour ça que trier les modifications récentes ne veut pas dire “tout ce qui est récent est infecté”. Ça veut dire “tout ce qui est récent est prioritaire”. Ensuite, on valide par des indices concrets : contenu suspect, emplacement anormal, mécanismes de persistance, appels à des URLs externes, obfuscation, présence de fonctions attendues ou non, etc.

Avant d’ouvrir le moindre fichier, je recommande toujours de figer le contexte. Sinon, vous risquez de vous perdre dans des allers-retours.

Sur un incident récent, je fais généralement trois choses avant l’analyse :

Même si le but est le tri des fichiers modifiés, cette étape évite de confondre une modification de routine avec une vraie action malveillante.

Le tri est beaucoup plus efficace si vous réduisez la fenêtre. Au lieu de “depuis toujours” ou “sur les 3 derniers mois”, visez une plage cohérente avec le début des symptômes.

Sur un site compromis, les signes se manifestent souvent en quelques minutes à quelques heures après l’installation initiale, mais il y a aussi des cas où l’attaque reste silencieuse plus longtemps. Une fenêtre trop courte peut vous faire rater la bonne cause, une fenêtre trop large vous noie sous le bruit.

Une approche pragmatique consiste à prendre :

Dans mon expérience, c’est souvent dans le chevauchement entre “fichiers modifiés après le début des symptômes” et “fichiers modifiés sans cause évidente” que l’on trouve l’entrée.

Le tri par modifications récentes ne sert à rien si vous commencez partout. WordPress a des zones avec des comportements plus révélateurs.

Les endroits qui donnent le plus d’indices, ce sont généralement ceux où l’attaquant peut ajouter du code sans casser immédiatement le site :

Les thèmes et plugins sont souvent ciblés, mais pas uniquement. Un “petit” fichier dans un répertoire d’upload peut suffire pour déclencher une charge utile selon une requête spécifique.

Ce que je fais lors du tri, c’est d’abord classer par répertoires. Ensuite, je regarde les fichiers modifiés dans ceux qui ont le plus de sens, plutôt que d’analyser une liste globale.

Si vous avez accès SSH, l’idéal est de générer une liste des fichiers modifiés sur une période. Vous voulez la date, le chemin, et idéalement la taille. Selon l’accès que vous avez, vous pouvez le faire via un outil de listing, ou via une commande de recherche dans l’arborescence.

Deux pièges reviennent souvent :

Donc, même si vous utilisez une commande, vous devez compléter par du jugement. Un fichier modifié la nuit d’un update planifié peut être normal, un fichier modifié à 3 h 17 un dimanche, sans événement connu, mérite un examen.

Si vous n’avez pas SSH, un accès via le gestionnaire de https://gardewp.fr/nettoyage-malware-wordpress/ fichiers du panneau d’hébergement peut aussi aider, mais il est parfois moins précis sur les dates. Dans ce cas, j’utilise davantage la logique d’emplacement et le contenu plutôt que la seule chronologie.

Une fois que vous avez une liste des fichiers “récents et plausiblement suspects”, le tri devient lecture de code, mais pas au hasard.

Sur beaucoup d’infections, vous verrez des signatures récurrentes :

Je ne vous conseille pas de chercher uniquement un mot spécifique dans le code. Les attaquants changent souvent. En revanche, vous pouvez rechercher des comportements : exécution dynamique, chargement à partir d’une source externe, exécution via base64, ou “gadget” PHP.

Un exemple typique que j’ai rencontré : un fichier PHP dans un dossier qui n’est pas censé contenir de logique. Le fichier n’avait presque rien “visuellement”, puis une condition vérifiait un paramètre et lançait un include. Tant qu’on ne déclenchait pas la condition, tout semblait normal.

Le tri par modifications récentes vous met sur cette piste, mais la validation vient du comportement.

Les thèmes peuvent être modifiés pour des mises à jour, et certaines équipes ont des routines qui touchent les fichiers à chaque build. Dans ce cas, “modifié récemment” n’est pas suffisant.

Ce qui aide, c’est de comparer :

Une règle pratique que j’utilise : si la modification concerne “trop peu” de fichiers mais de façon “très ciblée” dans des points non attendus, la probabilité d’une infection augmente. À l’inverse, si toute une cascade de fichiers change, souvent c’est un déploiement légitime ou une recompilation.

Trier les fichiers est essentiel, mais vous pouvez renforcer la chronologie avec les traces d’administration.

Quand un site est compromis, il peut aussi y avoir :

Le tri des modifications récentes des fichiers vous donne une piste, mais vérifier l’administration vous dira si la compromission a aussi touché la couche “WordPress” au même moment.

Par exemple, si vous voyez des fichiers modifiés deux heures après une connexion admin réussie qui ne vous appartient pas, le lien devient très plausible.

Si vous voulez une méthode simple pour ne pas vous éparpiller, je fais souvent un premier filtre sur “ce qui a bougé après la dernière action que je connais”. Ça inclut fichiers et base de données, et ça réduit drastiquement le temps de recherche.

Oui, les attaques ciblent souvent des fichiers PHP, mais parfois l’infection est un script stocké ailleurs, ou une charge utile qui s’exécute via un autre mécanisme.

Dans certains cas, vous verrez :

Le tri par modifications récentes s’applique aussi, mais vous devez accepter que la lecture du code puisse être moins intuitive si vous ne connaissez pas la logique du “dropper” ou du mécanisme d’amorçage.

Si le site a commencé à rediriger, à insérer des scripts dans le front, ou à afficher du contenu différent selon les requêtes, regardez aussi les modifications récentes dans les fichiers qui génèrent la sortie (templates, loaders, scripts de rendu).

Voici une façon de procéder qui m’a évité des “faux nettoyages” (les nettoyages qui cassent ensuite la preuve). Elle n’est pas magique, mais elle suit une logique d’enquête : restreindre, comparer, valider.

Plutôt que de lancer une recherche globale, fixez une plage. Par exemple autour de la période de début des symptômes, puis élargissez.

Ensuite, filtrez par dossiers sensibles : wp-content, notamment themes et plugins, et certains sous-dossiers d’uploads. Vous pouvez aussi regarder la racine WordPress, mais avec prudence, car beaucoup de fichiers changent lors de mises à jour légitimes.

Deux fichiers peuvent être modifiés la même journée, mais pas pour les mêmes raisons. Un ajout d’un fichier là où il n’y avait rien auparavant ressemble plus à une installation malveillante. Une réécriture massive ressemble à un déploiement.

Si votre environnement permet de comparer avec une sauvegarde saine, c’est encore mieux. Sinon, au minimum, regardez la taille, les permissions, et le contenu.

Le contenu suspect, ce n’est pas seulement “du code bizarre”. C’est aussi :

Ne cherchez pas une seule signature, cherchez un ensemble de comportements.

Dès que vous trouvez un fichier qui ressemble à un point d’entrée, je préfère isoler plutôt que supprimer immédiatement. Par exemple, vous pouvez mettre temporairement un nom différent ou restreindre l’accès, le temps de confirmer l’impact.

Suppression directe peut effacer un indice utile, surtout si vous devez ensuite prouver ce qui a été fait, ou si vous devez reconstruire un état sain avec confiance.

Une fois que vous êtes certain de la source, reconstruisez avec des versions propres des thèmes et plugins, idéalement depuis des sources officielles, et remettez les fichiers corrigés.

Le point important : ne reconstruisez pas seulement “les fichiers visibles”. Si une persistance existe, elle peut revenir si vous n’avez pas neutralisé la cause.

Pour rester concret, une des erreurs fréquentes est de remplacer un thème, puis de ne pas traiter un plugin malveillant qui continue à injecter. Le tri des modifications récentes sert justement à éviter cette situation, car vous savez quels éléments se sont mis à bouger.

Même en étant rigoureux, il y a https://gardewp.fr/ des cas qui déstabilisent.

Certains plugins ou scripts peuvent modifier des fichiers, par exemple pour générer des caches, des optimisations, ou des fichiers de minification. Dans ce cas, la notion de “modifié récemment” trompe. La solution, c’est de connaître vos plugins actifs et leurs routines.

Si vous avez un plugin de caching agressif, ou un outil de build qui régénère des assets, vous devez le prendre en compte. Je n’élimine pas la piste, je l’aligne sur ce que l’outil fait réellement.

Sur certains hébergements, la date affichée dans l’interface peut être décalée. J’ai déjà vu des panneaux qui ne reflétaient pas correctement les timestamps système.

Si vos dates ne collent pas, faites confiance au contenu et à l’emplacement, puis utilisez la date comme indice secondaire.

Parfois, l’attaquant modifie des fichiers en reproduisant la forme d’une mise à jour, en gardant une structure proche. Dans ce cas, une comparaison ligne par ligne avec une version saine aide, mais c’est plus chronophage.

Ce qui marche bien, c’est de chercher des “cibles” non typiques : un fichier que le thème n’utilise pas, une fonction absente dans le code d’origine, une URL qui ne fait aucun sens pour votre activité.

Si vous avez une avalanche de fichiers modifiés sur une période, vous devez vous demander si :

Dans ce contexte, les infections peuvent aussi être plus difficiles à identifier, parce que le tri par date devient bruité. Dans ces cas, je réduis encore plus le périmètre : je filtre par fichiers PHP dans des zones sensibles, puis je fais une lecture ciblée.

Si une infection est présente, elle laisse presque toujours une trace comportementale. Même si vous ne trouvez pas instantanément “le” fichier coupable, vous trouverez des incohérences dans le code.

Après le nettoyage, ne considérez pas le dossier terminé. Les infections se répètent parfois si l’accès initial n’a pas été réparé.

Côté WordPress, je vérifie systématiquement :

Côté serveur, je regarde aussi les points d’accès, par exemple s’il y a des tentatives répétées, et si les autorisations sont cohérentes.

Le nettoyage fichiers infectés WordPress n’est pas seulement une question de supprimer un fichier. C’est une question de fermer la porte.

Imaginons un site e-commerce qui reçoit des redirections vers une page externe et une augmentation du trafic à partir d’une heure précise.

En triant les modifications récentes sur la période autour de cette heure, on constate que :

Au premier regard, on pourrait remplacer le thème et les plugins. Mais si on lit le contenu, on découvre que le plugin modifié contient une logique de chargement conditionnel, déclenchée seulement sur certaines requêtes. Le thème modifié ajoute juste un petit appel ou un point d’injection.

Dans ce scénario, si vous nettoyez uniquement le thème, le plugin peut continuer à réinjecter au prochain événement. Le tri par modifications récentes vous donne l’ordre d’enquête : d’abord le plugin à comportement anormal, ensuite le thème qui fait le relais.

C’est exactement la raison pour laquelle je ne fais pas un “gros reset” en premier réflexe.

Sur un site “simple”, l’investigation peut être rapide. Sur un site “d’entreprise” avec déploiements réguliers, c’est souvent plus subtil.

Dans les deux cas, le tri par modifications récentes reste la boussole. Ce n’est pas une preuve, mais c’est un filtre intelligent.

Si vous arrivez après coup, avec un site qui a déjà été “touché” par des interventions précédentes (remplacement partiel de dossiers, suppression de plugins, tentatives de correction), je recommande de revenir à un tri méthodique plutôt que de poursuivre sur les décisions du passé.

Rassemblez l’état actuel, reconstituez la chronologie, puis reprenez le tri sur une fenêtre cohérente. Concentrez-vous sur les fichiers qui n’ont pas de raison d’avoir changé, et sur ceux dont le contenu a un comportement qui ne colle pas à votre projet.

Vous verrez souvent que l’infection a laissé des traces persistantes, et elles sont généralement dans quelques emplacements précis. Le travail consiste à les retrouver et à les traiter correctement.

Après avoir identifié et corrigé les fichiers suspects, je fais un passage de validation, sans inventer d’étapes complexes.

Cette validation est ce qui sépare un “nettoyage” d’une résolution.

Il y a des moments où le tri des modifications récentes est clair, et d’autres où il devient ambigu. Par exemple, si votre site a subi un déploiement fréquent, si vous avez un grand volume de changements, ou si vous ne pouvez pas relier les timestamps aux événements réels.

Dans ces cas, plutôt que de tenter une suppression irréversible, un second avis peut accélérer la recherche. Le mieux est de fournir un historique : date du problème, changements préalables, liste des fichiers récemment modifiés, et ce que vous avez déjà remplacé.

On gagne du temps quand l’investigation est documentée, même avec une simple chronologie.

Le nettoyage files infectés WordPress ne se résume pas à “effacer ce qui semble étrange”. Le cœur du travail, c’est de trier les modifications récentes, de réduire la fenêtre, de prioriser les dossiers à risque, puis de valider par le comportement du code et la cohérence des événements.

Quand vous faites ça proprement, vous ne coupez pas seulement du contenu, vous coupez la voie de l’attaque. Et vous évitez la situation frustrante où le site semble guéri, puis retombe dès que la prochaine requête déclenche la même mécanique.