Renforcer la sécurité WordPress : scanner malware (méthode et conseils)

Quand un site WordPress se met à agir bizarrement, on n’a pas besoin d’imagination pour comprendre le risque. Un plugin qui “disparaît”, des pages qui redirigent vers une autre URL, des publicités qui apparaissent nulle part, une baisse brutale de trafic ou des alertes Google Search Console. Dans ces moments-là, scanner le malware n’est pas un geste de curiosité, c’est une enquête technique avec un objectif simple: retrouver ce qui a été modifié, comprendre comment ça a été injecté, puis fermer la porte avant que l’attaque ne recommence.

Ce billet explique une méthode réaliste pour scanner un site WordPress, avec des conseils concrets, des limites à connaître, et les décisions à prendre selon votre situation.
D’abord, clarifier le type de problème
Le mot “malware” regroupe plusieurs scénarios. Tous ne se traitent pas pareil, et un scanner ne vous donnera jamais une vérité totale à lui seul.

Un cas fréquent, ce sont des charges malveillantes côté serveur: fichiers PHP modifiés, scripts injectés dans des thèmes ou dans des plugins, tâches planifiées (cron) qui déposent d’autres fichiers, ou encore des connexions sortantes vers des domaines compromis.

Un autre scénario est plus “discret”: la compromission vient d’un compte administrateur, mais le contenu malveillant est surtout côté base de données. Là, le scanner peut repérer des URLs suspectes, des signatures connues ou des changements de templates, mais il faut aussi vérifier l’historique des utilisateurs, les rôles, et les contenus.

Enfin, il existe les faux positifs. Un thème qui embarque un script de tracking peut être déclaré “suspect” par certains outils, surtout s’il est obfusqué. De même, certaines optimisations de performance peuvent changer des fichiers, et les scanners les remarquent. L’enjeu est de distinguer une modification bénigne d’une modification réellement malveillante, même si le scanner met un drapeau rouge.
Préparer le terrain avant de lancer des scans
L’erreur classique consiste à lancer un scan “en direct” sur un site qui subit déjà une charge anormale, puis à agir dans la précipitation. Le résultat: vous démultipliez le volume de requêtes, vous alourdissez le serveur, et vous perdez du temps à tenter de “réparer” sans base de comparaison.

Le bon réflexe est de figer la situation au maximum.
Commencez par prendre une sauvegarde complète, base de données et fichiers. Si possible, dupliquez le site en staging (copie serveur ou clone local). Vérifiez les logs d’accès et d’erreurs sur la période de suspicion. Notez l’heure approximative du début du problème, ainsi que les symptômes observés (redirection, modification de pages, emails sortants, etc.).
Même si vous ne pouvez pas faire un clone, un simple snapshot ou une copie des https://gardewp.fr/securite-wordpress/ https://gardewp.fr/securite-wordpress/ dossiers du site et une exportation de la base de données font gagner un temps précieux, surtout pour comparer “avant” et “après”.
Choisir la bonne approche de scan: plugin, signatures, analyse de fichiers, et configuration
Sur WordPress, un malware peut se cacher à plusieurs endroits: fichiers du cœur, thèmes, plugins, uploads, base de données, configuration serveur, et parfois même dans des scripts qui tournent via cron.

Aucun outil ne couvre tout avec la même fiabilité. En pratique, je combine presque toujours quatre axes:

1) Un scan “automatique” qui repère des signatures connues et des incohérences basiques. 2) Une analyse de cohérence sur les fichiers, fichiers manquants, fichiers modifiés, empreintes inhabituelles. 3) Une vérification des utilisateurs et des modifications dans l’administration. 4) Un contrôle des traces d’exécution, logs et cron, pour comprendre comment l’injection a été déclenchée.

Le plugin n’est pas inutile. Il accélère le repérage. Mais il ne remplace pas une lecture technique quand il y a un doute, surtout si l’attaque est récente ou si elle est personnalisée.
Méthode de scan avec comparaison des fichiers (le plus fiable pour les injections PHP)
Beaucoup d’infections se résument à une modification de fichiers: un fichier PHP dans un thème, un plugin, ou un script dans la racine du site. La façon la plus robuste de les détecter, c’est de comparer l’état actuel avec un état attendu.

