# OAuth Client ID Spoofing: Attackers Bypass Microsoft Entra ID Telemetry to Validate Stolen Credentials


Two distinct threat actor groups are exploiting a novel evasion technique called OAuth client ID spoofing to enumerate user accounts and validate stolen credentials in Microsoft Entra ID environments—all while remaining invisible to standard security telemetry. The attacks, identified by security researchers at Proofpoint, represent a significant evolution in cloud-focused credential validation tradecraft and expose a blind spot in how Entra ID logs authentication attempts.


## The Threat: Invisible Credential Validation at Scale


Since late December 2025, attackers have weaponized OAuth client ID spoofing in two large-scale campaigns targeting thousands of organizations. The technique exploits a fundamental discrepancy in how Microsoft Entra ID responds to authentication requests using invalid but syntactically valid OAuth client IDs—a gap that allows attackers to infer account existence and password validity without ever generating a successful sign-in event.


The two campaigns identified by Proofpoint demonstrate the broad adoption of this technique:


  • UNK_pyreq2323 (January–March 2026): Deployed over 700,000 spoofed client IDs from Amazon Web Services infrastructure to target more than 1 million user accounts across nearly 4,000 tenants. The campaign resulted in account lockouts for roughly 28% of targeted users due to the volume of failed authentication attempts.
  • UNK_OutFlareAZ (December 2025 onwards): Leveraged Cloudflare infrastructure to target over 2 million user accounts, indicating broader geographic and infrastructural distribution of the attack.

    • The fact that two independent threat actors have adopted this technique within weeks of its emergence suggests it is no longer an isolated exploit but an increasingly mainstream element of attacker tradecraft.


    ## Background and Context: Entra ID Authentication and Prior Campaigns


    Microsoft Entra ID (formerly Azure Active Directory) is the identity and access management service at the heart of enterprise cloud infrastructure for hundreds of thousands of organizations. Authentication logs and sign-in telemetry are the primary defense mechanisms for detecting unauthorized access attempts, credential spray campaigns, and user enumeration attacks.


    Prior to this discovery, Proofpoint researchers documented the activities of threat cluster UNK_CustomCloak, which conducted brute-force campaigns by spoofing User-Agent strings and exploiting a discontinued first-party Microsoft application called Windows Live Custom Domains. That campaign successfully bypassed standard sign-in restrictions and probed user passwords across over 4,000 tenants. The latest OAuth client ID spoofing technique represents a tactical refinement that achieves similar goals—credential validation and account enumeration—but with dramatically reduced detection risk.


    The gap exploited by OAuth client ID spoofing stems from how Entra ID's authentication flow handles invalid client identifiers. Unlike legitimate applications registered in an organization's Entra ID tenant, spoofed client IDs bypass validation while still triggering authentication responses that reveal sensitive information about user accounts.


    ## Technical Details: How OAuth Client ID Spoofing Works


    The attack methodology leverages the OAuth 2.0 Resource Owner Password Credentials (ROPC) flow, a legacy authentication method that allows applications to exchange a username and password directly for an access token. Attackers perform the following steps:


    1. Crafting Spoofed Client IDs

    Attackers create syntactically valid Globally Unique Identifiers (GUIDs) that mimic legitimate OAuth client IDs but do not correspond to any registered application in a target tenant. Critically, if the client ID is not a proper UUIDv4 format, Entra ID does not reject the request outright—it processes it and returns an error response.


    2. Authentication Requests via ROPC Flow

    The attacker sends HTTP POST requests to Microsoft's OAuth 2.0 token endpoint (https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token) using the ROPC flow, supplying:

  • A target username
  • A candidate password
  • A spoofed (but syntactically valid) client ID

    • 3. Error Response Analysis

    Entra ID returns different AADSTS (Azure Active Directory Security Token Service) error codes depending on whether:

  • The account exists (specific error code)
  • The password is correct (different error code)
  • Both are invalid (yet another error code)

    • By analyzing these error responses, attackers can:

  • Enumerate valid usernames
  • Validate correct passwords from a breached credential list
  • Identify accounts vulnerable to compromise

    • 4. Telemetry Evasion

    When a spoofed client ID is used, the sign-in log records only the application ID—not a corresponding application name. Detection systems that look for surges against a specific application name miss the activity entirely, as the field remains blank. Additionally, because the attack validates passwords *without* generating a successful sign-in event, the attack leaves no record of successful authentication. This means standard indicators of compromise (successful logins, unusual access patterns) never appear in telemetry.


    | Aspect | Impact |

    |--------|--------|

    | Detection Method | Analyzes AADSTS error responses from invalid OAuth client IDs |

    | Telemetry Visibility | Application name field is blank; no successful sign-in event |

    | Scale | 700,000+ spoofed client IDs in one campaign; 1M+ accounts targeted |

    | Infrastructure | AWS and Cloudflare used for distribution and anonymization |

    | Success Rate | ~28% account lockout rate in UNK_pyreq2323 campaign (indicates high attempt volumes) |


    ## Implications: A New Blind Spot in Cloud Security


    This attack technique exposes three critical security gaps:


    Logging Blindness

    Security teams rely on Entra ID sign-in logs as the primary telemetry source for detecting malicious authentication activity. The blank application name field in spoofed OAuth client ID attacks means these logs provide incomplete context. Detections tuned to look for patterns like "repeated failed logins against Application X" will miss spoofed client ID attacks entirely.


    Credential Validation Without Detection

    Attackers can now validate stolen credentials at massive scale without triggering the alerts that traditional brute-force and password spray campaigns generate. An attacker with a list of 10 million compromised credentials can test them against a target tenant and identify which accounts are valid and which passwords are correct—all without a single alert firing.


    Account Enumeration Without Boundaries

    Unlike legitimate account enumeration techniques (which often generate distinctive error patterns), the AADSTS error response differentiation allows granular inference of account validity. An attacker can build a map of all valid accounts in a target organization without triggering rate-limiting or account lockout protections initially.


    The downstream impact is severe: once attackers identify a valid account with a correct password, they can move directly to lateral movement, privilege escalation, or data exfiltration—bypassing the initial detection window that organizations typically rely on.


    ## Recommendations: Detection and Mitigation


    For Cloud Security Teams:


  • Log aggregation and parsing: Parse Entra ID sign-in logs specifically for blank application name fields combined with AADSTS error codes. This combination is strongly indicative of OAuth client ID spoofing.
  • Rate limiting on ROPC flow: Restrict or disable the ROPC flow entirely if not actively used in your tenant; this eliminates one vector for abuse.
  • Monitor AADSTS error patterns: Implement alerting on abnormal concentrations of specific AADSTS error codes (particularly those indicative of account validation attempts) within short time windows.
  • Implement conditional access policies: Restrict legacy authentication protocols and require multi-factor authentication for sensitive accounts.

    • For Organizations:


  • Audit active OAuth applications: Conduct a comprehensive inventory of all registered OAuth applications in Entra ID. Remove any that are no longer in use, particularly legacy or first-party applications.
  • Enable sign-in risk policies: Configure Entra ID's identity protection to detect and respond to anomalous sign-in patterns, even when telemetry is incomplete.
  • Review credential exposure: If your organization was targeted in either of the identified campaigns (check for anomalous login attempts from AWS or Cloudflare IP ranges), assume credentials may be compromised. Conduct a password audit and enforce resets for high-risk accounts.
  • Prioritize MFA enforcement: Multi-factor authentication is the single most effective defense against credential-based attacks, including those that bypass sign-in telemetry.

    • ---


    ## HackWire Analysis


    This vulnerability represents a troubling evolution in how attackers think about cloud authentication. For years, the security industry has treated Entra ID sign-in logs as a reliable source of truth—the authoritative record of who tried to access what, and when. OAuth client ID spoofing shatters that assumption.


    What makes this particularly dangerous is the *calibrated* exploitation of error responses. The attackers didn't need to find a zero-day vulnerability or break Microsoft's cryptography. They simply reverse-engineered the intentional design of Entra ID's error handling—the fact that the service provides *different* error codes for different failure modes is a feature meant to help developers debug legitimate authentication problems. Attackers have weaponized that diagnostic transparency.


    The 28% account lockout rate in the UNK_pyreq2323 campaign deserves scrutiny. This suggests that in organizations with standard lockout policies (typically 5-10 failed attempts), attackers are *successfully* distributing enough requests across enough IP addresses and client IDs to test hundreds or thousands of password candidates per account without tripping lockout protection. This is not a theoretical attack—it's working at massive scale.


    The timeline is also significant. The technique emerged in late December 2025 and was independently adopted by at least two threat actors within weeks. This speed suggests the technique is either being shared in underground forums or reverse-engineered so readily that attackers don't need detailed instructions. Either way, organizations should expect this to proliferate.


    The most consequential gap here is *temporal*: attackers can now validate credentials invisibly, then wait days or weeks before attempting actual compromise using those credentials. By the time an attacker logs in successfully, the initial reconnaissance pass—which might have appeared as a noisy, obvious attack—is long forgotten in the log files. This compressed detection window is what makes the technique so operationally valuable to threat actors.


    — HackWire Editorial


    ---


    ## Related Coverage


  • Read more in our [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) coverage
  • Cross-reference with [Breaches](https://www.hackwire.news/category/breaches) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)