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.
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.
- 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
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.