SECURITY 12 min

Phishing Avanzado con Evilginx: Evasión de 2FA, Session Hijacking y Defensa Definitiva con FIDO2

Análisis técnico y defensivo sobre ataques Adversary-in-the-Middle (AitM) con Evilginx: cómo los proxies inversos interceptan cookies de sesión y eluden el 2FA tradicional, telemetría para Blue Teams y la defensa definitiva basada en FIDO2 y Passkeys.

Escrito por Samir El Azem Crovetto • Senior Backend Engineer & DevSecOps

Aviso Ético y Legal: Este documento tiene fines estrictamente educativos, de concienciación técnica y de auditoría defensiva en infraestructuras corporativas autorizadas. El análisis de herramientas ofensivas como Evilginx es fundamental para diseñar arquitecturas de identidad resilientes y evaluar la eficacia de los controles de acceso. Cualquier uso no autorizado sobre sistemas ajenos es ilegal.

La Muerte del 2FA Tradicional Frente al Phishing AitM

Durante más de una década, la recomendación estándar de seguridad para proteger identidades corporativas ha sido tajante: "activa la autenticación en dos factores (2FA)". Se asumía que si un atacante obtenía la contraseña de un usuario mediante una filtración o un portal clonado, la barrera del segundo factor (un SMS con un código OTP o una notificación temporal en aplicaciones como Google Authenticator o Microsoft Authenticator) frenaría en seco el acceso ilegítimo.

En el panorama actual de ciberseguridad, esta suposición es completamente falsa.

La proliferación de frameworks de Adversary-in-the-Middle (AitM), encabezados por herramientas como Evilginx (en sus versiones 2 y 3), ha transformado el phishing de un simple engaño estático a una intercepción dinámica de credenciales y tokens de sesión. Evilginx no intenta descifrar tráfico, adivinar códigos de seis dígitos ni explotar vulnerabilidades en el protocolo criptográfico: se sitúa como un proxy inverso transparente entre la víctima y el Proveedor de Identidad legítimo (como Microsoft Entra ID, Google Workspace u Okta).

El resultado es devastador: el usuario completa satisfactoriamente su proceso de autenticación legítimo, introduce su contraseña y aprueba su desafío MFA. Sin embargo, el atacante no roba únicamente la contraseña: intercepta la cookie de sesión autenticada posterior al MFA, permitiéndole acceder a la plataforma corporativa eludiendo cualquier control de doble factor tradicional.

En este artículo analizamos la arquitectura interna de Evilginx, la anatomía de los phishlets, los indicadores de compromiso para equipos de detección (Blue Team) y la única respuesta arquitectónica definitiva: la adopción de credenciales resistentes al phishing basadas en FIDO2 y Passkeys.

Anatomía y Arquitectura de un Proxy Inverso AitM

Para comprender por qué los controles tradicionales fracasan, observemos el flujo técnico completo de una sesión intermediada por Evilginx:

sequenceDiagram
    autonumber
    actor Victim as Víctima (Navegador)
    participant Proxy as Servidor AitM (Evilginx 3)
    participant IdP as Proveedor de Identidad Legítimo (Entra ID / Okta)

    Victim->>Proxy: 1. Hace clic en enlace señuelo (Lure URL)
    Proxy->>IdP: 2. Solicita la página de login real vía TLS
    IdP-->>Proxy: 3. Devuelve HTML/JS y desafío oficial
    Proxy-->>Victim: 4. Reescribe URLs y sirve el portal legítimo
    Victim->>Proxy: 5. Envía credenciales (usuario + contraseña)
    Proxy->>IdP: 6. Reenvía credenciales en tiempo real
    IdP-->>Proxy: 7. Solicita desafío MFA (App / TOTP)
    Proxy-->>Victim: 8. Presenta el desafío MFA legítimo
    Victim->>Proxy: 9. Introduce código TOTP o aprueba notificación
    Proxy->>IdP: 10. Reenvía aprobación de MFA al IdP
    IdP-->>Proxy: 11. Autenticación exitosa: Emite Cookie de Sesión
    Note over Proxy: Evilginx captura la Cookie (ESTSAUTH, SSO, JWT)
    Proxy-->>Victim: 12. Redirige a la aplicación corporativa real
    Note over Proxy: Atacante inyecta la cookie en su navegador
    Proxy->>IdP: 13. Sesión activa sin requerir contraseña ni MFA

