2026-07-15 · view entry permalink →
Proofpoint: OAuth client ID spoofing validates stolen Entra ID credentials at scale without writing a successful sign-in log
Proofpoint's Threat Research team documented a stealthy authentication-evasion technique — OAuth client ID spoofing — being independently weaponised by two distinct clusters against Microsoft Entra ID (Proofpoint, 2026-07-13). The mechanism abuses the legacy Resource Owner Password Credentials (ROPC) flow: an attacker POSTs a username and password to Entra ID's /common/oauth2/token endpoint while supplying an arbitrary, unregistered GUID as the client_id parameter instead of a real application ID. Entra ID's differential error responses then leak validity regardless of whether the client_id is legitimate — AADSTS50034 for a non-existent username, AADSTS50126 for a valid username with the wrong password, and, critically, AADSTS700016 ("application not found in directory") when the username and password are both correct, because Entra ID validates the credential before it fails on the unrecognised client. The result is a credential-validity oracle that most defenders misread: AADSTS700016 is ordinarily dismissed as a harmless misconfigured-app error, which is precisely the blind spot both clusters exploited (Help Net Security, 2026-07-13).
The evasion value is in the telemetry: none of these code paths writes a successful sign-in event, and because the client_id is unregistered, the sign-in log entry carries no application name at all — "detections that look for surges against a specific application name may miss this activity entirely, as the field is blank" (Proofpoint, 2026-07-13). Proofpoint attributes two campaigns of opportunistic mass enumeration: UNK_pyreq2323 (January–March 2026, AWS-hosted, 700,000+ distinct spoofed client IDs) and UNK_OutFlareAZ (December 2025–March 2026, Cloudflare-fronted, 3.7M distinct spoofed IDs), whose divergent tooling and client-ID-generation strategies point to parallel invention rather than shared code (The Hacker News, 2026-07-13).
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.
By fragmenting authentication attempts across many fictional applications, activity becomes harder to correlate and may evade per-application detections and rate limiting.