Az - Exchange Hybrid Impersonation (ACS Actor Tokens)

Tip

Impara & pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Impara & pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Impara & pratica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Sostieni HackTricks

Informazioni di base

Nelle architetture legacy di Exchange Hybrid, la deployment on-prem di Exchange poteva autenticarsi come la stessa identità dell’applicazione Entra usata 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 cassette postali. 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 federation tramite Exchange

Storicamente, i token di Exchange avevano permessi per scrivere le impostazioni di dominio/federation. Dal punto di vista di un attaccante, questo permetteva la manipolazione diretta dei dati di trust dei domini federati, incluse le liste dei certificati per la firma dei token e i flag di configurazione che controllavano l’accettazione delle MFA-claim dall’infrastruttura di federation on-prem.

Ciò significa che un server Exchange Hybrid compromesso poteva essere usato per orchestrare o rafforzare un’impersonazione in stile ADFS modificando la config di federation dalla parte cloud, anche quando l’attaccante era partito solo da una compromissione di Exchange on-prem.

ACS Actor Tokens and Service-to-Service Impersonation

Il percorso di auth hybrid di Exchange usava Access Control Service (ACS) actor tokens con trustedfordelegation=true. Quei actor token venivano poi incorporati in un secondo service token non firmato che portava 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 scambiare 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. Questo consentiva l’impersonazione di utenti attraverso le API di Exchange Online e SharePoint/OneDrive, inclusa l’esfiltrazione di dati ad alto valore.

Storicamente, lo stesso schema funzionava anche contro graph.windows.net costruendo un token di impersonazione con il netId della vittima. Ciò permetteva azioni amministrative dirette in Entra come utenti arbitrari e abilitava workflow di takeover dell’intero 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 route di token.

Questa è la correzione più importante da documentare per l’attacco: mantenere separato il rischio di impersonazione Exchange/SharePoint dall’escalation di impersonazione su Graph ora patchata.

Ciò che può ancora avere importanza nella pratica

Se un’organizzazione esegue ancora una configurazione hybrid vecchia o incompleta con trust condiviso e materiale dei certificati esposto, l’impatto dell’impersonazione Exchange/SharePoint può rimanere grave. L’angolo di abuso della configurazione di federation può anche restare rilevante a seconda della configurazione del tenant e dello stato della migrazione.

La mitigazione a lungo termine di Microsoft è separare le identità on-prem e di 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 display/source punta ad attività di Exchange Online. Quel pattern di identità mista è un segnale di hunting ad alto valore, sebbene i defender dovrebbero definire una baseline dei workflow legittimi degli Exchange-admin per ridurre i falsi positivi.

Riferimenti

Tip

Impara & pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Impara & pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Impara & pratica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Sostieni HackTricks