Entra ID AiTM Token Replay y Viajes Imposibles

Entra ID AiTM Token Replay, Detección de Viajes Imposibles: Por Qué Importa Ahora

La autenticación multifactor detiene los ataques basados solo en contraseña. No detiene a un atacante que interpone un proxy en todo el flujo de inicio de sesión y se marcha con una cookie de sesión válida después de que el usuario complete la MFA. Eso es exactamente lo que hacen los kits de phishing adversary-in-the-middle (AiTM), y es justo la brecha que Entra ID AiTM Token Replay, Detección de Viajes Imposibles y las señales de fatiga por notificaciones MFA están diseñadas para cerrar. Microsoft ha sido explícito en que esta clase de ataque representa una parte creciente del compromiso de identidad: el blog de seguridad de Microsoft sobre la evolución de las técnicas de ataque a la identidad, junto con varios análisis de incidentes, describen kits AiTM como Evilginx desplegando un reverse proxy entre la víctima y la página de inicio de sesión real de Microsoft 365, sirviendo el contenido legítimo mientras capturan usuario, contraseña y — de forma crítica — el token de sesión/refresh emitido tras completarse la MFA. Deepwatch documenta el uso del mismo kit por actores maliciosos que van desde el prolífico operador de phishing Storm-0485 hasta el actor de espionaje ruso Star Blizzard, para interceptar silenciosamente sesiones de Microsoft 365.

Microsoft Entra ID Protection convierte este tipo de actividad en señales de riesgo, pero esas señales están dispersas entre varias detecciones distintas, tablas de logs y niveles de licencia. Este artículo es una guía de campo para leer cinco de ellas en conjunto:

Reuso de token AiTM — un token de sesión o refresh robado se reutiliza desde una infraestructura que el usuario real nunca tocó
Viaje imposible / atípico — dos inicios de sesión de la misma identidad, demasiado alejados geográficamente para ser ambos legítimos
Abuso de aprobación MFA push — un atacante con una contraseña válida intenta convencer o presionar a un usuario para que apruebe una notificación push que no solicitó
Picos de inicio de sesión de service principals — una identidad de carga de trabajo se autentica de repente mucho más, o de forma mucho más amplia, que su línea base
Geografía inusual en cuentas admin — una identidad privilegiada inicia sesión desde una ubicación o dispositivo que nunca había usado

ℹ️

ℹ️ Nota: Este artículo cubre en profundidad las señales de AiTM/reuso de token, anomalía de viaje, service principal y geografía admin. El abuso de aprobación MFA recibe un resumen específico aquí — para la cadena de ataque completa, la secuencia de detección y la checklist de hardening, vea MFA Fatigue: Detección y Prevención en Microsoft Entra ID. La configuración de políticas de riesgo de inicio de sesión y de usuario está en Azure Identity Protection: Bloquear Credenciales Filtradas.

Cómo Aparece Cada Señal en la Telemetría de Entra ID

Proxies AiTM y reuso de token

MITRE clasifica el robo de cookies de sesión bajo T1539 (Steal Web Session Cookie). Un kit AiTM se sitúa entre el usuario y el endpoint real de inicio de sesión de Microsoft, retransmite cada paso de la autenticación — incluido el desafío MFA — y luego captura el artefacto de sesión resultante. Como la víctima completó realmente la MFA, el token robado lleva consigo esa afirmación. El atacante lo reutiliza desde su propia infraestructura, no desde el dispositivo o la red de la víctima.

Microsoft Entra ID Protection tiene varias detecciones que capturan fragmentos de este escenario:

Token anómalo (riskEventType: anomalousToken) — se activa por características anómalas del token: una vida útil inusual, o un token usado desde una ubicación, aplicación, dirección IP o user agent que no coincide con el historial del usuario. La documentación de Microsoft cita esta señal como un indicador directo de un posible reuso de token. Es en tiempo real o fuera de línea, y requiere Entra ID P2.
Attacker in the Middle (attackerinTheMiddle, una detección de riesgo de usuario) — una detección de alta precisión que se activa cuando una sesión de inicio de sesión se vincula a un reverse proxy malicioso conocido, obtenida desde la telemetría de Microsoft Defender for Cloud Apps. Eleva directamente al usuario a riesgo alto y requiere Microsoft 365 E5 con Enterprise Mobility + Security E5 — a diferencia de la mayoría de las demás detecciones que provienen de Defender for Cloud Apps, Microsoft no menciona una ruta de licencia independiente Entra ID P2 + Defender for Cloud Apps para esta.
Propiedades de inicio de sesión inusuales (unfamiliarFeatures) — compara un inicio de sesión con el historial aprendido del usuario (IP, ASN, ubicación, dispositivo, navegador, subred del tenant). La guía de Microsoft señala específicamente esto: cuando se activa en un inicio de sesión no interactivo, merece atención adicional, porque ese patrón es consistente con un token de refresh reutilizado silenciosamente en segundo plano en lugar de un inicio de sesión interactivo.
Anomalía de emisor de token (tokenIssuerAnomaly) — para tokens SAML, señala reclamaciones de emisor inusuales o que coinciden con patrones de atacantes conocidos.

