OAuth client ID spoofing exposes a cloud identity blind spot

At a glance

What this is: Proofpoint documents how spoofed OAuth client IDs let attackers enumerate accounts and test credentials in Entra ID without a normal successful sign-in record.

Why it matters: IAM, IGA, and SOC teams need to treat blank application-name log entries as a governance and detection problem because the attack path bypasses assumptions built into application-scoped monitoring and Conditional Access.

By the numbers:

• The campaign tracked as UNK_pyreq2323 targeted over one million unique user accounts across nearly 4,000 tenants.
• The observed high volume of failed attempts triggered account lockouts for approximately 28% of targeted users.

👉 Read Proofpoint's analysis of OAuth client ID spoofing in Entra ID

Context

OAuth client ID spoofing is a technique that abuses how identity platforms log and respond to authentication requests when the application identifier looks valid but does not correspond to a registered app. In this case, the primary identity control gap is not password policy alone, but the trust placed in application metadata inside sign-in telemetry.

For IAM practitioners, the issue sits at the intersection of account enumeration, log interpretation, and Conditional Access scoping. If detections depend on an application name being present, the attacker can suppress the very field analysts use to correlate activity, which makes the attack relevant to both human identity monitoring and cloud access governance.

Key questions

Q: How should security teams detect OAuth client ID spoofing in cloud identity logs?

A: Focus on response patterns, not just successful sign-ins. Investigate blank application-name events, repeated AADSTS error codes, unusual client_id values, and distributed requests from rotating infrastructure. The goal is to identify account enumeration before attackers convert the results into valid credentials or follow-on access attempts.

Q: Why does OAuth client ID spoofing undermine application-scoped IAM controls?

A: Because the attacker can invent or randomise the application context while still triggering meaningful identity responses. If detections and Conditional Access policies depend on a known app name, the attack can bypass those assumptions and keep the enumeration campaign fragmented across many apparently unrelated events.

Q: What breaks when sign-in telemetry treats application name as a trust signal?

A: Correlation breaks first. Analysts lose the ability to distinguish legitimate app traffic from fabricated client identifiers, and per-application rate limits or alerting may never trigger. That creates a blind spot where account probing looks like disconnected noise instead of a coordinated identity attack.

Q: Who is accountable when spoofed client IDs expose valid accounts without a successful sign-in?

A: Identity engineering, SOC monitoring, and Conditional Access owners all share responsibility because the failure spans logging, policy scope, and account protection. The accountability test should ask whether the programme can prove which telemetry fields it trusts, and whether those fields can be manipulated by an unauthenticated requester.

Technical breakdown

How OAuth client ID spoofing shapes Entra sign-in telemetry

OAuth client ID spoofing works because the client_id parameter is accepted during token requests and reflected in sign-in logs as an application identifier. When the supplied identifier is syntactically valid but not tied to a registered app, Entra ID can still return error codes that leak whether a username exists, whether a password is correct, or whether MFA and Conditional Access are enforced. The attacker does not need a successful sign-in to gain value from the response channel. The control weakness is in the metadata path, where logging behaviour becomes an oracle for account state.

Practical implication: Monitor for sign-in events where the application name is blank or inconsistent with expected application inventory.

Why unauthenticated enumeration can bypass application-scoped detections

Traditional enumeration often concentrates on a known first-party application, which makes rate spikes easier to spot and to throttle. Spoofed client IDs break that pattern by fragmenting attempts across many fabricated application identifiers, so per-application detections and Conditional Access policies scoped to a specific app may never engage. In effect, the attacker moves the signal out of the monitoring bucket defenders assumed was authoritative. The technical lesson is that identity telemetry has to be evaluated by response semantics, not just by whether a named app appears in the log.

Practical implication: Build detections that key off response codes, user validity patterns, and log anomalies rather than application-name thresholds alone.

What the campaign scale reveals about automated credential validation

The two campaigns show that this is no longer a one-off trick. One used AWS infrastructure and more than 700,000 spoofed client IDs, while another used Cloudflare-based infrastructure and 3.7 million spoofed IDs with distinct tooling and execution patterns. That diversity suggests independent adoption of the same technique, not a single shared operator. At that point the issue becomes systemic: attackers can industrialise identity probing against large cloud tenants without ever crossing the threshold into a successful authenticated session.

Practical implication: Treat repeated client ID spoofing as an active reconnaissance phase that should feed into account protection, risk scoring, and SOC triage.

Threat narrative

Attacker objective: The attacker aims to enumerate valid accounts and credentials at scale while suppressing the telemetry that would normally expose the campaign.

1. Entry occurs when attackers send OAuth token requests with spoofed client IDs through the Entra ID endpoint, often from rotating infrastructure and user agents designed to avoid straightforward correlation.
2. Credential harvesting happens through error-code analysis, where the response reveals whether a username exists, whether the password is valid, and whether MFA or Conditional Access is in force.
3. Impact follows when valid accounts or password combinations are identified at scale without generating successful sign-in events, weakening account protection and enabling follow-on access attempts.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Blank application-name telemetry is now a governance weakness, not a logging quirk. Proofpoint’s findings show that attackers can turn Entra ID response behaviour into an enumeration channel while leaving the application name empty in sign-in logs. That means the control assumption that a named app will always anchor correlation no longer holds. Teams should stop treating application-name presence as a reliable signal of legitimacy.

