Press play to start listening
Attackers are using spoofed OAuth client IDs to identify valid Microsoft Entra ID accounts and test credentials while avoiding many application-based signals commonly used to detect malicious authentication activity.
New research from Proofpoint documents multiple campaigns using the technique against millions of accounts in thousands of Microsoft Entra tenants. The campaigns used different infrastructure, tools and request patterns, indicating that multiple threat actors have independently adopted OAuth client ID spoofing.
Unlike an OAuth application compromise, the activity does not require attackers to register an application or exploit a vulnerability. Attackers only need to submit authentication requests with spoofed client IDs and examine the error responses returned by Microsoft Entra ID.
Those responses can reveal whether a username exists, whether a password is incorrect and, in some cases, whether a valid username and password combination has been supplied. Attackers can obtain this information without completing a successful sign-in.
Proofpoint’s report shared with Hackread.com stated that researchers found a valid username paired with an incorrect password returns the AADSTS50126 error code. An invalid username produces AADSTS50034, although attempts involving nonexistent accounts do not appear in Entra sign-in logs. When valid credentials are submitted with an unregistered client ID, Entra can return AADSTS700016, indicating that the application identifier is not recognised.
This behaviour allows attackers to identify working credentials even when authentication fails because the supplied application does not exist. Organisations may interpret the event as an application error and miss evidence that a username and password have already been validated.
How OAuth Client ID Spoofing Avoids Common Entra Detections
The problem becomes harder to spot once the request reaches Entra’s sign-in logs. A spoofed client ID can still appear in the application ID field, but the application name may be left blank. If the identifier is malformed, both fields can be empty.
That gap can weaken rules built to group suspicious activity by application name or flag sudden request spikes against a known app. When attackers rotate through different client IDs, related login attempts can look disconnected even when they are part of the same campaign.
Proofpoint Links the Technique to Million-Account Campaigns
Proofpoint saw that pattern in a campaign it tracks as UNK_pyreq2323, which began in January 2026. The operation tested more than one million accounts in nearly 4,000 Microsoft Entra tenants and used more than 700,000 spoofed client IDs.
The requests came from Amazon Web Services infrastructure and carried the python-requests/2.32.3 user agent. The volume of failed authentication attempts was high enough to lock about 28% of the targeted accounts.
To keep the activity spread out, the operators altered the final six digits of a known Exchange Online application ID. Each spoofed identifier was used against only a small number of accounts, making it harder for application-based rules to connect the requests.
Two Campaigns Show Separate Adoption of the Same Technique
A separate campaign, tracked as UNK_OutFlareAZ, used the same technique with a different operating pattern. Beginning in December 2025, the activity targeted more than two million users and generated about 3.7 million spoofed application IDs, primarily through Cloudflare infrastructure.
Each authentication request in that campaign used a newly generated UUIDv4 client ID. The one-client-ID-per-request approach made application-level correlation more difficult and represented a more developed implementation than the modified Exchange Online identifiers used by UNK_pyreq2323.
Differences also appeared in the campaigns’ user agents and account-testing patterns. UNK_OutFlareAZ used an Outlook-style user agent and processed usernames alphabetically, while UNK_pyreq2323 used Python tooling and followed a non-alphabetical sequence.
Although the operators appeared unrelated, both campaigns distributed authentication attempts among spoofed application identities. Their different methods indicate that OAuth client ID spoofing is becoming established as a cloud account enumeration technique.
Proofpoint recommends monitoring Microsoft Entra sign-in records for missing application names, unexpected application IDs, and absent application information. These events should be reviewed alongside authentication error codes, request volumes, source infrastructure and repeated activity involving the same users.
