Topic starter
14/07/2026 5:23 pm
TL;DR: Multiple cloud campaigns abused OAuth client ID spoofing to enumerate accounts and infer password validity in Microsoft Entra ID without generating a successful sign-in event; one campaign targeted more than one million accounts across nearly 4,000 tenants and another exceeded 2 million users, according to Proofpoint. The finding shows that application-name based detection is no longer enough when identity telemetry can be deliberately shaped.
Editorial analysis by NHI Mgmt Group, based on content published by Proofpoint: “OAuth Client ID Spoofing: Why Fake Client IDs Are Gaining Traction for Stealthy Enumeration”.
By the numbers:
- The campaign tracked as UNK_pyreq2323 targeted over one million unique user accounts across nearly 4,000 tenants.
- High-volume failed attempts triggered account lockouts for approximately 28% of targeted users.
Key questions
Q: What breaks when attackers spoof OAuth client IDs in Entra ID?
A: The main failure is that application-scoped detections lose a reliable label to key on, while Entra ID can still return responses that reveal whether a username exists or a password is valid.
Q: Why do spoofed client IDs increase the risk of account enumeration?
A: They let attackers probe authentication outcomes without creating a conventional successful sign-in event, so the platform's error handling becomes an oracle for account state.
Q: What are the signs that OAuth client ID spoofing is happening?
A: Look for sign-in attempts with blank application names, inconsistent application IDs, repeated AADSTS error codes, and user-agent patterns that recur across many usernames or tenants.
Practitioner guidance
- Inspect sign-in events with blank application names Search Entra ID logs for authentication attempts where the application ID is present but the application name is missing, then correlate those events with username validity probes and repeated AADSTS errors.
- Correlate AADSTS codes across client IDs Group failed sign-in attempts by source IP, user agent, username pattern, and AADSTS response so that spoofed application identifiers do not fragment the investigation into separate low-signal alerts.
- Review Conditional Access scope assumptions Check whether policies rely on known application objects in ways that can be bypassed when the client_id does not map to a registered app in the tenant.
Bottom line: OAuth client ID spoofing turns Entra ID authentication metadata into an attacker-controlled signal that can expose account validity without a successful sign-in event.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
14/07/2026 5:26 pm
OAuth client ID spoofing is a telemetry manipulation problem before it is an authentication problem. The attack works because defenders often trust the application name field as a stable correlate of intent, but the platform can be made to return useful authentication state even when that field is absent. That breaks a common monitoring assumption in Entra ID operations. Practitioners should stop treating application labels as authoritative evidence of legitimacy.
A few things that frame the scale:
- Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
A question worth separating out:
Q: How should teams detect spoofed OAuth activity without relying on application names?
A: Use a combination of client ID anomalies, AADSTS response patterns, IP and user-agent clustering, and username enumeration patterns to reconstruct the campaign. The goal is to detect authentication abuse from the behaviour of the request, not from a supposedly stable app label.
👉 Read our full editorial: OAuth client ID spoofing exposes a cloud identity blind spot