Cybersecurity researchers have identified a growing cloud attack technique known as OAuth client ID spoofing, which allows threat actors to probe Microsoft Entra ID environments while slipping past common sign-in telemetry.
According to Proofpoint, at least two distinct threat clusters have adopted the technique in large-scale campaigns. The activity allows attackers to enumerate user accounts and validate stolen credentials without generating the type of successful sign-in event that defenders often rely on for detection.
The issue is not a traditional software exploit.
It is a weakness in how authentication responses and logging behavior can be abused.
What Is OAuth Client ID Spoofing?
OAuth client IDs are globally unique identifiers assigned to applications that request access to user data.
In normal authentication flows, the client_id identifies the application making the request. Security teams often use this information to understand which app is involved in a sign-in attempt.
In these campaigns, attackers send authentication requests using spoofed or fictional OAuth client IDs.
By analyzing the error responses returned by Microsoft Entra ID, attackers can infer whether:
- a user account exists
- a password is correct
- a credential list contains usable entries
The dangerous part is that this can happen without creating the kind of successful sign-in event that would normally alert defenders.
Why This Matters
Entra ID sign-in logs are one of the main sources defenders use to detect malicious authentication activity.
They are commonly used to spot:
- password spraying
- brute-force attempts
- user enumeration
- suspicious application access
- initial access attempts
OAuth client ID spoofing weakens that visibility.
When spoofed client IDs are used, the sign-in log may record only the application ID, without a corresponding application name. This means detections that depend on known application names, specific app patterns, or application-scoped Conditional Access policies may miss the activity.
Attackers can fragment authentication attempts across many fictional applications, making the activity harder to correlate.
How Attackers Abuse the Gap
Proofpoint says the latest campaigns use HTTP POST requests to Microsoft’s OAuth 2.0 token endpoint with the Resource Owner Password Credentials flow.
Rather than using a registered application, the attackers supply spoofed client IDs. The response includes Entra ID error codes that can reveal useful information about the account or credential state.
This allows attackers to check large stolen credential lists at scale.
The technique gives them a way to identify promising accounts for later access while reducing the chance of triggering traditional sign-in alerts.
Two Large Campaigns Observed
Proofpoint identified two large campaigns that independently adopted OAuth client ID spoofing around the end of 2025.
The first cluster, tracked as UNK_pyreq2323, operated from January to March 2026. It used more than 700,000 spoofed client IDs from AWS infrastructure and targeted more than 1 million accounts across nearly 4,000 tenants. Proofpoint said the activity caused account lockouts for roughly 28% of targeted users due to failed attempts.
The second cluster, tracked as UNK_OutFlareAZ, began in December 2025 and used Cloudflare infrastructure. It targeted more than 2 million users with 3.7 million randomized spoofed application IDs.
Both campaigns used valid UUID-style client IDs and showed signs of working from precompiled username wordlists.
However, their behavior differed. UNK_pyreq2323 modified trailing digits of known application IDs and reused spoofed IDs across multiple users. UNK_OutFlareAZ generated a unique client ID per request.
That level of variation makes detection more difficult.
Why Conditional Access May Not Be Enough
Many organizations use Conditional Access policies to control which users and applications can access cloud resources.
But OAuth client ID spoofing can bypass some application-scoped logic.
If a policy is scoped to a specific application, a spoofed or fictional client ID may not trigger it in the expected way. That creates a gap for attackers who deliberately avoid targeting one known application identity.
This does not mean Conditional Access is ineffective.
It means policies must be designed with broader authentication abuse in mind, not only known application names.
What Defenders Should Watch For
Security teams should look beyond successful sign-ins and known application names.
Useful detection areas include:
- high volumes of failed token requests
- sign-in records with application IDs but no application name
- large numbers of unique client IDs
- unusual Resource Owner Password Credentials activity
- spikes in account lockouts
- repeated AADSTS error patterns
- authentication attempts from cloud hosting providers
- activity spread across many fictional applications
- tenant-wide enumeration patterns
- attempts that do not map cleanly to normal app usage
The key is to detect the pattern of abuse, not only the application label.
Recommended Defensive Actions
Organizations using Microsoft Entra ID should review authentication monitoring and Conditional Access coverage.
Recommended actions include:
- monitor failed authentication attempts, not only successful sign-ins
- detect missing or blank application names in sign-in telemetry
- alert on high-cardinality OAuth client IDs
- review use of ROPC and reduce password-based flows where possible
- enforce phishing-resistant MFA for sensitive users
- investigate large-scale account lockouts
- apply Conditional Access policies broadly, not only to specific apps
- monitor authentication attempts from unusual cloud infrastructure
- correlate Entra logs with network, identity, and endpoint telemetry
- review detections that depend on application display names
Passwordless and phishing-resistant authentication can significantly reduce the value of stolen passwords, even when attackers can validate them.
Final Thoughts
OAuth client ID spoofing shows how attackers are evolving cloud identity attacks.
They are not only trying to steal passwords. They are also learning how to abuse authentication flows, error responses, and logging assumptions to validate credentials while staying below traditional detection thresholds.
Cloud identity monitoring cannot rely only on successful sign-ins, known application names, or standard authentication alerts. Attackers are targeting the gaps between authentication, telemetry, and application trust.
To defend against this, organizations need broader visibility into token requests, failed authentication patterns, OAuth behavior, and unusual application identifiers across their Entra ID environments.
