Durante gli audit di Active Directory, il Kerberoasting rientra tra gli attacchi verificati sistematicamente, tanto questa tecnica è efficace, rapida e discreta. In pochi secondi, un semplice account utente privo di qualsiasi privilegio può recuperare il necessario per craccare, offline e senza rumore, le password di account a volte molto potenti. Questo articolo ne descrive il funzionamento, il motivo per cui riesce così spesso e, soprattutto, come proteggersi.
Un po’ di Kerberos e di SPN
In un dominio Windows, l’autenticazione si basa su Kerberos, un protocollo fondato su ticket rilasciati dal domain controller. Il principio risale agli anni ’80 (il progetto Athena del MIT) e Microsoft lo ha adottato come meccanismo di autenticazione predefinito a partire da Windows 2000. Ogni servizio accessibile tramite Kerberos è identificato da un SPN, ovvero Service Principal Name, un’etichetta del tipo MSSQLSvc/serveur.entreprise.local:1433 che collega un servizio (un database SQL, un server web, una condivisione) a un account di servizio nella directory.
Come promemoria, un account di servizio è un account utente dedicato all’esecuzione di un’applicazione. Spesso dispone di diritti elevati e la sua password viene cambiata di rado, perché modificarla rischia di interrompere l’applicazione che ne dipende. È un segreto che invecchia male.
Perché gli account di servizio attirano così tanto
Questi account concentrano tutti i difetti che un attaccante cerca. Sono stati creati molto tempo fa, spesso durante l’installazione di un software, con una password scelta a mano da un amministratore di fretta. Questa password in genere non scade mai, perché una scadenza significherebbe un guasto applicativo. E per finire, questi account risultano spesso membri di gruppi altamente privilegiati, a volte Domain Admins, «giusto il tempo di far funzionare l’applicazione», e poi ci si dimentica di tornare indietro. Un attaccante lo sa e prende di mira in via prioritaria questi SPN.
Il meccanismo dell’attacco
Il punto chiave sta in una frase: qualsiasi utente autenticato del dominio può richiedere un ticket di servizio (un TGS, ovvero Ticket-Granting Service) per qualsiasi SPN. È un funzionamento perfettamente normale di Kerberos, non una vulnerabilità. Tuttavia, una parte di questo ticket è cifrata con una chiave derivata direttamente dalla password dell’account di servizio. Ottenendo il ticket si ottiene quindi un campione cifrato che si potrà attaccare con calma.
L’attaccante enumera gli SPN della directory, richiede i ticket corrispondenti e poi li estrae. Con GetUserSPNs.py, della suite Impacket, basta un solo comando da Linux:
GetUserSPNs.py entreprise.local/utilisateur:MotDePasse -request -outputfile tickets.txtLato Windows, lo strumento Rubeus fa la stessa cosa da una postazione già compromessa, ed è in grado di prendere di mira gli account più interessanti:
Rubeus.exe kerberoast /outfile:tickets.txtPunto cruciale: in nessun momento l’attaccante ha bisogno di scrivere sul domain controller né di testare password contro di esso. Tutto il cracking avviene poi sulla sua macchina, offline. Non ci sono quindi né account bloccati né picchi di autenticazioni fallite visibili nei log.
Il cracking offline
Una volta recuperati i ticket, l’attaccante li sottopone a uno strumento di cracking come hashcat. Il formato Kerberos TGS corrisponde alla modalità 13100:
hashcat -m 13100 tickets.txt dictionnaire.txt -r regles.ruleIl parametro -r applica un insieme di regole che riproduce le abitudini umane: maiuscola iniziale, cifra finale, sostituzioni classiche. Contro una password debole del tipo Serveur2021, il risultato arriva in pochi secondi su un semplice portatile dotato di scheda grafica. Ed è proprio qui il problema:
- gli account di servizio hanno spesso password corte, scelte da una persona anni fa;
- non vengono quasi mai rinnovate;
- cumulano privilegi elevati, a volte fino all’amministrazione completa del dominio.
Basta una sola password debole craccata e l’attaccante eredita direttamente i diritti dell’account, senza exploit né ulteriore privilege escalation. È una scorciatoia spettacolare tra «sono un utente qualsiasi» e «controllo la directory».
RC4, il carburante silenzioso dell’attacco
Un dettaglio tecnico aggrava spesso la situazione: per compatibilità, molti ticket sono ancora cifrati con l’algoritmo RC4, derivato dall’hash NTLM della password. E RC4 si presta particolarmente bene al cracking massivo. Imponendo l’uso di AES per gli account di servizio, il cracking diventa nettamente più oneroso. Gli strumenti di attacco lo sanno: Rubeus, per esempio, richiede volentieri ticket in RC4 quando sono disponibili, proprio perché sono più facili da trattare.
Cosa emerge sul campo
In una missione tipo, l’enumerazione fa emergere regolarmente diverse decine di SPN. Basta che uno solo corrisponda a un account con una password datata per aprire una breccia. Gli account di backup, di monitoraggio o di database ricorrono spesso, frequentemente dotati di privilegi elevati e protetti da una password che riprende il nome del produttore del software seguito da un anno. L’impatto sul business è immediato: chi controlla un account del genere controlla l’autenticazione di tutta l’azienda. La BOX Oxyscan individua proprio questi account di servizio esposti al Kerberoasting sull’intera directory, il che permette di correggerli prima che un attaccante li trovi.
Correggere la falla: passare agli account di servizio gestiti
Poiché il Kerberoasting non sfrutta un difetto software ma la debolezza di una password, la correzione consiste nel rendere questa password impossibile da craccare. Gli account di servizio gestiti di gruppo (gMSA, ovvero group Managed Service Accounts) rispondono esattamente a questa esigenza: la loro password è generata casualmente dal dominio, si estende su 240 byte e viene rinnovata automaticamente, senza alcun intervento umano. Un attaccante che recupera un ticket cifrato con un segreto simile può dedicarci tutte le schede grafiche che vuole, non lo ritroverà.
Come promemoria, è già il comportamento degli account macchina (quelli il cui nome termina con $): la loro password è casuale e molto lunga, il che li rende immuni al Kerberoasting. Il gMSA estende semplicemente questo principio agli account che eseguono i servizi applicativi.
L’implementazione si riduce a tre comandi PowerShell, lato domain controller. Si genera prima, una sola volta per tutto il dominio, la chiave radice del Key Distribution Service (KDS):
Add-KdsRootKey -EffectiveImmediatelyNonostante il nome, l’opzione -EffectiveImmediately rende la chiave utilizzabile solo dopo la sua replica su tutti i domain controller, con un ritardo di sicurezza che può arrivare a dieci ore. Questo ritardo va rispettato in produzione. Si crea poi l’account gestito, indicandone il nome DNS e l’host o gli host autorizzati a recuperarne la password:
New-ADServiceAccount -Name sql-service -DNSHostName sql-service.exemple.local -PrincipalsAllowedToRetrieveManagedPassword "GRP-SRV-SQL$"Quindi si installa l’account sulla macchina che eseguirà il servizio:
Install-ADServiceAccount sql-serviceResta solo da designare questo account come identità del servizio. In Server Manager si indica l’account gestito, riconoscibile dal suffisso $, come account personalizzato, qui per l’identità di un application pool IIS:
Non tutti i software sono ancora in grado di funzionare con un gMSA. Per questi casi residui la regola è duplice: una password di almeno venticinque caratteri, generata casualmente e conservata in un vault, e il rigoroso rispetto del principio del privilegio minimo, perché un account di servizio non ha quasi mai bisogno di appartenere ai Domain Admins. Si impone inoltre la cifratura AES dei ticket, molto più onerosa da craccare rispetto all’RC4 ereditato, e si monitorano le richieste anomale e numerose di ticket di servizio, spesso il primo segnale di una campagna di Kerberoasting in corso.
Conclusione
Il Kerberoasting non sfrutta un bug: sfrutta una password debole impostata su un account troppo potente. Per questo figura tra le tecniche più redditizie per un attaccante interno, e tra le più facili da trascurare sul fronte della difesa. La buona notizia è che le contromisure sono note, documentate (in particolare dal MITRE e dall’ANSSI) ed efficaci.
Consigli: assegnare agli account di servizio password molto lunghe (25 caratteri e oltre) o, meglio ancora, migrare agli account di servizio gestiti di gruppo (gMSA), la cui password viene rinnovata automaticamente dal dominio; applicare il principio del privilegio minimo (nessun account di servizio dovrebbe essere Domain Admin senza una solida giustificazione), imporre la cifratura AES invece di RC4 e monitorare le richieste massive di ticket TGS, spesso il primo segnale di un attacco in corso.
Per approfondire
- Consulenza e accompagnamento in cybersecurity Oxydian, per implementare l’hardening di una directory (gMSA, cifratura AES, privilegio minimo).
- Perché le password aziendali cadono durante gli audit, l’articolo dedicato al cracking offline e all’igiene dei segreti.
- MITRE ATT&CK, tecnica T1558.003 (Kerberoasting), descrizione, rilevamento e misure di mitigazione.
- ANSSI, raccomandazioni per la messa in sicurezza di una directory Active Directory.
- Microsoft Learn, panoramica dei group Managed Service Account (gMSA).
- hashcat, lo strumento di riferimento per il cracking offline (modalità 13100 per i ticket Kerberos).
- Suite Impacket (GetUserSPNs.py), il toolkit open source utilizzato per la raccolta dei ticket.
