Kerberoasting: crackare gli account di servizio senza toccarli
Kerberoasting è tra le tecniche più temute in un dominio Active Directory perché non sfrutta alcuna vulnerabilità: sfrutta il funzionamento previsto di Kerberos. Bastano credenziali valide di un utente qualsiasi — anche il più insignificante — e il resto avviene offline, sulla macchina dell'attaccante, invisibile agli agenti sull'endpoint del bersaglio.
Il pezzo di Kerberos che conta: il TGS
In Active Directory, quando un utente vuole usare un servizio (un database SQL, un web server interno, un file share) chiede al Domain Controller un service ticket, tecnicamente un TGS (Ticket Granting Service). Il DC glielo restituisce cifrato con la chiave a lungo termine dell'account di servizio, che è derivata direttamente dalla password di quell'account.
La logica è: solo il servizio, che conosce la propria password, può decifrare il ticket e fidarsi del suo contenuto. Ma il DC non verifica che chi chiede il ticket abbia il diritto di parlare con quel servizio. Rilascia il ticket a chiunque lo chieda. E il ticket, una volta in mano tua, è cifrato con qualcosa che puoi attaccare a forza bruta.
Gli SPN sono la mappa dei bersagli
Ogni account di servizio kerberizzato ha uno o più SPN (Service Principal Name) registrati nel suo attributo LDAP. Un account utente normale non ne ha; un account di servizio sì. Quindi il primo passo è banale: chiedi a LDAP tutti gli utenti con un SPN.
# enumerazione: utenti con SPN = candidati al roasting
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName
# o con impacket, da Linux, con sole credenziali di dominio:
GetUserSPNs.py DOMINIO/utente:password -dc-ip 10.0.0.1 -requestIl flag -request fa in un colpo solo le due cose: trova gli account
con SPN e chiede il TGS per ognuno.
Il ticket diventa un hash da craccare
Lo strumento estrae la parte del ticket cifrata con la chiave dell'account e la
formatta come un hash offline (formato $krb5tgs$). Da lì è un normale
attacco a dizionario/forza bruta, senza più alcun contatto con il dominio:
hashcat -m 13100 hashes.txt wordlist.txt -r rules/best64.ruleIl modo 13100 è proprio Kerberoasting con cifratura RC4. Ogni
tentativo è: prendi una password candidata, derivane la chiave NTLM, prova a
decifrare il ticket, e vedi se la struttura interna è ben formata. Milioni di
tentativi al secondo su una GPU.
Perché RC4 è il regalo
Kerberos supporta più tipi di cifratura per i ticket. Con RC4-HMAC (etype 23) la chiave è l'hash NTLM della password, e il crack è velocissimo. Con AES (etype 17/18) la derivazione della chiave passa per 4096 iterazioni di PBKDF2, che rallentano il brute-force di ordini di grandezza. Molti attaccanti forzano esplicitamente la richiesta in RC4 se il dominio lo permette ancora, proprio per questo. Disabilitare RC4 nel dominio è una delle mitigazioni più efficaci.
Perché è così difficile da rilevare
- La richiesta di un TGS è un'operazione legittima e continua: succede migliaia di volte al giorno in un dominio sano. Un roasting si nasconde nel rumore di fondo.
- Il crack avviene offline: dopo aver ottenuto i ticket, l'attaccante può scollegarsi. Nessuna telemetria sull'endpoint del servizio.
- L'unico segnale utile è l'evento 4769 (richiesta di service ticket) sul DC, filtrato per etype RC4 e per un singolo account che chiede molti SPN diversi in poco tempo. È un segnale debole, non un allarme certo.
La difesa vera
Poiché l'attacco è brute-force offline, la difesa è rendere il brute-force impraticabile:
- Password lunghe e casuali per gli account di servizio: 25+ caratteri generati a macchina. Una passphrase da 30 caratteri casuali sconfigge qualsiasi dizionario e rende il brute-force AES economicamente assurdo.
- Group Managed Service Accounts (gMSA): Windows genera e ruota automaticamente una password da 120 caratteri che nessun umano conosce. È la soluzione strutturale: rende il roasting inutile perché non c'è nulla da craccare in tempi umani.
- Disabilita RC4 a livello di dominio, forzando AES.
- Rimuovi gli SPN inutili: ogni SPU su un account con privilegi è un bersaglio. Gli account di servizio non dovrebbero mai essere in Domain Admins.
La lezione più ampia: in Active Directory la superficie d'attacco più preziosa non sono i bug, ma le configurazioni legittime. Kerberoasting, AS-REP roasting, delega non vincolata, ACL deboli — sono tutte funzioni del protocollo usate contro chi le ha lasciate aperte.