OAuth client ID spoofing cible Entra ID sans déclencher d'alerte

Une technique invisible contourne la journalisation des connexions Entra ID

Le 13 juillet 2026, Proofpoint a publié une analyse de menace détaillant une technique d'attaque inédite baptisée OAuth client ID spoofing, permettant à des acteurs malveillants de valider des credentials Microsoft Entra ID volés — noms d'utilisateur et mots de passe — sans jamais générer d'événement de connexion réussie dans les journaux d'audit. Cette découverte est fondamentale pour les équipes de sécurité : des campagnes massives de validation de credentials compromis peuvent se dérouler en silence, sans déclencher les alertes SOC habituellement associées aux tentatives de connexion suspectes. L'analyse a été relayée par Help Net Security, The Hacker News et SC Media le même jour, soulignant son impact immédiat sur des millions d'organisations utilisant Microsoft 365.

Pour comprendre la technique, il faut revenir au fonctionnement standard de l'authentification OAuth dans Microsoft Entra ID. Lorsqu'une application demande un token d'accès pour le compte d'un utilisateur, elle peut utiliser le flux OAuth 2.0 Resource Owner Password Credentials (ROPC), qui permet la soumission directe d'un nom d'utilisateur et d'un mot de passe au endpoint token Microsoft. Normalement, une requête ROPC réussie génère un token d'accès ET un événement dans les journaux de connexion Entra ID — un signal que les équipes SOC surveillent activement pour détecter les connexions depuis des IPs suspectes ou des pays inhabituels.

La technique d'OAuth client ID spoofing exploite une subtilité dans le comportement du endpoint token Microsoft. En envoyant une requête POST vers l'endpoint OAuth 2.0 avec un client_id usurpé — c'est-à-dire un identifiant d'application qui n'appartient pas à l'attaquant et qui peut même ne pas exister dans le tenant cible — Microsoft Entra ID retourne des codes d'erreur AADSTS (Azure Active Directory Security Token Service) qui trahissent l'état des credentials soumis. Un code d'erreur spécifique indique que le mot de passe est incorrect, un autre que le compte n'existe pas, un autre encore que les credentials sont valides mais que l'authentification multifacteur est requise, ou qu'une politique d'accès conditionnel bloque la connexion. La clé : aucune de ces réponses ne génère d'événement de connexion réussie dans les journaux Entra ID standard. Les équipes SOC et leurs SIEM sont donc complètement aveugles à ces validations.

Proofpoint a documenté deux campagnes distinctes exploitant cette technique à grande échelle. La première, attribuée à l'acteur référencé UNK_pyreq2323, s'est déroulée de janvier à mars 2026. Cet acteur a utilisé plus de 700 000 client_id usurpés différents, opérant depuis une infrastructure basée sur Amazon Web Services (AWS), pour cibler plus d'un million de comptes répartis dans près de 4 000 tenants Microsoft 365 d'entreprises dans le monde. L'analyse des codes d'erreur retournés a permis à l'acteur de constituer une liste précise de credentials valides, de comptes avec MFA activé et de comptes protégés par des politiques d'accès conditionnel. Un effet secondaire notable : environ 28 % des comptes ciblés ont été verrouillés temporairement suite aux tentatives avec de mauvais mots de passe, causant des perturbations opérationnelles pour les organisations visées même sans intrusion réussie.

La seconde campagne, attribuée à UNK_OutFlareAZ et active depuis décembre 2025, a ciblé plus de deux millions d'utilisateurs avec 3,7 millions d'identifiants d'application aléatoires usurpés, en opérant depuis l'infrastructure Cloudflare Workers pour bénéficier de la rotation d'adresses IP et de la réputation des plages Cloudflare. L'échelle de ces deux campagnes, et le fait qu'elles se soient déroulées pendant des semaines sans déclencher d'alertes dans les SIEM des organisations victimes, illustre l'efficacité redoutable de cette technique d'évasion des contrôles de détection.

L'impact pratique est considérable. Les acteurs opérant ces campagnes accumulent un inventaire structuré de credentials validés : pour chaque compte cible, ils savent si le mot de passe est correct, si la MFA est activée, et si des politiques d'accès conditionnel s'appliquent. Ces informations permettent de prioriser les tentatives d'intrusion réelles vers les comptes sans MFA, ou de développer des techniques de contournement adaptées pour les comptes avec MFA. Les credentials validés peuvent être utilisés directement pour des intrusions ciblées, revendus sur des marchés cybercriminels, ou exploités dans des campagnes de phishing adversary-in-the-middle (AiTM) ciblant les comptes identifiés comme actifs et insuffisamment protégés.

