Az - Cloud Kerberos Trust

Reading time: 8 minutes

Questo post è un riassunto di 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.

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):

# 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:

# 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_AD) 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:

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:

# 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:

# 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.)

Riferimenti

• Obtaining Domain Admin from Azure AD via Cloud Kerberos Trust