Nettoyage virus WordPress : analyser le contenu du dossier wp-content

Quand on parle de “virus WordPress”, on imagine souvent un fichier magique qui s’exécute dès qu’on ouvre une page. La réalité est plus grise, plus pénible, et surtout plus utile à diagnostiquer: dans beaucoup d’infections, le vrai dommage se cache dans wp-content. Plugins, thèmes, médias, parfois des fichiers “oubliés” dans les sous-dossiers, et parfois des scripts PHP ajoutés là où ils n’ont rien à faire.

J’ai déjà vu des sites qui n’avaient “que” un peu de redirection bizarre, puis, en creusant, on a découvert une chaîne complète: une charge utile déposée dans un thème enfant, activée par un fichier dans uploads, et déclenchée uniquement pour certains navigateurs ou pages précises. L’analyse de wp-content est donc la première étape rationnelle, celle qui donne du concret. Pas des suppositions, pas juste un “scan antivirus” vague, mais une lecture assistée des fichiers et de leur logique.

Comprendre ce que wp-content dit vraiment

Wp-content est l’endroit où WordPress laisse de la place à la personnalisation. C’est aussi le point d’entrée le plus fréquent quand un site est compromis sans que l’attaque passe par une modification du noyau. Typiquement, un attaquant cherche à:

injecter du PHP dans un fichier chargé par WordPress, créer une liaison avec quelque chose d’actif (hook, include, requête externe, tâche planifiée), et masquer l’origine en profitant de la structure existante.

Sur un site “normal”, wp-content peut contenir plusieurs milliers de fichiers, surtout si vous avez des images, des déclinaisons d’images (souvent générées), et des caches. Si vous avez, par exemple, 10 000 fichiers dans wp-content, vouloir tout “regarder à la main” est irréaliste. La bonne approche consiste à réduire le périmètre, repérer les anomalies, et n’ouvrir que ce qui doit l’être.

L’autre point important: on ne nettoie pas seulement “les fichiers suspects”, on cherche la cause. Sinon, la seconde étape est toujours la même: vous supprimez, ça revient. Même si l’on se concentre sur wp-content, il faut garder en tête que la persistance peut venir d’un plugin, d’un compte administrateur compromis, d’un cron, ou d’une option en base de données.

Préparer l’enquête avant de toucher aux fichiers

Avant d’éditer, supprimez le moins possible. Vous voulez d’abord comprendre ce que vous avez. Sur des sites déjà instables (pages lentes, erreurs 500, comportements aléatoires), j’ai appris à faire une “mise à plat” avant le nettoyage.

Commencez par une sauvegarde complète, au minimum:

une copie de votre dossier wp-content (ou un clone par archive)
et idéalement une sauvegarde de la base de données

Ensuite, documentez l’état du site au moment T: pages qui redirigent, URLs touchées, moments (heure, fréquence), et présence ou non de visiteurs “spécifiques” concernés. Cette trace vous aidera si vous devez vérifier si l’infection est toujours active après suppression.

Techniquement, je recommande aussi de travailler avec un accès qui permet des comparaisons. Un simple copier-coller dans un dossier local peut suffire, mais dès que vous avez des tailles de fichiers et des horodatages, un outil de comparaison (diff) devient précieux.

Où regarder en priorité dans wp-content

Wp-content se compose souvent de sous-dossiers assez standard, mais l’infection se glisse dans les interstices.

Si vous avez un dossier uploads volumineux, les fichiers y sont parfois utilisés comme “stockage” (scripts encodés, fichiers GIF/PNG contenant du code, ou fichiers qui ne devraient pas être là). Dans themes, une infection peut s’insérer dans le thème parent ou enfant, surtout dans des fichiers qui sont chargés à chaque requête (header, functions, template hooks). Dans plugins, c’est encore plus courant, car WordPress charge certains fichiers selon les hooks et l’activation des extensions.

