Entra ID Blind Spot: OAuth Client ID Spoofing Explained

There is a quiet gap in Microsoft Entra ID sign-in telemetry, and at least two separate groups have worked out how to walk through it. Proofpoint researchers are calling the technique OAuth client ID spoofing, and it lets attackers verify stolen credentials and enumerate valid accounts without ever generating the successful sign-in event that defenders lean on.

The gap in the token endpoint

Every legitimate application authenticating against Entra passes a client_id, a unique identifier tying the request back to a registered app. Entra, it turns out, returns subtly different error messages depending on whether that client ID is valid, whether the username exists, and whether the password is correct. Send in a syntactically valid but entirely fictional client ID, read the AADSTS error code that comes back, and you can quietly work out which credentials in your dump are live.

Because the spoofed application does not actually exist, the sign-in log records an application ID with no corresponding application name. That has knock-on effects across the defensive stack:

• Detections tuned to spikes against a known application see nothing unusual.
• Conditional Access policies scoped to specific applications never fire.
• Per-app rate limiting is largely meaningless when every request pretends to come from a different fictional client.

Two campaigns, same idea

Proofpoint tracked two clusters that independently adopted the approach at the end of December 2025. UNK_pyreq2323 tweaked the trailing digits of a real application ID and reused each spoofed ID across up to a dozen users. UNK_OutFlareAZ generated a fresh client ID for every request and worked through target usernames alphabetically. Both leaned on precompiled wordlists, and the fact that two unrelated groups landed on the same trick within weeks of each other suggests it is graduating from novelty to standard tradecraft.

This follows earlier activity from UNK_CustomCloak, which abused a discontinued first-party Microsoft app to probe more than 4,000 tenants. The through-line is that attackers are getting more comfortable poking at the identity layer itself, not just the accounts hanging off it.

What defenders can actually do

The uncomfortable takeaway is that sign-in logs are not the full picture. A password-spraying campaign can run against your tenant, confirm which accounts exist, and quietly filter its credential list, all without ever succeeding at a login you would notice.

A few practical adjustments:

• Alert on authentication attempts where the application name field is blank. Legitimate apps have a resolvable name.
• Watch for high volumes of unique or near-duplicate client IDs hitting the token endpoint from the same source.
• Assume any credential list circulating on the open web has already been test-driven against your tenant, and prioritise resets and step-up authentication accordingly.

The broader point is that identity providers are becoming an interesting target in their own right. When the reconnaissance step is this quiet, the useful signal is usually somewhere the attackers assumed nobody was looking.