Site WordPress infecté : automatiser le scan de fichiers

Quand on découvre un site WordPress infecté, la première réaction est souvent émotionnelle: on veut “tout nettoyer” tout de suite, sans prendre le temps de comprendre. Le problème, c’est que nettoyer à l’aveugle donne rarement un résultat stable. Souvent, l’infection a déjà modifié des points précis, laissé des portes ouvertes, ou introduit des charges utiles discrètes. Et si vous ne mettez pas en place un moyen fiable de vérifier ce qui change, vous risquez de repartir en cycles: nettoyage, retour en ligne, nouvelle rechute.

Automatiser le scan de fichiers ne sert pas seulement à détecter un “virus”. Dans la pratique, ça sert surtout à obtenir une base factuelle: quels fichiers ont été modifiés, quand, par rapport à quoi, et avec quelle confiance. Ensuite, vos décisions de remédiation deviennent plus rationnelles. Vous ne travaillez plus sur des impressions, vous travaillez sur une trace.

Je vais vous décrire une approche pragmatique, centrée sur l’automatisation. Elle s’appuie sur des outils de vérification et sur des méthodes de comparaison, plutôt que sur une seule alerte “ça sent mauvais”. L’objectif est de réduire le temps entre détection et action, sans transformer votre serveur en usine à gaz.

Pourquoi le scan doit être automatisé (même si vous “surveillez” déjà)

Beaucoup d’administrateurs font, au moins une fois, ce réflexe: vérifier quelques fichiers suspects, relire le contenu de wp-config.php, jeter un œil aux plugins récents, regarder les logs, puis passer à la purge. C’est utile, mais c’est rarement suffisant, parce que l’infection WordPress moderne n’arrive pas en une seule fois. Elle peut:

modifier des fichiers au hasard dans des répertoires inattendus mettre en place un mécanisme de persistance via des scripts qui ne s’exécutent que dans des conditions spécifiques réécrire des fichiers très souvent, ce qui rend la comparaison “à la main” fragile

L’automatisation change la cadence. Au lieu de “quand j’ai le temps”, vous passez sur “à chaque heure, ou chaque nuit, ou à chaque déploiement”. Et surtout, vous pouvez historiser les résultats. C’est là que ça devient vraiment puissant: vous voyez la tendance. Une infection qui se “réinstalle” après remédiation devient visible quand vous comparez les scans.

Il y a aussi un point d’hygiène opérationnelle. Quand un site est compromis, on ne sait pas s’il l’est encore. L’analyse manuelle demande souvent de naviguer sur le serveur, d’ouvrir des fichiers, de lancer des commandes. Selon la configuration, ces gestes peuvent être trop intrusifs, ou tout simplement risquent d’oublier un répertoire. Un script robuste, en dehors des heures de pointe, limite l’exposition et la fatigue.

Définir ce que vous voulez détecter, avant de lancer des scans

Automatiser, ça ne veut pas dire “lancer n’importe quoi en cron”. Si vous ne fixez pas des critères, vous aurez soit trop d’alertes inutiles, soit des faux négatifs qui vous donnent une fausse sécurité.

Sur WordPress, les indicateurs utiles se répartissent en trois familles:

Des modifications de fichiers en dehors des schémas attendus Des contenus anormaux dans des fichiers censés rester “propres” (par exemple des signatures dans des fichiers PHP) Des ajouts de fichiers ou de répertoires (fichiers temporaires, scripts cachés, charges utiles dans uploads, ou dans des dossiers rarement consultés)

Le piège classique, c’est de confondre “fichier modifié” et “infection”. WordPress met à jour des caches, génère des fichiers, change des timestamps, et certains plugins écrivent dans le système de fichiers. Si votre scan ne connaît pas vos comportements légitimes, vous allez passer votre temps à valider des faux positifs.

C’est pour ça qu’il faut un référentiel. Même simple.

Un référentiel minimal: l’état de référence

Avant de commencer à scanner “en continu”, établissez au moins une référence de base. Concrètement, après une période d’observation stable, faites une première empreinte de l’arborescence que vous surveillez. Ça peut être:

la liste des fichiers et leurs tailles, droits, propriétaires une vérification par hachage (hash SHA-256 ou équivalent) une extraction de métadonnées (timestamps, propriétaire, permissions)

Le point clé n’est pas d’avoir un système mathématiquement parfait. Le point clé, c’est d’avoir un “avant / après” clair. Dans les incidents réels, c’est souvent cette comparaison qui tranche.

Choisir la stratégie de scan: différentiel, heuristique, ou les deux

Le scan “différentiel” compare l’état courant à votre référence. C’est très efficace quand votre objectif est de voir des changements.

