Deviner des mots de passe sans jamais déclencher la moindre connexion réussie : c’est le tour de passe-passe que décrivent les chercheurs de Proofpoint. Leur technique d’abus de l’OAuth Client ID permet de tester des comptes Microsoft Entra et des identifiants dérobés en restant sous les radars. Dans les journaux de connexion, le nom de l’application peut rester vide. Autant dire une aubaine pour l’attaquant et un casse-tête pour les équipes de sécurité.
L’attaque envoie au point de terminaison OAuth de Microsoft des requêtes avec des valeurs de client_id falsifiées ou arbitraires. D’après les travaux de Proofpoint, la méthode a été observée à grande échelle contre des tenants Microsoft Entra, via des campagnes distinctes, des outils différents et des schémas d’exécution indépendants.
Points clés
- La technique abuse du client_id OAuth d’Entra pour tester des comptes sans générer de connexion réussie dans les logs
- Le code d’erreur AADSTS700016 permet de distinguer un identifiant valide d’un mauvais compte
- La campagne UNK_pyreq2323 a testé plus de 700 000 identifiants client falsifiés depuis des infrastructures AWS
- Les défenseurs doivent surveiller les logs avec application ID vide et les erreurs AADSTS700016 répétées
Quand la réponse d’erreur devient un mouchard
Dans Entra, l’identifiant client OAuth sert à déclarer quelle application initie la requête. Les chercheurs ont reproduit l’approche avec le flux Resource Owner Password Credentials (ROPC), qui transmet directement nom d’utilisateur et mot de passe au point de terminaison de jeton. Quand l’application enregistrée n’existe pas, ou quand l’identifiant est syntaxiquement valide mais ne correspond à rien, le journal peut afficher un identifiant d’application vide ou aucun nom.
À partir de là, les codes d’erreur trahissent tout. Un identifiant utilisateur inexistant ne se comporte pas comme un compte valide. Un mot de passe incorrect renvoie un autre code. Et le code AADSTS700016 apparaît lorsque le couple identifiant-mot de passe est correct mais que l’application n’est pas reconnue. De quoi distinguer un mauvais compte d’un identifiant valide, sans qu’aucune connexion réussie ne s’affiche dans les logs.
Selon Proofpoint, des identifiants client falsifiés « permettent l’énumération de comptes sans application OAuth enregistrée et autorisent les attaquants à inférer la validité du mot de passe et du compte sans générer d’événement de connexion réussi ».
700 000 identifiants falsifiés et des millions de comptes visés
Les analyses publiées le 13 juillet 2026 évoquent plusieurs campagnes massives. L’une, suivie sous le nom UNK_pyreq2323, sévit depuis le 14 janvier 2026 depuis des infrastructures AWS avec l’agent utilisateur python-requests/2.32.3. L’opérateur aurait testé plus de 700 000 identifiants client falsifiés, bricolés à partir du préfixe de l’application Exchange Online complété par une chaîne aléatoire.
Une autre campagne s’appuie sur des patterns différents, signe que plusieurs acteurs se sont emparés de la même recette. Au total, les chercheurs disent avoir vu des tentatives contre des millions de comptes dans des milliers de tenants Microsoft Entra.
Ce que les équipes sécurité doivent vérifier maintenant
- les sign-in logs Entra avec un nom d’application absent ou un application ID vide ;
- les erreurs AADSTS700016 répétées sur des comptes ciblés ;
- les pics de requêtes ROPC ou de tentatives de validation de mots de passe ;
- les infrastructures associées à des user agents automatisés, typiquement des bibliothèques HTTP de scripts.
La technique ne réclame ni malware installé ni poste déjà compromis. Elle exploite la manière dont le service d’authentification répond aux requêtes et consigne ses métadonnées. Pour les environnements Entra, la parade impose de corréler les erreurs d’authentification avec les champs de journal d’application, au lieu de se contenter des connexions réussies ou des échecs classiques. Le classique n’est plus suffisant quand l’attaquant a appris à ne jamais réussir sa connexion.
