Nettoyer WordPress infecté : gérer les utilisateurs créés via API

Quand un site WordPress se fait compromettre, on a souvent le même premier réflexe: paniquer, changer le thème, réinstaller des fichiers. Ça peut aider, mais ce n’est pas là que se joue le vrai rapport de force. L’attaque moderne vise surtout l’accès durable. Et dans WordPress, l’accès durable passe souvent par des utilisateurs créés ou modifiés sans que vous ayez la moindre trace côté interface.

Le symptôme est parfois très discret. Une page “très récente” apparaît. Un plugin qui n’a jamais été installé se met en route. Ou, plus directement, vous découvrez dans “Utilisateurs” un compte utilisateur créé “il y a quelques minutes”, avec un rôle élevé, un nom étrange, et une date qui ne colle à rien.

Ce billet traite un cas fréquent et particulièrement piégeux: gérer les utilisateurs créés lors d’une infection, notamment quand ils l’ont été via une API ou un mécanisme automatisé. L’objectif est simple: reprendre la main, couper la persistance, puis revenir à un état propre et vérifiable.

Le vrai problème, ce n’est pas l’utilisateur visible, c’est la persistance

Dans un incident WordPress, l’attaque n’est pas uniquement “injecter du code quelque part”. Elle cherche surtout à survivre au nettoyage initial. Un utilisateur nouvellement créé est une forme de persistance. Même si vous supprimez le plugin malveillant, cet utilisateur peut réinstaller des extensions, modifier des pages, reprogrammer des tâches, ou re-téléverser des scripts à travers l’API.

J’ai vu des sites où le support “supprimer le compte suspect” semblait suffisant. À la reprise, tout allait bien pendant quelques heures. Puis le même scénario revenait, parce que le compte n’était qu’un verrou parmi d’autres, et le verrou se faisait réapprovisionner automatiquement. Dans ce contexte, parler de “nettoyer site WordPress infecté” sans aborder l’accès et l’API revient à traiter un symptôme et pas la cause.

Une infection “via API” ne signifie pas forcément que quelqu’un a tapé à la main des requêtes depuis un script. Ça peut être un composant du malware qui utilise WordPress REST API, WP-CLI, des endpoints internes, ou encore une fonction backend exposée par un plugin vulnérable. Le résultat, lui, est concret: des créations d’utilisateurs, des changements de rôles, des tokens qui restent valides, et parfois des entrées dans la table usermeta qui ne sont pas visibles dans l’interface.

Avant d’agir: figer le contexte sans aggraver la compromission

Avant de supprimer des comptes, prenez deux minutes pour limiter le risque d’aggraver la situation. La pire erreur, c’est de faire un nettoyage “à l’aveugle” alors que le site continue de recevoir des requêtes malveillantes.

Si vous avez accès au serveur, vérifiez rapidement si l’attaque est active au moment où vous intervenez. Des pics d’accès inhabituels, une charge CPU élevée, ou des erreurs répétées dans les logs peuvent indiquer que vous êtes encore en cours de compromission. Si vous pouvez mettre le site en mode maintenance, le temps de reprendre la main, faites-le. Ça ne supprime pas le malware, mais ça réduit les chances que des actions automatiques se rejouent pendant que vous corrigez.

Ensuite, copiez au minimum ce qui peut vous servir à documenter l’incident: export base de données, capture des utilisateurs existants, liste des plugins installés et leur date, et configuration WP. Le but n’est pas de produire un rapport juridique, mais de pouvoir revenir en arrière si une suppression casse un élément légitime (par exemple un plugin de gestion multi-sites ou un compte de service utilisé par votre hébergeur).

Repérer les utilisateurs créés de façon anormale

Dans WordPress, les utilisateurs “normaux” ont des patterns. Ils ont des noms que vous reconnaissez, des dates cohérentes, et souvent un historique d’actions côté “Historique” ou “Activité” si vous avez des plugins de journalisation. Les comptes créés par un script ont plus souvent des noms imprévisibles, des emails suspects, et un rôle élevé (administrateur, éditeur, auteur).

