Az - Exchange Hybrid Impersonation (ACS Actor Tokens)

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Información básica

En diseños legacy de Exchange Hybrid, el despliegue on-prem de Exchange podía autenticarse como la misma identidad de aplicación Entra utilizada por Exchange Online. Si un atacante comprometía el servidor Exchange, extraía la clave privada del certificado híbrido y realizaba un OAuth client-credentials flow, podía obtener first-party tokens con el contexto de privilegios de Exchange Online.

El riesgo práctico no se limitaba al acceso a buzones. Debido a que Exchange Online tenía amplias relaciones de confianza de back-end, esta identidad podía interactuar con servicios adicionales de Microsoft 365 y, en comportamientos antiguos, podía aprovecharse para una comprometimiento más profundo del tenant.

Attack Paths and Technical Flow

Modify Federation Configuration via Exchange

Exchange tokens históricamente tenían permisos para escribir la configuración de dominios/federación. Desde la perspectiva del atacante, esto permitía la manipulación directa de los datos de confianza de dominios federados, incluyendo listas de certificados para token-signing y flags de configuración que controlaban la aceptación de MFA-claim desde la infraestructura de federación on-prem.

Eso significa que un servidor Exchange Hybrid comprometido podría usarse para montar o reforzar suplantación al estilo ADFS cambiando la configuración de federación desde el lado cloud, incluso cuando el atacante partía únicamente de un compromiso de Exchange on-prem.

ACS Actor Tokens and Service-to-Service Impersonation

La ruta de auth híbrida de Exchange usaba Access Control Service (ACS) actor tokens con trustedfordelegation=true. Esos actor tokens eran luego embebidos en un segundo service token no firmado que llevaba la identidad del usuario objetivo en una sección controlada por el atacante. Debido a que el token exterior no estaba firmado y el actor token delegaba ampliamente, el llamador podía intercambiar usuarios objetivo sin re-autenticarse.

En la práctica, una vez obtenido el actor token, el atacante disponía de una primitiva de suplantación de larga duración (típicamente alrededor de 24 horas) que era difícil de revocar durante su vida útil. Esto permitía la suplantación de usuarios a través de Exchange Online y las SharePoint/OneDrive APIs, incluyendo high-value data exfiltration.

Históricamente, el mismo patrón también funcionó contra graph.windows.net construyendo un impersonation token con el valor netId de la víctima. Eso proporcionaba acción administrativa directa en Entra como usuarios arbitrarios y permitía workflows de takeover completo del tenant (por ejemplo, crear una nueva cuenta Global Administrator).

Qué ya no funciona

The graph.windows.net impersonation path via Exchange Hybrid actor tokens has been fixed. The old “Exchange to arbitrary Entra admin over Graph” chain should be considered removed for this specific token route.

Esta es la corrección más importante al documentar el ataque: mantener el riesgo de suplantación Exchange/SharePoint separado de la escalada de impersonation sobre Graph que ya fue parchada.

Qué puede seguir siendo relevante en la práctica

Si una organización aún mantiene una configuración híbrida antigua o incompleta con confianza compartida y material de certificados expuesto, el impacto de la suplantación Exchange/SharePoint puede seguir siendo severo. El ángulo de abuso de la configuración de federación también puede mantenerse relevante dependiendo del estado de configuración y migración del tenant.

La mitigación a largo plazo de Microsoft es dividir las identidades on-prem y Exchange Online de modo que la ruta de confianza shared-service-principal deje de existir. Los entornos que completaron esa migración reducen materialmente esta superficie de ataque.

Notas de detección

Cuando se abusa de esta técnica, los eventos de auditoría pueden mostrar desajustes de identidad donde el user principal name corresponde a un usuario suplantado mientras el contexto de display/source apunta a actividad de Exchange Online. Ese patrón de identidad mixta es una señal valiosa para hunting, aunque los defensores deberían basar una línea base de workflows legítimos de Exchange-admin para reducir falsos positivos.

Referencias

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks