Detección de phishing AiTM: reutilización de tokens en Entra
Cómo el phishing AiTM roba sesiones de Microsoft 365 pese a la MFA y cómo detectar la reutilización de tokens en los inicios de sesión de Entra ID y en el UAL.
En resumen. En el phishing adversary-in-the-middle (AiTM, adversario en el medio), la víctima inicia sesión a través del proxy inverso del atacante, que retransmite contraseña y MFA a Microsoft y se queda con la cookie de sesión. Después el atacante reutiliza esa sesión desde su propio equipo. En los registros: un inicio de sesión interactivo desde la red del proxy (a menudo un proveedor de hosting), después inicios de sesión no interactivos con el mismo Session ID desde otra IP u otro país y, por último, registros del registro de auditoría unificado cuyo AADSessionId coincide. Se contiene revocando las sesiones, no solo restableciendo la contraseña; se previene con MFA resistente al phishing.
Microsoft describió una campaña AiTM que intentó atacar a más de 10.000 organizaciones desde septiembre de 2021, en la que los atacantes iniciaban el fraude de pagos apenas cinco minutos después de robar credenciales y sesión. Desde entonces, estos kits se han vuelto un producto de consumo. La buena noticia para quien investiga es que el AiTM deja una huella muy concreta, porque la sesión robada se usa desde dos lugares.
Cómo funciona el ataque
- La víctima hace clic en un enlace a una página que actúa como proxy del inicio de sesión real de Microsoft.
- Escribe su contraseña y aprueba la MFA. El proxy envía ambas a Entra ID, que emite una cookie de sesión al proxy, y este pasa una copia a la víctima. Para la víctima, el inicio de sesión ha funcionado.
- El kit guarda la cookie (y a menudo la contraseña).
- El atacante importa la cookie en su navegador, o usa tokens derivados, y accede a Outlook en la web, Exchange o SharePoint sin que se le vuelva a pedir MFA.
MITRE ATT&CK recoge estos pasos como Adversary-in-the-Middle (T1557) y Use Alternate Authentication Material: Web Session Cookie (T1550.004).
Qué se ve en los registros
| Momento | Registro | Qué buscar |
|---|---|---|
| Inicio de sesión de phishing | Inicios de sesión interactivos de Entra | Inicio de sesión correcto, MFA satisfecha, desde la IP del proxy. A menudo un ASN de hosting / VPS; aplicación a menudo OfficeHome |
| Reutilización | Inicios de sesión no interactivos de Entra | Mismo Session ID, otra IP / ASN / país, de minutos a horas después; el agente de usuario puede cambiar |
| Persistencia | Auditoría de Entra / UAL | User registered security info (nuevo Authenticator o teléfono), consentimientos |
| Acciones | UAL | New-InboxRule, Set-Mailbox, MailItemsAccessed, Send con AppAccessContext.AADSessionId = el Session ID robado y ClientIP = la IP de reutilización |
El dato clave es que todos los tokens derivados del inicio de sesión original heredan el identificador de sesión (Microsoft Learn, identificadores vinculables). Una sesión legítima también cambia de red (el portátil que pasa de la oficina a casa), pero un salto a otro país o a una red de hosting minutos después de un inicio de sesión desde otro hosting es difícil de explicar de forma inocente.
El análisis de Microsoft de junio de 2023 sobre una campaña en varias fases describe exactamente esta secuencia: la cookie robada reutilizada horas después desde una IP de otro país, después la adición de un nuevo método MFA (señalando que añadir un método no exigía volver a autenticarse de forma predeterminada) y después reglas que movían todo el correo entrante a Archive y lo marcaban como leído (blog de seguridad de Microsoft).
Una búsqueda manual, paso a paso
- Exporte ambos archivos de inicio de sesión (interactivos y no interactivos) de todo el tenant, tan atrás como permita la retención (guía de exportación).
- Agrupe por Session ID. Para cada sesión, anote dónde empezó: las IP de sus inicios de sesión interactivos (o de su primer evento).
- Marque las sesiones usadas desde otro lugar: cualquier inicio de sesión correcto de la sesión desde una IP cuyo país o ASN difiera del de origen. Sin país ni ASN, un /16 distinto (IPv4) es una aproximación burda pero útil.
- Priorice las sesiones cuyo origen es una red de hosting y cuya reutilización procede del extranjero.
- Pivote hacia el UAL con las IP de reutilización y el Session ID, y liste las acciones (investigación del UAL).
- Revise otros usuarios con inicios de sesión desde las mismas IP de proxy o de reutilización: las campañas rara vez se quedan en un solo buzón.
Si el tenant tiene Entra ID P2, los campos de riesgo ayudan: anomalousToken, unfamiliarFeatures y la detección Attacker in the Middle a nivel de usuario descrita en Microsoft Learn. Microsoft advierte de que Anomalous token tiene una tasa de falsos positivos más alta de lo normal en los niveles bajo y medio, así que verifique siempre en los registros en bruto.
Falsos positivos
| Situación | Por qué parece una reutilización | Qué la descarta |
|---|---|---|
| Portátil que cambia de red | Misma sesión, IP nueva | Mismo país y ASN residencial/corporativo; mismo ID de dispositivo y agente de usuario |
| VPN con túnel dividido | Parte del tráfico por la VPN, parte directo | ASN de la VPN conocido; alternancia, no un salto en un solo sentido |
| Cambio de red móvil (wifi a 4G) | IP nueva, ASN de operador | ASN móvil en el país del usuario |
| Direcciones IPv6 de privacidad | La dirección cambia constantemente | Mismo prefijo /48 |
Cómo lo detecta M365 Forensics
El analizador en el navegador implementa esta búsqueda en el hallazgo «Una sesión usada desde varios lugares (reutilización de token)» (alto): para cada Session ID, el origen son sus inicios de sesión interactivos (o el primer evento), y cualquier evento correcto de la misma sesión desde otra IP cuenta como reutilización si su país difiere, si su ASN difiere cuando los países coinciden o se desconocen, o si cae en otro /16 (/48 en IPv6) cuando no se sabe nada más. El hallazgo muestra Sesión abierta desde y Sesión usada desde.
Después viene la correlación: toda acción del UAL o de la auditoría que lleve la sesión reutilizada, la IP de reutilización o un token de un inicio de sesión sospechoso se agrupa en «Acciones realizadas desde la sesión o la IP del atacante» (crítico). Solo sirven como marcadores los hallazgos de inicio de sesión que reflejan el propio inicio de sesión del atacante (red de hosting, sesión reutilizada, código de dispositivo, inicio de sesión de riesgo, fatiga de MFA seguida de éxito); el viaje imposible no, porque uno de sus dos inicios de sesión es del usuario. El incidente ficticio comentado muestra el resultado en un caso AiTM de ejemplo.
Contención y prevención
- Revocar las sesiones (centro de administración de Entra → usuario → Revoke sessions, o
Revoke-MgUserSignInSession). Invalida los tokens de actualización; los tokens de acceso pueden seguir siendo válidos hasta que caduquen (una hora por defecto), salvo que la aplicación admita la evaluación continua de acceso. - Eliminar lo que añadió el atacante: métodos MFA, reglas de bandeja de entrada y reenvíos, consentimientos de aplicaciones.
- Restablecer la contraseña desde un dispositivo limpio.
- Prevenir: MFA resistente al phishing (claves de acceso / FIDO2, Windows Hello para empresas, autenticación basada en certificados), acceso condicional que exija dispositivos conformes o unidos de forma híbrida, y protección de tokens donde esté disponible. La guía de Microsoft sobre robo de tokens detalla la investigación y la respuesta.
El orden completo de las operaciones está en la primera hora después de un BEC.
Preguntas frecuentes
¿La MFA detiene el phishing AiTM?
No la MFA clásica (notificaciones push, SMS, códigos). El proxy retransmite el paso de MFA y roba la cookie de sesión que demuestra que se completó. Los métodos resistentes al phishing, como las claves de acceso (passkeys), las llaves de seguridad FIDO2 o Windows Hello para empresas, están ligados al sitio real y no se pueden retransmitir así.
¿Dónde aparece la reutilización de tokens en los registros?
En los inicios de sesión no interactivos de Entra ID: inicios de sesión con el mismo Session ID que el inicio de sesión interactivo original pero desde otra IP, red o país. Las acciones realizadas con la sesión robada llevan el mismo identificador en el registro de auditoría unificado.
¿Basta con restablecer la contraseña tras un phishing AiTM?
No. Revoque las sesiones y los tokens de actualización del usuario, elimine cualquier método MFA, regla de bandeja de entrada, reenvío o consentimiento de aplicación que haya añadido el atacante y, después, restablezca la contraseña.
Para saber más
- Microsoft Learn: Guía de respuesta al robo de tokens
- Glosario: reutilización de tokens, inicio de sesión no interactivo, identificadores vinculables
- Análisis de los registros de inicio de sesión de Entra ID para los demás patrones de inicio de sesión.