Attack Technique: OAuth Client ID Spoofing


To execute this attack, adversaries target the Resource Owner Password Credentials (ROPC) flow. Designed for legacy applications that cannot support web-based browser redirection, ROPC permits an application to collect a user's plaintext password directly and exchange it for an access token via a backend API call. A standard ROPC authentication request requires several mandatory parameters, most notably the grant_type, the user's plaintext credentials, and a client_id.

Within Microsoft Entra ID, an attacker directs this request to the /common/oauth2/token endpoint. Instead of providing a legitimate client_id assigned to a registered application, the attacker submits a fabricated, unregistered, fully randomised, or malformed UUID. Entra ID evaluates user credentials before validating the application context, therefore the system's logging behaviour changes drastically when a fake client_id is introduced. By systematically using spoofed IDs, attackers strip the application context from the resulting telemetry, leaving the AppDisplayName field completely blank in security logs.

Security researchers have utilised custom tooling, such as the Invoke-ClientIdSpoofEnum PowerShell module, to meticulously map these varying responses across four distinct scenarios:

• Valid Client ID with a Registered Application: Under standard operations, when the provided UUID corresponds to a legitimate application, Entra ID processes the request normally. Both the Application ID field (AppId) and the human-readable Application Name field (AppDisplayName) are fully populated and recorded in the Entra ID sign-in logs.
  
• Valid Client ID Structure for an Unregistered Application: If an attacker supplies a syntactically valid UUIDv4 that does not map to any registered application within the tenant, Entra ID processes the authentication request but only records the raw Application ID. The critical Application Name field (AppDisplayName) is left entirely blank in the resulting telemetry.
• Fully Randomised UUIDs: Functioning similarly to the unregistered application scenario, when an attacker generates a fully random UUIDv4 per request, the identity provider processes the payload but generates an authentication log with a completely blank Application Name.

• ‍Malformed Client IDs: If the provided identifier violates strict UUIDv4 structural formatting, Entra ID does not immediately reject the payload at the network or API edge. Instead, it processes the authentication attempt, evaluates the provided credentials, and returns specific error codes. However, neither the Application ID nor the Application Name is populated in the resulting sign-in logs.

Weaponising the AADSTS Error Code Oracle

Attackers use Azure Active Directory Security Token Service (AADSTS) error codes as an oracle to confirm the validity of massive data dumps without triggering successful sign-in alerts.

OAuth Threat Landscape

Client ID spoofing is part of a larger trend of attackers subverting delegated authorisation protocols to achieve persistence without malware:

• Device Code Phishing: Attackers exploit flows meant for IoT devices to bypass interactive MFA. Victims are tricked into entering a device code on a legitimate Microsoft domain, handing highly privileged access tokens directly to attackers (heavily utilised by the STORM-2372 threat group and the Kali365 Phishing-as-a-Service platform).
• ‍OAuth Redirect Abuse: Threat actors register malicious apps and construct authorisation URLs designed to fail (using parameters such as prompt=none), triggering an automatic redirect to attacker-controlled infrastructure for consent phishing or Adversary-in-the-Middle session theft.

Threat Actor Campaigns

Security researchers have observed the rapid adoption of OAuth Client ID spoofing by multiple independent threat actors:

• UNK_pyreq2323: Active from January to March 2026, this campaign was orchestrated from Amazon Web Services (AWS) infrastructure, utilizing the HTTP user agent string python-requests/2.32.3. The operator hardcoded the prefix of the legitimate Microsoft Exchange Online application ID and utilised an algorithm to randomise only the final six digits of the identifier.
• UNK_OutFlareAZ: Emerging in December 2025, the attacker routed traffic through Cloudflare proxies and utilised a deceptive user agent string: Microsoft Office/16.0 (Windows NT 10.0; Microsoft Outlook 16.0.12026; Pro). This campaign generated a completely unique, fully randomised UUIDv4 client ID for every single authentication attempt, limiting correlation. Enumeration of users is in strict alphabetical order using generic corporate wordlists, systematically mapping employee directories while evading detection.

Mitigations and Recommendations

• Response Action: If an AADSTS700016 error is observed alongside a blank AppDisplayName, treat it as a confirmed credential compromise. Immediately execute a forced password reset and revoke all active sessions and refresh tokens.
  

• Deprecate ROPC: Completely phase out and actively block the Resource Owner Password Credentials grant type across all environments in accordance with RFC 9700.
  
• Implement PKCE: Mandate Proof Key for Code Exchange (PKCE) for all OAuth clients to prevent authorisation code interception.
  
• Validate Redirect URIs: Enforce exact string matching for all redirect configurations, strictly disabling wildcard or partial URL matching to neutralise redirect abuse.
• ‍Constrain Access Tokens: Use Demonstration of Proof-of-Possession (DPoP) or mTLS to cryptographically bind access tokens to the client, neutralising token replay attacks originating from AiTM phishing kits.