Disponible pour missions & renforts d’agence · Réponse rapide, par la personne qui intervient

WhatsApp contact@allaux.fr
FR EN TR
allaux.
Urgence Parler de mon projet

Je nettoie mon site et l’infection revient le lendemain

Vous supprimez les fichiers signalés, tout redevient normal quelques heures, puis le problème réapparaît à l’identique : il reste un point de rechargement quelque part, et il se trouve rarement là où le scanner regarde.

Décrire mon problème Discuter sur WhatsApp

Pourquoi un nettoyage partiel garantit la récidive

Quand une infection revient à l’identique après un nettoyage, il s’agit rarement d’une nouvelle attaque. C’est la même compromission qui se réinstalle, à partir d’un composant que le nettoyage n’a pas touché. Un site compromis contient en général deux catégories de fichiers : ceux qui produisent l’effet visible — redirection, page injectée, script inattendu sur le tunnel de commande — et ceux qui servent à les reposer. Les premiers sont bruyants, un scanner les trouve. Les seconds sont discrets, et souvent placés dans des emplacements que le tableau de bord n’affiche pas.

Tant que le mécanisme de rechargement est en place, supprimer les fichiers signalés revient à balayer devant une porte restée ouverte. Le délai typique, quelques heures ou une nuit, correspond simplement à la fréquence à laquelle ce mécanisme se déclenche. C’est d’ailleurs un indice utile : une réapparition régulière, à heure ou à intervalle fixe, désigne une tâche planifiée bien plus qu’une attaque manuelle répétée.

La conséquence pratique est simple : tant que je n’ai pas trouvé par où le code revient, je considère que le site est toujours compromis, même s’il paraît propre.

Ce qui indique qu’il reste un point de rechargement

  • Les mêmes fichiers réapparaissent, avec le même nom ou un nom très proche, quelques heures après leur suppression.
  • Le scanner déclare le site propre, mais le comportement anormal revient : redirection, page inconnue, script ajouté dans les pages.
  • L’infection revient alors que vous avez déjà changé tous les mots de passe.
  • Un compte administrateur que vous aviez supprimé réapparaît.
  • Le retour se produit à intervalle régulier plutôt qu’à un moment aléatoire.
  • Restaurer une sauvegarde règle le problème quelques jours, puis il revient à l’identique.

Pourquoi un scanner qui regarde la liste des extensions passe à côté

WordPress dispose d’un dossier d’extensions à chargement automatique, wp-content/mu-plugins/, dit « must-use ». Le code qui s’y trouve est chargé à chaque affichage de page, sans activation préalable, et il n’apparaît pas dans la liste des extensions du tableau de bord. C’est précisément ce qui en fait une cachette efficace. Sucuri a documenté en mars 2025 l’usage de ce dossier par des attaquants, avec trois fichiers observés : redirect.php, qui redirige les visiteurs vers une page extérieure malveillante déguisée en mise à jour de navigateur ; index.php, un webshell donnant un accès distant au serveur ; et custom-js-loader.php, qui remplace le contenu du site par des liens indésirables et manipule les images.

Un outil qui compare la liste affichée dans l’administration à une liste de référence ne verra rien de ce dossier, puisque son contenu n’y figure jamais. Le même angle mort existe côté thèmes. Une campagne analysée par Sucuri en mai 2025 injectait son code dans le fichier header.php de tous les thèmes installés, y compris ceux qui n’étaient pas actifs, pour afficher au visiteur une fausse page de vérification anti-robot. Nettoyer le thème actif laisse alors intactes autant de copies qu’il reste de thèmes sur le serveur : il suffit d’en activer un, ou qu’un processus le fasse, pour que tout revienne.

Les recommandations de détection tiennent en quelques points : surveiller les comportements inhabituels (redirections, modifications de fichiers), vérifier les permissions anormales, mettre en place un contrôle d’intégrité des fichiers, contrôler les comptes administrateurs, tout maintenir à jour et activer la double authentification.

