OAuth Client ID Spoofing Enables Silent Credential Validation Against Microsoft Entra ID — UNK_pyreq2323 & UNK_OutFlareAZ

OAuth Client ID Spoofing Enables Silent Credential (TL-2026-1342), also tracked as OAuth Client ID Spoofing, is a high-severity software vulnerability, first published 2026-07-14. It is attributed to UNK_pyreq2323 with low confidence, affects Microsoft Microsoft Entra ID (Azure Active Directory), maps to 20 MITRE ATT&CK techniques (T1036, T1036.005, T1078.004), and is covered by 9 detection rules and 15 indicators of compromise.

Key facts for TL-2026-1342

Threat ID
TL-2026-1342
Also known as
OAuth Client ID Spoofing, Fake Client ID Enumeration, Entra ID Application ID Spoofing
Severity
HIGH
Status
ACTIVE
Category
VULNERABILITY
First published
2026-07-14
Last reviewed
2026-07-14
Attribution
UNK_pyreq2323
Attribution confidence
LOW
Motivation
UNKNOWN
Target sectors
cross-sector, enterprise-saas-tenants, finance, health, government administration, technology
Target regions
Global
Detection rules
9
Indicators of compromise
15

Malware and tooling in OAuth Client ID Spoofing Enables Silent Credential

Malware and tooling: Invoke-ClientIdSpoofEnum

Two distinct threat clusters, UNK_pyreq2323 and UNK_OutFlareAZ, are abusing Microsoft Entra ID's OAuth 2.0 Resource Owner Password Credentials (ROPC) token endpoint with spoofed, non-registered client (application) IDs to enumerate valid usernames and validate stolen credentials without ever producing a successful sign-in event. Because the spoofed application ID leaves the application-name field blank in sign-in logs, activity fragments across thousands of fictional applications and evades per-application detections, rate limiting, and Conditional Access policies scoped to real apps.

How OAuth Client ID Spoofing Enables Silent Credential works

Proofpoint threat research (published July 2026, syndicated by The Hacker News, Help Net Security, Infosecurity Magazine, Cybersecurity Dive, and others) documents a previously under-appreciated blind spot in Microsoft Entra ID's OAuth 2.0 token endpoint (`/common/oauth2/token`): the Azure AD Security Token Service (AADSTS) returns materially different error codes depending on whether the submitted `client_id` corresponds to a real, registered application, and independently, whether the submitted username/password pair is valid. Because the ROPC grant type accepts a username and password directly in the POST body alongside an arbitrary `client_id` parameter, an attacker never needs to register or control a real Entra application — they only need a syntactically plausible (or even malformed) GUID.

When the client ID does not resolve to a registered application, Entra ID still processes the credential check and returns an AADSTS error, but the sign-in log entry that results has an application ID with no corresponding application name. This lets attackers infer three things purely from error codes and without generating a single successful authentication: (1) whether a username exists at all (AADSTS50034 for non-existent accounts, which Entra does not log to the sign-in log), (2) whether an existing username's password is wrong (AADSTS50126), and (3) whether the username and password pair is fully valid (AADSTS700016 — 'application not found in directory', returned only once credentials check out). None of these produce a successful interactive or non-interactive sign-in record, so account-takeover and password-spray detections tuned to successful logons or to specific first-party/third-party application names never fire.

Two clusters were tracked operating this technique at industrial scale. UNK_pyreq2323 ran from January 14 through early March 2026 (peaking late January/early February), using the Python `requests` library (`python-requests/2.32.3` User-Agent) from Amazon Web Services infrastructure. It generated more than 700,000 spoofed client IDs by taking Microsoft's own first-party Exchange Online application ID prefix (`00000002-0000-0ff1-ce00-`) and randomizing the trailing six hex digits, reusing each spoofed ID across up to 12 different target users. It targeted over 1 million accounts across roughly 4,000 Entra tenants, and its aggressive password-attempt volume caused Entra ID smart lockout to trigger for approximately 28% of targeted accounts — a side effect that made the campaign detectable primarily through account-lockout spikes rather than through sign-in telemetry.

UNK_OutFlareAZ was more mature and began earlier, in December 2025, operating in at least two distinct waves (a December 2025 wave peaking around 242,000 targeted users, and a February–March 2026 wave peaking around 720,000 users on March 15, 2026). It routed traffic through Cloudflare infrastructure, spoofed a User-Agent string mimicking Microsoft Outlook (`Microsoft Office/16.0 (Windows NT 10.0; Microsoft Outlook 16.0.12026; Pro`), generated a fully randomized, unique UUIDv4 client ID for every single authentication attempt (rather than reusing IDs), and enumerated usernames alphabetically using precompiled wordlists — targeting over 2 million users with 3.7 million distinct spoofed application IDs in total. The full randomization of client IDs per request meant no single fictitious application ID ever appeared more than once in logs, defeating any detection logic keyed on repeated anomalous application IDs.

Both clusters' techniques were validated and reproduced by researchers using a proof-of-concept PowerShell tool, `Invoke-ClientIdSpoofEnum`, confirming the enumeration and credential-validation behavior is trivially scriptable against any Entra ID tenant that has not disabled the legacy ROPC grant type. No CVE has been assigned; Microsoft has not classified this as a vulnerability in the traditional sense but rather as an abuse of legitimate protocol behavior (verbose, information-disclosing OAuth error responses) combined with a logging gap (spoofed/unregistered client IDs are logged with blank application-name fields instead of being rejected or flagged). The primary practical risk is silent validation of previously stolen or leaked credentials at scale — enabling attackers to triage huge stolen-credential dumps to a much smaller list of confirmed-valid username/password pairs before ever attempting an interactive sign-in, follow-on MFA fatigue attack, or session-token theft, and to do so while remaining invisible to sign-in-log-based detections and to per-application Conditional Access and rate-limiting controls.

