Si en tu organización seguís pensando que tener el Autenticador de Microsoft o los SMS activados os hace inmunes al Account Takeover (ATO), tenemos un problema. En Hard2bit, nuestros equipos de Respuesta a Incidentes (DFIR) están lidiando semanalmente con intrusiones críticas en Microsoft 365 donde el MFA estaba perfectamente configurado y validado por el usuario.
La realidad técnica es dura: los atacantes ya no intentan adivinar contraseñas ni romper algoritmos de doble factor; simplemente, los esquivan. En este artículo vamos a diseccionar a nivel de protocolo cómo las amenazas avanzadas utilizan ataques Adversary-in-the-Middle (AiTM) para robar tokens de sesión, cómo lograr persistencia en Entra ID y, lo más importante, cómo detectarlo y bloquearlo en tu infraestructura.
La Evolución del Phishing: Adversary-in-the-Middle (AiTM) y Proxies Inversos
El phishing estático (clonar un HTML y robar credenciales) es inútil contra el MFA. Para sortearlo, el cibercrimen ha adoptado arquitecturas de Proxy Inverso utilizando frameworks como Evilginx2, Muraena o Modlishka.
La arquitectura detrás del Proxy Inverso
En un ataque AiTM, el servidor del atacante se interpone dinámicamente entre la víctima y login.microsoftonline.com. No hay una página falsa pre-renderizada.
- Terminación TLS y SNI: El proxy del atacante termina la conexión TLS con el navegador de la víctima utilizando un certificado SSL válido (usualmente de Let's Encrypt para un dominio tipográfico como
login.micros0ft-security.com). - Proxying Transparente: Simultáneamente, abre una conexión legítima hacia Microsoft. Actúa como un man-in-the-middle perfecto, reescribiendo los enlaces al vuelo (modificando el DOM y las cabeceras HTTP) para que la víctima interactúe con el servidor real de Microsoft a través del túnel del atacante.
💡 Consejo Hard2bit: Si necesitas evaluar si tu infraestructura actual es vulnerable a estas tácticas de proxy inverso, considera realizar una Auditoría de Ciberseguridad Avanzada para simular estos vectores de ataque en un entorno controlado.
Anatomía Técnica del Robo de Tokens (Pass-the-Cookie)
El objetivo final del atacante no es la contraseña, sino el artefacto de confianza que emite Microsoft tras una autenticación exitosa: la cookie de sesión.
JWT, ESTSAUTH y la diferencia con el PRT
Cuando el usuario introduce su contraseña y aprueba el prompt de MFA en su móvil, Entra ID genera una serie de tokens basados en JSON Web Tokens (JWT).
En dispositivos administrados, Windows utiliza un Primary Refresh Token (PRT), que está fuertemente vinculado al hardware (TPM) del equipo mediante criptografía. Sin embargo, en la capa del navegador web, la sesión se mantiene mediante cookies estándar, principalmente ESTSAUTH y ESTSAUTHP.
Al pasar en texto claro por la memoria del proxy inverso del atacante, estas cookies son interceptadas antes de llegar a la víctima.
HTTP
# Captura de tráfico (simplificada) en el servidor del atacante:
HTTP/1.1 200 OK
Set-Cookie: ESTSAUTH=0.AT8A_...[JWT_Payload_Truncado]...; domain=.login.microsoftonline.com; secure; HttpOnly
Una vez que el atacante exporta esta cookie y la inyecta en su propio navegador, hereda la identidad y el estado de MFA del usuario. Para Microsoft Entra ID, la sesión ya ha sido validada, por lo que permite el acceso inmediato a SharePoint, Exchange Online o Teams sin lanzar un nuevo desafío de seguridad.
Post-Explotación: Persistencia y Evasión en Entra ID
Una vez dentro, el reloj corre. Los atacantes saben que la cookie ESTSAUTH tiene una vida útil limitada, por lo que su primer movimiento es garantizar el acceso continuo.
Abuso de la API de Graph y manipulación del buzón
El atacante suele acceder a Outlook on the Web (OWA) o utilizar scripts que interactúan directamente con la Microsoft Graph API para:
- Robo de información (Data Exfiltration): Búsqueda rápida de palabras clave (
password,factura,IBAN,confidencial). - Reglas de Ocultación: Creación de reglas de bandeja de entrada para mover cualquier correo de alertas de seguridad o respuestas de clientes a la carpeta de Elementos Eliminados o RSS Feeds, cegando a la víctima.
- Registro de un nuevo dispositivo MFA: Añaden un dispositivo controlado por ellos mismos en
mysignins.microsoft.com, permitiéndoles autenticarse en el futuro incluso si la contraseña cambia o la cookie expira.
Detección Forense: Buscando las Huellas en los Logs de Azure AD
Detectar un ataque AiTM requiere afinar la monitorización en los Sign-in logs de Microsoft Entra ID. No busques inicios de sesión fallidos; el peligro está en los inicios de sesión exitosos con anomalías de contexto.
Si utilizas Microsoft Sentinel u otro SIEM, deberías buscar estos patrones usando KQL (Kusto Query Language):
- Análisis del
SessionId: Busca un mismoSessionIdque salte repentinamente de una dirección IP (la de la víctima) a otra dirección IP diferente o un ASN distinto (la del atacante inyectando la cookie) en un lapso corto de tiempo. - Mismatches en el User-Agent: Cambios abruptos del navegador reportado dentro de la misma sesión autenticada.
- Eventos de actualización de cuenta: Monitoriza eventos de auditoría como
Update useroAdd registered security infoinmediatamente posteriores a un inicio de sesión desde una IP inusual.
Code snippet
// Ejemplo KQL básico para buscar cambios de IP en la misma sesión
SigninLogs
| where ResultType == 0
| summarize IPCount = dcount(IPAddress), make_set(IPAddress) by SessionId, UserPrincipalName
| where IPCount > 1
Mitigación Estratégica: Defensas Reales contra AiTM
El enfoque tradicional ya no sirve. Para proteger tu tenant de Microsoft 365, debes implementar una arquitectura Zero Trust sólida. Desde nuestro departamento de Consultoría en Microsoft 365, recomendamos dos pilares fundamentales:
1. Políticas de Acceso Condicional (Conditional Access) y CAE
El contexto lo es todo. Configura políticas estrictas en Entra ID para limitar desde dónde y con qué se puede acceder:
- Dispositivos Conformables (Compliant): Requiere que el acceso a Office 365 solo se pueda realizar desde dispositivos que estén enrolados en Microsoft Intune y cumplan con las políticas de salud de la empresa. El atacante tendrá la cookie, pero su portátil no estará en tu Intune.
- Continuous Access Evaluation (CAE): Habilita CAE para que la revocación de tokens sea casi en tiempo real si se detecta un cambio crítico (como un cambio abrupto de IP o la desactivación del usuario).
2. MFA Resistente al Phishing (FIDO2 y Passkeys)
La solución criptográfica definitiva. Reemplaza los códigos SMS y los prompts de la app por llaves de seguridad de hardware (FIDO2/YubiKeys) o Windows Hello for Business.
Estos estándares utilizan Channel Binding (Vinculación de Canal). La firma criptográfica de la autenticación se vincula al nombre de dominio real (login.microsoftonline.com). Si la víctima está en el proxy del atacante (micros0ft-security.com), el desafío criptográfico falla a nivel de navegador y el ataque es neutralizado instantáneamente.
Tu Próximo Paso en Seguridad
La falsa sensación de seguridad es el mayor enemigo de las organizaciones. El secuestro de cuentas en Microsoft 365 mediante ataques AiTM y robo de tokens es una amenaza diaria, silenciosa y altamente efectiva. Superar este desafío no requiere soluciones mágicas, requiere una configuración experta, visibilidad forense y la adopción de estándares modernos de autenticación.
Si no estás seguro de si tu configuración actual de Entra ID resistiría un ataque de Evilginx2, o si sospechas que podrías haber sufrido una brecha silenciada, no esperes a que el daño sea irreversible.
Contacta con los expertos de Hard2bit hoy mismo. Analizaremos la postura de seguridad de tu tenant, ajustaremos tus políticas de Acceso Condicional y blindaremos tu identidad corporativa frente a las amenazas de nueva generación.