L’attacco Kerberoasting spiegato: da un normale utente AD a Domain Admin

Affidateci un solo account di dominio valido su quasi qualunque rete Active Directory e ci sono buone probabilità che ne usciamo con la password di un account di servizio prima di pranzo. Nessun exploit. Nessun malware. Nessun diritto di amministratore. Solo Kerberos che fa esattamente ciò per cui è stato progettato. Questo è un attacco Kerberoasting, e resta una delle vie più affidabili da un utente qualsiasi fino a Domain Admin in cui ci imbattiamo nei test interni.

A renderlo ostinato è il fatto che non esiste una patch. La debolezza è un mucchio di account di servizio con password deboli, scelte da esseri umani e mai ruotate, poste dietro un protocollo che consegnerà a qualsiasi utente autenticato il materiale necessario a decifrarle. Un attacco Kerberoasting è silenzioso, paziente e quasi interamente offline. È proprio questa combinazione la ragione per cui i difensori continuano a non accorgersene.

Di seguito ripercorriamo come funzionano i ticket di servizio Kerberos, perché un Service Principal Name (SPN) mette gli account di servizio nel mirino, come l’attacco si concatena verso il dominio completo e le mitigazioni che sopravvivono davvero all’impatto con la produzione. La tecnica corrisponde a MITRE ATT&CK T1558.003.

Punti chiave

• Un attacco Kerberoasting consente a qualsiasi utente di dominio autenticato di richiedere ticket di servizio Kerberos per gli account dotati di un SPN e poi di decifrare quei ticket offline per recuperare la password in chiaro. Non servono privilegi elevati.
• Il ticket è cifrato con una chiave derivata dalla password dell’account di servizio, quindi le password deboli o vecchie cadono in fretta di fronte a hashcat, soprattutto quando RC4 (tipo di cifratura 0x17) è ancora consentito.
• Gli account di servizio sono abitualmente sovra-privilegiati, perciò una sola password decifrata spesso significa amministratore locale su molti host, accesso a dati sensibili o una via diretta verso Domain Admin.
• Il rilevamento si basa sulle anomalie dell’evento Kerberos 4769 (richieste RC4, volume elevato da un singolo utente) e su account SPN esca che nessun servizio reale dovrebbe mai interrogare.
• La soluzione duratura sono i group Managed Service Accounts (gMSA) oppure password casuali di 25 caratteri o più, l’imposizione di AES, la potatura degli SPN inutilizzati e il privilegio minimo sostenuto da una segmentazione degli amministratori (admin tiering).

Che cos’è un attacco Kerberoasting?

Un attacco Kerberoasting è una tecnica di cracking delle password offline rivolta agli account di servizio di Active Directory. Qualsiasi utente di dominio può chiedere a un Domain Controller un ticket di servizio per un qualunque account dotato di un SPN registrato. Parte di quel ticket è cifrata con una chiave derivata dalla password dell’account di servizio. L’attaccante afferra il ticket, se ne va e decifra la password per forza bruta sul proprio hardware, senza toccare mai più il Domain Controller.

Il pericolo sta nell’asimmetria. Richiedere un ticket è un’azione normale che ogni postazione di lavoro compie centinaia di volte al giorno, quindi si confonde con il rumore di fondo. Il cracking avviene sull’hardware dell’attaccante, invisibile ai vostri log. E gli account che più probabilmente portano un SPN, come SQL Server, i pool di applicazioni IIS e vari servizi HTTP o MSSQL, sono di solito quelli con gli accessi più ampi e le password più vecchie. È la peggiore combinazione possibile.

Come funzionano davvero i ticket di servizio Kerberos?

L’autenticazione Kerberos ha tre parti in movimento: il client, il Key Distribution Center (KDC, che risiede su ogni Domain Controller) e il servizio di destinazione. Quando accedete, il client invia un AS-REQ e riceve in risposta un Ticket Granting Ticket (TGT) nell’AS-REP. Il TGT è la prova di chi siete.

