Credential Harvesting: Evilginx, Modlishka y Bypass de MFA en Tiempo Real

MFA no es suficiente

Un analista SOC recibe una alerta: un usuario con MFA habilitada ha tenido su cuenta comprometida. Las credenciales fueron capturadas, el segundo factor fue satisfecho correctamente, y el atacante obtuvo una session cookie válida. Todo ocurrió en menos de 30 segundos. El usuario nunca compartió su contraseña ni su código MFA con nadie. Simplemente inició sesión en lo que parecía ser el portal corporativo de Microsoft 365.

La realidad es incómoda: MFA basada en OTP, SMS o push notifications no protege contra credential harvesting con reverse proxy. Estas técnicas, conocidas como AiTM (Adversary-in-the-Middle), interceptan la comunicación completa entre la víctima y el servicio legítimo, capturando no solo las credenciales sino también los tokens de sesión post-autenticación. Microsoft reportó en 2025 que más de 10.000 organizaciones fueron objetivo de campañas AiTM solo en el primer semestre del año.

Este artículo analiza las tres herramientas principales de AiTM phishing (Evilginx2, Modlishka, Muraena), documenta campañas reales donde se utilizaron, y detalla qué tipos de MFA resisten y cuáles no.

Credential harvesting clásico vs AiTM

Antes de profundizar en las herramientas, conviene entender por qué AiTM representa un salto cualitativo respecto al credential harvesting tradicional.

Harvesting clásico (página estática)

El modelo clásico funciona con una página de login falsa alojada en un servidor controlado por el atacante. La víctima introduce sus credenciales, el servidor las almacena (archivo de texto, Telegram, email) y redirige al usuario al sitio legítimo. El problema para el atacante: si el objetivo tiene MFA habilitada, las credenciales solas no bastan. El atacante necesita también el segundo factor, y ese factor tiene una ventana de validez de 30 segundos (TOTP) o es un evento de un solo uso (push notification).

Algunos kits intentaban resolver esto mostrando una segunda pantalla donde la víctima introducía su código MFA. El atacante tenía que usarlo manualmente en tiempo real (o automatizar la inyección con scripts). Esto funcionaba de forma intermitente y requería infraestructura de relay entre el kit y el servicio real.

Harvesting AiTM (reverse proxy)

AiTM elimina estas limitaciones porque el atacante no clona la página: la retransmite en tiempo real. El proxy se interpone entre la víctima y el sitio legítimo, actuando como un intermediario transparente. La víctima ve la página real de Microsoft, Google o cualquier servicio, renderizada en tiempo real a través del proxy. Introduce sus credenciales. El proxy las captura y las reenvía al servicio legítimo. El servicio pide MFA. La víctima completa el MFA (código, push, lo que sea). El servicio emite una session cookie. El proxy intercepta esa session cookie antes de enviarla al navegador de la víctima.

El resultado: el atacante obtiene una session cookie válida y completamente autenticada. No necesita las credenciales (aunque también las captura). Puede inyectar esa cookie en su propio navegador y acceder a la cuenta como si fuera el usuario, bypaseando cualquier MFA basada en knowledge factors (contraseñas) o possession factors sin binding criptográfico al dominio (TOTP, SMS, push).

Diagrama del flujo AiTM

┌──────────┐         ┌─────────────────┐         ┌──────────────────┐
│          │  HTTPS   │                 │  HTTPS   │                  │
│  Víctima │────────→│  Reverse Proxy  │────────→│  Servicio Real   │
│          │         │  (Evilginx)     │         │  (Microsoft 365) │
│          │←────────│                 │←────────│                  │
│          │         │  Captura:       │         │                  │
└──────────┘         │  - Credenciales │         └──────────────────┘
                     │  - Token MFA    │
                     │  - Session      │
                     │    Cookie ←─────────── Aquí está la clave
                     └─────────────────┘

  1. Víctima accede al dominio phishing (ej: login.micriosoft-auth.com)
  2. Proxy retransmite la página real de login.microsoftonline.com
  3. Víctima introduce email + password → proxy captura y reenvía
  4. Microsoft pide MFA → proxy retransmite el challenge
  5. Víctima completa MFA → proxy captura el token y lo reenvía
  6. Microsoft emite session cookie → proxy la intercepta
  7. Atacante usa la session cookie para acceder sin MFA

