Scanner malware WordPress : les indicateurs à surveiller après une tentative d’attaque

Après une tentative d’attaque sur un site WordPress, la première question n’est pas “est-ce que l’attaque a réussi ?”, mais plutôt “qu’est-ce que l’attaquant a pu laisser derrière lui ?”. Même quand le site semble intact, certains éléments restent en place, subtils, et assez longtemps pour que le problème revienne. J’ai vu des cas où l’admin ne “voyait” rien, puis deux jours plus tard les requêtes explosaient, ou un faux plugin finissait par rediriger les visiteurs.

Un point essentiel: les signaux d’alerte ne se limitent pas aux fichiers ou aux pages visibles. On doit surveiller l’environnement d’exécution, la base de données, le comportement du serveur, et la façon dont le site “répond” quand on le met sous contrainte (pics de charge, URLs spécifiques, utilisateurs précis). Voici les indicateurs les plus utiles à observer après une tentative d’intrusion, surtout si vous avez lancé un scanner malware WordPress ou si vous avez reçu des alertes de type blocage par navigateur, signalements de Google, ou notifications de votre hébergeur.
D’abord, comprendre ce qu’on peut vraiment conclure
Quand on fait tourner un scanner malware WordPress, il peut donner une photo partielle. Selon l’outil et sa méthode, il détectera surtout des motifs connus: noms de fichiers suspects, signatures de code, schémas de webshell, patterns d’obfuscation ou modifications attendues par des règles. Mais une tentative d’attaque peut aussi viser autre chose que le “code à détecter”.

Dans les incidents que je traite le plus souvent, l’erreur classique consiste à conclure trop vite: “le scan est vert, donc tout est propre”. Or un attaquant expérimenté peut laisser un mécanisme dormant, un accès de contournement, ou une modification qui ne déclenche rien avant qu’un événement précis ne survienne (jour, heure, type de visiteur, référent, agent utilisateur).

La bonne posture consiste à considérer le scan comme un déclencheur d’enquête, pas comme un verdict final. On cherche des traces convergentes: cohérence entre ce qu’on a détecté, ce qu’on observe dans les logs, et ce qu’on constate sur le site.
Les signaux côté WordPress, ceux qui reviennent presque à chaque fois
Dans WordPress, la surface de compromis la plus fréquente se situe autour des identifiants, des capacités de l’utilisateur, et de la configuration. Les attaques peuvent être “brutes” (mot de passe deviné ou volé) ou plus fines (création d’un nouvel utilisateur, élévation de rôles, modification de thèmes ou de plugins).
Comptes et rôles : l’indicateur le plus révélateur
Quand une attaque commence par l’accès, elle laisse souvent un compte “témoin”. Ce n’est pas toujours un nouvel utilisateur visible, parfois c’est un compte existant qui a été réutilisé après vol, ou un rôle renforcé. Un autre scénario très courant: l’attaquant crée un utilisateur avec un rôle administrateur ou éditeur, puis supprime certaines traces, notamment les fichiers de log.

Après une tentative, je surveille systématiquement:
la liste des utilisateurs, y compris ceux avec des dates de création récentes, les rôles actuels, même si l’utilisateur “existe depuis longtemps”, les changements d’e-mail, les modifications de profil, et les actions associées (publications, réglages), les nouveaux thèmes ou plugins installés, activés ou importés.
Le détail qui fait gagner du temps: regarder les dates de création et les activités associées, puis croiser avec la fenêtre temporelle de l’alerte. Si votre alerte de tentatives d’attaque tombe à 03:12 UTC, un utilisateur créé à 03:14 local (ou 03:12 dans le fuseau serveur) mérite une attention immédiate.
Plugins et thèmes : présence inattendue et modifications
Les scanners malware WordPress détectent souvent des plugins ou des fichiers modifiés, mais l’attaque peut aussi laisser un thème modifié, ou un plugin légitime remplacé partiellement.

Deux comportements sont typiques:

1) Le code “additionnel” n’est pas forcément dans un fichier totalement nouveau. Parfois, c’est une petite portion injectée dans un endroit banal, par exemple un fichier chargé au démarrage, une fonction de template, ou une partie qui manipule des paramètres de requête.

2) Un plugin peut sembler présent mais sans logique évidente. Ce qui compte alors, c’est l’intégrité: dates de modification, taille du fichier, et cohérence avec la version attendue.

Si vous avez accès à la gestion de fichiers de l’hébergement ou au dépôt du code, comparez la liste des fichiers modifiés à la version de base que vous aviez avant l’incident. À défaut, l’historique Git ou la sauvegarde la plus proche du moment de l’alerte devient votre point d’ancrage.
Indicateurs dans la base de données : quand le site “passe” au scan mais reste dangereux
WordPress stocke beaucoup de choses en base. Un attaquant peut y déposer des chaînes de caractères, des options anormales, des entrées injectées dans des champs qui ne semblent pas critiques, ou des paramètres qui pilotent des actions cachées. Certains scanners se concentrent sur les fichiers, donc la base peut rester un angle mort.

