MFA Fatigue en Entra ID: detección y prevención

¿Qué es MFA Fatigue?

MFA fatigue, también llamada MFA bombing o push bombing, consiste en generar repetidamente solicitudes de multifactor authentication hasta que un usuario termina aprobando una. MITRE sigue esta técnica como T1621, Multi-Factor Authentication Request Generation.

El mecanismo es más concreto de lo que muchas organizaciones describen. En el caso habitual, el atacante ya dispone de la contraseña de la víctima y solo queda bloqueado por el segundo factor. En lugar de detenerse ahí, genera una y otra vez notificaciones push hacia Microsoft Authenticator, Duo, Okta Verify o un servicio MFA similar, intentando desgastar al usuario.

El alcance de este artículo es Microsoft Entra ID y MFA push con Microsoft Authenticator, con foco en detección operativa y hardening del tenant. MFA fatigue no es lo mismo que password spraying, phishing adversary-in-the-middle o SIM swapping, aunque esas técnicas suelen aparecer antes o en paralelo.

El riesgo clave es simple: un control MFA basado en aprobaciones push sigue dependiendo de que el usuario tome la decisión correcta bajo presión. Si el atacante puede crear prompts repetidos, o combinarlos con un pretexto de ingeniería social, un control que parecía fuerte en la política puede fallar en la práctica.

Cómo funciona MFA Fatigue

La definición de MITRE es precisa: los adversarios pueden intentar bypassear MFA generando solicitudes MFA enviadas a los usuarios. Si ya poseen credenciales válidas, pueden quedarse bloqueados únicamente porque no controlan el segundo factor. Para sortear eso, abusan de las notificaciones push y esperan que el usuario conceda acceso.

Esto importa porque el ataque no rompe criptografía. Abusa del diseño del flujo de autenticación y del comportamiento humano de aprobación.

Una secuencia típica centrada en Entra se parece a esto:

el atacante obtiene un usuario y contraseña válidos mediante phishing, password spraying, credential stuffing o ingeniería social contra help desk
el atacante inicia un sign-in interactivo que requiere aprobación de Microsoft Authenticator
el usuario recibe notificaciones push repetidas
el atacante sigue reintentando, a menudo en momentos elegidos para provocar confusión o cansancio
si el usuario termina aprobando una solicitud, el atacante obtiene una sesión autenticada válida

MITRE también apunta una segunda vía que a veces se pasa por alto: si el atacante aún no tiene credenciales, la generación automática de push también puede abusarse en ciertos escenarios de self-service password reset cuando ese flujo está configurado para enviar notificaciones push.

MFA fatigue no es lo mismo que otros ataques de identidad

Las diferencias importan porque las mitigaciones no son idénticas.

Password spraying prueba una o pocas contraseñas sobre muchos usuarios para obtener la primera credencial válida. Ver Password Spraying: detección y prevención en Active Directory y Entra ID.
MFA fatigue empieza después de que el atacante ya tenga, o casi tenga, un primer factor válido y quiera convertir un login bloqueado en uno aprobado.
Phishing adversary-in-the-middle proxifica el flujo de inicio de sesión para capturar tokens o contexto de sesión en tiempo real. No depende del cansancio del usuario del mismo modo.
SIM swapping apunta a factores basados en teléfono tomando control del número móvil de la víctima.

MFA fatigue ataca específicamente el paso humano de aprobación dentro de una MFA basada en push.

Por qué MFA Fatigue sigue funcionando

MFA fatigue sigue siendo eficaz cuando se superponen tres problemas: el atacante tiene un primer factor válido, el tenant sigue confiando en aprobaciones push para cuentas importantes y el usuario no tiene suficiente contexto o fricción para rechazar la solicitud con seguridad.

La propia guía de Microsoft sobre phishing-resistant MFA es explícita: métodos MFA tradicionales como SMS, OTP por email y notificaciones push son cada vez menos eficaces frente a atacantes modernos. El documento cita user fatigue y MFA bombing como ejemplos concretos de cómo los atacantes sortean patrones MFA heredados.

En la práctica, MFA fatigue funciona porque:

Las aprobaciones push son fáciles de disparar repetidamente

El atacante no necesita romper un token ni vencer una llave física. Solo necesita un flujo de inicio de sesión que siga generando prompts.

Muchos usuarios siguen viendo prompts con poco contexto