Los Componentes Centrales de Evilginx:

  1. Servidor DNS Autoritativo Integrado: Evilginx actúa como servidor DNS para los dominios bajo control del atacante. Resuelve dinámicamente registros tipo A para subdominios señuelo y gestiona los desafíos ACME DNS-01 con Let's Encrypt, obteniendo certificados TLS válidos que muestran el "candado seguro" en el navegador de la víctima.
  2. Motor de Phishlets: Los phishlets son archivos de configuración en formato YAML que especifican las reglas de reescritura para cada plataforma objetivo. Definen qué dominios proxyficar, qué cadenas de texto o URLs reemplazar en el tráfico HTTP/HTTPS y, de manera crítica, qué cookies de autenticación deben ser interceptadas y almacenadas.
  3. Mecanismo de Lures (Señuelos): URLs parametrizadas y ofuscadas que pueden asociarse a identificadores únicos por víctima, permitiendo registrar la telemetría del ataque (aperturas, clics, envíos de credenciales) y redirigir dinámicamente a la víctima tras la captura.

2. Configuración Técnica de un Phishlet: Cómo se Captura la Sesión

Un phishlet describe con precisión quirúrgica el comportamiento del servicio de autenticación corporativo. A continuación se muestra un extracto ilustrativo de cómo un phishlet intercepta sesiones en entornos tipo Microsoft 365 / Entra ID:

# Extracto representativo de configuracion de un phishlet (YAML)
name: 'o365-defense-audit'
author: 'SecDevOps Research'
min_ver: '3.0.0'

# Dominios proxyficados (Proxy Hosts)
proxy_hosts:
  - {phish_sub: 'login', orig_sub: 'login', domain: 'microsoftonline.com', session: true, is_landing: true}
  - {phish_sub: 'portal', orig_sub: 'portal', domain: 'office.com', session: false, is_landing: false}

# Reglas de intercepcion de credenciales
credentials:
  username:
    key: 'login'
    search: '(.*)'
    type: 'post'
  password:
    key: 'passwd'
    search: '(.*)'
    type: 'post'

# Cookies de sesion criticas que el proxy debe capturar
auth_tokens:
  - domain: '.login.microsoftonline.com'
    keys: ['ESTSAUTH', 'ESTSAUTHPERSISTENT', 'SignInStateCookie']
  - domain: '.portal.office.com'
    keys: ['SessionId']

# Reglas de sustitucion en tiempo real para evitar fugas hacia el dominio original
sub_filters:
  - {triggers_on: 'login.microsoftonline.com', orig_sub: 'login', domain: 'microsoftonline.com', search: 'login.microsoftonline.com', replace: 'login.{hostname}'}

La Captura de las Cookies ESTSAUTH

En el ecosistema de Microsoft Entra ID, la presencia de la cookie ESTSAUTH en una petición HTTP es prueba suficiente de que el usuario ya ha superado con éxito todos los desafíos de autenticación (contraseña + MFA).

Cuando Evilginx intercepta esta cabecera Set-Cookie procedente del servidor legítimo, emite una notificación en su consola:

[17:15:22] [o365] Captured credentials for user: director.finanzas@empresa.com
[17:15:22] [o365] Password: **********
[17:15:35] [o365] Captured 3 auth tokens:
[17:15:35] [o365] ESTSAUTH = 0.AXoA8k... [SESSION COOKIE]
[17:15:35] [o365] ESTSAUTHPERSISTENT = 0.AXoA8k... [PERSISTENT COOKIE]

