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
Fiducia
Quando viene stabilita una fiducia con Azure AD, viene creato un Read Only Domain Controller (RODC) nell'AD. L'account computer del RODC, chiamato AzureADKerberos$. Inoltre, viene creato un account krbtgt secondario 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 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 sono in quei gruppi. Quindi il nuovo account krbtgt, se compromesso, potrebbe essere utilizzato per impersonarli.
TGT Kerberos
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 locale (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.
NTLM
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 quindi ottenere un TGT completo firmato con la chiave krbtgt primaria includendo l'hash NT nella risposta.
Abuso della Fiducia 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 il SID e il nome dell'utente in AzureAD, quando richiede un TGT per quell'utente il SID 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 il 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 Set-AADIntAzureADObject cmdlet.
Prerequisiti dell'Attacco
Il successo dell'attacco e il conseguimento dei privilegi di Domain Admin dipendono dal soddisfacimento di determinati prerequisiti:
La capacità di modificare gli account tramite l'API di Sincronizzazione è cruciale. Ciò può essere ottenuto avendo il ruolo di Global Admin o possedendo un account di sincronizzazione AD Connect. In alternativa, il ruolo di Amministratore di Identità Ibrida sarebbe sufficiente, poiché concede la capacità di gestire AD Connect e stabilire 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. Anche se l'attacco può essere eseguito su qualsiasi account già sincronizzato, il tenant di Azure AD non deve aver replicato gli identificatori di sicurezza locali, rendendo 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 di 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 è sincronizzato con Azure AD, lasciando il suo SID come un obiettivo valido, e detiene intrinsecamente privilegi equivalenti a 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 express, questo account è prefisso con MSOL_. Per altre istanze, l'account può essere individuato enumerando tutti gli account dotati di privilegi di Replica Directory sull'oggetto dominio.
L'attacco completo
Controlla nell'articolo originale: https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/
Last updated
