Fatiga de MFA y secuestro de sesión: los ataques que vencen al 2FA

Activaron el 2FA y le dijeron al consejo que el riesgo estaba cubierto. No lo estaba. Los atacantes dejaron de pelear contra la pantalla de inicio de sesión y aprendieron a saltársela. La contraseña sigue importando, pero las dos técnicas que hoy más éxito tienen, la fatiga de MFA y el secuestro de sesión, tratan el segundo factor como un badén, no como un muro.

Por qué el 2FA dejó de ser suficiente

El phishing clásico roba una contraseña. El MFA fue la respuesta: aunque el atacante tenga la contraseña, le falta el segundo factor. Esa lógica se sostuvo hasta que los atacantes cambiaron de objetivo.

Dos cambios rompieron el modelo:

• El humano se cansó. El MFA por notificación push le pide a una persona que apruebe. Y las personas aprueban cosas todo el día. Los atacantes aprendieron a convertir ese reflejo en un arma.
• La sesión se convirtió en el botín. Cuando ustedes se autentican, el servidor le entrega al navegador un token de sesión. Ese token, y no la contraseña, es lo que demuestra su identidad en cada petición posterior al login. Quien roba el token se salta la contraseña, el aviso de MFA, todo.

Ambos ataques comparten una misma causa raíz: la autenticación es un evento, pero el acceso es un estado. Invertimos muchísimo en el evento y casi nada en el estado, que sobrevive durante horas o días. Si quieren la versión completa de este argumento, lean nuestro análisis sobre arquitectura Zero Trust. La versión corta: nunca confíen en una sesión solo porque un login salió bien alguna vez.

Fatiga de MFA, también conocida como push bombing

La mecánica es tan simple como eficaz. El atacante ya tiene la contraseña (de una filtración, de un kit de phishing o de un infostealer). Inicia sesión. El teléfono de la víctima se ilumina con una solicitud de aprobación. Vuelve a iniciar sesión. Y otra vez. Diez avisos. Cincuenta avisos. A las dos de la madrugada.

Tarde o temprano ocurre una de estas tres cosas:

1. El usuario pulsa aprobar para que el ruido pare.
2. El usuario asume que el equipo de TI está haciendo mantenimiento y aprueba.
3. El atacante llama por teléfono, se hace pasar por soporte técnico y guía al usuario paso a paso.

Ese es todo el ataque. Sin zero-days, sin malware. Funciona porque un push plano de "Aprobar / Rechazar" no aporta contexto y aceptarlo no le cuesta nada al usuario.

Medidas que sí cambian las probabilidades

• Emparejamiento de números (number matching). La pantalla de login muestra un número de dos dígitos que el usuario debe teclear en la app. Un atacante que no ve esa pantalla no puede aportar el número. Esto, por sí solo, elimina la aprobación a ciegas.
• Contexto en el aviso. Muestren ubicación, aplicación e IP. "Inicio de sesión desde Yakarta en su aplicación de nóminas" es mucho más difícil de aprobar por descuido que un botón vacío.
• Límite de intentos y bloqueo ante avisos repetidos. Tres solicitudes rechazadas o ignoradas en una ventana corta deberían congelar los nuevos avisos y alertar al SOC. El push bombing es ruidoso por naturaleza. Detecten el volumen.
• Abandonar el push por completo en las cuentas de alto valor. El emparejamiento de números es un parche. Los factores resistentes al phishing son la cura (más abajo).

El emparejamiento de números ya es el valor por defecto en la mayoría de las plataformas de identidad. Actívenlo. Si su proveedor todavía permite el aprobar/rechazar simple para usuarios con privilegios, eso es un hallazgo de auditoría, no una preferencia.

Secuestro de sesión: robar el token y saltarse el login

Esta es la familia más peligrosa, porque derrota incluso a un MFA bien configurado. Hasta el login más perfecto, con número emparejado y todo, termina emitiendo un token de sesión. Si el atacante consigue ese token, su MFA nunca llega a opinar.

Hay tres caminos habituales hacia el token.

1. Phishing de adversario en el medio (AiTM)

Esta es la técnica detrás de la mayoría de los bypass de MFA modernos. El atacante coloca un proxy inverso (Evilginx y kits similares lo convirtieron en algo de apuntar y disparar) entre la víctima y el sitio real.

El flujo:

1. La víctima hace clic en un enlace de phishing y aterriza en el proxy del atacante, que se ve idéntico al original porque literalmente está retransmitiendo el sitio real.
2. La víctima escribe la contraseña. El proxy la reenvía al sitio real.
3. El sitio real envía el desafío de MFA. La víctima lo completa. Emparejamiento de números, TOTP, SMS: todo se satisface, porque hay un humano real iniciando sesión de verdad.
4. El sitio real emite una cookie de sesión válida. El proxy la captura en tránsito.
5. El atacante importa la cookie en su propio navegador y ya está dentro, plenamente autenticado, con el MFA ya superado.