El atacante copia esta cadena codificada, la inyecta mediante herramientas como Cookie-Editor en su propio navegador y accede de forma transparente a Outlook Web, SharePoint o el portal de Azure sin disparar una nueva alerta de MFA.

3. Telemetría y Caza de Amenazas (Threat Hunting para Blue Teams)

Aunque los ataques AitM son transparentes para la víctima, dejan rastros inequívocos tanto en el tráfico de red como en los registros de auditoría de los Proveedores de Identidad:

1. Detección en los Registros de Inicio de Sesión de Microsoft Entra ID

Los analistas de SOC pueden identificar accesos procedentes de proxies inversos correlacionando los siguientes campos en los Sign-in Logs:

  • Discrepancia de IP vs. Sistema Operativo / User-Agent: La petición de login inicial se origina en la IP residencial o corporativa de la víctima, pero la primera llamada a la API que utiliza el token de sesión robado se origina inmediatamente desde una IP perteneciente a un proveedor de hosting o VPS en la nube (como DigitalOcean, AWS, Linode o Hetzner).
  • *Ausencia de Estado de Dispositivo Gestionado (Managed / Compliant Device):* Si la organización exige dispositivos registrados en Intune mediante políticas de Acceso Condicional, el atacante no podrá utilizar la cookie de sesión desde su máquina personal a menos que consiga falsificar el identificador del dispositivo.
  • *Viaje Imposible (Impossible Travel):* Un inicio de sesión en Madrid seguido, tres minutos después, por actividad de sesión en Frankfurt o Ámsterdam.

2. Detección en el Perímetro de Red y PCAP

En las capturas de paquetes de red analizadas con Wireshark, tal como detallamos en nuestra guía sobre Análisis Forense de Red y Tráfico Cifrado:

  • Huellas TLS Anómalas (JA4): Evilginx utiliza librerías de Go para negociar el canal TLS con el IdP legítimo. La huella JA4 generada por el motor de Evilginx difiere marcadamente de las huellas de navegadores estándar (Chrome, Edge, Safari).
  • Retardos de Red (RTT Jitter): La latencia añadida por la intermediación en tiempo real del proxy inverso introduce discrepancias medibles en los tiempos de respuesta TCP entre el cliente y el servidor.

4. Por Qué Fallan las Defensas Basadas en Concienciación

Durante años se ha instruido a los empleados para identificar ataques de phishing buscando pistas visuales:

  • "Revisa que la página tenga el candado verde de HTTPS." -> Inútil: Evilginx emite certificados TLS válidos de Let's Encrypt de forma automática.
  • "Fíjate en errores ortográficos o logotipos desactualizados." -> Inútil: Evilginx no clona la página manualmente; descarga y presenta el código HTML, CSS e imágenes oficiales del portal real en tiempo real.
  • "Usa una app de autenticación en lugar de SMS." -> Inútil: El proxy inverso retransmite el código TOTP o el número de aprobación al servidor legítimo de inmediato.

La conclusión de la ingeniería defensiva es categórica: no se puede resolver un fallo arquitectónico de los protocolos de autenticación delegando la responsabilidad en la atención visual del usuario.

5. La Defensa Definitiva: FIDO2, WebAuthn y Passkeys

La única tecnología capaz de neutralizar matemáticamente los ataques de tipo Adversary-in-the-Middle es la autenticación basada en los estándares FIDO2 / WebAuthn y las Passkeys.

El Secreto: Vinculación Criptográfica de Origen (Origin Binding)