Concrètement, sur WordPress vous pouvez:
comparer votre installation avec une version propre du même WordPress (même branche, idéalement même version); comparer vos thèmes et plugins avec leurs sources officielles, au moins pour identifier si un fichier est modifié alors qu’il ne devrait pas l’être; repérer les ajouts de fichiers dans des répertoires inattendus, notamment des dossiers cachés, des fichiers nommés de manière banale, ou des scripts obfusqués.
L’idée n’est pas d’être parfait, c’est d’être pragmatique. Si un scan dit “suspect” et que vous constatez qu’un fichier a été modifié à l’heure de l’incident, la probabilité grimpe fortement.
Comment interpréter un résultat “suspect” sans se tromper
Quand un outil signale un fichier, il vous donne souvent une signature ou un indicateur. Le piège, c’est de croire que tout indicateur implique une compromission active. Certains plugins ajoutent des minifiers, des fichiers d’autoload, ou des scripts qui peuvent déclencher des heuristiques.

Mon test mental est simple: “Ce fichier a-t-il une raison d’être là, et son contenu est-il cohérent avec sa fonction déclarée ?”

Si vous voyez un fichier PHP dans un endroit où aucun plugin ne devrait écrire, si l’extension n’est pas celle attendue, ou si le code contient de l’obfuscation lourde et des appels à des fonctions de chargement dynamique ou d’exécution, vous avez une piste sérieuse. Si, au contraire, vous avez un fichier de cache ou un artefact de minification, il se peut que ce soit un changement normal.

Pour trancher, je privilégie la comparaison de contenu. Les signatures peuvent mentir, la cohérence avec l’installation, elle, vous pousse à la vérité.
Scan des plugins et thèmes: regarder les écarts, pas seulement les signaux
Les plugins et thèmes sont le terrain le plus probable, mais aussi le plus “bruyant”. Un plugin peut être compromis, ou un plugin peut contenir du code obfusqué pour des raisons de performance. Les thèmes peuvent inclure des fragments qui ressemblent à du code malveillant, surtout si vous avez des scripts publicitaires ou des intégrations marketing.

La stratégie que j’utilise consiste à réduire le champ. Plutôt que de tout inspecter à la loupe, je commence par les éléments récemment modifiés:
fichiers ayant un timestamp récent; fichiers qui contiennent des chaînes de caractères inhabituelles (URLs, paramètres de requêtes, appels à des fonctions sensibles); fichiers chargés très tôt dans la page, notamment via require, include, ou actions d’amorçage.
Si vous avez accès à un gestionnaire de fichiers ou à un client SFTP, vous pouvez aussi regarder la structure des dossiers. Un malware aime créer des “chemins de passage”: un petit fichier qui charge un autre script, puis un script qui télécharge une charge distante. Dans ce schéma, le fichier principal peut paraître presque inoffensif, et c’est le fichier chargé ensuite qui fait tout. D’où l’importance de suivre le fil d’exécution dans les includes.
Le piège de la “désinstallation” qui ne résout rien
Si un plugin est compromis, le supprimer de l’interface ne suffit pas toujours. Il peut avoir laissé des traces:
dans des fichiers persistants ailleurs que dans son dossier; dans la base de données (options, meta, shortcodes); dans des tâches cron ou des entrées planifiées; dans des comptes utilisateurs ou des rôles modifiés.
Donc, même après suppression, je conserve l’idée de faire un audit sur les fichiers et la base de données, au moins sur la période suspecte.
Scanner la base de données: utilisateurs, options, contenus et injections
Quand la compromission passe par l’administration, les traces sont souvent dans la base de données. Là aussi, le scan automatique peut donner des indices, mais la structure change selon les thèmes, les plugins et les versions.

Les vérifications qui m’ont le plus souvent fait gagner du temps:
vérifier les utilisateurs administrateurs, surtout ceux ajoutés récemment; chercher des rôles ou des comptes qui n’étaient pas là avant; vérifier les options et paramètres qui stockent des URLs externes ou des scripts; inspecter les contenus qui affichent des redirections, des iframes, ou des fragments “automatisés”.
Un détail pratique: un site peut continuer à “fonctionner”, tout en étant compromis. Les injections peuvent viser la génération de pages spécifiques, ou être activées seulement sous certaines conditions. C’est pour ça que les recherches dans la base (par exemple sur des morceaux de scripts ou des fragments d’URL) peuvent être plus efficaces que de parcourir page par page.