La víctima hizo todo bien y aun así perdió. Por eso "tenemos MFA" no responde a la pregunta "¿somos resistentes al phishing?".

2. Malware infostealer y robo de cookies

No hace falta un proxy si se puede leer el disco de la víctima. Los infostealers (RedLine, Lumma y el resto del mercado) extraen los almacenes de cookies del navegador, los tokens guardados y los archivos de sesión locales, y luego los venden. El comprador carga su sesión activa y entra caminando. Sin contraseña, sin MFA, porque el token ya está emitido.

Por eso un endpoint comprometido es una identidad comprometida. No son dos incidentes separados.

3. Robo de tokens en flujos OAuth y de API

Los refresh tokens de larga vida y las aplicaciones OAuth mal configuradas son una mina de oro silenciosa. Un refresh token robado puede emitir nuevos access tokens durante semanas. Los tokens con permisos excesivos convierten una fuga en acceso a todo el tenant. Si su plataforma emite tokens a integraciones de terceros, algo habitual en cualquier fintech o SaaS de América Latina que se conecta con pasarelas de pago y servicios locales, cada uno de esos tokens es una credencial que quizá no están rotando. Profundizamos en alcances y rotación en buenas prácticas de seguridad de APIs.

La defensa que de verdad aguanta: MFA resistente al phishing

Aquí viene la verdad incómoda. El emparejamiento de números ayuda contra la fatiga. Contra el AiTM no sirve de nada, porque el humano sigue entregando una credencial real a un sitio real a través de un proxy. Para vencer al AiTM se necesita un factor vinculado al origen que no se pueda retransmitir.

Ese factor es FIDO2 / WebAuthn, materializado en passkeys o llaves de seguridad físicas.

Por qué resiste el AiTM: el autenticador firma un desafío que incluye el origen (el dominio real). Un proxy en un dominio parecido produce un origen incorrecto, así que la firma no valida. No hay código que phishear ni cookie que el humano pueda ser engañado para reenviar. La criptografía se niega a funcionar fuera del dominio legítimo.

Si van a leer un solo artículo complementario, que sea passkeys y autenticación sin contraseñas. Para administradores, finanzas y cualquiera con acceso a producción, el MFA resistente al phishing debería ser obligatorio, no opcional.

Orden de prioridad por robustez del MFA:
  1. FIDO2 / passkeys / llaves físicas    (resistente al phishing, vence al AiTM)
  2. Push con número emparejado + contexto (vence a la fatiga, no al AiTM)
  3. Apps de autenticación TOTP            (phisheable vía proxy)
  4. OTP por SMS / voz                     (phisheable + riesgo de SIM swapping)

No desplieguen solo el nivel superior. Despliéguenlo primero en las cuentas que, de ser comprometidas, acabarían con su trimestre.

Proteger la sesión en sí

El MFA resistente al phishing protege el login. Todavía hay que proteger el token después de emitido, porque el malware y las malas configuraciones pueden capturarlo directamente.

Vincular el token al dispositivo

El control más fuerte es el token binding: atar criptográficamente la sesión al dispositivo que se autenticó, de modo que una cookie robada sea inútil en otra máquina. Dos mecanismos que conviene conocer:

• DPoP (Demonstrating Proof of Possession) para OAuth. El cliente demuestra en cada petición que posee una clave privada. Un token copiado sin la clave llega muerto.

POST /api/orders HTTP/1.1
Authorization: DPoP eyJ...access_token...
DPoP: eyJ...signed_proof_bound_to_request_and_key...

• Sesiones vinculadas al dispositivo en la capa del navegador. Estándares emergentes (comercializados a menudo como device bound session credentials) refrescan las cookies con una clave que reside en el dispositivo, de forma que una cookie exfiltrada caduca rápido y no puede reutilizarse en otro sitio.

Endurecer las cookies, la parte aburrida

La mayoría de los robos de sesión explotan un manejo descuidado de cookies. Los valores por defecto importan:

Set-Cookie: session=...;
  HttpOnly;          // JavaScript no puede leerla, frena el robo vía XSS
  Secure;            // nunca viaja por HTTP sin cifrar
  SameSite=Lax;      // limita el envío cross-site, reduce el CSRF
  Path=/;
  Max-Age=3600       // vida corta, radio de impacto pequeño

HttpOnly por sí solo detiene una clase enorme de exfiltración de cookies mediante cross-site scripting. Si su cookie de sesión es legible desde JavaScript, arreglen eso antes que cualquier otra cosa de esta página.

Acortar lo que un token robado puede hacer