Si la notificación no muestra claramente el nombre de la aplicación y el contexto geográfico del inicio de sesión, el usuario tiene menos información para distinguir una actividad legítima de un ataque. Microsoft recomienda explícitamente aportar ese contexto en las notificaciones de Authenticator.

Los usuarios pueden ser manipulados mientras llegan los prompts

Una solicitud push tiene más probabilidades de ser aprobada si llega mientras el atacante presiona a la víctima por teléfono o mensajería, durante un reset de contraseña legítimo o cuando el usuario ya espera actividad real de inicio de sesión.

Las cuentas de alto valor suelen seguir protegidas solo por MFA estándar

Si los administradores siguen dependiendo de aprobaciones push estándar en lugar de MFA resistente al phishing, la lista de objetivos del atacante gana muchísimo valor.

Requisitos previos para que un ataque MFA Fatigue tenga éxito

Un ataque MFA fatigue exitoso suele requerir las siguientes condiciones.

1. El atacante tiene un primer factor válido o puede disparar un flujo de reset

La suposición base de MITRE es que el atacante ya dispone de credenciales válidas. En el mundo Entra eso suele significar una contraseña robada, una contraseña recuperada de otra intrusión o una contraseña obtenida tras Password Spraying: detección y prevención en Active Directory y Entra ID.

2. El objetivo usa MFA push

El ataque depende de que el usuario reciba una solicitud de aprobación. Si la cuenta objetivo está restringida a métodos resistentes al phishing, por ejemplo mediante authentication strengths más fuertes para inicios de sesión privilegiados, MFA fatigue pierde mucha utilidad.

3. El tenant no ha reducido lo suficiente las aprobaciones de bajo contexto

Si el prompt solo muestra una solicitud genérica, o si no está habilitado el reporte de actividad sospechosa, el usuario recibe menos contexto y el defensor menos señales de alta confianza cuando hay abuso.

4. La cuenta tiene suficiente valor como para justificar intentos repetidos

Administradores, operadores cloud, personal de help desk y administradores de aplicaciones son objetivos especialmente atractivos, porque una sola aprobación puede producir mucho acceso posterior.

5. Los workflows de respuesta son demasiado lentos

Si las negativas repetidas de prompts no se investigan rápido, o si los reportes de prompt sospechoso no provocan containment, el atacante puede seguir insistiendo hasta que un usuario apruebe o una segunda maniobra de ingeniería social tenga éxito.

La cadena de ataque

Una cadena práctica de intrusión por MFA fatigue suele verse así.

Paso 1 - Obtener la contraseña

El atacante consigue primero la contraseña por phishing, password spraying, reutilización de credenciales o ingeniería social.

Paso 2 - Disparar el reto MFA

El atacante intenta un inicio de sesión contra Microsoft 365, Azure o una carga conectada a Entra que requiera aprobación de Authenticator.

Paso 3 - Repetir la generación de prompts

En lugar de aceptar el fallo inicial, el atacante sigue generando solicitudes de aprobación. Ese es exactamente el comportamiento que MITRE recoge en T1621.

Los atacantes pueden acompañar los prompts con llamadas o mensajes que empujan al usuario a aprobar una solicitud, a menudo fingiendo ser soporte interno o aprovechando un momento de confusión alrededor de un inicio de sesión o un reset de contraseña real.

Paso 5 - Usar la sesión aprobada de inmediato

Una vez que el usuario aprueba un prompt, el atacante ya tiene lo que quería: una sesión válida dentro del tenant objetivo. A partir de ahí, las siguientes acciones dependen del nivel de privilegio y de la cobertura de políticas. Las más habituales son revisar el directorio, descubrir roles privilegiados, buscar app registrations, acceder a buzones o cambiar configuraciones de autenticación.

El prompt aprobado no es el final del incidente. Es el punto de pivote entre login bloqueado y acceso autenticado.

Detección

No existe un único evento Entra que diga “esto fue definitivamente MFA fatigue”. El modelo correcto es detección basada en secuencias más contexto.

Buscar negativas repetidas de MFA sobre el mismo usuario

La señal más evidente es un grupo de intentos repetidos en el que el mismo usuario recibe múltiples solicitudes MFA y las deniega o ignora. En los sign-in logs de Entra, eso suele verse como sign-ins interrumpidos repetidos con detalles de fallo MFA antes de un posible éxito posterior.