A diferencia de una contraseña o un código TOTP, que son cadenas de caracteres que el usuario puede teclear en cualquier formulario web, una llave física FIDO2 (como una YubiKey) o una Passkey en el sistema operativo realiza una negociación criptográfica directa con el navegador web:

  1. El navegador detecta el dominio exacto en el que se encuentra el usuario según la barra de direcciones (por ejemplo, login.micros0ft-portal.com).
  2. El navegador empaqueta este dominio dentro de una estructura de datos llamada clientDataJSON.
  3. La llave de seguridad firma criptográficamente el desafío utilizando su clave privada, vinculando la firma al dominio que el navegador le reportó.
  4. La respuesta firmada viaja al proxy de Evilginx, y este la reenvía al IdP legítimo (login.microsoftonline.com).
  5. El servidor legítimo verifica la firma criptográfica y comprueba el campo origin. Al constatar que la firma está vinculada al dominio del atacante (micros0ft-portal.com) y no a su propio dominio (microsoftonline.com), rechaza de inmediato la autenticación.
sequenceDiagram
    autonumber
    actor V as Usuario con Llave FIDO2 / Passkey
    participant B as Navegador Web (Chrome/Edge)
    participant P as Proxy AitM (Evilginx)
    participant IdP as Proveedor Legítimo (microsoftonline.com)

    V->>B: Accede a login.micros0ft-portal.com
    B->>P: Pide desafio WebAuthn
    P->>IdP: Solicita desafio WebAuthn real
    IdP-->>P: Emite Challenge Criptografico
    P-->>B: Reenvia Challenge
    Note over B: El navegador detecta origin: "login.micros0ft-portal.com"
    B->>V: Solicita toque en Llave FIDO2
    V-->>B: Llave firma: {challenge, origin: "login.micros0ft-portal.com"}
    B->>P: Envia firma criptografica vinculada al dominio senuelo
    P->>IdP: Reenvia firma al IdP real
    Note over IdP: IdP verifica origen esperado: "login.microsoftonline.com"<br/>Origen recibido: "login.micros0ft-portal.com"<br/>DISCREPANCIA DETECTADA
    IdP-->>P: ERROR: Autenticacion rechazada (Firma invalida para este origen)
    P-->>B: Fallo de inicio de sesion (Ataque Bloqueado)

El ataque queda desbaratado a nivel criptográfico sin que el usuario tenga que darse cuenta del engaño.

Medidas Complementarias de Arquitectura Defensiva:

  1. Transición a Autenticación Phishing-Resistant en el IdP: En Microsoft Entra ID u Okta, deshabilitar progresivamente contraseñas y TOTP para imponer como único método válido llaves FIDO2, Windows Hello for Business o Passkeys, tal como analizamos en nuestra guía sobre Autenticación vs. Autorización Moderna.
  2. Políticas de Dispositivo Obligatorias (Device Compliance): Exigir que cualquier acceso a recursos corporativos proceda de un dispositivo administrado e identificado con certificado mTLS.
  3. Continuous Access Evaluation (CAE): Implementar la evaluación continua de acceso para invalidar tokens de sesión en tiempo real cuando la IP del cliente cambie drásticamente.
  4. Hardening de Infraestructura: Complementar la seguridad de identidades con defensas de red sólidas, como las expuestas en nuestra guía de Hardening de Servidores SSH y Seguridad en Contenedores Docker.

Conclusión

Evilginx y los frameworks de phishing AitM han demostrado que el modelo tradicional de credenciales compartidas y factores secundarios reutilizables ha llegado a su fin. Tratar la autenticación como una simple validación de texto plano en formularios web es una vulnerabilidad arquitectónica insostenible en 2026.

La ciberseguridad corporativa moderna exige migrar hacia modelos de Zero Trust, donde la identidad se verifica mediante criptografía asimétrica no exportable y vinculada al origen (Passkeys / FIDO2), respaldada por gobernanza estricta en Pipelines DevSecOps.

Si tu organización necesita evaluar su exposición frente a ataques de phishing AitM, implementar arquitecturas de autenticación resistentes al phishing con FIDO2 o auditar sus políticas de acceso condicional en la nube, puedes consultar mis Servicios de Ciberseguridad y Consultoría o contactar directamente conmigo en Sobre mí.