Les points de persistance, dans l’ordre où je les vérifie

  1. Les extensions à chargement automatique

    Je liste le contenu de wp-content/mu-plugins/ avant tout le reste. Sur beaucoup d’installations saines, ce dossier n’existe même pas. S’il existe et contient des fichiers que personne n’a demandés, c’est le point de rechargement à traiter en premier, parce qu’il s’exécute à chaque page sans jamais s’afficher dans l’administration.

  2. Les thèmes non actifs

    Je relis le fichier d’en-tête de chaque thème présent sur le serveur, pas seulement celui du thème actif. Un thème inutilisé reste un fichier lisible et modifiable, et il conserve l’injection intacte après le nettoyage du thème en place. Un thème que vous n’utilisez pas et que vous ne comptez pas utiliser doit être supprimé, pas désactivé.

  3. Les tâches planifiées

    Je liste les événements du planificateur. Dans la campagne d’hameçonnage analysée par Patchstack en avril 2025, l’extension malveillante programmait une tâche WP-Cron au nom aléatoire exécutée chaque minute, qui réinstallait la charge. Une tâche dont vous ne reconnaissez pas le nom, avec une fréquence anormalement élevée, doit être traitée comme une réinfection programmée.

  4. Le fichier de fonctions du thème actif

    Lors de la compromission de la chaîne de distribution ShapedPlugin publiée en juin 2026, un code chargeur était injecté dans le functions.php du thème actif et lisait une charge encodée en base64. C’est un emplacement parfaitement légitime, modifié par de nombreuses extensions : il se relit ligne par ligne, il ne se scanne pas.

  5. Les comptes administrateurs

    Je compare la liste des comptes à privilèges à ce que vous attendez réellement. Plusieurs campagnes créent des comptes administrateurs, parfois masqués de la liste des utilisateurs affichée dans le tableau de bord. Un seul compte oublié rouvre l’accès complet, quel que soit le soin apporté au nettoyage des fichiers.

  6. Les clés et jetons d’API

    Mots de passe applicatifs, clés d’API, jetons OAuth des services connectés, secrets de double authentification : s’ils ont pu être lus, les régénérer est la seule mesure qui coupe l’accès. Un attaquant qui détient encore un jeton valable n’a pas besoin de la porte dérobée que vous venez de supprimer.

Vérifications de base (shell et WP-CLI)
ls -la wp-content/mu-plugins/
wp cron event list
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp theme list
find wp-content/themes -name "header.php"
find . -type f -name "*.php" -mtime -14

Pour aller plus loin

Décrivez votre besoin en 1 minute

Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.

Qu’avez-vous constaté ?
Depuis quand le problème est-il constaté ?

Plus l’infection est ancienne, plus elle a pu se propager dans les fichiers et la base de données.

Disposez-vous d’une sauvegarde saine ?
Avez-vous encore accès à l’administration WordPress ? (facultatif)
Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Questions fréquentes

Pourquoi l’infection revient-elle toujours au bout de quelques heures ?
Parce qu’un mécanisme de rechargement subsiste et se déclenche à intervalle fixe. Une tâche planifiée au nom aléatoire exécutée chaque minute a été documentée dans une campagne analysée par Patchstack ; tant qu’elle est en place, la suppression des fichiers ne tient que jusqu’à sa prochaine exécution.
Mon scanner dit que le site est propre, est-ce que je peux m’y fier ?
Pas seul. Un outil qui se base sur la liste des extensions affichée dans le tableau de bord ne voit pas le contenu de wp-content/mu-plugins/, qui est chargé sans activation et n’y figure jamais. Je vérifie ce dossier à la main, systématiquement.
Faut-il nettoyer les thèmes que je n’utilise pas ?
Oui, et il vaut mieux les supprimer. Une campagne documentée par Sucuri injectait son code dans le fichier header.php de tous les thèmes installés, actifs ou non. Un thème inactif reste un fichier sur le serveur, donc une copie intacte de l’injection.
Restaurer une sauvegarde suffit-il à régler le problème ?
Rarement. Si la sauvegarde est postérieure à la compromission, elle contient déjà le point de rechargement. Si elle est antérieure, elle remet aussi en place la version vulnérable par laquelle l’attaquant est entré. Une restauration ne remplace pas l’identification du point d’entrée.
Dois-je changer les clés d’API même si j’ai retiré tous les fichiers ?
Oui, dès lors qu’un webshell ou un code chargeur a pu s’exécuter sur le serveur. Un jeton ou une clé encore valable donne un accès qui ne dépend plus d’aucun fichier présent sur le site.
Quand puis-je considérer que c’est terminé ?
Quand le composant par lequel l’attaquant est entré est identifié et corrigé, que les points de persistance sont vides, que la liste des comptes à privilèges correspond à ce qui est attendu et que les secrets ont été régénérés. Avant cela, le site n’est pas nettoyé, il est seulement calme.

Pages liées