Quand un site WordPress se fait contaminer, le problème ne se résume presque jamais à “supprimer quelques fichiers”. La partie visible du piratage, celle qu’on trouve dans /wp-content/uploads ou dans la racine, est souvent un résultat. La cause se cache ailleurs: un plugin abandonné, un compte admin dont le mot de passe a été réutilisé, une faille sans patch appliqué, ou une faiblesse côté hébergement.
Le nettoyage, oui. Mais le vrai enjeu, c’est d’éviter que l’infection revienne. Et pour ça, la surveillance continue n’est pas un luxe, c’est une discipline opérationnelle. Dans cet article, je vais détailler une approche réaliste, celle que j’ai vue fonctionner dans des contextes très différents, des sites vitrine aux boutiques WooCommerce. L’objectif: détecter tôt, réduire le temps de réaction, et rendre la restauration moins “au hasard”.
Pourquoi le “nettoyage des fichiers infectés WordPress” ne suffit pas
La plupart des interventions commencent de la même manière: on identifie des scripts suspects, on compare des contenus avec l’original WordPress, on supprime, on change des identifiants, puis on teste. Et parfois, ça marche. Parfois seulement.
Le piège, c’est que l’infection peut être multi-couches:
- des fichiers webshell qui réapparaissent parce qu’un processus les recrée, des injections dans des thèmes ou plugins mis à jour par le pirate, des charges utiles qui activent une redirection seulement sur certains user agents, des comptes ajoutés ou des droits escaladés, puis effacés dans la foulée.
J’ai vu un cas où le site semblait “propre” après suppression des fichiers. Le lendemain, les pages de recherche internes redirigeaient vers une URL aléatoire. La charge active n’était pas dans les fichiers effacés, mais dans un mécanisme de persistance: une tâche cron masquée, alimentée par un script encore présent dans un répertoire moins évident. Le nettoyage avait traité le symptôme, pas la mécanique.
La surveillance continue sert précisément à ça: observer le système après le nettoyage, vérifier qu’il ne dérive plus, et repérer les signaux faibles avant que tout ne redevienne “visible”.
Définir ce que vous cherchez à détecter (sinon vous ne détecterez rien)
Sur un WordPress, la surveillance peut vite devenir un bruit permanent. L’erreur fréquente consiste à collecter “tout ce qui existe” et à espérer que les bons événements ressortent. En pratique, il faut définir des objectifs concrets.
Votre surveillance devrait viser au minimum trois familles de problèmes:
Altérations de fichiers (créations, modifications, suppression) dans les zones sensibles. Activité suspecte côté application (tentatives d’accès, erreurs répétées, comportements anormaux). Signaux réseau et livraison (redirections, requêtes vers des domaines inattendus, charge de ressources anormale).Chaque famille demande des capteurs et des règles différentes. Si vous ne faites pas ce tri, vous allez recevoir des alertes inutiles. Si vous le faites mal, vous allez rater le signal utile. D’où l’intérêt d’une approche structurée, mais sans lourdeur excessive.
Cartographier vos surfaces WordPress, en partant du réel
Avant d’installer quoi que ce soit, je conseille presque systématiquement une cartographie “terrain” des emplacements où un pirate aime déposer du code. Sur WordPress, les cibles classiques sont bien connues, mais chaque installation a ses nuances.
Commencez par distinguer:
- le noyau WordPress (fichiers distribués par WordPress), le contenu applicatif (thèmes et plugins), les uploads et médias, les zones liées à l’hébergement (cron, configuration, logs, sauvegardes), et votre propre couche (mu-plugins, customizations, MU, snippets, uploads spécifiques).
Ce que je fais ensuite, c’est un “inventaire de référence” après nettoyage. L’idée n’est pas de tout figer à jamais, mais de savoir ce qui change “normalement” et ce qui ne devrait jamais changer.
Par exemple, un site qui publie du contenu chaque semaine doit naturellement modifier des fichiers liés à la génération de cache, ou à certains systèmes de minification. En revanche, la création d’un fichier PHP dans un dossier d’uploads à minuit, sans publication associée, n’a rien de normal. Les règles doivent tenir compte de votre rythme réel.
La méthode qui marche: baseline + surveillance + validation
La surveillance continue, dans un environnement WordPress, tient sur un cycle répétable.
1) Créer une baseline solide après nettoyage
Une baseline, c’est votre point de référence: un état connu et sain. Elle peut être un instantané des hachages de fichiers (hash MD5 ou SHA), une liste d’empreintes, et une collecte de métadonnées.
En pratique, je recommande de baseliner:
- les fichiers du répertoire WordPress (hors caches générés), les thèmes et plugins (avec versions et empreintes), et les fichiers de configuration que vous contrôlez.
Si vous avez des fichiers générés (par exemple un cache statique, des bundles), vous excluez ce qui n’est pas stable ou vous le regroupez dans une catégorie “non critique” avec des règles plus souples.
L’erreur que je vois, c’est baseliner avant d’avoir fini. On fige une situation déjà sale, puis on alerte en boucle sur ce qui ne changera jamais “normalement”.
2) Surveiller les changements avec des règles ciblées
Ensuite, on met en place des mécanismes de détection. Selon votre hébergeur et votre niveau d’accès, vous pouvez combiner:
- une surveillance des fichiers par hachage périodique, une journalisation des modifications (si votre stack le permet), des alertes sur création de fichiers dans des répertoires sensibles, et une surveillance applicative (authentification, erreurs, comportements).
Je privilégie une logique “détecter, puis comprendre”. Cela veut dire que l’outil qui repère un changement doit permettre d’identifier rapidement: quel fichier, quand, et par quel contexte.
3) Valider l’alerte (sinon vous perdez du temps)
La surveillance continue ne vous sert que si vous savez répondre. Une alerte doit déclencher un mini-processus d’investigation, pas juste une panique.
Avec les bonnes pratiques, votre validation consiste souvent à:
- vérifier si l’événement correspond à une action planifiée (mise à jour plugin, déploiement), vérifier si le fichier correspond à un composant légitime, et comparer contre la baseline.
Quand une équipe ignore ce volet, elle finit par “apprendre” que les alertes sont inutiles, puis elle les laisse tomber. C’est là que la surveillance perd son sens.
Capteurs côté fichiers: hash, règles de répertoires, et exclusions intelligentes
Les changements de fichiers sont le meilleur levier de détection pour des infections persistantes. Mais il faut le faire proprement, sinon vous allez être noyé.
Le point clé, c’est de choisir une approche compatible avec votre hébergement:
- si vous avez un accès shell et suffisamment de ressources, vous pouvez faire des scans périodiques avec hachage, si vous êtes limité, vous dépendrez davantage d’outils de sécurité applicatifs ou de fonctions d’alerte côté panel, si votre système gère déjà des “integrity checks”, vous vous branchez dessus plutôt que de dupliquer.
Dans tous les cas, je conseille de structurer vos règles en répertoires. Par exemple, vous pouvez être strict sur des zones où un PHP inattendu n’a pas de raison d’apparaître. Vous pouvez aussi être plus flexible sur certains sous-dossiers d’outils (cache, minification), à condition d’avoir la baseline.
Une mini-règle empirique utile
Quand je configure la surveillance, je me pose une question simple: “Est-ce qu’il y a un scénario légitime qui expliquerait la modification dans les 24 dernières heures, sans que je l’aie fait moi-même?” Si la réponse est non, alors le niveau d’alerte doit être élevé.
Capteurs côté WordPress: authentification, erreurs, et traces d’actions
Les fichiers ne racontent pas toute l’histoire. Un pirate peut modifier des données via l’application, ou créer un accès persistant sans laisser de code visible immédiatement. C’est là que la surveillance applicative devient indispensable.
Sur WordPress, les signaux les plus utiles sont souvent:
- les tentatives de connexion répétées, la création de nouveaux comptes ou des changements de rôles, les erreurs 404 sur des endpoints inexpliqués, les événements WordPress liés aux mises à jour, et les traces d’injection dans les zones de contenu.
Je ne parle pas seulement des logs bruts. Ce qui compte, c’est la corrélation. Par exemple, une hausse de tentatives de login combinée à des modifications de fichiers sur un thème peu après est un couple très révélateur.
Surveiller la livraison: redirections, domaines inconnus, et comportement anormal
Certaines infections ne visent pas à “casser” le site. Elles cherchent plutôt à détourner le trafic, injecter des liens, ou déclencher des redirections conditionnelles.
C’est là qu’une surveillance réseau, même légère, aide beaucoup. Elle peut prendre plusieurs formes:
- vérification régulière de pages clés (par exemple accueil, pages produit, pages de recherche), comparaison du HTML attendu, détection de redirections vers des domaines non autorisés, et surveillance des performances (un pic de chargement anormal peut révéler une injection de ressources).
J’ai déjà vu un site qui redirigeait uniquement sur un sous-ensemble d’adresses IP, donc impossible à repérer avec un simple test depuis un seul navigateur. La solution a été de mettre en place une vérification automatisée depuis plusieurs points, pas “plus sophistiqué”, juste plus représentatif.
Mise en place concrète: un scénario “propre” de surveillance continue
Je vous propose maintenant une séquence pragmatique. Elle ne dépend pas d’un fournisseur unique, et elle peut être adaptée à la taille de votre site.
Étape 1: remettre une base saine avant de surveiller
Si votre site est déjà infecté, la surveillance pendant le nettoyage n’a pas de sens. Vous allez surveiller une situation instable. Faites d’abord le travail de fond: identifier les fichiers et entrées persistantes, restaurer un état sain, changer les accès, et mettre à jour ce qui doit l’être. L’objectif est d’arriver à un état que vous acceptez comme “référence”.
Étape 2: générer une baseline de fichiers et de configurations
Ensuite, générez les empreintes de référence. Selon votre stack, ce peut être:
- un export de hachages des fichiers pertinents, une liste des fichiers présents, et une extraction de versions de plugins et thèmes.
Gardez aussi un inventaire des comptes WordPress, et un relevé des rôles. Un pirate aime créer un compte admin “technique” à faible visibilité.
Étape 3: activer des alertes sur les changements non attendus
À ce stade, vous configurez des alertes sur:
- création/modification dans des zones sensibles, changements de rôle, et tentatives d’accès suspectes.
Le réglage du seuil est important. Sur un site vivant, certains événements arrivent légitimement. Le but n’est pas d’avoir zéro alerte, mais des alertes justes.
Étape 4: tester vos alertes avec un scénario contrôlé
Oui, tester. Par exemple, simulez une modification de fichier dans un répertoire surveillé (sur une copie ou dans un environnement de staging). Vous vérifiez que l’alerte se déclenche et que vous comprenez l’info fournie.
Si l’alerte arrive sans contexte, vous ne gagnerez pas de temps en incident. Vous voulez idéalement un message avec l’identifiant du fichier, l’heure, et un moyen d’ouvrir une investigation.
Checklist courte pour une surveillance qui ne vous fatigue pas
Voici une https://gardewp.fr/nettoyage-malware-wordpress/ checklist orientée “terrain”. Elle sert à vérifier que votre surveillance continue ne devient pas un fardeau.
- Baseline créée après un état sain, pas pendant un nettoyage en cours Périmètre défini par répertoires (strict sur le sensible, flexible sur le cache) Alertes capables de dire quoi a changé, quand, et où Traces applicatives suivies (authentification, nouveaux comptes, rôles) Un processus de validation écrit, même sur une page de notes
Gérer les faux positifs: le compromis réaliste
Les faux positifs arrivent, même avec une bonne configuration. Je pense que ce qui fait la différence, c’est la façon dont vous les gérez.
Souvent, les faux positifs viennent de trois sources:
Des mises à jour manuelles sans concertation, Des outils d’optimisation qui réécrivent des fichiers ou régénèrent des caches, Des sauvegardes ou restores qui modifient des artefacts.Si vous travaillez en équipe, documentez les fenêtres de maintenance. Une alerte déclenchée pendant une mise à jour programmée peut être traitée différemment, parfois en mode “contrôle”, pas en mode “incident”.
Un autre point crucial: ne “désactivez” pas aveuglément les alertes les plus utiles. J’ai vu des équipes couper les contrôles sur les répertoires sensibles parce qu’elles recevaient trop d’alertes, puis découvrir trop tard que la persistance passait justement par ces zones.
Persistance: les indices qui reviennent dans les infections persistantes
Quand une infection revient après nettoyage, il y a souvent un schéma. Vous allez le voir dans les logs et dans les changements.
Les indicateurs typiques que j’ai observés, dans des termes simples, sont:
- des fichiers recréés automatiquement dans des temps proches d’une tâche programmée, des comptes WordPress ajoutés juste après une tentative de suppression, des erreurs 403 ou 404 qui augmentent, associées à des URL inconnues, des redirections qui ne se produisent pas dans tous les contextes, des mêmes patterns de modification sur des zones peu utilisées.
Ce n’est pas un diagnostic automatique, mais ça oriente. Et surtout, ça rend votre investigation plus rapide, parce que vous savez où chercher en premier.
Automatiser sans perdre le contrôle
L’automatisation est tentante, mais elle peut dérailler si elle masque des informations. Pour ma part, je vise un équilibre:
- automatiser le recueil et la corrélation, laisser l’humain valider l’action.
Par exemple, vous pouvez envoyer une alerte dès qu’un fichier sensible change. Ensuite, vous déclenchez un script d’extraction de métadonnées ou une comparaison de baseline. Mais l’action finale reste une décision: restaurer, isoler, investiguer, ou nettoyer.
Une automatisation trop agressive, du type “supprimer tout ce qui a bougé”, peut détruire des changements légitimes, notamment après une mise à jour ou un déploiement custom. Vous voulez une stratégie qui réduit le temps de réaction sans casser votre capacité de livraison.
Choisir où stocker et comment protéger les preuves
Sur une infection, les preuves comptent autant que le nettoyage. Si vous devez revenir en arrière, vous aurez besoin de:
- la baseline, les logs applicatifs, les logs web ou d’hébergement, et idéalement des captures d’état.
Protégez ces données comme si elles étaient critiques, parce qu’elles le sont. Un pirate peut tenter de les effacer ou de les corrompre, surtout s’il a un accès assez large.
J’ai déjà vu un incident où les logs étaient “accessibles”, mais compressés et rotatifs très vite. Quand l’équipe a voulu analyser, il restait trop peu d’historique. Depuis, j’essaie de m’assurer que la surveillance conserve une fenêtre de rétention suffisante pour remonter au moment de l’introduction.
Cas d’usage: deux architectures, deux réglages
Un WordPress sur mutualisé n’a pas le même niveau de contrôle qu’un WordPress sur VPS. Deux décisions changent alors.
Sur un mutualisé:
- vous privilégiez les outils applicatifs et les checks de fichiers accessibles, vous surveillez plus les logs, les changements déclaratifs (comptes, rôles), et la livraison (redirections), vous minimisez les scripts lourds.
Sur un VPS ou un serveur géré:
- vous pouvez faire des intégrités réguliers plus fréquentes, vous pouvez analyser les tâches cron, les permissions, et les processus, vous pouvez tracer plus finement.
Dans les deux cas, le principe reste le même: baseline, surveillance ciblée, validation.
Quand suspecter autre chose que des “fichiers infectés”
Parfois, on croit traiter des fichiers infectés WordPress alors que la cause est différente. Cela arrive si:
- l’infection a lieu via une extension légitime mais compromise, l’accès passe par une configuration d’hébergement mal protégée, l’attaquant exploite une faille de mise à jour automatique, ou le site est “propre” mais le trafic est détourné ailleurs, via DNS, CDN mal configuré, ou script externe.
C’est pour ça que la surveillance continue doit couvrir aussi les domaines, les redirections, et le comportement. Les fichiers ne sont qu’une partie du système.
Plan d’action si une alerte tombe
Je termine avec un principe simple: traitez l’alerte comme une scène d’incident. Même si vous êtes pressé.
Sans écrire un protocole interminable, mon approche est:
- Identifier rapidement la nature de l’événement (quel fichier, quel compte, quel endpoint). Vérifier si cela correspond à une action planifiée. Comparer immédiatement la baseline. Si suspicion forte, isoler le site (au minimum limiter l’exposition, selon votre marge) et restaurer vers une version de référence saine. Puis seulement, investiguer la cause: faille, mot de passe, rôle, permission, plugin, configuration.
Ce qui change tout, c’est la séquence. Si vous supprimez des choses au hasard, vous perdez la capacité de comprendre comment le problème s’est répété. Le bon ordre, c’est d’abord comprendre, puis agir, même si l’urgence impose des compromis.
Ce que vous gagnerez avec une surveillance continue
Une fois en place, la surveillance continue transforme le nettoyage en système. Vous passez d’une stratégie “je répare quand ça casse” à “je détecte avant que ça casse”.
Le bénéfice le plus concret se mesure en temps: moins d’heures perdues à inspecter, moins de restauration “à l’aveugle”, et une meilleure maîtrise des récurrences. Et surtout, vous réduisez la probabilité que votre nettoyage fichiers infectés WordPress devienne un rendez-vous régulier.
Si vous devez retenir une seule idée, ce serait celle-ci: la surveillance n’est pas un outil, c’est une méthode. Elle relie la baseline à des signaux clairs, puis elle vous donne une façon rapide de décider. C’est ce trio qui fait tenir dans la durée, sans épuiser l’équipe.
Si vous me donnez votre configuration (hébergeur, accès shell ou non, plugins critiques, fréquence de mise à jour, taille du site), je peux vous proposer une stratégie de surveillance continue plus ajustée, avec des règles et des seuils adaptés à votre réalité.