OAuth client ID spoofing sneaks past Entra sign-in logs

Here’s what changed. Two threat crews — Proofpoint tracks them as UNK_pyreq2323 and UNK_OutFlareAZ — are validating stolen Microsoft Entra ID credentials by submitting made-up OAuth client IDs to the token endpoint. The trick reads the AADSTS error codes Entra returns to figure out whether an account exists and whether the password is right. It never produces a successful sign-in event, and it doesn’t put an application name in the sign-in log the way a real OAuth app would. If your detection watches for a surge of failures against a specific application, this activity walks past it, because the application-name field is blank.

The two campaigns, per Proofpoint’s writeup relayed by The Hacker News on July 14:

• UNK_pyreq2323 ran January through March 2026 out of AWS infrastructure. Proofpoint counted 700,000+ spoofed client IDs targeting more than a million accounts across roughly 4,000 tenants. About 28% of the targeted accounts ended up locked out — which is how a lot of victim orgs found out at all.
• UNK_OutFlareAZ has been running since December 2025 out of Cloudflare, targeting more than 2 million users with 3.7 million randomized fake application IDs.

The mechanic itself is the Resource Owner Password Credentials (ROPC) flow — a legacy OAuth grant where the client sends the username and password straight to the token endpoint. Microsoft has been telling tenants to disable ROPC for years. Most enterprises haven’t.

What this actually gets attackers

Two things worth separating. First, account enumeration: a spoofed client ID with a real username still tells the attacker whether the account exists in the tenant. Second, credential validation: if the attacker also has a candidate password (from a breach dump, a phishing catch, an infostealer log), the response distinguishes “bad password” from “good password, MFA required” from “good password, no MFA.” That last one is the payload. It tells them which stolen credentials are worth pushing to a real login later.

None of this generates the successful sign-in event most defenders key on. That’s the whole point.

Honest timeline for defense

Patch this first: disable ROPC at the tenant level if you haven’t already. In Entra, this is a Conditional Access policy blocking the urn:ietf:params:oauth:grant-type:password grant type, or the equivalent authentication method policy setting. There is essentially no modern app that needs ROPC. If a vendor asks for it, that’s a finding, not a requirement.

Second: stop scoping detections to specific application names or IDs. That’s the exact assumption Proofpoint’s tracked crews are exploiting. A blank application name on a failed sign-in is itself the signal — filter for it, alert on volume against a single tenant, alert on volume against a single account. Sign-in logs still capture the source IP and the user principal name; hunt on those.

Third: treat lockouts as a detection, not just a helpdesk ticket. The 28% lockout rate in the UNK_pyreq2323 campaign is a bright red line — an org would notice hundreds of simultaneous lockouts. If your current lockout thresholds are too permissive to spot 4,000-tenant campaigns, they’re too permissive.

Fourth, longer term: push the identity plane off passwords. Passkeys, FIDO2, certificate-based auth — anything where a stolen password from a breach dump isn’t a valid credential to test against in the first place. Microsoft is making passkeys the default Entra authentication method starting September 2026 — that helps new tenants, not the existing ones with millions of password-authenticated identities already in the wild.

Nothing here needs a CVE, because there’s no vulnerability being exploited in the classic sense. Entra is behaving as designed: it returns informative error codes, it accepts syntactically valid client IDs, it supports a legacy grant that’s been deprecated in practice but not switched off by default. The attack is defenders’ blind spots and a legacy flow that never should have survived this long. Fix both.