AD-ventures in offensive security – Parte 7/9 – Golden & Diamond Ticket
Disclaimer: Gli strumenti e le tecniche descritte in questa serie di articoli sono destinati esclusivamente a scopi educativi e di ricerca nel campo della sicurezza informatica. L’uso di tali strumenti e tecniche contro sistemi informatici senza il consenso esplicito del proprietario è illegale e può comportare gravi conseguenze legali. L’autore e gli editori declinano qualsiasi responsabilità per l’abuso o l’uso improprio di queste informazioni da parte degli utenti. Si consiglia vivamente di ottenere il consenso scritto prima di condurre qualsiasi tipo di test o di valutazione della sicurezza su sistemi informatici.
Questo articolo è parte della serie AD-ventures: La battaglia per la sicurezza di Active Directory – ICT Power
Nell’articolo precedente abbiamo parlato di Pass-The-Hash, una tecnica che consente di accedere a servizi basati su autenticazione Kerberos sfruttando i ticket di un utente ed utilizzandoli per autenticarsi senza l’utilizzo della password. Con questo articolo continuiamo ad analizzare i concetti di autenticazione parlando di una ulteriore tecnica.
Il Golden Ticket è una delle tecniche di attacco più temibili che sfrutta le vulnerabilità del protocollo di autenticazione Kerberos, utilizzato nelle reti Windows. Quando viene eseguito con successo, questo attacco consente agli aggressori di ottenere un accesso pressoché illimitato all’intero dominio di un’organizzazione. L’obiettivo principale di questo attacco è quello di creare una persistenza all’interno dell’infrastruttura della vittima sfruttando l’account krbtgt, componente critica del sistema Kerberos, che gestisce, come sappiamo, la creazione e la firma di tutti i ticket di autenticazione.
In questo articolo analizzeremo in dettaglio come funzionano il Golden ed il Diamond Ticket, come gli attaccanti li utilizzano in scenari pratici, come difendersi da queste tecniche ed alcune considerazioni strategiche per proteggere al meglio le reti aziendali.
Golden Ticket e Diamond Ticket
Il Golden Ticket è un attacco che prende di mira il protocollo di autenticazione Kerberos, un sistema utilizzato per l’autenticazione all’interno di reti Windows. Ricordiamo che Kerberos si basa sull’utilizzo di ticket, emessi da un server centrale chiamato Domain Controller (DC), che permettono a utenti e servizi di autenticarsi senza dover continuamente immettere la propria password. Il ticket principale, noto come Ticket Granting Ticket (TGT), è firmato con la chiave dell’account krbtgt del dominio, un account di servizio utilizzato per crittografare e decrittografare i TGT.
L’attaccante che intende creare un Golden Ticket deve prima compromettere un sistema nella rete bersaglio e acquisire privilegi di amministratore di dominio. Questo livello di accesso consente all’attaccante di estrarre l’hash NT (NTHash) dell’account krbtgt, insieme all’Identificatore di Sicurezza (SID) del dominio. Questi due elementi sono cruciali perché permettono di creare un Golden Ticket valido, un TGT forgiato che funziona come se fosse stato emesso legittimamente dal DC.
Figura 1 – Golden Ticket
Una volta creato, il ticket può essere utilizzato ripetutamente, senza necessità di compromessi ulteriori, fornendo all’attaccante un controllo prolungato nel tempo.
Una variante di questa tecnica è il Diamond Ticket, un metodo simile che prevede la modifica dei campi di un TGT esistente, invece di crearne uno ex novo, e di utilizzarlo per l’accesso a servizi. Questo rende il Diamond Ticket più difficile da individuare, poiché sfrutta un ticket effettivamente emesso dal Domain Controller. Questa è una variante più complessa e sofisticata del classico attacco Golden Ticket, utilizzata per manipolare il protocollo Kerberos in un modo ancora più sottile e difficile da rilevare.
Differenze chiave tra Golden Ticket e Diamond Ticket
-
Creazione vs. Modifica:
- Il Golden Ticket è un TGT completamente creato dall’attaccante utilizzando l’NTHash dell’account krbtgt e il SID del dominio. Questo ticket forgiato permette all’attaccante di accedere a qualsiasi risorsa di rete come se fosse un utente legittimo.
- Il Diamond Ticket, invece, non viene creato ex novo. Piuttosto, l’attaccante modifica un TGT autentico emesso da un Domain Controller. L’idea è quella di alterare determinati campi del ticket, come i privilegi dell’utente o la durata del ticket, mantenendo intatta la firma del Domain Controller.
-
Precisione:
- Mentre il Golden Ticket può essere utilizzato in modo più generico per ottenere accesso amministrativo completo, il Diamond Ticket è spesso usato per operazioni più mirate. Ad esempio, l’attaccante potrebbe voler ottenere l’accesso a una risorsa specifica o alterare i privilegi di un utente senza destare sospetti.
-
Rilevabilità:
- Il Golden Ticket può essere rilevato più facilmente dai sistemi di monitoraggio se l’attaccante non è attento a camuffare le sue attività. In genere, le durate insolitamente lunghe del ticket o le richieste di autenticazione anomale possono indicare la presenza di un Golden Ticket.
- Il Diamond Ticket è molto più difficile da rilevare, poiché il ticket utilizzato è tecnicamente legittimo.
Funzionamento
Per quanto riguarda il Golden Ticket:
- Compromissione iniziale: Un attaccante ottiene accesso iniziale alla rete bersaglio tramite phishing, exploit o vulnerabilità nel software. Una volta all’interno, l’attaccante eleva i propri privilegi fino a ottenere accesso come amministratore di dominio.
- Estrazione dell’NTHash dell’account krbtgt: Utilizzando strumenti come Mimikatz, l’attaccante estrae l’NTHash dell’account krbtgt dal Domain Controller. Questo hash è essenziale per firmare i TGT forgiati e farli apparire legittimi.
- Ricavare il SID del dominio: Oltre all’hash della password dell’utente krbtgt, l’attaccante ha bisogno dell’Identificatore di Sicurezza (SID) del dominio, una stringa che rappresenta l’identità del dominio. Questo può essere facilmente ottenuto con strumenti di amministrazione, ad esempio PowerShell.
- Creazione del Golden Ticket: Con queste informazioni, l’attaccante utilizza strumenti come Mimikatz o Rubeus per creare un Golden Ticket. Questo ticket forgiato poteva includere qualsiasi identità (anche un amministratore di dominio) e avere una durata personalizzata. Dal 2022, con l’introduzione di una patch relativa alla PAC validation (più precisamente con la KB5008380) e successive integrazioni, l’identità tendenzialmente utilizzata da questo tipo di tecnica è l’amministratore di dominio Administrator.
- Utilizzo del Golden Ticket: Una volta creato, il Golden Ticket viene iniettato nel contesto della sessione dell’attaccante, permettendogli di ottenere accesso a qualsiasi risorsa all’interno del dominio, inclusi file, server e controller di dominio. Questo tipo di attacco non richiede ulteriori compromissioni della rete: il Golden Ticket resta valido finché l’hash della password dell’utente krbtgt non viene cambiato.
Per quanto riguarda il Diamond Ticket i primi tre passi sono i medesimi. Successivamente:
- Modifica del TGT: Invece di creare un TGT forgiato da zero, come accade con il Golden Ticket, l’attaccante utilizza un TGT autentico e ne modifica alcuni campi. Ad esempio, potrebbe alterare la durata di validità del ticket, oppure i privilegi associati all’utente, garantendo a sé stesso o a un altro account l’accesso a risorse aggiuntive o privilegi amministrativi.
- Utilizzo del Diamond Ticket: Poiché questo è firmato correttamente dal Domain Controller, viene accettato come valido da qualsiasi risorsa di rete che verifica i TGT tramite Kerberos. L’attaccante può quindi accedere a sistemi critici, dati sensibili o altre risorse senza sollevare sospetti.
Primo esempio: Golden Ticket
Un attaccante può creare un Golden Ticket per impersonare un amministratore di dominio ed accedere ai dati critici in server protetti, estrarre informazioni sensibili, come documenti riservati o segreti commerciali, e installare backdoor per un accesso futuro.
Supponiamo che, utilizzando una delle tecniche già viste nelle precedenti puntate, siamo riusciti ad ottenere un accesso sul Domain Controller con un Domain Admin. In questo caso, l’utente in questione è “dcaldarelli”.
Figura 2 – Accesso con Domain Admin
Eseguiamo mimikatz con i privilegi dell’utente in corso utilizzando il comando
mimikatz.exe “lsadump::dcsync /user:LAB\krbtgt”
Figura 3 – Recupero informazioni su KRBTGT
In questo modo abbiamo recuperato diverse informazioni. Quelle che ci servono sono le seguenti:
- FQDN del dominio
- Il SID del dominio
- L’hash della password in AES-256 dell’utente KRBTGT.
A questo punto possiamo proseguire con l’attacco utilizzando, ad esempio, una macchina Kali Linux. Possiamo utilizzare diversi strumenti, tra cui impacket.
Il comando necessita di diversi parametri:
impacket-ticketer -aesKey [HASH in AES256 della password dell’utente KRBTGT] -domain-sid [SID del dominio] -domain [FQDN del dominio] -user-id 500 [Username dell’utente].
Eseguiamo, quindi:
impacket-ticketer -aesKey 24e4a8119a75b876af3ee4d32839832409e18658cfe5af3e01fd7633d4f124da -domain-sid S-1-5-21-3339080808-936048312-3877283591 -domain lab.local -user-id 500 Administrator
Figura 4 – Creazione Golden Ticket
A questo punto è necessario creare una variabile d’ambiente relativa alla posizione del ticket appena creato con il comando
export KRB5CCNAME=[PATH ASSOLUTO]/Administrator.ccache
Infine, eseguiamo un tentativo di connessione al Domain Controller utilizzando PsExec con il comando
impacket-psexec lab.local/Administrator@dc01 -k -no-pass
Figura 5 – Accesso al Domain Controller tramite Golden Ticket
Il gioco è fatto! L’utente che stiamo utilizzando è SYSTEM sul Domain Controller.
Secondo esempio: Diamond Ticket
Utilizzando le stesse informazioni carpite, nell’esempio precedente, relativamente all’utente KRBTGT.
Supponiamo di essere in possesso delle credenziali di un utente amministratore locale di una VM a dominio. Tentiamo di accedere tramite protocollo CIFS al DC, ovviamente senza riuscirci.
Figura 6 – Tentativo di accesso al Domain Controller con utente amministratore locale
A questo punto, con l’utilizzo del tool Rubeus, richiediamo un ticket per l’utente Administrator, Domain Admin, e tentiamo di modificarlo in modo da poterlo impersonare con il nostro attuale account, “lab\utente” (con davvero poca fantasia), amministratore locale.
Il comando da utilizzare è il seguente:
Rubeus.exe diamond /domain:DOMAIN /user:USER /password:PASSWORD /dc:DOMAIN_CONTROLLER /enctype:AES256 /krbkey:HASH /ticketuser:USERNAME /ticketuserid:USER_ID /groups:GROUP_IDS
Figura 7 – Creazione Diamond Ticket
Osservando l’output di Rubeus possiamo notare le fasi di decodifica, modifica e crittografia del ticket. Infine, l’output in base64.
Figura 8 – Creazione Diamond Ticket
Non ci resta che copiare il ticket ed utilizzarlo per poter utilizzare il protocollo CIFS nell’accesso al Domain Controller
.\Rubeus.exe asktgs /ticket:[Ticket in BASE64] /service:cifs/dc01.lab.local /ptt /nowrap
Figura 9 – Injection Diamond Ticket
Rimanendo nella stessa sessione, verifichiamo l’accesso tramite CIFS
Figura 10 – Accesso al Domain Controller utilizzando il Diamond Ticket
Perfetto! Stiamo impersonando l’utente Administrator, Domain Admin, sul Domain Controller.
Come difendersi
Proteggersi da un attacco Golden Ticket richiede un approccio olistico che combini strategie di prevenzione, rilevamento e risposta:
- Rotazione dell’account krbtgt: Il modo più efficace per invalidare un Golden Ticket è cambiare l’hash dell’account krbtgt. Tuttavia, questo deve essere fatto in maniera controllata, poiché il cambio può causare interruzioni temporanee nei processi di autenticazione. Le best practices Microsoft suggeriscono di effettuare due reset della password dell’utente KRBTGT distanziate da almeno 10 ore. La rotazione dell’hash dovrebbe avvenire regolarmente, idealmente ogni 180 giorni o subito dopo la scoperta di una violazione.
- Monitoraggio del traffico di autenticazione: Il monitoraggio del traffico Kerberos può aiutare a rilevare anomalie. Ad esempio, l’uso di un TGT con una durata insolitamente lunga o richieste di autenticazione per account amministrativi in orari atipici può indicare un tentativo di Golden Ticket. I seguenti Event ID sono piuttosto esplicativi nella ricerca di questo tipo di tecnica:
- Event ID 4769: Audit Kerberos Service Ticket Operation. Fornisce informazioni sul tipo di crittografia utilizzata per forgiare il ticket. Se l’attaccante non ha preso le dovute attenzioni, il ticket non viene criptato con AES(128 e 256) (cosa che accade già da Windows Server 2008) ma con RC4, un algoritmo più debole ed obsoleto. I campi da guardare, in questo caso, sono Ticket Options e Ticket Encryption Type.
Figura 11 – EventID 4769
- Event ID 4627: Audit Group Membership. Questo ID fornisce informazioni sul SID dell’utente e sull’appartenenza a specifici gruppi utili nell’analisi di questi scenari d’attacco.
- Event ID 4624: Audit Logon. Questo ID fornisce informazioni relative all’utente (SID) e relativo IP. Questo potrebbe indicare un host compromesso.
- Implementazione di Privileged Access Management (PAM): Limitare l’accesso privilegiato attraverso soluzioni PAM può ridurre il rischio che un attaccante ottenga i diritti di amministratore di dominio, rendendo molto più difficile creare un Golden Ticket.
- Segregazione dei privilegi: Ridurre al minimo il numero di amministratori di dominio e utilizzare account separati per compiti amministrativi e quotidiani può limitare l’esposizione in caso di compromissione.
- Rafforzamento del Domain Controller: È cruciale proteggere i Domain Controller implementando controlli avanzati come la crittografia, firewall specifici e politiche di accesso rigorose. Qualsiasi compromissione del DC rappresenta una grave minaccia per la sicurezza del dominio.
- Aggiornamenti e patching regolari: Anche se l’utilizzo di questa tecnica non implica la presenza di vulnerabilità e l’utilizzo di exploit, mantenere i sistemi aggiornati è una delle misure preventive più semplici ma efficaci per ridurre le superfici d’attacco.
Difendersi dal Diamond Ticket
Difendersi da un Diamond Ticket è una sfida più complessa rispetto al Golden Ticket, proprio per la difficoltà nel rilevarlo. Tuttavia, esistono misure che possono essere implementate per mitigare i rischi:
- Monitoraggio avanzato: Poiché il Diamond Ticket altera campi specifici di un TGT legittimo, è necessario monitorare attentamente qualsiasi attività che comporti l’elevazione dei privilegi, soprattutto se riguarda utenti che normalmente non dovrebbero avere quei privilegi. Le soluzioni di Security Information and Event Management (SIEM) e l’analisi comportamentale degli utenti (UEBA) possono aiutare a individuare comportamenti sospetti.
- Gestione delle chiavi di sessione: Implementare una rotazione regolare delle chiavi di sessione utilizzate per firmare i TGT può rendere più difficile per un attaccante mantenere il controllo su un Diamond Ticket.
- Protezione del Domain Controller: Anche nel caso del Diamond Ticket, il punto chiave è proteggere il Domain Controller. Restrizioni di accesso rigorose, auditing continuo e l’utilizzo di meccanismi di protezione avanzati possono ridurre la superficie di attacco e prevenire che un attaccante possa compromettere il Domain Controller o accedere alle chiavi di sessione.
- Controlli sui privilegi: La riduzione del numero di utenti con privilegi di amministratore di dominio e l’utilizzo di account separati per attività amministrative e quotidiane possono ridurre le opportunità per un attaccante di compromettere la rete e utilizzare il Diamond Ticket.
Considerazioni
Il Golden Ticket rappresenta una minaccia persistente e difficile da rilevare. La sua forza risiede nella capacità di fornire all’attaccante un accesso continuativo alla rete bersaglio. Una volta che un attaccante ottiene l’accesso privilegiato al krbtgt, può muoversi nella rete quasi senza destare sospetti. Tuttavia, anche se il Golden Ticket è uno strumento potente, la sua efficacia dipende dalla capacità dell’attaccante di rimanere nascosto. Strategie di monitoraggio avanzato, come l’analisi comportamentale e il monitoraggio delle sessioni privilegiate, possono essere strumenti preziosi per individuare attività sospette.
Entrambe le tecniche sono state eseguite in un ambiente preparato allo scopo per cui alcune semplificazioni sono ovvie ed alcuni concetti sono stati dati per scontato, sia dal punto di vista offensivo che difensivo. Un esempio, parlando di difesa, è quello della rotazione delle password dell’utente krbtgt: è vero, il doppio cambio invalida eventuali ticket forgiati a mano, così come tutti gli altri. Prestare attenzione all’esecuzione di queste azioni è doveroso se si opera all’interno di una rete molto grande, con sistemi che contemplano varie tecnologie. Non rispettare le 10 ore di intervallo provocherebbe la disconnessione degli utenti. In questo scenario è necessario tenere in considerazione tutti quegli elementi che, ad esempio, utilizzano credenziali hardcoded o i cui processi di logon contemplano un riavvio, ad esempio, di web server o application server.
Conclusioni
Il Golden Ticket rappresenta una delle tecniche di attacco più sofisticate e pericolose all’interno del panorama delle minacce informatiche moderne. Attraverso la manipolazione del protocollo Kerberos, gli attaccanti possono ottenere un accesso illimitato alle risorse di rete. Tuttavia, esistono misure efficaci che possono essere adottate per difendersi, tra cui la rotazione dell’account krbtgt, il monitoraggio continuo delle autenticazioni e l’implementazione di soluzioni di gestione dei privilegi. È fondamentale che le organizzazioni comprendano la gravità di questa minaccia e adottino una strategia di sicurezza proattiva per ridurre il rischio di compromissioni di questo tipo.
Il Diamond Ticket rappresenta una minaccia ancora più sofisticata rispetto al Golden Ticket. La sua capacità di operare sfruttando TGT legittimi lo rende difficile da rilevare, richiedendo quindi misure di sicurezza avanzate e un monitoraggio continuo per proteggere le reti aziendali. Se un Golden Ticket fornisce un accesso illimitato e immediato, il Diamond Ticket offre agli attaccanti una via più sottile per muoversi lateralmente nella rete, incrementando i propri privilegi senza destare sospetti.
Come sempre abbiamo a disposizione tanti strumenti per migliorare le nostre infrastrutture, per prendercene cura. La consapevolezza deve essere il mantra del 2024, in modo da concentrare l’attenzione dove realmente è necessario.
Stay tuned!