Ataques de fatiga MFA - la nueva táctica de forzar la aprobación de notificaciones
Lectura de 13 min aprox.
Los ataques de fatiga MFA - también conocidos como bombardeo de prompts MFA o fatiga de notificaciones push - se han convertido en una de las técnicas más efectivas para eludir la autenticación multifactor. El atacante ya posee las credenciales de la víctima (obtenidas mediante phishing, credential stuffing o compras en la dark web) y activa repetidamente notificaciones push de MFA hasta que la víctima aprueba una por puro agotamiento o confusión. El informe de amenazas 2023 de Mandiant documentó que los ataques de elusión de MFA se duplicaron con creces año tras año, siendo la fatiga push el vector dominante. La brecha de Uber en 2022 demostró el devastador impacto real: una sola notificación aprobada dio al grupo Lapsus$ acceso a sistemas internos incluyendo Slack, Google Workspace y repositorios de código fuente. Este artículo analiza la mecánica técnica, la explotación psicológica, los casos de brechas emblemáticos y las defensas concretas - desde number matching hasta FIDO2 - que neutralizan este ataque.
Mecánica técnica del ataque
Los ataques de fatiga MFA explotan una debilidad de diseño fundamental en la MFA basada en notificaciones push. Con la MFA push tradicional, los usuarios completan la autenticación simplemente tocando "aprobar" o "denegar" en una notificación del smartphone. Aunque este diseño destaca en conveniencia, no proporciona medios para que los usuarios verifiquen la legitimidad de una solicitud de autenticación. Los atacantes aprovechan que cada intento de inicio de sesión con credenciales robadas activa una notificación push, enviando decenas a cientos de notificaciones continuamente, incluyendo durante horas nocturnas y madrugada.
El flujo típico del ataque procede de la siguiente manera. En la primera fase, el atacante obtiene el nombre de usuario y contraseña del objetivo mediante phishing, compra de credenciales de bases de datos filtradas o ingeniería social. En la segunda fase, scripts automatizados intentan repetidamente iniciar sesión en el servicio objetivo. Cada intento genera una notificación push, inundando el smartphone de la víctima con alertas continuas. En la tercera fase, la víctima aprueba una notificación, o el atacante los contacta vía WhatsApp o SMS haciéndose pasar por soporte de TI, diciendo "por favor apruebe para resolver un problema de seguridad." En el caso de Uber, el atacante envió notificaciones push durante más de una hora antes de contactar a la víctima vía WhatsApp, haciéndose pasar por el departamento de TI para fomentar la aprobación.
Análisis detallado de la brecha de Uber en 2022
En septiembre de 2022, un atacante de 18 años asociado con el grupo Lapsus$ infiltró los sistemas internos de Uber. El ataque se originó a partir de credenciales VPN de un contratista externo de Uber compradas en la dark web. El atacante intentó iniciar sesión en la VPN de Uber usando estas credenciales, pero como la MFA estaba habilitada, se enviaron notificaciones push al smartphone del empleado contratista. El atacante intentó repetidamente iniciar sesión durante más de una hora, enviando continuamente una avalancha de notificaciones push.
Finalmente, el atacante contactó a la víctima vía WhatsApp, haciéndose pasar por soporte de TI de Uber y declarando que "el problema de inicio de sesión no se resolverá a menos que apruebe la notificación." La víctima agotada aprobó la notificación, y el atacante obtuvo acceso VPN. Después de conectarse a la VPN, el atacante escaneó la red interna y descubrió un script PowerShell en una carpeta compartida de red. Este script contenía credenciales de administrador codificadas para Thycotic (una herramienta de gestión de acceso privilegiado). Usando estas credenciales, el atacante accedió al Slack de Uber, Google Workspace, consola AWS, informes de bug bounty de HackerOne y repositorios de código fuente. El alcance total del daño fue severo, con Uber enfrentando obligaciones de reporte ante la SEC y serio daño a la reputación de marca.
La brecha de Cisco en 2022 y patrones de ataque comunes
En mayo de 2022, Cisco también fue víctima de un ataque de fatiga MFA. En este caso, el atacante primero comprometió la cuenta personal de Google de un empleado. A través de la función de sincronización de contraseñas del navegador Chrome, las credenciales VPN de Cisco almacenadas en la cuenta personal cayeron en manos del atacante. Luego, el atacante envió repetidamente notificaciones push MFA similar al caso de Uber, combinado con phishing de voz (vishing) haciéndose pasar por soporte de TI de Cisco, para que la víctima aprobara una notificación. Cisco detectó la intrusión y la contuvo exitosamente, pero algunos datos internos fueron exfiltrados.
Lo que los casos de Uber y Cisco tienen en común es que los ataques de fatiga MFA no se usan de forma aislada sino combinados con ingeniería social. Al explotar simultáneamente tanto vectores de ataque técnicos como debilidades psicológicas humanas, la tasa de éxito aumenta dramáticamente. Para esta metodología de ataque combinada, nuestro artículo sobre defensas de ingeniería social proporciona contexto adicional.
Por qué las personas aprueban notificaciones - Análisis de factores psicológicos
El éxito de los ataques de fatiga MFA depende más de las debilidades psicológicas humanas que de las vulnerabilidades técnicas. El primer factor es la "fatiga de notificaciones." Los usuarios de smartphones reciben un promedio de más de 80 notificaciones por día, desarrollando el hábito de procesar notificaciones sin escudriñar su contenido. Las notificaciones MFA quedan enterradas entre esta avalancha de alertas. El segundo factor es la suposición de que "quizás yo activé esto." Muchos usuarios, al recibir una notificación MFA, piensan "tal vez estaba intentando iniciar sesión en algún lugar" y aprueban sin cuestionamiento profundo.
El tercer factor es el "deterioro del juicio por interrupción del sueño." Cuando los atacantes envían notificaciones continuamente a las 2 o 3 AM, las víctimas privadas de sueño aprueban por el impulso de "simplemente hacer que pare." La investigación muestra que la capacidad de toma de decisiones durante la privación de sueño cae a niveles equivalentes a la intoxicación, y los atacantes deliberadamente apuntan a esta debilidad fisiológica. El cuarto factor es la "obediencia a la autoridad." Como en el caso de Uber, cuando los atacantes contactan a las víctimas haciéndose pasar por soporte de TI, muchos empleados cumplen sin sospecha porque "es una instrucción del departamento de TI." Este es el mismo mecanismo psicológico demostrado en los experimentos de obediencia de Stanley Milgram.
Notificaciones push vs Number Matching vs FIDO2 - Comparación de resistencia
La resistencia a los ataques de fatiga varía significativamente según el método de implementación MFA. La MFA tradicional basada en notificaciones push es la más vulnerable a ataques de fatiga porque la autenticación se completa con un simple toque de "aprobar." Los atacantes pueden enviar notificaciones push ilimitadas mientras tengan las credenciales. El number matching requiere que los usuarios ingresen un número de 2 dígitos mostrado en la pantalla de inicio de sesión en su aplicación autenticadora del smartphone. Incluso si un atacante envía notificaciones push, la víctima no puede completar la autenticación sin conocer el número mostrado en la pantalla de inicio de sesión. Esto previene la autenticación accidental mediante simples toques de "aprobar."
La autenticación basada en FIDO2/WebAuthn (llaves de seguridad de hardware y passkeys) tiene resistencia completa a los ataques de fatiga MFA. En la autenticación FIDO2, las notificaciones push no existen - la autenticación se inicia solo cuando el usuario toca físicamente una llave de seguridad o realiza autenticación biométrica en su dispositivo. Además, las solicitudes de autenticación están criptográficamente vinculadas al origen (dominio) del servicio, haciendo imposible la autenticación a través de sitios de phishing. Microsoft habilitó el number matching por defecto en la aplicación Authenticator en febrero de 2023 y reportó una disminución significativa en los reportes de ataques de fatiga push.
Para una comprensión más profunda de la autenticación resistente al phishing, nuestra guía de autenticación de dos factores y la guía de llaves de seguridad de hardware cubren los fundamentos técnicos. La entrada del glosario sobre TOTP también explica por qué los códigos basados en tiempo son más resistentes que las notificaciones push.
Contramedidas para organizaciones e individuos
La contramedida de mayor prioridad para las organizaciones es migrar de MFA basada en notificaciones push a number matching o autenticación basada en FIDO2. Microsoft Authenticator, Duo Security y Okta Verify ofrecen funcionalidad de number matching que los administradores pueden aplicar como política. Además, las organizaciones deben configurar alertas para patrones anormales de intentos de autenticación (grandes volúmenes de solicitudes MFA a la misma cuenta en un período corto) y construir un marco para que los equipos de seguridad respondan inmediatamente. Implementar limitación de tasa en solicitudes MFA (por ejemplo, máximo 3 solicitudes por 5 minutos) dificulta que los atacantes envíen grandes volúmenes de notificaciones.
Para usuarios individuales, el primer paso es verificar la configuración MFA de los servicios que usa y habilitar number matching donde esté disponible. Los servicios principales incluyendo cuentas de Microsoft y cuentas de Google ya soportan number matching. Para una protección aún más fuerte, considere migrar a passkeys o llaves de seguridad de hardware. Además, si recibe una notificación MFA que no inició, nunca la apruebe y cambie su contraseña inmediatamente. Incluso si alguien lo contacta afirmando ser soporte de TI, desarrollar el hábito de verificar contactando los canales de soporte oficiales usted mismo es la defensa más fuerte contra la ingeniería social.
Para una guía completa sobre la transición a autenticación resistente al phishing, recursos de autenticación multifactor (Amazon) cubren tanto la implementación técnica como la gestión del cambio organizacional.
Perspectivas futuras - La carrera armamentista entre la evolución MFA y los ataques
El auge de los ataques de fatiga MFA está acelerando la evolución de la seguridad de autenticación. Microsoft, Google y Apple anunciaron conjuntamente la promoción de passkeys en 2022, y la transición a nivel industrial hacia autenticación que no depende de notificaciones push está en marcha. Sin embargo, los atacantes también continúan evolucionando. Los proxies de phishing en tiempo real (EvilProxy, Evilginx, etc.) retransmiten MFA incluyendo number matching en tiempo real para eludirla, y combinados con el robo de tokens de sesión, eluden completamente la MFA. Contra este ataque, la verificación de origen de FIDO2 es la única contramedida técnica. La defensa multicapa para prevenir el "punto único de fallo" de autenticación - incluyendo adopción de arquitectura zero trust, autenticación continua y verificaciones de salud del dispositivo - será cada vez más importante.
Preguntas frecuentes
- ¿Cómo puedo saber si estoy siendo objetivo de un ataque de fatiga MFA?
- Si recibe notificaciones push MFA repetidas cuando no ha intentado iniciar sesión, es probable que esté siendo objetivo de un ataque de fatiga MFA. Múltiples notificaciones en un período corto es especialmente indicativo de un ataque. En este caso, nunca apruebe la notificación, cambie su contraseña inmediatamente y reporte a su departamento de TI (para organizaciones) o al equipo de soporte del servicio.
- ¿Habilitar number matching previene completamente los ataques de fatiga MFA?
- El number matching reduce significativamente la tasa de éxito de los ataques de fatiga MFA pero no es una defensa completa. Si los atacantes usan proxies de phishing en tiempo real, las víctimas pueden ingresar el número en un sitio de phishing. La defensa completa requiere autenticación basada en FIDO2 (llaves de seguridad de hardware o passkeys). FIDO2 verifica criptográficamente el origen del servicio, haciendo la autenticación a través de sitios de phishing matemáticamente imposible.
- ¿Pueden ocurrir ataques de fatiga MFA con TOTP (contraseñas de un solo uso basadas en tiempo)?
- No, los ataques de fatiga MFA no se aplican a TOTP. TOTP no usa notificaciones push - los usuarios ingresan manualmente un código de 6 dígitos mostrado en su aplicación autenticadora. Incluso si un atacante intenta iniciar sesión, no se envía ninguna notificación al smartphone de la víctima. Sin embargo, TOTP es vulnerable al robo de códigos mediante phishing en tiempo real. La opción más segura es la autenticación basada en FIDO2.