Nettoyer WordPress infecté : analyser la session, cookies et utilisateurs

Quand on suspecte une infection sur WordPress, on a souvent tendance à partir en mode “recherche de code malveillant” puis à coller des nettoyages au hasard. Ça marche parfois, mais c’est aussi la meilleure façon de refaire le même diagnostic, sans jamais comprendre pourquoi le site se ré-infec­te. Dans les incidents sérieux, la persistance vient rarement d’un fichier unique. Elle vient d’un ensemble cohérent: comptes utilisateurs piégés, sessions en cours, cookies de persistance, tâches planifiées, scripts injectés, et parfois des accès oubliés (un compte admin “ancien” mais encore valide, une clé API, un plugin installé puis retiré mais dont le code a été réutilisé ailleurs).

Dans cet article, je vais me concentrer sur trois leviers souvent sous-estimés quand on nettoie WordPress infecté: analyser la session, décortiquer les cookies et vérifier les utilisateurs. L’objectif n’est pas seulement de “supprimer ce qui est visible”, mais de comprendre comment l’attaque conserve sa porte d’entrée.

Un site compromis peut paraître propre pendant quelques minutes. Le visiteur voit une page normale, le tableau de bord s’ouvre, certains tests passent, puis quelques heures plus tard, des redirections apparaissent sur des pages précises ou seulement depuis certains navigateurs.

Ce comportement n’est pas magique. Il pointe souvent vers une logique conditionnelle. Les attaquants utilisent fréquemment des critères comme:

Si vous ne regardez pas la session, les cookies et les comptes, vous risquez de nettoyer les fichiers et de “croire” que c’est fini, alors que l’accès continu existe encore. Vous remplacez le code source, mais l’agent malveillant a déjà “fait son nid” dans la logique d’authentification.

Sur WordPress, l’authentification et la persistance de l’état reposent sur des cookies. Quand un utilisateur se connecte, WordPress crée et met à jour des identifiants côté navigateur, puis vérifie ces identifiants à chaque requête.

Selon la configuration, vous pouvez aussi avoir des couches supplémentaires: cache, reverse proxy, WAF, protection applicative, plugins de sécurité, et bien sûr des sessions gérées différemment si vous utilisez des passerelles (Cloudflare, un load balancer, ou un plugin SSO).

Quand un site est infecté, les attaquants peuvent viser plusieurs niveaux:

Dans un incident réel, j’ai déjà vu un cas où seules certaines personnes se faisaient rediriger, et pas tout le monde. La différence tenait à une session déjà active sur leur poste. Tant qu’elles étaient connectées, leur expérience restait contaminée. Dès qu’elles fermaient la session côté navigateur, le comportement changeait. C’est exactement le genre de signature que vous cherchez.

Le bon réflexe n’est pas de “regarder un fichier”. Le bon réflexe, c’est de tracer ce qui se passe quand un utilisateur visite une page, puis quand il se connecte. La session vous donne des indices temporels, parce qu’elle lie des événements.

Commencez par dresser une chronologie simple: quand le comportement suspect a commencé, quels comptes sont concernés, depuis quels navigateurs, et si cela change après déconnexion et reconnexion.

Dans WordPress, les éléments utiles sont souvent:

Si vous avez accès aux logs serveur (Nginx/Apache), cherchez aussi les routes anormales autour des moments clés: requêtes sur wp-login.php, pics sur des endpoints d’administration, ou patterns typiques de scripts automatisés.

L’idée est de tester le même utilisateur dans des conditions différentes:

Si le problème ne se reproduit que dans une session déjà établie, vous avez une piste forte sur les cookies, ou sur une logique persistante déclenchée par un état de connexion.

Un comportement “admin-only” est un classique. Parfois l’injection vise la zone d’administration, parfois elle vise l’édition de contenu. Dans d’autres cas, l’attaquant laisse du code qui s’exécute pour les utilisateurs avec des privilèges, pas forcément pour tout le monde.

Dans votre approche, ne vous contentez pas de vérifier “un administrateur”. Vérifiez:

Vous cherchez des divergences dans les pages chargées, les redirections, et les scripts.

Les cookies sont l’angle mort de beaucoup de nettoyages. On supprime des fichiers, on réinstalle des plugins, mais on laisse des cookies actifs côté navigateur. Si l’attaque a déjà mis en place une condition basée sur un cookie spécifique, un utilisateur peut rester contaminé même après correction.

Avec les outils de développement du navigateur (onglet réseau et stockage), vous pouvez repérer:

Il n’y a pas une liste universelle des cookies “mauvais” pour WordPress, car la structure dépend de la config, des plugins, et du thème. Le signal d’alerte, c’est surtout la répétition d’un comportement après effacement des cookies, ou au contraire la disparition du comportement uniquement après purge.

