diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md index abfb8b55b..93504a084 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md @@ -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-prem — anche 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-prem—anche 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}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-exchange-hybrid-impersonation.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-exchange-hybrid-impersonation.md new file mode 100644 index 000000000..f00643d24 --- /dev/null +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-exchange-hybrid-impersonation.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}}