Si vous devez faire une recherche, privilégiez les motifs qui reviennent dans vos symptômes. Par exemple, si le site redirige vers une URL connue, cherchez ce domaine dans les options et les contenus. Si vous voyez un comportement de “magazine” ou de “spam de contenu”, cherchez des titres générés automatiquement ou des champs meta anormaux.
Vérifier la configuration serveur: cron, réécritures, et exécution
Sur WordPress, la configuration serveur et le cron sont souvent des moteurs de persistance. Un malware peut déposer un script “discret” et le déclencher toutes les minutes.

C’est un point qui est parfois sous-estimé: même si vous nettoyez les fichiers web, une tâche planifiée peut réinjecter du code.

Selon votre hébergement, vous pouvez vérifier:
la présence de tâches cron anormales; les erreurs et logs au moment où des modifications apparaissent; des réglages du serveur qui permettent l’exécution de scripts depuis des dossiers inattendus.
Sur un WordPress “standard”, beaucoup de gens inspectent seulement wp-content, mais le déclencheur peut être ailleurs. Si vous observez une récurrence rapide des symptômes après nettoyage, c’est le signal numéro un.
Analyse des logs: l’enquête qui complète le scan
Un scanner malware vous dit “voici ce qui semble modifié ou suspect”. Les logs vous disent “voici comment c’est arrivé”.

Même des logs simples peuvent être très utiles. En général je regarde:
les tentatives de connexion, notamment sur des comptes administrateurs ou sur des plages horaires qui coïncident avec le début de l’incident; les requêtes qui ciblent des fichiers inhabituels, par exemple des endpoints qui ne font pas partie de votre site; des erreurs 404 ou 500 répétées sur des chemins étranges.
Si votre hébergeur affiche un filtrage ou des alertes WAF, c’est aussi une source intéressante, à condition de ne pas vous y enfermer. Un WAF peut bloquer certains patterns, mais laisser passer d’autres comportements, surtout si l’attaque est “adaptée” au site.
Nettoyer proprement: corriger, puis reconstruire les zones à risque
Le nettoyage est l’étape où beaucoup d’administrateurs se font piéger. On supprime les fichiers identifiés comme “infectés” et on recharge le site, puis le malware revient. La raison est souvent une variante qui a été laissée derrière, ou une persistance via la base de données ou un cron.

J’ai une règle de travail: si j’ai de gros doutes et que l’infection semble “active”, je préfère reconstruire les éléments concernés avec une version propre, plutôt que de bricoler au cas par cas.

Voici comment je procède le plus souvent après le scan, en restant pragmatique.
Remplacer WordPress core par une version propre, même si le scan ne le dénonce pas. Réinstaller en propre les thèmes et plugins critiques (ceux utilisés ou installés récemment au moment des symptômes). Supprimer les comptes utilisateurs ajoutés pendant la période suspecte, puis forcer une réinitialisation de mot de passe pour les comptes restants. Rechercher et corriger les entrées anormales dans la base de données (options, schedules, contenus injectés). Contrôler et supprimer les tâches cron suspectes, puis surveiller les logs après remise en ligne.
Le trade-off est clair: reconstruire prend du temps, mais c’est plus fiable que la réparation “au millimètre” quand l’infection est avancée.
Mettre en place une surveillance après nettoyage (pour éviter la récidive)
Une fois le site “remis en état”, la question n’est pas seulement “est-ce que ça marche ?”. C’est “est-ce que quelqu’un peut réamorcer facilement ?”.

Je recommande une surveillance ciblée. Par exemple, si vous avez observé une injection PHP, la surveillance peut viser les changements de fichiers. Si le vecteur principal était un compte, la surveillance peut viser les connexions et la création de comptes.

Côté WordPress, la configuration de sécurité gagne aussi à être cohérente:
mots de passe robustes, idéalement uniques; contrôle des rôles, retirer ce qui n’a pas de raison d’être; limitation des tentatives et durcissement de l’authentification; mises à jour régulières des plugins et thèmes, pas seulement du cœur.
J’ai vu des cas où le malware partait, puis revenait parce qu’un plugin de formulaires non mis à jour était le vecteur. Dans ce contexte, “nettoyer” sans “verrouiller” revient à repeindre un mur fissuré sans colmater.
Conserver des preuves: utile pour comprendre, utile pour ne pas perdre de temps
Pendant une enquête, il est tentant de supprimer vite. Mais garder des preuves aide énormément, surtout si vous devez revenir sur des décisions.