J’insiste sur ce point, parce qu’il clarifie énormément. Si vous pouvez reproduire un redirection ou une modification de contenu seulement dans un navigateur qui a une session déjà établie, l’attaque joue sur la persistance.

Dans ce scénario, un nettoyage “fichiers et base” peut être incomplet. Il faut aussi invalider ce qui permet à l’attaquant de réutiliser l’état. Côté utilisateur, cela signifie déconnexion, purge des cookies, puis reconnexion à partir d’un site redevenu sain.

Le “bon” nettoyage combine sécurité et continuité. Un incident WordPress peut faire tomber un site en production si on réinstalle trop vite ou si on purge tout sans plan.

Je recommande de penser en couches, du plus probable au plus risqué, en gardant un œil sur la restauration.

1) D’abord, couper l’infection active.

Vous n’avez pas besoin de tout automatiser. Ce qui compte, c’est la cohérence entre ce que vous observez et ce que vous supprimez.

Les attaques réussies n’ont pas seulement un payload. Elles ont un moyen de revenir. Sur WordPress, le moyen le plus efficace, c’est souvent un compte.

Un compte piégé peut servir à:

Même si les fichiers ont l’air propres, un compte compromis redémarre l’infection dès qu’il retrouve les privilèges.

Voici les signaux qui reviennent souvent dans les incidents que j’ai vus:

Si vous avez un plugin de journalisation, utilisez-le. Sinon, récupérez déjà les infos de base: liste des utilisateurs, dates de création, rôles, et dernière connexion si elle est disponible selon votre configuration.

Il y a un piège classique: un compte admin que personne n’utilise plus. Il a un mot de passe ancien, mais il reste valide. Parfois, l’attaquant ne vise pas le compte le plus évident, il vise le plus facile, celui qui ne déclenche pas de suspicion.

Dans un incident, j’ai déjà vu un compte “tech” avec un rôle d’admin, créé des mois auparavant. Le site avait l’air normal. Puis un payload revenait à chaque fois après un nettoyage. La clé, c’était ce compte, qui se reconnectait automatiquement via une session persistée côté navigateur interne et réactivait la mécanique.

Quand vous pensez “session et cookies”, vous devez relier ça aux utilisateurs. L’approche la plus robuste consiste à invalider les sessions de façon globale après correction des comptes et des fichiers.

WordPress dispose de mécanismes pour déconnecter et révoquer les sessions selon les configurations, mais ce n’est pas toujours activé de manière homogène. Dans la pratique, même si vous faites “disconnect”, certains navigateurs peuvent conserver l’état pendant un moment si cache et reverse proxy compliquent la lecture.

C’est là que le test avec navigateur propre redevient crucial: s’il n’y a plus de comportement suspect sans cookies préexistants, vous tenez une victoire.

Le nettoyage efficace repose sur l’enchaînement logique: ce que vous trouvez explique ce que vous observez.

Si, après purge des cookies et déconnexion complète, le comportement suspect disparaît, alors vous savez que la session ou les cookies étaient en cause. Si, à l’inverse, le problème revient immédiatement même dans un navigateur propre, l’infection se situe probablement côté serveur, sur un endpoint public, une page injectée, ou une logique déclenchée à chaque requête.

Cette logique de preuve vous aide à trier ce qui est urgent. Par exemple, si l’attaque semble “admin-only”, vous pouvez prioriser l’invalidation des sessions des comptes élevés et la rotation des mots de passe, avant de passer des heures sur un fichier dont le comportement n’est jamais reproduit sur des rôles non privilégiés.

Voici un déroulé raisonnable, sans tomber dans l’excès. Il ne remplace pas un incident response complet, mais https://gardewp.fr/ il donne une base solide pour comprendre d’où vient la persistance.

Cette liste a un mérite, elle vous oblige à répondre à des questions précises. Et quand vous avez répondu, le reste du nettoyage devient plus rationnel.

Tous les compromis ne se comportent pas pareil. Deux cas reviennent souvent.

Signaux fréquents: seuls certains utilisateurs sont impactés, et uniquement quand ils sont connectés dans leur navigateur habituel. Après purge des cookies, le problème s’atténue ou disparaît.

Dans ce cas, l’attaquant a probablement mis en place une persistance via cookies, une logique conditionnelle liée à l’état d’authentification, ou un accès via un compte déjà actif.

Signaux fréquents: tout le monde voit le même comportement, y compris depuis un navigateur propre et non connecté. Les redirections touchent des pages publiques, parfois de manière aléatoire selon l’IP ou le référent.

