~/docs/golden-ticket.krbtgt

Il Golden Ticket in Active Directory, proprio come ne la fabbrica di cioccolato di Willy Wonka, garantisce al portatore un accesso illimitato a tutte le risorse della nostra Active Directory. Un attacco Golden Ticket abusa del protocollo Kerberos il quale usa sistemi per crittografare e firmare i messaggi. Uno di questi è l’hash della password per l’utente KRBTGT, noto solo al Key Distribution Center (KDC), che viene utilizzato per emettere i ticket Kerberos necessari per accedere a sistemi e risorse. Se un attaccante compromette l’hash della password KRBTGT possiede questo “biglietto d’oro” con il quale può coniare nuovi biglietti Kerberos dando quindi il potere di accedere a qualsiasi risorsa.

Un passo indietro: come funziona kerberos?

Avevo già scritto in passato un articolo su come funzionano le autenticazioni kerberos, ve lo lascio qui se siete interessati ad approfondire.

Volendo riassumere, con kerberos, gli utenti non si autenticano mai direttamente ai vari servizi che devono utilizzare. Al contrario, il Kerberos Key Distribution Center (KDC) funziona come un servizio di autenticazione di terze parti attendibile. Ogni controller di dominio esegue un servizio KDC.

Nello specifico, quando un utente si autentica, il KDC emette un Ticket Granting Ticket (TGT), che include una chiave di sessione univoca e un timestamp che specifica per quanto tempo la sessione è valida (di default 10 ore). Quando l’utente ha bisogno di accedere alle risorse non deve ripetere l’autenticazione: il client invia il TGT per dimostrare che l’utente è già stato autenticato.

È importante sottolineare che, prima di inviare un TGT, il KDC lo crittografa utilizzando l’hash della password di un account speciale, l’account KRBTGT. L’hash della password è condiviso tra tutti i controller di dominio di Active Directory in modo che possano leggere i TGT che ricevono quando gli utenti richiedono l’accesso a varie risorse.

Come difendersi

Per prima cosa c’è da rispondere a questa domanda: quando è stata l’ultima volta che hai resettato la password dell’utente krbtgt? Se non sai la risposta allora, con ogni buona probabilità, siamo davanti al primo segnale d’allarme (cit).

Come ci siamo detti, l’account KRBTGT è un account predefinito che funge da account di servizio per il servizio Key Distribution Center (KDC): questo account non può essere eliminato, il nome dell’account non può essere modificato o abilitato e viene creato automaticamente quando viene creato un nuovo dominio.

Poco fa ho scritto che prima di inviare il TGT il KDC “lo crittografa utilizzando l’hash della password per un account speciale”. Bene: l’hash dell’account in questo è proprio il KRBTGT.

Per verificare quanto è stata l’ultima volta che avete cambiato la passowrd dell’utente krbtgt, da powershell, si può dare il comando

PS C:\> Get-ADUser "krbtgt" -Property Created, PasswordLastSet

Nella pratica

Pertanto, la prima strategia di difesa contro gli attacchi Golden Ticket è cambiare regolarmente la password KRBTGT. Sia ben chiaro che ciò non impedisce ad un attaccante di creare ticket, ma invalida quelli già presenti se mai ce ne fossero. Microsoft consiglia cambi regolari della password ogni 180 giorni.

Altro consiglio che mi sento di dare è quello di cambiare la password dell’utente krbtgt ogni volta che un un amministratore lascia l’organizzazione. Anche se si elimina l’account dell’amministratore dimissionario, l’utente potrebbero aver lasciato dei TGT che si potrebbero ancora utilizzare: reimpostare la password KRBTGT renderà tutti questi ticket non validi.

NOTA BENE: il valore della cronologia delle password per l’account KRBTGT è 2, il che significa che include le due password più recenti. Pertanto, per invalidare tutti i TGT attualmente presenti nel sistema, è necessario reimpostare la password due volte. A questo link c’è descritta la procedura manuale, ma è altamente consigliato eseguire questo script il quale automatizza tutti i passaggi ed esegue il cambio in maniera presidiata e sicura previa analisi e conferma che tutti i requisiti a procedere siano affermativi.

Altra cosa, il privilegio minimo è una pietra miliare della sicurezza: assicurarsi di disporre solo di un gruppo definito di amministratori di dominio, nonché di membri di altri gruppi che forniscono diritti di accesso ai controller di dominio. Se trovi altri account al di fuori della tua lista con accesso a questi dati critici allora c’è da indagare immediatamente e rimuovere eventuali autorizzazioni non necessarie.