Un détail qui m’a plusieurs fois servi: les comptes “administrateur” créés alors que personne n’a fait de demande d’accès. La date suffit parfois, même sans logs. Si vous voyez par exemple un compte administrateur créé à 03:12 pendant une plage où vous dormiez, c’est un signal fort.

Mais ne vous arrêtez pas aux seuls noms. Une infection peut aussi modifier un compte existant, ou ajouter des métadonnées qui donnent des privilèges supplémentaires. Donc la question à se poser est double: “qui a été créé” et “qu’est-ce qui a été fait autour de ces identités”.

Ce que vous regardez dans l’interface

Dans “Utilisateurs”, triez et comparez:

date de création rôle email présence de biographie ou de champ non standard incohérence avec les accès habituels

Si votre tableau de bord affiche l’historique des changements, croisez avec l’heure d’apparition de contenu suspect. Un utilisateur créé à 03:12 et un lot de pages modifiées entre 03:13 et 03:20, c’est un couplage très probable.

Nettoyer sans casser: plan d’action centré sur l’utilisateur et les accès

Le nettoyage “propre” suit une logique: couper l’accès, retirer la persistance, puis vérifier l’intégrité.

Je vous propose un plan opérationnel, qui privilégie le contrôle et limite les mauvaises surprises.

1) Mettre le site sous contrôle immédiat

Si vous pouvez basculer en mode maintenance, faites-le. Puis vérifiez l’accès admin depuis vos IP habituelles uniquement si votre hébergeur ou un plugin de firewall le permet. Cette étape réduit les requêtes malveillantes pendant que vous manipulez les comptes.

Ensuite, désactivez temporairement tout mécanisme qui pourrait créer ou propager du contenu pendant que vous intervenez. Selon votre stack, cela peut signifier désactiver des plugins suspects en premier, ou bloquer l’accès aux endpoints REST si vous avez cette capacité.

2) Identifier les comptes suspects avec un critère simple

Il y a une façon efficace de trier sans se perdre: repérer les comptes qui “ne devraient pas exister”.

Voici un mini-contrôle que j’utilise en incident, avec une attention particulière aux signes d’automatisation.

utilisateur créé récemment, sans demande rôle administrateur ou éditeur pour un compte “non reconnu” email à domaine non habituel ou incohérent avec votre organisation utilisateur actif (connexion ou actions) alors que vous n’aviez rien déclenché présence d’éléments bizarres dans les champs de profil, même si WordPress n’en affiche pas tous les détails

Si vous avez plusieurs comptes, priorisez ceux qui ont les rôles les plus élevés.

3) Supprimer les comptes à haut privilège, puis vérifier que personne ne les recrée

Supprimer un utilisateur “suspect” est une action nécessaire, mais pas toujours suffisante. Si la création d’utilisateurs se fait via API, il est probable que le malware ait une routine qui recroira des comptes, parfois avec un mot de passe différent, parfois avec un email différent, parfois en créant un “compte à usage unique” pour contourner votre blocage.

Donc, après suppression, surveillez. Si vous observez une recréation dans la foulée, vous tenez un levier: il faut chercher le composant qui déclenche la création. Le composant peut être:

un plugin compromis un script dans le thème ou un fichier uploadé une tâche cron malveillante une entrée dans le backend qui appelle l’API à l’instant T une porte d’entrée (formulaire, endpoint vulnérable)

4) Couper les jetons et la session si nécessaire

WordPress utilise des cookies de session. Si un attaquant a déjà pris une session, supprimer le compte ne suffit pas à forcément empêcher l’usage immédiat s’il garde un jeton valide côté navigateur ou côté mécanisme automatisé.

Dans la pratique, “révoquer les sessions” dépend des outils que vous avez. Certains plugins de sécurité le font. Sinon, une approche plus drastique consiste à forcer une rotation côté configuration, ou à mettre en place une règle de sécurité plus large.

