Az - Cloud Kerberos Trust
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.
Informazioni di base
Trust
Quando viene stabilita una trust con Azure AD, viene creato un Read Only Domain Controller (RODC) nell'AD. L'account del computer RODC è chiamato AzureADKerberos$. Inoltre, viene creato un account krbtgt secondario chiamato krbtgt_AzureAD. Questo account contiene le chiavi Kerberos utilizzate per i ticket creati da Azure AD.
Pertanto, se questo account viene compromesso, potrebbe essere possibile impersonare qualsiasi utente... anche se questo non è vero perché a questo account è impedito di creare ticket per qualsiasi gruppo AD privilegiato comune come Domain Admins, Enterprise Admins, Amministratori...
Tuttavia, in uno scenario reale ci saranno utenti privilegiati che non fanno parte di quei gruppi. Quindi il nuovo account krbtgt, se compromesso, potrebbe essere utilizzato per impersonarli.
TGT di Kerberos
Inoltre, quando un utente si autentica su Windows utilizzando un'identità ibrida di Azure AD, Azure AD emetterà un ticket Kerberos parziale insieme al PRT. Il TGT è parziale perché AzureAD ha informazioni limitate sull'utente nell'AD locale (come l'identificatore di sicurezza (SID) e il nome).
Windows può quindi scambiare questo TGT parziale con un TGT completo richiedendo un ticket di servizio per il servizio krbtgt.
NTLM
Poiché potrebbero esserci servizi che non supportano l'autenticazione Kerberos ma NTLM, è possibile richiedere un TGT parziale firmato utilizzando una chiave krbtgt secondaria che include il campo KERB-KEY-LIST-REQ nella parte PADATA della richiesta e quindi ottenere un TGT completo firmato con la chiave krbtgt primaria includendo l'hash NT nella risposta.
Abuso della Trust di Kerberos Cloud per ottenere Domain Admin
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 sarà diverso.
Non è possibile farlo tramite il Microsoft Graph o l'Azure AD Graph, ma è possibile utilizzare l'API Active Directory Connect utilizzata per creare e aggiornare gli utenti sincronizzati, che può essere utilizzata dai Global Admin per modificare il nome SAM e SID di qualsiasi utente ibrido, e quindi se ci autentichiamo, otteniamo un TGT parziale contenente il SID modificato.
Si noti che possiamo fare ciò con AADInternals e aggiornare gli utenti sincronizzati tramite il cmdlet Set-AADIntAzureADObject.
Prerequisiti dell'attacco
Il successo dell'attacco e il conseguimento dei privilegi di Domain Admin dipendono dal soddisfacimento di determinati prerequisiti:
È fondamentale avere la capacità di modificare gli account tramite l'API di sincronizzazione. Ciò può essere ottenuto avendo il ruolo di Global Admin o possedendo un account di sincronizzazione AD Connect. In alternativa, sarebbe sufficiente il ruolo di Hybrid Identity Administrator, in quanto consente di gestire AD Connect e creare nuovi account di sincronizzazione.
È essenziale la presenza di un account ibrido. Questo account deve essere modificabile con i dettagli dell'account vittima e deve essere accessibile per l'autenticazione.
È necessario identificare un account vittima target all'interno di Active Directory. Sebbene l'attacco possa essere eseguito su qualsiasi account già sincronizzato, il tenant di Azure AD non deve avere identificatori di sicurezza replicati in locale, il che rende necessaria la modifica di un account non sincronizzato per ottenere il ticket.
Inoltre, questo account dovrebbe possedere privilegi equivalenti a Domain Admin ma non deve essere membro dei gruppi amministratori AD tipici per evitare la generazione di TGT non validi da parte del RODC di AzureAD.
Il target più adatto è l'account Active Directory utilizzato dal servizio di sincronizzazione AD Connect. Questo account non viene sincronizzato con Azure AD, lasciando il suo SID come un obiettivo valido, e detiene implicitamente privilegi equivalenti a Domain Admin a causa del suo ruolo nella sincronizzazione degli hash delle password (a condizione che Password Hash Sync sia attivo). Per i domini con installazione espressa, questo account ha il prefisso MSOL_. Per altre istanze, l'account può essere individuato enumerando tutti gli account dotati di privilegi di replica della directory sull'oggetto del dominio.
L'attacco completo
Controlla l'articolo originale: https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/
Last updated