Voici ce que je regarde en priorité après tentative d’attaque:
des options WordPress modifiées, surtout celles liées à l’exécution, au chargement de contenu, ou à la redirection, des tables qui contiennent des valeurs incompréhensibles ou longues, souvent avec du code ou des marqueurs d’obfuscation, des entrées liées à des formulaires, à la planification (cron), ou à des shortcodes si vous en utilisez, des changements sur les tables liées aux utilisateurs et à leurs métadonnées.
Je n’encourage pas à “hacker la base” à l’aveugle. La base est sensible, et casser une relation ou une option peut provoquer des symptômes difficiles à reproduire. Mais si vous avez une sauvegarde antérieure, la comparaison ciblée des options et des métadonnées est un bon levier.
Les logs: là où la réalité se révèle
Le plus gros gain après une tentative d’attaque, c’est de lire vos logs avec un objectif clair. Un scan vous dit “voici ce que je vois”. Les logs vous disent “voici ce qui s’est réellement passé”.

Pour un site WordPress exposé au web, les signaux pertinents se situent dans:
tentatives de connexion (auth échouées, IP récurrentes), accès à des endpoints inhabituels, erreurs 403, 404, 500 en rafale, pics de trafic, pattern d’URLs, et requêtes qui déclenchent des réponses anormales, comportement de PHP (fatals, erreurs de syntaxe, temps de réponse élevés).
Un exemple concret: j’ai déjà vu un site “propre” au niveau fichiers, car le code malveillant avait été déposé puis retiré. Pourtant, les logs montraient des requêtes répétées vers des chemins de type “upload” et “include” avec des paramètres cohérents, suivies de 200 sur une ressource cachée. Le scanner n’avait rien à détecter parce que la charge avait été retirée. Les logs, eux, gardaient la trace.

Si vous ne savez pas encore quelles lignes consulter, partez de l’horodatage de l’alerte, élargissez de quelques heures autour, puis cherchez les répétitions: même IP, mêmes requêtes, même taille de réponse, mêmes codes HTTP.
Signaux côté navigateur et SEO: quand le problème devient visible pour les visiteurs
Les attaques de type redirection, injection de liens, ou substitution de contenu se remarquent souvent via des signaux externes. Même si vous ne recevez pas de plaintes, votre trafic et vos pages changent.

Après tentative, surveillez:
des variations de pages vues sur des URL qui n’ont rien à voir avec vos contenus, des retours inhabituels dans la Search Console (si vous l’utilisez), des avertissements de sécurité dans les navigateurs de test, ou des blocages par réputation, des différences de contenu entre un navigateur “normal” et un navigateur en mode privé, ou entre des agents utilisateur distincts.
Un piège fréquent: l’injection est conditionnelle. L’attaquant peut servir un contenu différent selon l’IP, le pays, le référent, ou l’agent utilisateur. C’est pour cela que tester “en local” ne suffit pas. Un simple test avec votre IP ne reproduit pas toujours le comportement réel d’un visiteur exposé.

Un conseil pragmatique: testez depuis plusieurs contextes. Si vous travaillez au bureau, testez aussi depuis votre réseau mobile. Si votre hébergeur a un pare-feu applicatif, testez en contournant ou en variant les chemins, au moins pour vérifier que les redirections conditionnelles ne reviennent pas.
Le comportement serveur: latence, charge, et erreurs PHP
Après une tentative, le site peut paraître fonctionnel mais devenir instable. L’attaquant peut installer un mécanisme qui consomme des ressources, ou déclencher un traitement lourd sur certains appels. Cela se voit rarement dans l’interface WordPress, mais souvent dans les métriques serveur.

Indicateurs à surveiller:
augmentation du nombre de requêtes par minute, hausse des erreurs 500 et de certains codes 403, temps de réponse anormalement élevés sur des URLs spécifiques, pics d’utilisation CPU ou mémoire au moment où les requêtes suspectes arrivent, répétition d’erreurs PHP liées à des fichiers spécifiques.
Si vous avez accès aux métriques, notez le moment où l’alerte a eu lieu, puis observez la distribution des temps de réponse. Quand le problème est “caché”, il se révèle souvent dans des sous-ensembles de trafic. Par exemple, seules certaines requêtes déclenchent une redirection, ou seules certaines requêtes exécutent une boucle.
Le rôle du “scanner” et ses limites, pour éviter les faux sentiments de sécurité
Revenons sur le scanner malware WordPress, puisque c’est souvent le premier geste. Les scanners sont utiles, mais je les traite comme un rapport de triage.