Je préfère une méthode concrète et prudente: après suppression des comptes et nettoyage des vecteurs d’exécution, vous déployez un reset des mots de passe des comptes légitimes et vous appliquez une rotation complète. Oui, c’est plus contraignant. Mais sur une infection, la contrainte administrative est souvent inférieure au coût d’une récidive.

Quand la création passe par l’API: comment raisonner au lieu de deviner

Le point délicat dans votre titre est “gérer les utilisateurs créés via API”. Même si vous ne savez pas exactement quelle API est utilisée, vous pouvez raisonner sur le comportement.

Un malware qui utilise l’API doit réussir au moins une étape d’authentification ou d’autorisation. Ça veut dire qu’il s’appuie soit sur une faille qui contourne les contrôles, soit sur un accès existant (compte admin compromis), soit sur un endpoint mal protégé.

Dans tous les cas, vous avez une piste: les créations d’utilisateurs et les modifications sont probablement synchronisées à une activité réseau ou à une exécution backend.

Voici ce que j’observe généralement, sans prétendre que ce soit universel:

l’attaque produit des entrées dans les logs du serveur au moment où les comptes apparaissent les utilisateurs “légitimes” voient leurs mots de passe réinitialisés ou leurs sessions perturbées les plugins installés récemment déclenchent des actions automatiques des appels REST sont faits en série, souvent à travers une identité compromise

Si votre hébergeur fournit https://gardewp.fr/nettoyage-malware-wordpress/ des logs d’accès (Nginx, Apache) et des logs PHP, vous pouvez vérifier à quelle période les requêtes vers des endpoints ont explosé. Les détails dépendent du serveur, mais la logique reste la même: vous cherchez le moment du “déclenchement”, puis vous suivez la trace vers le composant responsable.

Nettoyer le vecteur d’exécution, pas seulement les comptes

Supprimer les utilisateurs est une opération de coupure de l’accès. Mais le malware peut continuer à tourner tant que l’exécution n’est pas neutralisée.

À ce stade, j’aborde le nettoyage en deux temps: retirer la surface d’exécution https://gardewp.fr/ et restaurer une base saine.

Si un plugin a été ajouté juste avant l’apparition des comptes, il est candidat prioritaire. Si un fichier suspect a été modifié dans le thème ou un dossier d’uploads, il faut le traiter comme une extension “fantôme”. Si un cron a été ajouté, il faut supprimer la tâche et vérifier qu’aucun équivalent n’a été recréé.

Je sais que certains sites sont en “tout en un”, avec peu d’accès aux détails. Pourtant, même sans tout voir, vous pouvez avancer. Le principe: une fois les comptes supprimés, observez ce qui se passe sur le site pendant une période courte. Si un plugin suspect est encore actif, il va souvent laisser d’autres traces.

Contrôler les rôles, car une infection sait se cacher derrière un “compte légitime”

Les attaques ne se contentent pas toujours de créer des utilisateurs nouveaux. Parfois, elles donnent des privilèges à un compte existant, ou elles modifient les rôles via des mécanismes qui ne sont pas immédiatement visibles.

Donc, ne vous contentez pas de supprimer les comptes créés. Passez en revue l’ensemble des utilisateurs avec un regard “permissions”, pas seulement “dates”.

Si un utilisateur a un rôle supérieur à celui attendu pour votre organisation, suspectez. Par exemple, un compte qui devrait être “abonné” ou “auteur” et qui devient “administrateur” est un signal.

Et si vous gérez un site avec plusieurs contributeurs, il faut un peu de jugement. Tous les projets ont des exceptions, et WordPress laisse parfois des rôles évoluer au fil du temps. C’est là que l’historique compte: quels comptes avez-vous créés vous-même, quels comptes avez-vous reçus d’un prestataire, lesquels ont été ajoutés avec votre accord.

Revenir à un état fiable: mots de passe, plugins, et validation

Une fois les comptes suspects supprimés et les vecteurs d’exécution neutralisés, vous devez reconstruire la confiance. WordPress est une plateforme qui accepte beaucoup de variations. Le danger, c’est de “croire” que c’est propre parce que la page a cessé d’être défigurée.

La validation doit être active.

Réinitialiser et verrouiller

Commencez par réinitialiser tous les mots de passe des comptes légitimes, pas seulement celui qui semble avoir été compromis. Changez aussi les accès de service: comptes utilisés par votre outil d’hébergement, votre intégration CI, votre plugin d’automatisation, ou vos connecteurs.

Ensuite, activez des contrôles qui rendent la prochaine intrusion plus difficile, même si votre sécurité actuelle vous semblait suffisante avant incident. L’idée n’est pas de surcharger le site, mais d’augmenter le coût pour l’attaquant.

Dans un contexte infection, un point clé est la gestion des tentatives. Une augmentation de protections trop agressive peut bloquer des tâches légitimes. Donc ajustez, surveillez, et ne laissez pas un réglage “par défaut” sans comprendre son impact.

Vérifier l’intégrité sans tomber dans l’illusion

Réinstaller “tout” peut être un bon geste, mais seulement si vous supprimez également les traces du malware. Sinon, vous remplacez une partie et vous conservez l’autre.

En pratique, selon votre configuration, vous pouvez:

comparer la base de fichiers de WordPress core à une source de référence réinstaller les thèmes et plugins à partir de versions propres vérifier que les uploads ne contiennent pas de fichiers exécutables inattendus reconstruire la base à partir d’une sauvegarde saine si vous suspectez une altération en profondeur

Je privilégie souvent une approche basée sur les sauvegardes. Si vous avez un snapshot fiable pris avant incident, restaurer et ensuite appliquer vos changements à nouveau est fréquemment plus rapide que de tenter un “chirurgical” parfait sur une base infectée.

Un cas concret: quand les utilisateurs reviennent après suppression

J’ai en tête un incident type. Un client me signale qu’un compte “admin” réapparaît environ toutes les 30 à 60 minutes. Les premières tentatives consistaient à supprimer le compte. Ça ne tenait pas. L’interface WordPress affichait le compte, puis il disparaissait, puis il revenait.

Ce que ça révèle, dans la majorité des cas, c’est l’existence d’un mécanisme automatisé. Soit un cron côté WordPress, soit une routine dans un plugin compromis, soit un script externe qui utilise l’API pour créer un utilisateur.

La décision qui a réellement résolu le problème n’a pas été “supprimer plus de comptes”. C’était: 1) identifier le composant exécutant (plugin, fichier, tâche) 2) le neutraliser 3) ensuite seulement relancer un nettoyage des comptes, des rôles et des sessions

Sans la neutralisation, le site était en permanence en train de se réinfecter, même si vous corrigiez le symptôme. C’est précisément cette logique qui explique l’importance de traiter “via API”, car l’attaquant n’a pas besoin de repasser par l’interface, il peut opérer par requête.

Où regarder pour trouver la routine API ou la porte d’entrée

Il n’y a pas une seule place. Mais vous pouvez vous focaliser sur des zones qui “respirent” le plus souvent dans les incidents.

Le plus rentable est de suivre l’angle “ce qui a été modifié avant”. Quand un incident commence, il y a un instant de bascule. Si vous avez des logs ou des dates, vous pouvez les exploiter.

Ensuite, côté WordPress, je regarde notamment:

les plugins installés récemment ou mis à jour dans la fenêtre de l’incident les fichiers modifiés dans les dossiers de thème (y compris dans des sous-dossiers) les tâches cron qui ajoutent, suppriment, ou appellent des endpoints les paramètres de configuration et les fichiers ajoutés dans des répertoires d’uploads

Et côté serveur, les logs d’accès indiquent parfois des requêtes en rafale vers des chemins spécifiques. Même si vous ne comprenez pas chaque endpoint, vous voyez où l’attaque tape.

Voici les signaux qui, dans ma pratique, indiquent une automatisation liée à l’API ou à un mécanisme similaire.

créations répétées d’utilisateurs avec des patterns d’emails proches connexions ou actions réalisées à des heures non cohérentes avec l’activité humaine changements de rôle à chaque cycle d’apparition apparition de plugins juste après la création d’un utilisateur pics de requêtes autour d’URLs d’API ou d’actions backend

Cas particuliers, multi-sites et rôles délégués

WordPress en multi-sites a ses propres règles. Un compte peut être créé dans un sous-site, et la compensation peut être plus compliquée car les permissions se gèrent aussi au niveau réseau. Dans ces cas, supprimer un utilisateur sur un site ne règle pas forcément la persistance au niveau “réseau”.

De même, si vous avez des rôles délégués, contributeurs, éditeurs, ou des comptes de prestataires avec des responsabilités précises, vous devez faire la différence entre un compte “non reconnu” et un compte “reconnu mais mal configuré”.

Le bon sens ne suffit pas, mais il guide. Si vous avez documenté qui a accès, votre décision de suppression devient plus rapide. Si vous ne l’avez pas fait, la première urgence est de recréer une liste fiable des accès autorisés. Ce n’est pas agréable, mais ça accélère énormément le tri.

Se prémunir après nettoyage, sans tomber dans la complexité inutile

Après un incident, il est tentant de tout renforcer. Les excès existent aussi, et on peut finir avec un site instable. Ma recommandation est pragmatique: renforcer là où l’attaque gagne du temps.

Ce que je privilégie, une fois le site redevenu stable:

réduire le nombre de comptes à privilèges appliquer des mots de passe solides, uniques, et une hygiène d’accès claire limiter les plugins au strict nécessaire, et vérifier les sources surveiller les créations d’utilisateurs et les changements de rôles conserver une routine de sauvegarde testée, pas seulement “planifiée”

Si vous avez déjà un système de surveillance, exploitez-le. Si vous n’en avez pas, la surveillance des utilisateurs est l’un des meilleurs retours sur investissement, parce que les infections reviennent souvent par cette porte.

Vérifier que le “nettoyage utilisateurs” a bien tenu

Une fois tout remis à plat, le test le plus parlant est temporel. Sur une attaque automatisée, le comportement se manifeste sur des cycles. Si, après plusieurs heures et parfois 1 à 2 jours, vous n’observez ni création de comptes inconnus, ni changements de rôles, ni installation de plugins non attendus, vous êtes sur la bonne trajectoire.

Mais gardez une règle simple: l’absence de symptôme immédiat ne prouve pas la propreté totale. Elle prouve au moins que la persistance connue a été coupée.

C’est pour ça que je recommande de garder une fenêtre d’observation renforcée: vérifiez les utilisateurs, les modifications de thèmes et plugins, les tâches programmées, et l’apparition éventuelle de contenu suspect.

Et si vous travaillez avec un environnement où vous avez des mises à jour fréquentes, évitez de publier de nouvelles fonctionnalités pendant cette période. Un site qui bouge change trop de variables. Le jour où vous identifiez une nouvelle anomalie, vous voulez que le diagnostic reste clair.

Conclusion opérationnelle: gérer les utilisateurs via API, c’est gérer la chaîne entière

Le point central est assez direct, mais il se refuse aux raccourcis. Quand des utilisateurs sont créés via API pendant une infection WordPress, supprimer ces comptes est indispensable. Mais si vous ne neutralisez pas la routine d’exécution, vous ne faites que repousser l’inévitable.

La bonne approche combine trois actions, dans le bon ordre: couper l’accès, retirer la persistance, puis valider l’intégrité. C’est ce séquencement qui transforme un nettoyage “qui soulage” en un nettoyage “qui tient”.

Si vous êtes en plein incident, votre priorité pratique aujourd’hui peut se résumer à une idée: trouver ce qui crée le compte, pas seulement le compte lui-même. C’est souvent là que se cache la vraie solution pour nettoyer site WordPress infecté, durablement.