OAuth Client ID Spoofing Enables Stealthy Account Enumeration Without a Single Login

Attackers are spoofing OAuth client IDs against Microsoft Entra ID to enumerate valid usernames and confirm working passwords without ever triggering a successful sign-in event, according to Proofpoint's threat research team, defeating the exact telemetry most security operations centres rely on to catch credential based attacks in the first place.

Why Entra sign-in logs stop working as intended

Entra sign-in logs are the primary source security teams use to spot malicious authentication activity, including user enumeration, password spraying, and early stage intrusion attempts. Normally, that visibility depends on requests being tied to a registered application, which is what lets defenders correlate suspicious volume against a specific client and investigate accordingly. Proofpoint found that when an attacker issues an OAuth token request using a spoofed, unregistered client ID rather than a real one, Entra's logs simply do not record an application name at all. Microsoft's own error responses still leak the information an attacker actually wants, whether a submitted username corresponds to a real account, and whether a submitted password is correct, without ever completing a genuine login. That combination means an attacker can quietly map out which accounts exist and which stolen or guessed credentials work, while leaving behind a log entry with no application tied to it, which is precisely the kind of gap defenders are not trained to notice.

Built specifically to stay under detection thresholds

Proofpoint's researchers simulated the technique directly against Entra ID using a custom PowerShell module, issuing requests through the Resource Owner Password Credentials flow, which allows direct submission of a username and password to Microsoft's OAuth token endpoint. The resulting AADSTS error codes reveal not just whether credentials are valid, but whether protections such as multi factor authentication or conditional access policies are enforced on that specific account, information that materially shapes how an attacker plans a follow-on attack. To avoid the volume-based alerts that a surge of requests against a single application would normally trigger, attackers fragment their authentication attempts across many fictional, non-existent applications instead. That fragmentation is deliberate: security teams are generally tuned to flag concentrated spikes against one app, not a low, distributed trickle spread across dozens of client IDs that were never registered in the first place. Proofpoint says it observed multiple distinct campaigns at scale, each using its own tooling, infrastructure, and execution pattern, indicating the technique has been adopted independently by more than one threat actor rather than spreading from a single source.

A gap that traditional enumeration defences do not cover

Older enumeration techniques typically target built-in first-party applications, most commonly command line tools such as Azure AD PowerShell, which exist by default in every tenant and have historically been a known blind spot for multi factor authentication enforcement. Client ID spoofing sidesteps that entire category of defence, since it does not rely on any pre-existing application at all, registered or otherwise. Even where security teams have specifically hardened their environment against enumeration via known first-party tools, this technique opens a separate path that most existing detection logic simply was not built to catch.

Why this feeds directly into the region's dominant attack pattern

The UAE Cyber Security Council reports that more than 75% of cyberattacks in the country begin with phishing or fraudulent messages, making stolen or guessed credentials the single most common way attackers gain initial access across the region. A technique that lets an attacker quietly confirm which stolen credentials from a phishing campaign are actually valid, before ever attempting to use them, feeds directly into that same entry point rather than representing a separate threat category. For GCC enterprises already contending with high phishing volumes, this closes a gap between the initial credential theft and the moment an attacker commits to using stolen credentials, a stage that has historically offered defenders very little visibility.

What security teams should actually watch for

Proofpoint's core detection recommendation is specific and actionable: monitor sign-in logs directly for authentication events where no application name is populated, since that absence is itself the signature of a spoofed client ID rather than a logging gap to dismiss. Security teams should also treat any pattern of failed or partial authentication attempts spread across an unusually large number of distinct, unfamiliar application identifiers as suspicious in its own right, even where no single application shows the kind of volume that would normally trigger an alert. Given how directly this technique feeds into credential based intrusion, the same broad attack category responsible for the majority of breaches across the UAE specifically, organisations should treat closing this detection gap as a near-term priority rather than a lower-severity item to address once existing enumeration defences are fully mature.