Tratar los reportes de prompts sospechosos como evidencia de alta confianza

La función Report suspicious activity de Microsoft es la señal nativa más fuerte en este flujo. Según Microsoft Learn:

los usuarios que reportan como sospechosa una solicitud MFA desconocida pasan a High User Risk
el evento aparece en sign-in logs, audit logs y risk detections
el riskEventType es userReportedSuspiciousActivity

Eso importa porque permite pasar de suposiciones a una señal concreta confirmada por el propio usuario.

Las investigaciones deberían correlacionar la secuencia de prompts con:

IPs y geografías que el usuario no suele utilizar
aplicaciones inusuales que inician el sign-in
intentos repetidos desde la misma fuente contra una cuenta de alto valor
un patrón de varias negativas seguido de un único éxito
actividad inmediatamente posterior a la aprobación exitosa

Prestar especial atención a identidades privilegiadas

Un solo episodio de push bombing contra un usuario normal ya es serio. Ese mismo patrón contra un Global Administrator, un Conditional Access Administrator o un Privileged Role Administrator exige containment inmediato.

Esa es una de las razones por las que conviene revisar Acceso privilegiado Azure: roles, PIM y administracion permanente y Cómo auditar la seguridad de Microsoft Entra ID (Azure AD): guía práctica junto con este patrón de ataque.

Evitar conclusiones basadas en un único evento

Los usuarios a veces deniegan prompts legítimos. Cambios de red móvil, sign-ins desde un nuevo dispositivo o simple confusión del usuario también generan ruido. Por eso, el mejor detector no es una sola negativa, sino un patrón repetido, sobre todo cuando se combina con user-reported suspicious activity, contexto de sign-in inusual o acciones privilegiadas posteriores.

Remediation / Remediación

Detener MFA fatigue no consiste en añadir más prompts MFA genéricos. Consiste en hacer que las aprobaciones maliciosas sean más difíciles de disparar, más fáciles de reconocer y menos valiosas cuando aun así se producen.

1. Verificar que los flujos push de Authenticator usan number matching

Microsoft indica que number matching está habilitado para las notificaciones push actuales de Authenticator y lo presenta como una mejora de seguridad clave respecto al antiguo modelo Approve/Deny.

Eso importa porque el atacante ya no puede ganar con un simple tap descuidado sobre un prompt genérico. El usuario debe introducir un número mostrado en el flujo de inicio de sesión.

Si tu entorno todavía depende de integraciones MFA más antiguas o adyacentes, hay que validar su comportamiento por separado en lugar de asumir que todos los workflows push tienen el mismo nivel de protección que la experiencia actual Entra + Authenticator.

Microsoft recomienda explícitamente mostrar el nombre de la aplicación y la ubicación geográfica en las notificaciones de Authenticator para que los usuarios puedan tomar decisiones informadas de aprobación.

Un tenant que deja las aprobaciones push demasiado genéricas facilita los ataques de fatiga. Cuando el prompt muestra una aplicación o ubicación que el usuario no reconoce, la denegación se vuelve mucho más probable.

Este control es especialmente útil cuando el atacante ya tiene una contraseña real y está intentando convertirla en una sesión aprobada.

3. Habilitar Report suspicious activity y conectarlo a respuesta

Este ajuste es uno de los controles Entra de más valor contra MFA fatigue.

Microsoft documenta que cuando un usuario reporta un prompt MFA sospechoso:

el usuario pasa a High User Risk
el evento es visible en sign-in logs, audit logs y risk detections
las organizaciones con la licencia adecuada pueden usar risk-based Conditional Access para bloquear o forzar una remediación segura
las organizaciones sin esa automatización siguen obteniendo una señal concreta que pueden investigar y contener

Operativamente, esto significa que el usuario puede hacer algo más que pulsar Deny. Puede crear una señal de incidente visible para el defensor desde el mismo prompt.

4. Mover a los usuarios privilegiados hacia MFA resistente al phishing

La guía actual de Microsoft es clara: los roles administrativos privilegiados son objetivos frecuentes y las organizaciones deberían exigir phishing-resistant MFA para esos roles.

Para el tema de este artículo, este punto es central. Una aprobación push estándar todavía puede ser abusada mediante fatiga o ingeniería social. Una authentication strength resistente al phishing hace ese camino materialmente más difícil.

