Durante años, el doble factor (MFA) se vendió como la solución definitiva contra el robo de credenciales: activa el MFA y el phishing pasa a ser un problema manejable. Esa premisa ya no se sostiene. La técnica de phishing dominante en 2025 y 2026 contra Microsoft 365, Google Workspace y Okta no intenta romper el MFA: deja que el usuario se autentique correctamente y luego roba el resultado. Se llama phishing AiTM (adversario en el medio), y conviene entenderlo bien.
Este artículo es de concienciación y defensa. Explica qué es el AiTM, cómo funciona a alto nivel, por qué el MFA clásico no lo detiene, en qué se diferencia del phishing de código de dispositivo que ha explotado en 2026 y, sobre todo, cómo detectarlo, defenderse y responder si ya ha ocurrido. No incluye instrucciones para montarlo ni ejecutarlo.
- Qué es el phishing AiTM
- El ataque en cinco fases
- Por qué el MFA clásico no lo para
- Tres formas de robar una sesión
- El frente de 2026: phishing de código de dispositivo
- Robo de token sin phishing: infostealers
- La escala del problema: phishing como servicio
- Cómo detectar un ataque AiTM
- Cómo defenderse de verdad
- Qué hacer si ya te ha pasado
- Preguntas frecuentes
Qué es el phishing AiTM
El AiTM (adversary-in-the-middle, adversario en el medio) es una técnica de phishing que usa un proxy inverso para interceptar credenciales y tokens de sesión en tiempo real. El atacante coloca un servidor entre la víctima y la página de login legítima: la víctima ve lo que parece el login real (porque, de hecho, lo es, retransmitido), introduce sus datos y completa el MFA. El proxy captura la cookie de sesión que el sitio legítimo emite al final, y la reproduce para entrar como la víctima.
La diferencia con el phishing de toda la vida es importante. El phishing clásico crea una página falsa, te roba el usuario y la contraseña y se acaba ahí; si tienes MFA, el atacante se queda fuera. El AiTM no se conforma con la contraseña: se queda con la sesión ya autenticada, que es justo lo que el MFA estaba protegiendo. En el marco MITRE ATT&CK esto cae bajo las técnicas T1557 (adversario en el medio) y T1539 (robo de cookie de sesión web).
El ataque en cinco fases
# Las 5 fases de un ataque AiTM (visión defensiva) Fase 1 Señuelo: la víctima hace clic en un enlace de phishing Fase 2 Proxy inverso: aterriza en un servidor que reenvía al login real Fase 3 Captura: introduce usuario y contraseña; el proxy los relaya y los copia Fase 4 Relay de MFA: aprueba el doble factor, que el proxy reenvía al sitio real Fase 5 Robo de cookie: el sitio real emite la cookie de sesión y el proxy la roba → el atacante importa la cookie y entra sin contraseña ni MFA
El detalle clave está en la fase 5: lo que se roba no es la contraseña, es la cookie de sesión, el testigo que demuestra que la autenticación (incluido el MFA) ya se completó con éxito. Con esa cookie en su navegador, el atacante tiene una sesión autenticada y no se le vuelve a pedir nada. Tampoco necesita la contraseña: la sesión ya está abierta.
Por qué el MFA clásico no lo para
Aquí está el cambio de mentalidad. El MFA basado en SMS, TOTP o notificaciones push protege el momento del login. Pero en un ataque AiTM la víctima completa un flujo de autenticación totalmente legítimo: introduce el código real, aprueba el push real. El MFA hace su trabajo. El problema es que el atacante no ataca el login, sino lo que viene después: el token que prueba que el login fue bueno. No puedes detener algo que ni siquiera llega a activarse.
El dato lo respalda la telemetría de respuesta a incidentes. Cisco Talos reportó que, en el primer trimestre de 2024, casi la mitad de los incidentes a los que respondió tenían relación con el MFA (push fraudulentos aceptados por el usuario e implementaciones deficientes), y que en el conjunto del año la identidad estuvo implicada en alrededor del 60 por ciento de los casos. El MFA dejó de ser una casilla que se marca y se olvida.
Tres formas de robar una sesión, un mismo resultado
El AiTM con proxy inverso es la variante más conocida, pero no es la única vía para acabar dentro de una cuenta sin romper el MFA. Conviene distinguirlas porque no se defienden igual, y este es el error más común: aplicar la defensa correcta a la variante equivocada.
| Técnica | Cómo funciona | Qué defensa la corta |
|---|---|---|
| AiTM (proxy inverso) Evilginx, Tycoon 2FA, EvilProxy, Mamba 2FA, Sneaky 2FA |
Un dominio de phishing retransmite el login real y captura la cookie de sesión emitida al final. | FIDO2 / passkeys. La credencial está ligada al origen y no firma para el dominio falso. |
| Phishing de código de dispositivo Storm-2372, EvilTokens, Kali365 |
El atacante inicia un flujo de código de dispositivo de OAuth y convence a la víctima de teclear el código en la página real de Microsoft. El dispositivo del atacante recibe los tokens. | Acceso condicional que bloquee el flujo de código de dispositivo donde no se use. Las passkeys aquí no bastan: la víctima se autentica en el origen legítimo. |
| Robo de token con infostealer Familias de malware ladrón de credenciales |
Malware en el equipo de la víctima vuelca cookies y tokens de sesiones ya autenticadas. No hay login ni MFA. | Tokens ligados al dispositivo (token protection), EDR y vidas de sesión cortas. |
El frente de 2026: el phishing de código de dispositivo
Si el AiTM con proxy inverso fue la gran historia de 2024 y 2025, la variante que se ha disparado en 2026 es el phishing de código de dispositivo (device code phishing). El flujo de código de dispositivo de OAuth existe para que aparatos sin teclado cómodo (televisores, impresoras, consolas) puedan autenticarse: el dispositivo muestra un código corto y tú lo introduces en una página web desde el móvil o el ordenador.
El abuso es elegante por lo simple: el atacante arranca ese flujo y hace llegar a la víctima un correo que la invita a entrar en una página real de Microsoft e introducir un código. Como la página es auténtica, el MFA se completa sin sospecha y, al terminar, quien recibe los tokens de acceso no es la víctima, sino el dispositivo del atacante. No hay dominio falso ni proxy: solo un flujo legítimo usado en tu contra.
Microsoft rastreó una campaña a gran escala con esta técnica a principios de 2025 (grupo Storm-2372). En 2026 se ha industrializado con plataformas como EvilTokens y Kali365. Esta última fue objeto de una alerta del FBI (PSA del 21 de mayo de 2026) por secuestrar cuentas de Microsoft 365 robando tokens OAuth sin tocar la contraseña, distribuida por Telegram desde unos 250 dólares al mes. Las detecciones de esta técnica se multiplicaron de forma drástica a comienzos de 2026, con múltiples kits compitiendo en el mercado.
Robo de token sin phishing: los infostealers
Existe una vía todavía más directa que ni siquiera necesita una página falsa: el robo de token con malware. Los llamados infostealers recolectan las cookies y los tokens del navegador, que representan sesiones ya autenticadas. El atacante importa esa cookie, se salta la página de login por completo, y el MFA nunca se dispara, porque no hay login que proteger.
Es la misma idea de fondo que el AiTM (lo valioso es el token, no la contraseña), pero por una puerta distinta. Por eso un buen EDR y la higiene del endpoint forman parte de la defensa anti-AiTM aunque parezca que no tienen nada que ver con el phishing: si el equipo está limpio, no hay cookies que volcar.
La escala del problema: phishing como servicio
Esto no es artesanal: está industrializado. Existe todo un mercado de phishing como servicio (PhaaS). Conviene separar dos cosas que a menudo se mezclan: por un lado, frameworks de código abierto como Evilginx, que cualquiera puede descargar; por otro, kits comerciales que se alquilan por suscripción, como Tycoon 2FA, EvilProxy, Sneaky 2FA o Mamba 2FA, y los más recientes orientados a código de dispositivo como EvilTokens y Kali365.
El precio de entrada es bajo, en algunos casos por debajo de los 300 dólares al mes, y la sofisticación alta: paneles con seguimiento de víctimas en tiempo real, plantillas de campaña y señuelos generados con IA. El AiTM y sus primos son atractivos para el atacante precisamente porque no requieren la investigación ni el tiempo de un SIM swap o de engañar a una mesa de ayuda: el kit hace el trabajo pesado.
Cómo detectar un ataque AiTM
Aunque el ataque sea sigiloso, deja rastros si sabes dónde mirar. La señal más fiable es la misma sesión usada desde dos contextos incompatibles:
# Señal de detección: misma sesión, dos contextos (registro de acceso) 2026-06-15 09:41:22 [email protected] ip=198.51.100.23 ua="Windows NT 10.0; Edge" geo=Madrid,ES action=login_ok 2026-06-15 09:43:05 [email protected] ip=203.0.113.77 ua="X11; Linux x86_64" geo=Amsterdam,NL action=mailbox_read → misma cuenta, +1500 km en 2 min, User-Agent distinto: viaje imposible + reúso de sesión
Las señales que conviene vigilar:
- Viaje imposible: la misma cuenta iniciando sesión desde dos ubicaciones geográficas incompatibles en poco tiempo.
- Misma cookie, distinto contexto: la misma cookie o token de sesión usado desde dos User-Agent o dos direcciones IP distintas (la de la víctima y la del atacante). Eso es visible en los registros.
- Anomalías de sesión: sesiones que aparecen sin un evento de login coherente que las preceda.
- Eventos de código de dispositivo inesperados: autenticaciones por device code que la víctima no inició, sobre todo desde IP de hosting o cloud.
- Consentimientos OAuth sospechosos: aplicaciones recién registradas o concesiones de permisos amplios que nadie recuerda haber autorizado.
Cómo defenderse de verdad
La defensa eficaz no es "más MFA", es el MFA resistente al phishing combinado con políticas que limiten el valor de un token robado:
- FIDO2 / WebAuthn y passkeys: es la defensa que de verdad neutraliza el AiTM de proxy inverso. Estas credenciales están ligadas al origen (origin-bound): la firma criptográfica solo funciona en el dominio legítimo. Si la víctima está en un dominio de phishing, el navegador detecta que no coincide y se niega a firmar. El proxy se queda sin nada que robar.
- Bloquear el flujo de código de dispositivo por acceso condicional allí donde no se use. Es la única defensa real contra la variante de device code, que las passkeys no cubren.
- Acceso condicional: exigir dispositivo gestionado o conforme, no solo credenciales válidas.
- Tokens ligados al dispositivo (token protection) y vidas de sesión cortas, para que una cookie robada caduque pronto o no sirva en otra máquina.
- Evaluación de acceso continuo (CAE): revoca tokens casi en tiempo real ante cambios de riesgo, en lugar de esperar a que caduquen.
- Monitorización de viaje imposible, tokens anómalos y consentimientos OAuth.
- Concienciación: ningún login legítimo llega por un enlace inesperado con urgencia, y nadie debería pedirte que introduzcas un código que no has solicitado.
Qué hacer si ya te ha pasado
Aquí se cometen los errores más caros. La reacción instintiva ante una cuenta comprometida es cambiar la contraseña, y eso por sí solo no expulsa al atacante. El token robado, y sobre todo el token de refresco, sigue siendo válido hasta que caduca o se revoca de forma explícita. Hay incidentes en los que el atacante mantuvo el acceso después de un reseteo de contraseña precisamente por esto.
El orden correcto de actuación:
- Revocar todas las sesiones y tokens de la cuenta afectada, no solo cambiar la contraseña.
- Revisar y retirar consentimientos OAuth y aplicaciones registradas que no reconozcas.
- Comprobar reglas de buzón y reenvíos automáticos: una acción habitual tras el robo es crear reglas que oculten o reenvíen correos.
- Restablecer la contraseña y, si es posible, migrar la cuenta a passkeys.
- Buscar movimiento lateral: un token robado suele ser el principio, no el final.
Preguntas frecuentes
¿El AiTM significa que el MFA es inútil?
No. El MFA sigue bloqueando la mayoría de los ataques y desactivarlo sería un error grave. Lo que demuestra el AiTM es que el MFA clásico (SMS, TOTP, push) ya no es suficiente por sí solo y que hay que migrar al MFA resistente al phishing.
¿Qué es exactamente lo que roba el atacante en un ataque AiTM?
La cookie o token de sesión, no la contraseña. Ese token prueba que la autenticación (incluido el MFA) se completó, así que con él el atacante entra sin que se le pida nada más.
¿Por qué las passkeys frenan el AiTM?
Porque están ligadas al origen: la credencial solo firma para el dominio legítimo. En un dominio de phishing, el navegador detecta que no coincide y se niega, así que el proxy no obtiene nada reutilizable.
¿Las passkeys me protegen del todo?
Frenan el AiTM de proxy inverso, pero no el phishing de código de dispositivo, porque en esa variante la víctima se autentica en la página real del proveedor. Para esa vía la defensa es el acceso condicional que bloquee el flujo de código de dispositivo donde no se use.
¿Qué diferencia hay entre AiTM y phishing de código de dispositivo?
El AiTM usa un proxy inverso y un dominio falso que retransmite el login real para robar la cookie. El phishing de código de dispositivo no usa dominio falso: abusa de un flujo legítimo de OAuth y engaña a la víctima para que autorice el dispositivo del atacante en la página auténtica.
¿Cómo detecto si me ha pasado?
Busca señales como viajes imposibles, una misma cookie de sesión usada desde dos User-Agent o IP distintas, sesiones sin un login coherente y eventos de código de dispositivo o consentimientos OAuth que no reconozcas. Los registros de acceso son tu mejor aliado.
¿Si cambio la contraseña, echo al atacante?
No necesariamente. El token de sesión robado sigue válido hasta que caduca o se revoca. Tras un incidente hay que revocar sesiones y tokens, retirar consentimientos OAuth y revisar reglas de buzón, además de cambiar la contraseña.
Referencias
- MITRE ATT&CK T1557: adversario en el medio.
- MITRE ATT&CK T1539: robo de cookie de sesión web.
- FBI / IC3: alerta sobre el kit Kali365 y el robo de tokens de Microsoft 365 (21 de mayo de 2026).
- CISA: guía sobre MFA resistente al phishing.
- FIDO Alliance: passkeys y autenticación resistente al phishing.