// Incident of the week
Severity: High #3 · 2026-08-24

One success among 47 failed logins… and a new OAuth app

Signals

  • 47 failed sign-ins in Entra ID (Azure AD)
  • 1 successful sign-in from a new IP
  • Impossible travel: Madrid then Singapore in 20 min
  • An OAuth application was registered with mail-read permissions

What do you investigate first?

▸ See the breakdown (reasoning, evidence, MITRE, detection)
  • A) Containing before scoping is premature: disabling the account does not remove an already-granted OAuth token, and you lose visibility into what the attacker did.
  • B) Blocking the IP is whack-a-mole: the attacker rotates IPs and, if the OAuth app is in place, does not even need it.
  • C) ✅ Correct. The pattern (failures → 1 success) is a successful password spray; the OAuth app is the PERSISTENCE mechanism. Investigating it tells you the scope and whether persistent access survives a reset.
  • D) Classic trap: resetting the password does NOT revoke OAuth tokens. The attacker would remain in via the consented app.
Why

This is a successful password spray followed by OAuth consent persistence. The triage key: scope before you contain, and hit the mechanism that survives the obvious fix first. Resetting the password or disabling the account does not touch the OAuth app token: the attacker would keep mailbox access. So you investigate (then revoke) the OAuth grant first; afterwards revoke sessions, reset credentials and enforce MFA.

Evidence to look at
  • SigninLogs: burst of errorCode 50126 (invalid credential) and 1 success from new IP/ASN
  • AuditLogs: "Consent to application" / "Add app role assignment" / "Add OAuth2PermissionGrant"
  • MailItemsAccessed / inbox rules created after the access
How to detect it

In Sentinel: correlate SigninLogs (spray: many failures + 1 success per user/IP) with OAuth consent AuditLogs in a short window. Alert when a suspicious sign-in precedes an app consent with mail permissions.

Share it as a challenge, then post the breakdown.