Quand un site WordPress se fait compromettre, on a parfois un signal assez clair. Une page blanche. Des redirections impossibles à expliquer. Des posts publiés “tout seuls”. Et puis il y a ce détail qui revient très souvent dans les enquêtes terrain: des comptes utilisateurs apparaissent automatiquement, créés par l’attaquant, ou plutôt par un script qui tourne sur le serveur.
Ces utilisateurs ne sont pas juste un souci de “propreté”. Ils signifient que l’attaquant a trouvé une porte d’entrée, ou pire, qu’il a maintenu un accès persistant. L’objectif de cet article est simple, mais pas basique: comprendre comment ces comptes se mettent en place, comment les neutraliser proprement, et surtout comment éviter que le site recrée de nouveaux utilisateurs au prochain cycle.
Je vais vous parler comme on le ferait lors d’un incident réel: ce qui compte, ce qui peut tromper, et les décisions à prendre quand on hésite entre “tout supprimer” et “réparer sans casser”.
Le scénario le plus fréquent: accès persistant via des comptes “fantômes”
Dans beaucoup de compromissions WordPress, l’attaquant cherche deux choses:
1) garder une méthode de réentrer, même après suppression apparente, 2) pouvoir exécuter des actions depuis l’interface, par exemple publier, injecter du contenu, modifier des thèmes ou des plugins, ou ajouter d’autres comptes.
Créer un utilisateur “admin” (ou un compte avec des rôles élevés) est une façon directe de contourner une partie des contrôles techniques. Et c’est souvent accompagné d’un mécanisme caché. L’utilisateur apparaît parce qu’un code malveillant s’exécute à intervalles réguliers, ou parce qu’une requête déclenche sa création.
Dans les cas que j’ai vus, le schéma est souvent le même: le propriétaire constate de nouveaux comptes dans “Utilisateurs” et commence à les supprimer. Le problème, c’est que la minute d’après, d’autres apparaissent. Là, on comprend que supprimer les utilisateurs ne suffit pas.
Il faut chercher la source, comprendre pourquoi les comptes se recréent, puis fermer le vecteur de persistance.
D’abord, vérifier si le site est réellement “compromis”
Avant de toucher au site, je recommande un minimum de triage. Pas pour gagner du temps, mais pour éviter de ruiner une piste.
Plusieurs signaux peuvent coexister:
- changements côté contenu (pages modifiées, articles publiés, spam dans les commentaires), comportement réseau anormal (redirections, chargement de scripts depuis des domaines récents), traces côté fichiers (nouveaux fichiers ou modifications de fichiers sensibles), nouveaux utilisateurs, parfois avec emails bizarres ou noms d’utilisateurs à consonance aléatoire.
Si vous supprimez des utilisateurs immédiatement, vous pouvez perdre la capacité d’attribuer l’intrusion à une période précise. Un attaquant qui a encore la main peut aussi utiliser ces comptes pour modifier l’environnement pendant que vous “récupérez”.
La bonne approche consiste à faire une petite collecte, sans transformer la restauration en archéologie interminable.
Geler l’incident sans casser la plateforme
Quand je traite un site compromis, je cherche à réduire l’action de l’attaquant tout en gardant assez de contexte pour investiguer.
Selon votre hébergement, vous avez plusieurs options pragmatiques, par exemple mettre temporairement le site en maintenance (ou limiter l’accès), puis travailler en parallèle sur l’analyse.
Ce qui compte: empêcher l’exécution répétée des scripts si c’est possible, tout en conservant les fichiers et les logs. Si vous avez la chance d’avoir des logs d’accès et d’erreurs (hébergeur, reverse proxy, serveur), c’est une mine. Sinon, il faut s’appuyer sur le système de fichiers et l’historique de modifications.
Le point clé est psychologique: la “vague” de création d’utilisateurs peut se produire à intervalle régulier. Si vous attendez, vous perdez des indices, et vous augmentez la surface d’attaque.
Pourquoi les utilisateurs se créent automatiquement
Cette partie aide énormément à éviter l’erreur classique: penser que le problème est uniquement “dans l’administration”.
Voici les mécanismes les plus courants observés dans le monde WordPress:
- un plugin ou un thème infecté, avec du code qui appelle wp createuser() ou qui interagit directement avec la base, une tâche planifiée (cron) malveillante, qui s’exécute à intervalle régulier, un script placé dans un fichier “discret” (souvent dans la racine, dans des sous-dossiers inhabituels, ou via des fichiers déjà existants mais modifiés), une backdoor via un fichier de type PHP inclus par WordPress, parfois déguisé en “helper”, une compromission par identifiants (attaque par mot de passe) suivie d’une “sur-couche” malveillante ajoutée après coup.
Le fait que des utilisateurs reviennent immédiatement après suppression est un indice fort d’un mécanisme automatique. Ce mécanisme doit être identifié, puis neutralisé. Les comptes ne sont que la façade.
Cas réel: supprimer le compte “admin” et voir le suivant apparaître
J’ai déjà vu une situation très frustrante. La personne supprime trois comptes, elle vérifie, tout semble calme. Vingt minutes plus tard, cinq nouveaux comptes sont présents, avec des rôles similaires. Les emails diffèrent, mais les patterns de noms d’utilisateurs sont proches. Les logs d’accès montraient des requêtes répétées sur des fichiers inconnus, appelés depuis WordPress.
Ce que ça raconte, c’est que l’attaquant a installé un mécanisme de régénération. Peut-être pour garder une entrée stable même si l’admin officiel change. Peut-être pour distribuer la capacité d’exécution, au cas où un compte est bloqué. Dans les deux cas, supprimer des utilisateurs “à la main” est un jeu de ping-pong.
Le bon réflexe consiste à passer en mode enquête: repérer les fichiers anormaux, vérifier les modifications récentes, contrôler les plugins et thèmes, et regarder le système de planification.
Étape par étape: traiter les utilisateurs créés automatiquement
Ici, je vais être concret. L’objectif n’est pas seulement de supprimer des comptes, mais de stopper la mécanique qui les produit, tout en sécurisant votre accès légitime.
1) Faire un inventaire des utilisateurs anormaux
Ne supprimez pas dans le vide. Regardez:
- date de création, rôle attribué, mode de création (quand WordPress affiche ce type d’info, ou au moins les indices dans les logs), cohérence des emails et des noms.
Si les comptes apparaissent en rafales proches, notez l’instant approximatif. Ensuite, vous pourrez recouper avec les journaux serveur ou d’accès.
Le but est d’éviter une suppression aveugle. Vous voulez éliminer le contrôle de l’attaquant, mais aussi comprendre quand il agit.
2) Vérifier si un mécanisme automatique tourne encore
C’est là que la plupart des interventions “trop rapides” échouent. Un utilisateur malveillant peut être supprimé, mais si un cron ou un plugin infecté s’exécute encore, il sera recréé.
Je vous conseille de vérifier plusieurs points qui sont souvent impliqués:
- plugins installés récemment ou mis à jour récemment, thèmes modifiés récemment (y compris dans les fichiers de templates), fichiers PHP nouvellement ajoutés dans la racine ou dans des dossiers suspects, cron WordPress (si accessible) et cron système, fonctions liées à la création d’utilisateurs ou à l’inclusion dynamique de fichiers.
Il n’y a pas de vérité universelle, mais ces axes reviennent dans la majorité des cas.
3) Supprimer les comptes avec méthode
Quand l’enquête pointe vers des utilisateurs précis, la suppression doit être faite proprement. Dans un environnement WordPress, cela passe généralement par l’interface d’administration, ou via l’outil SQL si vous savez exactement ce que vous faites.
La règle que je privilégie: supprimer les comptes malveillants, puis revérifier immédiatement, une fois que vous avez stoppé le vecteur (au moins temporairement). Si vous attendez deux jours et que ça recrée, vous perdez l’occasion d’itérer vite.
Vous devrez peut-être recommencer la boucle une ou deux fois, notamment si vous n’avez pas identifié le bon mécanisme dès le premier passage.
4) Fermer les portes qui permettaient la persistance
Après avoir nettoyé les utilisateurs, il faut se protéger contre les retours. Sinon, vous allez être “capturé” dans un cycle de suppression.
Cela peut impliquer:
- désactivation des plugins et thèmes non essentiels, remplacement des fichiers WordPress par une version saine, suppression des fichiers malveillants identifiés, reconfiguration des accès (mots de passe, rôles, permissions), mise en place de durcissements pour empêcher la même famille d’attaque.
La logique est la même que pour supprimer malware WordPress: vous coupez ce qui permet l’exécution, pas seulement ce qui montre la conséquence.
Voici la première checklist, courte, parce qu’en incident elle sert vraiment.
- Documenter l’heure d’apparition des comptes et capturer une liste des utilisateurs créés Désactiver temporairement les plugins récemment ajoutés ou suspects Contrôler les fichiers modifiés récemment dans wp-content et la racine Rechercher des indices de cron malveillant (WordPress et serveur) Nettoyer les comptes, puis vérifier immédiatement si de nouveaux comptes reviennent
Supprimer malware WordPress: ne pas confondre cause et symptôme
Le mot “malware” est utilisé largement, mais dans WordPress, le “malware” n’est pas toujours un fichier unique. Parfois, c’est une combinaison de petites altérations:
- un plugin légitime mais détourné, une charge qui n’est appelée que dans certains contextes, un snippet caché dans un fichier de thème, un enchaînement avec des requêtes externes (domaines fraîchement créés ou rares), des modifications dans la base.
Quand vous vous focalisez uniquement sur les utilisateurs, vous traitez une conséquence. Si vous supprimez le code source, vous traitez la cause. Si vous faites les deux mais dans le mauvais ordre, vous pouvez créer un scénario où l’attaquant “attend” le prochain déclenchement.
Mon approche préfère d’abord limiter ce qui exécute le code, puis nettoyer les comptes.
Identifier les points infectés sans tout casser
WordPress est tolérant, jusqu’à ce qu’il ne le soit plus. Pour éviter les erreurs, je procède souvent dans cet ordre:
1) plugins, 2) thèmes, 3) fichiers de configuration et inclusions, 4) scripts dans la racine ou dossiers inattendus, 5) base de données et options WordPress.
Ce qui compte n’est pas la liste en soi, c’est le fait d’avoir une démarche. Par exemple, si un plugin est infecté, le désactiver aide tout de suite. Si c’est un fichier PHP discret dans un dossier inattendu, le repérer nécessite de comparer l’état actuel à une copie saine.
Si vous avez un accès à des backups “avant incident”, c’est idéal. Sinon, vous pouvez au moins comparer avec une installation identique, même version WordPress, même structure.
Évitez de “réparer au feeling” en modifiant un fichier à l’aveugle. C’est le meilleur moyen de casser le site et de masquer la trace.
Les pièges fréquents quand on gère les utilisateurs
Il y a plusieurs pièges qui reviennent. Je vous en cite quelques-uns, parce qu’ils font perdre beaucoup de temps.
Le rôle exact ne vous protège pas
Un compte “éditeur” ou “auteur” peut suffire à publier des contenus malveillants ou à déclencher des flux. Même si vous ne supprimez que les admins, l’attaquant peut garder sa persistance.
La suppression peut déclencher des actions
Dans certains scénarios, le code malveillant surveille la présence de comptes. Il peut recréer un utilisateur dès qu’il détecte la disparition. Si vous supprimez trop tôt, vous relancez involontairement la mécanique.
Les noms d’utilisateurs ressemblent parfois aux vôtres
Parfois, l’attaquant ajoute des comptes avec des schémas qui passent inaperçus, surtout si vous avez déjà des habitudes de naming. Ne cherchez pas seulement des “noms bizarres”.
Un seul compte peut ne pas être “le vrai” problème
Même si vous supprimez le compte que vous voyez, l’origine peut rester active ailleurs. Le symptôme se répète.
Vérifier la base de données: options, tables, et traces invisibles
Quand la compromission passe par la base, il y a des traces. WordPress stocke beaucoup de configuration dans wp_options, et certains plugins créent leurs propres entrées.
Sans rentrer dans des “recettes SQL” qui risquent d’endommager votre base, je vous conseille une méthode prudente:
- identifiez les entrées créées ou modifiées récemment, comparez les versions en base avec un backup sain si vous en avez, cherchez des champs contenant des URLs étranges, des chemins inconnus, ou des charges encodées.
L’enjeu n’est pas de tout supprimer. L’enjeu est d’éliminer ce qui rend l’exécution possible. Souvent, les utilisateurs sont “le résultat” d’une chaîne qui commence plus tôt.
Si vous devez faire des requêtes, faites-le en ayant un backup de la base et idéalement une copie test.
Sécuriser la prochaine étape: empêcher la réapparition
Une fois que vous avez supprimé les utilisateurs créés automatiquement, et neutralisé la source, il reste une question: comment éviter que ça recommence.
Les mesures suivantes ne sont pas “des gadgets”. Elles répondent à des mécanismes concrets d’attaques.
En premier lieu, changez tous les mots de passe des comptes WordPress et des connexions associées. C’est essentiel, surtout si l’attaque a pu passer par vol de session ou réutilisation de mots de passe.
Ensuite, contrôlez les permissions. Un attaquant aime les privilèges élevés, donc limitez les rôles.
Enfin, surveillez. Même avec un nettoyage réussi, une surveillance légère aide à détecter une récidive avant qu’elle ne se transforme en crise.
Voici une deuxième liste, courte, utile pour l’après-nettoyage.
- Vérifier les nouveaux utilisateurs et confirmer qu’aucun compte ne réapparaît après une période de test Contrôler la liste des plugins et thèmes, avec attention aux éléments installés récemment Rechercher les modifications de fichiers et rétablir les fichiers WordPress depuis une source saine si besoin Mettre en place une journalisation (au minimum logs d’accès) et suivre les anomalies Durcir l’accès (mots de passe forts, 2FA si possible, réduction des droits)
Contrôles ciblés sur les utilisateurs: quoi regarder exactement
Pour être efficace, il faut savoir quoi inspecter dans l’écran “Utilisateurs”.
Les points pratiques qui aident vraiment:
- la date de création, surtout si elle tombe dans la même fenêtre horaire que d’autres anomalies, le rôle, et pas seulement l’identifiant, si l’utilisateur a des activités récentes (selon votre configuration), l’email, qui peut donner une indication, même si ce n’est pas une preuve.
Dans certains cas, j’ai vu des utilisateurs créés avec des emails “fourre-tout” qui n’ont rien à voir avec la réalité. Mais parfois l’attaquant utilise un email qui a un sens, juste pour que vous l’ignoriez.
Le bon réflexe reste le recoupement avec le reste: plugins, fichiers, cron, logs.
Quand vous ne pouvez pas identifier la source rapidement
Il arrive qu’on nettoie et qu’on soit bloqué, parce que plusieurs éléments semblent “possiblement” modifiés. Dans ces cas, il faut faire un choix pragmatique.
La stratégie la plus sûre, quand elle est faisable, consiste à:
- restaurer à partir d’un backup sain, réinstaller WordPress et les composants depuis une source fiable, reconfigurer la base avec prudence, puis réappliquer vos thèmes et plugins un par un, en contrôlant l’état à chaque étape.
C’est plus long, mais ça évite de laisser une micro-charge qui recrée des utilisateurs. La complexité vient du fait que WordPress peut fonctionner avec des traces malveillantes très discrètes. Tant qu’elles existent, l’attaquant peut réapparaître.
Si vous êtes sous une contrainte forte de disponibilité, vous pouvez faire un compromis, par exemple désactiver les plugins, remplacer les fichiers WordPress, puis faire une vérification progressive.
Liens entre utilisateurs malveillants et accès au panneau d’administration
Un point utile: un utilisateur malveillant peut exister sans que vous ayez la preuve qu’il s’est connecté. Parfois, l’attaquant crée des comptes uniquement pour déclencher une logique interne, ou pour se garantir une porte d’entrée future.
Inversement, si vous avez une preuve de connexion (logs), vous pouvez dater l’incident plus précisément. On peut aussi repérer la source IP, et parfois comprendre le vecteur: brute force, exploitation, ou vol de session.
Si les logs montrent des tentatives répétées sur le même ensemble d’URL, c’est un indicateur. Si vous voyez des requêtes sur des fichiers qui n’existent pas normalement, c’est un autre indicateur.
Dans tous les cas, le nettoyage des utilisateurs doit être relié à ce que vous observez au niveau exécution.
Récapitulatif orienté action
Vous avez deux objectifs, en réalité:
- couper la persistance (sinon les utilisateurs reviennent), éliminer les comptes et privilèges qui permettent à l’attaquant de continuer.
Les utilisateurs créés automatiquement sont souvent le symptôme le plus visible, mais ils ne sont pas la cause unique. La cause se trouve presque toujours dans un code modifié, un plugin ou un thème, ou une planification malveillante.
Si vous voulez un ordre d’intervention réaliste, c’est:
- limiter la capacité d’exécution pendant l’analyse, isoler ce qui a changé récemment, neutraliser le mécanisme qui recrée les comptes, supprimer les comptes malveillants, vérifier que la situation ne se répète pas.
Le vrai soulagement, c’est quand vous revérifiez après un délai raisonnable et qu’aucun utilisateur n’apparaît à nouveau. Ce silence est un bon signe, à condition d’avoir vraiment traité le mécanisme qui tournait avant.
Un mot sur le “nettoyage complet” et les responsabilités
Quand on fait supprimer malware WordPress, on pense souvent au code. Mais il y a aussi la réalité opérationnelle: vous devez pouvoir prouver que c’est propre, et que vous avez restauré un environnement stable.
Si votre site est lié à du e-commerce, à des données clients, ou à des obligations de conformité, le nettoyage doit être documenté. Au minimum, conservez les étapes, les dates, et les éléments supprimés. Dans les incidents, cette traçabilité fait gagner https://gardewp.fr/ énormément de temps, surtout si un hébergeur ou un prestataire intervient.
Je l’ai appris en gérant des urgences: une bonne sortie d’incident, c’est celle où vous pouvez expliquer ce qui s’est passé et pourquoi vous êtes confiant dans le statut “net”.
Si vous êtes en plein épisode, le meilleur prochain pas est souvent d’arrêter le cycle de création, puis d’investiguer la source. Les utilisateurs malveillants se voient, mais ils ne sont pas seuls. Une fois la cause traitée, la suppression devient une conséquence logique, pas une lutte quotidienne.