The Ghost Applications: How OAuth Client ID Spoofing Enumerates Microsoft Entra Accounts Without a Successful Sign-In

Originally published by HCLTech.

Attackers are using fabricated OAuth application identifiers to fragment cloud account enumeration across millions of fictional applications. The result is a signal that resembles configuration noise while revealing whether user accounts and passwords are valid.

Key takeaways

• OAuth client ID spoofing separates application identity from account validation, allowing an attacker to learn from Entra ID error responses without registering an application.
• AADSTS700016 can indicate a valid username and password paired with an unrecognized application ID, not only an application configuration problem.
• Detections centered on a named application can miss the activity when the application name is blank and every request uses a different client ID.
• Defenders should correlate error codes, missing application names, client ID uniqueness, username patterns, source infrastructure, and account lockouts.

The signal hiding in plain sight

In December 2025, a rise in failed sign-ins against Microsoft Entra ID could easily have looked ordinary. The requests were spread across application IDs that had never recorded a successful login. No single application generated enough volume to cross a familiar threshold, and none was tied to a name that a security operations center would immediately recognize. The pattern looked like noise. It was not. Two separate groups had discovered the same weakness in how cloud identity activity is categorized, and they were using it to test large numbers of credentials without producing a successful sign-in event.

How OAuth client ID spoofing works

Proofpoint's threat research team describes a technique that abuses the OAuth 2.0 Resource Owner Password Credentials (ROPC) flow. A request to the token endpoint contains a username, a password, and a client ID that is supposed to identify the calling application. Proofpoint found that a fabricated or unregistered client ID still produces responses precise enough to support enumeration.

In the observed behavior, AADSTS50034 indicates that the username does not exist, AADSTS50126 indicates that the username exists but the password is incorrect, and AADSTS700016 is returned when the username and password are valid but the application identifier is not recognized. The last response is especially important. In isolation, it resembles an application registration error. In the context of an unfamiliar client ID and authentication probing, it can be evidence that an attacker has identified a working credential pair.

Figure 1. OAuth client ID spoofing attack and detection workflow.

Two campaigns, two operating models

UNK_pyreq2323. Proofpoint first observed this campaign in mid-January 2026. It operated from AWS infrastructure under the user agent python-requests/2.32.3. The actor modified the trailing digits of a legitimate Exchange Online application identifier and generated more than 700,000 variations. Each spoofed identifier was reused against no more than twelve accounts before being discarded. The campaign targeted more than one million users across nearly 4,000 tenants and caused lockouts for roughly 28 percent of the accounts it touched.

UNK_OutFlareAZ. This campaign began in December 2025 and returned in February and March 2026, primarily through Cloudflare infrastructure. Instead of altering a known identifier, the actor generated a new random UUID for every request. By the time the research was published, the campaign had used 3.7 million spoofed application IDs and targeted more than two million accounts. Activity peaked at an estimated 720,000 users on March 15, 2026. Its alphabetic progression through generic usernames also suggests systematic wordlist-based enumeration.

The differences in user agents, infrastructure, identifier generation, and targeting order suggest independent tools or operators. Help Net Security reached the same conclusion when covering the research. Independent adoption matters because it suggests that the technique is not a one-off trick. It is a repeatable pattern that other actors can reproduce once they understand the response and logging behavior.

Why familiar controls can miss the activity

Many identity detections aggregate failed sign-ins by application name or by a known application ID. Client ID spoofing breaks that assumption. A request can carry a syntactically valid but unregistered identifier, leaving the application name blank in the sign-in record. An actor can also use a different identifier for each request, distributing one campaign across millions of apparent applications and weakening per-application thresholds.

Microsoft's documentation for the ROPC flow recommends against its use because the application handles the user password directly, the flow requires a high degree of trust, and it is incompatible with multifactor authentication. Microsoft also provides migration paths for interactive applications and service workloads. In this attack pattern, Conditional Access policies scoped only to named applications may be insufficient because the fabricated client ID may not match the intended application scope. Identity controls should therefore consider the user, authentication strength, device, location, sign-in risk, and behavior, not only the application label.