La diferencia fundamental: en harvesting clásico, el atacante obtiene credenciales. En AiTM, obtiene una sesión autenticada completa.

Evilginx2: arquitectura y funcionamiento

Evilginx2 es el framework AiTM más conocido y documentado. Creado por Kuba Gretzky como herramienta de investigación y pentesting, se ha convertido en la base de múltiples campañas de phishing avanzado, tanto en red team como en ataques reales.

Arquitectura

Evilginx2 está escrito en Go y opera como un servidor HTTP/HTTPS independiente con su propio servidor DNS integrado. No requiere un servidor web separado (nginx, Apache). Los componentes principales:

• Core engine. Reverse proxy HTTP/HTTPS que intercepta, modifica y retransmite tráfico entre la víctima y el sitio objetivo. Gestiona certificados TLS automáticamente vía Let's Encrypt.
• Phishlets. Archivos YAML que definen cómo proxear un servicio específico (Microsoft 365, Google Workspace, Okta, etc.). Contienen las reglas de reescritura de URLs, los subdominios a interceptar, y los nombres de las cookies de sesión que deben capturarse.
• Lures. URLs de phishing individuales que el atacante genera y distribuye. Cada lure puede tener un redirect URL personalizado para después de la captura, y un parámetro de tracking para identificar campañas.
• DNS server. Resuelve los subdominios definidos en los phishlets apuntando al propio servidor Evilginx.

Phishlets: el corazón de Evilginx

Un phishlet es un archivo YAML que define exactamente cómo interceptar un servicio. Ejemplo simplificado para Microsoft 365:

# Estructura conceptual de un phishlet (simplificado para comprensión)
name: 'o365'
author: '@kuba_gretzky'

proxy_hosts:
  - phish_sub: 'login'
    orig_sub: 'login.microsoftonline'
    domain: 'com'
    session: true
    is_landing: true

  - phish_sub: 'www'
    orig_sub: 'www.office'
    domain: 'com'

  - phish_sub: 'aadcdn'
    orig_sub: 'aadcdn.msauth'
    domain: 'net'

auth_tokens:
  - domain: 'login.microsoftonline.com'
    keys: ['ESTSAUTH', 'ESTSAUTHPERSISTENT']
    # Estas son las session cookies que Evilginx captura

credentials:
  username:
    key: 'login'
    search: '(.*)'
    type: 'post'
  password:
    key: 'passwd'
    search: '(.*)'
    type: 'post'

auth_urls:
  - '/kmsi'       # "Keep Me Signed In" page = autenticación completada

force_post:
  - path: '/common/login'
    search:
      - {key: 'login', search: '.*'}
      - {key: 'passwd', search: '.*'}

Cada phishlet define: los subdominios a proxear (proxy_hosts), las cookies de sesión a capturar (auth_tokens), los campos de credenciales a interceptar (credentials), y las URLs que indican que la autenticación fue exitosa (auth_urls).

Paso a paso de un ataque con Evilginx

