El phishing AiTM (adversary in the middle) es la razón por la que activar la MFA ya no basta para dormir tranquilo. En lugar de robar solo la contraseña, el atacante coloca un proxy inverso entre la víctima y la página de login real, deja que la autenticación se complete de verdad (incluido el segundo factor) y roba la cookie de sesión que emite el proveedor de identidad. Con esa cookie entra en la cuenta sin contraseña y sin volver a pasar la MFA. Importa ahora porque es la técnica que dispara las tomas de cuenta empresariales.
En este artículo explicamos qué es exactamente el phishing AiTM, en qué se diferencia del clásico man in the middle de red, cómo funciona paso a paso el robo de la cookie de sesión, por qué la MFA basada en OTP o push no protege frente a él y qué defensas sí funcionan. Cerramos con detección, respuesta y preguntas frecuentes para que puedas revisar tu propia exposición.
Lo esencial sobre el phishing AiTM
- AiTM es phishing con proxy inverso (por ejemplo, Evilginx): el atacante retransmite el tráfico en tiempo real entre la víctima y el login legítimo.
- La víctima se autentica de verdad, así que la MFA "pasa"; el objetivo real es la cookie de sesión post-autenticación.
- Con la cookie robada, el atacante hace replay en su navegador y entra sin contraseña ni segundo factor.
- La MFA tradicional (OTP, SMS, push) no protege; las credenciales resistentes al phishing (FIDO2 y passkeys) sí, porque están ligadas al origen.
- Microsoft reportó un aumento del 146% en ataques AiTM en 2024 y el auge de plataformas de Phishing como Servicio (PhaaS).
- Las defensas clave son MFA resistente al phishing, token binding, acceso condicional, sesiones cortas y detección de reutilización anómala.
Qué es el phishing AiTM
AiTM significa adversary in the middle, adversario en el medio. Es una evolución del phishing en la que el atacante no se limita a copiar visualmente una página de login para robar credenciales. En su lugar, despliega un proxy inverso que se sitúa entre la víctima y la página de inicio de sesión real del servicio (por ejemplo, el portal de identidad corporativo) y retransmite el tráfico en ambos sentidos en tiempo real.
El resultado es que la víctima ve una página que parece auténtica, con los textos y el comportamiento del servicio real, porque en realidad está interactuando con el servicio legítimo a través del proxy del atacante. La diferencia está en el dominio: la URL y el certificado TLS que ve la víctima son los del atacante, no los del sitio real. Todo lo que la víctima introduce (usuario, contraseña y el segundo factor) viaja hasta el servicio real. La autenticación se completa correctamente. Y ahí está el problema: en el momento en que el proveedor de identidad emite la cookie de sesión post-autenticación, el proxy la intercepta y la exfiltra.
El papel de herramientas como Evilginx
Herramientas de este tipo, como Evilginx, funcionan precisamente como ese proxy inverso de phishing. No falsifican una página estática, sino que reenvían las peticiones al servidor legítimo y capturan los tokens y cookies que se intercambian durante la sesión. Esto explica por qué las campañas AiTM son tan convincentes: la experiencia de la víctima es casi idéntica a la de un login normal (el único indicio suele ser el dominio de la URL), incluida la aparición del prompt de MFA en su teléfono.
El auge de plataformas de Phishing como Servicio (PhaaS) ha bajado la barrera de entrada. Un atacante ya no necesita construir su propia infraestructura de proxy inverso: la alquila. Eso ha industrializado la técnica y ha ampliado el volumen de víctimas potenciales.
En qué se diferencia del man in the middle clásico
Es fácil confundir AiTM con el clásico man in the middle de red, pero no son lo mismo. En el man in the middle tradicional, el atacante se interpone en la capa de red (por ejemplo, en una wifi comprometida o mediante envenenamiento ARP) para interceptar o manipular tráfico entre dos partes que creen comunicarse directamente. El objetivo suele ser espiar o alterar datos en tránsito.
En AiTM el vector es distinto. El atacante no compromete tu red: te lleva mediante ingeniería social a un enlace de phishing que apunta a su proxy. Y el objetivo tampoco es genérico: es específicamente la cookie de sesión que demuestra que ya te has autenticado. Por eso hablamos de un ataque orientado a la identidad y no a la red. Comprender esta diferencia es clave, porque las defensas de red (VPN, cifrado TLS) no detienen un ataque AiTM: el TLS funciona perfectamente entre la víctima y el proxy, y entre el proxy y el servicio real.
Cómo funciona paso a paso el robo de sesión
Veamos el flujo completo para entender por qué la MFA "pasa" y aun así la cuenta cae.
1. El cebo y el enlace
Todo empieza con un correo, un mensaje o un anuncio de phishing que conduce a la víctima a una URL controlada por el atacante. Esa URL es la puerta del proxy inverso. Puede llegar por los mismos canales que cualquier otro de los tipos de phishing que ya conocemos, y a menudo se combina con pretextos urgentes o técnicas como ClickFix con falso CAPTCHA para reducir las sospechas.
2. La retransmisión en tiempo real
Cuando la víctima hace clic, el proxy le sirve la página de login real reenviando su petición al servicio legítimo. La víctima introduce sus credenciales. El proxy las retransmite. El servicio las valida y solicita el segundo factor.
3. La MFA se completa de verdad
La víctima recibe su OTP, su SMS o su notificación push y aprueba la autenticación, porque para ella es un login legítimo. El segundo factor viaja también a través del proxy hasta el servicio real. La MFA se cumple. Este es el punto que desconcierta a muchos equipos: no hay ningún fallo en la MFA, simplemente el atacante ha convertido a la víctima en el operador que la resuelve por él.
4. La captura de la cookie de sesión
Una vez validada la autenticación completa, el proveedor de identidad emite la cookie de sesión post-autenticación, ese token que le dice al servicio "esta persona ya ha demostrado quién es, déjala pasar". El proxy intercepta y exfiltra esa cookie.
5. El replay y la toma de la cuenta
El atacante importa la cookie robada en su propio navegador y hace replay de la sesión. Para el servicio, esa cookie es válida, así que le concede acceso a la cuenta autenticada sin pedir de nuevo contraseña ni segundo factor. La toma de cuenta está completa. A partir de ahí puede leer correo, exfiltrar datos, crear reglas de reenvío o pivotar hacia otras cuentas.
Por qué la MFA tradicional no protege frente a AiTM
Este es el mensaje incómodo pero necesario: la MFA basada en OTP, SMS o push no protege frente a AiTM. La razón es sencilla. Todos esos factores son secretos o aprobaciones que la víctima introduce o concede, y que por tanto pueden retransmitirse a través del proxy. El atacante no necesita conocer tu OTP de antemano; le basta con que tú lo introduzcas en su proxy en el momento justo.
Lo mismo ocurre con las notificaciones push. De hecho, AiTM comparte terreno con otras técnicas de abuso del segundo factor, como el MFA fatigue o push bombing, donde el atacante bombardea a la víctima con aprobaciones hasta que cede. En AiTM ni siquiera hace falta cansar a nadie: la víctima aprueba porque cree que es su propio login.
Por eso, aunque la MFA sigue siendo imprescindible frente a la reutilización de contraseñas y el credential stuffing, no debe considerarse una defensa completa contra el phishing moderno.
Las defensas que sí funcionan
La buena noticia es que existen contramedidas efectivas, y la principal ataca la raíz del problema.
MFA resistente al phishing (FIDO2 y passkeys)
Las credenciales resistentes al phishing, basadas en FIDO2 y WebAuthn, rompen el ataque AiTM en su punto crítico. La clave está en que estas credenciales están ligadas criptográficamente al origen (el dominio real del servicio). Cuando el navegador realiza la autenticación, verifica el origen y firma un reto vinculado a ese dominio. Si la víctima está en el dominio del proxy del atacante, y no en el dominio real, la firma no coincide y la autenticación no se completa. El proxy no puede retransmitir esa credencial porque no puede falsificar el origen.
Esto es lo que convierte a las passkeys en la defensa más sólida disponible. Si quieres profundizar, tenemos guías sobre qué es una passkey, sobre FIDO2, passkeys y WebAuthn y una específica sobre MFA resistente al phishing que explica por qué un proxy no puede retransmitirla.
Token binding y sesiones ligadas al dispositivo
El token binding y las sesiones ligadas al dispositivo atacan la fase de replay. La idea es que la cookie de sesión deje de ser un token portátil que funciona en cualquier navegador. Si la sesión está criptográficamente ligada al dispositivo o al cliente que la originó, una cookie robada y reproducida desde el navegador del atacante deja de ser válida, porque no procede del mismo dispositivo.
Acceso condicional
Las políticas de acceso condicional añaden contexto a la decisión de autorización. Pueden exigir dispositivos gestionados y conformes, restringir accesos por ubicación o red, o forzar reautenticación ante señales de riesgo. Un acceso condicional bien diseñado puede bloquear un replay que provenga de un dispositivo desconocido o de una geografía inesperada.
Vida de sesión corta y revocación
Reducir la vida de la sesión y disponer de mecanismos de revocación ágiles limita la ventana de oportunidad del atacante. Cuanto antes caduque la cookie robada y cuanto más rápido puedas revocar sesiones activas ante una sospecha, menor será el daño. La revocación debe ser un botón real y ensayado, no una casilla teórica.
Detección y respuesta
Ninguna defensa es infalible, así que la detección de reutilización anómala de sesión es imprescindible. Las señales más útiles son las clásicas del análisis de riesgo de identidad: viaje imposible (la misma sesión activa en dos geografías incompatibles en poco tiempo), aparición de un dispositivo nuevo o desconocido, cambios bruscos de dirección IP o de agente de usuario, y la creación de reglas de reenvío de correo justo después de un login.
Estas capacidades encajan de lleno en una estrategia de detección y respuesta a amenazas de identidad. Si tu organización aún no ha formalizado esa capa, merece la pena entender qué es ITDR y cómo se integra con el resto de tu telemetría de seguridad.
El componente humano
Conviene recordar que muchas campañas de toma de cuenta combinan AiTM con ingeniería social dirigida. Grupos como los que se agrupan bajo el paraguas de Scattered Spider han demostrado lo eficaz que resulta atacar al help desk y a las personas para conseguir el acceso inicial o el restablecimiento de factores. La tecnología resistente al phishing reduce la superficie, pero la formación y los procesos de verificación de identidad en soporte siguen siendo decisivos.
Cómo revisar tu exposición
Un ejercicio práctico consiste en preguntarse: si un empleado introdujera sus credenciales y su segundo factor en un proxy AiTM ahora mismo, ¿qué lo detendría? Si la respuesta es "nada hasta que alguien note actividad rara", la organización depende por completo de la detección reactiva. El objetivo es mover esa respuesta hacia la prevención: credenciales ligadas al origen, sesiones ligadas al dispositivo y acceso condicional que no confíe ciegamente en una cookie.
Auditar esto de forma realista requiere simular el ataque, no solo revisar la configuración sobre el papel. Una campaña de phishing controlada que incluya un proxy AiTM revela qué usuarios muerden el anzuelo, qué factores resisten y qué sesiones pueden reproducirse. Es la diferencia entre suponer que estás protegido y demostrarlo.
Preguntas frecuentes
¿La MFA sirve para algo si AiTM la salta?
Sí, sigue siendo necesaria. La MFA tradicional detiene la reutilización de contraseñas, el relleno de credenciales y el phishing básico. Lo que no hace es proteger frente a AiTM, porque el atacante retransmite el segundo factor en tiempo real. La conclusión no es desactivar la MFA, sino migrar a MFA resistente al phishing basada en FIDO2 y passkeys.
¿Por qué las passkeys sí resisten a AiTM?
Porque están ligadas criptográficamente al origen. El navegador solo completa la autenticación si el dominio coincide con el que se registró la credencial. Como el proxy del atacante usa un dominio distinto, la firma no es válida y no puede retransmitirse. El proxy no puede falsificar el origen, así que el ataque se rompe en su punto crítico.
¿En qué se diferencia AiTM de un man in the middle de red?
El man in the middle clásico se interpone en la capa de red para espiar o alterar tráfico. AiTM no compromete la red: usa un proxy inverso de phishing al que llega la víctima por ingeniería social, y su objetivo específico es robar la cookie de sesión post-autenticación para hacer replay. El TLS no lo detiene, porque funciona correctamente en ambos tramos.
¿Cómo detecto que una sesión ha sido robada por AiTM?
Buscando reutilización anómala de sesión: viaje imposible, dispositivos nuevos o desconocidos, cambios inesperados de IP o de agente de usuario y acciones sospechosas justo tras el login, como la creación de reglas de reenvío de correo. Estas señales son el núcleo de una capacidad de ITDR.
¿Es AiTM lo mismo que el MFA fatigue?
No, aunque ambos abusan del segundo factor. En el MFA fatigue o push bombing el atacante bombardea a la víctima con notificaciones hasta que aprueba una por error. En AiTM la víctima aprueba porque cree que está en su login legítimo, y el foco no es la aprobación sino la captura y el replay de la cookie de sesión.
¿Qué es lo primero que debería implementar?
MFA resistente al phishing (FIDO2 y passkeys) para las cuentas privilegiadas y de mayor riesgo, junto con acceso condicional que exija dispositivos gestionados. Después, sesiones cortas, token binding y detección de reutilización anómala. Esa combinación ataca a la vez la fase de captura y la de replay.
Recursos relacionados
- MFA resistente al phishing
- Qué es un ataque man in the middle
- Qué es una passkey
- FIDO2, passkeys y WebAuthn
- Tipos de phishing
- MFA fatigue y push bombing
- ClickFix y falso CAPTCHA
- Qué es ITDR
- Scattered Spider e ingeniería social al help desk
Pon a prueba tu resistencia al phishing AiTM
Secra es una empresa de ciberseguridad ofensiva con programa propio de investigación de vulnerabilidades. Hemos publicado CVE reales, como CVE-2025-40652 en CoverManager y CVE-2023-3512 en Setelsa ConacWin CB, ambos en la NVD y en INCIBE-CERT. Esa misma mentalidad ofensiva la aplicamos a auditar tu exposición real frente a AiTM: campañas de phishing controladas con proxy inverso, revisión de tu MFA y tu acceso condicional, y validación de si una cookie de sesión robada podría reproducirse en tu entorno.
Si quieres saber qué pasaría de verdad si tus empleados cayeran en un proxy AiTM, ponte en contacto con nosotros y te ayudamos a comprobarlo antes de que lo haga un atacante.
Sobre el autor
Equipo de Secra Solutions
Ethical hackers certificados OSCP, OSEP, OSWE, CRTO, CRTL y CARTE, con más de 7 años de experiencia en ciberseguridad ofensiva. Autores de los CVE-2025-40652 y CVE-2023-3512.