Detección de ataques de fatiga MFA en los logs de Okta
Detecta la fatiga MFA (push bombing) en el System Log de Okta: eventTypes de Classic e Identity Engine, un umbral razonable, falsos positivos y qué corregir.
TL;DR. La fatiga MFA (push bombing) aparece en el System Log como una ráfaga de system.push.send_factor_verify_push para un mismo usuario, con los rechazos registrados como user.mfa.okta_verify.deny_push en Classic Engine o como user.authentication.auth_via_mfa fallidos en Identity Engine, y a veces termina con un push aceptado. Cinco o más en 15 minutos justifican una alerta; un push aceptado justo después de la ráfaga es un incidente. El atacante ya tiene la contraseña, así que restablécela, elimina las sesiones, restablece los factores y activa el number challenge.
Cómo funciona el ataque
El atacante tiene una contraseña válida (obtenida por phishing, reutilizada, comprada o por spraying). La cuenta exige un push de Okta Verify. Así que lanza inicios de sesión una y otra vez hasta que el usuario, cansado, confundido o tranquilizado por una falsa llamada del «soporte de TI», pulsa Aprobar. MITRE ATT&CK recoge esta técnica como T1621, Multi-Factor Authentication Request Generation. El aviso conjunto de CISA y el FBI sobre Scattered Spider incluye, entre las técnicas del grupo, solicitudes MFA repetidas que acaban siendo aceptadas por los empleados (CISA AA23-320A).
No se explota nada. Los registros simplemente muestran a un usuario que recibió muchas más solicitudes de las que genera una persona.
Cómo se ve en el System Log
| eventType | Classic Engine | Identity Engine | Significado |
|---|---|---|---|
system.push.send_factor_verify_push | sí | sí | se envió un push al dispositivo |
user.mfa.okta_verify.deny_push | sí | no | el usuario rechazó el push |
user.authentication.auth_via_mfa + outcome.result = FAILURE + factor push | — | sí | la verificación push falló o fue rechazada |
user.authentication.auth_via_mfa + SUCCESS | sí | sí | una verificación de factor tuvo éxito |
user.session.start | sí | sí | los inicios de sesión que provocaron las solicitudes |
La diferencia Classic / OIE está documentada en el catálogo de event types de Okta: la entrada de deny_push indica que Identity Engine usa en su lugar el fallo genérico de auth_via_mfa. Los Workflows contra la fatiga MFA de Okta Security usan justo estas dos consultas, una por motor, con un umbral por defecto de más de cinco rechazos en una hora (Okta Security: responder a solicitudes push anómalas).
Una ráfaga típica, simplificada:
09:12:03 system.push.send_factor_verify_push j.doe 203.0.113.50
09:12:31 user.authentication.auth_via_mfa j.doe FAILURE factor=OKTA_VERIFY_PUSH
09:13:10 system.push.send_factor_verify_push j.doe 203.0.113.50
09:13:40 user.authentication.auth_via_mfa j.doe FAILURE
09:15:02 system.push.send_factor_verify_push j.doe 203.0.113.50
...
09:21:47 user.authentication.auth_via_mfa j.doe SUCCESS ← el que importa
Fíjate en la IP: cada push lo provoca el inicio de sesión del atacante, así que el client.ipAddress de esos eventos es el suyo, no el del teléfono del usuario.
Una detección defendible
La regla del analizador Okta Forensics (mfa.push_fatigue) es:
| Parámetro | Valor |
|---|---|
| Eventos contados | push enviados, deny_push, auth_via_mfa fallidos con factor push |
| Agrupados por | usuario |
| Umbral | 5 eventos en 15 minutos → alta |
| Agravamiento | un auth_via_mfa o user.mfa.okta_verify correcto para ese usuario en los 15 minutos posteriores a la ráfaga → crítica |
| ATT&CK | T1621 |
Por qué estos números: un inicio de sesión real produce un push, quizá dos si el teléfono tarda. Cinco en un cuarto de hora queda muy fuera de lo normal, pero es lo bastante bajo para atrapar a un atacante paciente que espacia las solicitudes. La plantilla de Workflow de Okta usa una ventana más amplia de una hora; si ajustas tu propia regla de SIEM, prueba ambas con tus datos.
Cosas que parecen fatiga MFA y no lo son
- Un usuario que accede a muchas aplicaciones con MFA por aplicación en poco tiempo, la mañana siguiente a un cambio de contraseña. Todos los push se aceptan y vienen de su red habitual. Mira los resultados y la IP.
- Un dispositivo averiado (notificaciones retrasadas que llegan todas juntas). El usuario lo reintenta; ves envíos sin rechazos.
- Cuentas de servicio compartidas con MFA por push (mala idea de por sí).
Lo que marca la diferencia es la red de origen de los inicios de sesión que provocan los push, la proporción de rechazos frente a aprobaciones y si el usuario puede explicarlo. Llámale a un número conocido.
Investigar una alerta
- Reúne todos los eventos del usuario de ese día. ¿Qué IP y qué ASN provocaron los push? ¿Es un proveedor de hosting o un anonimizador (
securityContext.isProxy,debugData.tunnels)? - ¿Se aceptó algún push? Si es así, localiza la sesión (
authenticationContext.externalSessionId) creada por esa aprobación y enumera todo lo que hizo: destinos de SSO, registro de factores, acceso a la Admin Console. - ¿Registró el atacante su propio factor? Un
user.mfa.factor.activatedesde la IP del atacante significa que ya no necesita la aprobación del usuario. Es el mismo punto de apoyo que en la ingeniería social al helpdesk. - ¿Lo notificó el usuario?
user.account.report_suspicious_activity_by_enduseraparece cuando los usuarios usan el enlace de aviso de los correos de notificación de seguridad de Okta (Okta Help Center). Es una señal valiosísima: trátala como un hallazgo de gravedad alta. - Busca el mismo origen en otras cuentas. Un atacante que tiene una contraseña suele tener varias. Pivota sobre la IP en la vista de entidades.
Contención y refuerzo
En este orden:
- Elimina las sesiones del usuario y revoca sus tokens.
- Restablece la contraseña (el atacante la conoce) y los factores; vuelve a registrarlos por un canal verificado.
- Elimina cualquier factor registrado desde la red del atacante.
- Investiga las aplicaciones abiertas con la sesión aprobada.
Después, cierra la puerta:
- Number challenge. Okta Verify puede exigir que el usuario elija el número que aparece en la pantalla de inicio de sesión, en todos los push o solo en los de alto riesgo (Okta Help Center: opciones de Okta Verify). CISA recomienda el number matching como mitigación provisional para el MFA basado en push (ficha de CISA).
- Autenticadores resistentes al phishing (qué significa), primero para los administradores y después para todos: no hay ninguna solicitud que aprobar.
- La notificación de actividad sospechosa activada, con un procedimiento que actúe el mismo día.
FAQ
¿Qué evento de Okta muestra un push rechazado?
En Classic Engine, user.mfa.okta_verify.deny_push. En Identity Engine, un evento user.authentication.auth_via_mfa con resultado FAILURE y un factor push de Okta Verify en debugData. Vigila los dos.
¿La fatiga MFA significa que la contraseña está comprometida?
Casi siempre. El push es el segundo factor: normalmente el atacante tuvo que superar el paso de la contraseña para provocarlo. Restablece la contraseña además de los factores.
¿Qué detiene el push bombing?
El number challenge en los push de Okta Verify reduce las aprobaciones a ciegas; los autenticadores resistentes al phishing, como Okta FastPass o las llaves FIDO2, eliminan por completo el paso de aprobar una solicitud.