Key Takeaways
- Proofpoint has observed OAuth client ID spoofing emerging as a novel technique, increasingly leveraged in cloud campaigns.
- Microsoft Entra ID returns different responses depending on whether a supplied OAuth client ID is valid and whether it corresponds to a registered application.
- This behavior enables account enumeration without a registered OAuth application and allows attackers to infer password validity or account state without generating a successful sign‑in event.
- Researchers observed multiple campaigns at scale abusing spoofed OAuth application identifiers, with distinct tooling, infrastructure, and execution patterns indicating independent adoption by multiple threat actors.
- To detect similar activity, defenders should monitor sign-in logs for events without an application name, which may indicate spoofed client IDs.
Intro
What if attackers could enumerate your entire organization's accounts without generating a single successful sign-in event?
The Entra sign‑in logs are a primary telemetry source for identifying malicious authentication activity, including user enumeration, password spraying, and initial access attempts. To evade detection, attackers routinely distribute requests using rotating user agents (as seen in UNK_CustomCloak) and proxy services that cycle source IPs per request.
Proofpoint researchers have identified multiple campaigns where attackers extend this evasive tradecraft by spoofing the OAuth client ID (application ID), a globally unique identifier (GUID) assigned to applications. The identifier is passed as client_id in authentication requests and recorded as the application ID in Entra sign-in logs.
Spoofed client IDs enable account enumeration without a registered OAuth application and allow attackers to infer both password and account validity without generating a successful sign-in event.
Simulating client ID spoofing
To understand how client ID spoofing works in practice, we simulated the technique against Entra ID.
Client ID spoofing was performed by issuing POST requests to Microsoft's OAuth 2.0 token endpoint (/common/oauth2/token) using the Resource Owner Password Credentials (ROPC) flow, which allows direct submission of username and password credentials.
Figure 1: ROPC request with client ID parameter
The resulting AADSTS error codes allow unauthenticated requestors to infer the validity of usernames and passwords, as well as the enforcement of controls such as multi-factor authentication (MFA) or Conditional Access (CA).
A custom PowerShell module (Invoke-ClientIdSpoofEnum) was developed to observe how Entra ID responds and logs requests with client_id values across the following scenarios:
- Valid client ID associated with registered applications
- Valid client ID associated with unregistered applications
- Randomly generated UUIDs with a valid structure
- Invalid client ID
Valid client ID + registered application
When a valid client_id corresponds to a registered application, Entra processes the request as expected, with both the application ID and application name populated in the sign‑in logs.
Figure 2: Sign-in log entry for registered application ID
Valid client ID + unregistered application
When the supplied client_id is syntactically valid but does not correspond to a real application, only the application ID is recorded in the sign-in log, without a corresponding application name.
Figure 3: Application name not populated for spoofed Application ID
The response can be used to infer whether the account exists and whether the password is correct without a registered application.
AADSTS50034 is returned for an invalid username. This event will not be logged to the sign-in log as Entra ID only logs sign in attempts to valid usernames.
Figure 4: Custom Invoke-ClientIdSpoofEnum tool showing response when the user is invalid and the client ID is a randomly generated UUIDv4 string that does not correspond to a registered application.
AADSTS50126 is returned for a valid username with an invalid password.
Figure 5: Custom Invoke-ClientIdSpoofEnum tool showing response when the user is valid and the password is invalid
Notably, AADSTS700016 (application identifier not recognized) is returned for a valid username and password. The use of the spoofed app identifier therefore facilitates enumeration of valid username-password pairs without generating a successful sign-in record.
Figure 6: Invoke-ClientIdSpoofEnum for valid username and password
Invalid Client ID
If the spoofed client ID is not a proper UUIDv4, Entra does not reject the request outright. Instead, it still returns AADSTS errors without populating application ID or application name in the signin log.
Attackers can therefore analyze this error response to identify valid accounts and passwords, despite using malformed client IDs.
Figure 7: Application name and Application ID not populated for an invalid UUIDv4 client ID
Why do attackers spoof the client ID?
When a spoofed client ID is used, no corresponding application name is recorded in the sign-in log. This means that detections that look for surges against a specific application name may miss this activity entirely, as the field is blank.
The observed logging behavior allows unauthenticated attackers to enumerate users and infer password validity without generating a successful sign-in event. Even when enumeration is detected, defenders may not realize that valid credentials were identified and may overlook compromised credentials entirely.
Traditional enumeration tools target hardcoded first-party applications, commonly CLI tools like Azure AD PowerShell, that exist in all tenants and have historically been a gap for MFA enforcement. However, surges in authentication requests to a single application quickly raise alarms for SOC teams. By fragmenting authentication attempts across many fictional applications, activity becomes harder to correlate and may evade per-application detections and rate limiting.
Organizations may attempt to mitigate traditional enumeration attacks by applying Conditional Access policies scoped to applications commonly targeted for enumeration. Spoofed client IDs won’t trigger CA policies that are scoped to a specific application.
UNK_PyReq2323
The campaign tracked by Proofpoint as UNK_pyreq2323 first emerged on January 14, 2026. The attacker distributed enumeration attempts across more than 700,000 spoofed client IDs.
The observed authentication requests were from the user agent:
python-requests/2.32.3
Activity peaked in late January and early February before declining by early March. The campaign originated from AWS infrastructure and targeted over one million unique user accounts across nearly 4,000 tenants. This high volume of failed attempts triggered account lockouts for approximately 28% of targeted users.
Figure 8: Timeline of UNK_pyreq2323
Client ID Spoofing Details
The method for spoofing client IDs was unsophisticated, using the prefix for the application “Exchange Online”.
00000002-0000-0ff1-ce00-000000000000
Rather than enumerating IDs sequentially, the threat actor randomized the final six digits of the identifier. This resulted in spoofed IDs being used on up to 12 users and never retried for the same user.
The table below presents a selection of observed client IDs, including the three lowest and three highest values. Analysis of the timestamps associated with each client ID shows no ascending or descending pattern, confirming they were not generated sequentially but are random.
|
00000002-0000-0ff1-ce00-000000100001 |
|
00000002-0000-0ff1-ce00-000000100003 |
|
00000002-0000-0ff1-ce00-000000100005 |
|
00000002-0000-0ff1-ce00-000000425603 |
|
00000002-0000-0ff1-ce00-000000544540 |
|
00000002-0000-0ff1-ce00-000000645372 |
|
00000002-0000-0ff1-ce00-000000999997 |
|
00000002-0000-0ff1-ce00-000000999998 |
|
00000002-0000-0ff1-ce00-000000999999 |
Figure 9: Most spoofed app IDs were used for 1–3 users, for a maximum of 12
UNK_OutFlareAZ Dec 2025
Beginning in December 2025, Proofpoint researchers observed a large-scale enumeration campaign tracked as UNK_OutFlareAZ originating primarily from Cloudflare infrastructure. The activity used the same client ID spoofing technique, but operated at a greater scale, targeting more than 2 million users and 3.7 million spoofed application IDs.
The observed authentication requests were from the user agent:
Microsoft Office/16.0 (Windows NT 10.0; Microsoft Outlook 16.0.12026; Pro.
Proofpoint has consistently observed this user agent over several years across multiple enumeration campaigns, where it has been widely propagated through attacker tooling.
The campaign occurred in two distinct waves: the first ramped up from December 10 and peaked in late December (~242K users), while a second, larger wave began in early February, escalated through March, and peaked on March 15 (~720K users).
A notable portion of usernames appeared across multiple tenants, following generic naming conventions like dsmith, msmith, and jbrown. Because Entra ID only logs attempts against valid accounts, this pattern suggests attackers reused a common wordlist of generic usernames across many organizations.
Client ID Spoofing Details
The spoofing approach employed in UNK_OutFlareAZ was more mature when compared to the UNK_pyreq2323. Rather than randomizing the last digits within a known first party application identifier, the threat actor generated a fully randomized UUIDv4, using a unique client id for each authentication attempt.
Example of spoofed app ids:
|
f9bae775-ef31-44c0-ad33-f50f62b3aba8 |
|
89274bc8-5605-4639-b850-1d5fc2de4bad |
|
ad48e616-54a3-4c53-b7f7-605d493d54ba |
|
2e2fa57b-e41e-40e6-b2d6-5aa448cef563 |
|
574f120a-5094-4f2d-930a-9e926221f0f2 |
|
fff3c7ac-36d1-46b8-80a9-212095b76264 |
Campaigns Compared
While both campaigns leveraged OAuth client ID spoofing for user enumeration, differences in user agents, infrastructure, client ID generation, and enumeration patterns suggest they were conducted by distinct tools or operators.
Both campaigns used valid UUIDs rather than malformed identifiers and exhibited patterns consistent with precompiled username wordlists. However, UNK_OutFlareAZ enumerated users alphabetically while UNK_pyreq2323 did not.
The client ID spoofing methods also differed: UNK_pyreq2323 modified the trailing digits of a known application ID, reusing spoofed IDs across up to 12 users, while UNK_OutFlareAZ generated a unique client ID per request, a more sophisticated approach that limits correlation.
These variations point to independent adoption of the same underlying technique, reinforcing Proofpoint's assessment that OAuth client ID spoofing is becoming increasingly common tradecraft among threat actors.
Comparison of Campaigns
|
Tracked as |
UNK_pyreq2323 |
UNK_OutFlareAZ |
|
User Agent |
python-requests/2.32.3 |
Microsoft Office/16.0 (Windows NT 10.0; Microsoft Outlook 16.0.12026; Pro |
|
Infrastructure |
AWS |
Cloudflare + others |
|
App ID Method |
00000002-0000-0ff1-ce00-000000XXXXXX |
Fully random UUID v4 |
|
Reuse |
Max 12 users per ID |
Max 1 user per ID |
|
Enumeration Style |
Non-alphabetical |
Alphabetical |
|
Campaign Duration |
Jan-Mar 2026 |
December 2025 Feb-March 2026 |
|
Likely Tooling |
Python-based |
Possible forked from existing tool based on UA |
Conclusion
OAuth client ID spoofing enables attackers to enumerate accounts and validate credentials at scale, without generating a successful sign-in event in Entra ID logs. The emergence of multiple campaigns with unique tools and infrastructure suggests this technique is gaining traction among threat actors targeting cloud environments.
Beyond evading sign-in telemetry, spoofed client IDs offer additional advantages such as distributing attacks across apparent applications and potentially evading downstream detections that rely on the application name field being populated.
Defenders should treat sign-in log entries with blank application IDs, or those without a correspond application name, as potential indicators of client ID spoofing, and recognize that an AADSTS700016 error code may signal compromised credentials, not just a failed login attempt.