Microsoft a été informé par Proofpoint avant la publication. La réponse officielle de Microsoft est que le comportement observé est une caractéristique inhérente au protocole ROPC standard et non une vulnérabilité per se, mais que les organisations peuvent se protéger en désactivant le flux ROPC dans leurs politiques d'accès conditionnel Entra ID et en adoptant des méthodes d'authentification sans mot de passe. Microsoft Entra ID a d'ailleurs annoncé que les passkeys deviendront la méthode d'authentification par défaut en septembre 2026, ce qui à terme réduira la surface d'attaque des campagnes basées sur des credentials statiques.

Pour la détection, Proofpoint recommande de surveiller les logs au niveau du endpoint OAuth token plutôt que des seuls journaux de connexion standard. Les équipes SOC doivent créer des règles de détection sur les codes d'erreur AADSTS retournés par l'endpoint token en volume anormal depuis des IPs inhabituelles ou des user-agents suspects. Microsoft Defender for Cloud Apps et certaines solutions SIEM compatibles avec la journalisation avancée Entra ID peuvent capturer ces événements, mais requièrent une configuration explicite absente par défaut dans la majorité des déploiements.

Pourquoi l'OAuth client ID spoofing redéfinit les menaces sur les identités cloud

La technique documentée par Proofpoint représente un tournant dans les campagnes d'attaque ciblant les identités cloud. Jusqu'à présent, les credential stuffing attacks — qui consistent à tester des listes de credentials volés contre des services en ligne — généraient des événements de connexion échouées facilement détectables. Les SIEM pouvaient alerter sur des volumes anormaux de tentatives depuis des IPs étrangères, et Microsoft implémentait des protections côté serveur comme le rate limiting ou les smart lockout policies. L'OAuth client ID spoofing contourne ces défenses en opérant en dessous du seuil de détection des journaux de connexion standards.

La montée en puissance des marchés de credentials compromis sur le dark web rend cette technique particulièrement menaçante. Des centaines de millions de couples email/mot de passe circulent sur ces marchés, issus de fuites de données antérieures comme les breach compilations COMB ou les dumps de stealer logs. Jusqu'ici, la principale défense contre la réutilisation de ces credentials était la MFA, qui bloque l'accès même avec un mot de passe valide. La technique d'OAuth spoofing permet désormais aux attaquants de savoir précisément quels comptes n'ont pas de MFA, sans jamais tenter de connexion complète, ce qui en fait un outil de reconnaissance extrêmement efficace avant de lancer des attaques ciblées à fort impact.

L'abus du flux ROPC soulève également des questions sur la pertinence de maintenir ce protocole dans des environnements d'entreprise modernes. ROPC a été conçu pour des scénarios d'authentification legacy où des applications ne peuvent pas implémenter les flux OAuth interactifs. Dans un environnement Microsoft 365 moderne, très peu d'applications légitimes ont réellement besoin de ROPC. Proofpoint recommande explicitement aux administrateurs Entra ID de désactiver ROPC via une politique d'accès conditionnel ciblant tous les clients d'authentification legacy, ce qui élimine le vecteur d'attaque à la source tout en n'affectant que marginalement les applications modernes correctement configurées.

Plus largement, cet incident illustre un problème structurel dans la gestion des identités cloud : les équipes de sécurité font souvent confiance aux journaux de connexion Entra ID comme source unique de vérité pour détecter les activités suspectes, sans surveiller les interactions au niveau des endpoints OAuth sous-jacents. Cet angle mort est d'autant plus préoccupant que les attaquants sophistiqués en sont parfaitement conscients et l'exploitent activement depuis au moins décembre 2025. Les organisations doivent revoir leurs modèles de détection et étendre leur surface de collecte de logs pour couvrir les interactions avec l'endpoint token Microsoft, au-delà des seuls événements de connexion réussie ou échouée présents dans les journaux Entra ID classiques.

Ce qu'il faut retenir

• Désactiver le flux ROPC (Resource Owner Password Credentials) dans les politiques d'accès conditionnel Entra ID pour éliminer le vecteur d'attaque principal documenté par Proofpoint.
• Étendre la surveillance SIEM aux codes d'erreur AADSTS retournés par l'endpoint OAuth token, pas uniquement aux journaux de connexion standard, pour détecter les campagnes de validation silencieuse de credentials.
• Auditer les comptes sans MFA dans l'annuaire Entra ID et les prioriser pour une migration vers des méthodes d'authentification phishing-resistant : passkeys, FIDO2 ou Windows Hello for Business.