Le point d’attention numéro un: les faux négatifs. Un scan peut ne pas détecter du code qui n’a pas de signature connue, ou des modifications qui ne matchent pas les règles de l’outil. Par exemple, une charge obfusquée peut varier de façon suffisante, même si l’intention est la même.

Le point d’attention numéro deux: les faux positifs. Un outil peut signaler une règle trop large. Dans ces cas, vous risquez de passer du temps sur des fichiers qui ne posent pas de problème, surtout si vous cherchez une “preuve” et non une piste.

Ce que je fais pour équilibrer: je prends la liste des éléments détectés, je les fais remonter à l’origine (date de modification, chemin, rôle dans WordPress), puis je croise avec les logs. Si un fichier est détecté mais jamais appelé dans les logs pendant la fenêtre de l’attaque, je m’interroge. Inversement, si les logs montrent un comportement clair mais que le scanner est silencieux, je creuse la base, le cron, et la configuration.
Indicateurs concrets que j’utilise pour prioriser les vérifications
Quand il y a urgence, il faut prioriser. Après une tentative d’attaque, toutes les vérifications n’ont pas la même valeur, et vous ne voulez pas casser votre site en changeant tout.

Je procède souvent dans cet esprit: d’abord ce qui donne un accès, puis ce qui redirige ou injecte, puis ce qui persiste.

Voici une grille de tri, courte, mais efficace:
Vérifier les utilisateurs récemment créés et les rôles qui ont changé autour de l’horodatage de l’alerte Contrôler la liste des plugins et thèmes ajoutés ou modifiés, en regardant la date de modification et l’activation réelle Examiner les entrées liées à l’exécution programmée (cron) et les options WordPress modifiées, surtout celles qui impactent le rendu ou des redirections Analyser les logs web et PHP sur la fenêtre de l’incident, en cherchant des requêtes répétitives et des URLs inhabituelles Tester un ensemble d’URLs sensibles depuis deux contextes de navigation, pour repérer une injection conditionnelle
Cette approche limite le temps perdu et évite de “réparer” des éléments qui ne sont pas impliqués.
Ce qui ressemble à une attaque, mais qui peut être autre chose
Il y a un vrai risque de sur-réaction. Certaines anomalies ressemblent à du malware WordPress, mais correspondent à des comportements légitimes ou à des erreurs de configuration.

Par exemple, une hausse de 404 peut venir d’un bot d’exploration, sans intention d’injection. Des utilisateurs créés peuvent venir d’un formulaire d’inscription activé, ou d’un script de test en production. Des plugins “nouveaux” peuvent provenir d’une mise à jour automatique ou d’un dépôt re-déployé.

La règle que j’applique: je https://gardewp.fr/ https://gardewp.fr/ cherche la cohérence. Si vous trouvez un nouvel utilisateur administrateur et des redirections dans les logs, la suspicion devient forte. Si vous trouvez juste un pico de 404 sans autres signaux, je creuse moins agressivement, et je vérifie d’abord l’origine.
Les “surprises” après nettoyage: persistance et angles morts
Même quand vous supprimez ce qui a été détecté, l’incident peut continuer sous une autre forme. Voici des angles morts que j’ai rencontrés, souvent après un premier nettoyage basé sur un scan:
un fichier malveillant supprimé, mais une option en base qui continue de piloter un comportement, un plugin “nettoyé” mais une dépendance compromise ailleurs, un compte réactivé via un accès persistant, après changement de mot de passe insuffisant (par exemple, l’utilisateur garde la même session ou un outil externe a encore accès), des règles WAF absentes, ce qui laisse l’attaquant revenir dès que la brèche est exploitée, un environnement d’hébergement modifié, par exemple paramètres PHP, ou scripts placés hors du scope WordPress.
C’est la raison pour laquelle je recommanderais de ne pas se contenter du moment “après le scan”. Faites une phase d’observation, avec des tests et des vérifications légères mais régulières pendant quelques jours.
Une approche de vérification après tentative, sans transformer votre site en chantier permanent
Une fois que vous avez réalisé un premier nettoyage ou confirmé l’absence de code évident, l’étape suivante consiste à vérifier que rien ne se réactive. Cela demande des tests ciblés, pas une refonte.

Je recommande de surveiller pendant 48 à 72 heures, avec une vigilance particulière sur les mêmes patterns de trafic observés pendant la tentative. Si votre hébergeur affiche un nombre de requêtes par minute, observez la stabilité. Si vous voyez des pics qui ressemblent à l’attaque, il faut traiter cela comme un signal, même si les pages semblent “normales”.

