MFA Fatigue y push bombing: qué es el ataque y cómo frenarlo

El MFA fatigue es un ataque de ingeniería social en el que el atacante, que ya posee una contraseña válida, lanza una avalancha de notificaciones push de doble factor contra la víctima hasta que esta aprueba una por cansancio, descuido o presión. También se conoce como MFA bombing y, en la terminología de CISA, como push bombing. Es una de las vías de entrada más rentables de los últimos años porque no rompe la criptografía del segundo factor: rompe la paciencia de la persona que está al otro lado de la pantalla.

Esta guía explica qué es el MFA fatigue, aclara la diferencia entre push bombing y MFA bombing, desglosa la mecánica del ataque, repasa los casos que lo hicieron famoso (Uber 2022, Cisco 2022 y la campaña 0ktapus contra Twilio) y detalla la defensa que lo cierra: emparejamiento de números, límites sobre el push y, como solución definitiva, MFA resistente a phishing con FIDO2 y WebAuthn.

Qué es el MFA fatigue

El MFA fatigue es la explotación del segundo factor de tipo push mediante el envío repetido de solicitudes de aprobación hasta que el usuario legítimo acepta una para que el ruido pare. El atacante no necesita interceptar el código de un token ni clonar el dispositivo. Le bastan dos cosas: una contraseña válida y un segundo factor configurado como notificación push de "Aprobar o Denegar".

La contraseña llega por las vías habituales de robo de identidad: reutilización tras una brecha (el motor del credential stuffing), venta en mercados de credenciales o captura por un infostealer. Con ese primer factor, el atacante intenta autenticarse una y otra vez, y cada intento dispara una notificación en el móvil de la víctima. Si el sistema no limita esos envíos, la persona recibe decenas de avisos idénticos, muchas veces de madrugada, hasta que pulsa "Aprobar" para dormir tranquila.

MITRE ATT&CK cataloga esta técnica como T1621 (Multi-Factor Authentication Request Generation). No es un fallo de software con CVE: es un fallo de diseño, porque el factor push delega la decisión final en un ser humano cansado. Por eso ningún parche lo corrige del todo y la defensa correcta cambia el tipo de factor, no solo su configuración.

Push bombing, MFA bombing y MFA fatigue: aclarando términos

Los tres nombres describen la misma familia de ataque, pero cada uno pone el acento en un sitio distinto:

• MFA fatigue subraya el mecanismo psicológico: el agotamiento del usuario ante la insistencia.
• MFA bombing y push bombing subrayan la técnica: el bombardeo continuado de solicitudes. CISA ha estandarizado "push bombing" en sus guías sobre autenticación resistente a phishing.

Conviene no confundirlo con dos técnicas vecinas. El phishing con proxy AitM (con kits como Evilginx o EvilProxy) no bombardea: intercepta la cookie de sesión ya autenticada y esquiva el segundo factor sin pedir aprobación. El SIM swapping ataca el factor SMS secuestrando el número de teléfono. El push bombing, en cambio, ataca de frente al factor push legítimo y depende de que la víctima acabe cediendo. La mitigación de cada uno es distinta, aunque el destino final, FIDO2, las cierra casi todas a la vez.

Cómo funciona el ataque paso a paso

La cadena operativa del MFA fatigue tiene tres fases reconocibles.

1. El atacante consigue una contraseña válida

Sin contraseña no hay campaña. El atacante parte de un par correo y contraseña obtenido de una brecha reutilizada, un log de infostealer o un panel de credenciales robadas. Esta fase enlaza con el problema del robo de identidad de la guía de ingeniería social: el factor humano vuelve a ser el punto de partida.

2. El bombardeo de solicitudes push

Con la contraseña, el atacante repite el inicio de sesión de forma automatizada. Cada intento genera una notificación push en la aplicación de la víctima (Microsoft Authenticator, Duo, Okta Verify). Si la plataforma no aplica límites, el usuario recibe una lluvia de avisos indistinguibles. La apuesta es sencilla: basta con que uno coincida con un momento de distracción, prisa o hartazgo.