El playbook de robo de tokens de Microsoft enumera los disparadores concretos que un SOC debe vigilar para investigaciones de robo de tokens: token anómalo, propiedades de inicio de sesión inusuales, inicios de sesión no interactivos desde fuentes desconocidas, intento de acceso al Primary Refresh Token (PRT) (vía Defender for Endpoint), y URLs sospechosas consistentes con una página de aterrizaje AiTM.

⚠️

⚠️ Advertencia: Ninguna de estas detecciones garantiza capturar un proxy AiTM bien ejecutado en el primer inicio de sesión. La propia documentación de detección de riesgo de Microsoft señala que la detección de token anómalo puede seguir siendo ruidosa, con una tasa de falsos positivos superior a la normal en los niveles de riesgo bajo y medio — trate un solo indicio de riesgo bajo como una pista a investigar, no como un compromiso confirmado.

Viaje imposible y viaje atípico

Entra ID Protection en realidad ofrece dos detecciones relacionadas pero distintas aquí, y confundirlas lleva a supuestos incorrectos de licencia y herramientas:

Viaje imposible (mcasImpossibleTravel) — identifica actividad desde ubicaciones geográficamente distantes dentro de una ventana de tiempo más corta que el viaje físicamente posible entre ellas. Proviene de Microsoft Defender for Cloud Apps, se calcula fuera de línea, y requiere Entra ID P2 más una licencia independiente de Defender for Cloud Apps (o Microsoft 365 E5).
Viaje atípico (unlikelyTravel) — una detección nativa de Entra ID Protection (sin dependencia de Defender for Cloud Apps) que señala dos inicios de sesión desde ubicaciones distantes donde al menos una también es atípica para el historial de ese usuario específico. Tiene en cuenta el tiempo de viaje entre ubicaciones y suprime deliberadamente falsos positivos comunes como puntos de salida VPN e IPs compartidas dentro de la organización. Los usuarios nuevos pasan por un período de aprendizaje de 14 días o 10 inicios de sesión (lo que ocurra primero) antes de que la detección se active.

Ambas requieren Entra ID P2. Si su tenant solo tiene P1 o Free, se activan como la detección genérica Additional risk detected, sin detalle.

Abuso de aprobación MFA push, en breve

Dos señales nativas de Entra importan aquí: Suspicious MFA authentication approval (authenticatorPhishing) es una detección en tiempo real, exclusiva de P2, que correlaciona discrepancias de ASN, navegador, dispositivo y GPS entre el dispositivo que solicita el inicio de sesión y el que aprueba vía Microsoft Authenticator, y marca directamente el emparejamiento como riesgo alto. User reported suspicious activity (userReportedSuspiciousActivity) se activa cuando un usuario rechaza una solicitud MFA que no inició y la reporta explícitamente — Microsoft trata esto como evidencia de alta confianza, confirmada por el usuario, y eleva la cuenta a riesgo alto de inmediato. Solo esta última depende de que la función Report suspicious activity esté activada; authenticatorPhishing se activa automáticamente desde la telemetría de inicio de sesión y no necesita activación por separado. Para la cadena de ataque completa y la secuencia de hardening (number matching, MFA resistente al phishing para administradores, flujo de respuesta), vea el artículo dedicado a la fatiga MFA enlazado arriba.

Picos de inicio de sesión de service principals

Las identidades de carga de trabajo no aparecen en la misma tabla SigninLogs que los usuarios — se registran en AADServicePrincipalSignInLogs (también llamada ServicePrincipalSignInLogs según el nombre del workspace/tabla). La guía de auditoría de Thomas Naunheim para identidades administradas y service principals recomienda agrupar por ServicePrincipalName e IPAddress, y luego agregar el conteo de fallos (ResultType != "0") y la diversidad de recursos accedidos (dcount(ResourceDisplayName)) — un pico en cualquiera de las dos dimensiones, especialmente desde una IP o ASN que el service principal nunca ha usado, es la señal a investigar. Microsoft Entra ID Protection también tiene una superficie de detección dedicada al riesgo de identidades de carga de trabajo para exactamente este escenario, separada del riesgo de usuario.

