Security researchers at Proofpoint have documented a technique that lets attackers verify usernames and passwords in Microsoft Entra ID without ever generating a logged sign-in event — a blind spot now exploited in campaigns spanning millions of accounts.
What if an attacker could check thousands of usernames and passwords against your organization’s cloud identity system without ever triggering a single logged sign-in event? According to new research from security vendor Proofpoint, that scenario is no longer theoretical. Researchers have documented a technique called OAuth client ID spoofing that lets attackers query Microsoft Entra ID for account and password validity while leaving almost no trace in standard sign-in logs.
How the technique works
Microsoft Entra ID, Microsoft’s cloud-based identity and access management service, returns different responses depending on whether a submitted OAuth client ID is valid and whether it belongs to a registered application. Proofpoint’s researchers found that this behavior can be turned against the platform itself. By submitting a client ID that is syntactically valid but not actually registered, attackers can determine whether a given user account exists and whether a password is correct, all without generating a successful sign-in event.
Crucially, when a spoofed client ID is used, no application name is recorded in the sign-in log, only a raw application ID. That single missing field is enough to blind detection rules that look for suspicious activity tied to a specific, named application. Spoofed IDs also sidestep Conditional Access policies that are scoped to particular applications, and by spreading requests across thousands of fictitious application identifiers, attackers can dodge per-application rate limiting and correlation. Proofpoint singles out one error code, AADSTS700016, as particularly dangerous from a defender’s perspective: it appears when a username and password are correct but the client ID is unregistered, and can easily be dismissed as a routine failed login rather than what it actually signals — valid, working credentials in an attacker’s hands.
Proofpoint says it verified the mechanics itself by simulating the technique in a lab environment, sending requests to Microsoft’s OAuth 2.0 token endpoint using the Resource Owner Password Credentials flow, which allows direct submission of a username and password. Testing four scenarios — valid registered client IDs, valid but unregistered ones, random UUIDs, and malformed identifiers — the researchers confirmed that only genuinely registered applications produce a fully logged event with both an application ID and an application name. Every other case leaves the application name field empty, regardless of whether the credentials supplied were correct.
UNK_PyReq2323: brute-force scale from AWS infrastructure
In the first campaign Proofpoint tracked, an actor designated UNK_PyReq2323 used more than 700,000 distinct spoofed client IDs, operating from AWS infrastructure with the user agent python-requests/2.32.3. The campaign tested more than one million user accounts across nearly 4,000 tenants. The sheer volume of failed attempts triggered account lockouts for roughly 28 percent of targeted users.
The spoofing method itself was crude: attackers took the known prefix of Microsoft’s “Exchange Online” application and randomized only the final six digits. Because that variation space is limited, the same fabricated ID was inevitably reused, in some cases against as many as twelve different accounts, though never twice against the same one.
UNK_OutFlareAZ: broader reach, more sophisticated tradecraft
A second, larger campaign, tracked as UNK_OutFlareAZ, operated primarily through Cloudflare infrastructure and targeted more than two million users with 3.7 million spoofed application IDs. It used the user agent string for Microsoft Office/Outlook, one Proofpoint says it has observed across numerous campaigns over several years, suggesting the use of widely circulated attack tooling.
Unlike UNK_PyReq2323, this group generated a completely random UUIDv4 for every single authentication attempt, making correlation far harder for defenders. Proofpoint also noted that many targeted usernames followed generic naming patterns, such as dsmith, msmith, or jbrown, and recurred across multiple tenants, pointing to the use of a shared, prebuilt wordlist.
Two actors, one technique
Despite relying on the same underlying weakness, the two campaigns differed markedly in user agent, infrastructure, ID-generation method, and enumeration pattern. Proofpoint interprets this as evidence that separate threat actors adopted the same core technique independently, rather than a single group running both operations — a sign that OAuth client ID spoofing is spreading as a recognized tradecraft rather than a one-off trick.
What defenders should do
Proofpoint recommends that security teams specifically monitor sign-in logs for entries with a missing application name, since that gap can indicate the use of a spoofed client ID. The AADSTS700016 error, in particular, should not be waved away as an ordinary failed login; it can be a strong signal of compromised credentials. Organizations should also review whether their existing Conditional Access policies remain effective against unregistered application IDs, since policies scoped narrowly to named applications will not catch this activity.
Traditional enumeration tooling tends to target a handful of hardcoded, first-party applications that exist by default in every tenant. Spreading requests across thousands of fabricated application identifiers instead makes the traffic far harder to tie together. Proofpoint’s findings suggest that attackers are increasingly turning to gaps in what gets logged, rather than gaps in authentication itself, to stay under the radar.
Dr. Jakob Jung is Editor-in-Chief of Security Storage and Channel Germany. He has been working in IT journalism for more than 20 years. His career includes Computer Reseller News, Heise Resale, Informationweek, Techtarget (storage and data center) and ChannelBiz. He also freelances for numerous IT publications, including Computerwoche, Channelpartner, IT-Business, Storage-Insider and ZDnet. His main topics are channel, storage, security, data center, ERP and CRM.
Contact via Mail: jakob.jung@security-storage-und-channel-germany.de