1. Setup. El atacante registra un dominio (ej: micriosoft-auth.com), apunta sus NS records al servidor Evilginx, y configura el phishlet para O365.
2. Certificados. Evilginx solicita certificados TLS vía Let's Encrypt para los subdominios del phishlet (login.micriosoft-auth.com, etc.). La víctima verá un candado verde válido.
3. Lure. El atacante genera un lure: https://login.micriosoft-auth.com/XXXX. Este enlace se distribuye por email, SMS o redes sociales.
4. Víctima accede. El navegador resuelve login.micriosoft-auth.com al servidor Evilginx. El proxy solicita la página real de login.microsoftonline.com y la retransmite al navegador, reescribiendo todas las URLs para que apunten al dominio phishing.
5. Credenciales. La víctima introduce email y contraseña en la página real (renderizada a través del proxy). Evilginx intercepta los datos POST, los almacena y los reenvía a Microsoft.
6. MFA. Microsoft solicita el segundo factor. La víctima lo completa normalmente (TOTP, SMS, Authenticator push). El proxy retransmite todo.
7. Session cookie. Microsoft valida la autenticación completa y emite cookies de sesión (ESTSAUTH, ESTSAUTHPERSISTENT). Evilginx las intercepta antes de enviarlas al navegador.
8. Post-captura. La víctima es redirigida al sitio real de Microsoft. Para ella, todo fue una experiencia de login normal. El atacante ahora tiene las credenciales, el historial MFA y la session cookie.

Qué puede hacer el atacante con la session cookie

Con las cookies ESTSAUTH y ESTSAUTHPERSISTENT de Microsoft 365, el atacante puede:

• Acceder a Outlook, OneDrive, SharePoint, Teams sin repetir MFA.
• Leer y enviar emails como el usuario comprometido.
• Registrar un nuevo dispositivo MFA (persistencia a largo plazo).
• Acceder a aplicaciones SSO federadas conectadas al tenant.
• Modificar reglas de buzón para ocultar sus actividades (forwarding, auto-delete).

La sesión permanece válida hasta que expire (horas o días, dependiendo de la configuración del tenant) o hasta que un administrador la revoque explícitamente.

Modlishka: diferencias y características

Modlishka (del polaco "mantis", por la mantis religiosa que imita su entorno) es un reverse proxy de phishing escrito en Go por Piotr Duszynski. Comparte el concepto de AiTM con Evilginx, pero con un enfoque diferente.

Diferencias clave con Evilginx

• Configuración centralizada. Modlishka usa un único archivo de configuración JSON en lugar de phishlets individuales. La configuración define el dominio objetivo, los patrones de reescritura y los campos a capturar.
• Sin phishlets predefinidos. No incluye templates por servicio. El operador configura manualmente los patrones de interceptación, lo que requiere más conocimiento técnico pero ofrece más flexibilidad.
• Modo de reescritura. Modlishka utiliza un enfoque basado en regex para reescribir contenido on-the-fly. Reemplaza todas las referencias al dominio original por el dominio phishing en el HTML, JavaScript y CSS.
• Plugin system. Arquitectura modular basada en plugins para extender funcionalidad (autocert para TLS automático, credenciales para captura de login).
• Sin DNS integrado. Requiere configuración DNS externa (a diferencia de Evilginx que incluye su propio servidor DNS).

Ventajas de Modlishka

• Configuración más simple para servicios no cubiertos por phishlets de Evilginx.
• Menor footprint: un solo binario Go sin dependencias.
• Más fácil de modificar y extender vía plugins.

Limitaciones

• No gestiona automáticamente servicios multi-dominio complejos (como Microsoft 365, que usa login.microsoftonline.com, aadcdn.msauth.net, office.com simultáneamente).
• Requiere más intervención manual para la reescritura de JavaScript dinámico.
• Comunidad y mantenimiento menos activos que Evilginx.

Muraena: la alternativa en Go

Muraena (nombrada por la morena, el pez depredador) es un reverse proxy AiTM desarrollado en Go por el equipo de investigación de seguridad de Muraena Project. Se posiciona como una alternativa más modular y automatizable.

Características distintivas

• Crawler automático. Muraena incluye un crawler que analiza el sitio objetivo y genera automáticamente las reglas de reescritura necesarias. Reduce significativamente el esfuerzo de configuración.
• NecroBrowser. Componente complementario que automatiza acciones post-phishing. Una vez capturada la sesión, NecroBrowser puede inyectar las cookies en una instancia de navegador headless y ejecutar acciones programáticas (exfiltración de emails, registro de nuevo dispositivo MFA).
• Wildcard DNS. Usa certificados wildcard y DNS wildcard para simplificar el setup de subdominios.
• API REST. Expone una API para integrar Muraena en pipelines de automatización (útil en red team, problemático si lo adoptan actores maliciosos).

