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

This commit is contained in:
Translator
2026-03-02 23:54:02 +00:00
parent 8b7cdfa3a2
commit 08181c8453
2 changed files with 62 additions and 13 deletions
@@ -4,37 +4,39 @@
## Informazioni di base
Questa sezione copre le tecniche di pivot per muoversi da un tenant Entra ID compromesso alla Active Directory (AD) on-premises o da un AD compromesso al tenant Entra ID.
Questa sezione copre le tecniche di pivoting per spostarsi da un tenant Entra ID compromesso all'Active Directory (AD) on-premises o da un AD compromesso al tenant Entra ID.
## Tecniche di Pivoting
## Tecniche di pivoting
- [**Arc Vulnerable GPO Desploy Script**](az-arc-vulnerable-gpo-deploy-script.md): Se un attacker può controllare o creare un account computer AD e accedere alla Azure Arc GPO deployment share, può decriptare il secret memorizzato del Service Principal e usarlo per autenticarsi ad Azure come il service principal associato, compromettendo completamente l'ambiente Azure collegato.
- [**Arc Vulnerable GPO Desploy Script**](az-arc-vulnerable-gpo-deploy-script.md): Se un attaccante può controllare o creare un AD computer account e accedere alla Azure Arc GPO deployment share, può decrittare il Service Principal secret memorizzato e usarlo per autenticarsi ad Azure come il service principal associato, compromettendo completamente l'ambiente Azure collegato.
- [**Cloud Kerberos Trust**](az-cloud-kerberos-trust.md): Come pivotare da Entra ID ad AD quando Cloud Kerberos Trust è configurato. Un Global Admin in Entra ID (Azure AD) può abusare di Cloud Kerberos Trust e della sync API per impersonare account AD ad alto privilegio, ottenere i loro ticket Kerberos o gli hash NTLM, e compromettere completamente la Active Directory on-premanche se quegli account non sono mai stati sincronizzati sul cloud — creando efficacemente un ponte per l'escalation di privilegi dal cloud verso AD.
- [**Cloud Kerberos Trust**](az-cloud-kerberos-trust.md): Come pivotare da Entra ID ad AD quando Cloud Kerberos Trust è configurato. Un Global Admin in Entra ID (Azure AD) può abusare di Cloud Kerberos Trust e della sync API per impersonare account AD ad alto privilegio, ottenere i loro ticket Kerberos o hash NTLM e compromettere completamente l'Active Directory on-premanche se quegli account non sono mai stati sincronizzati sul cloud—collegando efficacemente l'elevazione di privilegi cloud-to-AD.
- [**Cloud Sync**](az-cloud-sync.md): Come abusare di Cloud Sync per spostarsi dal cloud verso AD on-premises e viceversa.
- [**Cloud Sync**](az-cloud-sync.md): Come abusare di Cloud Sync per muoversi dal cloud all'AD on-premises e viceversa.
- [**Connect Sync**](az-connect-sync.md): Come abusare di Connect Sync per spostarsi dal cloud verso AD on-premises e viceversa.
- [**Connect Sync**](az-connect-sync.md): Come abusare di Connect Sync per muoversi dal cloud all'AD on-premises e viceversa.
- [**Domain Services**](az-domain-services.md): Cos'è il servizio Azure Domain Services e come pivotare da Entra ID all'AD che genera.
- [**Domain Services**](az-domain-services.md): Cos'è il servizio Azure Domain Services e come pivotare da Entra ID all'AD che esso genera.
- [**Federation**](az-federation.md): Come abusare di Federation per spostarsi dal cloud verso AD on-premises e viceversa.
- [**Federation**](az-federation.md): Come abusare di Federation per muoversi dal cloud all'AD on-premises e viceversa.
- [**Hybrid Misc Attacks**](az-hybrid-identity-misc-attacks.md): Attacchi vari che possono essere usati per pivotare dal cloud verso AD on-premises e viceversa.
- [**Hybrid Misc Attacks**](az-hybrid-identity-misc-attacks.md): Attacchi vari che possono essere usati per pivotare dal cloud all'AD on-premises e viceversa.
- [**Exchange Hybrid Impersonation (ACS Actor Tokens)**](az-exchange-hybrid-impersonation.md): Internals degli actor-token di Exchange Hybrid, percorsi di abuso patchati vs ancora rilevanti e come valutare il rischio residuo dopo migrazioni con split dei service-principal.
- [**Local Cloud Credentials**](az-local-cloud-credentials.md): Dove trovare le credenziali per il cloud quando un PC è compromesso.
- [**Pass the Certificate**](az-pass-the-certificate.md): Generare un certificato basato sul PRT per effettuare il login da una macchina a un'altra.
- [**Pass the Cookie**](az-pass-the-cookie.md): Rubare cookie di Azure dal browser e usarli per il login.
- [**Pass the Cookie**](az-pass-the-cookie.md): Rubare le cookie di Azure dal browser e usarle per effettuare il login.
- [**Primary Refresh Token/Pass the PRT/Phishing PRT**](az-primary-refresh-token-prt.md): Cos'è il PRT, come rubarlo e usarlo per accedere alle risorse Azure impersonando l'utente.
- [**PtA - Pass through Authentication**](az-pta-pass-through-authentication.md): Come abusare di Pass-through Authentication per spostarsi dal cloud verso AD on-premises e viceversa.
- [**PtA - Pass through Authentication**](az-pta-pass-through-authentication.md): Come abusare di Pass-through Authentication per muoversi dal cloud all'AD on-premises e viceversa.
- [**Seamless SSO**](az-seamless-sso.md): Come abusare di Seamless SSO per spostarsi da on-prem al cloud.
- [**Seamless SSO**](az-seamless-sso.md): Come abusare di Seamless SSO per muoversi dall'on-prem al cloud.
- **Un altro modo per pivot dal cloud a On-Prem è** [**abusing Intune**](../az-services/intune.md)
- **Another way to pivot from cloud to On-Prem is** [**abusing Intune**](../az-services/intune.md)
{{#include ../../../banners/hacktricks-training.md}}
@@ -0,0 +1,47 @@
# Az - Exchange Hybrid Impersonation (ACS Actor Tokens)
{{#include ../../../banners/hacktricks-training.md}}
## Informazioni di base
Nelle architetture Exchange Hybrid legacy, la distribuzione Exchange on-prem poteva autenticarsi come la stessa identità applicativa Entra utilizzata da Exchange Online. Se un attaccante comprometteva il server Exchange, estraeva la chiave privata del certificato hybrid e eseguiva un OAuth client-credentials flow, poteva ottenere token first-party con il contesto di privilegi di Exchange Online.
Il rischio pratico non si limitava all'accesso alle caselle. Poiché Exchange Online aveva ampie relazioni di trust back-end, questa identità poteva interagire con altri servizi Microsoft 365 e, nei comportamenti più vecchi, poteva essere sfruttata per un compromesso più profondo del tenant.
## Percorsi d'attacco e flusso tecnico
### Modificare la configurazione di federazione tramite Exchange
Storicamente i token di Exchange avevano permessi per scrivere le impostazioni di dominio/federazione. Dal punto di vista dell'attaccante, questo permetteva la manipolazione diretta dei dati di trust del dominio federato, incluse le liste di certificati per la firma dei token e i flag di configurazione che controllavano l'accettazione delle MFA-claim dall'infrastruttura di federazione on-prem.
Ciò significa che un server Exchange Hybrid compromesso poteva essere usato per avviare o rafforzare un'impersonazione in stile ADFS modificando la config di federazione dalla parte cloud, anche quando l'attaccante era partito solo da una compromissione di Exchange on-prem.
### ACS Actor Tokens e impersonazione servizio-a-servizio
Il percorso di autenticazione hybrid di Exchange usava Access Control Service (ACS) actor tokens con `trustedfordelegation=true`. Questi actor token venivano poi incorporati in un secondo service token non firmato che trasportava l'identità dell'utente target in una sezione controllata dall'attaccante. Poiché il token esterno non era firmato e l'actor token delegava ampiamente, il chiamante poteva sostituire gli utenti target senza ri-autenticarsi.
In pratica, una volta ottenuto l'actor token, l'attaccante disponeva di una primitiva di impersonazione a lunga durata (tipicamente circa 24 ore) difficile da revocare a metà vita. Ciò abilitava l'impersonazione di utenti attraverso le API di Exchange Online e SharePoint/OneDrive, includendo esfiltrazione di dati ad alto valore.
Storicamente, lo stesso pattern funzionava anche contro `graph.windows.net` costruendo un token di impersonazione con il valore `netId` della vittima. Questo forniva azioni amministrative dirette su Entra come utenti arbitrari e permetteva workflow di takeover completo del tenant (per esempio, la creazione di un nuovo account Global Administrator).
## Cosa non funziona più
Il percorso di impersonazione `graph.windows.net` via Exchange Hybrid actor tokens è stato corretto. La vecchia catena "Exchange to arbitrary Entra admin over Graph" dovrebbe essere considerata rimossa per questa specifica via di token.
Questa è la correzione più importante da evidenziare nella documentazione dell'attacco: mantenere il rischio di impersonazione Exchange/SharePoint separato dall'escalation di impersonazione Graph ora patchata.
## Cosa può ancora essere rilevante in pratica
Se un'organizzazione esegue ancora una configurazione hybrid vecchia o incompleta con trust condiviso e materiale di certificato esposto, l'impatto dell'impersonazione Exchange/SharePoint può rimanere severo. L'angolo di abuso della configurazione di federazione può anche rimanere rilevante a seconda della configurazione del tenant e dello stato di migrazione.
La mitigazione a lungo termine di Microsoft è separare le identità on-prem e Exchange Online in modo che il percorso di trust del shared-service-principal non esista più. Gli ambienti che hanno completato quella migrazione riducono materialmente questa superficie d'attacco.
## Note di rilevamento
Quando questa tecnica viene abusata, gli eventi di audit possono mostrare mismatch di identità in cui lo user principal name corrisponde a un utente impersonato mentre il contesto di display/sorgente indica attività di Exchange Online. Quel pattern di identità mista è un segnale di hunting di alto valore, sebbene i difensori debbano basare una baseline dei workflow legittimi degli Exchange-admin per ridurre i falsi positivi.
## Riferimenti
- https://www.youtube.com/watch?v=rzfAutv6sB8
{{#include ../../../banners/hacktricks-training.md}}