The Entra sign‑in logs are a primary telemetry source security teams use to identify malicious authentication activity, including user enumeration, password spraying, and initial access attempts. To evade detection, attackers routinely distribute requests using rotating user agents and proxy services that cycle source IPs per request.
Proofpoint researchers have identified multiple campaigns in which attackers extend this evasive tradecraft by spoofing the OAuth client ID (application ID), the unique identifier assigned to each application. The identifier is included in authentication requests and recorded as the application ID in Entra sign-in logs.
Spoofed client IDs enable account enumeration without a registered OAuth application and allow attackers to infer both password and account validity without generating a successful sign-in event.
The technique matters for the region because credential theft is already the dominant entry point. The UAE Cybersecurity Council reports that more than 75% of cyber breaches in the country begin with phishing or fraudulent messages, making stolen or guessed credentials the most common way attackers get in. A method that quietly confirms which accounts exist and which passwords work, without generating a successful sign-in, feeds straight into that same entry point.
When a spoofed client ID is used, no corresponding application name is recorded in the sign-in log. This means that detections that look for surges against a specific application name may miss this activity entirely, as the field is blank.
Proofpoint’s threat research team observed that logging behaviour allows unauthenticated attackers to enumerate users and infer password validity without generating a successful sign-in event. Even when this activity is detected, defenders may not realize that valid credentials were identified and may overlook compromised credentials entirely.
Traditional enumeration tools target built-in first-party applications, commonly command-line (CLI) tools like Azure AD PowerShell, that exist in all tenants and have historically been a gap for MFA enforcement. However, surges in authentication requests to a single application quickly raise alarms for security operations centre teams. By fragmenting authentication attempts across many fictional applications, activity becomes harder to correlate and may evade per-application detections and rate limiting.
Organisations may attempt to mitigate traditional enumeration attacks by applying Conditional Access (CA) policies scoped to applications commonly targeted for enumeration. Spoofed client IDs won’t trigger CA policies that are scoped to a specific application.
Proofpoint has already observed this technique in active campaigns. The first one, tracked as UNK_pyreq2323, initially emerged on January 14, 2026. The attacker distributed enumeration attempts across more than 700,000 spoofed client IDs.
Activity peaked in late January and early February before declining by early March. The campaign originated from AWS infrastructure and targeted over one million unique user accounts across nearly 4,000 tenants. This high volume of failed attempts triggered account lockouts for approximately 28% of targeted users.
A second campaign shows the same method on a greater scale. Beginning in December 2025, Proofpoint researchers observed a large-scale enumeration campaign tracked as UNK_OutFlareAZ originating primarily from Cloudflare infrastructure. The activity used the same client ID spoofing technique, but operated at a greater scale, targeting more than 2 million users and 3.7 million spoofed application IDs.
Proofpoint has consistently observed this user agent over several years across multiple discovery campaigns, where it has been widely propagated through attacker tooling.
The campaign occurred in two distinct waves: the first ramped up from December 10 and peaked in late December (~242K users), while a second, larger wave began in early February, escalated through March, and peaked on March 15 (~720K users).
A notable portion of usernames appeared across multiple tenants, following generic naming conventions like dsmith, msmith, and jbrown. Because Entra ID only records attempts against valid accounts, this pattern suggests attackers reused a common wordlist of generic usernames across many organisations.
While both campaigns leveraged OAuth client ID spoofing for user enumeration, differences in user agents, infrastructure, client ID generation, and enumeration patterns suggest they were conducted by distinct tools or operators.
The client ID spoofing methods also differed: UNK_pyreq2323 modified the trailing digits of a known application ID, reusing spoofed IDs across up to 12 users, while UNK_OutFlareAZ generated a unique client ID per request and enumerated users alphabetically, a more sophisticated approach that limits correlation.
These variations point to independent adoption of the same underlying technique, reinforcing Proofpoint’s assessment that OAuth client ID spoofing is becoming increasingly common tradecraft among threat actors.
OAuth client ID spoofing enables attackers to enumerate accounts and validate credentials at scale, without generating a successful sign-in event in Entra ID logs. The emergence of multiple campaigns with unique tools and infrastructure suggests this technique is gaining traction among threat actors targeting cloud environments.
Beyond evading sign-in telemetry, spoofed client IDs offer additional advantages such as distributing attacks across apparent applications and potentially evading downstream detections that rely on the application name field being populated.
Security teams should treat sign-in log entries with blank application IDs, or those without a corresponding application name, as potential indicators of client ID spoofing, and recognise that some authentication errors may signal compromised credentials, not just a failed login attempt.
Image Credit: Proofpoint
Source: Tahawul Tech