El AiTM phishing —Adversary in the Middle— es la técnica que permite a un atacante colocarse entre tú y la web legítima de tu banco, tu correo o tu Microsoft 365, robarte la sesión autenticada y saltarse el segundo factor como si no existiera. No es ciencia ficción: herramientas como Evilginx automatizan el montaje de un proxy inverso phishing en minutos. El resultado es un robo de sesión en tiempo real, con cookie incluida, mientras tú ves exactamente la página que esperabas ver. Y tu MFA, esa capa extra que te prometieron infalible, no sirve de nada.
Si creías que activar la verificación en dos pasos te blindaba contra el phishing, sigue leyendo. Esto te interesa.
Cómo funciona un ataque AiTM paso a paso
El concepto es elegante en su maldad. El atacante levanta un servidor que actúa como intermediario —un proxy inverso— entre la víctima y el servicio real. Cuando accedes al enlace de phishing, no ves una copia estática mal hecha: ves la web auténtica, servida a través del servidor del atacante.
El flujo es este:
- Recibes un email con un enlace que apunta al dominio del atacante (algo como
login-micros0ft.com). - Tu navegador se conecta al proxy del atacante, que a su vez se conecta al servidor legítimo de Microsoft.
- Introduces tu usuario y contraseña. El proxy los reenvía al servidor real.
- Microsoft te pide el segundo factor. Lo introduces. El proxy lo reenvía también.
- Microsoft valida todo y emite una cookie de sesión. El proxy la captura antes de reenviártela.
- Tú entras a tu cuenta normalmente. El atacante ya tiene tu cookie.
Con esa cookie, el atacante abre un navegador, la inyecta, y tiene acceso completo a tu cuenta sin necesitar tu contraseña ni tu código MFA. La sesión ya está autenticada. Fin del juego.
Esto es lo que diferencia al adversary in the middle del phishing clásico: no necesita que la víctima entregue credenciales en una página falsa. La página es real. El robo ocurre en tránsito.
Evilginx y el arsenal de proxies inversos
Hablar de proxy inverso phishing sin mencionar Evilginx sería como hablar de ransomware sin mencionar WannaCry. Desarrollada originalmente por Kuba Gretzky como herramienta de investigación, Evilginx es un framework de código abierto que automatiza ataques AiTM contra prácticamente cualquier servicio web.
Funciona sobre Nginx (de ahí el nombre) y permite crear phishlets: archivos de configuración que definen cómo interceptar el flujo de autenticación de un servicio concreto. Hay phishlets públicos para Microsoft 365, Google Workspace, Okta, LinkedIn y decenas más.
Pero Evilginx no está solo. El ecosistema incluye:
| Herramienta | Tipo | Objetivo principal |
|---|---|---|
| Evilginx 3.x | Proxy inverso | Robo de sesión MFA bypass |
| Modlishka | Proxy inverso | Interceptación transparente |
| Muraena | Proxy inverso | Automatización avanzada |
| EvilnoVNC | VNC remoto | Captura de sesión vía navegador remoto |
La versión 3 de Evilginx añadió evasión de detección, integración con redirectores y técnicas para esquivar los filtros de navegador. Microsoft documentó en julio de 2022 una campaña masiva de AiTM phishing que comprometió más de 10.000 organizaciones en cinco meses. Posteriormente, en 2023, identificó al actor DEV-1101 como operador de una plataforma de phishing-as-a-service que vendía kits AiTM listos para usar.
Si te interesan los kits de ataque que usan los ciberdelincuentes, estos frameworks de proxy inverso son su evolución natural. Más sofisticados, más difíciles de detectar, más efectivos.
Por qué tu MFA no te protege (y qué sí lo hace)
Vamos a ser directos: los códigos OTP —ya sean por SMS, app de autenticación o email— no protegen contra AiTM phishing. El atacante no necesita tu código. Necesita tu cookie. Y la obtiene porque tú completas la autenticación legítimamente a través de su proxy.
Los métodos de MFA vulnerables a robo de sesión mediante proxy inverso incluyen:
- SMS con código de verificación
- Aplicaciones TOTP (Google Authenticator, Authy, Microsoft Authenticator con código)
- Códigos enviados por email
- Notificaciones push simples (aprobación con un toque)
Lo que sí funciona contra el adversary in the middle:
- FIDO2 / WebAuthn (llaves físicas como YubiKey o Titan): la autenticación está vinculada criptográficamente al dominio legítimo. Si el dominio no coincide, la llave no responde. El proxy no puede falsear esto.
- Passkeys (Apple, Google, Microsoft): misma tecnología FIDO2 integrada en el dispositivo. Verifican el dominio automáticamente.
- Certificate-based authentication: los certificados de cliente validan el servidor antes de enviar credenciales.
- Conditional Access con device compliance (Azure AD / Entra ID): puedes exigir que el dispositivo esté gestionado y sea conforme antes de emitir la cookie.
Microsoft, Google y CISA llevan desde 2022 recomendando la migración a phishing-resistant MFA —que en la práctica significa FIDO2—. No es un capricho. Es la única capa que un proxy inverso no puede interceptar, porque la criptografía valida el dominio real, no lo que muestra el navegador.
Si tu empresa aún usa códigos OTP como segundo factor, estáis jugando con munición de fogueo contra un francotirador. Contraseñas reutilizadas y MFA débil son un regalo para los atacantes.
Señales de alerta y cómo detectar un AiTM en marcha
Detectar un ataque de AiTM phishing a nivel de usuario es complicado, precisamente porque la experiencia visual es idéntica a la legítima. Pero hay señales:
En el momento del clic:
- La URL no coincide exactamente con el dominio del servicio. Busca variaciones sutiles:
microsoftonline-login.com,office365-auth.net, caracteres Unicode similares (homógrafos). - El certificado TLS es válido (los atacantes usan Let's Encrypt), pero el dominio registrado tiene días o semanas de antigüedad.
- Pequeños retrasos inusuales durante la carga —el proxy añade latencia al reenviar peticiones—.
Desde el lado del administrador / SOC:
- Inicios de sesión desde IPs sospechosas inmediatamente después de una autenticación legítima (la cookie robada se usa desde otra ubicación).
- Creación de reglas de bandeja de entrada maliciosas (el atacante redirige emails para mantener persistencia).
- Tokens de sesión usados desde user-agents o geolocalizaciones inconsistentes.
- Alertas de Microsoft Defender for Cloud Apps o Google Workspace Alert Center sobre actividad de sesión anómala.
Herramientas como Have I Been Pwned no detectan este tipo de compromiso directamente —no es una filtración de base de datos—, pero si tu email aparece en una brecha, sabes que tu contraseña anda suelta, lo que te hace más vulnerable si un proxy inverso phishing captura una sesión donde además ya conocen tus credenciales.
Si administras sistemas, monitorizar los logs de autenticación con reglas que detecten token replay desde diferentes IPs es la medida más efectiva. Azure AD Premium tiene políticas de Continuous Access Evaluation (CAE) y Token Protection (en preview) diseñadas exactamente para este escenario.
Qué hacer si has picado
Si sospechas que has autenticado tus credenciales a través de un proxy AiTM:
- Revoca todas las sesiones activas del servicio afectado. En Microsoft 365: Entra ID → Usuarios → Revocar sesiones. En Google: Seguridad → Dispositivos → Cerrar sesión en todos.
- Cambia la contraseña inmediatamente, desde un dispositivo que consideres limpio.
- Revisa las reglas de bandeja de entrada. Los atacantes crean reglas para redirigir emails a carpetas ocultas o eliminarlos. Es su forma favorita de mantener acceso sin que te enteres.
- Audita los accesos recientes: aplicaciones OAuth autorizadas, dispositivos registrados, reenvíos de correo configurados.
- Reporta el dominio de phishing a Google Safe Browsing, Microsoft SmartScreen y PhishTank.
- Activa MFA resistente a phishing (FIDO2/Passkeys) si no lo tenías. Si lo tenías y aun así te comprometieron, algo falla en tu configuración.
La velocidad importa. Un robo de sesión da acceso inmediato al atacante, y los primeros minutos suelen usarse para exfiltrar datos, configurar persistencia o lanzar phishing lateral a tus contactos. Si gestionas un equipo, que tu programa de formación en ciberseguridad incluya este escenario con simulacros reales.
Preguntas frecuentes
¿Un ataque AiTM funciona contra cualquier servicio con login web?
En teoría, sí. Si el servicio usa autenticación basada en cookies de sesión y no implementa binding criptográfico al dominio (como FIDO2), un proxy inverso puede interceptar el flujo. En la práctica, los ataques se concentran en Microsoft 365, Google Workspace y Okta por su volumen de usuarios corporativos.
¿Las VPN protegen contra el proxy inverso phishing?
No. La VPN cifra tu tráfico de red, pero si haces clic en un enlace de phishing y te autenticas a través del proxy del atacante, la VPN no interviene en ese flujo. El robo de sesión ocurre a nivel de aplicación, no de red.
¿Cómo sé si mi organización ha sufrido un ataque AiTM?
Busca en tus logs de autenticación sesiones donde el mismo token se use desde dos IPs geográficamente distantes en un intervalo corto. En Azure AD, las alertas de impossible travel y anomalous token son indicadores. Google Workspace tiene alertas similares en el Alert Center.
¿Evilginx es legal?
La herramienta en sí es legal y se distribuye como software de pentesting. Usarla contra sistemas sin autorización explícita es un delito en la mayoría de jurisdicciones, incluyendo España (artículos 197 y 264 del Código Penal) y la normativa europea sobre acceso no autorizado a sistemas informáticos.
¿Las passkeys eliminan completamente el riesgo de AiTM?
Eliminan el vector de proxy inverso phishing porque la autenticación FIDO2 verifica criptográficamente el dominio del servidor. Si el dominio no es el legítimo, la passkey no responde. Dicho esto, ninguna medida elimina el riesgo al cien por cien: ataques a la cadena de suministro del proveedor de identidad, vulnerabilidades en la implementación WebAuthn o ingeniería social para desactivar la passkey son vectores residuales, aunque mucho más complejos de explotar.
El siguiente paso
Abre ahora mismo la configuración de seguridad de tu cuenta principal —Microsoft, Google, la que uses para trabajar— y comprueba si tienes activada la opción de passkey o llave de seguridad FIDO2. Si solo ves códigos OTP o notificaciones push, estás expuesto a exactamente el ataque que acabas de leer. Configura una passkey en tu dispositivo o compra una YubiKey (desde aproximadamente 25 €). Son diez minutos que pueden ahorrarte un incidente que, como sabe cualquiera que haya lidiado con phishing bancario, te roba mucho más que la sesión.