Si estás endureciendo acceso privilegiado, combínalo con Identidad Azure: MFA, metodos y Security Defaults y Azure Identity Protection: Politicas de Riesgo.

5. Reducir la cantidad de contraseñas reutilizables desde el inicio

MFA fatigue suele empezar después de una compromisión de contraseña. Si reduces el robo de contraseñas y el éxito del password spraying, también reduces las oportunidades de push bombing.

Eso hace que Acceso condicional Azure: brechas reales que permiten bypass de MFA y Endurecimiento del tenant Azure: corregir defaults inseguros sean directamente relevantes. Los flujos MFA más robustos importan, pero deben asentarse sobre un tenant que ya está reduciendo el acceso inicial basado en contraseña.

6. Revisar identidades externas e invitadas por separado

El riesgo de MFA push no se limita a cuentas de empleados. Identidades externas, cuentas invitadas B2B y accesos de partners también pueden convertirse en caminos de aprobación ruidosos o poco revisados si están exentos de controles más fuertes o se monitorizan peor. Por eso Cuentas invitado Azure: gobierno, MFA y riesgo de acceso externo forma parte de la misma revisión.

7. Desplegar políticas más fuertes con cuidado

La guía de Microsoft para administradores incluye una advertencia operativa real: antes de exigir MFA resistente al phishing de forma amplia a los administradores, hay que confirmar que esos usuarios ya están registrados con los métodos necesarios. Si no, puedes bloquearte a ti mismo fuera del tenant.

La misma lógica aplica a cambios de Conditional Access en general:

usar report-only cuando esté disponible
proteger deliberadamente las cuentas de acceso de emergencia
revisar por separado cuentas de servicio y workload identities
validar que los workflows de help desk y recuperación de identidad siguen funcionando

Un buen hardening de identidad no consiste solo en más controles. También consiste en evitar caídas autoinducidas.

Validación tras el endurecimiento

No cierres este tema solo porque hayas activado una opción en Entra. Hay que validar todo el workflow de aprobación.

confirmar que el tenant realmente presenta number matching en los escenarios Authenticator push que de verdad utilizas
confirmar que el prompt muestra nombre de la aplicación y ubicación geográfica donde corresponde
confirmar que Report suspicious activity está habilitado para la población de usuarios prevista
confirmar que los reportes de prompts sospechosos generan las señales esperadas en sign-in logs, audit logs y risk detections
confirmar que el workflow de respuesta revoca sesiones, investiga sign-ins y resetea credenciales cuando un usuario reporta un prompt malicioso
confirmar que los administradores privilegiados están cubiertos por requisitos de autenticación más fuertes que los usuarios normales

La prueba real no es si MFA está habilitada en el tenant. La prueba real es si una contraseña robada, combinada con prompts push repetidos, todavía tiene una vía realista hacia una aprobación.

Cómo EtcSec detecta exposición relacionada

MFA fatigue es una técnica de ataque, no una única mala configuración de Entra. Los findings de catálogo más cercanos son los gaps de control que hacen más probable el éxito del push bombing o más difícil su contención.

Las exposiciones relacionadas más relevantes son:

ausencia de risk-based sign-in response, lo que debilita el containment después de que un usuario reporta un prompt sospechoso
protección débil o incompleta de identidades privilegiadas, especialmente cuando los usuarios administrativos no se mueven a patrones de autenticación más fuertes
diseños de Conditional Access que siguen apoyándose demasiado en prompts MFA estándar en lugar de exigir métodos más fuertes

Por eso este tema se ubica junto a Azure Identity Protection: Politicas de Riesgo, Identidad Azure: MFA, metodos y Security Defaults y Cómo auditar la seguridad de Microsoft Entra ID (Azure AD): guía práctica, y no como un ajuste aislado del tenant.

Controles relacionados

Si estás revisando MFA fatigue, también deberías revisar los controles que moldean el mismo camino de ataque: Identidad Azure: MFA, metodos y Security Defaults, Azure Identity Protection: Politicas de Riesgo, Acceso condicional Azure: brechas reales que permiten bypass de MFA, Endurecimiento del tenant Azure: corregir defaults inseguros, Cómo auditar la seguridad de Microsoft Entra ID (Azure AD): guía práctica y Cuentas invitado Azure: gobierno, MFA y riesgo de acceso externo.

MFA Fatigue: detección y prevención en Microsoft Entra ID