3. El empujón final por voz o mensaje

Cuando el bombardeo por sí solo no funciona, el atacante añade vishing. Llama o escribe a la víctima haciéndose pasar por el equipo de soporte de IT: "estamos migrando el sistema, por favor acepte la notificación para dejar de recibir alertas". Esa combinación de bombardeo y pretexto de autoridad es exactamente lo que rompió a Uber y a Cisco. El tipo de phishing previo suele ser dirigido y muy convincente.

Casos públicos: Uber, Cisco y 0ktapus

Sin mitificarlos, estos incidentes fijaron el MFA fatigue en la agenda de cualquier equipo de seguridad.

Uber (septiembre de 2022). Un atacante vinculado a Lapsus$ obtuvo las credenciales de un contratista externo, probablemente compradas tras infectar su equipo con un infostealer. Lo bombardeó con solicitudes push y, cuando no cedía, lo contactó por WhatsApp haciéndose pasar por soporte de Uber para pedirle que aceptara. El contratista aprobó una. Ya dentro, el atacante encontró scripts de PowerShell con credenciales de administrador codificadas que le dieron acceso a la solución PAM y, con ella, a secretos de múltiples plataformas internas.

Cisco (mayo de 2022). Un actor de acceso inicial comprometió la cuenta personal de Google de un empleado, donde estaban sincronizadas credenciales corporativas. A continuación combinó vishing con bombardeo de push de Duo hasta que el empleado aceptó una solicitud. El patrón es idéntico al de Uber: contraseña robada más push fatigue más una llamada convincente.

0ktapus y Twilio (agosto de 2022). La campaña que Group-IB bautizó como 0ktapus golpeó a más de 130 organizaciones mediante smishing que suplantaba páginas de acceso de Okta para robar credenciales y códigos. Twilio fue una de las víctimas. El contraste con Cloudflare es la mejor lección: la misma campaña alcanzó a sus empleados, pero fracasó porque su segundo factor eran llaves FIDO2, imposibles de bombardear ni de phishear. El mismo cebo, dos resultados opuestos, y la diferencia fue el tipo de factor.

Cómo frenar el MFA fatigue

La defensa se ordena en capas, de la más rápida de aplicar a la más definitiva:

Emparejamiento de números (number matching)

El emparejamiento de números elimina la aprobación a ciegas. En lugar de un simple "Aprobar o Denegar", la pantalla de inicio de sesión muestra un número de dos dígitos que el usuario debe teclear en su aplicación para confirmar. Como el atacante no ve ese número, el bombardeo deja de funcionar: la víctima no puede aprobar por reflejo. Microsoft lo convirtió en comportamiento por defecto de Authenticator en mayo de 2023; Duo lo ofrece como Verified Push y Okta como number challenge. Es la medida con mejor relación esfuerzo e impacto a corto plazo.

Límite de intentos y bloqueo del push

El bombardeo vive de la ausencia de límites. Configurar un tope de solicitudes por ventana de tiempo, aplicar backoff cuando se acumulan denegaciones y bloquear temporalmente la cuenta tras varias notificaciones ignoradas corta el ataque de raíz. La consola de identidad (Microsoft Entra ID, Okta, Ping) permite estas políticas. Conviene además mostrar contexto en la propia notificación: nombre de la aplicación, ubicación aproximada y dirección IP del intento, para que una solicitud desde otro país resulte obviamente sospechosa.

Acceso condicional y contexto de riesgo

La autenticación basada en riesgo puntúa cada intento según dispositivo, geolocalización, hora y patrón, y bloquea o exige factores adicionales antes de generar ningún push cuando algo no cuadra. Encaja de lleno en una arquitectura Zero Trust, donde ninguna sesión se da por buena solo porque el segundo factor haya dicho que sí.

FIDO2, WebAuthn y passkeys: la solución definitiva