Le scan “heuristique” examine le contenu avec des règles ou des patterns (chaînes suspectes, comportements typiques). Il est utile pour détecter des modifications malveillantes même quand les métadonnées ne changent pas de manière significative.

En pratique, les meilleures chaînes d’automatisation combinent les deux: d’abord vous repérez “ce qui a changé”, ensuite vous inspectez “ce que ça contient”. Comme ça, vous limitez le volume d’analyse coûteuse, et vous augmentez la pertinence.

Il faut aussi tenir compte du périmètre. Un site WordPress ne correspond pas à un seul dossier. Il faut décider si vous incluez:

le dossier des thèmes et plugins wp-content/uploads (souvent énorme) les fichiers racine (dont wp-config.php) éventuellement les fichiers de configuration serveur (selon vos contraintes)

Si vous scannez tout sans discernement, le temps d’exécution peut devenir pénible. Si vous excluez trop, vous perdez des preuves.

Une approche automatisée qui marche vraiment sur le terrain

Voici une méthode que j’ai vue fonctionner dans des contextes différents: VPS, mutualisé, et environnements plus structurés. L’idée est de produire un rapport exploitable, pas juste un statut “ok / ko”.

Étape par étape, sans complexité inutile

Construire un inventaire initial: générer la liste des fichiers surveillés, avec hachage (au moins sur les dossiers “à risque”) et métadonnées. Indexer un sous-ensemble à haute valeur: thèmes, plugins, fichiers PHP racine, et tout ce qui est proche de l’exécution. Exécuter un scan différentiel à fréquence régulière (par exemple une fois par nuit), et sortir une liste de changements. Enrichir l’analyse sur les changements: rechercher des patterns suspects et conserver les extraits (quelques lignes autour d’une occurrence, sans exposer tout le fichier dans les logs).

Ce déroulé tient parce qu’il sépare détection rapide et inspection ciblée. Vous n’êtes pas forcé de scanner chaque octet à chaque passage, vous regardez d’abord “où ça a bougé”.

Exemple concret de fréquence et de périmètre

Sur un site “normal” où le contenu change peu, une exécution nocturne est un bon compromis. Sur un site soumis à beaucoup https://gardewp.fr/nettoyage-malware-wordpress/ de commentaires, ou avec un volume élevé de médias dans uploads, scannez plus intelligemment. Par exemple:

hachage et contenu suspect uniquement pour les fichiers PHP et les fichiers de configuration différentiel de liste de fichiers sur uploads, sans forcément hacher chaque image (ça n’a pas grand intérêt)

Cette séparation évite un coût énorme.

Définir ce qui est “anormal” dans un WordPress

