Un login correcto entre 47 fallidos… y una app OAuth nueva
Señales
- 47 inicios de sesión fallidos en Entra ID (Azure AD)
- 1 inicio de sesión correcto desde una IP nueva
- Viaje imposible: Madrid y luego Singapur en 20 min
- Se registró una aplicación OAuth con permisos de lectura de correo
¿Qué investigas primero?
▸ Ver la resolución (razonamiento, evidencia, MITRE, detección)
- A) Contener antes de acotar es prematuro: deshabilitar la cuenta no elimina el token OAuth ya concedido, y pierdes visibilidad de qué hizo el atacante.
- B) Bloquear la IP es whack-a-mole: el atacante rota IPs y, si ya tiene la app OAuth, ni la necesita.
- C) ✅ Correcto. El patrón (fallidos → 1 éxito) es un password spray con éxito; la app OAuth es el mecanismo de PERSISTENCIA. Investigarla te dice el alcance y si ya hay acceso persistente que sobrevive a un reseteo.
- D) Trampa clásica: resetear la contraseña NO revoca los tokens OAuth. El atacante seguiría dentro vía la app consentida.
Es un password spray con éxito seguido de persistencia por consentimiento OAuth. La clave de triage: acota antes de contener, y ataca primero el mecanismo que sobrevive a la remediación obvia. Resetear la contraseña o deshabilitar la cuenta no toca el token de la app OAuth: el atacante mantendría acceso al correo. Por eso se investiga (y luego se revoca) la concesión OAuth primero; después, revocar sesiones, resetear credenciales y forzar MFA.
- SigninLogs: ráfaga de errorCode 50126 (credencial inválida) y 1 éxito desde IP/ASN nuevos
- AuditLogs: «Consent to application» / «Add app role assignment» / «Add OAuth2PermissionGrant»
- MailItemsAccessed / reglas de bandeja creadas tras el acceso
En Sentinel: correlaciona SigninLogs (spray: muchos fallos + 1 éxito por usuario/IP) con AuditLogs de consentimiento OAuth en una ventana corta. Alerta si un inicio de sesión sospechoso precede a un consentimiento de app con permisos de correo.