NecroBrowser: automatización post-captura

El componente NecroBrowser diferencia a Muraena de las otras herramientas. Mientras Evilginx y Modlishka capturan la sesión y dejan la explotación al operador, Muraena puede automatizar:

• Inyección de session cookies en Chromium headless.
• Navegación programática por la cuenta comprometida.
• Exfiltración automática de datos (contactos, emails, documentos).
• Registro de nuevo factor MFA para persistencia.

Esto convierte un ataque de phishing puntual en un pipeline automatizado de compromiso, escalando la capacidad del atacante de una víctima a cientos simultáneas.

Comparativa de herramientas AiTM

Característica	Evilginx2	Modlishka	Muraena
Lenguaje	Go	Go	Go
Configuración	Phishlets YAML por servicio	JSON centralizado	Crawler automático + JSON
DNS integrado	Si	No	No (usa wildcard)
TLS automático	Let's Encrypt integrado	Plugin autocert	Let's Encrypt
Phishlets predefinidos	Si (O365, Google, Okta, etc.)	No	No (auto-generados)
Captura credenciales	Si	Si	Si
Captura session cookies	Si	Si	Si
Post-explotación	Manual	Manual	NecroBrowser automatizado
Multi-dominio	Nativo (proxy_hosts)	Limitado	Wildcard DNS
Comunidad	Muy activa, phishlets comunitarios	Moderada	Limitada
Complejidad setup	Media	Baja (simple)	Baja (crawler auto)
Uso en campañas reales	Documentado (Storm-1167, etc.)	Documentado	Menos documentado
Detección por EDR	Alta visibilidad	Media	Media

En la práctica, Evilginx2 domina las campañas documentadas tanto en red team como en ataques reales. Modlishka se utiliza más en investigación y PoC. Muraena ofrece la automatización más completa pero tiene menor adopción.

Campañas AiTM documentadas

Storm-1167 / DEV-1167 (Microsoft, 2023-2025)

Microsoft Threat Intelligence documentó extensivamente las campañas del grupo que designa como Storm-1167. Este grupo utilizó Evilginx2 con phishlets de Microsoft 365 para comprometer cuentas corporativas a gran escala.

Cadena de ataque:

1. Email de phishing con enlace a documento compartido en "OneDrive".
2. El enlace dirigía a una página de login de Microsoft proxeada por Evilginx.
3. Captura de credenciales + session cookie post-MFA.
4. Acceso a la cuenta comprometida con la session cookie.
5. Creación de reglas de buzón para ocultar alertas de seguridad.
6. Envío de emails de phishing internos desde la cuenta comprometida (lateral phishing).
7. Compromiso de cuentas adicionales del mismo tenant (propagación interna).

Microsoft reportó que este grupo comprometió más de 10.000 organizaciones en 2023 usando exclusivamente AiTM con Evilginx. El factor clave: todas las víctimas tenían MFA habilitada (TOTP o push notification), y todas fueron comprometidas igualmente.

Scattered Spider y Okta (2023-2024)

Scattered Spider (UNC3944, Muddled Libra) combinó social engineering telefónico con infraestructura AiTM para comprometer tenants de Okta de empresas como MGM Resorts, Caesars Entertainment y Twilio.

Técnica AiTM en Okta:

1. Registro de dominios typosquatting del portal Okta corporativo del objetivo (ej: company-okta.com).
2. Despliegue de Evilginx con phishlets de Okta personalizados.
3. SMS masivo a empleados con "Your Okta session has expired. Re-authenticate: [URL phishing]".
4. Captura de session tokens de Okta.
5. Uso de las sesiones para acceder a aplicaciones SSO federadas (Slack, GitHub, AWS Console).

La particularidad de Scattered Spider: combinaban AiTM con llamadas telefónicas al helpdesk solicitando resets de MFA, creando un ataque multi-vector que superaba las defensas tecnológicas y humanas simultáneamente.