Même si vous ne voulez pas vous disperser, l’ordre de priorité est généralement: plugins, thèmes, uploads, puis le reste.

Signaux d’alerte très concrets dans les fichiers

Le piège, c’est de confondre “fichier PHP normal” et “fichier PHP dangereux”. Sur un site sérieux, vous avez souvent des fichiers PHP propres dans plugins et thèmes. Mais l’infection a des comportements reconnaissables. Sans faire de chasse au moindre “eval”, cherchez plutôt une combinaison de signaux.

1) Une quantité anormale de PHP dans des endroits non attendus

Dans un site sain, on trouve des fichiers PHP essentiellement dans plugins et thèmes, parfois dans quelques dossiers spécifiques. Si vous repérez des fichiers .php directement dans des sous-dossiers d’uploads (exemple: wp-content/uploads/2024/xx/), c’est un signal fort.

Je me base souvent sur une simple règle pragmatique: si un fichier PHP se trouve dans un dossier qui sert au contenu média, il mérite au minimum une vérification ligne par ligne, même si la taille du fichier est minuscule.

2) Horodatages et tailles incohérents

Sur beaucoup de compromissions, vous verrez des fichiers qui apparaissent “d’un coup” autour d’une date. Parfois, ce sont une ou deux dates, parfois un lot complet. Une taille minuscule associée à une logique suspecte (quelques centaines d’octets) est souvent plus inquiétante qu’un gros fichier.

Attention toutefois aux cas légitimes: des mises à jour de plugins peuvent générer de nouveaux fichiers ou modifier des caches. Le critère n’est pas “modifié récemment”, c’est “modifié récemment plus comportement suspect”.

3) Contenu obfusqué ou encodé

L’obfuscation seule n’est pas une preuve. Des bibliothèques de minification peuvent sembler “codées”. Mais quand un fichier PHP ressemble à une charge utile qui reconstruit du code à partir de chaînes, avec des fonctions qui manipulent des encodages et des exécutions conditionnelles, là, on est dans une autre catégorie.

Dans mon expérience, les infections se trahissent souvent par des patterns comme l’exécution conditionnelle selon des variables serveur, des checks sur l’agent utilisateur, ou des inclusions dynamiques.

4) Tentatives de communication externe

Certains payloads tentent de télécharger un second stade depuis un domaine externe, ou d’envoyer des requêtes pour sonder l’environnement. Ce n’est pas toujours visible si vous analysez un fichier isolé, mais dans les logs et dans le code, on repère vite ce qui “ne ressemble pas à du WordPress”.

Si vous avez des données de serveur (par exemple accès sortants bloqués par pare-feu, ou erreurs réseau), c’est un bon complément. Sans logs réseau, la lecture du code reste la méthode la plus fiable.

Travailler par comparaison, pas uniquement par lecture

Une erreur fréquente consiste à ouvrir “le fichier suspect” et à croire que l’affaire est finie. Souvent, l’infection est en plusieurs morceaux. Par exemple: un fichier dépose une autre charge utile, ou un plugin lit un fichier dans uploads, ou un thème déclare un hook qui invoque une fonction ailleurs.

Pour éviter de rater une partie, comparez:

la structure de vos fichiers avec une version saine si vous l’avez (même un commit, même une sauvegarde “d’avant”), ou la présence de modifications par rapport à l’état connu.

Si vous ne pouvez pas comparer, utilisez des heuristiques. Dans un dossier plugin infecté, vous verrez parfois plusieurs fichiers qui portent des noms “banals” mais ne sont pas attendus par la logique du plugin.

Analyser uploads sans se faire piéger par le volume

Uploads est le dossier qui génère le plus de bruit. Il peut contenir des milliers d’images, PDFs, SVG, et parfois des caches générés. L’analyse doit donc être orientée “anomalies”.

Ce que je fais en général, c’est filtrer d’abord par extension et par rôle:

