At least two threat actors have reportedly used OAuth client ID spoofing to enumerate Microsoft Entra accounts and check whether stolen credentials are still valid, while avoiding parts of the telemetry defenders expect to see.
Why identity teams should care
The practical lesson is that attackers are learning how to make hostile authentication activity resemble traffic from a legitimate application.
That has a direct consequence for detection engineering. Rules keyed to application names or individual client IDs are unreliable against this, because the attempts are spread across fictional applications rather than concentrated in one. If your alerting treats the client ID as a trustworthy signal, it is treating something the attacker controls as evidence.
A client ID is an assertion by the caller, not a fact established by your tenant.
What to check
Do any detections allow-list by application name or client ID? Those are the rules this technique is designed to walk past.
Can you see credential-validation attempts that fail quietly? Enumeration and credential testing are noisy in aggregate and invisible per-event.
Are you alerting on the shape of the traffic rather than its labels? Volume, timing, source diversity and failure ratios survive spoofing. Names do not.
Worth noting alongside this: the OpenID Connect Key Binding specification currently in implementer's draft review addresses the adjacent problem of a valid token being replayed away from the key it was issued against.
Source
OAuth client ID spoofing lets attackers test stolen credentials, The Hacker News