The Cloud Security Alliance's recent distinction between identity spoofing and identity abuse is useful here. The false client ID is application-identity spoofing. The confirmed username and password represent potential identity abuse. A complete response must detect both the fabricated application context and the misuse of a legitimate user identity.

What cloud defenders should do now

1. Inventory and retire ROPC. Identify applications, scripts, and service integrations that use the password grant. For interactive applications, move to browser-based authentication with modern libraries and strong authentication. For non-user workloads, prefer managed identities, federated credentials, or certificate-based service principals.
2. Detect missing application context. Alert on sign-in events where the application name is blank or the client ID does not map to a registered application, especially when combined with AADSTS700016, AADSTS50126, rapid client ID changes, or generic username patterns.
3. Correlate across fields and time. Aggregate by user, tenant, source ASN, IP range, user agent, error code, client ID cardinality, and account-lockout activity. A campaign designed to evade per-application thresholds can still expose a stable behavioral pattern across these dimensions.
4. Treat AADSTS700016 as a possible credential-compromise signal. When the response appears with an unfamiliar application identifier during enumeration activity, investigate the affected user, reset the password when warranted, revoke active sessions, and review subsequent access for signs of account takeover.
5. Do not rely only on application-scoped policy. Apply identity and risk controls that remain effective when the client ID is untrusted. Review authentication strength, device state, location, user risk, and workload identity controls as part of one policy strategy.
6. Test the detection safely. Validate the analytics in a controlled tenant using dedicated test accounts and approved procedures. Confirm that the security team can distinguish legitimate application-registration errors from concentrated spoofing and credential-validation behavior.

From static identifiers to continuous authorization

Retiring ROPC is necessary, but it does not resolve the broader trust problem by itself. Cloud platforms often make an authorization decision when a token, key, certificate, or application registration is issued, then continue trusting that artifact until expiration. A stronger design reassesses effective authority at the time of each sensitive operation. The decision should bind the requester to the specific resource, action, purpose, time window, device or workload context, and current risk state. It should fail closed when expected context is missing. Under that model, a client ID is evidence to evaluate, not authority to inherit.

One architecture that illustrates this direction is the Human-Workload-Agent Authorization Mesh (HWAAM). HWAAM uses mission envelopes to restrict the permitted resources, actions, duration, delegation depth, and operational impact. It narrows authority as requests pass through users, applications, workloads, and agents; continuously checks revocation and relationship changes; and records the policy context behind each decision. This approach is relevant to client ID spoofing because the attack succeeds when a mutable application label is allowed to carry more trust than it was designed to support. A request-specific authorization layer would still evaluate the user, resource, behavior, risk, and policy constraints even when the client identifier is fabricated, unregistered, or missing.

HWAAM is not a direct patch for Microsoft Entra ID, and it should not be described as one. Its value in this discussion is architectural. It shows how organizations can move from identifier-centered trust toward continuously evaluated authorization without discarding existing OAuth, Conditional Access, RBAC, or zero trust controls. For CSA readers, this is the larger takeaway: modernizing authentication flows must be accompanied by a review of downstream authorization decisions. Replacing ROPC reduces one exposure, but static trust can reappear elsewhere unless every sensitive action is evaluated against current context and bounded purpose.

The broader lesson

The most important lesson is not limited to one OAuth parameter. Attackers look for fields that defenders collect but do not correlate, then shape their activity around those blind spots. The next variation may not use a spoofed client ID. It may use another mutable attribute that security tooling assumes is trustworthy or stable.

A durable defense treats application identity as one signal among many and applies Zero Trust principles to the entire authentication context. It also recognizes the potential use of valid credentials, which maps to MITRE ATT&CK's Valid Accounts: Cloud Accounts technique. Cloud identity monitoring should answer a behavioral question: does this sequence of requests make sense for the user, application, device, network, and organization, even when every attacker-controlled field changes from one request to the next?