je liste les fichiers qui ont des extensions inattendues au regard de votre site, je regarde les fichiers PHP ou “bizarres” dans des sous-dossiers images, je vérifie les fichiers dont le contenu ne correspond pas à leur type attendu (au minimum via l’inspection rapide de l’entête, si c’est faisable).

Si vous trouvez par exemple un fichier avec extension .php ou une extension non standard, le traitement est clair: vous examinez le code source ou la charge éventuelle. Si vous trouvez uniquement des images et des PDFs, sans comportement suspect apparent, vous avancez, mais vous gardez un œil sur les dates et sur la présence de fichiers textuels ou d’archives là où ils ne devraient pas être.

Edge case fréquent: des générateurs de PDF ou des pipelines de conversion déposent des fichiers temporaires, parfois temporaires et pas toujours supprimés. Dans ce cas, la cohérence du projet compte. La “bonne anomalie” a un contexte, la mauvaise ne laisse aucune logique.

Analyser plugins et thèmes comme une enquête, pas comme un scan

Dans plugins et thèmes, vous pouvez être plus direct. WordPress charge les fichiers en fonction des hooks, des inclusions, des conditions de chargement. Une infection s’y cache souvent dans:

un fichier functions.php modifié, un fichier principal du plugin (souvent celui qui définit l’ensemble), des fichiers qui ne sont normalement pas actifs mais qui sont inclus dynamiquement.

Quand vous ouvrez un fichier suspect, je cherche trois choses:

Est-ce qu’il “parle” à WordPress (hooks, filtres) d’une manière qui semble cohérente, ou est-ce que le code se contente de détourner des points d’entrée?
Est-ce qu’il exécute du code à partir de chaînes ou d’un contenu externe? 3) Est-ce que l’infection est conditionnelle, par exemple selon l’URL ou selon des paramètres d’environnement?

Un détail qui m’a sauvé plusieurs fois: parfois l’infection ne démarre pas pour l’URL que vous testez. Elle se déclenche sur une autre route, ou pour une session, ou seulement quand une variable est présente. Si vous ne coupez pas le mécanisme d’amorçage (le fichier “qui lance”), vous pouvez supprimer des morceaux “apparents” sans résultat.

Une méthode pratique pour trier ce qui compte

Voici une façon de rester efficace sans transformer l’analyse en marathon.

Mini-checklist de tri immédiat (wp-content)

Repérez les fichiers .php dans des emplacements inattendus (notamment sous uploads). Vérifiez les fichiers modifiés récemment, en croisant avec une sauvegarde d’avant si vous l’avez. Ouvrez les fichiers suspects et repérez l’obfuscation, les inclusions dynamiques, les appels à des fonctions d’exécution ou de téléchargement. Contrôlez dans plugins et thèmes les points d’entrée (fichiers “principaux”, hooks, includes). Faites l’hypothèse la plus simple qui colle aux faits, puis cherchez ce qui pourrait contredire cette hypothèse.

Cette méthode n’est pas “la vérité absolue”, mais elle vous évite de vous perdre. Le but n’est pas d’être parfait du premier coup, c’est d’être rapide sans être aveugle.

Repérer la persistance dans wp-content, même si ce n’est pas “le virus”

Quand on nettoie, on confond souvent https://gardewp.fr/nettoyage-malware-wordpress/ l’infection avec la charge utile. Or, une infection peut persister via un mécanisme dans wp-content, même si le déclencheur principal se trouve ailleurs.

Exemples typiques:

Un plugin compromis enregistre une routine sur shutdown ou init, qui lance une logique cachée. Un thème modifie un hook et inclut un fichier externe ou interne. Un fichier dans uploads contient du code encodé que le plugin décode au moment opportun.

Donc, même si vous trouvez un fichier “méchant”, demandez-vous: qui l’invoque? La réponse est souvent dans les hooks de plugins ou de thèmes. C’est là que vous devez trouver le fil rouge.

