By NHI Mgmt Group Editorial TeamBased on Proofpoint: “OAuth Client ID Spoofing: Why Fake Client IDs Are Gaining Traction for Stealthy Enumeration” (July 10, 2026)

TL;DR: Multiple cloud campaigns abused OAuth client ID spoofing to enumerate accounts and infer password validity in Microsoft Entra ID without generating a successful sign-in event; one campaign targeted more than one million accounts across nearly 4,000 tenants and another exceeded 2 million users, according to Proofpoint. The finding shows that application-name based detection is no longer enough when identity telemetry can be deliberately shaped.

At a glance

What this is: Proofpoint describes OAuth client ID spoofing as a cloud identity blind spot that lets attackers probe account and password validity in Entra ID without a successful sign-in event.

Why it matters: IAM teams need to detect spoofed authentication patterns because application-name filters and per-app rate limits can miss enumeration that is already shaping account lockouts and credential exposure.

By the numbers:

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

Context

OAuth client ID spoofing is an authentication telemetry abuse pattern, not a new login protocol flaw. In Microsoft Entra ID, the client_id field influences how the platform labels and logs a request, which means an attacker can deliberately shape the evidence defenders rely on while still probing account validity.

For identity programmes, the problem is not only that requests can be malformed or spoofed. It is that detection logic often assumes the application name field will be present and trustworthy, even though spoofed identifiers can leave that field blank and still generate useful error responses for enumeration.

Proofpoint describes multiple campaigns that used this behaviour at scale, showing that the gap is already operationally relevant rather than theoretical. The defensive issue spans human identity telemetry, conditional access scoping, and cloud authentication monitoring.

Key questions

Q: What breaks when attackers spoof OAuth client IDs in Entra ID?

A: The main failure is that application-scoped detections lose a reliable label to key on, while Entra ID can still return responses that reveal whether a username exists or a password is valid. That means telemetry can be informative for attackers but ambiguous for defenders, especially when requests are spread across many fake application identifiers.

Q: Why do spoofed client IDs increase the risk of account enumeration?

A: They let attackers probe authentication outcomes without creating a conventional successful sign-in event, so the platform's error handling becomes an oracle for account state. When that probing is distributed across many fabricated client IDs, per-application rate limits and alerts are much less effective.

Q: What are the signs that OAuth client ID spoofing is happening?

A: Look for sign-in attempts with blank application names, inconsistent application IDs, repeated AADSTS error codes, and user-agent patterns that recur across many usernames or tenants. Those signals matter because the activity may be visible in logs even when the application context is not trustworthy.

Q: How should teams detect spoofed OAuth activity without relying on application names?

A: Use a combination of client ID anomalies, AADSTS response patterns, IP and user-agent clustering, and username enumeration patterns to reconstruct the campaign. The goal is to detect authentication abuse from the behaviour of the request, not from a supposedly stable app label.

Technical breakdown

How OAuth client ID spoofing changes Entra ID log semantics

In OAuth, the client_id is the application identifier presented during token requests. Entra ID uses that identifier to populate sign-in telemetry, so when the supplied client_id is syntactically valid but not tied to a registered app, the log may contain an application ID without an application name. That matters because many monitoring rules key off application labels, not raw request metadata. The technique does not need a legitimate app registration to be useful. It exploits the platform's error handling and logging behaviour to create an observable difference that can be used for inference.

Practical implication: monitor for sign-in events with blank or missing application names, not just named applications.

Why ROPC and AADSTS responses enable account enumeration

The Resource Owner Password Credentials flow allows direct username and password submission to the token endpoint, which makes it suitable for bulk probing when attackers do not need interactive user consent. The returned AADSTS codes differentiate invalid usernames, invalid passwords, and other state conditions, so a request can leak whether an account exists even if authentication never succeeds. That leakage becomes more useful when the attacker rotates spoofed client IDs, because rate limits and application-based detections are harder to correlate across many fake app identities.

Practical implication: treat authentication error patterns as intelligence, not just failures, and correlate them across users, IPs, and client IDs.

How spoofed client IDs evade application-scoped Conditional Access

Conditional Access policies scoped to specific applications assume the application object is identifiable and stable. A spoofed client_id breaks that assumption by making the request appear to originate from an application context that does not exist in the tenant's inventory. The result is a detection gap between policy intent and the actual telemetry path. In these campaigns, attackers also used rotating infrastructure and user agents, which reduced the chance that one application or one source would stand out in isolation. That combination makes correlation the real control point.

Practical implication: validate whether your Conditional Access and log analytics rules depend on a trusted application name field.

Threat narrative

Attacker objective: The attacker aims to identify valid accounts and password combinations while minimizing visible authentication telemetry.

  1. Entry occurs when attackers send OAuth token requests to Entra ID using spoofed client identifiers and direct credential submission through the ROPC flow.
  2. Credential access happens when AADSTS responses reveal whether the username exists, whether the password is valid, and whether MFA or Conditional Access is being enforced.
  3. Escalation follows as the actor fragments requests across many fictional applications and rotating infrastructure to avoid application-scoped detections and rate limits.
  4. Impact is account enumeration at scale, with valid credential pairs and lockouts created without a successful sign-in event that defenders would normally use for alerting.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OAuth client ID spoofing is a telemetry manipulation problem before it is an authentication problem. The attack works because defenders often trust the application name field as a stable correlate of intent, but the platform can be made to return useful authentication state even when that field is absent. That breaks a common monitoring assumption in Entra ID operations. Practitioners should stop treating application labels as authoritative evidence of legitimacy.

