• Guide, Sicurezza, Sistemi Operativi
• 4 Luglio 2024

Disclaimer: Gli strumenti e le tecniche descritte in questo articolo 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 Unquoted Service Path per capire come sia possibile sfruttare quelle configurazioni così puntuali da rendere vulnerabili determinati sistemi in modo così importante. Per continuare il nostro percorso, immaginando di aver ottenuto un accesso tramite Unquoted Service Path, utilizzeremo una tecnica denominata Kerberoasting che sfrutta il sistema di autenticazione Kerberos per effettuare azioni di Privilege Escalation o Lateral Movement.

Kerberos Authentication

Nell’universo di Active Directory, il protocollo Kerberos è colui che gestisce la stragrande maggioranza delle autenticazioni, sia per gli utenti che per i servizi. A differenza del vecchio sistema NTLM (di cui abbiamo visto qualcosa anche nel nostro percorso parlando di LLMNR/NTB-NS), basato su un processo di challenge-response, Kerberos introduce un metodo più elegante e raffinato: il sistema di ticket.

Il funzionamento è basato sostanzialmente su tre entità:

• Un client
• Un servizio
• Un gestore di chiavi che solitamente è all’interno di un Domain Controller negli ambienti Active Directory

Immaginate un utente che si sveglia al mattino e decide di accedere al suo computer. Invia una richiesta di accesso al Domain Controller, che nel mondo Kerberos è conosciuto come il Key Distribution Center
(KDC), una sorta di ufficio delle chiavi. Questa richiesta iniziale, chiamata Kerberos Authentication Service Request (KRB_AS_REQ), contiene un timestamp criptato. Questo timestamp viene creato usando lo username e l’hash della password dell’utente.

Quando il KDC riceve questa richiesta, tenta di decriptare il timestamp utilizzando l’hash della password dell’utente. Se riesce a farlo, bingo! L’utente è autentico.

Figura 1 – Kerberos Authentication Service Request

A questo punto, il KDC risponde con un messaggio chiamato Kerberos Authentication Service Reply (KRB_AS_REP) che contiene una chiave di sessione (session-key) criptata con l’hash della password dell’utente e un Ticket Granting Ticket (TGT), a sua volta contenente:

• Username dell’utente
• Indirizzo IP
• Periodo di validità del ticket
• Il Privilege Attribute Certificate (PAC) contenente molte informazioni sull’utente, come il SID oppure i gruppi di cui l’utente è membro

La session-key è una chiave di cifratura simmetrica temporanea utilizzata per proteggere la comunicazione tra un client ed un servizio, mentre il TGT è il biglietto d’ingresso per il parco divertimenti delle risorse di rete e viene criptato con una chiave segreta nota solo al KDC.

Una volta ricevuti session-key e il TGT, l’utente è autenticato e può procedere con le sue attività. Il TGT ha una validità di dieci ore (se si utilizzano le configurazioni di default) durante le quali l’utente può accedere alle risorse senza dover reinserire la password ogni volta.

Figura 2 – Kerberos Authentication Service Reply

Per quanto riguarda l’accesso ai servizi?

Ad alto livello possiamo immaginare un flusso come descritto nell’immagine che segue:

Figura 3 – Service Ticket

In questo caso il KDC entra in azione quando un utente desidera accedere a una risorsa aziendale con un Service Principal Name (SPN) registrato. Il client si mette al lavoro creando una Ticket Granting Service Request (KRB_TGS_REQ) composta da:

• lo username dell’utente ed il timestamp criptati con la session key
• il SPN della risorsa richiesta
• il TGT

Figura 4 – Kerberos Granting Service Request

A questo punto il KDC riceve la richiesta KRB_TGS_REQ e, se l’SPN esiste, effettua l’azione di decifratura del TGT utilizzando la chiave segreta. Se riesce, estrae la session-key e la utilizza per decifrare il nome utente e il timestamp presenti all’interno della richiesta. Se tutto va a buon fine, il KDC dà il via libera generando un Ticket Granting Service (TGS) ed inserendolo all’interno di una Ticket Granting Service Reply (KRB_TGS_REP) contenente:

• il SPN della risorsa
• la session-key per la comunicazione tra client e SPN
• un ticket di servizio (Service Ticket) con le informazioni dell’utente criptato con l’hash della password del service account

Figura 5 – Kerberos Ticket Granting Service Reply

Quest’immagine descrive i primi quattro passi:

Figura 6 – Kerberos Authentication

Dopo aver ricevuto il TGS grazie alla risposta del KDC (KRB_TGS_REP), l’utente è pronto per avviare il processo di autenticazione con il servizio. Per farlo invia una Application Request (KRB_AP_REQ) formata con le stesse informazioni utilizzate in precedenza: nome utente e timestamp, sempre criptati con la session-key associata al Service Ticket.

Quando il servizio riceve la richiesta (KRB_AP_REQ) decifra il ticket per validare l’utente. Dopo averlo fatto estrae lo username e session-key per l’ultima azione di verifica. Se tutto va a buon fine l’utente è autorizzato ad accedere alla risorsa desiderata.

Figura 7 – Kerberos Authentication

Apparentemente questo sistema sembra complesso ma porta notevoli benefici in termini di sicurezza. Questa è la versione implementata da Microsoft che lo ha introdotto da Windows 2000 e per i domini Active Directory. La prima versione fu sviluppata dal Massachusetts Institute of Technology (MIT) e solo nella versione 5 fu formalizzata nella RFC 1510 nell’ormai lontano 1993.

