"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 said in a statement.
How attackers spoof OAuth client IDs to probe accounts
Attackers are abusing the OAuth "client_id" field — a globally unique identifier assigned to applications — to enumerate user accounts and validate stolen credentials in Microsoft Entra ID environments without producing a successful sign‑in event. According to Proofpoint, adversaries submit HTTP POST requests to Microsoft's OAuth 2.0 token endpoint using the Resource Owner Password Credentials (ROPC) flow while supplying syntactically valid client IDs that do not map to real applications. The responses return Azure Active Directory Security Token Service (AADSTS) error codes that let attackers infer whether an account exists and whether a supplied password is correct.
Proofpoint researchers note two variants of the approach. In some cases attackers supply valid UUIDs that simply are not registered to any application; in others they submit malformed client IDs (not proper UUIDv4). Entra does not always reject malformed identifiers outright, and the differing error responses give the adversary the information they seek without generating a successful login entry in sign‑in telemetry.
Campaigns observed: UNK_pyreq2323 and UNK_OutFlareAZ
Proofpoint has identified at least two large campaigns that adopted OAuth client ID spoofing. UNK_pyreq2323, active from January to March 2026, used infrastructure in Amazon Web Services and more than 700,000 spoofed client IDs to target more than 1 million accounts across nearly 4,000 tenants. Those attempts caused lockouts for roughly 28% of the users targeted, Proofpoint said.
UNK_OutFlareAZ, first observed in December 2025, leveraged Cloudflare infrastructure and targeted over 2 million users with 3.7 million randomized spoofed application IDs. Unlike UNK_pyreq2323, which modified the trailing digits of a known application ID and reused spoofed IDs across up to 12 users, UNK_OutFlareAZ generated a unique client ID per request. UNK_OutFlareAZ also enumerated users alphabetically; UNK_pyreq2323 did not follow that pattern.
Why Entra sign‑in logs can miss this activity
When a spoofed client ID is used, Entra sign‑in logs record the application ID but often leave the application name blank because no corresponding registered application exists. "The Entra sign‑in logs are a primary telemetry source for identifying malicious authentication activity," Proofpoint researcher Rachel Rabin said, calling out user enumeration, password spraying, and initial access attempts specifically. Because the application name field is empty, detections that look for surges tied to a specific application name may fail to surface this activity.
Proofpoint also explains that defenders who rely on Conditional Access (CA) policies scoped to particular applications can be bypassed by this technique. "Spoofed client IDs won't trigger CA policies that are scoped to a specific application," the company said, and by fragmenting authentication attempts across many fictional applications attackers make their activity harder to correlate and may evade per-application rate limiting.
Context: evolution from User‑Agent spoofing to client‑ID fragmentation
The client ID tactic represents an evolution of prior tradecraft. Proofpoint previously observed threat clusters such as UNK_CustomCloak spoofing User‑Agent strings to mount brute‑force and password‑probing campaigns against Microsoft Entra ID environments by abusing a discontinued first‑party application, Windows Live Custom Domains, to bypass sign‑in restrictions. The new technique shifts the evasion point to the client identifier itself and leverages differences in AADSTS error responses to perform "blind" credential validation at scale.
Proofpoint highlighted operational differences between the campaigns: UNK_pyreq2323 reused variations of a known application ID across multiple users, while UNK_OutFlareAZ generated a unique fictional application per request. Both patterns fragment authentication attempts in ways that complicate detection and forensic correlation.
What this means for security teams, cloud administrators, and end users
- Security teams and cloud administrators: Review authentication telemetry that includes application IDs, not only application names, and consider monitoring for large volumes of failed token requests that carry valid‑looking but unregistered client IDs. Be aware that Conditional Access policies scoped to specific applications may not block these requests.
- Procurement and platform owners: Expect threat actors to incorporate client‑ID spoofing into routine credential‑validation toolkits. Policies or tooling that rely exclusively on per‑application controls will need reassessment if they assume the client_id field reliably maps to registered applications.
- End users: Campaigns using this technique have caused account lockouts — Proofpoint reported roughly 28% lockouts among UNK_pyreq2323's targets — meaning users may see increased friction if attackers test large credential lists against tenant accounts.
The technique exploits a specific telemetry gap: variance in AADSTS error responses depending on client_id validity combined with how Entra logs application metadata. Proofpoint's findings — including the scale of the two campaigns and the operational differences between them — show the method has moved from isolated misuse into repeated attacker tradecraft. For defenders, the record is clear: look beyond application names, track anomalous client IDs, and adjust detection and access controls to account for fictional or malformed client identifiers.
Source: https://thehackernews.com/2026/07/oauth-client-id-spoofing-lets-attackers.html