Las capas anteriores reducen el riesgo; FIDO2 lo elimina. Una llave de seguridad hardware (YubiKey, Titan) o una passkey vinculan la credencial al origen real del sitio mediante criptografía de clave pública, la base de la PKI. No hay ninguna notificación de "Aprobar" que bombardear, y la firma solo es válida para el dominio legítimo, así que ni el push fatigue ni el phishing con proxy funcionan. WebAuthn es el estándar del W3C que lo implementa en el navegador y las passkeys son su forma de consumo masivo. Migrar las cuentas privilegiadas a MFA resistente a phishing, empezando por administradores y accesos externos, es la recomendación central de CISA y el cierre real del problema, gobernado desde una estrategia de IAM coherente.

Checklist de prevención

• Activar el emparejamiento de números si aún se usa push simple.
• Limitar las solicitudes push por usuario y ventana de tiempo, con bloqueo tras denegaciones repetidas.
• Mostrar aplicación, ubicación e IP en cada notificación y aplicar acceso condicional basado en riesgo.
• Migrar administradores, cuentas privilegiadas y accesos externos a FIDO2 o passkeys.
• Formar al personal para que denuncie los bombardeos en lugar de aprobarlos y desconfíe de cualquier llamada que pida aceptar una notificación.
• Endurecer el helpdesk y monitorizar los picos de solicitudes MFA denegadas como señal temprana de campaña.

Preguntas frecuentes

¿Qué diferencia hay entre MFA fatigue y push bombing?

Ninguna de fondo: son dos nombres para el mismo ataque. "MFA fatigue" (o fatiga de MFA) pone el acento en el agotamiento del usuario que acaba aprobando; "push bombing" (el término de CISA) y "MFA bombing" lo ponen en la técnica de bombardear con solicitudes. Describen la misma cadena: contraseña robada más avalancha de push hasta la aprobación.

¿El emparejamiento de números detiene el MFA fatigue?

En gran medida, sí. Al obligar a teclear un número que solo aparece en la sesión legítima, elimina la aprobación por reflejo que hace posible el bombardeo. No es infalible frente a un vishing que dicte el número a la víctima, pero eleva mucho el coste y es la mitigación más rápida de desplegar.

¿Por qué FIDO2 es inmune al push bombing?

Porque no hay ninguna notificación que aprobar. FIDO2 y WebAuthn sustituyen el "Aprobar o Denegar" por una firma criptográfica ligada al dominio real del servicio: no se pueden generar solicitudes que la víctima acepte por error y la credencial no funciona en un sitio de phishing. Por eso las llaves FIDO2 frenaron la campaña 0ktapus en Cloudflare.

¿El MFA por SMS protege del MFA fatigue?

El SMS no sufre push bombing porque no envía notificaciones de aprobación, pero es más débil frente a otros vectores, en especial el SIM swapping y el phishing de códigos. Cambiar push por SMS no es una mejora: la vía correcta es FIDO2 o passkeys.

¿A qué cuentas debo migrar primero a MFA resistente a phishing?

A las de mayor impacto: administradores de dominio y de plataformas cloud, accesos remotos de terceros y perfiles con privilegios laterales. Son las que un atacante busca tras el primer compromiso, como demostró Uber, y las que justifican el coste de las llaves o passkeys desde el primer día.

Recursos relacionados

• Qué es ingeniería social: el marco del factor humano que sostiene el MFA fatigue y el pretexto de la llamada de soporte.
• Qué es credential stuffing: la fuente habitual de la contraseña que arranca el bombardeo.
• Qué es vishing: el empujón por voz que remató los casos Uber y Cisco.
• Qué es IAM: dónde se gobierna la política de MFA y de accesos privilegiados.

Defensa frente a MFA fatigue con Secra

En Secra validamos empíricamente la resistencia de tu organización al MFA fatigue: revisamos la configuración del segundo factor (number matching, límites de push, contexto en las notificaciones y acceso condicional), simulamos campañas de bombardeo y vishing en proyectos Red Team para comprobar si la plantilla y el helpdesk resisten, y diseñamos el roadmap de migración a FIDO2 y passkeys empezando por las cuentas privilegiadas. Si todavía confías en push simple o TOTP para tus administradores, escríbenos desde contacto o consulta nuestro servicio de Red Team.