Quando volete raggiungere un servizio, il client presenta quel TGT e invia un TGS-REQ che indica lo SPN, ad esempio MSSQLSvc/db01.acme-corp.local:1433. Il KDC risponde con un TGS-REP che contiene un ticket di servizio. Ecco il dettaglio che conta: il ticket è cifrato con la chiave a lungo termine dell’account proprietario dello SPN. Per RC4, quella chiave è letteralmente l’hash NT dell’account. Per AES, è una chiave derivata dalla password e da un sale.

Ora la parte che gli attaccanti adorano. Il KDC non verifica mai se siete davvero autorizzati a usare il servizio. Controlla solo che possediate un TGT valido, poi restituisce un ticket cifrato con la chiave dell’account di servizio. L’autorizzazione avviene più tardi, al servizio stesso. Perciò il KDC consegnerà volentieri a qualsiasi utente autenticato un blob cifrato derivato dalla password di un qualunque account di servizio. Basta chiederlo con gentilezza, e risponde di sì.

Che cos’è uno SPN e perché gli account di servizio sono il bersaglio?

Un Service Principal Name è una stringa univoca che collega un’istanza di servizio all’account che la esegue, così che Kerberos sappia quale chiave usare quando cifra il ticket. Anche gli account computer hanno SPN, ma le loro password sono lunghe stringhe casuali che ruotano da sole, il che le rende di fatto indecifrabili. I bersagli facili sono gli account utente con SPN: gli account di servizio del dominio che un essere umano ha creato e configurato a mano.

È lì che si concentra il rischio. Nei nostri interventi troviamo regolarmente account di servizio con password impostate cinque o più anni fa, scelte da un amministratore che voleva qualcosa di memorizzabile e spesso riutilizzate tra un ambiente e l’altro. Le eccezioni alla policy sulle password sono qui la norma, perché “l’applicazione si rompe se la password ruota.” Trovare questi account è banale per qualsiasi membro del dominio, dato che gli SPN sono attributi di directory leggibili. Una singola riga li fa emergere:

# Native, no tooling required
setspn -Q */*

# Impacket, from a non-domain-joined attacker box
GetUserSPNs.py acme-corp.local/lowpriv:'Password123' -dc-ip 10.0.0.10 -request

# Or on-host with Rubeus
Rubeus.exe kerberoast /outfile:hashes.txt

Come funziona l’attacco Kerberoasting passo dopo passo?

L’attacco è breve e non richiede altro che un account di dominio funzionante. Enumerare gli account dotati di un SPN, richiedere un TGS per ciascuno, estrarre la porzione cifrata di ogni ticket e poi decifrarla offline. Quattro mosse, e solo le prime due toccano la rete.

La fase di richiesta è quella in cui Rubeus e il GetUserSPNs di Impacket svolgono il loro lavoro. Interrogano la directory alla ricerca di oggetti utente con l’attributo servicePrincipalName impostato, lanciano un TGS-REQ per ciascuno e formattano i ticket restituiti in stringhe pronte per hashcat. La maggior parte degli strumenti consente anche di forzare RC4 per riottenere il tipo di hash più rapido, che è esattamente il comportamento che un difensore può sorvegliare. Un hash Kerberoast RC4 inizia con $krb5tgs$23$; AES256 torna nella forma $krb5tgs$18$.

La fase di cracking è puro calcolo offline. I ticket RC4 usano la modalità hashcat 13100. I ticket AES sono più lenti, ma si sgretolano comunque di fronte a una lista di parole decente, con le modalità 19600 (AES128) e 19700 (AES256).

# RC4 (etype 23 / 0x17) - fastest to crack
hashcat -m 13100 hashes.txt rockyou.txt -r rules/best64.rule

# AES256 (etype 18) - slower, still viable against weak passwords
hashcat -m 19700 hashes.txt rockyou.txt

Notate che nulla richiama il Domain Controller mentre il cracking è in corso. Una volta catturati i ticket, l’attaccante può staccare il cavo di rete e continuare a macinare. Una password corta o basata su un dizionario può cadere in pochi minuti. Ecco perché la robustezza della password dell’account di servizio è tutto ciò che conta.

Perché le password deboli degli account di servizio rendono tutto questo così letale?

Perché l’intera difesa del ticket cifrato poggia sull’entropia della password, e su nient’altro. Kerberos non limita la frequenza dei tentativi offline. Non c’è alcun blocco dell’account. Non c’è alcun avviso una volta che il ticket ha lasciato il KDC. Una password di dieci caratteri costruita su una parola di dizionario e due cifre non è un dosso di fronte a una GPU moderna. Una password davvero casuale di 25 caratteri è un muro di mattoni.

Il riutilizzo e l’obsolescenza peggiorano la situazione. Le password degli account di servizio non cambiano quasi mai, quindi una che decifrate oggi può essere stata valida per anni, e valida contemporaneamente in test, staging e produzione. Abbiamo visto un solo account decifrato sbloccare decine di server semplicemente perché era stato inserito nel gruppo Administrators locale di ogni macchina su cui girava.

Come si concatena Kerberoasting fino a Domain Admin?

Decifrare la password è il punto di svolta, non il traguardo. Ciò che viene dopo dipende da quanto è privilegiato l’account, e gli account di servizio sono noti per l’accumulo di privilegi. Le catene che vediamo più spesso hanno questo aspetto:

• L’account è amministratore locale su molti host, quindi otteniamo l’esecuzione di codice ed estraiamo altre credenziali da LSASS su ciascuno, raccogliendo lungo il percorso sessioni di amministratore di dominio in cache.
• L’account è stato aggiunto direttamente a Domain Admins o a un gruppo altrettanto potente, di solito “per ora” durante una migrazione, e poi mai rimosso. È l’intero incarico riassunto in una riga.
• L’account detiene diritti di directory pericolosi, come la possibilità di reimpostare le password di altri utenti o di scrivere l’appartenenza a un gruppo, che BloodHound traccerà come un percorso verso il Tier 0.

Il punto è che un attacco Kerberoasting raramente si ferma a un solo account. È un punto d’appoggio che si trasforma in movimento laterale e poi in escalation dei privilegi, e i percorsi più brevi verso Domain Admin sono quasi sempre quelli di cui nessuno sospettava l’esistenza. BloodHound rende quei percorsi rapidi da trovare, per l’attaccante e per voi.

Come si rileva un attacco Kerberoasting?

Il rilevamento si concentra sulle richieste di ticket di servizio Kerberos, registrate come evento 4769 sui Domain Controller. Prese da sole, queste voci sono puro rumore. Il segnale sta nella forma. Tenete d’occhio un singolo account utente che richiede ticket per un gran numero di SPN distinti in una finestra temporale ristretta, e soprattutto le richieste che specificano RC4 (tipo di cifratura del ticket 0x17) in un ambiente che dovrebbe funzionare in AES. I client moderni negoziano AES per impostazione predefinita, quindi una raffica di richieste RC4 è una classica impronta di Kerberoasting.

Il controllo a segnale più forte che raccomandiamo è uno SPN esca. Predisponete un account utente civetta, collegategli uno SPN che non corrisponde ad alcun servizio reale, dategli una lunga password casuale e non toccatelo mai. Nessun processo legittimo dovrebbe mai richiederne il ticket, quindi un singolo 4769 che nomina quell’account è un indicatore di intrusione pressoché certo, con quasi nessun falso positivo. Abbinatelo a un avviso sui volumi anomali di RC4 e intercetterete gran parte del roasting opportunistico prima ancora che il cracking finisca.

Come si previene Kerberoasting?

La prevenzione si riduce a eliminare i due ingredienti: password deboli ed esposizione inutile. In ordine di priorità, ecco cosa consigliamo ai clienti.

• Passate ai gMSA. I Group Managed Service Accounts ricevono lunghe password casuali che il dominio ruota da solo, così i loro ticket sono di fatto indecifrabili. Migrate ogni account di servizio in grado di supportarne uno.
• Usate password lunghe e casuali dove i gMSA non sono adatti. Per gli account che devono restare oggetti utente standard, impostate una password casuale di 25 caratteri o più. A quella lunghezza, persino un ticket RC4 non vale la pena di essere decifrato.
• Imponete AES ed eliminate gradualmente RC4. Impostate msDS-SupportedEncryptionTypes solo su AES e ritirate RC4 in tutto il dominio. Rallenta ogni tentativo di cracking e trasforma ogni richiesta RC4 residua in un segnale di rilevamento pulito.
• Applicate il privilegio minimo. Togliete gli account di servizio da Domain Admins e dagli altri gruppi di Tier 0, concedete solo i diritti di cui il servizio ha realmente bisogno e verificate l’appartenenza ai gruppi di amministratori locali.
• Potate gli SPN obsoleti. Ogni SPN su un account utente è superficie di attacco. Rimuovete gli SPN dagli account che non eseguono più quel servizio.
• Adottate una segmentazione degli amministratori. Isolate le identità di Tier 0 affinché un account di servizio applicativo decifrato non possa mai raggiungere, in primo luogo, i controller di dominio o le credenziali di amministratore di dominio.

Come aiuta CyberXplore

Kerberoasting è una delle prime cose a cui ricorre il nostro team in qualsiasi intervento interno, perché è rapido, silenzioso e funziona molto spesso. La nostra valutazione di sicurezza di Active Directory mappa i vostri reali percorsi di attacco come farebbe un intruso: enumerando gli SPN, testando la robustezza delle password degli account di servizio e tracciando ogni catena che finisce a Domain Admin, per poi consegnarvi un elenco di correzioni prioritizzato costruito attorno ai gMSA, all’imposizione di AES e alla segmentazione. Se volete sapere se un solo utente colpito da phishing potrebbe impadronirsi dell’intero dominio, richiedete un preventivo e vi mostreremo esattamente fin dove arriva.

FAQ

Un attacco Kerberoasting richiede privilegi di amministratore?

No, ed è per questo che è ovunque. Qualsiasi account di dominio autenticato, compreso un utente con pochi privilegi o un servizio compromesso, può enumerare gli SPN e richiedere ticket di servizio. Il KDC non verifica l’autorizzazione prima di emettere il ticket, quindi non servono diritti speciali per andarsene con materiale decifrabile.

Il passaggio ad AES ferma completamente Kerberoasting?

No, ma aiuta parecchio. I ticket AES sono molto più lenti da decifrare rispetto a RC4, quindi una password robusta dietro AES è di fatto al sicuro. Detto questo, una password debole dietro AES può ancora cadere, perciò AES non sostituisce le password lunghe e casuali né i gMSA. Imporlo converte anche ogni richiesta RC4 residua in un segnale di rilevamento utile.

Quanto tempo occorre per decifrare un hash Kerberoast?

Dipende interamente dalla robustezza della password e dal tipo di cifratura. Un ticket RC4 debole costruito su una parola di dizionario può cadere in pochi secondi o minuti con una GPU moderna. Una password davvero casuale di 25 caratteri, o una password gMSA, non si decifrerà in alcun tempo realistico. Non c’è alcun blocco lato server a rallentare l’attaccante, quindi l’entropia è l’unica difesa che conta.

Qual è la differenza tra Kerberoasting e AS-REP roasting?

Entrambi decifrano materiale Kerberos offline, ma colpiscono cose diverse. Kerberoasting (T1558.003) attacca gli account di servizio dotati di SPN decifrando i ticket di servizio. L’AS-REP roasting (T1558.004) prende di mira gli account che hanno la pre-autenticazione Kerberos disabilitata e decifra invece l’AS-REP. L’AS-REP roasting può essere eseguito senza alcuna credenziale valida, purché si conosca un nome utente bersaglio.

I gMSA sono davvero immuni a Kerberoasting?

A fini pratici, sì. Una password gMSA è un lungo valore casuale che il dominio ruota automaticamente, quindi, anche se il suo ticket può essere richiesto e catturato, decifrarlo è impraticabile. L’unica avvertenza: chiunque riceva il diritto di leggere la password gestita del gMSA può recuperarla direttamente, perciò custodite con cura quel permesso.

Come posso verificare se il mio dominio è vulnerabile?

Eseguite un’enumerazione controllata degli account con SPN e valutate la robustezza delle loro password, idealmente nell’ambito di una valutazione completa di Active Directory. Il GetUserSPNs di Impacket o Rubeus faranno emergere ogni account decifrabile, e gli SPN esca insieme al monitoraggio dell’evento 4769 vi diranno se sono già in corso tentativi. Farlo come esercizio autorizzato vi dà la stessa visione che ottiene un attaccante, prima che se la prenda lui.