An OAuth client ID is the public identifier an application presents when it requests a token from an identity provider. In Microsoft Entra ID, the OAuth client ID maps to a registered application object in the tenant, which is what gives defenders the application name, the owner, and the expected sign-in behavior.
The client ID is not a secret. It travels in the request, it is trivial to observe, and it is trivial to fabricate. Attackers do not need to compromise an account on the first try. Increasingly, they are using exposed identity data and spoofed OAuth client IDs to quietly test cloud identity defenses, validating accounts and probing authentication workflows without generating the obvious alerts many security teams rely on.
That is why Proofpoint’s recent research on OAuth client ID spoofing in Microsoft Entra ID caught my attention. Proofpoint reported that multiple cloud campaigns are abusing spoofed OAuth application identifiers to enumerate accounts, infer password validity, and avoid generating the successful sign-in events many teams rely on for detection.
For identity security teams, that matters. Email addresses, usernames, tenant details, job titles, group membership, and other exposed identity data are not harmless. They are attacker-ready inputs. Once adversaries know who exists in a tenant, the next move is often account enumeration, credential validation, password spraying, or authentication attempts from unexpected clients.
To be clear, I am not saying this specific technique was used in the recent Hatman-related data exposures. But when identity data is exposed, this is exactly the type of activity defenders should expect next: enumeration, credential validation, and authentication probing against cloud identity systems.
Cayosoft Guardian now includes a new threat detection for this activity: CTD-000206: Microsoft Entra ID Account Enumeration via Unknown OAuth Client ID.
Why Unknown OAuth Client IDs Matter
In Microsoft Entra ID, authentication requests typically include an OAuth client ID that identifies the application requesting access. When that application is known, defenders get useful context: the application name, ownership, expected behavior, and historical sign-in patterns.
When the client ID is unknown, missing, spoofed, or does not map cleanly to an application in the tenant, that context starts to disappear. Instead of seeing a familiar application, the security team may see failed sign-ins with limited application metadata. That makes the activity easier to overlook, especially if the attacker spreads attempts across users, IP addresses, user agents, or fabricated client IDs.
That is the blind spot. Many teams have built detections around known applications, successful sign-ins, or clear password spray patterns. But this technique can create signals that look like application misconfiguration or routine authentication failure unless they are correlated properly.
Proofpoint also called out the detection challenge directly: when the application name is blank or unfamiliar, detections that depend on known application names can miss the pattern. That is what defenders need to pay attention to. The attacker is not only testing identities. They are shaping the telemetry analysts depend on.
How OAuth Client ID Spoofing Works
At a high level, the technique is straightforward. The attacker sends a POST request to Microsoft’s OAuth token endpoint using the legacy Resource Owner Password Credentials, or ROPC, flow. That request includes a username, a password, and a client ID that is supposed to identify the application requesting the token.
The client ID is the trick. Instead of using a normal registered application, the attacker supplies a spoofed or fabricated OAuth client ID. Microsoft Entra ID still returns distinct AADSTS error codes based on what it sees in the request. Those responses can tell the attacker whether the username exists, whether the password is wrong, and in some cases whether the username and password are both valid.
That last case is the important one. AADSTS700016 normally points to an application identifier that is not recognized. But in this context, it can also tell the attacker that the username and password were correct, while no successful sign-in is logged. From a defender’s point of view, this may still look like failed authentication activity. From the attacker’s point of view, it can confirm a working credential pair.
This is Not Just a Logging Problem
Authentication telemetry is one of the best places to catch identity attacks early, but only if we understand what the attacker is trying to learn. In this case, the goal may not be immediate access. The goal may be discovery.
An attacker with a list of email addresses can start testing which accounts exist, which credentials might be valid, and which controls are enforced. If MFA is missing, weak, inconsistently applied, or required only for certain apps, the risk increases quickly. Even with MFA in place, account enumeration gives attackers useful information for future phishing, token theft, adversary-in-the-middle attacks, help desk abuse, and targeted social engineering.
This is why I keep coming back to a simple point: identity data has operational value to attackers. A username is not “just” a username. In Microsoft 365 and Entra ID environments, it is often half of the login prompt.
This is the uncomfortable part of identity data exposure. The breach notification may focus on the data that was taken, but defenders also need to think about what that data enables. A valid username can help an attacker tune phishing campaigns, identify high-value users, test authentication behavior, and determine where conditional access, MFA, or legacy authentication policies create gaps.
That does not mean every exposed account will be compromised. It means every exposed identity becomes part of the attack surface. Security teams need detections that recognize this early stage instead of waiting for a successful sign-in, mailbox compromise, or privilege escalation event.
What Cayosoft Guardian Detects
CTD-000206 identifies authentication activity in Microsoft Entra ID involving unknown OAuth client IDs that may indicate account enumeration, credential validation, or attempts to bypass application-centric monitoring.
The value is not in treating every unknown client ID as automatically malicious. That would create noise. The value is in correlating the unknown client ID with the surrounding authentication behavior, including repeated failures, activity against multiple users, suspicious error codes, unfamiliar source infrastructure, or patterns that look like credential testing.
Individually, these events may appear benign. Together, they can form a strong signal that an attacker is actively probing your identity perimeter.
Final Thoughts
Identity attacks rarely begin with compromise. They begin with discovery, validation, and quiet probing that tells an attacker where the identity perimeter is weak. That is what makes this technique important. Unknown OAuth client IDs may look like failed sign-in noise, but in the right context they can be an early signal that exposed identity data is being put to work.
Defenders should not wait for a successful login to decide an identity attack is underway. The earlier signal is often the test itself: which users exist, which controls respond, and which authentication paths can be abused without looking obvious. That is the gap this detection is designed to close.
FAQs
An OAuth client ID is the public identifier an application sends when requesting a token from an identity provider. In Microsoft Entra ID, it maps to a registered application in your tenant. It is not a secret, and it is not a credential, which is why it can be spoofed.
Yes. Because the OAuth client ID is a public value sent in the token request, an attacker can supply a fabricated one. Microsoft Entra ID still returns distinct error codes, and those responses can reveal whether an account exists or whether a password is valid.
AADSTS700016 normally means the application identifier in the request was not found in the directory. In an enumeration context, it carries a second meaning: the username and password may have been valid, but no successful sign-in event is written to the logs.
The ROPC flow still functions at the protocol level, but Microsoft recommends against it and has deprecated ROPC support in MSAL. It does not support MFA, Conditional Access, or SSO. Blocking legacy authentication removes most of its usefulness to attackers.
No. MFA blocks the sign-in, but it does not stop the reconnaissance. Enumeration confirms which accounts exist and which credentials are valid before any MFA prompt is reached, which is useful input for phishing, help desk abuse, and adversary-in-the-middle attacks.
Correlate unknown OAuth client IDs with the surrounding authentication behavior: repeated failures, multiple targeted users, suspicious AADSTS codes, and unfamiliar source infrastructure. Cayosoft Guardian detection CTD-000206 flags this pattern.
See Cayosoft in Action
Cayosoft is recognized by Gartner as an ITDR solution provider and provides solutions that make identities more resilient to attacks and guarantee a fast forest recovery, if needed. Learn how Cayosoft Guardian facilitates granular change tracking, post-breach analysis, and long-term AD security improvements. Schedule a demo to see the capabilities in depth.