Quand un site WordPress commence à “bouger tout seul”, la première tentation est de lancer un scanner et d’attendre. Malheureusement, j’ai vu trop de cas où le diagnostic arrive tard, ou pire, où l’outil pointe un fichier non coupable parce qu’il a été modifié par le thème, un plugin légitime, ou un script d’optimisation. L’analyse efficace, celle qui tient dans le temps, repose sur une méthode pragmatique: vérifier ce qui a changé, comprendre comment le malware s’exécute, puis confirmer la piste avant de supprimer.
L’objectif n’est pas seulement de “nettoyer”. L’objectif est de savoir ce que vous supprimez, comment c’est arrivé, et ce qui vous évitera une récidive.
Le premier vrai signal: ce qui ne ressemble pas à du WordPress normal
Avant même d’ouvrir un fichier, je commence par observer les symptômes. C’est souvent là que la logique apparaît. Un hack “bruyant” laisse des traces visibles, un hack “silencieux” s’exécute discrètement, et la stratégie d’analyse n’est pas la même.
Sur un site compromis, les signaux typiques incluent des URL inattendues dans les logs, des redirections vers des pages de spam, l’apparition de contenus inconnus dans l’admin, des connexions échouées en boucle, ou des erreurs PHP inhabituelles. J’ai aussi vu des infections qui ne se manifestaient que sur certaines pages, avec un comportement conditionnel, par exemple selon l’agent utilisateur ou un pays.
Ce que je cherche concrètement, c’est une rupture par rapport au fonctionnement normal du site. Une rupture dans les comportements réseau, une rupture dans les requêtes, ou une rupture dans le fichier.
Préparer l’enquête pour éviter de détruire des preuves
Un point que je rappelle souvent sur des interventions, parce qu’il change tout: si vous lancez des actions “au feeling”, vous pouvez casser la piste.
Je prépare donc une base de travail avant d’analyser:
- une copie des fichiers potentiellement modifiés, une copie des extraits de configuration concernés, et, si possible, les traces applicatives ou système disponibles.
Le piège classique est de modifier ou de purger trop vite. Si vous remplacez tout le WordPress “par défaut”, vous effacez parfois l’élément de persistance, ce qui empêche ensuite de comprendre le mécanisme exact. Sur une infection qui déclenche une charge distante, supprimer le fichier trop vite, c’est comme éteindre l’incendie sans relever la cause.
Si votre hébergement permet des snapshots ou des sauvegardes versionnées, utilisez-les pour revenir à un état antérieur. Si vous n’avez pas ça, prenez au minimum des copies locales des fichiers suspects et un export des tables de base liées aux contenus et aux utilisateurs, quand vous en avez l’autorisation.
Scanner malware WordPress: utile, mais pas suffisant
Un scanner malware WordPress est un bon premier filtre. Il repère souvent des signatures connues, des patterns de code obfusqué, ou des emplacements classiques d’injection. Sur le papier, c’est rapide.
En pratique, la question centrale est: “Le scanner a-t-il trouvé quelque chose de plausible, ou a-t-il confondu un mécanisme légitime avec une signature mal interprétée?”
Deux exemples concrets que j’ai rencontrés:
Un plugin de cache ou d’optimisation qui modifie des fichiers de configuration au moment du déploiement, déclenche des alertes de type “code suspect dans un fichier non attendu”, alors qu’il y a une explication par le pipeline CI/CD. Un thème avec un script de tracking ou un auto-constructeur de contenus, qui contient des expressions ressemblant à du code d’obfuscation. Le scanner “voit” un pattern, mais le code ne fait pas de requêtes externes ni de chargement dynamique.La bonne approche consiste à considérer le scanner comme un compteur de pistes. Ensuite, vous validez chaque piste avec une lecture réelle du code et des preuves d’exécution.
Repérer la persistance: le malware n’est presque jamais “seulement un fichier”
Un vrai malware WordPress cherche un point de persistance. Ça peut être un fichier qui se charge au moment du bootstrap, une modification d’un fichier PHP crucial, une modification de la configuration, ou un mécanisme côté base de données.
Ce que je veux identifier, c’est la chaîne d’exécution. Le malware se connecte-t-il à l’extérieur? Est-ce qu’il attend une condition? Est-ce qu’il s’injecte dans la sortie HTML? Est-ce qu’il détourne des requêtes?
La persistance se repère souvent en trois axes:
- fichiers “logiquement au mauvais endroit” (ou modifiés récemment), hooks WordPress (ajouts dans des endroits connus), présence de code qui tente de télécharger ou d’exécuter autre chose.
Sans vous donner une liste de moyens universels, retenez l’idée suivante: si un fichier ne peut pas être appelé, il ne sert probablement qu’à masquer. S’il est appelé, il doit expliquer comment il se déclenche.
Analyse pas à pas d’un fichier suspect, sans se raconter d’histoires
Quand vous avez un fichier identifié par le scanner, je fais une analyse en plusieurs lectures, dans un ordre qui réduit les mauvaises conclusions.
D’abord, je regarde le contexte: emplacement, date de modification, taille, et liens possibles avec le site. Un fichier trop gros pour son rôle habituel, ou trop récent, attire l’attention. Un fichier créé dans le répertoire de plugins mais qui a un nom “générique” ou “obscur” est souvent un indice.
Ensuite, je lis le code avec une logique d’exécution. Les signaux qui m’aident:
- présence de fonctions d’exécution (au sens large, comme des appels qui chargent du code externe ou qui construisent du code à la volée), présence d’URL ou de chaînes de domaine, présence de logique conditionnelle basée sur des variables de requête, présence de base64, de zlib, d’encoding, ou d’algorithmes d’obfuscation.
Le but n’est pas de comprendre tout le code malveillant. Le but est de répondre à trois questions:
Enfin, je corrèle. Si le site montre des redirections, je cherche dans le fichier les patterns qui construisent des redirections. Si le site injecte des scripts, je cherche des morceaux qui modifient le HTML. Si des connexions sortantes existent, je cherche des requêtes réseau dans le code.
Quand le “suspect” est un faux positif: comment trier sans perdre du temps
Un faux positif coûte cher, parce qu’il pousse à supprimer du code légitime ou à casser un fonctionnement. Je garde donc une règle simple: je ne supprime pas tant que je n’ai pas vérifié l’exécution ou l’intention.
Voici les cas typiques où je ralentis:
- le fichier est dupliqué dans un répertoire “attendu” pour une tâche précise (par exemple cache, génération, import), les changements correspondent à une mise à jour de plugin ou à un déploiement, le code suspect ressemble à un utilitaire de tracking ou à un générateur statique, sans appels externes ni mécanisme d’exécution dynamique.
Dans ces cas, je cherche des preuves externes. Par exemple, des logs d’accès qui montrent un appel à ce fichier. Ou des variations corrélées entre l’apparition du problème et la modification de ce fichier.
Le bon jugement consiste à accepter que “scanner plus X fichiers” ne suffit pas, et que “lire le code” ne suffit pas non plus sans corrélation.
Concrètement, que vérifier dans l’espace fichiers et dans WordPress
Sans tomber dans une recette universelle, il y a un lot de contrôles qui reviennent dans presque toutes les infections WordWordPress. Ils servent surtout à distinguer une modification isolée d’un mécanisme de compromise plus profond.
Mini plan de triage (rapide, mais structuré)
- Vérifiez les dates et tailles des fichiers signalés, et comparez avec l’historique de déploiement si vous en avez un. Ouvrez chaque fichier suspect et cherchez les déclencheurs d’exécution: conditions, hooks, chemins de chargement. Contrôlez les requêtes sortantes potentielles dans le code (URL, domaines, mécanismes de chargement). Recherchez la présence de code dans les points de bootstrap WordPress ou dans des fichiers chargés très tôt. Croisez avec les logs serveur ou applicatifs pour voir si le fichier est réellement appelé.
Cette séquence évite deux erreurs fréquentes: supprimer trop vite, ou croire que “scan = vérité”.
Exemples d’indices qui changent l’interprétation
Sur un cas récent, un scanner a signalé un fichier dans une arborescence de plugin. La première lecture du code semblait “obfuscée”. Beaucoup s’arrêtent là et suppriment. Mais en suivant la logique d’exécution, j’ai trouvé une structure conditionnelle basée sur un paramètre de requête non présent dans les logs, et aucune trace d’appel réseau dans le chemin activé. Le fichier ne faisait pas ce que le scanner insinuait, et la date de modification correspondait à une mise à jour.
À l’inverse, sur un autre site, un fichier semblait inoffensif au premier coup d’œil, sans domaine explicite. Mais en décodant une portion encodée, on trouvait une logique de chargement depuis un identifiant fragmenté. Dans ce cas, le scanner avait partiellement raison, mais le point crucial était ailleurs: le mécanisme n’était pas juste “du code suspect”, c’était un https://gardewp.fr/nettoyage-malware-wordpress/ schéma d’exécution dynamique.
Ces exemples illustrent une règle: vous ne gagnez pas en supprimant plus, vous gagnez en comprenant mieux.
Les emplacements à surveiller, sans vous enfermer dans une liste fermée
Je préfère parler d’emplacements “à risque” plutôt que de promettre une liste exhaustive. Les attaquants changent de stratégie en permanence. Cela dit, certaines zones reviennent, parce qu’elles sont faciles à compromettre et efficaces.
Typiquement, les zones sensibles sont celles qui sont chargées tôt, celles qui influencent la configuration, et celles qui servent de pont entre PHP et la génération de contenu.
Si vous avez des preuves dans vos logs ou dans le comportement observé, vous pouvez “remonter” depuis ce point. Par exemple, si les redirections sont constatées vers des domaines inconnus, vous cherchez le code qui génère ces sorties. Si des scripts apparaissent dans le HTML, vous inspectez les endroits où la sortie est modifiée.
L’idée, c’est d’aligner l’analyse avec le symptôme. Ne cherchez pas uniquement des signatures, cherchez la chaîne.
Base de données: quand le malware est “dans WordPress”
Parfois, le malware ne réside pas principalement dans un fichier. Il vit dans la base de données, et ses effets se voient lors du rendu ou via des actions admin.
C’est fréquent lorsque:
- des comptes utilisateurs ont été ajoutés ou modifiés, des options WordPress ont été altérées, des contenus ont été injectés ou des champs liés à des pages ont été manipulés.
Je recommande de traiter la base comme un espace de preuve, pas comme un objet à “nettoyer au hasard”. Exportez ce que vous pouvez, identifiez les changements récents (si vous avez accès à des timestamps fiables), et comparez avec votre état connu.
Si vous êtes en incident, vous pouvez aussi désactiver temporairement certains plugins non essentiels. Mais faites-le avec prudence, parce que désactiver brutalement peut modifier le chemin d’exécution et masquer des traces.
Outils et méthodes: choisir sans vous enfermer
La partie outils est tentante, mais elle mérite un minimum de discernement. Un bon outil ne remplace pas l’analyse humaine. Il réduit le bruit, et c’est déjà beaucoup.
Voici les catégories que je considère, avec une logique de complémentarité.
Outils possibles à combiner
- Scanner de fichiers (local ou via l’hébergement) pour repérer des patterns connus. Vérification d’intégrité (hash ou comparaison de fichiers) pour repérer des modifications. Analyse des logs (web server, PHP, application) pour corréler l’exécution réelle. Inspection WordPress côté utilisateurs et options pour repérer des altérations. Sauvegarde et comparaison avant correction, pour ne pas casser la preuve.
Le piège consiste à choisir un outil unique, puis à le suivre comme une vérité absolue.
Comment interpréter les résultats sans tomber dans le piège du “tout supprimer”
Quand un scanner liste des fichiers suspects, vous avez souvent plusieurs niveaux de certitude. Les cas les plus dangereux sont ceux où:
- le scanner marque un fichier “core” ou un fichier chargé très tôt, le site montre un comportement actif (redirections, contenu injecté), les logs montrent un accès au fichier au moment où le site se dégrade.
Dans ces situations, la suppression et le remplacement par une version saine est généralement justifié. Mais même alors, je recommande de garder une copie des fichiers incriminés, pour analyse post-mortem.
À l’inverse, si le scanner remonte un fichier isolé et que l’analyse montre une absence d’exécution et une cohérence avec un déploiement, vous gagnez à investiguer avant d’intervenir.
Le coût d’un “nettoyage hâtif” est celui d’une récidive silencieuse, surtout si la vraie cause se situe ailleurs, par exemple dans un compte compromis ou une clé d’accès exposée.
Cas particuliers: hébergement, environnements et déploiements
Il y a des pièges spécifiques aux environnements modernes:
- Un pipeline de déploiement qui génère des fichiers à la volée peut déclencher des alertes. Un CDN ou un WAF peut changer l’ordre des requêtes et masquer la corrélation. Certaines extensions de sécurité ont des mécanismes de protection qui ressemblent à du code intrusif.
Je travaille avec ce contexte plutôt que contre lui. Par https://gardewp.fr/ exemple, si vous avez déployé un nouveau plugin juste avant l’apparition du problème, je ne pars pas en guerre contre le nouveau plugin sans vérifier l’exécution réelle. Je compare les dates, puis je lis le code des zones activées.
Dans un incident réel, c’est souvent le moment où l’on comprend le calendrier du déploiement qui fait gagner le plus de temps.
Après nettoyage: vérifier que la faille de fond est fermée
Le nettoyage ne se termine pas quand les pages “infectées” semblent redevenir normales. Le vrai travail commence quand vous vérifiez l’absence d’exécution.
Je fais généralement trois vérifications:
- le site ne génère plus les comportements observés (redirection, injection, anomalies), les fichiers suspects n’ont plus leur code actif, côté WordPress, aucun compte ou option anormale ne subsiste.
Ensuite, je regarde la sécurité d’accès: mots de passe, 2FA si possible, durcissement de l’accès admin, et mise à jour des plugins. Parce qu’un malware qui revient est souvent un symptôme d’une porte d’entrée encore ouverte.
Un mot sur la communication et la décision interne
Si vous êtes dans une organisation, il y a souvent une tension entre “remettre en ligne vite” et “comprendre exactement”. Mon approche vise à protéger les deux.
On peut reprendre le service en urgence, mais en conservant les preuves et en planifiant une analyse approfondie. Une intervention propre évite de faire revivre l’énigme à chaque récidive.
Ce qui fait la différence, c’est la traçabilité: ce qui a été supprimé, ce qui a été remplacé, pourquoi, et quels symptômes ont cessé.
Si vous voulez une règle simple pour rester efficace
Quand vous utilisez un scanner malware WordPress, gardez cette règle en tête: chaque alerte doit être reliée à une conséquence observable ou à un mécanisme d’exécution plausible.
Si vous ne pouvez pas relier, vous n’avez pas forcément un malware, vous avez peut-être un bruit. Si vous pouvez relier, vous avez une piste crédible, et vous pouvez décider avec plus de confiance.
Si vous me décrivez votre situation (hébergement, type de symptômes, ce que le scanner a signalé comme fichiers ou chemins, et si vous avez des logs), je peux vous proposer une méthode d’analyse plus ciblée sur votre cas, sans vous faire perdre de temps sur des suppositions.
