Fake OAuth client IDs are helping attackers slip past sign-in logs

Attackers running account enumeration against Microsoft cloud tenants have added a step that keeps their probing out of the usual telemetry. They spoof the OAuth client ID, the globally unique identifier assigned to an application and passed as client_id in an authentication request. Microsoft Entra ID records that value as the application ID in its sign-in logs, and the way it handles unfamiliar identifiers opens a gap that operators have started to work through.

Entra sign-in logs sit at the center of how defenders spot malicious authentication, from user enumeration to password spraying to early access attempts. Common evasion already includes rotating user agents and proxy services that cycle source IPs on every request. Client ID spoofing extends that toolkit. Spoofed identifiers let an unauthenticated attacker enumerate accounts and infer whether a password is valid, all without producing a successful sign-in event.

How the technique works

Proofpoint researchers reproduced the method against Entra ID by sending POST requests to Microsoft’s OAuth 2.0 token endpoint using the Resource Owner Password Credentials flow, which accepts a username and password. A custom PowerShell module, Invoke-ClientIdSpoofEnum, recorded how Entra responded to requests carrying different kinds of client ID. The responses vary in a way that carries information: a registered application fills in both the application ID and the application name in the sign-in log, and a syntactically valid client ID with no matching application leaves the name field blank. A malformed identifier still draws a response, with both fields empty.

One code marks an invalid username, another marks a valid username paired with a wrong password, and AADSTS700016, which reads as an unrecognized application identifier, comes back when the username and password are both correct. The invalid username case never reaches the sign-in log at all, since Entra ID only records attempts against usernames that exist. An attacker reading that last code has confirmed a working credential pair, and the tenant has no successful sign-in record to show for it.

Why the blank field matters

A spoofed client ID leaves the application name blank in the log. Detections tuned to watch for surges against a named application can pass over the activity entirely, since the field they key on holds nothing. Even where the enumeration itself gets caught, the absence of a sign-in event can leave defenders unaware that a valid credential was found, and compromised accounts can go unnoticed.

Older enumeration tooling aimed at hardcoded first-party applications, often CLI utilities like Azure AD PowerShell that appear in every tenant. A spike against one such application tends to alert a SOC. Spreading attempts across thousands of fictional applications scatters the signal, weakens per-application detection, and slides past rate limits keyed to a single app. Conditional Access policies scoped to a targeted application also go unenforced, because a spoofed client ID matches no policy scope.

“Using spoofed fields is a technique that has been known for years. The challenge for attackers is identifying which fields can be spoofed successfully, ideally before defenders are aware of them. There are constant discussions in underground forums about fields that can be spoofed or otherwise abused, and attackers are quick to take advantage of those discoveries,” Yaniv Miron, Director, Threat Research at Proofpoint, told Help Net Security.

Two campaigns, two toolsets

Proofpoint tracked one campaign as UNK_pyreq2323, which surfaced on January 14, 2026 and ran from AWS infrastructure under the user agent python-requests/2.32.3. Its operator spread enumeration across more than 700,000 spoofed client IDs, built by taking the Exchange Online application prefix and randomizing the final six digits. The campaign reached over a million user accounts across nearly 4,000 tenants, and the volume of failed attempts locked out about 28% of the users it touched.

A second campaign, UNK_OutFlareAZ, began in December 2025, ran mostly from Cloudflare infrastructure, and moved through two waves that peaked in late December and again on March 15. It reached more than 2 million users and drew on 3.7 million spoofed application IDs, each one a fully random UUIDv4 generated per request, a step up in maturity that limits correlation. Usernames advanced in alphabetical order, and generic handles such as dsmith, msmith, and jbrown recurred across tenants, a sign of a shared wordlist.

The differences run through hosting, client ID generation, and enumeration order, and they suggest separate tools or operators arriving at one technique on their own.

“We’ve observed multiple campaigns using this technique; however, we cannot presently confirm whether the activity can be attributed to the same threat actor or is being conducted by different clusters of threat actors. It’s likely the result of a combination of discussions in hacker forums and attackers’ own trial-and-error experimentation,” Miron said. On how fast such methods travel, he added that “Once a new spoofing technique is disclosed – whether by researchers or threat actors – it typically becomes widely known across both communities within hours or days.”

Beyond one vendor

“We see this as a broader industry blind spot. While our research focuses on Entra ID and this specific technique, the underlying challenge isn’t limited to a single vendor. Similar issues likely exist across other identity provider platforms, although the specific fields and implementation details will vary,” said Miron.

A successful authentication event has long served as dependable ground truth for judging whether a credential held. This technique erodes that footing. As Miron framed the lesson from the research, “Overall, this research reinforces an important point: a successful sign-in event should no longer be treated as the definitive source of truth when determining whether credentials have been compromised.”

Sign-in entries with a blank application ID, or with an application ID and no matching name, deserve a second look as possible markers of client ID spoofing. An AADSTS700016 error code carries its own weight in that review: it can mean an attacker just confirmed a working username and password, and the log holds no successful sign-in to say so.