Dans ce cas, vous êtes davantage face à une injection côté serveur, des fichiers modifiés, ou des mécanismes d’exécution déclenchés à chaque chargement.

Entre les deux, il existe une zone grise. Certains payloads sont hybrides, par exemple ils injectent un script, puis ce script ne redirige que si certains cookies existent. Dans les incidents réels, j’ai plus souvent rencontré cette hybridation que le cas “tout ou rien”.

Réinstaller WordPress et les thèmes peut corriger la source, mais si l’utilisateur compromis et la persistance de sessions/cookies restent, l’infection revient. C’est la raison pour laquelle l’analyse des utilisateurs est aussi importante que la suppression de fichiers.

Si le serveur reste compromis, la purge ne fait que vous ralentir. Le comportement revient au prochain chargement, surtout pour des endpoints publics. La purge est utile, mais elle n’est pas une preuve que le serveur est sain.

Mettre à jour plugins et thèmes dans la panique peut casser encore plus si certains plugins contiennent des hooks utilisés par l’infection. Une méthode plus prudente consiste à isoler, investiguer et seulement ensuite mettre à jour, idéalement en comparant avec des versions connues comme propres.

Le nettoyage d’un site WordPress infecté se fait rarement en une seule passe. Il faut penser en “cycle de vérification”. Chaque cycle réduit la surface d’attaque et augmente la confiance.

Dans cette optique, la session, les cookies et les utilisateurs ne sont pas des sujets secondaires. Ils déterminent si votre correction tient dans le temps.

Si vous ne traitez pas ces éléments, vous pouvez vous retrouver avec une situation frustrante: le site paraît correct pendant votre contrôle, puis redevient problématique dès que quelqu’un retrouve une session, ouvre une page spécifique ou se reconnecte.

Pour orienter vos actions sans perdre de temps, voici deux repères simples.

| Indicateur observé | Ce que ça suggère généralement | Priorité | |---|---|---| | Comportement suspect disparaît dans navigateur propre non connecté | Persistance via cookies ou état de session | Invalider sessions, vérifier comptes, purge cookies | | Comportement suspect visible non connecté sur pages publiques | Injection côté serveur, fichiers, hooks, endpoints | Corriger code source et mécanismes d’exécution |

Je préfère ce type de décision par observation, plutôt que de suivre une checklist rigide. Elle s’adapte à votre cas.

Une fois que vous avez nettoyé WordPress infecté, l’étape “après” compte autant que l’étape “pendant”. Les infections exploitent des failles ou des habitudes. Si vous ne réparez pas la cause, vous recommencez le cycle.

Concrètement, après avoir validé que les cookies et les sessions ne déclenchent plus le problème, il faut verrouiller l’accès:

La qualité du nettoyage se juge à la stabilité. Un site “propre” mais instable ressemble à un incident non terminé.

Je résume un scénario très fréquent, sans prétendre qu’il s’agit d’un modèle universel.

Une équipe constate des redirections vers des pages externes, principalement quand une personne se connecte au back-office. En vérifiant, on voit que la redirection ne touche pas les visiteurs non connectés, ni les personnes qui ouvrent le site dans un navigateur neuf. On suspecte une condition liée à l’état d’authentification.

L’équipe purge les cookies sur le poste impacté. Le problème diminue fortement. En parallèle, l’analyse des utilisateurs révèle un compte admin créé récemment, avec un mot de passe changé pour masquer l’entrée. Après désactivation du compte, rotation des mots de passe et invalider les sessions, le comportement ne revient pas, même après reconnexion.

Ce scénario illustre l’intérêt de votre sujet: si vous ne purgeiez que les fichiers, vous auriez peut-être un faux sentiment de fin. Le compte et l’état de session auraient continué la persistance.

Un audit sérieux ne se contente pas de dire “il y a un fichier modifié”. Il relie des faits à des comportements. Il répond à des questions comme:

Si vous obtenez des réponses à ces points, vous avez déjà l’essentiel. Le reste du nettoyage devient une mécanique de restauration et de durcissement.

Quand vous nettoyez WordPress infecté, traitez la persistance comme un système. La session, les cookies et les utilisateurs ne sont pas des détails. Ce sont des mécanismes de continuité, donc les endroits où l’attaquant est le plus patient.

Si votre vérification ne tient pas dans un navigateur propre, ou si le comportement revient après reconnexion, vous avez encore une porte d’entrée. Tant que cette porte reste ouverte, le nettoyage de fichiers ne sera qu’une pause.

Si vous voulez, décrivez votre cas (types de symptômes, pages touchées, présence de redirections, plugins de sécurité installés, accès admin disponibles). Je peux vous proposer une démarche d’analyse plus ciblée, adaptée à votre configuration, sans partir dans le “tout supprimer d’un coup”.