À minima, conservez:
une copie des fichiers infectés ou suspects avant suppression; une exportation de la base de données avant nettoyage si possible; un relevé des résultats du scan (fichiers pointés, signatures, timestamps).
Même si vous ne traitez pas un incident de façon formelle, cette trace réduit le risque de “chercher dans le mauvais sens”. Elle permet aussi de prouver à un prestataire ou à votre hébergeur ce qui s’est passé.
Edge cases: quand le scan n’est pas suffisant
Il y a des situations où le scan vous donnera l’impression que tout est “clean” alors que le site continue d’être affecté.

Exemples concrets que j’ai rencontrés:
L’infection est ailleurs que dans l’instance WordPress. Le code malveillant se trouve dans un service externe, une redirection via DNS, ou un système tiers (CDN, gestionnaire d’assets, plugin SaaS). Un script malveillant n’est pas dans un fichier PHP modifié, mais dans des paramètres, options, ou contenus injectés dynamiquement. Le problème est un compromis partiel: une page ou un template spécifique est corrompu, et le scanner fait un passage qui rate un dossier ou ne suit pas les includes.
Dans ces cas, la méthode doit redevenir une enquête. Les symptômes guident l’endroit où chercher. Si le site redirige seulement sur une URL, la base de code dans cette zone est probablement le point de départ, même si l’outil n’y voit rien.
Conseils pratiques pour gagner du temps pendant un incident
Le scan malware est un outil, pas un juge. Pour qu’il soit vraiment utile, il doit être suivi par une logique de tri.

J’ai appris à ne pas “tout nettoyer” au hasard. Je préfère:
isoler le périmètre suspect (période, fichiers modifiés, utilisateurs ajoutés); vérifier les mécanismes de persistance (cron, options, comptes); reconstruire ce qui est trop risqué plutôt que d’espérer que la modification “enlevée” suffit.
Il y a aussi un volet organisation. Pendant une crise, le plus grand ennemi, c’est le flou. Définissez un plan minimal, même si vous êtes seul:
moment où vous lancez les scans; qui a accès au site; ce que vous changez, et ce que vous ne changez pas avant d’avoir les preuves.
Quand vous travaillez proprement, vous réduisez les chances d’effacer le signal avant de l’avoir compris.
Méthodes de scan: résumé opérationnel (sans dépendre d’un seul outil)
Si je devais résumer une méthode robuste, elle ressemblerait à ceci en logique, pas en commandes:

Vous démarrez avec un scan automatique pour obtenir des indices. Ensuite, vous comparez les fichiers et vous cherchez les écarts, surtout côté thèmes, plugins et racine. Vous inspectez les utilisateurs et la base de données pour les changements “de logique” et pas seulement “de code”. Vous vérifiez cron et les logs, car c’est souvent la persistance qui fait échouer le nettoyage. Puis vous reconstruisez ou remplacez proprement les éléments à risque, et vous surveillez le comportement après remise en ligne.

Ce qui fait la différence, c’est la combinaison. Un scanner seul, même excellent, ne remplace pas la comparaison et le suivi des traces.
Se renforcer durablement: sécurité WordPress après l’incident
Le scanner malware peut vous sauver pendant une attaque, mais le renforcement sécurité WordPress se joue sur la prévention et la réduction de surface.

Après un incident, je conseille généralement de traiter trois zones: accès, intégrité, et mise à jour.

L’accès, c’est l’authentification solide et la réduction des rôles. L’intégrité, c’est le fait de savoir quels fichiers doivent exister et lesquels ne doivent pas changer. La mise à jour, c’est garder les plugins et thèmes à jour, et éviter les installations “dormantes” qui ont pu être exploitées sans que vous le remarquiez.

Vous ne pouvez pas rendre WordPress invulnérable. En revanche, vous pouvez rendre une compromission difficile, bruyante, et surtout réversible sans panique.

Si vous prenez une seule habitude, faites-la simple: avant même que ça tourne mal, gardez une base de comparaison et des sauvegardes exploitables. Quand un malware arrive, vous ne voulez pas improviser un puzzle avec des pièces déjà jetées. Vous voulez diagnostiquer vite, nettoyer proprement, puis surveiller pour confirmer que le problème est réellement parti.