Application-scoped controls are fragile when the application identity itself can be fabricated. Conditional Access policies that are scoped to known applications do not behave as a complete control when requests are driven through spoofed or nonexistent client IDs. This is not a narrow logging quirk. It is a governance gap between policy design and the actual identity surface being evaluated. Teams need to reassess how much of their authentication control plane depends on a trusted application object.

Account enumeration at scale is now a cloud identity control issue, not just an adversary tradecraft issue. The campaigns described by Proofpoint show that attackers can spread activity across many fake apps, many source IPs, and many usernames without generating the success signals that older detections expect. The implication for identity governance is that telemetry integrity has to be treated as part of access control, not only as a SOC concern.

Telemetry-aware detection must become a first-class identity control. When a request can be authenticated enough to produce informative error handling but not enough to show up as a conventional sign-in success, the control boundary has shifted from login verification to response interpretation. That means identity teams must govern how platform responses are interpreted, correlated, and escalated. The practical conclusion is that log semantics are now part of the control surface.

Blank application names are a named signal of spoofed client ID activity. Proofpoint's analysis sharpens a useful concept here: application-name absence as a detection trigger. That signal is valuable because it identifies requests that are valid enough for the platform to process but abnormal enough to lack a trustworthy application label. Practitioners should build detections around that absence, not around successful sign-in outcomes.

From our research library:

What this signals

Telemetry integrity is now part of identity governance. When authentication responses can be shaped to conceal the application context, identity teams need to govern the quality of the evidence as carefully as the access decision itself. The practical shift is from trusting sign-in labels to validating whether those labels are complete, consistent, and actionable.

Client ID spoofing exposes a logging assumption that many programmes never tested. The assumption was that application identity would remain stable enough for detection and Conditional Access correlation. Proofpoint's examples show that this assumption can be broken at scale, so detection engineering has to treat absence of an application name as a signal in its own right.

For practitioners

  • Inspect sign-in events with blank application names Search Entra ID logs for authentication attempts where the application ID is present but the application name is missing, then correlate those events with username validity probes and repeated AADSTS errors.
  • Correlate AADSTS codes across client IDs Group failed sign-in attempts by source IP, user agent, username pattern, and AADSTS response so that spoofed application identifiers do not fragment the investigation into separate low-signal alerts.
  • Review Conditional Access scope assumptions Check whether policies rely on known application objects in ways that can be bypassed when the client_id does not map to a registered app in the tenant.
  • Reduce reliance on application name in detections Tune SIEM and identity analytics rules so they flag anomalous authentication behaviour even when the application name is absent, malformed, or inconsistent across requests.
  • Validate lockout and enumeration thresholds Test whether repeated password and username probes trigger alerts before they create broad lockouts, especially when requests are distributed across many spoofed client IDs.

Key takeaways

  • OAuth client ID spoofing turns Entra ID authentication metadata into an attacker-controlled signal that can expose account validity without a successful sign-in event.
  • Proofpoint observed multiple campaigns using the technique at scale, including activity that targeted more than one million accounts across nearly 4,000 tenants and another that exceeded 2 million users.
  • Defenders should build detections around blank application names, AADSTS response patterns, and cross-user correlation rather than relying on application labels alone.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-04 — Insecure AuthenticationSpoofed client IDs exploit authentication behaviour and error handling in Entra ID.
NHI-02 — Secret LeakageThe article shows how error responses can leak account and password validity state.
NHI-10 — Human Use of NHIAttackers abuse application identifiers to impersonate legitimate application context in identity flows.
Recommendation — Harden authentication telemetry and validate abnormal client_id patterns as insecure authentication signals. Treat response leakage as a credential exposure risk and suppress unnecessary authentication detail. Separate human-driven login signals from application context and flag impossible application identity combinations.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsConditional Access scope and application-based authorization assumptions are central to the gap.
DE.CM-09 — Configuration and vulnerability monitoringDetection relies on monitoring anomalous sign-in behaviour and telemetry quality.
Recommendation — Review application-scoped authorization rules for dependence on a trusted application name or object. Monitor sign-in telemetry for blank labels, abnormal AADSTS patterns, and distributed probing.
NIST SP 800-53 Rev 5IA-5 — Authenticator ManagementThe campaign abuses authentication workflows and credential validation logic.
Recommendation — Apply authenticator management controls to reduce validation leakage in authentication flows.
MITRE ATT&CKTA0006;TA0007 — Credential Access; DiscoveryThe activity combines account discovery with credential validation through authentication responses.
Recommendation — Map client ID spoofing to credential access and discovery tactics in detection engineering.

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.
  • Authentication Oracle: A response path that leaks useful state about usernames, passwords, or policy enforcement even when authentication fails. In identity systems, error codes and logging behaviour can inadvertently tell an attacker whether an account exists, whether a password is valid, or whether additional controls are active.
  • Application-Scoped Detection: A monitoring approach that keys alerts or policy decisions to a specific application object or application name. It is useful only when that application context is trustworthy and stable, which means it can fail when attackers can fabricate or suppress the application label in the request path.
  • Telemetry integrity: Telemetry integrity is the confidence that logs, metrics, and traces accurately reflect what happened. If an attacker can alter, redirect, or suppress telemetry, the security team may still see data, but it can no longer trust that data for investigation, detection, or compliance evidence.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on July 14, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org