Non concedere agli utenti finali privilegi di amministratore sulle loro workstation e non consentire agli amministratori di accedere ai computer degli utenti finali. In questo modo, un utente malintenzionato che riesce a prendere il controllo di un endpoint non troverà alcuna credenziale privilegiata da raccogliere e utilizzare.

Monitorare, monitorare e monitorare

Parti dal presupposto che il tuo ambiente sia compromesso e controlla sempre:

• qualsiasi ticket Kerberos che supera la policy di dominio per la durata massima di validità. Se ne dovessi trovare le cose da fare sono iniziare un’immediata indagine e reimpostare la password KRBTGT. Qua lascio un articolo dove spiega come controllare questo criterio.

• un’insolita attività di replica del dominio può indicare che qualcuno sta utilizzando DCSync o altre tecniche per rubare gli hash delle password
• presta attenzione a quali eseguibili e quali script (in particolare gli script di PowerShell) sono in esecuzione sui controller di dominio. A tal proposito avevo scritto un articolo dove parlavo di come abilitare il trascrizione degli script powershell per analisi ed indagini
• monitora le attività associate ad Active Directory e Keberos. Puoi controllare gli eventi Kerberos AS e TGS, gli eventi di accesso e disconnessione di Windows che contengono campi vuoti (ID evento 4769, 4624, 4672 e 4634) i quali possono essere indicatori di un golden ticket o di un’attività pass-the-ticket. Altri indicatori di un attacco golden ticket possono includere richieste di ticket TGS senza precedenti richieste TGT

Tecniche di attacco

Se siete arrivati fino a qui sapete come funziona kerberos e come questo si basi sul presupposto che qualsiasi TGT crittografato con l’hash della password di KRBTGT sia legittimo. Ma come funziona l’attacco?

In un attacco Golden Ticket, gli hacker aggirano il KDC e creano essi stessi TGT per ottenere l’accesso a varie risorse.

Per falsificare un TGT, gli hacker hanno bisogno di quattro informazioni chiave:

• L’FQDN (Fully Qualified Domain Name) del dominio
• Il SID (Security Identifier) del dominio
• Il nome utente dell’account che vogliono impersonare
• L’hash della password KRBTGT

Le prime tre informazioni sono semplici da reperire, la quarta un po’ meno in quanto, come abbiamo ripetuto alla neausea, per fare in modo che un ticket appaia legittimo ai controller di dominio, l’attaccante deve crittografarlo utilizzando l’hash della password KRBTGT.

Per farlo si possono seguire quattro potenziali strade, ad esempio:

• Sottraendo il file NTDS.DIT presente in tutti i controller di dominio al path C:\Windows\NTDS\. Chiunque abbia accesso a questo file può, col dovuto tempo e in un ambiente “sicuro”, crackare le credenziali offline. Comprese quelle dell’amministratore
• Usando tool come mimikatz per raccogliere ed elaborare le credenziali in uso in un sistema compromesso
• Compromettendo un PC di un utente dove un amministratore ha avuto precedentemente accesso
• Eseguendo un attacco di tipo “DCSync attack“.

DCSync attack

Su quest’ulima tecnica vale la pena soffermarsi un attimo. Gli ambienti Active Directory generalmente includono più controller di dominio che devono rimanere sincronizzati a vicenda sulle modifiche, ad esempio gli aggiornamenti delle credenziali utente.

In un attacco DCSync, un utente malevolo che ha ottenuto l’accesso a un account privilegiato con diritti di replica del dominio sovverte questa funzionalità fingendo di essere un DC e richiedendo gli hash delle password da un DC legittimo.

Conclusioni

L’amara verità, come è facile intuire, è che intercettare questi attacchi è complesso e non sempre possibile. Lascio qui una guida con dei buoni spunti e approfondimenti sulla questione, ma è bene tenere a mente che qualsiasi linea guida si voglia seguire non vi terrà mai al sicuro. Il consiglio è quello di tenere un calendario per schedulare periodicamente il cambio della password dell’utente krbtgt e monitorare con attenzione tutti gli eventi relativi a kerberos, oltre a mantenere aggiornata la lista degli utenti con privilegi amministrativi.

EOF