Geografía inusual en cuentas admin

La guía de operaciones de seguridad de Microsoft para cuentas privilegiadas es explícita: los inicios de sesión admin merecen una supervisión más estricta y separada que la de los usuarios estándar — un nuevo dispositivo o ubicación, inicios de sesión fuera del horario laboral esperado, y cualquier detección de riesgo de Entra ID Protection (en cualquier nivel de riesgo) sobre una identidad privilegiada deberían generar una alerta de alta prioridad. La misma guía recomienda tratar cualquier actividad de Unfamiliar sign-in o originada en TOR contra un rol privilegiado como merecedora de revisión inmediata, en lugar de esperar a que escale a riesgo alto.

Detección: Qué Extraer de los Logs

El playbook de robo de tokens de Entra de Microsoft ofrece consultas iniciales concretas para SigninLogs, AADUserRiskEvents y AuditLogs. Adaptadas aquí para el conjunto de señales de AiTM/viaje/geo-admin:

Encontrar detecciones de riesgo etiquetadas como inusuales o anómalas desde una IP específica (punto de partida una vez que se tiene una IP sospechosa de un reporte de phishing o una alerta EDR):

AADUserRiskEvents
| where RiskEventType contains "unfamiliar" or RiskEventType contains "anomalous"
| where IpAddress == "<suspect-ip>"

Extraer todos los inicios de sesión desde la misma IP de origen para delimitar el radio de impacto:

SigninLogs
| where IPAddress == "<suspect-ip>"

Establecer la línea base de geografía y dispositivos de inicio de sesión de una identidad específica — esta es la consulta que el playbook recomienda antes de decidir si un inicio de sesión marcado es realmente anómalo para ese usuario:

SigninLogs
| where UserId == "<user-object-id>"
| extend deviceId_ = tostring(DeviceDetail.deviceId)
| extend city_ = tostring(LocationDetails.city)
| extend countryOrRegion_ = tostring(LocationDetails.countryOrRegion)
| summarize min(TimeGenerated), max(TimeGenerated)
  by IPAddress, ResultDescription, deviceId_, city_, countryOrRegion_, AppDisplayName

El playbook señala explícitamente que no toda alerta de riesgo de Entra tiene una fila correspondiente en SigninLogs — las detecciones de token anómalo en particular a veces solo son visibles vía AADUserRiskEvents o la API de detecciones de riesgo de ID Protection, no el flujo de inicio de sesión bruto.

Pico de service principal, adaptado de la guía de auditoría de cloud-architekt.net:

AADServicePrincipalSignInLogs
| where TimeGenerated >= ago(1d)
| where ResultType != "0"
| summarize StartTimeUtc = min(TimeGenerated), EndTimeUtc = max(TimeGenerated),
    count(), applicationCount = dcount(ResourceDisplayName),
    applicationSet = make_set(ResourceDisplayName)
  by ServicePrincipalName, IPAddress, ResultType

Para la geografía de cuentas privilegiadas y la supervisión de rechazos MFA, Microsoft ofrece contenido de Sentinel ya preparado en lugar de una única consulta para copiar — la guía de operaciones de seguridad para cuentas privilegiadas apunta a plantillas nombradas como SuspiciousSignintoPrivilegedAccount.yaml, MFARejectedbyUser.yaml y AADPrivilegedAccountsFailedMFA.yaml en el repositorio de GitHub Azure-Sentinel, una mejor fuente de verdad que reconstruir aquí la lógica exacta de los filtros.

💡

💡 Consejo: Si un inicio de sesión marcado es no interactivo (sin usuario presente), trátelo con mayor prioridad que una marca interactiva equivalente. La propia guía de Microsoft destaca este patrón porque es consistente con un reuso de token en segundo plano en lugar de un inicio de sesión de usuario activo (y potencialmente legítimo).

Remediation / Remediación

Para el reuso de token / AiTM:

Migre las cuentas privilegiadas y de alto valor a una MFA resistente al phishing (claves de seguridad FIDO2 o autenticación basada en certificados) — una cookie de sesión con proxy resulta mucho menos útil para un atacante si la ceremonia de autenticación original no puede simplemente reutilizarse. Vea Seguridad de Identidad Azure: Por Qué el MFA Solo No Es Suficiente para entender por qué la MFA push estándar no basta por sí sola.
Active Continuous Access Evaluation y la protección de tokens de Conditional Access donde esté disponible, para que un token vinculado a un dispositivo no pueda simplemente reutilizarse desde la infraestructura del atacante. El catálogo de EtcSec rastrea esta brecha directamente como CA_TOKEN_PROTECTION_DISABLED — vea Brechas de Acceso Condicional Azure: Bypass MFA para la revisión de política más amplia.
Active las detecciones Attacker in the Middle y Anomalous token (requiere P2, y Defender for Cloud Apps para la primera) y enrútelas hacia una política de Conditional Access basada en riesgo de inicio de sesión en lugar de dejarlas solo como visibilidad en el panel.
Trate cualquier detección AiTM confirmada como un incidente de robo de token, no como un simple reseteo de contraseña: siga los pasos de contención del playbook de robo de tokens de Microsoft — revocar sesiones, bloquear la IP del atacante, y verificar métodos MFA recién registrados o reglas de buzón dejadas tras el uso de la sesión.

Para el viaje imposible / atípico:

Confirme el licensing — el viaje atípico es nativo de ID Protection P2, pero el viaje imposible además necesita Defender for Cloud Apps conectado. La falta de esa conexión hace que la señal mcasImpossibleTravel desaparezca silenciosamente.
Deje que se complete la ventana de aprendizaje de 14 días/10 inicios de sesión para cuentas nuevas o migradas recientemente antes de ajustar umbrales con datos ruidosos de los primeros días.
Incorpore el riesgo de inicio de sesión a una política de Conditional Access que exija MFA o bloquee en riesgo medio/alto, en lugar de solo revisar de forma reactiva el informe de inicios de sesión de riesgo.

Para el abuso de aprobación MFA: active el number matching y la función Report suspicious activity, y exija MFA resistente al phishing para administradores — vea el artículo dedicado a la fatiga MFA para la secuencia completa.

Para los picos de service principal:

Revise AADServicePrincipalSignInLogs para comparar comportamiento base y picos de forma recurrente, no solo durante la respuesta a incidentes.
Evite roles de alto privilegio permanentes en service principals; rote secretos/certificados de cliente según un calendario definido y prefiera identidades administradas cuando sea posible.
Active las detecciones de riesgo de identidad de carga de trabajo de Entra ID Protection si su licencia lo permite — las políticas de riesgo de usuario no cubren los service principals.

Para la geografía admin inusual:

Inscriba todos los roles privilegiados en Privileged Identity Management (PIM) con activación limitada en el tiempo, y exija reautenticación en la activación.
Alerte ante cualquier detección de riesgo de ID Protection contra una identidad privilegiada, sin importar el nivel de riesgo asignado por Microsoft — la propia guía de Microsoft para cuentas privilegiadas recomienda este estándar más estricto para administradores frente a usuarios estándar.
Restrinja la elevación de administrador a dispositivos aprobados (PAW/SAW) cuando sea posible, y alerte cuando la elevación ocurra fuera de esa población.

Cómo Detecta Esto EtcSec

Las categorías Risk Protection y Conditional Access de EtcSec verifican si un tenant cuenta con la estructura de políticas y licencias de la que dependen estas detecciones, no solo si Entra ID Protection está activado. Las verificaciones relevantes del catálogo incluyen MFA_SUSPICIOUS_ACTIVITY (actividad MFA / patrón de inicio de sesión sospechoso) y MFA_UNUSUAL_LOCATION (inicio de sesión MFA desde una geolocalización inusual) a nivel de señal, además de RISK_NO_SIGNIN_RISK_POLICY (sin política de riesgo de inicio de sesión) y RISK_SIGNINS_NOT_INVESTIGATED (inicios de sesión de riesgo acumulándose sin revisión), y CA_TOKEN_PROTECTION_DISABLED (sin vinculación de token para frenar el reuso) a nivel de respuesta.

Un tenant que muestra inicios de sesión de riesgo en el portal pero no tiene ninguna política actuando sobre ellos, y ninguna protección de token frente a las cookies de sesión, es exactamente la brecha que estas verificaciones están diseñadas para revelar.

Controles Relacionados

Lea esto junto con Azure Identity Protection: Bloquear Credenciales Filtradas para la configuración de políticas de riesgo de inicio de sesión y de usuario, MFA Fatigue: Detección y Prevención en Microsoft Entra ID para la cadena de ataque de abuso de aprobación, Acceso Privilegiado Azure: Demasiados Global Admins y Cómo Auditar la Seguridad de Microsoft Entra ID para el lado de PIM y hardening admin, y OAuth Consent Phishing y Aplicaciones Maliciosas y Device Code Phishing en Entra ID para técnicas de phishing de identidad adyacentes que alimentan las mismas señales de riesgo.

Entra ID AiTM Token Replay: Detección de Viajes Imposibles y Fatiga MFA