En bref : vous ne trouvez des comptes admin inconnus que si vous vérifiez tous les niveaux : le CMS ou la boutique, le panneau d'hébergement, les utilisateurs système du serveur, les accès SSH et les utilisateurs de la base de données. Ne vous fiez pas à la liste des utilisateurs du back-office, car du code injecté peut y cacher des comptes. D'abord documenter et bloquer les découvertes, puis établir la cause, et seulement ensuite supprimer.
Pourquoi un administrateur inconnu est si dangereux
Un compte admin supplémentaire est la porte dérobée la plus commode pour les attaquants. Il n'exige aucun code malveillant, passe inaperçu dans les analyses de fichiers et survit à toute mise à jour. Qui se connecte plus tard avec ce compte ressemble, dans le journal, à un rédacteur normal.
Après PHP2Shell, cette vérification gagne en importance. Les failles CVE-2026-109618 et CVE-2026-109619 permettent l'exécution de code malveillant sans authentification. Qui peut exécuter du code sur le serveur peut aussi écrire dans la base de données et ainsi créer des comptes. Une mise à jour de PHP ferme la faille, mais ne supprime aucun compte créé auparavant.
Pour PHP2Shell, il n'existe pas d'indicateurs de compromission (Indicators of Compromise) publiés et confirmés, donc pas de liste de traces typiques. Un compte inconnu n'est donc pas une preuve de PHP2Shell, mais un indice net d'accès non autorisé, quelle que soit la voie. Un aperçu d'autres signes figure sous Suis-je déjà compromis ?.
Où des comptes admin étrangers peuvent se cacher
De nombreux exploitants ne regardent que dans le CMS. Les attaquants pensent en niveaux, et chaque niveau a ses propres comptes :
| Niveau | Où regarder | À quoi faire attention |
|---|---|---|
| CMS ou boutique | gestion des utilisateurs et table de la base de données des utilisateurs | rôle administrateur, date de création, adresse e-mail étrangère |
| Panneau d'hébergement | utilisateurs, comptes supplémentaires, comptes FTP | comptes que personne dans l'équipe n'a créés |
| Serveur Linux | /etc/passwd, groupes sudo ou wheel, sudoers |
autres comptes avec UID 0, nouveaux shells de connexion |
| SSH | authorized_keys de tous les utilisateurs |
clés sans propriétaire connu |
| Base de données | table des utilisateurs du serveur de base de données | utilisateurs avec droits globaux ou hôte % |
| Services externes | registrar, DNS, Search Console, CDN | propriétaires ou ayants droit supplémentaires |
Le niveau SSH est assez autonome pour un article à part : Trouver et supprimer les clés SSH inconnues.
Trouver des comptes admin étrangers dans le CMS, y compris cachés
La liste des utilisateurs du back-office est produite par l'application elle-même. Si du code injecté s'exécute, il peut en filtrer certaines entrées. Les outils qui regardent directement les données enregistrées sont donc plus fiables. Pour WordPress, WP-CLI liste tous les administrateurs avec leur date de création :
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
Une interrogation en lecture dans la base de données va encore un niveau plus profond. Elle montre chaque compte auquel le rôle d'administrateur est attribué, indépendamment de ce qu'affiche l'interface. Le préfixe de table wp_ est à adapter à votre installation :
SELECT u.ID, u.user_login, u.user_email, u.user_registered
FROM wp_users u
JOIN wp_usermeta m ON m.user_id = u.ID
WHERE m.meta_key = 'wp_capabilities'
AND m.meta_value LIKE '%administrator%'
ORDER BY u.user_registered DESC;
Comparez les résultats du back-office, de WP-CLI et de la base de données. Si un compte n'apparaît que dans la base de données, c'est un signal d'alerte fort, car du code est alors en jeu pour le cacher. Pour d'autres systèmes comme Shopware, TYPO3 ou Joomla, le même principe s'applique : interroger directement la table des utilisateurs et comparer avec l'affichage du back-office. Les tables concernées figurent dans la documentation de l'éditeur.
Vérifier les utilisateurs système et ceux de la base de données
Sur le serveur lui-même, les comptes avec droits root et ceux qui peuvent se connecter intéressent surtout. Les commandes suivantes ne font que lire :
# Comptes avec UID 0 (normalement seulement root)
awk -F: '$3 == 0 {print $1}' /etc/passwd
# Comptes avec un vrai shell de connexion
grep -vE '(nologin|false)$' /etc/passwd
# Membres des groupes d'administration
getent group sudo wheel
# Règles sudo supplémentaires
sudo ls -la /etc/sudoers.d/
sudo grep -rvE '^\s*(#|$)' /etc/sudoers /etc/sudoers.d/
# Dernières connexions avec la date complète
last -F | head -30
Sur le serveur de base de données, vous vérifiez quels utilisateurs existent et quels droits ils ont :
SELECT user, host FROM mysql.user ORDER BY user;
SHOW GRANTS FOR 'anwendung'@'localhost';
Une application a en règle générale besoin d'un utilisateur avec des droits sur exactement une base de données. Un utilisateur supplémentaire avec des droits globaux, autorisé à accéder depuis n'importe quel hôte (%), doit être clarifié.
N'oubliez pas les comptes en dehors du serveur. Qui a accès au contrat de domaine ou à la gestion DNS peut rediriger les visiteurs ou faire émettre des certificats sur des serveurs étrangers. Un propriétaire supplémentaire dans la Google Search Console peut soumettre des sitemaps et modifier des paramètres. Passez donc en revue chez le registrar, le fournisseur DNS, le CDN et la Search Console la liste des ayants droit et comparez-la avec ce que connaît votre équipe.
Comment réagir correctement à une découverte
Le premier réflexe est de supprimer immédiatement le compte étranger. Mais une trace importante disparaît alors : la date de création délimite souvent le moment où l'attaquant était dans le système. Mieux vaut cet ordre :
- Documenter : consigner le nom d'utilisateur, l'ID, l'e-mail, la date de création, le rôle et la dernière activité avec l'heure, idéalement sous forme de capture d'écran et d'export.
- Bloquer plutôt que supprimer : retirer le rôle, remplacer le mot de passe par une valeur aléatoire ou désactiver le compte.
- Délimiter la période : vérifier les journaux autour de la date de création. Quelles requêtes y a-t-il eu peu avant, quels fichiers ont changé ?
- Vérifier d'autres niveaux : qui crée un compte n'en laisse que rarement un seul. Passer aussi en revue les fichiers, les tâches cron, les clés SSH et la base de données.
- Nettoyer et renouveler les accès : ce n'est qu'après le nettoyage et la mise à jour de PHP que l'on renouvelle tous les mots de passe, clés et sessions.
Une remarque de prudence : tout compte inconnu n'est pas malveillant. Des agences, d'anciens prestataires ou des extensions de maintenance créent parfois leurs propres comptes. Clarifiez cela avant de donner l'alerte, mais clarifiez-le rapidement.
Empêcher le retour
Après le nettoyage, les comptes admin devraient être l'exception, non la règle. Ont fait leurs preuves : des comptes personnels plutôt que des accès partagés, le moins d'administrateurs possible et une authentification à deux facteurs pour les accès admin. Déterminez en outre qui peut créer de nouveaux comptes admin et où cela est documenté.
Une interrogation régulière comme celles ci-dessus, par exemple chaque semaine et avec comparaison à la semaine précédente, rend rapidement visibles les nouveaux comptes. Pour WordPress, le guide Trouver les portes dérobées dans WordPress aide en complément.
Comment PHP SOS aide-t-il concrètement ?
- Nous vérifions tous les niveaux de comptes, du CMS au serveur jusqu'à la base de données, et comparons l'affichage du back-office avec les données enregistrées.
- Nous sauvegardons les découvertes avec horodatages avant que des comptes soient bloqués ou supprimés.
- Dans le cadre de la réponse aux incidents, nous établissons comment le compte est né et s'il existe d'autres portes dérobées.
- Nous renouvelons les accès dans le bon ordre et mettons en place un contrôle continu des nouveaux comptes admin.
Questions fréquentes
Dois-je supprimer immédiatement un compte admin inconnu ?
Mieux vaut ne pas le faire tout de suite. Documentez d'abord le nom d'utilisateur, la date de création, l'adresse e-mail et la dernière activité, puis bloquez le compte. On ne supprime qu'une fois les traces sauvegardées, car la date de création est souvent un indice important du moment de l'intrusion.
Un compte admin peut-il être invisible dans le back-office ?
Oui. Du code injecté peut masquer certains comptes dans la liste des utilisateurs de l'interface. Une interrogation directe de la base de données ou un outil en ligne de commande montre en revanche tous les comptes enregistrés. Ne regardez donc pas seulement dans le back-office.
Quels niveaux dois-je vérifier en dehors du CMS ?
Panneau d'hébergement, accès FTP et SFTP, utilisateurs système du serveur y compris droits sudo, clés SSH, utilisateurs de la base de données ainsi que comptes chez le registrar, le DNS et la Search Console. Un attaquant n'a besoin que d'une de ces portes pour revenir.
Suffit-il de changer tous les mots de passe après la découverte ?
Non. Un compte étranger montre que quelqu'un a eu accès. Il faut alors aussi clarifier la porte d'entrée, d'autres portes dérobées et d'éventuelles fuites de données. Ne changez les mots de passe qu'après le nettoyage et depuis un appareil sain.