Tycoon 2FA (PhaaS, 2024-presente)

Tycoon 2FA opera como un servicio Phishing-as-a-Service que incorpora capacidades AiTM. Los operadores pagan una suscripción y reciben acceso a un panel con phishlets pre-configurados para Microsoft 365 y Google Workspace.

Características del servicio:

• Panel web con estadísticas de campaña en tiempo real.
• Phishlets actualizados automáticamente cuando Microsoft/Google cambian sus páginas de login.
• Integración con Telegram para alertas instantáneas de credenciales capturadas.
• Técnicas anti-detección: Cloudflare Turnstile, fingerprinting de navegador, geofencing.
• Pricing: desde 120 USD/mes para campañas básicas.

Sekoia.io y Proofpoint documentaron que Tycoon 2FA fue responsable de miles de campañas AiTM entre 2024 y 2025, democratizando el acceso a técnicas que antes requerían conocimiento técnico significativo.

Qué MFA resiste y qué no

No todas las implementaciones de MFA son iguales frente a AiTM. La diferencia crítica es si el mecanismo de autenticación valida criptográficamente el dominio del sitio donde se está autenticando.

Tipo de MFA	Resistente a AiTM	Razón
SMS OTP	No	El código se introduce en el proxy, que lo reenvía al sitio real
TOTP (Google Auth, Authy)	No	El código es independiente del dominio, el proxy lo retransmite
Push notification (MS Auth)	No	El usuario aprueba desde el móvil, la sesión se genera en el proxy
Phone call	No	Mismo problema que SMS, el código no está vinculado al dominio
Email OTP	No	El código se introduce en el proxy igual que TOTP
FIDO2/WebAuthn (YubiKey, passkeys)	Si	Challenge-response vinculado al dominio (origin binding)
Passkeys (Apple/Google/MS)	Si	Basadas en WebAuthn, misma protección de origin binding
Certificate-based auth (smartcard)	Si	TLS client certificate valida el dominio del servidor
Conditional Access Policies	Parcial	Pueden detectar y bloquear sesiones anómalas post-autenticación
Token Binding	Parcial	Vincula el token a la conexión TLS, pero adopción limitada

Por qué FIDO2/WebAuthn resiste

FIDO2 y WebAuthn son resistentes a AiTM porque el proceso de autenticación incluye el dominio (origin) como parte del challenge criptográfico.

Cuando una YubiKey o passkey firma un challenge de autenticación, incluye en la firma el origin del sitio (ej: login.microsoftonline.com). Si la víctima está accediendo a través de un proxy en login.micriosoft-auth.com, el origin firmado no coincidirá con el que Microsoft espera. Microsoft rechazará la autenticación porque la firma es para un dominio diferente.

El proxy no puede modificar la firma porque no posee la clave privada del dispositivo FIDO2. Tampoco puede re-firmar el challenge con el origin correcto. El ataque falla por diseño criptográfico, no por detección.

Conditional Access: protección parcial

Las Conditional Access Policies de Microsoft Entra ID (antes Azure AD) pueden mitigar parcialmente los ataques AiTM:

• Compliant device required. Exige que el dispositivo esté registrado y cumpla las políticas de seguridad. El proxy no es un dispositivo compliant.
• Trusted location. Restringe sign-ins a IPs corporativas conocidas. La IP del proxy será diferente.
• Sign-in risk policy. Azure AD Identity Protection puede detectar sign-ins de riesgo (IP de VPS/hosting, país inusual, viaje imposible).

Pero estas políticas no son infalibles contra AiTM: un atacante sofisticado puede usar proxies residenciales para simular una IP legítima, o capturar la sesión cuando el usuario está en una red corporativa.

Detección técnica de ataques AiTM

Indicadores en Azure AD / Entra ID

Los sign-in logs de Microsoft Entra ID contienen señales específicas de ataques AiTM:

1. SessionId y IP mismatch