Un contenu suspect n’est pas uniquement une chaîne évidente comme eval(. Les infections utilisent souvent des variantes, des concaténations, et des mécanismes plus discrets. Vous voulez donc des règles capables de capturer des comportements typiques, sans trop de bruit.

Par expérience, les critères qui reviennent sont:

présence de fonctions d’exécution dynamique dans des fichiers où elles n’existent pas habituellement ajout de fichiers PHP “non standard” dans des répertoires non attendus modifications de fichiers de base ou de fichiers stables (par exemple wp-includes ou des fichiers racine), hors mises à jour planifiées

La difficulté est de gérer le contexte. Si vous lancez une mise à jour WordPress tous les mois, vous devez intégrer une phase “post-update” où vous mettez à jour votre référentiel, sinon vous allez déclarer une alerte à chaque changement légitime.

Gestion des exclusions: le point qui fait la différence entre utile et inutilisable

Les faux positifs ne sont pas une question de confort, ils sont un risque opérationnel. Si vous recevez trop d’alertes “basiques”, vous finissez par ignorer les alertes, même les vraies.

Sur WordPress, les zones qui génèrent du bruit:

répertoires de caches fichiers générés par certains plugins certains logs qui tournent en continu

La bonne approche consiste à exclure ce qui est stable et non critique, ou à scoper le scan au contenu réellement exécutable.

En automatisation, on travaille souvent avec deux niveaux:

niveau 1: “liste des fichiers changés” sur un périmètre précis niveau 2: inspection “contenu suspect” uniquement sur les fichiers qui ont changé (ou sur ceux correspondant à des patterns d’emplacement)

C’est une manière de réduire le bruit sans perdre de signaux.

Conserver les preuves: rapport, historique, et triage

Un scan sans historique est presque inutile. Il vaut mieux savoir “ça a changé hier, puis encore aujourd’hui” que d’avoir une alerte isolée.

Conservez au minimum:

la date et l’heure du scan le nombre de fichiers changés par catégorie (PHP, autres) la liste des chemins modifiés (ou un identifiant) et leur ancien / nouveau hash si vous enregistrez les hashes des extraits pertinents si vous cherchez des patterns

Ensuite, vous devez pouvoir trier. Dans les incidents réels, toutes les alertes ne déclenchent pas la même réaction. Si un fichier de thème a changé suite à un déploiement, vous n’allez pas “nettoyer tout”. Si un fichier inconnu a été ajouté dans une zone non documentée, vous déclenchez plus fort.

J’ai vu des équipes se tirer une balle dans le pied en traitant “toutes les alertes comme un incident critique”. En réalité, l’automatisation doit aider à décider.

Un mini guide de triage, en conditions réelles

Quand le rapport tombe, vous vous demandez d’abord: “est-ce que ce changement a une explication légitime?”

si vous venez de déployer, la chronologie doit matcher si le fichier appartient à un plugin installé récemment, ce n’est pas forcément sain, mais c’est moins surprenant si le fichier a des permissions étranges, ou s’il apparaît dans un répertoire improbable, ça devient prioritaire

Il arrive aussi que le référentiel de départ soit “contaminé” si vous l’avez créé pendant une période de compromission. Dans ce cas, l’algorithme différentiel peut ne rien dire, parce que tout semble normal à l’intérieur de votre référence. C’est rare, mais c’est arrivé: le premier scan sert aussi à qualifier la qualité de base.

Sélection d’outils: rester pragmatique plutôt que chercher le “parfait”

Il existe plusieurs manières d’automatiser un scan de fichiers. Plutôt que de vous promettre un outil magique, je préfère vous donner des catégories d’approche, chacune avec ses points de vigilance. Le choix dépend de votre hébergement, de vos droits, et de votre tolérance au bruit.

Voici trois options typiques, utilisées dans des contextes différents:

Outils basés sur hachage: ils comparent des empreintes et sont très efficaces pour repérer un changement. En revanche, ils nécessitent un inventaire de référence et une attention sur les exclusions. Outils basés sur patterns / signatures: ils inspectent le contenu et peuvent détecter des webshells ou des scripts cachés. Ils produisent parfois plus de faux positifs si les règles sont trop agressives. Outils intégraux type “scanner de vulnérabilité”: ils peuvent signaler des comportements, mais ils sont souvent moins orientés “preuve de modification de fichier” pour un triage précis.

En pratique, la combinaison “différentiel + inspection contenu ciblée” donne des résultats plus propres qu’un scan monolithique.

Exemple de configuration d’un pipeline sans se ruiner

Sur un serveur où vous avez accès shell, vous pouvez orchestrer vos tâches avec un script qui:

calcule une liste de fichiers (périmètre ciblé) compare aux hachages précédents si différence, ouvre le fichier et cherche des patterns génère un rapport au format texte, avec un identifiant temporel envoie un résumé par email ou via un webhook

Le point de vigilance: assurez-vous que le script manipule correctement les encodages et les fichiers binaires. Si vous tentez d’ouvrir une image comme un texte, vous risquez des erreurs, et vous allez ajouter du temps de maintenance.

Sécurité autour du scan: ne pas se transformer soi-même en vecteur

Un détail qu’on oublie parfois: le scan doit être exécuté de manière sécurisée. Si votre site est infecté, l’environnement peut être compromis. Les risques les plus fréquents:

un fichier malveillant peut déclencher une sortie anormale au moment où vous lisez ou exécutez quelque chose un script de scan mal écrit peut exposer des informations sensibles dans les logs si vous lancez le scan avec un utilisateur trop privilégié, vous augmentez l’impact potentiel d’une compromission

La règle simple: le scan lit, il ne devrait pas écrire. L’écriture doit être limitée à la génération de rapports dans un emplacement contrôlé.

Aussi, évitez de charger des dépendances inutiles. Plus le pipeline est léger, moins il y a de surface d’attaque “dans votre outil”.

Automatiser après la remédiation: ne pas perdre le bénéfice

Nettoyer un site infecté, c’est utile, mais la vraie victoire, c’est de vérifier que la compromission ne revient pas. Sans automatisation, le site peut sembler sain pendant quelques heures, puis rechuter.

Après remédiation, vous devez:

régénérer votre référentiel “propre” (ou le reconstruire depuis une sauvegarde fiable) tester votre mécanisme de scan sur un changement contrôlé (un fichier de test dans un dossier de test, par exemple) garder le scan actif, au moins pendant une période de stabilisation

Une chose que j’ai apprise dans la durée: si vous éteignez le scan dès que le site revient, vous perdez la meilleure fenêtre d’observation. Les infections persistantes jouent sur le temps.

Quand l’infection ne se voit pas dans les fichiers: penser au-delà

Même un scan de fichiers bien conçu peut rester muet si la compromission passe par d’autres voies. Certaines infections:

modifient les options en base de données sans changer grand-chose au système de fichiers injectent du contenu via des mécanismes temporaires, ou des processus côté serveur exploitent des vulnérabilités pour exécuter au moment de la requête, sans laisser de trace évidente au repos

Dans ces cas, l’automatisation de scan de fichiers reste une brique essentielle, mais elle n’est pas toute l’architecture. Vous pouvez compléter avec une surveillance:

d’intégrité de la base (au moins sur certaines tables sensibles) de la configuration serveur des logs d’erreurs et d’accès

Je reste volontairement prudent ici: la bonne combinaison dépend de votre stack. Mais l’idée est claire: le scan de fichiers donne des preuves, il ne résout pas à lui seul tous les scénarios.

Cas fréquents et choix de jugement (ce que vous devez décider sur le moment)

Un rapport de scan contient rarement “une seule alerte”. Il contient des changements, des ajouts, des suppressions parfois. Vous allez devoir trancher avec une méthode.

Voici quelques situations qui reviennent:

De nombreux petits fichiers changés: souvent lié à un déploiement ou à un cache qui a été régénéré. Vérifiez la chronologie. Un fichier ajouté dans un répertoire improbable: ça attire votre attention en priorité, même si le hash ne correspond pas à une signature connue. Un changement dans un fichier de thème, sans déploiement: c’est suspect même si “ça ressemble à un petit ajustement”. Un webshell peut être dissimulé dans une zone qui passe pour du code de personnalisation. Mauvaise cohérence des droits: un fichier important qui passe de 644 à 777 ou un changement de propriétaire doit déclencher un examen rapide.

Dans tous ces cas, le scan automatisé fait gagner du temps, mais il ne remplace pas un jugement. L’objectif est de réduire la zone grise, pas de la supprimer totalement.

Mettre en place l’automatisation sans casser votre exploitation

Le point pratique: le scan ne doit pas ralentir le site au point de créer des symptômes qui imitent l’infection. Si vos scans prennent trop de temps, vous pouvez:

exécuter à heure fixe (nuit) limiter le périmètre strictement aux fichiers sensibles réduire la profondeur de lecture sur les fichiers qui ne changent pas utiliser une stratégie différentiel, plutôt que “tout re-hacher à chaque fois”

Il faut aussi prévoir l’échec. Votre script peut échouer à cause de permissions insuffisantes, d’un fichier illisible, ou d’une montée en charge. Un bon pipeline écrit un rapport même partiel, et signale clairement “scan incomplet”. Sinon, vous aurez l’impression de sécurité, alors que vous n’avez rien vérifié.

Une checklist courte pour démarrer (et éviter les erreurs classiques)

Définir le périmètre surveillé, thèmes, plugins, racine, et fichiers exécutables. Construire une référence “propre” après un état stable, idéalement depuis une sauvegarde fiable si doute. Lancer un premier scan manuellement, valider le bruit, ajuster exclusions. Mettre en place un scan différentiel automatisé la nuit, avec rapport horodaté. Restreindre l’inspection de contenu aux fichiers qui ont changé, puis conserver des extraits pour triage.

Cette liste ne remplace pas une stratégie, elle vous évite surtout de démarrer avec un scan trop large et trop bruyant.

Ce que vous gagnez concrètement en automatisant

Quand vous passez d’une vérification ponctuelle à un pipeline automatisé, les bénéfices apparaissent vite:

vous détectez des changements tôt, parfois avant que le référencement ne décroche ou avant que les utilisateurs ne signalent une redirection vous avez des preuves exploitables, utiles pour travailler avec un hébergeur ou une équipe sécurité vous réduisez la charge mentale, parce que la surveillance devient un processus, pas un effort héroïque

Le gain le plus sous-estimé est la qualité de remédiation. Quand vous nettoyez un site sans savoir précisément ce qui a changé, vous risquez de rater une modification silencieuse. Un scan automatisé fournit la liste des candidats. Et dans un incident, ça vaut de l’or.

Questions à vous poser avant de verrouiller la solution

Avant de figer votre automatisation, je vous recommande de répondre honnêtement à trois questions:

Est-ce que mon référentiel de départ est fiable, ou je pourrais l’avoir construit pendant une compromission? Est-ce que je connais mon historique de déploiement, pour distinguer un changement légitime d’un changement non attendu? Est-ce que mes alertes sont assez actionnables, pour que quelqu’un puisse trier sans relire tout le code?

Ce sont des questions simples, mais elles déterminent si votre automatisation devient une aide ou une source de fatigue.

Si vous voulez, je peux aussi vous aider à cadrer une architecture adaptée à votre environnement, par exemple sur mutualisé sans shell, sur VPS avec accès root, ou sur un déploiement via CI/CD. Le bon système dépend beaucoup de vos contraintes d’accès et de votre capacité à conserver un référentiel fiable dans le temps.