Client ID spoofing is a named example of identity telemetry shaping. The attacker is not simply avoiding detection, but manipulating the structure of the event record so that application-scoped policies and per-app detections lose context. That matters because IAM programmes often assume the log schema is a neutral observer. In practice, the schema itself becomes part of the attack surface, so practitioners need to review which response fields are trusted as evidence.

Application-scoped Conditional Access is too narrow for this class of abuse. Proofpoint shows that spoofed client IDs can avoid app-specific controls precisely because they do not map to the applications defenders expect to protect. That makes policy granularity a liability when the attacker can invent the application context. The practical conclusion is that identity governance must move from application-centric assumptions to response-centric monitoring.

Credential validation without success-event generation changes the meaning of failure. AADSTS error codes can now indicate that an account exists, that a password is close to correct, or that a control has been tripped, even when the sign-in never looks successful. That weakens the traditional separation between failed login and actionable compromise. Security teams should treat repeated error-pattern analysis as part of account risk management, not as harmless noise.

Identity security teams need to assume that authentication metadata can be adversarially manufactured. Proofpoint’s campaigns differ in tooling, infrastructure, and client ID generation, which shows the technique is portable and likely to spread. The named concept here is identity telemetry shaping, where attackers manipulate log structure to preserve ambiguity. Practitioners should design detection and governance around behaviour and response semantics, not just around the application label on the event.

From our research:

• Organisations that describe themselves as confident in their AI deployment actually experience a 72% security incident rate, compared to 33% for those who remain cautious, according to The 2026 Infrastructure Identity Survey.
• From our research: Systems with least-privileged AI access had a 17% incident rate versus 76% for over-privileged systems, according to The 2026 Infrastructure Identity Survey.
• From our research: See also 52 NHI Breaches Analysis for breach patterns where identity telemetry gaps and standing access enabled later abuse.

What this signals

Identity telemetry shaping is becoming a practical threat model for cloud IAM. As attackers learn which log fields drive correlation, programmes will need detections that survive absent application names, synthetic client IDs, and response-code abuse rather than assuming the schema is truthful by default.

The operational signal for teams is clear: authentication monitoring has to move closer to response semantics, tenant-wide anomaly patterns, and account state drift. If your programme can only see named applications, it is already too narrow for this class of abuse.

The lesson extends beyond Entra ID. Any identity platform that exposes useful state through differentiated error handling can become an enumeration oracle, which means access governance, SOC triage, and Conditional Access design now need to be reviewed together.

For practitioners

• Detect blank application-name events Flag sign-in records where the application name is missing but the client_id or error behaviour suggests active authentication probing, and route those events into threat hunting and account risk workflows.
• Correlate AADSTS error patterns Track repeated AADSTS50034, AADSTS50126, and AADSTS700016 responses together so analysts can distinguish invalid users, valid users with bad passwords, and spoofed client ID behaviour.
• Shift Conditional Access review beyond app-scoping Review whether any Conditional Access policy only applies to a small set of named applications, then test whether spoofed client IDs can bypass those scopes during enumeration.
• Hunt for distributed enumeration patterns Look for many low-volume requests spread across rotating source infrastructure, user agents, and fabricated client IDs, especially when the same usernames recur across multiple tenants.
• Treat repeated lockouts as compromise indicators When lockouts affect a large portion of targeted users, treat the activity as active credential validation and not just nuisance noise, then prioritise reset and verification steps for impacted accounts.

Key takeaways

• OAuth client ID spoofing turns identity error handling into an enumeration channel that can expose valid accounts without a successful sign-in.
• Proofpoint’s observed campaigns reached more than one million targets in one case and more than two million in another, showing the tactic is already operating at scale.
• Teams should redesign detection around response patterns, blank application-name events, and tenant-wide anomaly logic instead of trusting application-scoped telemetry alone.

Key terms

• OAuth Client ID Spoofing: A technique where an attacker supplies a forged or unregistered OAuth client identifier to influence how an identity platform processes or logs authentication requests. In practice, it can expose account state, password validity, or control enforcement without requiring a successful sign-in.
• Identity Telemetry Shaping: The deliberate manipulation of identity event structure so logs, alerts, or correlation logic become less reliable. Instead of hiding activity completely, the attacker changes the form of the evidence, forcing defenders to rely on response semantics and cross-field validation rather than one trusted log field.
• Account Enumeration Oracle: A response channel that reveals whether a username exists or whether a password is valid. In identity systems, error handling can become an oracle when different responses expose account state, especially if the platform logs or returns enough detail for unauthenticated probing.

What's in the full analysis

Proofpoint's full analysis covers the operational detail this post intentionally leaves for the source:

• The exact AADSTS response behaviours observed across valid, invalid, registered, and spoofed client IDs.
• The campaign timelines, user-agent patterns, and infrastructure fingerprints behind UNK_pyreq2323 and UNK_OutFlareAZ.
• The custom enumeration method used to test how Entra logs spoofed application IDs and account validity.
• The detection recommendations for sign-in logs that show blank application names or suspicious error-code combinations.

👉 Proofpoint's full post covers the campaign comparison, error-code behaviour, and detection guidance in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.