Notifications
Clear all
Topic starter
14/07/2026 5:23 pm
TL;DR: Multiple cloud campaigns abused OAuth client ID spoofing to enumerate accounts and infer password validity in Microsoft Entra ID without generating a successful sign-in event; one campaign targeted more than one million accounts across nearly 4,000 tenants and another exceeded 2 million users, according to Proofpoint. The finding shows that application-name based detection is no longer enough when identity telemetry can be deliberately shaped.
NHIMG editorial — based on content published by Proofpoint: OAuth client ID spoofing exposes a cloud identity blind spot
By the numbers:
- The campaign tracked as UNK_pyreq2323 targeted over one million unique user accounts across nearly 4,000 tenants.
- The observed high volume of failed attempts triggered account lockouts for approximately 28% of targeted users.
Questions worth separating out
Q: How should security teams detect OAuth client ID spoofing in cloud identity logs?
A: Focus on response patterns, not just successful sign-ins.
Q: Why does OAuth client ID spoofing undermine application-scoped IAM controls?
A: Because the attacker can invent or randomise the application context while still triggering meaningful identity responses.
Q: What breaks when sign-in telemetry treats application name as a trust signal?
A: Correlation breaks first.
Practitioner guidance
- Detect blank application-name events Flag sign-in records where the application name is missing but the client_id or error behaviour suggests active authentication probing, and route those events into threat hunting and account risk workflows.
- Correlate AADSTS error patterns Track repeated AADSTS50034, AADSTS50126, and AADSTS700016 responses together so analysts can distinguish invalid users, valid users with bad passwords, and spoofed client ID behaviour.
- Shift Conditional Access review beyond app-scoping Review whether any Conditional Access policy only applies to a small set of named applications, then test whether spoofed client IDs can bypass those scopes during enumeration.
What's in the full analysis
Proofpoint's full analysis covers the operational detail this post intentionally leaves for the source:
- The exact AADSTS response behaviours observed across valid, invalid, registered, and spoofed client IDs.
- The campaign timelines, user-agent patterns, and infrastructure fingerprints behind UNK_pyreq2323 and UNK_OutFlareAZ.
- The custom enumeration method used to test how Entra logs spoofed application IDs and account validity.
- The detection recommendations for sign-in logs that show blank application names or suspicious error-code combinations.
👉 Read Proofpoint's analysis of OAuth client ID spoofing in Entra ID →
OAuth client ID spoofing in Entra ID: what should teams watch?
Explore further
14/07/2026 5:26 pm
Blank application-name telemetry is now a governance weakness, not a logging quirk. Proofpoint’s findings show that attackers can turn Entra ID response behaviour into an enumeration channel while leaving the application name empty in sign-in logs. That means the control assumption that a named app will always anchor correlation no longer holds. Teams should stop treating application-name presence as a reliable signal of legitimacy.
A few things that frame the scale:
- Organisations that describe themselves as confident in their AI deployment actually experience a 72% security incident rate, compared to 33% for those who remain cautious, according to The 2026 Infrastructure Identity Survey.
- Systems with least-privileged AI access had a 17% incident rate versus 76% for over-privileged systems, according to The 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: Who is accountable when spoofed client IDs expose valid accounts without a successful sign-in?
A: Identity engineering, SOC monitoring, and Conditional Access owners all share responsibility because the failure spans logging, policy scope, and account protection. The accountability test should ask whether the programme can prove which telemetry fields it trusts, and whether those fields can be manipulated by an unauthenticated requester.
👉 Read our full editorial: OAuth client ID spoofing exposes a cloud identity blind spot
