Quand on soupçonne un site WordPress d’être compromis, on a vite fait de se focaliser sur la façade. Le visiteur voit une redirection étrange, une page “plantée”, des fenêtres qui s’ouvrent toutes seules. Mais côté serveur, l’histoire est souvent plus lisible, plus technique, et surtout plus exploitable. Les indicateurs ne crient pas toujours “piratage”, ils parlent en signaux: des comportements anormaux, des traces dans les journaux, une usure inhabituelle du système, et des incohérences entre ce que WordPress fait normalement et ce qu’il fait maintenant.
Je vais prendre le sujet sous l’angle “côté serveur”, parce que c’est là que vous pouvez confirmer, dater, et parfois remonter à l’origine. L’objectif n’est pas seulement de “nettoyer”, mais de comprendre ce qui s’est passé pour éviter la récidive.
Ce que signifie vraiment “site WordPress infecté”
Un site WordPress infecté, ce n’est pas uniquement du malware visible. La plupart des incidents que j’ai vus commencent par un détail discret: un plugin ou un thème modifié, un fichier ajouté dans un répertoire inattendu, un utilisateur WordPress créé à la volée, ou une modification de configuration qui permet une exécution de code.
Le plus déroutant, c’est que l’impact peut être diffus. Un site peut continuer à charger des pages normales, tout en injectant du JavaScript malveillant à certaines conditions, en redirigeant certains navigateurs, ou en déposant une charge utile sur les formulaires. Dans ces cas, le “symptôme” n’est pas constant, ce qui rend l’observation côté serveur essentielle.
Côté technique, on rencontre souvent trois grands scénarios.
Le premier ressemble à de la persistance “propre”: un attaquant injecte une fonction dans un thème, modifie un plugin, ou ajoute du code dans un fichier PHP jamais touché depuis des mois. Le site reste “vivant”, mais le code malveillant s’active selon des règles.
Le second est plus brut: des backdoors déposées dans l’arborescence, des scripts dans des dossiers temporaires, ou des fichiers cachés. Là, les logs et les timestamps deviennent des indices puissants.
Le troisième ressemble à un détournement via la configuration: mauvaise gestion des droits sur certains fichiers, accès SSH avec clés compromises, base de données modifiée, ou serveur mal durci. On ne voit https://gardewp.fr/nettoyage-malware-wordpress/ pas toujours une “infection” au sens strict, mais plutôt une porte d’entrée qui a permis l’incident.
Distinguer ces scénarios aide à orienter la recherche, car les indicateurs ne sont pas les mêmes.
Le point de départ pratique : figer l’état avant d’ouvrir tous les vannes
Avant de plonger dans les logs, prenez une décision simple: réduire le risque de détruire la preuve.
Sur un incident “site WordPress infecté”, la phase la plus coûteuse en temps, c’est souvent quand on nettoie trop vite, puis qu’on se rend compte qu’on a effacé ce qui permettait de comprendre comment l’attaque fonctionnait. Par exemple, si vous remplacez tous les fichiers WordPress par une version saine sans conserver une copie, vous pouvez perdre les différences exactes qui révèlent la méthode d’injection.
En pratique, vous voulez au minimum:
- une copie des fichiers modifiés (ou un snapshot si votre hébergeur le permet), une copie des journaux pertinents (au moins ceux qui couvrent la période suspecte), et un relevé de la configuration actuelle (PHP, extensions, directives serveur, cron, tâches planifiées, règles de filtrage).
L’idée n’est pas de ralentir, c’est de travailler avec un “cadre” pour être sûr que la suite d’actions ne brouille pas l’enquête.
Indicateurs côté serveur: où regarder quand WordPress est compromis
Les indicateurs les plus utiles ne viennent pas uniquement de WordPress. Ils se trouvent dans le système, le serveur web, les interpréteurs PHP, la base de données, et les mécanismes d’exécution planifiée.
Les logs du serveur web : le bruit utile
Les journaux d’accès du serveur web (Nginx ou Apache) révèlent parfois des motifs très spécifiques. Par exemple, des requêtes vers des fichiers PHP qui n’existent pas habituellement, des requêtes répétées sur des endpoints connus, ou des volumes d’accès atypiques.
Ce que je cherche en priorité:
- des requêtes vers des chemins sans rapport avec le site (ex: scripts “fourre-tout” ajoutés à la racine), des codes de réponse qui ne collent pas à vos habitudes (404 et 403 en masse peuvent indiquer une tentative de découverte), des pics en dehors des horaires “normaux”, une cohérence temporelle avec d’autres événements (changement de fichier, création d’utilisateur, augmentation CPU).
Il arrive aussi que l’attaquant masque l’activité côté web en limitant le trafic pour ne pas déclencher d’alertes. Dans ce cas, les logs d’erreur et les logs PHP sont parfois plus parlants.
Les logs PHP et les erreurs: l’activation du code
Si l’attaque repose sur l’exécution de code PHP malveillant, les logs PHP peuvent montrer des erreurs de syntaxe, des tentatives de lecture de fichiers, ou des signaux indirects d’exécution.
Même sans “erreurs” explicites, la présence de requêtes qui déclenchent des comportements non standards peut se repérer. Sur certains hébergements, les logs PHP sont limités ou désactivés. Dans ce cas, un contrôle via les niveaux de logging applicatif peut aider, mais attention aux effets secondaires (augmenter trop le logging peut générer du bruit, et parfois des latences).
Un point important: si vous activez temporairement le logging pour comprendre un incident, assurez-vous qu’il ne change pas le comportement du site au point de masquer le problème.
Les journaux système et la charge: quand le serveur “travaille” sans raison
Un site compromis peut provoquer une charge CPU ou disque inhabituelle. Les raisons sont multiples: exploitation, minage, exfiltration lente, génération de trafic, téléchargement de charges externes.
Sur Linux, des indicateurs comme les pics d’utilisation CPU, les écritures massives en I/O, ou l’apparition de nouveaux processus (souvent en arrière-plan) sont des signaux. Si vous avez accès aux logs système, cherchez l’horodatage. Les mêmes secondes ou minutes que vous observez dans les logs web peuvent correspondre à d’autres événements.
Ce n’est pas toujours une corrélation parfaite, mais quand elle existe, elle accélère l’analyse.
La “cartographie” des changements WordPress : fichiers, droits, et dates
Les logs vous montrent des événements, mais les fichiers vous donnent le contexte. Une approche réaliste consiste à comparer l’état actuel avec une référence saine. Si vous avez une sauvegarde antérieure à l’incident, c’est l’or.
À défaut, vous pouvez comparer les fichiers avec une installation WordPress connue (même version), ou au minimum contrôler ce qui a été modifié sur le serveur.
Dates de modification: utile, mais pas suffisant
Les timestamps des fichiers peuvent être trompeurs si l’attaquant a ajusté les métadonnées ou si le déploiement légitime a modifié les dates. Mais souvent, un motif ressort: un ensemble de fichiers modifiés à la même minute, ou une séquence d’écritures dans des répertoires “bizarres”.
Je prends aussi en compte les fichiers qui changent sans raison. Des téléchargements de thèmes ou plugins peuvent modifier de nombreux fichiers, donc il faut comparer “ce qui a bougé” avec ce qui a été prévu.
Droits et propriétaires: un indicateur trop souvent ignoré
Les permissions peuvent révéler une faiblesse structurelle. Par exemple, si des fichiers PHP sensibles sont en écriture par un utilisateur qui n’en a pas besoin, ou si des répertoires sont trop permissifs, l’incident a pu être facilité.
Sans juger trop vite, ce contrôle permet de comprendre la surface d’attaque. WordPress fonctionne, mais votre serveur n’est pas configuré pour limiter l’impact d’un compromis partiel.
Fichiers inattendus et charge utile: repérer les signatures comportementales
Dans les cas les plus simples, on trouve du code PHP ajouté, des fichiers avec des noms peu explicites, ou des scripts qui utilisent des fonctions système. Mais l’attaque peut aussi être “propre”: elle n’ajoute rien d’évident, elle modifie un endroit connu pour injecter du code lors du chargement.
Dans ce genre de situation, le diff d’un fichier thème ou d’un plugin est déterminant. Regardez:
- les ajouts de conditions basées sur des variables (nom d’hôte, IP, user agent), l’accès à des endpoints externes, des fonctions de chargement dynamique, la présence de base64, de gzinflate, ou de chaînes compressées qui ne devraient pas être là.
Vous n’avez pas besoin de comprendre chaque ligne pour commencer. Vous cherchez des motifs qui ne correspondent pas à la logique WordPress attendue.
Utilisateurs WordPress créés à la volée, rôles et “accès fantôme”
Quand l’attaquant gagne un compte ou crée un compte, il vise souvent la persistance. Sur WordPress, cela passe par des utilisateurs avec des rôles élevés, parfois “camouflés” par un nom banal.
Le serveur donne des indices via la base de données. Selon votre accès, vous pouvez inspecter la table des utilisateurs, et aussi vérifier les activités liées.
Ce que vous voulez éviter, c’est d’avoir supprimé le code malveillant, mais de laisser un compte admin intact. Dans certains incidents, la charge utile reste inactive tant que personne ne visite certains pages. Tant que l’accès persistent est là, l’attaquant peut réactiver le comportement au moment choisi.
Un détail pratique: si vous voyez des utilisateurs créés à des heures étranges, comparez l’heure avec les logs web et les modifications de fichiers. La synchronisation aide à reconstituer la séquence.
Cron côté serveur: le piège discret
Un compromis WordPress ne se limite pas à l’exécution lors du chargement d’une page. Souvent, il utilise le planificateur (cron) pour exécuter périodiquement une tâche: télécharger une charge externe, exfiltrer un fichier, ou réinjecter du code.
Vous pouvez avoir du cron système, du cron applicatif, et parfois des tâches liées à un plugin. Le contrôle doit être ciblé, car vous ne voulez pas désactiver une tâche légitime.
Là encore, les timestamps et la cohérence temporelle sont vos alliés. Une tâche nouvelle apparue juste avant le pic d’accès suspect est un indice fort.
Base de données: quand l’infection change la logique au lieu de modifier les fichiers
Le compromis peut viser la base de données: options WordPress modifiées, contenu injecté dans la base, ou paramètres de plugin changés. Dans certains cas, les fichiers restent presque identiques, mais WordPress se comporte différemment parce que la configuration a été touchée.
Les indicateurs côté base peuvent être:
- des entrées modifiées dans les tables “options”, des contenus ou scripts injectés dans des pages ou articles, des metadata incohérentes, des connexions DB inhabituelles (plus rare, mais possible selon l’accès au monitoring).
Sans forcément vous lancer dans une inspection totale immédiatement, vous pouvez commencer par identifier ce qui a changé autour de la période suspecte. Si vous avez un dump de sauvegarde saine, comparez les variables principales.
Le rôle des plugins et thèmes: la surface d’attaque réelle
Beaucoup d’incidents commencent par une vulnérabilité applicative. Un plugin non à jour, un thème modifié, ou un thème enfant qui a hérité de mauvais choix de sécurité.
Quand vous cherchez des indicateurs côté serveur, les plugins et thèmes ont deux fonctions: ils sont souvent le point d’injection, et ils servent aussi de “preuve” sur la méthode.
Je recommande une démarche pragmatique:
- identifier les plugins installés récemment ou ceux modifiés récemment, vérifier les fichiers PHP changés dans les dossiers concernés, contrôler si des fichiers “vendor” ou “lib” ont été ajoutés à des endroits inattendus.
Le piège, c’est de croire qu’un plugin populaire est forcément sain. Le fait qu’il ait une large base d’utilisateurs ne le rend pas immunisé contre une installation corrompue, ou contre un plugin qui a été modifié après téléchargement.
Indices concrets, interprétation raisonnable
Il existe des indicateurs faciles à lister, mais ce qui compte, c’est l’interprétation. Un même signal peut avoir des causes différentes.
Voici une grille utile, qui n’est pas “universelle”, mais qui aide à orienter rapidement.
- Une vague de requêtes vers des fichiers PHP inhabituels, associée à des pics CPU, suggère une tentative d’exécution de charge utile. Des modifications simultanées de plusieurs fichiers dans un même plugin, à une minute près, évoquent une injection automatisée. Des créations d’utilisateurs sans action côté admin, autour du même intervalle temporel que des requêtes web suspectes, pointent vers un accès initial via l’application. Des changements d’options en base sans modification visible de fichiers, peuvent indiquer une injection par la base ou une fonction déclenchée au chargement. Un cron nouveau ou modifié juste après l’incident, suggère une persistance planifiée.
L’intérêt de cette lecture, c’est qu’elle vous évite de partir en croisade contre tout à la fois. Vous ne cherchez pas juste “du mal”. Vous cherchez “la mécanique”.
Mini checklist de triage immédiat (serveur d’abord)
Quand je dois cadrer une enquête vite, je vise un triage sans casser la suite. Voici une checklist courte, orientée serveur, sans suppositions trop tôt.
Conserver une copie des fichiers modifiés et des logs web, PHP, et système sur la fenêtre temporelle suspecte Identifier les pics d’activité (CPU, I/O, erreurs, requêtes vers des chemins inattendus) et noter les heures Rechercher les créations ou modifications de fichiers PHP dans les thèmes, plugins, racines, et dossiers temporaires Vérifier les utilisateurs WordPress (rôles, dates de création) et repérer les comptes créés récemment Contrôler cron (système et applicatif) pour repérer une tâche nouvellement apparue ou modifiéeCette liste ne remplace pas une réponse complète à incident, mais elle vous donne une direction solide pendant que les preuves existent encore.
Stratégies de nettoyage qui ne cassent pas la preuve (et réduisent la récidive)
Nettoyer, ce n’est pas juste “remettre une sauvegarde”. Sur un site WordPress infecté, j’ai vu des cas où restaurer les fichiers à un état sain n’empêchait pas la réinfection, parce que la porte d’entrée, elle, restait ouverte.
La logique de décision dépend du scénario probable.
Si vous pensez que l’attaque a modifié des fichiers de thèmes ou plugins, un remplacement depuis une source saine et un contrôle des clés et droits est indispensable. Si la base a été modifiée, il faut vérifier les options et le contenu, pas seulement le code.
Et dans tous les cas, si vous suspectez une exécution planifiée (cron) ou un compte admin persistant, vous devez traiter ces éléments en priorité.
Un autre point pragmatique: changer les identifiants sans comprendre comment l’accès initial a été obtenu peut laisser une faille active ailleurs. Par exemple, si l’accès initial passait par une vulnérabilité dans un plugin, changer les mots de passe sans corriger le plugin, c’est accepter une récidive.
Pourquoi les indicateurs “côté serveur” sont parfois contradictoires
Parfois, on observe un détail qui ne colle pas.
Vous trouvez un fichier modifié, mais aucun pic de requêtes à l’époque. Ou bien vous voyez un pic de requêtes, mais aucune trace de modification de fichiers. Dans ces cas, il faut envisager plusieurs explications.
Le fichier a pu être déposé puis nettoyé par l’attaquant, ou la charge utile a pu être déclenchée sans laisser de modifications persistantes sur le système. À l’inverse, un plugin peut avoir été mis à jour légitimement, créant un bruit temporel, pendant qu’une autre partie de l’incident se déroulait ailleurs.
C’est pour cela que je privilégie la cohérence entre trois éléments: logs web, modifications de fichiers, et base de données ou comptes. L’un seul suffit rarement.
Cas typiques: trois récits courts, trois signatures
Pour rendre l’idée concrète, voici trois situations vues dans des diagnostics d’incidents, chacune avec ses signaux serveur.
Cas 1 : l’injection “au moment de la page”
Le site affichait des pages normales la plupart du temps, mais certaines visites étaient redirigées ou injectaient un comportement. Dans les logs web, on voyait des requêtes vers des scripts PHP inhabituels. Dans l’arborescence, un fichier dans un thème avait été modifié, avec une fonction ajoutée qui chargeait du code sous conditions.
Le serveur ne montrait pas toujours une charge CPU énorme, car l’activation était ciblée. Le fil conducteur était la cohérence entre la modification de fichier et les patterns de requêtes.
Cas 2 : la persistance par cron
Le site semblait “stable”, mais le volume d’accès et certains comportements revenaient à intervalles réguliers. Le cron système avait une tâche nouvellement ajoutée, déclenchée toutes les X minutes. Elle téléchargeait une petite charge utile et réécrivait un fichier.
Ici, les logs web étaient parfois trop “propres”, parce que l’attaquant n’exécutait pas directement sur la requête. La preuve était côté scheduler.
Cas 3 : la base qui change le comportement sans que les fichiers bougent
Dans un cas, les fichiers étaient quasiment identiques à une installation saine. Pourtant, des options WordPress avaient été altérées, et certaines pages affichaient du contenu inj ecté.
L’accès serveur au système de fichiers ne suffisait pas à expliquer l’incident. La base était la scène principale. Ce genre de cas rappelle un point: une infection WordPress peut être “logicielle” plus que “graphique”.
Ce que vous pouvez faire après l’analyse, pour que ça ne revienne pas
Une réponse à incident robuste combine deux axes: refermer les portes et durcir.
Fermer les portes, c’est notamment corriger la cause probable: plugin vulnérable, mot de passe exposé, permissions trop larges, compte admin anormal. Durcir, c’est rendre l’exécution non triviale et limiter l’impact.
Sur le plan opérationnel, je conseille aussi de mettre en place une surveillance minimale. Même sans outil sophistiqué, une alerte sur les modifications de fichiers dans les répertoires critiques et une observation régulière des logs peuvent réduire le temps de réaction.
Et surtout, documentez. Notez les horaires, les fichiers suspects, les décisions prises. Quand un nouvel incident arrive, vous gagnez des heures parce que vous pouvez comparer.
Les limites à accepter, et la prudence nécessaire
Il y a un point que je veux garder net: côté serveur, vous pouvez souvent confirmer qu’il y a eu quelque chose d’anormal, mais reconstruire l’intégralité de la chaîne d’attaque peut être impossible, surtout si des éléments ont été nettoyés.
Votre objectif réaliste est de:
- identifier la méthode probable, supprimer la persistance, restaurer la base et les fichiers à un état sain, et corriger la cause qui a permis l’accès.
C’est déjà beaucoup. Et c’est ce qui empêche les “retours” qui frustrent le plus.
Vers une lecture plus sereine des indicateurs
Quand on passe du symptôme au serveur, on gagne en clarté. Les indicateurs côté serveur ne remplacent pas l’analyse applicative WordPress, ils la cadrent. Ils permettent de dater, de prioriser, et de décider avec moins d’émotion.
Un site WordPress infecté peut sembler “mystique” sur la page affichée. Mais sur le serveur, les mécanismes laissent des traces: des requêtes, des exécutions, des modifications, des tâches planifiées, des changements dans la base, des droits trop ouverts.
Si vous devez retenir une idée simple, c’est celle-ci: cherchez la cohérence entre plusieurs couches. Quand les logs web, les modifications de fichiers, et les signaux de persistance racontent la même histoire, vous pouvez avancer vite et surtout proprement.