OAuth client ID spoofing lets attackers validate stolen Entra credentials
Proofpoint found two campaigns submitting forged OAuth client IDs to Entra's token endpoint. Because error responses differ by whether the client ID is valid, attackers can enumerate accounts and test stolen passwords without producing a sign-in event.
Proofpoint researchers, including analyst Rachel Rabin, identified two large independent campaigns adopting a technique they call OAuth client ID spoofing, beginning in late December 2025.
The mechanics are simple. An OAuth client ID is a GUID identifying an application requesting access. Attackers POST forged client IDs to Microsoft's OAuth 2.0 token endpoint, and Entra ID returns different errors depending on whether the client ID is valid. That difference is an oracle: it reveals whether an account exists and whether a password is correct, all without a successful sign-in.
The telemetry consequence is the point. Because no successful sign-in occurs, the activity sidesteps detections built on sign-in events. Worse, when a spoofed client ID is used, Entra sign-in logs record an application ID with the application name field left blank, so any rule keyed on application name simply does not fire.
Why it matters
This is a validation technique, not an access technique, and that is precisely why it deserves attention: it is what an attacker does with a dump before they use it. A campaign can confirm which of a million stolen passwords still work, quietly, then spend only verified credentials on the noisy part.
Two practical consequences. If your password spraying detections depend on failed or successful sign-in volume, test whether they see this at all. And check your Conditional Access scoping, because the researchers note that policies scoped to specific applications will not trigger on a spoofed client ID. A blank application name in Entra sign-in logs is worth alerting on by itself.
Source: The Hacker News