• Access tokens de vida corta. Minutos, no horas. Fuercen la revalidación frecuente.
• Rotación de refresh tokens con detección de reutilización. Cada refresh emite un token nuevo e invalida el anterior. Si un token viejo reaparece, eso es un robo: maten toda la familia de sesiones.
• Alcance acotado por token. Mínimo privilegio para cada token. Un token de solo lectura filtrado es un incidente. Un token todopoderoso filtrado es una brecha.

Detectar el secuestro que no pudieron prevenir

Asuman que algún token se escapará. Su trabajo es hacer que su vida sea corta y ruidosa.

• Evaluación continua de acceso (CAE). En lugar de confiar en un token hasta que caduque, se reevalúan las condiciones casi en tiempo real. Contraseña restablecida, cuenta deshabilitada, ubicación de riesgo: revoquen a mitad de sesión, no a la hora siguiente.
• Viajes imposibles y anomalías de dispositivo. Una sesión en Madrid a las 14:00 y otra en Manila a las 14:10 no es alguien que va al trabajo. Márquenla, exijan un factor adicional o mátenla.
• Deriva de user agent y de IP dentro de una sesión. Un token que salta de la huella de un portátil corporativo a una VM aleatoria en la nube está robado. Alerten sobre el cambio.
• Registren el ciclo de vida de la sesión, no solo los logins. La emisión, el refresco y la revocación de tokens pertenecen a su telemetría. No se puede investigar lo que nunca se registró. Complementen esto con la visión amplia de observabilidad: logs, métricas y trazas.

Cuando salte una alerta, necesitan una respuesta ensayada: revocar sesiones, rotar tokens y forzar una nueva inscripción con factores resistentes al phishing. Ténganla por escrito antes de necesitarla. Y recuerden el frente regulatorio: en España, un secuestro de sesión que expone datos personales es una brecha notificable a la AEPD en 72 horas bajo el RGPD, y buena parte de América Latina (México, Colombia, Argentina) impone obligaciones equivalentes. Nuestro manual de respuesta a incidentes cubre los pasos de revocación de tokens que la mayoría de los equipos olvida hasta las tres de la madrugada.

Un marco de decisión aplicable este trimestre

No se puede hacer todo a la vez. Prioricen por radio de impacto.

1. Inventaríen el acceso privilegiado. Administradores, finanzas, producción y cualquiera que pueda mover dinero o datos. Ese es su nivel uno.
2. Impongan MFA resistente al phishing en el nivel uno. Passkeys o llaves físicas. Sin excepciones, sin TOTP de respaldo para esas cuentas.
3. Activen el emparejamiento de números y el contexto en el aviso para todos los demás. Ese es su parche contra la fatiga para la población general.
4. Conviertan la higiene de cookies y tokens en política. HttpOnly, Secure, SameSite, vidas cortas, rotación de refresh tokens con detección de reutilización. Verifíquenlo en la revisión de código, no en una wiki.
5. Habiliten CAE y la detección de anomalías de sesión. Dejen de confiar en los tokens durante toda su vida útil.
6. Ensayen la revocación. Hagan un ejercicio de mesa donde se roba un token. Cronometren cuánto tardan en matar todas las sesiones. Si no conocen esa cifra, esa cifra es el hallazgo.

El patrón: prevenir lo que se pueda con criptografía y contener lo que no con sesiones de vida corta, vinculadas y revocables.

Lista rápida de autoevaluación

• Las cuentas privilegiadas usan FIDO2 / passkeys, no push ni TOTP.
• El emparejamiento de números y el contexto de inicio de sesión están activos para todos los usuarios.
• Las cookies de sesión son HttpOnly, Secure y SameSite.
• Los access tokens caducan en minutos; los refresh tokens rotan.
• La reutilización de un refresh token dispara la revocación completa de la sesión.
• El token binding (DPoP o sesiones vinculadas al dispositivo) está implantado en las APIs sensibles.
• CAE o un equivalente revoca sesiones ante eventos de riesgo a mitad de sesión.
• La emisión, el refresco y la revocación de sesiones se registran y generan alertas.
• Han cronometrado un simulacro real de revocación de sesiones en los últimos 90 días.

Si quieren saber cómo aguantan estos controles frente a un operador real, eso es exactamente lo que prueba un ejercicio serio. Vean introducción al pentesting para entender cómo se ejercita de principio a fin un escenario de AiTM y robo de tokens.

Cómo puede ayudar Innovation T

Construimos y endurecemos la capa de autenticación que los equipos realmente ponen en producción: despliegues de passkeys, MFA resistente al phishing para el acceso privilegiado, token binding, rotación de refresh tokens y detección de anomalías de sesión conectada a su logging. Nada de diapositivas. Controles funcionando, probados contra los ataques exactos que acabamos de describir.

Si su 2FA está a un proxy convincente de distancia de una toma completa de sesión, permítannos ponerlo a prueba y cerrar la brecha. Consulten nuestros servicios o contacten al equipo y trazaremos su camino más rápido de "tenemos MFA" a "somos resistentes al phishing".