MITRE ATT&CK techniques used in TL-2026-1342

Defense Evasion

T1036 Masquerading; T1036.005 Match Legitimate Resource Name or Location

Initial Access

T1078.004 Cloud Accounts; T1190 Exploit Public-Facing Application

Discovery

T1087.004 Cloud Account; T1201 Password Policy Discovery

Credential Access

T1110 Brute Force; T1110.001 Password Guessing; T1110.003 Password Spraying; T1110.004 Credential Stuffing

Collection

T1213 Data from Information Repositories

lateral-movement

T1550 Use Alternate Authentication Material

Resource Development

T1583.006 Web Services; T1587.001 Malware; T1588.002 Tool

Reconnaissance

T1589 Gather Victim Identity Information; T1589.001 Credentials; T1589.002 Email Addresses; T1595 Active Scanning

defense-impairment

T1685.002 Disable or Modify Cloud Log

Affected products and versions in OAuth Client ID Spoofing Enables Silent Credential

  • Microsoft — Microsoft Entra ID (Azure Active Directory)
    Vulnerable versions: Any tenant with the Resource Owner Password Credentials (ROPC) OAuth 2.0 grant type enabled
    Fixed in: No fix available; mitigated by disabling ROPC and enforcing modern auth / phishing-resistant MFA

Remediation for OAuth Client ID Spoofing Enables Silent Credential

Patches

  • No vendor patch exists; this abuses standard, documented Entra ID OAuth 2.0 error-response behavior rather than a coding defect.

Immediate actions

  • Disable the legacy Resource Owner Password Credentials (ROPC) OAuth grant type for the tenant unless a specific, inventoried application requires it.
  • Alert on and triage Entra ID sign-in log entries that contain an application ID with a blank or non-matching application name field.
  • Alert on spikes in AADSTS700016 ('application not found in directory') responses correlated with valid-credential confirmation, even absent a successful sign-in.
  • Alert on spikes in AADSTS50126 (valid username, invalid password) responses per source IP/ASN as a password-validation indicator distinct from normal failed logons.
  • Treat sudden smart-lockout spikes across many accounts as a possible client ID spoofing / password validation campaign, not routine user error.
  • Block or heavily scrutinize authentication attempts using the python-requests default User-Agent or generic scripted User-Agents against the token endpoint.

Workarounds

  • Disable ROPC grant at the tenant/application level via Conditional Access 'block legacy authentication' policies.
  • Restrict token endpoint access by network location/Conditional Access named locations where feasible.
  • Deploy a SIEM correlation rule joining AADSTS50034/50126/700016 events by source IP and time window to surface enumeration sweeps that never appear as successful sign-ins.

Longer-term hardening

  • Enforce phishing-resistant MFA (FIDO2/passkeys, certificate-based auth) tenant-wide so validated password pairs alone are insufficient for account takeover.
  • Migrate all legacy/basic-auth and ROPC-dependent applications to modern auth flows (Authorization Code with PKCE) that do not accept raw credentials.
  • Deploy Conditional Access policies that key on user risk and sign-in risk (Identity Protection) rather than solely on application identity, since spoofed-app traffic bypasses per-application scoping.
  • Enable and monitor Entra ID Identity Protection 'anomalous token' and 'leaked credentials' risk detections tenant-wide.
  • Rotate credentials for any accounts flagged by AADSTS700016/50126 correlation as password-validated during the active campaign windows (Dec 2025–Mar 2026).

Weaknesses (CWE) in OAuth Client ID Spoofing Enables Silent Credential

CWE-203, CWE-307, CWE-799

Timeline of OAuth Client ID Spoofing Enables Silent Credential

  • UNK_OutFlareAZ campaign begins, using Cloudflare infrastructure and a spoofed Microsoft Outlook User-Agent to enumerate Entra ID accounts via spoofed OAuth client IDs.
  • UNK_OutFlareAZ's first wave peaks at approximately 242,000 targeted users.
  • UNK_pyreq2323 campaign begins, using AWS infrastructure and the python-requests library to spoof Exchange Online first-party application IDs.
  • UNK_pyreq2323 activity peaks in late January/early February 2026, generating the bulk of its 700,000+ spoofed client IDs.
  • UNK_pyreq2323 campaign winds down in early March 2026 after targeting over 1 million accounts across roughly 4,000 tenants.
  • UNK_OutFlareAZ's second wave peaks at approximately 720,000 targeted users in a single day.
  • UNK_OutFlareAZ campaign concludes after targeting over 2 million users with 3.7 million spoofed application IDs total.
  • Proofpoint publishes threat research disclosing both campaigns and the underlying OAuth client ID spoofing technique.
  • The Hacker News, Help Net Security, Infosecurity Magazine, Cybersecurity Dive, and other outlets syndicate coverage of the disclosure.

Sources cited for OAuth Client ID Spoofing Enables Silent Credential

Threats related to OAuth Client ID Spoofing Enables Silent Credential

Detection coverage for TL-2026-1342

As of 2026-07-14, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-1342 across Splunk SPL, Microsoft KQL and Sigma, covering 15 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.

Threadlinqs Intelligence — Real-Time Threat Detection Platform

[ 0 threats ] [ 0 det ] [ CRIT: 0 ] [ HIGH: 0 ]
// threat_feed
$ sort --newest
Showing all threats

Latest Threats