Buscar sesiones donde el SessionId se reutiliza desde una IP diferente a la del sign-in original. Esto indica que alguien copió la session cookie y la está usando desde otra ubicación.

// KQL - Azure AD Sign-in Logs
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0
| summarize IPs = make_set(IPAddress), 
            IPCount = dcount(IPAddress) by SessionId
| where IPCount > 1

2. Impossible travel

Sign-ins desde ubicaciones geográficamente incompatibles en un periodo corto. Si un usuario se autentica desde Madrid y 10 minutos después su sesión se usa desde un VPS en Amsterdam, es un indicador fuerte.

3. Sign-in desde IP de hosting/VPS

Los reverse proxies AiTM se despliegan en servidores VPS o cloud. Las IPs pertenecerán a rangos de hosting (AWS, Azure, DigitalOcean, OVH, Hetzner). Un sign-in corporativo desde un data center es sospechoso.

// KQL - Detectar sign-ins desde ASN de hosting conocidos
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0
| where AutonomousSystemNumber in (
    14618, 16509, 8075,    // AWS, Azure
    14061, 63949,          // DigitalOcean
    16276, 35540           // OVH, Hetzner
)

4. MFA satisfied pero sin device registration

En un ataque AiTM, MFA se satisface correctamente (porque la víctima realmente la completó), pero el dispositivo que "pasa" la MFA no está registrado en el tenant. Este mismatch es detectable.

5. User-agent anomalías

El proxy puede modificar algunos headers, pero frecuentemente hay inconsistencias entre el user-agent del sign-in y el del uso posterior de la sesión.

Regla Sigma para detección AiTM

title: Potential AiTM Phishing - Session Cookie Reuse from Different IP
id: a1b2c3d4-e5f6-7890-abcd-ef1234567890
status: experimental
description: >
  Detects potential AiTM phishing attack where a session cookie is
  reused from a different IP address than the original authentication,
  indicating session hijacking via reverse proxy phishing.
references:
  - https://www.microsoft.com/en-us/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/
author: MalwareIntel Research
date: 2026/06/05
tags:
  - attack.credential_access
  - attack.t1557
  - attack.t1539
  - attack.initial_access
  - attack.t1078
logsource:
  product: azure
  service: signinlogs
detection:
  selection:
    ResultType: 0
  condition: selection
  # Post-processing: agrupar por SessionId,
  # alertar si dcount(IPAddress) > 1 en ventana de 4h
  # con distancia geográfica > 500km entre IPs
falsepositives:
  - VPN usage with IP changes
  - Mobile users switching between WiFi and cellular
  - Users connecting through corporate proxy chains
level: high

Detección en proxy logs y firewalls

Si la organización tiene visibilidad del tráfico DNS o web proxy:

• Dominios typosquatting. Monitorizar registros de dominios similares al portal corporativo. Herramientas como dnstwist o URLCrazy pueden generar variaciones automáticamente.
• Certificados TLS nuevos. Certificate Transparency logs (crt.sh) pueden revelar certificados emitidos para dominios typosquatting del portal de login corporativo.
• Headers sospechosos. Los reverse proxies AiTM a veces dejan trazas en headers HTTP (X-Forwarded-For, Via, o headers custom de Go HTTP).

Contramedidas efectivas

FIDO2 y Passkeys (contramedida principal)

La medida más efectiva contra AiTM es migrar toda la autenticación a FIDO2/WebAuthn o passkeys. No como segundo factor opcional, sino como requisito obligatorio.

Implementación en Microsoft Entra:

1. Registrar security keys o configurar passkeys para todos los usuarios.
2. Crear una Conditional Access Policy que requiera authentication strength "Phishing-resistant MFA".
3. Deshabilitar métodos MFA no resistentes (TOTP, SMS, push) para cuentas de alto privilegio como mínimo.
4. Aplicar gradualmente a todos los usuarios.

Implementación en Google Workspace:

1. Activar la inscripción de Titan Security Keys o passkeys.
2. Configurar "Advanced Protection Program" para usuarios de alto riesgo.
3. Requerir security keys como política en la Admin Console.

Continuous Access Evaluation (CAE)

Microsoft CAE permite revocar sesiones en tiempo casi real cuando se detectan condiciones de riesgo. A diferencia de las sesiones clásicas que son válidas hasta su expiración (potencialmente horas), CAE puede interrumpir una sesión comprometida en minutos.

Condiciones que pueden disparar la revocación:

• Cambio de ubicación de red significativo.
• Deshabilitación de la cuenta del usuario.
• Cambio de contraseña.
• Detección de riesgo elevado por Identity Protection.

Token Binding y Token Protection

Token Protection (preview en Microsoft Entra) vincula los tokens de acceso a la conexión TLS específica donde fueron emitidos. Si un atacante captura un token y lo usa desde una conexión TLS diferente, el token es rechazado.

Limitación actual: solo funciona con sign-in tokens en aplicaciones que lo soportan. La adopción es gradual y no cubre todos los escenarios.

Checklist de defensa contra AiTM

Prioridad	Medida	Impacto
P0	Migrar a FIDO2/passkeys (al menos cuentas privilegiadas)	Bloquea AiTM por diseño
P0	Conditional Access: requerir dispositivo compliant	Bloquea sesiones desde proxy
P1	Activar CAE (Continuous Access Evaluation)	Reduce ventana de explotación
P1	Monitorizar sign-in logs para session reuse multi-IP	Detección post-compromiso
P1	Alertar en sign-ins desde ASN de hosting/VPS	Detección temprana
P2	Certificate Transparency monitoring (dominios typosquatting)	Detección pre-ataque
P2	Bloquear legacy authentication protocols	Reduce superficie de ataque
P2	Token Protection (preview)	Protección de tokens en tránsito
P3	DMARC/DKIM/SPF estrictos en dominios corporativos	Dificulta envío de email phishing
P3	Security awareness: phishing simulado con AiTM	Formación sobre URLs sospechosas

Lo que NO funciona contra AiTM

• Verificar el candado HTTPS. El proxy tiene un certificado válido de Let's Encrypt.
• MFA basada en SMS/TOTP. El proxy retransmite los códigos en tiempo real.
• Push notification MFA. El usuario aprueba la push, la sesión se genera en el proxy.
• Password complexity. Irrelevante, las credenciales se capturan en texto claro.
• Rotación frecuente de contraseñas. El atacante captura la contraseña actual en tiempo real.

Recursos y referencias

Papers y reportes

• Microsoft Threat Intelligence. "From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud" (2022, actualizado 2024).
• Sekoia.io. "Tycoon 2FA: An in-depth analysis of the latest version of the AiTM phishing kit" (2024).
• Kuba Gretzky. "Evilginx2: Next Generation of Phishing 2FA Tokens" (breakdev.org, 2018-2025).
• Proofpoint. "Cloud Account Takeover Campaign Leveraging EvilProxy Phishing Kit" (2023).
• Mandiant. "UNC3944 (Scattered Spider): SMS Phishing, SIM Swapping, and AiTM" (2023).

Herramientas de detección

• AADInternals (o365blog.com). Módulo PowerShell para investigar tokens y sesiones de Azure AD.
• dnstwist. Generador de permutaciones de dominio para detectar typosquatting.
• crt.sh / certspotter. Certificate Transparency monitoring.
• MFASweep. Herramienta para enumerar qué tipos de MFA están habilitados en un tenant (defensiva).

MITRE ATT&CK

Técnica	ID	Descripción
Adversary-in-the-Middle	T1557	Interceptación de comunicaciones de autenticación
Steal Web Session Cookie	T1539	Captura de cookies de sesión post-autenticación
Valid Accounts: Cloud Accounts	T1078.004	Uso de credenciales válidas en servicios cloud
Phishing: Spearphishing Link	T1566.002	Distribución del lure por email
Modify Authentication Process	T1556	Manipulación del flujo de autenticación