At least two distinct threat actor groups are weaponizing a novel evasion technique dubbed **OAuth client ID spoofing** in their cloud campaigns, effectively slipping past traditional telemetry. This activity enables them to enumerate user accounts and validate stolen credentials in **Microsoft Entra ID** environments without generating a successful sign-in event that would otherwise alert defenders. "A blind spot in cloud sign-in telemetry: Entra ID returns different error responses depending on whether a supplied OAuth client ID is valid," **Proofpoint** stated. "Attackers exploit this to infer valid usernames and correct passwords at scale, effectively checking stolen credential lists without logging a successful login."  ### How OAuth Client ID Spoofing Works The attacks exploit the **OAuth client ID**, a globally unique identifier (GUID) assigned to applications requesting access to user data. This ID is passed as `client_id` in authentication requests. By providing spoofed client IDs, attackers can enumerate accounts without a registered OAuth application and infer both password and account validity without generating a successful sign-in event. **Proofpoint** researcher **Rachel Rabin** highlighted the issue: "The Entra sign-in logs are a primary telemetry source for identifying malicious authentication activity, including user enumeration, password spraying, and initial access attempts." This new method evolves previous brute-force campaigns that spoofed User-Agent strings to target **Microsoft Entra ID** environments, often by exploiting legacy applications like **Windows Live Custom Domains** to bypass sign-in restrictions. The current tactic involves spoofing OAuth client IDs via HTTP POST requests to Microsoft's OAuth 2.0 token endpoint using the **Resource Owner Password Credentials (ROPC)** flow. Specifically, attackers supply a syntactically valid client ID that does not correspond to a real application. In such cases, only the application ID is recorded in the Entra sign-in log, without a corresponding application name. The response, containing an **Azure Active Directory Security Token Service (AADSTS)** error code, can then be used to infer whether the account exists and if the password is correct, all without a registered application. "If the spoofed client ID is not a proper UUIDv4, Entra does not reject the request outright," **Proofpoint** explained. "Attackers can therefore analyze this error response to identify valid accounts and passwords, despite using malformed client IDs." Crucially, when a spoofed client ID is used, no application name is recorded in the sign-in log. This renders detections that look for surges against specific application names ineffective, as the field remains blank. ### Observed Campaigns **Proofpoint** has identified two significant campaigns that independently adopted this technique towards the end of December 2025, indicating its growing popularity within attacker tradecraft: * **UNK_pyreq2323**: Active from January to March 2026, this campaign used over 700,000 spoofed client IDs from **Amazon Web Services (AWS)** infrastructure. It targeted more than 1 million accounts across nearly 4,000 tenants, leading to lockouts for approximately 28% of targeted users due to failed attempts. * **UNK_OutFlareAZ**: Starting in December 2025, this campaign leveraged **Cloudflare** infrastructure to target over 2 million users with 3.7 million randomized spoofed application IDs. Both campaigns utilized valid UUIDs rather than malformed identifiers and exhibited patterns consistent with precompiled username wordlists. While **UNK_OutFlareAZ** enumerated users alphabetically, **UNK_pyreq2323** did not. Their methods for spoofing client IDs also differed: **UNK_pyreq2323** modified trailing digits of known application IDs and reused spoofed IDs across multiple users, whereas **UNK_OutFlareAZ** generated a unique client ID per request. ### Mitigation Challenges "By fragmenting authentication attempts across many fictional applications, activity becomes harder to correlate and may evade per-application detections and rate limiting," **Proofpoint** noted. Organizations attempting to mitigate traditional enumeration attacks with Conditional Access policies scoped to commonly targeted applications will find these ineffective against spoofed client IDs. While the current findings are specific to **Microsoft**, **Yaniv Miron**, director of threat research at **Proofpoint**, suggested that "other identity providers are possibly exposed to such issues." He added, "Spoofing in general has been a well-known method for years; adversaries will attempt to spoof anything that they can (different fields usually), including client ID. Adversaries are constantly monitoring threat researchers' blogs and publications, so we believe that they are adopting public research into their attacks." This development underscores the continuous evolution of attacker techniques and the need for robust, adaptive security measures to protect cloud environments.