Pour les tests, je privilégie des actions qui déclenchent le rendu ou des zones sensibles:
pages publiques qui affichent des contenus dynamiques, formulaires d’authentification, zones où des scripts sont chargés, URLs qui ont généré des réponses anormales dans vos logs.
Vous n’avez pas besoin de tout parcourir à la main. Le but est de repérer une redirection, une injection, ou une erreur conditionnelle.
Quand il faut aller plus loin que WordPress
Parfois, l’attaque n’est pas confinée à WordPress. Un scanner malware WordPress peut détecter des fichiers dans l’arborescence, mais d’autres traces peuvent exister dans l’environnement:
fichiers déposés dans des répertoires non attendus, tâches cron système, clés ou configurations d’accès modifiées, exécution de scripts en dehors de WordPress.
Si votre hébergeur a des outils de surveillance ou des notifications de modification de fichiers, utilisez-les. Si vous gérez vous-même l’infrastructure, vérifiez les composants système autour de la période de l’attaque. Le “malware” est parfois une combinaison, WordPress étant seulement la porte d’entrée.
Deux scénarios typiques et les indicateurs à surveiller dans chacun Scénario A: attaque par mot de passe, succès partiel
Dans ce cas, l’indicateur central est WordPress, notamment l’apparition de nouveaux utilisateurs ou des rôles modifiés. Ensuite, l’attaquant cherche à maintenir un accès et à semer une charge. Les scanners détectent parfois des fichiers, mais pas toujours.

Après tentative, je surveille fortement l’évolution des rôles, les plugins activés, et les changements d’options autour de l’heure. Je vérifie aussi les logs de connexion, car c’est souvent là que la première alerte devient claire: des tentatives répétées depuis des IP similaires, puis une authentification réussie.
Scénario B: injection de contenu conditionnelle
Ici, vous pouvez avoir des fichiers peu suspects, voire absents des scans. Le site peut sembler identique dans votre navigateur pendant des jours, puis la charge apparaît chez certains visiteurs.

Après tentative, les logs et les tests de navigation conditionnelle deviennent prioritaires. Un signal clé: des réponses différentes sur des URLs spécifiques, ou des erreurs ponctuelles qui ne suivent pas votre trafic habituel. Je compare aussi la sortie HTML de pages sensibles entre deux contextes (IP différente, agent différent). Quand ça varie de façon inexplicable, je sais que je dois creuser, même si le scanner est plutôt “rassurant”.
Ce que je ferais “maintenant”, si vous me décriviez votre situation
Je ne peux pas voir votre serveur, donc je ne peux pas vous dire quoi supprimer exactement. Mais je peux vous donner un plan d’action raisonnable, centrée sur les indicateurs.

Si vous avez déjà lancé un scanner malware WordPress, gardez son rapport comme fil conducteur, puis vérifiez:
que les éléments détectés correspondent à des modifications datées et documentées, que les logs confirment que les chemins détectés ont été touchés pendant l’incident, que les utilisateurs et les rôles n’ont pas bougé au mauvais moment, que la base de données ne contient pas d’options ou chaînes inhabituelles qui pilotent un comportement.
Si vous ne savez pas par où commencer, voilà l’ordre de priorité qui m’a le plus souvent évité des heures de recherche: d’abord accès et persistance (comptes, rôles, planification), ensuite injection et redirection (plugins, thèmes, contenu), enfin environnement (cron et fichiers hors WordPress).

Et si vous devez choisir entre corriger “tout” et corriger “le plus probable”, corrigez ce qui donne un retour immédiat dans vos logs et vos tests. Le reste se fait ensuite, avec une approche incrémentale.
Indicateurs de fin d’incident: comment savoir que le danger s’éloigne
Une fois les actions menées, le confort ne vient pas d’un simple “scan terminé”. Il vient d’une convergence d’observations:
les tentatives suspectes cessent ou diminuent fortement, les mêmes URLs anormales n’apparaissent plus en rafales, les utilisateurs, rôles et activations de modules restent stables, les pages testées ne montrent plus d’écarts entre contextes de navigation, les métriques serveur redeviennent cohérentes avec votre trafic habituel.
Je garde aussi une règle simple: si des symptômes reviennent après quelques jours, considérez que la cause n’a pas été entièrement traitée. Les attaquants aiment les mécanismes qui reviennent sous des conditions précises. Le fait que “ça marche” à un instant ne signifie pas que tout est fini.

Si vous avez besoin de produire un diagnostic exploitable, je peux vous aider à interpréter vos traces si vous me décrivez, sans données sensibles, ce que le scanner malware WordPress a signalé, quelles dates correspondent à la tentative, et quels logs montrent des patterns anormaux. On peut alors transformer des signaux dispersés en hypothèses testables, puis en décisions concrètes.