Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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.
Quando viene stabilita una fiducia con Azure AD, un Read Only Domain Controller (RODC) viene creato nell'AD. L'account computer RODC, chiamato AzureADKerberos$. Inoltre, un account secondario krbtgt chiamato krbtgt_AzureAD. Questo account contiene le chiavi Kerberos utilizzate per i ticket che Azure AD crea.
Pertanto, se questo account viene compromesso, potrebbe essere possibile impersonare qualsiasi utente... anche se ciò non è vero perché questo account è impedito dal creare ticket per qualsiasi gruppo AD privilegiato comune come Domain Admins, Enterprise Admins, Administrators...
Tuttavia, in uno scenario reale ci saranno utenti privilegiati che non sono in quei gruppi. Quindi il nuovo account krbtgt, se compromesso, potrebbe essere utilizzato per impersonarli.
Inoltre, quando un utente si autentica su Windows utilizzando un'identità ibrida, **Azure AD emetterà un ticket Kerberos parziale insieme al PRT. Il TGT è parziale perché AzureAD ha informazioni limitate dell'utente nell'AD on-prem (come l'identificatore di sicurezza (SID) e il nome).
Windows può quindi scambiare questo TGT parziale per un TGT completo richiedendo un ticket di servizio per il servizio krbtgt.
Poiché potrebbero esserci servizi che non supportano l'autenticazione kerberos ma NTLM, è possibile richiedere un TGT parziale firmato utilizzando una chiave krbtgt secondaria includendo il campo KERB-KEY-LIST-REQ nella parte PADATA della richiesta e poi ottenere un TGT completo firmato con la chiave krbtgt primaria includendo l'hash NT nella risposta.
Quando AzureAD genera un TGT parziale, utilizzerà i dettagli che ha sull'utente. Pertanto, se un Global Admin potesse modificare dati come l'identificatore di sicurezza e il nome dell'utente in AzureAD, quando richiede un TGT per quell'utente, l'identificatore di sicurezza sarebbe diverso.
Non è possibile farlo tramite Microsoft Graph o Azure AD Graph, ma è possibile utilizzare l'API che Active Directory Connect utilizza per creare e aggiornare utenti sincronizzati, che possono essere utilizzati dai Global Admins per modificare il nome SAM e il SID di qualsiasi utente ibrido, e poi se ci autentichiamo, otteniamo un TGT parziale contenente il SID modificato.
Nota che possiamo fare questo con AADInternals e aggiornare gli utenti sincronizzati tramite il cmdlet Set-AADIntAzureADObject.
Il successo dell'attacco e il conseguimento dei privilegi di Domain Admin dipendono dal soddisfacimento di determinati prerequisiti:
La capacità di alterare gli account tramite l'API di sincronizzazione è cruciale. Questo può essere ottenuto avendo il ruolo di Global Admin o possedendo un account di sincronizzazione AD Connect. In alternativa, il ruolo di Hybrid Identity Administrator sarebbe sufficiente, poiché consente di gestire AD Connect e stabilire nuovi account di sincronizzazione.
La presenza di un account ibrido è essenziale. Questo account deve essere modificabile con i dettagli dell'account vittima e deve anche essere accessibile per l'autenticazione.
L'identificazione di un account vittima target all'interno di Active Directory è una necessità. Sebbene l'attacco possa essere eseguito su qualsiasi account già sincronizzato, il tenant Azure AD non deve aver replicato gli identificatori di sicurezza on-premises, necessitando la modifica di un account non sincronizzato per procurare il ticket.
Inoltre, questo account dovrebbe possedere privilegi equivalenti a quelli di Domain Admin ma non deve essere un membro dei gruppi tipici di amministratori AD per evitare la generazione di TGT non validi da parte del RODC di AzureAD.
L'obiettivo più adatto è l'account Active Directory utilizzato dal servizio AD Connect Sync. Questo account non è sincronizzato con Azure AD, lasciando il suo SID come obiettivo valido, e possiede intrinsecamente privilegi equivalenti a quelli di Domain Admin a causa del suo ruolo nella sincronizzazione degli hash delle password (supponendo che la Password Hash Sync sia attiva). Per i domini con installazione espressa, questo account è prefissato con MSOL_. Per altri casi, l'account può essere individuato enumerando tutti gli account dotati di privilegi di replica della directory sull'oggetto dominio.
Controllalo nel post originale: https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
