Quand un site WordPress commence à rediriger vers des pages douteuses, à afficher du code en base ou à générer des scripts minifiés “inexplicables”, la première réaction est souvent de vouloir “enlever virus WordPress” le plus vite possible. C’est normal. Mais si vous faites seulement le ménage, sans tracer d’où vient l’injection, vous risquez de refermer la porte sans retrouver la clé. La https://gardewp.fr/ bonne approche consiste à couper le vecteur, puis à remonter la trace, en restant prudent sur ce que les logs disent réellement.
J’ai déjà vu des sites nettoyés en deux heures, puis réinfectés le lendemain, parce qu’un identifiant compromis n’avait pas été remplacé ou parce qu’un job planifié continuait à déposer la charge utile. Dans ces cas, la recherche de l’IP n’est pas “une chasse aux coupables” gratuite, c’est une façon d’identifier la méthode d’accès et de fermer le bon trou.
Distinguer “l’IP vue” de “l’IP responsable”
Avant de regarder un log, il faut accepter une idée simple: l’IP que vous verrez côté serveur n’est pas forcément celle de la personne qui a exécuté l’injection.
Sur un site WordPress, vous avez souvent au moins un intermédiaire:
- un CDN ou un proxy (Cloudflare, Fastly, un reverse proxy de l’hébergeur), un load balancer, parfois un pare-feu applicatif (WAF), et dans certains cas, du NAT chez le client.
Résultat, vous verrez généralement l’IP du proxy ou de l’infrastructure, pas celle de l’attaquant final. Cela dit, ces IP “intermédiaires” sont utiles pour deux raisons. D’abord, elles vous aident à retrouver la chaîne complète de requêtes. Ensuite, elles vous permettent d’identifier l’hôte qui a probablement déclenché la série d’accès, ce qui aide à corréler avec d’autres événements (tentatives de connexion, pics de trafic, changement de fichiers, exécution planifiée).
Le bon réflexe, c’est de décider ce que vous cherchez exactement. Dans la pratique, “tracer l’IP ayant injecté le malware” signifie souvent: retrouver l’IP la plus probable ayant déclenché la requête qui a permis l’écriture de fichiers ou la modification d’options. Et si cette IP n’est pas l’acteur final, elle reste un marqueur exploitable.
Ce qu’il faut faire immédiatement (sans casser les preuves)
Quand l’infection est active, votre priorité est de stopper l’accès malveillant et d’empêcher toute modification ultérieure, tout en conservant les traces.
La tentation est de supprimer au plus vite. Je recommande plutôt de créer un “plan de lecture” des événements, puis de procéder. Concrètement, vous voulez capturer:
- les logs web (nginx/apache) sur la fenêtre temporelle concernée, les logs d’authentification WordPress (ou les logs du serveur quand ils existent), les logs hébergeur (si disponibles), et l’état du système de fichiers et de la base avant toute nouvelle modification.
Vous n’avez pas besoin d’être parfait du premier coup. Même une capture partielle sur quelques heures peut suffire, surtout si l’injection est accompagnée de changements de fichiers identifiables.
Voici une petite préparation utile, si vous pouvez le faire dans les premières minutes:
- Copier les fichiers WordPress suspects (par ex. Les thèmes ou plugins modifiés) vers un dossier en lecture seule Exporter la base (au moins les tables susceptibles d’avoir bougé) Récupérer les logs serveur sur la plage horaire de l’apparition Noter les heures exactes où vous avez observé les symptômes (redirections, chargements de scripts, erreurs)
Cette liste tient en quelques actions, mais elle vous évite de “perdre” des informations alors que vous êtes prêt à lire.
Identifier le point d’entrée avant de regarder l’IP
Traquer une IP au hasard, sans hypothèse, c’est souvent perdre du temps. L’injection WordPress suit généralement une logique. Elle correspond à un point d’entrée classique: identifiants, faille de plugin ou thème, mauvaise configuration, ou accès direct via une fonction permettant l’écriture.
Avant de chercher l’IP, posez-vous ces questions en observant ce que vous avez sous les yeux:
Le site a-t-il montré des redirections instantanées, souvent après une connexion admin ou une mise à jour plugin? Voyez-vous des fichiers nouvellement créés dans wp-content/uploads, wp-content/plugins ou wp-content/themes? La base contient-elle des champs anormaux, comme des options modifiées, du contenu injecté dans des paramètres, ou des scripts ajoutés à une page? Le code malveillant est-il dans un endroit typique d’escalade (fichier “loader”, plugin de backdoor, webshell, ou simple script qui contact un serveur distant)?
Même si vous n’êtes pas développeur, vous pouvez souvent repérer des motifs: chaînes hexadécimales, fonctions d’obfuscation, chargement de ressources externes, usage de eval, base64_decode, ou des requêtes HTTP depuis le PHP. Je ne propose pas d’exploiter le code ici, mais de le lire comme un indice.
Une fois l’endroit probable trouvé, la suite devient plus “chirurgicale”: vous remontez les requêtes qui auraient pu provoquer ce changement.
Récupérer les bons logs: nginx/apache, WordPress, et hébergeur
Pour tracer l’IP, vous avez besoin de logs qui contiennent au moins l’adresse source (ou une entité proxy) et l’URL demandée, avec un horodatage cohérent.
Côté serveur, selon l’infrastructure, vous aurez typiquement:
- des logs d’accès HTTP (requêtes) avec la méthode (GET, POST), l’URI, le status code, et l’IP source, des logs d’erreurs (si quelque chose a échoué), parfois des logs PHP (selon la config), et des logs “applicatifs” selon votre stack.
WordPress, de son côté, ne trace pas automatiquement toutes les actions sensibles. Il trace certaines choses via des événements (comme l’authentification) si des plugins de sécurité ou de journalisation sont en place, ou si vous avez des systèmes comme “audit logs” dans un outil hébergeur.
Le piège courant: regarder uniquement les logs “généraux” et croire qu’ils montrent l’injection. Or une injection peut se produire via une requête POST vers wp-admin/admin-ajax.php, vers une page d’upload, ou même via des appels AJAX après authentification. Si vous ne filtrez pas la fenêtre horaire et les endpoints pertinents, vous noyez la trace.
Je m’appuie souvent sur trois indices pour réduire la masse:
- les heures exactes de symptôme (redirection ou chargement malveillant), la taille des réponses ou la présence de status inhabituels, et la cohérence avec des opérations WordPress probables (connexion admin, upload, création/modification de fichier, actions AJAX).
Filtrer la fenêtre temporelle: le plus important pour trouver “l’IP utile”
La plupart des sites WordPress reçoivent des requêtes en permanence, y compris des tentatives d’accès automatisées. Sans fenêtre temporelle, l’IP que vous trouverez sera souvent un bruit.
Quand vous observez l’infection, notez:
- l’heure locale à laquelle vous l’avez vu, l’heure UTC si votre environnement l’affiche dans les logs, et la durée probable d’action (par exemple, si vous avez constaté la redirection au bout de quelques minutes, l’injection peut s’être produite avant).
Astuce pratique: comparez l’horodatage des logs d’accès avec le changement constaté dans les fichiers. Si un plugin a été modifié, vous pouvez vérifier sa date de modification sur le filesystem, puis remonter dans les logs autour de ce moment.
Cette étape paraît “méthodologique”, mais elle fait souvent gagner un ordre de grandeur dans le temps de tri.
Repérer les requêtes liées à une modification de contenu ou de fichiers
Sans vous donner une recette universaliste, je peux vous dire ce qui revient le plus en incident response WordPress.
Les attaques qui injectent du code passent fréquemment par:
- des tentatives de connexion sur wp-login.php (par force brute ou credentials stuffing), des accès au back-office suivis d’actions de modification (édition de thème/plugin, installation de plugin, upload de fichier), et des requêtes POST vers des endpoints internes qui manipulent la base.
Dans les logs d’accès HTTP, vous cherchez donc des séquences de requêtes cohérentes autour du moment de la modification:
- un pic d’échecs ou de réussites sur l’authentification, puis des requêtes vers des pages d’administration, puis des requêtes qui ressemblent à des actions de changement (édition, upload, mise à jour d’option).
Si vous avez un WAF ou un contrôle d’intégrité, vous verrez parfois des blocs. Même bloqués, ils donnent une chronologie.
Cas fréquent: injection via un compte compromis
Dans beaucoup d’incidents réels, le vecteur n’est pas un exploit “magique”, mais un compte admin dont le mot de passe a été pris. Ensuite, l’attaquant se connecte, installe un plugin ou modifie un fichier, puis couvre ses traces.
Dans ce scénario, les logs d’accès montrent souvent une IP (ou un proxy) qui :
- réussit une authentification, accède rapidement à des pages d’admin, et déclenche des modifications dans un laps de temps court.
L’IP “responsable” correspond alors à celle de la session ou de la série de requêtes. Ce n’est pas la seule IP possible, mais c’est un point de départ solide.
Lire les champs d’IP correctement derrière un proxy
Quand votre site est derrière un CDN ou un proxy, l’IP “réelle” peut se trouver dans des en-têtes comme X-Forwarded-For ou des champs spécifiques à votre infrastructure.
Le problème, c’est que ces en-têtes peuvent être mal configurés. Certains setups enregistrent l’IP proxy sans l’IP client, ou bien font confiance à des en-têtes que l’attaquant peut falsifier si vous ne filtrez pas.
Concrètement, dans vos logs:
- vérifiez si le champ IP affiché correspond à l’adresse vue côté serveur, cherchez si les logs incluent un autre champ, parfois noté “forwarded” ou similaire, et identifiez ce que votre serveur considère comme “source de confiance”.
Si vous n’êtes pas sûr, ne vous contentez pas de “l’IP la plus méchante”. Regardez la cohérence: si X-Forwarded-For change d’une requête à l’autre alors que tout passe par le même proxy, vous êtes probablement en présence de données non fiables ou de multiples couches.
Dans ce contexte, la trace utile n’est pas uniquement “l’IP finaliste”, c’est la relation entre:
- l’IP d’origine côté serveur (proxy), l’identité de la session (cookie, user agent si vous l’avez), et la chronologie des actions.
Corréler IP et événements WordPress (même sans logs WordPress natifs)
Même si WordPress ne fournit pas un journal complet par défaut, vous pouvez faire des corrélations.
Regardez:
- les utilisateurs WordPress: date et heure de création, rôles, modifications, et activité récente, les plugins ou thèmes installés récemment, les fichiers modifiés et leur séquence, et, si vous avez gardé une copie de la base, les options modifiées.
L’attaque laisse souvent une empreinte dans la base. Par exemple, un code malveillant peut être stocké comme option, comme contenu de champ, ou comme paramètre déclenchant un rendu. Même sans comprendre tout, la présence de modifications autour d’une heure précise aide à aligner les logs web.
Ce que j’attends, dans une bonne corrélation, c’est une cohérence temporelle: “même minute” ou “quelques minutes d’écart” entre le moment où un utilisateur a agi ou s’est connecté et le moment où un fichier ou une option a changé.
Méthode pratique de tri des requêtes dans les logs (sans se noyer)
Les logs peuvent être énormes. Le but n’est pas de tout lire, c’est de trouver des séquences.
Sans entrer dans une procédure outillée précise (qui dépend de votre hébergeur), l’approche que j’utilise est simple:
Filtrer par période (fenêtre horaire autour du changement de fichiers) Filtrer par endpoints d’administration et d’upload Chercher les méthodes POST, car l’injection passe souvent par des formulaires ou des appels AJAX Repérer les status codes “suspects” (succès sur des pages d’admin, réponses anormales après une séquence de tentatives) Extraire l’IP source dominante sur la séquence “auth puis action”Le résultat attendu ressemble à une “courbe”: une première phase de tentative ou de connexion, puis une phase d’accès admin et modifications rapides.
Exemple concret de séquence (pattern typique)
Imaginons que vous observez la redirection vers des sites inconnus à 03:42. Vous regardez les logs autour de 03:40 à 03:50. Vous trouvez:
- plusieurs POST vers wp-login.php avec des échecs, puis un POST vers wp-login.php avec un succès, puis des POST vers des URLs d’admin, puis peu après, des requêtes déclenchant un upload ou une modification de contenu.
L’IP de ce bloc de requêtes est souvent votre meilleure piste. Ensuite, vous vérifiez si le user agent correspond à un navigateur normal, si ce n’est pas un bot, et si les cookies ou identifiants de session existent dans les logs (ça dépend de votre configuration).
Quand l’IP ne suffit pas: user agent, patterns, et limitation technique
Parfois, vous ne pouvez pas conclure avec certitude. https://gardewp.fr/nettoyage-malware-wordpress/ Voici des situations que j’ai rencontrées:
- l’attaquant utilise un proxy qui change souvent d’adresse côté “dernier saut”, l’accès provient d’une adresse d’infrastructure très partagée (cloud, NAT), ou l’injection ne nécessite pas une action “vue” sur l’URL, car elle exploite un mécanisme interne et ne passe pas par une page d’admin classique.
Dans ces cas, je considère l’IP comme un indice, pas comme une preuve finale. Vous cherchez alors des preuves complémentaires:
- répétition du même user agent dans la séquence, cohérence de la chronologie avec une modification de plugin ou de fichier, présence d’événements de sécurité dans l’hébergeur, et surtout, état des comptes WordPress et de la configuration.
L’objectif n’est pas de “deviner”, c’est de réduire les hypothèses à quelques scénarios plausibles, puis de les vérifier.
Se protéger après la traque: fermer le vecteur de réinfection
Traquer l’IP, c’est bien. Mais si vous ne corrigez pas, vous allez répéter la même histoire.
La correction se fait sur deux axes: nettoyer et durcir.
Nettoyage orienté, pas juste suppression
Si vous supprimez des fichiers sans comprendre comment ils ont été déposés, vous risquez de casser la trace ou de laisser une porte ouverte. Par exemple, si un plugin backdoor était activé, vous devez vérifier aussi les options et les utilisateurs, pas uniquement les fichiers.
D’un point de vue pratique, je préfère:
- isoler les fichiers suspects, restaurer depuis une sauvegarde connue saine, puis vérifier la base et la liste des plugins/thèmes, et seulement ensuite réactiver progressivement.
Durcissement côté accès et WordPress
Voici un mini plan de durcissement que je fais quasi systématiquement après ce type d’incident:
- forcer la rotation des mots de passe et vérifier les utilisateurs, retirer tout compte non reconnu désactiver temporairement l’installation automatique de plugins, et limiter les rôles capables d’installer ou d’éditer vérifier les fichiers et dossiers ayant des permissions trop larges activer une protection anti force brute ou un mode “bloquant” au niveau du serveur ou du pare-feu renforcer l’authentification (idéalement avec une seconde étape) quand c’est possible chez vous
Je sais, tout le monde ne peut pas activer la même chose du jour au lendemain. Mais l’idée est d’empêcher la prochaine intrusion de réutiliser le même chemin.
Rôle des sauvegardes et de la restauration pour confirmer l’origine
Quand vous avez des sauvegardes, vous pouvez aller plus loin que la simple “suppression”.
Si vous restauriez à un instant avant l’injection, puis vous surveillez, vous pouvez constater:
- si le malware revient après restauration, et si oui, combien de temps il faut avant le retour.
Un retour rapide après restauration suggère que le vecteur n’est pas uniquement “dans les fichiers restaurés”. Il peut provenir d’un compte, d’une tâche planifiée, d’un webhook, ou d’un mécanisme qui réinscrit le code.
Même si vous n’êtes pas certain de “l’IP qui a injecté”, cette observation confirme que vous n’avez pas seulement un problème de fichiers, mais un problème d’accès et de persistance.
Cas particulier: injections “dans la base” et impact sur l’IP à tracer
Quand le malware est principalement dans la base, la traçabilité change. L’IP qui a injecté peut être celle d’une action WordPress qui a écrit des options, ou celle d’un processus externe qui a consommé une API.
Vous devez alors enrichir vos corrélations:
- journaux d’accès et endpoints d’administration, modifications d’options et d’éléments de contenu, création de pages ou de fragments, et, si vous avez un plugin de sauvegarde ou un audit, les événements liés aux changements de paramètres.
Si vous ne trouvez pas de trace web claire, l’hypothèse la plus fréquente reste un compte compromis, car l’écriture en base se fait alors par l’interface ou via des appels backend.
Une façon simple de conclure votre enquête: la “piste dominante”
Après tri, vous aurez généralement une “piste dominante”, une IP (ou un proxy) qui ressort clairement dans la fenêtre temporelle liée à:
- la connexion (ou la réussite d’une tentative), puis l’enchaînement vers des URLs d’administration, puis un changement de fichiers et/ou de base.
Ce que vous faites ensuite dépend du contexte, mais l’idée est de ne pas rester bloqué sur une seule valeur. Je vous conseille de documenter votre constat interne, même si vous n’allez pas au bout côté juridique:
- heure de l’apparition observée, heure des modifications détectées, IP dominante et sa nature (proxy, cloud, NAT), endpoints sollicités, et changements WordPress corrélés.
Cette documentation sert pendant la restauration, la communication avec l’hébergeur, et la vérification de l’absence de persistance.
Si vous êtes accompagné par un hébergeur ou une assistance sécurité
Beaucoup d’incidents WordPress sont traités avec des équipes d’hébergement. Ils peuvent vous aider, surtout pour accéder aux logs qui ne sont pas visibles chez vous.
Préparez les éléments, et vous gagnerez beaucoup de temps. Par exemple, je fournis souvent:
- une fourchette d’heures (avec fuseau horaire), l’URL affectée (la redirection observée, un exemple de page), la liste des plugins ou thèmes modifiés, et les fichiers suspects repérés.
Cela dit, gardez en tête que l’hébergeur voit parfois une version différente des logs (niveau réseau, niveau applicatif). Leur “IP” peut être différente de la vôtre si la chaîne proxy est différente. Ce n’est pas contradictoire, c’est un problème de couche.
Checklist finale de vérification (pour éviter la fausse piste)
Avant de clore l’enquête et d’attendre la prochaine visite d’un bot, je fais une dernière vérification, concentrée sur la cohérence.
- L’IP dominante correspond-elle bien à la fenêtre autour des changements détectés? Les comptes WordPress et leurs rôles semblent-ils avoir été modifiés? Un plugin ou thème “nouveau” ou modifié apparaît-il à l’endroit attendu? Le code malveillant a-t-il une source cohérente (upload, édition, import)? La réinfection est-elle évitée après restauration, sur quelques cycles de surveillance?
Si plusieurs réponses sont “non”, il ne sert à rien de s’accrocher à une IP. Dans ce cas, le vecteur est peut-être ailleurs, ou bien la trace a été partiellement effacée, ce qui arrive.
Et le mot clé pratique: “enlever virus WordPress” sans perdre la trace
L’erreur la plus fréquente, c’est de se focaliser sur la suppression du code tout en négligeant l’enquête. Supprimer le malware sans tracer l’IP, c’est comme changer la serrure alors que la personne a encore un badge ou connaît un autre accès.
Le bon équilibre, c’est:
- isoler et nettoyer, conserver les preuves, tracer la séquence d’accès dans les logs, corréler avec les modifications WordPress, puis durcir pour que l’IP retrouvée (ou ses proxys) ne puisse pas rejouer la même mécanique.
Si vous voulez, décrivez-moi ce que vous observez (redirection vers quels domaines, quels fichiers ou plugins ont été modifiés, et si vous êtes derrière un CDN). Avec ces éléments, je peux vous proposer une méthode de tri des logs plus ciblée, et vous aider à interpréter l’IP visible sans tomber dans les faux amis.