Executive Summary
Proofpoint's July 2026 research documents a useful change in cloud identity reconnaissance: attackers are no longer obliged to concentrate authentication attempts on a small set of recognizable first-party application IDs. They can submit valid-looking but nonexistent OAuth client IDs, creating the appearance of activity spread across hundreds of thousands or millions of applications.
The technique does not make the authentication request legitimate. It changes the grouping key defenders are tempted to trust. If a SOC summarizes failures by application, sets thresholds per app, or scopes Conditional Access analysis only to familiar client IDs, a single campaign can dissolve into a long tail of apparently unrelated events.
AttackAttack Overview
Proofpoint tracked two distinct campaigns. UNK_pyreq2323 appeared in January 2026, originated from AWS infrastructure, and distributed requests across more than 700,000 spoofed client IDs while targeting over one million accounts in nearly 4,000 tenants. The campaign reused an Exchange Online-style prefix with randomized trailing digits and caused lockouts for roughly 28 percent of targeted users.
UNK_OutFlareAZ operated at still larger scale. Proofpoint reported more than two million targeted users and 3.7 million spoofed application IDs. Instead of modifying one recognizable prefix, the operator generated a unique UUIDv4 client ID for each attempt. The campaigns differed in infrastructure, user agent, ordering, and ID generation, which argues for independent adoption of the same idea rather than one monolithic tool.
Enumeration is the immediate goal, but the security meaning is larger. An AADSTS700016 result normally says the specified application was not found in the tenant. In the observed flow, the response can still help an unauthenticated operator distinguish account and password states without producing a successful sign-in. A failure record can therefore be evidence that the actor learned something valuable.
DetectionDetection Opportunities
Start with fields that should agree but do not. Alert on user authentication events where a client or application ID is present but no application name or corresponding service principal can be resolved. Treat bursts of AADSTS700016 as a hunting lead, especially when the same source, autonomous-system neighborhood, user agent, or username pattern spans many client IDs.
Measure cardinality in both directions. Useful ratios include unique client IDs per source IP, unique client IDs per user agent, users per client ID, and tenants or user principals touched per source cluster. The two observed operators deliberately chose different reuse patterns, so a rule that requires one client ID to hit many users would miss the more mature one-ID-per-attempt variant.
Join the identity stream to lockout, password-reset, risky-user, and later successful-authentication data. The absence of a successful event during enumeration is not reassurance. A later login from a new network, device, protocol, or application may be the operational payoff from credentials validated during an earlier failure-only sequence.
ValidationValidation Workflow
Use historical sign-in data to establish a baseline for unresolved application IDs and AADSTS700016 by tenant, source ASN, user agent, and hour. Separate known deployment mistakes and abandoned internal applications from high-cardinality behavior. Then replay the detection against a synthetic dataset with three cases: one invalid internal app repeatedly hitting a test user, one source rotating client IDs across many users, and many sources each using a unique client ID against a shared username list.
A useful validation result should promote the latter two without turning every development typo into an incident. Verify that application-name enrichment failures remain searchable rather than being dropped during normalization. Finally, confirm the investigation view preserves raw client ID, error code, IP, user agent, user principal, correlation ID, and timestamp.
GapsEvasion & Gaps
Cloud identity telemetry can make application labels feel authoritative even when the application does not exist. Normalization pipelines may replace missing names with generic values, discard failed attempts, aggregate away individual identifiers, or retain less history than the campaign's slowest operating window. NAT, common cloud infrastructure, and familiar user agents also make source-only blocking brittle.
Conditional Access is essential but is not a substitute for this detection. A policy scoped to applications commonly abused for enumeration cannot match a fictional client ID in the same way. The defensive unit needs to be the authentication behavior across the tenant, not only the named app in a single record.
Defensive Recommendations
Retain and centrally query failed user authentication events. Add explicit fields for application-resolution status and whether the client ID maps to a service principal in the tenant. Correlate high client-ID cardinality with error codes, lockouts, password activity, and subsequent successful access.
Require phishing-resistant MFA for privileged and high-impact workflows, reduce password-only and legacy authentication paths, and make validated-credential exposure a reason to rotate credentials even when no successful attacker login is visible. Most importantly, teach analysts that some authentication failures describe successful reconnaissance.