Deux campagnes ont créé plus de 4 millions de fausses identités pour énumérer les comptes Microsoft Entra ID, sans connexion. Apprenez à détecter le comportement, pas la menace.
Points clés à retenir
- L’usurpation d’ID client OAuth élimine les détections qui cryptent le nom de l’application ou un ID d’application connu, car le champ lui-même est fabriqué, pivoté ou vide.
- AADSTS700016 associé à un ID client non reconnu peut signifier des informations d’identification valides, et non un enregistrement d’application interrompu : traitez-le comme un signal de triage et non comme du bruit.
- Une logique de détection efficace met en corrélation la cardinalité de l’ID client, les noms d’applications manquants et les séquences d’erreurs AADSTS sur une fenêtre temporelle, et non sur un événement unique.
- Un runbook de réponse répété (réinitialisation, révocation, révision) compte autant que la requête de détection elle-même, et le coût de son omission apparaît comme une prise de contrôle de compte, et pas seulement comme une fatigue des alertes.
Le signal caché à la vue de tous
Imaginez une file d’attente d’alertes de connexion ayant échoué par rapport à Microsoft Entra ID. Chacun pointe vers un ID d’application différent. Aucun des identifiants n’est enregistré dans le locataire. Aucun ne franchit à lui seul un seuil de volume. Rien dans la file d’attente ne se lit comme une campagne coordonnée ; cela se lit comme les débris normaux d’enregistrements d’applications expirés et de scripts de test oubliés que chaque locataire accumule. Un analyste recherchant une application nommée présentant un pic de pannes ferait défiler cette file d’attente sans y jeter un deuxième coup d’œil. C’est là le point. Depuis décembre 2025, au moins deux acteurs de la menace ont élaboré des campagnes d’énumération spécialement conçues pour ressembler à du bruit de configuration plutôt qu’à une attaque, et la différence entre les deux est une question d’ingénierie de détection, pas seulement une question de renseignements sur les menaces.
Le mécanisme, en trois codes d’erreur
La technique abuse du flux ROPC (Resource Owner Password Credentials) OAuth 2.0, dans lequel une seule demande de jeton regroupe un nom d’utilisateur, un mot de passe et un ID client. Trois codes de réponse Entra ID transmettent le signal qui compte.
AADSTS50034 signifie que le nom d’utilisateur n’existe pas. AADSTS50126 signifie que le nom d’utilisateur existe, mais que le mot de passe est erroné. AADSTS700016 se déclenche lorsque le nom d’utilisateur et le mot de passe sont tous deux valides mais que l’ID client n’est pas reconnu. Ce dernier code est celui autour duquel il vaut la peine de construire une détection : à lui seul, il ressemble à un problème d’enregistrement d’application qu’un administrateur a oublié de nettoyer. Lorsqu’il est associé à un identifiant client inconnu et en constante rotation, cela peut signifier qu’un attaquant a déjà confirmé une paire d’identifiants fonctionnels et qu’il est sur le point de prendre le contrôle du compte.
ROPC persiste dans plus d’environnements que prévu par les équipes de sécurité. Il survit dans les scripts existants, les pipelines CI et les intégrations tierces construites avant les conseils de Microsoft pour l’éviter, précisément parce que c’est la voie de moindre résistance pour les développeurs qui n’ont jamais besoin d’ouvrir un navigateur. Cette base installée est ce qui donne à la technique la marge de manœuvre nécessaire. Les attaquants n’exploitent pas une mauvaise configuration rare ; ils exploitent un flux encore suffisamment courant pour se cacher à l’intérieur.
Deux campagnes, une lacune de détection
UNK_pyreq2323. Proofpoint a suivi cette campagne exécutée à partir de l’infrastructure AWS, en modifiant les derniers chiffres d’un véritable identifiant d’application Exchange Online sur plus de 700 000 variantes, en réutilisant chacune d’entre elles sur une douzaine de comptes maximum avant de la supprimer. La campagne a ciblé plus d’un million d’utilisateurs répartis sur environ 4 000 locataires, et environ 28 % des comptes touchés ont été verrouillés.
UNK_OutFlareAZ. Exécutée principalement via Cloudflare, cette campagne a complètement ignoré la mutation et a généré un nouvel UUID aléatoire par requête : 3,7 millions d’identifiants usurpés sur plus de deux millions de comptes, avec un pic de près de 720 000 utilisateurs ciblés le 15 mars 2026.
Les propres chercheurs de Proofpoint disent qu’ils ne peuvent pas encore confirmer s’il s’agit d’un seul acteur ou de deux clusters indépendants convergeant vers la même astuce via des discussions sur des forums et des essais et erreurs, un point également abordé par Help Net Security dans son rapport sur la recherche. À des fins de détection, cette ambiguïté n’a pas d’importance. Les deux campagnes contournent le même contrôle, les seuils de volume par application, en utilisant le même écart : un champ d’identifiant non corrélé et jetable dont personne ne surveille la cardinalité.
Pourquoi s’agit-il d’un problème de RSSI, pas seulement d’un problème de file d’attente
Un taux de verrouillage de 28 % sur une campagne impliquant un million d’utilisateurs n’est pas une erreur d’arrondi. Il s’agit d’un coût pour le service d’assistance, d’un impact sur la productivité et, pour chaque compte sur lequel AADSTS700016 a été déclenché avant le verrouillage, d’un identifiant en direct qu’un attaquant a déjà validé et peut utiliser ailleurs : accès à la boîte aux lettres, octroi du consentement OAuth, mouvement latéral vers un SaaS connecté. L’écart de détection ici n’est pas cosmétique. C’est la différence entre détecter un événement d’identification validé alors qu’il est encore isolé d’une tentative d’authentification et le découvrir trois semaines plus tard à partir d’une règle de transfert de boîte aux lettres ou d’une demande électronique frauduleuse. C’est ce qui fait que cela vaut la peine d’être une règle, et pas seulement une note de bas de page dans un résumé d’informations sur les menaces.
Construire la détection
Une règle réalisable reconstruit la séquence de requête au lieu de noter un événement isolément. Sur les journaux de connexion Entra ID, ou l’ingestion SIEM équivalente, la logique de base ressemble à ceci :
SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType in ("50034", "50126", "700016") or isempty(AppDisplayName)
| summarize
DistinctClientIDs = dcount(AppId),
ResultCodes = make_set(ResultType),
Usernames = make_set(UserPrincipalName)
by SourceIPAddress, UserAgent, bin(TimeGenerated, 15m)
| where DistinctClientIDs > 5
| where ResultCodes has "700016"Les deux variables les plus importantes sont les DistinctClientID, car une source unique parcourant de nombreux ID d’application non enregistrés indique que les seuils par application manquent et la présence de AADSTS700016 dans cette même fenêtre, qui élève l’événement du bruit de configuration à une éventuelle validation des informations d’identification en cours. Superposez la détection du modèle de nom d’utilisateur, la progression alphabétique ou du dictionnaire entre les tentatives provenant de la même source, pour détecter spécifiquement le modèle de liste de mots de style OutFlareAZ.
Ajustez le seuil DistinctClientIDs par rapport à la référence de votre propre locataire avant de lui faire confiance en production. Une équipe de développement exécutant CI sur une poignée d’enregistrements d’applications de test peut produire une version plus petite de la même forme, et les politiques d’accès conditionnel limitées uniquement aux applications nommées ne détecteront pas un ID client fabriqué qui ne correspond jamais à la portée d’une application prévue en premier lieu.
Intégrez la règle aux workflows SOAR ou de billetterie existants plutôt qu’à un tableau de bord autonome que personne ne vérifie le vendredi après-midi. Une détection qui se déclenche dans la même file d’attente que les alertes de pulvérisation de mot de passe et de voyage impossible est triée avec la même urgence ; celui qui atterrit dans un rapport d’identité et d’hygiène isolé est lu des semaines plus tard, voire pas du tout.
Séparer le signal du bruit
Tous les événements de nom d’application vide ou 700016 ne constituent pas une attaque. Les enregistrements d’applications supprimés, le consentement multi-tenant expiré, les appels de point de terminaison de mauvais locataire et les pipelines CI pointés vers le mauvais ID client produisent tous un bruit similaire. Deux filtres réduisent considérablement le taux de faux positifs. Une mauvaise configuration légitime est presque toujours de faible cardinalité, un ou deux ID client, et non des dizaines, et elle se répète à partir d’une infrastructure interne connue. Le modèle d’attaque est à cardinalité élevée et provient d’ASN ou de gammes de fournisseurs d’hébergement inconnus. Les références croisées avec les alertes de pulvérisation de mot de passe et de voyage impossible existantes avant de les escalader évitent d’appeler un analyste pour un principal de service obsolète, et le suivi de la précision de la règle au cours de ses premières semaines, des incidents confirmés par rapport aux incendies totaux, vaut la peine d’être fait avant de la traiter comme étant de qualité production. Documentez les critères de tri ainsi que la règle elle-même, car le prochain analyste en poste a besoin du même raisonnement pour clôturer un ticket en toute confiance plutôt que de l’escalader par prudence.
Le runbook de réponse
Lorsque le signal corrélé se déclenche, le runbook doit être court et répété avant d’être nécessaire, et non improvisé pendant l’incident. Forcez la réinitialisation du mot de passe sur le compte concerné, révoquez les sessions actives et actualisez les jetons, et examinez l’activité de connexion et d’accès à la boîte aux lettres pour les jours suivant l’appel AADSTS700016, car il s’agit de la fenêtre dans laquelle un identifiant confirmé est utilisé ailleurs.
Le retrait complet de ROPC, la migration des applications interactives vers des charges de travail d’authentification et de service basées sur un navigateur vers des identités gérées ou des principes de service basés sur des certificats, supprime le flux dont dépend cette technique. Jusqu’à ce que cette migration soit terminée, la détection ci-dessus est ce qui se situe entre un ticket fermé en raison du bruit de configuration et une tentative de piratage de compte interceptée.
La leçon plus large pour les ingénieurs en détection
La leçon réutilisable ici ne concerne pas spécifiquement OAuth. Tout champ qu’un défenseur enregistre mais qui n’est pas corrélé (ID d’application, agent utilisateur, ASN, quoi qu’il arrive ensuite) est un candidat pour qu’un attaquant fragmente son trafic jusqu’à ce que les seuils par champ cessent de se déclencher.
Quatre millions de fausses applications, voilà à quoi ressemble cet écart à grande échelle lorsque personne ne surveille la cardinalité au lieu du volume, et c’est le même manuel de jeu sous-jacent que les comptes valides de MITRE ATT&CK : comptes cloud, T1078.004 : un attaquant utilisant des informations d’identification techniquement valides. Le correctif se généralise quel que soit le champ exploité ensuite. Créez des détections autour de séquences comportementales sur plusieurs champs et une fenêtre temporelle, et non sur un seul champ franchissant un seuil statique.
