Des cybercriminels détournent l'identifiant OAuth des applications Microsoft pour tester des mots de passe sur Entra ID sans laisser de trace. Proofpoint a documenté deux campagnes d'ampleur ayant visé plus de 3 millions de comptes.
L'OAuth Client ID Spoofing s'impose malheureusement comme une technique d'usurpation en plein essor, comme nous l'apprend Proofpoint ce lundi 13 juillet. La méthode consiste à falsifier l'identifiant technique d'une application pour interroger Microsoft Entra ID en toute discrétion, sans jamais déclencher la moindre alerte de sécurité. De quoi permettre à des pirates de tester des milliers de mots de passe sur les comptes d'une entreprise, invisibles aux yeux des équipes chargées de les protéger.
Comment les pirates trompent Microsoft Entra ID avec un faux identifiant
Chaque application connectée à Microsoft Entra ID, l'ancien Azure Active Directory, se voit attribuer un numéro d'identification unique, le client ID. Un peu comme un badge d'accès qui permet au système de reconnaître qui frappe à la porte. Sauf que des attaquants ont découvert qu'il suffisait de présenter n'importe quel badge, même faux ou périmé, pour être laissé entrer dans le hall d'accueil sans jamais avoir à s'enregistrer officiellement, une logique de contournement qui rappelle les fausses applications Microsoft OAuth déjà repérées par Proofpoint, où de faux programmes imitant Adobe ou DocuSign servaient à piéger les utilisateurs.
Pour en avoir le cœur net, les chercheurs de Proofpoint ont reproduit eux-mêmes la manœuvre, en envoyant des requêtes directement vers le point de terminaison d'authentification de Microsoft avec un identifiant et un mot de passe, via une méthode technique appelée ROPC. Ils sont même allés jusqu'à développer leur propre outil de test pour observer, cas par cas, comment le système réagissait face à un identifiant valide, inventé, ou totalement malformé.
Ce qui rend l'astuce redoutable, c'est justement la subtilité de ces réactions. Selon que l'identifiant est reconnu ou non, les messages d'erreur renvoyés changent, et c'est là que tout se joue, car en les décryptant, un attaquant devine si un compte existe, si le mot de passe est correct, ou si une protection comme la double authentification est activée, sans jamais réussir à se connecter pour de bon. Un code d'erreur trahit qu'un nom d'utilisateur n'existe pas, un autre qu'il est valide mais que le mot de passe ne correspond pas, et un troisième, le plus parlant, confirme que les identifiants sont bel et bien exacts tout en bloquant la connexion faute d'application reconnue. C'est ce dernier cas qui inquiète le plus les experts. Il permet de valider un couple identifiant-mot de passe sans jamais générer la moindre connexion réussie dans les journaux.
La conséquence, c'est que dans les registres de connexion, l'attaque s'évapore. Quand l'identifiant est valide mais non enregistré, seul le numéro s'affiche, sans nom d'application associé, une case vide que les outils de sécurité ne savent pas interpréter. Les systèmes configurés pour repérer des pics d'activité sur une application précise passent alors complètement à côté du phénomène. Autre avantage pour les attaquants : les politiques d'accès conditionnel, souvent réglées pour restreindre les connexions à des applications précises, ne se déclenchent tout simplement pas face à un badge fictif, ce qui prive les équipes de sécurité d'un rempart pourtant jugé fiable jusqu'ici.
Deux campagnes distinctes pour une même technique d'usurpation
Proofpoint ne parle pas d'une hypothèse d'école. Ses chercheurs ont bien mis au jour plusieurs campagnes bien réelles qui exploitent cette faiblesse à grande échelle, dans la lignée de techniques d'évasion déjà repérées par le passé, comme la rotation d'adresses IP et de faux navigateurs utilisée par le groupe UNK_CustomCloak. La première, baptisée UNK_pyreq2323, a fait son apparition le 14 janvier 2026. Ses auteurs, qui opèrent depuis une infrastructure hébergée sur Amazon Web Services et se faisant passer pour un simple script Python, ont eu recours à plus de 700 000 identifiants falsifiés, obtenus en modifiant légèrement les derniers chiffres du numéro d'une application Microsoft bien connue, Exchange Online.
L'opération a visé plus d'un million de comptes utilisateurs répartis dans près de 4 000 organisations, avec une intensité maximale détectée fin janvier et début février, avant un déclin observé début mars. Un tel déluge de tentatives a eu des répercussions bien concrètes, puisque environ 28 % des comptes ciblés se sont retrouvés verrouillés par mesure de précaution automatique, un dégât collatéral qui a pu, de façon assez ironique, mettre la puce à l'oreille de certaines équipes informatiques sans qu'elles en cernent la véritable origine.
Une seconde vague, baptisée UNK_OutFlareAZ, s'est révélée plus ambitieuse encore. Lancée dès décembre 2025 depuis une infrastructure Cloudflare, en imitant cette fois le comportement d'un client Outlook parfaitement légitime, elle s'est déroulée en deux temps forts. Il y a d'abord eu une première poussée fin décembre avec environ 242 000 comptes visés, avant qu'une seconde vague, amorcée en février, n'explose à 720 000 comptes ciblés à la mi-mars. Au total, la campagne a ratissé plus de deux millions d'utilisateurs à l'aide de 3,7 millions d'identifiants falsifiés, cette fois générés de façon totalement aléatoire pour brouiller encore davantage les pistes.
Ces noms d'utilisateurs génériques que les pirates ciblent en priorité
Les deux campagnes affichent des profils franchement différents, ce qui montre que la technique séduit indépendamment plusieurs groupes d'attaquants, sans concertation apparente. La première recyclait ses faux identifiants sur plusieurs comptes à la fois, jusqu'à douze utilisateurs testés avec le même numéro. La seconde, plus soignée dans son exécution, générait un identifiant unique à chaque tentative et testait les noms d'utilisateur par ordre alphabétique, signe que ses auteurs s'appuyaient sur des listes de prénoms génériques préétablies plutôt que sur une prospection au hasard.
Un détail interpelle tout de même les experts. Des noms d'utilisateurs comme jsmith, ssmith ou msmith revenaient dans des centaines d'organisations différentes, jusqu'à 174 entreprises distinctes pour le plus fréquent d'entre eux. On peut en conclure que ces attaques puisent dans des dictionnaires de patronymes courants, appliqués à des milliers d'entreprises sans distinction, dans l'espoir de tomber sur la bonne combinaison, plutôt que de viser une cible précise.
Proofpoint appelle les équipes de sécurité à revoir leur copie. Les experts recommandent de surveiller de près les journaux de connexion où le nom d'application reste vide, un indice qui devrait mettre la puce à l'oreille, et d'arrêter de considérer certains codes d'erreur comme de simples échecs de connexion sans conséquence : ils peuvent au contraire trahir des identifiants d'ores et déjà compromis, même en l'absence de toute connexion réussie officiellement enregistrée.
