Translated ['src/pentesting-cloud/azure-security/az-lateral-movement-clo

This commit is contained in:
Translator
2026-03-02 23:54:01 +00:00
parent da4191ce37
commit e33f2ca6a2
2 changed files with 57 additions and 8 deletions

View File

@@ -4,29 +4,31 @@
## Información básica
Esta sección cubre las técnicas de pivoting para moverse desde un tenant de Entra ID comprometido hacia el Active Directory (AD) on-premises o desde un AD comprometido hacia el tenant de Entra ID.
Esta sección cubre las técnicas de pivoting para moverse desde un tenant de Entra ID comprometido hacia el Active Directory (AD) on-premises, o desde un AD comprometido hacia el tenant de Entra ID.
## Pivoting Techniques
- [**Arc Vulnerable GPO Desploy Script**](az-arc-vulnerable-gpo-deploy-script.md): Si un atacante puede controlar o crear una cuenta de equipo AD y acceder al Azure Arc GPO deployment share, puede descifrar el secreto almacenado del Service Principal y usarlo para autenticarse en Azure como el Service Principal asociado, comprometiendo completamente el entorno de Azure vinculado.
- [**Arc Vulnerable GPO Desploy Script**](az-arc-vulnerable-gpo-deploy-script.md): Si un atacante puede controlar o crear una cuenta de equipo en AD y acceder al recurso compartido de despliegue de GPO de Azure Arc, puede descifrar el secret almacenado del Service Principal y usarlo para autenticarse en Azure como el service principal asociado, comprometiendo completamente el entorno de Azure vinculado.
- [**Cloud Kerberos Trust**](az-cloud-kerberos-trust.md): Cómo pivotar de Entra ID a AD cuando Cloud Kerberos Trust está configurado. Un Global Admin en Entra ID (Azure AD) puede abusar de Cloud Kerberos Trust y del sync API para hacerse pasar por cuentas AD de alto privilegio, obtener sus tickets Kerberos o hashes NTLM, y comprometer completamente el Active Directory on-premises — incluso si esas cuentas nunca fueron sincronizadas con la nube — efectivamente conectando la escalada de privilegios de la nube al AD.
- [**Cloud Kerberos Trust**](az-cloud-kerberos-trust.md): Cómo pivotar desde Entra ID hacia AD cuando Cloud Kerberos Trust está configurado. Un Global Admin en Entra ID (Azure AD) puede abusar de Cloud Kerberos Trust y de la sync API para suplantar cuentas AD de alto privilegio, obtener sus tickets de Kerberos o hashes NTLM, y comprometer completamente el Active Directory on-prem—even si esas cuentas nunca fueron cloud-synced—, enlazando efectivamente la escalada de privilegios de la nube al AD.
- [**Cloud Sync**](az-cloud-sync.md): Cómo abusar de Cloud Sync para moverse de la nube al AD on-premises y viceversa.
- [**Connect Sync**](az-connect-sync.md): Cómo abusar de Connect Sync para moverse de la nube al AD on-premises y viceversa.
- [**Domain Services**](az-domain-services.md): Qué es el servicio Azure Domain Services y cómo pivotar desde Entra ID al AD que genera.
- [**Domain Services**](az-domain-services.md): Qué es el servicio Azure Domain Services y cómo pivotar desde Entra ID hacia el AD que genera.
- [**Federation**](az-federation.md): Cómo abusar de Federation para moverse de la nube al AD on-premises y viceversa.
- [**Hybrid Misc Attacks**](az-hybrid-identity-misc-attacks.md): Ataques misceláneos que pueden usarse para pivotar de la nube al AD on-premises y viceversa.
- [**Local Cloud Credentials**](az-local-cloud-credentials.md): Dónde encontrar credenciales de la nube cuando un PC está comprometido.
- [**Exchange Hybrid Impersonation (ACS Actor Tokens)**](az-exchange-hybrid-impersonation.md): Internals de Exchange Hybrid actor-token, rutas de abuso parcheadas vs aún relevantes, y cómo evaluar el riesgo residual después de migraciones con split de service-principal.
- [**Pass the Certificate**](az-pass-the-certificate.md): Generar un certificado basado en el PRT para iniciar sesión de una máquina a otra.
- [**Local Cloud Credentials**](az-local-cloud-credentials.md): Dónde encontrar credenciales para la nube cuando un PC está comprometido.
- [**Pass the Cookie**](az-pass-the-cookie.md): Robar cookies de Azure desde el navegador y usarlas para iniciar sesión.
- [**Pass the Certificate**](az-pass-the-certificate.md): Generar un cert basado en el PRT para iniciar sesión de una máquina a otra.
- [**Pass the Cookie**](az-pass-the-cookie.md): Robar cookies de Azure del navegador y usarlas para iniciar sesión.
- [**Primary Refresh Token/Pass the PRT/Phishing PRT**](az-primary-refresh-token-prt.md): Qué es el PRT, cómo robarlo y usarlo para acceder a recursos de Azure suplantando al usuario.
@@ -34,7 +36,7 @@ Esta sección cubre las técnicas de pivoting para moverse desde un tenant de En
- [**Seamless SSO**](az-seamless-sso.md): Cómo abusar de Seamless SSO para moverse de on-prem a la nube.
- **Otra forma de pivotar desde la nube hacia On-Prem es** [**abusing Intune**](../az-services/intune.md)
- **Otra forma de pivotar de la nube a On-Prem es** [**abusing Intune**](../az-services/intune.md)
{{#include ../../../banners/hacktricks-training.md}}

View File

@@ -0,0 +1,47 @@
# Az - Exchange Hybrid Impersonation (ACS Actor Tokens)
{{#include ../../../banners/hacktricks-training.md}}
## Información básica
En diseños legacy de Exchange Hybrid, la implementación on-prem de Exchange podía autenticarse como la misma identidad de aplicación de Entra usada 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 tokens de primera parte 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 back-end, esta identidad podía interactuar con servicios adicionales de Microsoft 365 y, en comportamientos anteriores, podía aprovecharse para una compromisión más profunda del tenant.
## Rutas de ataque y flujo técnico
### Modificar la configuración de federación vía Exchange
Históricamente, los tokens de Exchange tenían permisos para escribir la configuración de dominio/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 firmar tokens y banderas de configuración que controlaban la aceptación de claims MFA desde la infraestructura de federación on-prem.
Eso significa que un servidor Exchange Hybrid comprometido podía usarse para preparar o reforzar una 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 on-prem de Exchange.
### ACS Actor Tokens y suplantación servicio-a-servicio
La ruta de auth híbrida de Exchange usaba Access Control Service (ACS) actor tokens con `trustedfordelegation=true`. Esos actor tokens se incrustaban luego en un segundo service token sin firmar 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 volver a 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 a mitad de su vida útil. Esto permitía la suplantación de usuarios a través de las APIs de Exchange Online y SharePoint/OneDrive, incluyendo exfiltración de datos de alto valor.
Históricamente, el mismo patrón también funcionaba contra `graph.windows.net` construyendo un token de suplantación con el valor netId de la víctima. Eso permitía acciones administrativas de Entra como usuarios arbitrarios y habilitaba flujos de takeover completo del tenant (por ejemplo, crear una nueva cuenta Global Administrator).
## Qué ya no funciona
La ruta de suplantación hacia `graph.windows.net` vía los actor tokens de Exchange Hybrid ha sido corregida. La antigua cadena "Exchange a Entra admin arbitrario vía Graph" debe considerarse eliminada para esta ruta específica de token.
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 suplantación de Graph que ya fue parcheada.
## Lo que aún puede importar en la práctica
Si una organización todavía ejecuta una configuración hybrid antigua o incompleta con confianza compartida y material de certificado expuesto, el impacto de la suplantación Exchange/SharePoint puede seguir siendo grave. El ángulo de abuso de la configuración de federación también puede seguir siendo relevante dependiendo del setup del tenant y del estado de la migración.
La mitigación a largo plazo de Microsoft es separar las identidades on-prem y de Exchange Online para que la ruta de confianza de 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 desacoples 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 admin de Exchange para reducir falsos positivos.
## Referencias
- https://www.youtube.com/watch?v=rzfAutv6sB8
{{#include ../../../banners/hacktricks-training.md}}