# Az - Cloud Kerberos Trust

{{#include ../../../banners/hacktricks-training.md}}

**Questo post è un riassunto di** [**https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/**](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) **che può essere consultato per ulteriori informazioni sull'attacco. Questa tecnica è anche commentata in** [**https://www.youtube.com/watch?v=AFay_58QubY**](https://www.youtube.com/watch?v=AFay_58QubY)**.**

## Panoramica della Relazione di Fiducia Kerberos

**Cloud Kerberos Trust (Entra ID -> AD)** -- Questa funzionalità (parte di Windows Hello for Business) stabilisce una fiducia unidirezionale in cui l'AD on-prem **si fida di Entra ID** per emettere ticket Kerberos per l'AD. Abilitandola si crea un oggetto computer **AzureADKerberos$** in AD (che appare come un Domain Controller in sola lettura) e un account **`krbtgt_AzureAD`** collegato (un KRBTGT secondario). Entra ID detiene le chiavi per questi account e può emettere TGT Kerberos "parziali" per gli utenti AD. I domain controller AD onoreranno questi ticket, ma con restrizioni simili a quelle di un RODC: per impostazione predefinita, **i gruppi ad alta privilegio (Domain Admins, Enterprise Admins, ecc.) sono *negati*** e gli utenti ordinari sono autorizzati. Questo impedisce a Entra ID di autenticare gli amministratori di dominio tramite la fiducia in condizioni normali. Tuttavia, come vedremo, un attaccante con privilegi sufficienti in Entra ID può abusare di questo design di fiducia.

## Pivoting da Entra ID a On-Prem AD

**Scenario:** L'organizzazione target ha **Cloud Kerberos Trust** abilitato per l'autenticazione senza password. Un attaccante ha ottenuto privilegi di **Global Administrator** in Entra ID (Azure AD) ma non controlla ancora l'AD on-prem. L'attaccante ha anche un accesso alla rete a un Domain Controller (tramite VPN o una VM Azure in rete ibrida). Utilizzando la fiducia cloud, l'attaccante può sfruttare il controllo di Azure AD per ottenere un accesso a livello di **Domain Admin** in AD.

**Prerequisiti:**

-   **Cloud Kerberos Trust** è configurato nell'ambiente ibrido (indicatore: esiste un account RODC `AzureADKerberos$` in AD).

-   L'attaccante ha diritti di **Global Admin (o Hybrid Identity Admin)** nel tenant di Entra ID (questi ruoli possono utilizzare l'API di **sincronizzazione** AD Connect per modificare gli utenti di Azure AD).

-   Almeno un **account utente ibrido** (esiste sia in AD che in AAD) su cui l'attaccante può autenticarsi. Questo potrebbe essere ottenuto conoscendo o reimpostando le sue credenziali o assegnando un metodo senza password (ad es. un Temporary Access Pass) per generare un Primary Refresh Token (PRT) per esso.

-   Un **account target AD on-prem** con privilegi elevati che *non* è nella policy di "negazione" predefinita del RODC. In pratica, un ottimo obiettivo è l'**account di sincronizzazione AD Connect** (spesso chiamato **MSOL_***), che ha diritti DCSync (replicazione) in AD ma di solito non è membro dei gruppi di amministrazione integrati. Questo account di solito non è sincronizzato con Entra ID, rendendo il suo SID disponibile per impersonare senza conflitto.

**Passi dell'Attacco:**

1.  **Ottenere Accesso all'API di Sincronizzazione Azure AD:** Utilizzando l'account Global Admin, acquisire un token di accesso per l'API di **Provisioning (sync) di Azure AD**. Questo può essere fatto con strumenti come **ROADtools** o **AADInternals**. Ad esempio, con ROADtools (roadtx):
```bash
# Using roadtx to get an Azure AD Graph token (no MFA)
roadtx gettokens -u <GlobalAdminUPN> -p <Password> --resource aadgraph
```
*(In alternativa, `Connect-AADInt` di AADInternals può essere utilizzato per autenticarsi come Global Admin.)*

2.  **Modifica gli attributi On-Prem di un utente ibrido:** Sfrutta l'**API di sincronizzazione di Azure AD** per impostare l'**Identificatore di Sicurezza (SID) onPremises** e il **SAMAccountName onPremises** di un utente ibrido scelto per corrispondere all'account AD di destinazione. Questo informa efficacemente Azure AD che l'utente cloud corrisponde all'account on-prem che vogliamo impersonare. Utilizzando il toolkit open-source **ROADtools Hybrid**:
```bash
# Example: modify a hybrid user to impersonate the MSOL account
python3 modifyuser.py -u <GlobalAdminUPN> -p <Password>\
--sourceanchor <ImmutableID_of_User>\
--sid <TargetAD_SID> --sam <TargetAD_SAMName>
```
> L'`sourceAnchor` (ID immutabile) dell'utente è necessario per identificare l'oggetto Azure AD da modificare. Lo strumento imposta il SID on-prem e il nome account SAM dell'utente ibrido ai valori del target (ad esempio, il SID e il SAM dell'account MSOL_xxxx). Azure AD normalmente non consente di modificare questi attributi tramite Graph (sono di sola lettura), ma l'API del servizio di sincronizzazione lo consente e gli Amministratori Globali possono invocare questa funzionalità di sincronizzazione.

3.  **Ottenere un TGT parziale da Azure AD:** Dopo la modifica, autenticati come utente ibrido su Azure AD (ad esempio, ottenendo un PRT su un dispositivo o utilizzando le loro credenziali). Quando l'utente accede (soprattutto su un dispositivo Windows unito al dominio o a Entra), Azure AD emetterà un **TGT Kerberos parziale (TGT**<sub>**AD**</sub>) per quell'account perché il Cloud Kerberos Trust è abilitato. Questo TGT parziale è crittografato con la chiave AzureADKerberos$ RODC e include il **SID target** che abbiamo impostato. Possiamo simulare questo richiedendo un PRT per l'utente tramite ROADtools:
```bash
roadtx getprt -u <HybridUserUPN> -p <Password> -d <DeviceID_or_Cert>
```
Questo genera un file `.prt` contenente il TGT parziale e la chiave di sessione. Se l'account era solo cloud password, Azure AD include comunque un TGT_AD nella risposta PRT.

4.  **Scambiare il TGT parziale per un TGT completo (su AD):** Il TGT parziale può ora essere presentato al Domain Controller on-prem per ottenere un **TGT completo** per l'account target. Facciamo questo eseguendo una richiesta TGS per il servizio `krbtgt` (il servizio TGT principale del dominio) -- essenzialmente aggiornando il biglietto a un TGT normale con un PAC completo. Sono disponibili strumenti per automatizzare questo scambio. Ad esempio, utilizzando lo script di ROADtools Hybrid:
```bash
# Use the partial TGT from the PRT file to get a full TGT and NTLM hash
python3 partialtofulltgt.py -p roadtx.prt -o full_tgt.ccache --extract-hash
```
Questo script (o equivalenti di Impacket) contatterà il Domain Controller e recupererà un TGT valido per l'account AD target, inclusa l'hash NTLM dell'account se viene utilizzata l'estensione Kerberos speciale. L'estensione **`KERB-KEY-LIST-REQ`** è inclusa automaticamente per chiedere al DC di restituire l'hash NTLM dell'account target nella risposta crittografata. Il risultato è una cache di credenziali (`full_tgt.ccache`) per l'account target *o* l'hash della password NTLM recuperato.

5.  **Impersonare il Target e Elevare a Domain Admin:** Ora l'attaccante controlla effettivamente **l'account AD target**. Ad esempio, se il target era l'account AD Connect **MSOL**, ha diritti di replica sulla directory. L'attaccante può eseguire un attacco **DCSync** utilizzando le credenziali di quell'account o il TGT Kerberos per estrarre gli hash delle password da AD (incluso l'account di dominio KRBTGT). Ad esempio:
```bash
# Using impacket's secretsdump to DCSync as the MSOL account (using NTLM hash)
secretsdump.py 'AD_DOMAIN/<TargetSAM>$@<DC_IP>' -hashes :<NTLM_hash> LOCAL
```
Questo estrae tutti gli hash delle password degli utenti AD, fornendo all'attaccante l'hash KRBTGT (permettendo loro di forgiare biglietti Kerberos di dominio a piacimento) e di fatto privilegi di **Domain Admin** su AD. Se l'account target fosse un altro utente privilegiato, l'attaccante potrebbe utilizzare il TGT completo per accedere a qualsiasi risorsa di dominio come quell'utente.

6.  **Pulizia:** Facoltativamente, l'attaccante può ripristinare il `onPremisesSAMAccountName` e il SID originali dell'utente Azure AD modificato tramite la stessa API o semplicemente eliminare qualsiasi utente temporaneo creato. In molti casi, il successivo ciclo di sincronizzazione di Azure AD Connect ripristinerà automaticamente le modifiche non autorizzate sugli attributi sincronizzati. (Tuttavia, a questo punto il danno è fatto -- l'attaccante ha privilegi DA.)

> [!WARNING]
> Abusando del meccanismo di fiducia e sincronizzazione del cloud, un Global Admin di Azure AD può impersonare quasi *qualsiasi* account AD non esplicitamente protetto dalla politica RODC, anche se quell'account non è mai stato sincronizzato con il cloud. In una configurazione predefinita, questo **colma una fiducia completa dalla compromissione di Azure AD alla compromissione di AD on-prem**.


## Riferimenti

- [Obtaining Domain Admin from Azure AD via Cloud Kerberos Trust](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/)



{{#include ../../../banners/hacktricks-training.md}}