Travailler avec prudence sur les suppressions

Supprimer un fichier est parfois nécessaire, mais c’est un acte destructeur. Sur des sites très bricolés, vous pouvez casser autre chose que l’infection, et déclencher des erreurs 500 ou un manque de fonctionnalités.

Je préfère souvent une approche “coupure d’accès” avant suppression définitive:

renommer un fichier suspect pour le rendre inactif, ou le déplacer hors du chemin de chargement, puis vérifier le comportement du site et des pages à risque.

Une fois que vous confirmez que l’infection ne se déclenche plus, vous supprimez proprement. Ce délai évite de tomber dans le scénario “j’ai supprimé, maintenant je ne sais pas ce qui a causé la panne”.

Deux signaux qui trompent souvent

Il y a des moments où un fichier semble suspect, mais ne l’est pas, et à l’inverse des moments où un fichier est très dangereux mais ressemble à “du code banal”.

Signaux trompeurs côté analyse statique

De simples fonctions utilitaires de plugins qui manipulent des chaînes. Sans contexte, ça peut sembler obfusqué, mais c’est parfois juste de la logique métier. Du code minifié dans des assets, surtout des fichiers .js ou .css. Dans ce cas, on n’est pas sur une charge PHP. Le danger est souvent ailleurs.

Signaux trompeurs côté dynamique

Un fichier PHP peut être “propre” à première vue mais être inclus de manière malveillante ailleurs. Inversement, un fichier très obfusqué peut n’être qu’un composant jamais exécuté.

C’est pour ça que la logique de déclenchement compte autant que le contenu.

Vérifier ce que WordPress charge réellement

Sans aller trop loin dans les outils, vous pouvez observer ce qui se charge vraiment en pratique. Les infections laissent des traces dans le comportement du site, et parfois dans les erreurs ou dans les pages qui s’affichent.

Sur un site compromis, j’utilise souvent un test simple: désactiver temporairement un plugin ou changer le thème, puis vérifier si le comportement malveillant disparaît. Si vous ne voulez pas toucher au site en production, faites-le sur un clone local.

Mais attention, désactiver “au hasard” peut casser le site. Et certains payloads restent actifs via d’autres éléments, donc ce test ne remplace pas l’analyse.

Quand wp-content n’est pas le seul coupable

Même si l’article se concentre sur wp-content, un nettoyage réaliste implique d’avoir l’œil sur le reste:

La base de données peut contenir des options malveillantes, des horaires de cron, ou des références à des fichiers dans wp-content. Le fichier wp-config.php peut être modifié, même si on ne le voit pas immédiatement. Des comptes utilisateurs peuvent être compromis et réinjecter du code.

Dans mon expérience, la bonne démarche est une boucle: vous analysez wp-content, vous neutralisez les fichiers et plugins suspects, puis vous observez. Si ça revient, vous élargissez le diagnostic.

Un plan de nettoyage cohérent après analyse

Une fois que vous avez identifié les fichiers ou plugins responsables, vous passez à l’action avec méthode. Le but est de faire disparaître la logique d’infection et de réduire la probabilité de réapparition.

Je procède généralement comme suit, en restant pragmatique:

neutraliser d’abord les points d’entrée dans plugins et thèmes, vérifier ensuite uploads pour tout ce qui sert de stockage à l’infection, remplacer par des versions “officielles” quand c’est possible (plutôt que corriger au hasard un fichier corrompu), puis re-tester les comportements à risque.

Si un plugin est modifié profondément et que vous n’avez pas une version de référence propre, le mieux est souvent de réinstaller le plugin depuis sa source fiable, après avoir vérifié qu’il n’est plus compromis. Idem pour un thème.

Le compromis, c’est le temps. Réinstaller proprement peut prendre plus de minutes que “supprimer la fonction suspecte”. Mais sur les infections, c’est souvent plus rentable, car vous évitez les résidus invisibles.

Signes d’une neutralisation réussie (à vérifier)

Les redirections ou scripts malveillants ne se déclenchent plus sur les URLs testées. Les fichiers suspects ne sont plus chargés, ni inclus par des hooks. Le comportement ne revient pas après quelques minutes (le temps que cron et hooks finissent leurs cycles). Le site ne renvoie plus d’erreurs 500 liées aux fichiers modifiés.

Et après le nettoyage: éviter la récidive

Nettoyer wp-content est indispensable, mais ce n’est pas la fin du travail. J’ai vu des sites “propres” au moment de la vérification, puis recontaminés parce que l’accès initial était resté ouvert: mot de passe trop faible, plugin obsolète, thème nullement à jour, autorisation trop large, ou serveur mal configuré.

Sur ce volet, l’idée est de fermer la porte avant de recoller le mur:

verrouiller les comptes et réduire les droits, mettre à jour les composants (plugins, thèmes), vérifier les règles d’accès au niveau serveur et les exécutions de scripts dans des dossiers non prévus, contrôler ce qui a créé la brèche.

Même si votre focus reste wp-content, cette étape détermine si votre nettoyage tiendra.

Cas concrets qui reviennent souvent

Sans transformer ça en liste exhaustive, voici trois situations typiques qui m’ont donné du fil à retordre.

Dans le premier cas, le fichier suspect était dans un thème enfant, modifié avec un morceau de code très court. À première vue, ça semblait presque inoffensif. Le piège, c’était que ce morceau déclenchait un chargement vers un fichier dans uploads, chargé ensuite selon l’URL. Tant que vous ne suiviez pas la chaîne d’inclusion, vous pensiez avoir “enlevé le problème” alors qu’il restait actif ailleurs.

Dans le deuxième cas, on avait des fichiers PHP dans un dossier sous uploads. Là, c’était clair, mais la question était: pourquoi ils étaient là, et qui les a déposés? Le plugin compromis s’activait seulement pour les pages d’administration, puis utilisait un mécanisme de reconstruction de contenu. Supprimer les fichiers “méchants” sans neutraliser le plugin a entraîné un retour quelques heures plus tard.

Dans le troisième cas, l’infection n’était pas dans des fichiers PHP évidents, mais dans un script qui modifiait l’exécution en fonction de certains paramètres. Le code était difficile à lire, mais l’analyse de déclenchement, en recoupant ce qui se produisait côté navigateur, a permis d’identifier le point d’amorçage. Une fois neutralisé, le reste était devenu inoffensif, même si des traces restaient en place.

Ces cas montrent pourquoi l’analyse de wp-content doit être structurée. On ne cherche pas juste “ce qui ressemble à un virus”, on cherche “ce qui déclenche quoi”.

Faire le tri final sans rater les détails

Quand vous arrivez à la fin, il reste deux risques: laisser un résidu actif, ou casser quelque chose de légitime en voulant faire propre.

Pour réduire ces risques, j’adopte deux principes:

si vous pouvez remplacer un plugin ou un thème par une version saine, faites-le plutôt que de réparer “au scalpel” 2) si vous devez modifier, ne le faites pas en aveugle: gardez une trace de ce qui a été changé, et testez les pages critiques après chaque correction majeure

Enfin, ne vous fiez pas uniquement à un test manuel rapide. Une infection peut être lente, conditionnelle, ou dépendre de caches. Sur un site vivant, j’ai l’habitude d’attendre un peu et de recouper avec des observations concrètes, avant de conclure que wp-content est “vraiment” propre.

Si vous voulez, je peux aussi vous aider à construire un plan d’analyse adapté à votre situation, en fonction de ce que vous avez remarqué (date d’infection, comportement du site, quels dossiers contiennent des fichiers inattendus, extensions étranges, erreurs serveur). Même quelques détails suffisent pour orienter l’enquête sans perdre des heures.