By ByteBot
Two active threat groups have been silently validating stolen Microsoft Entra ID credentials for months using a technique your sign-in logs almost certainly missed. The method, detailed by Proofpoint on July 13, 2026, exploits a gap between how Microsoft’s OAuth token endpoint behaves and how most enterprise security teams have configured their detection stack. Attackers can confirm a username-and-password pair is valid without ever generating a successful sign-in event.
How the Attack Works
Microsoft’s OAuth 2.0 token endpoint supports the Resource Owner Password Credentials (ROPC) grant — a legacy flow that accepts a raw username and password and returns an access token. Microsoft’s own documentation tells you not to use it. It stays live for backward compatibility.
The spoofing twist: ROPC requires a client_id in the request. Attackers supply a syntactically valid GUID that belongs to no real registered application. The endpoint still processes the credentials and returns an error code. Those error codes are the payload:
AADSTS50034— username does not exist in the tenantAADSTS50126— username is valid, password is wrongAADSTS700016— application not recognized, but credentials are correct
AADSTS700016 is confirmation. The attacker has a working credential pair. The token was never issued — but the damage is done.
Why Your Logs Do Not Show It
When a spoofed client ID is used, Entra ID records no application name in the sign-in log. The “App” field is blank. Every detection built on “alert when app X shows suspicious activity” misses this entirely. The event appears as a failed authentication — not a successful sign-in — so SOC rules requiring a completed sign-in before alerting never fire.
Conditional Access policies scoped to specific applications do not help either. A spoofed client ID matches no registered app, so the policy conditions never trigger. Organizations that blocked ROPC for Exchange Online and called it done are still exposed if they used per-app scoping rather than the “Block authentication flows” CA condition type.
The Campaigns Already Running
Proofpoint tracked two active groups using this technique independently:
UNK_pyreq2323 ran from January to March 2026 using AWS infrastructure and over 700,000 spoofed client IDs built by randomizing the last six digits of the Exchange Online app prefix. It targeted more than one million accounts across roughly 4,000 tenants. Approximately 28% of targeted users were locked out from password attempt volume — entirely invisible to credential-validation detections.
UNK_OutFlareAZ started in December 2025 and remains active. It runs on Cloudflare infrastructure with fully randomized UUIDs and has probed over two million Entra ID users with 3.7 million spoofed application IDs.
Both campaigns used common username patterns — dsmith, msmith, jbrown — sprayed across multiple tenants simultaneously. If your organization appeared in any credential leak over the past two years, assume these campaigns have already checked your exposed accounts.
What to Do Now
The fix is available; it requires the right CA policy configuration. Create a Conditional Access policy using the “Authentication flows” condition to block the Resource Owner Password Credentials flow explicitly — not scoped to any specific application. Microsoft’s documentation for blocking authentication flows covers this precisely.
For detection: build a Microsoft Sentinel query that filters SignInLogs where AppDisplayName is empty and ResultType is 700016, 50034, or 50126. A burst of these events from the same IP range in a short window is active enumeration in progress.
One more point: if you already have logs showing AADSTS700016 events with blank application names — even historically — treat those entries as confirmed valid credential pairs, not benign failed logins. The framing matters for how urgently you respond.
The Bigger Problem
Microsoft has spent 2026 systematically deprecating ROPC — pulling it from Exchange Online PowerShell, deprecating it in MSAL, steering developers to modern auth flows. That work is correct. But the /common/oauth2/token endpoint itself remains accessible because removing it would break too many legacy integrations.
As Shane Barney of Keeper Security noted: attackers found a way to confirm valid credentials without leaving a trace in the logs defenders rely on. This is not unique to Microsoft — it is the recurring cost of backward compatibility in identity infrastructure. The ROPC flow was never safe; the documentation said so from day one. It has now become a credential oracle for active threat actors. Block it yourself. Do not wait for Microsoft to remove it for you.