Ora che abbiamo visto una panoramica sul funzionamento di Kerberos possiamo ragionare in maniera differente, cercando qualcosa che può esserci utile dal punto di vista offensivo.

Kerberoasting

Kerberoasting è una tecnica di attacco usata nella fase di post-exploitation (quindi bisogna avere già un accesso valido) utilizzata per tentare di decifrare la password di un account di servizio all’interno di Active Directory. Può essere eseguita da qualsiasi utente all’interno del dominio, non necessariamente da un domain admin. In un attacco di questo tipo, un attaccante utilizza strumenti specifici per estrarre i ticket Kerberos criptati per poi tentare di decifrarli.

Un possibile scenario potrebbe essere composto dai seguenti passi:

• Ricerca di un SPN registrato: ad esempio relativo a SQL Server o Exchange Server
• Richiesta di TGS: richiesta al KDC di un TGS per tutti gli SPN di interesse. Se la richiesta viene effettuata con un utente valido (noi assumiamo di averlo ottenuto dopo aver sfruttato l’Unquoted Service Path nella puntata precedente oppure, come abbiamo visto nella seconda puntata, parlando di LLMNR/NTB-NS) il KDC non farà problemi nel rilasciare quanto richiesto
• Raccolta dei TGS: criptati con la password dell’account di servizio associato al SPN. Sono ciò che ci interessa.
• Attacco offline: con l’aiuto di tool specifici (e magari un po’ di GPU dedicata allo scopo) si tenta di decriptare i TGS per recuperare la password dell’account di servizio

Partiamo dalla ricerca dei vari SPN.

Figura 8 – Informazioni utente

Con il comando setspn.exe -Q */*

possiamo subito avere una panoramica dei vari SPN

Figura 9 – Enumerazione SPN

Possiamo verificare quali e quanti sono i ticket già presenti sulla macchina con il comando klist

Figura 10 – Enumerazione Ticket

Con queste due azioni notiamo già qualcosa di interessante: l’account “sqlservice”.

Esistono tanti metodi per portare a termine questa tipologia di attacco. Potremmo utilizzare Mimikatz per estrarre i ticket, potremmo utilizzare Rubeus o altri tool.

In questo caso utilizziamo EmpireProject che, nonostante non sia più supportato da molto tempo, offre molti tools interessanti come Invoke-Kerberoast.ps1, uno script in PowerShell che fa proprio al caso nostro.

Prese le dovute precauzioni (UAC, Defender, AMSI, ecc…) considerato l’attuale status di utente semplice sulla macchina, recuperiamo ed eseguiamo lo script con il comando

In questo modo effettueremo il download di ciò che ci serve direttamente da riga di comando.

Il risultato è il seguente

Figura 11 – Kerberoasting

A questo punto non ci resta che tentare di craccare questo hash utilizzando hashcat in una vm Kali Linux, inserendolo in un file di testo ed utilizzando una wordlist preparata allo scopo.

Figura 12 – Hash

Nel caso in cui una wordlist non si riveli utile è possibile comunque tentare la strada del brute force.

Figura 13 – Password cracking

Figura 14 – Password cracking

Perfetto: password trovata!

Come difendersi

Il registro eventi può aiutarci a capire cosa succede.

L’evento che ci interessa, e che ci permette di rilevare questa tecnica di attacco, ha ID 4769 e, per ovvie ragioni, è molto frequente.

Ciò a cui è necessario prestare attenzione sono i seguenti elementi:

• Il service name deve essere diverso da krbtgt
• Il service name non termina con “$”
• L’account name deve essere diverso da “macchina@dominio” (in modo da filtrare le richieste delle macchine”)
• Il Failure code “0x0”
• La tipologia di ticket encryption “0x17” – Crittografia RC4 più debole (obsoleta) di AES-256
• Il Ticket Options “0x40810000”

Figura 15 – EventID 4769

Utilizzare delle password complesse aiuta a mitigare questo tipo di problema, ad esempio utilizzando stringhe lunghe più di 25 caratteri.

Infine, possiamo utilizzare i Managed Service Account (sMSA). Sono account di dominio che si occupano della gestione delle password in maniera automatica, semplificando la gestione dei SPN e con la possibilità di delegare. Questa funzionalità è stata introdotta con Windows Server 2008 R2 e Windows 7.

Considerazioni

Questa tecnica è stata eseguita in un ambiente preparato allo scopo per cui alcune semplificazioni sono ovvie ed alcuni concetti sono stati dati per scontato.

Ciononostante, non è raro trovare configurazioni simili negli ambienti di produzione. Questa tecnica dimostra come le tecniche di cracking siano ancora efficaci in determinati contesti che, con il largo utilizzo delle GPU moderne, rendono l’argomento assolutamente non obsoleto.

Conclusioni

Gli utenti di servizio sono spesso gestiti in maniera superficiale. A seconda delle configurazioni e del livello di privilegi possono essere sfruttati per accedere ad informazioni o sistemi sensibili che si credevano al sicuro. Quanto affrontato oggi è solo la punta dell’iceberg: sono molte le tecniche che possono sfruttare l’hash di un utente, che non contemplano la fase di cracking e che rendono l’attaccante in grado di muoversi lateralmente o di ottenere maggiori privilegi. Alcune di queste le affronteremo prossimamente.

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!