Stop Chasing Events: Your OAuth Alerts Are Lying

The Conventional Wisdom

Your SIEM is firing alerts: failed sign-ins, unrecognized client IDs. Your team triages them one by one, checking if each event crosses a threshold. Five failed attempts? Investigate. Ten? Escalate. This event-by-event approach feels thorough. You're catching anomalies. You're doing detection "right."

Except you're not. You're watching individual trees while attackers burn down the forest.

The Flaw in Event-Based Detection

Single-event detection logic assumes attackers play by your rules. They don't. Modern OAuth client ID spoofing campaigns operate at a scale that exploits your event-focused mindset. When a threat actor generates 3.7 million spoofed client IDs against over two million accounts, no individual event looks suspicious. Each failed authentication attempt appears as routine noise, just another misconfigured app or user typo.

The problem isn't your detection rules. It's that they're asking the wrong question. "Did this event exceed a threshold?" misses what actually matters: "How many unique patterns am I seeing across time?"

Since December 2025, at least two threat actors have been running enumeration campaigns that your current detection stack probably can't see. One campaign hit a 28 percent lockout rate across a million-user organization. Your alerts fired. Your team investigated individual events. The attack continued.

The Evidence of Failure

Research into these spoofing campaigns reveals why event-based detection fails here. Attackers using fabricated or rotating client IDs don't trigger traditional volume thresholds because they distribute their attempts. Instead of hammering one account with 100 failed logins, they touch 100 accounts with one or two attempts each. Your SIEM sees configuration noise. The attacker sees password spray success.

The detection gap lives in cardinality, not volume. You need to track: How many distinct client IDs attempted authentication in the last hour? How many of those IDs have never been seen before? What's the ratio of new-to-known IDs over a rolling seven-day window?

Microsoft Entra ID logs capture the data you need, but most detection rules don't correlate it. Your team reviews individual sign-in failures. You don't have a dashboard showing client ID diversity over time. When 500 unique client IDs appear in an hour (versus your normal baseline of 12), nobody notices because no single event crossed a threshold.

Legacy authentication flows make this worse. Organizations still running Resource Owner Password Credential (ROPC) flows create additional noise that masks spoofing attempts. ROPC was deprecated for good reason: it bypasses modern security controls. But migration takes time, and attackers know which organizations haven't finished.

What to Do Instead

Build detection queries that surface cardinality changes, not event counts. In your SIEM or log analysis tool, create alerts for:

• Distinct client ID count per hour exceeding 2x your rolling 30-day average
• New client IDs (never seen before) attempting authentication across multiple accounts within a 15-minute window
• Client IDs with authentication attempts against more than 50 accounts in 24 hours

These queries require baseline establishment. Run them in observation mode for two weeks. Document your normal cardinality patterns. What's typical for Monday mornings when employees return? What happens during onboarding weeks? Build your thresholds from reality, not from vendor defaults.

For OAuth specifically, correlate client ID behavior with other signals. A new client ID isn't suspicious by itself. A new client ID attempting authentication from 200 different IP addresses in an hour? That's a campaign. Your detection logic should weight multiple weak signals together rather than waiting for one strong signal.

Your incident response runbook needs updating too. When a cardinality alert fires, your team should immediately:

1. Pull the complete list of affected accounts and client IDs
2. Check if any successful authentications occurred (not just failures)
3. Cross-reference client IDs against your approved application registry
4. Isolate any accounts that successfully authenticated with spoofed IDs

This isn't a "investigate and escalate if needed" scenario. Cardinality anomalies at scale represent active campaigns. Your runbook should assume compromise until you prove otherwise.

Longer term, audit your authentication flows. If you're still running ROPC anywhere in your environment, you're giving attackers cover. Modern OAuth 2.0 flows with proper client registration don't eliminate spoofing risk, but they make detection significantly easier because you have a known-good baseline to compare against.

When Event-Based Detection Still Works

Event-based detection still matters for targeted attacks. If an attacker compromises credentials and uses them from a single client ID, cardinality analysis won't help you. Volume thresholds catch brute force attempts. Geolocation checks catch credential stuffing. Impossible travel detection catches account takeover.

The conventional approach works when attackers behave conventionally: high volume, low sophistication, obvious patterns. Your existing rules probably catch 80 percent of authentication attacks just fine.

But that remaining 20 percent represents the sophisticated campaigns that understand your detection logic and engineer around it. These attackers studied your thresholds. They know you're counting events. They've adapted.

Your detection strategy needs to adapt too. Keep your event-based rules. Add cardinality tracking. Build queries that surface distribution patterns, not just counts. The attackers already know you're watching individual trees. Start watching the forest.