Punti chiave
- Il Kerberoasting è un attacco ad Active Directory: chi ha un qualsiasi account di dominio chiede ticket di servizio Kerberos e prova a ricavarne, fuori dalla rete, la password degli account di servizio.
- Funziona perché il ticket di servizio è cifrato con una chiave derivata dalla password dell'account che esegue il servizio, e qualsiasi utente di dominio può chiederlo.
- Sono esposti solo gli account con un SPN registrato; il rischio cresce con password corte, cifratura RC4 e privilegi elevati.
- Si rileva sui domain controller con l'evento 4769: richieste con cifratura RC4 (0x17), molte richieste in poco tempo dallo stesso utente, account di servizio chiesti fuori dal loro uso normale.
- Microsoft consiglia gMSA o dMSA, password lunghe e casuali dove non si possono usare, AES al posto di RC4 con cambio della password e la rimozione degli SPN che non servono.
- Dagli aggiornamenti di aprile 2026 i domain controller aggiornati assumono solo AES per gli account senza configurazione esplicita, salvo che l'amministratore abbia impostato diversamente il domain controller; una password debole resta comunque decifrabile anche con AES.
Il Kerberoasting è un attacco ad Active Directory in cui chi ha già un qualsiasi account di dominio chiede ticket di servizio Kerberos e li porta fuori dalla rete per indovinare, con calma, la password degli account di servizio. Funziona perché quei ticket sono cifrati con una chiave derivata dalla password dell'account. Si rileva sui domain controller con l'evento 4769 e si previene con account di servizio gestiti (gMSA), password lunghe e cifratura AES al posto di RC4.
Di seguito: come funziona l'attacco, perché è ancora efficace nel 2026, come lo si vede nei log e quali interventi riducono davvero il rischio. Non trovi istruzioni d'attacco: l'angolo è quello di chi gestisce il dominio.
Come funziona il Kerberoasting
Kerberos è il protocollo con cui Active Directory autentica utenti e servizi. Quando un utente vuole usare un servizio, per esempio un database SQL Server, chiede al domain controller un ticket di servizio (TGS). Il domain controller lo rilascia cifrato con una chiave derivata dalla password dell'account che esegue quel servizio, così solo il servizio può leggerlo.
Il servizio è identificato da un Service Principal Name (SPN), un nome registrato sull'account che lo esegue. Microsoft spiega che Active Directory rilascia ticket di servizio solo per gli account che hanno un SPN, e che qualsiasi utente con credenziali di dominio può chiedere ticket verso qualsiasi account di servizio. All'attaccante non servono privilegi particolari: gli basta il funzionamento normale del protocollo.
MITRE ATT&CK cataloga la tecnica come T1558.003, sotto-tecnica di Steal or Forge Kerberos Tickets nella tattica Credential Access. Lo schema, in sintesi, è questo:
- l'attaccante controlla già un account di dominio qualunque, per esempio dopo un phishing riuscito;
- chiede ticket di servizio per gli account con un SPN;
- porta i ticket fuori dalla rete e prova password candidate, una dopo l'altra, finché una non decifra il ticket;
- con la password trovata entra come account di servizio, con tutti i suoi privilegi.
Il passaggio decisivo è il terzo. Il tentativo di decifrare avviene su macchine dell'attaccante, quindi non genera accessi falliti, blocchi dell'account o altri segnali sul dominio. L'unica traccia che resta in rete è la richiesta dei ticket.
Perché funziona ancora
Il Kerberoasting è noto da anni, eppure resta una tecnica di uso comune. Nell'advisory AA23-278A sulle dieci configurazioni errate più frequenti (ottobre 2023), CISA e NSA lo indicano come una tecnica comune contro gli account di servizio e come uno dei modi più rapidi per elevare i privilegi e muoversi lateralmente in una rete. Fra i gruppi che lo hanno usato, MITRE elenca FIN7, Wizard Spider e APT29 durante la compromissione SolarWinds. Le ragioni sono tre, e di solito si presentano insieme.
1. Password scelte da persone, mai cambiate
Molti account di servizio hanno una password scelta a mano quando sono stati creati e cambiata di rado, perché cambiarla vuol dire toccare l'applicazione che li usa. Microsoft osserva che l'efficacia del Kerberoasting sta crescendo perché le GPU accelerano il cracking delle password. Nello stesso advisory CISA e NSA riportano che uno dei loro team ha decifrato oltre l'80% delle password degli utenti di un Active Directory in 12 ore: il dato riguarda tutte le password del dominio, non solo i ticket di servizio, ma dà la misura di quanto reggono le password scelte da persone.
Gli account macchina, invece, hanno password lunghe e generate a caso: per questo Microsoft li considera molto meno esposti al Kerberoasting.
2. La cifratura RC4
Il ticket può essere cifrato con RC4 o con AES. Secondo Microsoft RC4 è più vulnerabile perché, quando trasforma la password in chiave, non usa né salt né hash iterati, e questo permette di provare molte più password nello stesso tempo. MITRE descrive proprio questo caso: parti del ticket cifrate con RC4 (tipo di cifratura 23) usano l'hash della password dell'account di servizio come chiave.
3. Account di servizio con troppi privilegi
CISA e NSA notano che gli account di servizio hanno spesso privilegi elevati nel dominio per la natura del servizio che eseguono. Microsoft aggiunge che il Kerberoasting tende a colpire proprio account di questo tipo, che poi servono per distribuire rapidamente codice malevolo, ransomware compreso, su altri dispositivi della rete. Un account di servizio membro di Domain Admins con una password corta è la combinazione che trasforma un account utente compromesso nel controllo del dominio.
Cosa è cambiato con la dismissione di RC4 nel 2026
Microsoft sta togliendo RC4 come cifratura predefinita dei domain controller con gli aggiornamenti legati alla vulnerabilità CVE-2026-20833, che riguarda proprio il rischio di ottenere ticket con cifratura debole per attacchi offline. Le fasi, secondo la pagina di supporto Microsoft:
- gennaio 2026: gli aggiornamenti dal 13 gennaio aggiungono gli eventi di audit KDCSVC da 201 a 209 nel registro System dei domain controller, che segnalano dove RC4 è ancora in uso;
- aprile 2026: dagli aggiornamenti del 14 aprile il domain controller assume solo AES per gli account che non hanno una configurazione esplicita dei tipi di cifratura (attributo msDS-SupportedEncryptionTypes);
- luglio 2026: gli aggiornamenti tolgono il supporto alla chiave di registro (RC4DefaultDisablementPhase) che permetteva di tornare al comportamento precedente.
Il cambiamento aiuta, ma non chiude il tema per tre motivi. Vale solo sui domain controller aggiornati su cui l'amministratore non ha impostato a mano i tipi di cifratura predefiniti del dominio (valore di registro DefaultDomainSupportedEncTypes). Gli account su cui RC4 è stato abilitato in modo esplicito, magari per compatibilità con un'applicazione vecchia, continuano ad accettarlo. E Microsoft è chiara sul punto: AES da solo non basta, una password debole si decifra anche con AES. MITRE, tra l'altro, riporta che Wizard Spider ha sottratto hash AES.
Come si rileva il Kerberoasting
Siccome il cracking avviene fuori dalla rete, si può vedere solo la fase di richiesta dei ticket. Le fonti indicano tre segnali.
Evento 4769 con cifratura RC4
Il domain controller registra l'evento 4769 (A Kerberos service ticket was requested) ogni volta che riceve una richiesta di ticket di servizio. Secondo la documentazione Microsoft l'evento compare solo sui domain controller e dipende dalla sottocategoria di audit Audit Kerberos Service Ticket Operations: se l'audit non è attivo, l'evento non c'è. Il campo Ticket Encryption Type dice con quale cifratura è stato emesso il ticket: 0x17 è RC4-HMAC, 0x11 e 0x12 sono AES.
La strategia di rilevamento DET0157 di MITRE parte proprio da qui: richieste 4769 anomale con cifratura RC4 (0x17) sono un segnale da indagare. Dopo l'aggiornamento cumulativo del 14 gennaio 2025 l'evento porta anche campi nuovi, come ServiceSupportedEncryptionTypes e ServiceAvailableKeys, utili per capire quali account di servizio hanno ancora chiavi RC4.
Molte richieste in poco tempo
Un utente normale chiede ticket per i pochi servizi che usa. Chi fa Kerberoasting li chiede per molti account di servizio in una finestra breve. Microsoft e MITRE indicano entrambi questo schema: un singolo utente che richiede numerosi ticket di servizio per account esposti in poco tempo.
Account di servizio usati fuori dal loro schema
Il terzo segnale è contestuale: un account di servizio chiesto da un utente o da una macchina che non lo ha mai usato, o a un orario anomalo. La documentazione dell'evento 4769 mette gli account di servizio fra gli account ad alto valore da monitorare singolarmente, e suggerisce di confrontare l'indirizzo del client con un elenco di indirizzi ammessi.
Perché servono log centralizzati
Nessuno di questi segnali si vede guardando un domain controller alla volta. Servono i log di tutti i domain controller in un unico posto, una baseline di cosa è normale nel dominio e regole che correlino volume, cifratura e contesto: è il lavoro di un SIEM con qualcuno che legge gli alert. MITRE suggerisce anche di correlare le anomalie sui ticket con attività sospette sui processi degli endpoint, per esempio un accesso anomalo a LSASS.
Come si riduce il rischio di Kerberoasting
Le raccomandazioni di Microsoft, MITRE e CISA convergono. In ordine pratico:
- Fare l'inventario degli account con SPN. Microsoft raccomanda di verificare gli account utente che hanno un SPN e di rimuoverlo dove non serve. Ogni SPN superfluo è un bersaglio in più.
- Passare a gMSA o dMSA dove possibile. Con un group Managed Service Account è Windows a generare e cambiare la password: secondo Microsoft è lunga 120 caratteri, complessa e casuale, e per questo molto resistente ai metodi a forza bruta noti. I gMSA esistono da Windows Server 2012; i Delegated Managed Service Accounts (dMSA) sono arrivati con Windows Server 2025 e permettono di migrare gli account di servizio esistenti.
- Dove non si può, password lunghe e casuali. Microsoft indica un minimo di 14 caratteri, meglio di più e generati a caso; CISA, NSA e MITRE indicano idealmente 25 o più caratteri per gli account di servizio. Microsoft consiglia anche di vietare le password comuni e di verificare periodicamente quelle degli account di servizio, per sapere quali sono deboli.
- AES su tutti gli account di servizio, poi cambio della password. Dopo aver impostato AES (128 e 256 bit) sull'account, Microsoft raccomanda di cambiarne la password: senza il cambio, l'account può restare esposto. Gli eventi KDCSVC dei domain controller aggiornati aiutano a trovare chi usa ancora RC4 prima di toglierlo.
- Privilegi minimi. MITRE e CISA chiedono di limitare gli account di servizio ai privilegi strettamente necessari, fuori da gruppi come Domain Admins. Se un account viene comunque compromesso, il danno resta circoscritto.
- Monitoraggio continuo. Audit dell'evento 4769 attivo su tutti i domain controller, log centralizzati e regole sui tre segnali visti sopra.
I primi cinque punti sono interventi di configurazione che rientrano in un lavoro più ampio di hardening dei sistemi. Il sesto è operativo e non finisce mai.
Da dove partire
La prima domanda è semplice: quanti account del tuo dominio hanno un SPN, chi li gestisce e che password hanno? Molte aziende scoprono la risposta durante un penetration test interno, quando il tester parte da un account utente qualsiasi e arriva agli account di servizio. Meglio scoprirla prima, con un inventario e un controllo delle configurazioni.
Dopo l'inventario, l'ordine che regge è: togliere gli SPN inutili, spostare su gMSA gli account che lo permettono, allungare e rendere casuali le altre password, abilitare AES e cambiare le password, controllare i privilegi. In parallelo, verificare che l'audit dell'evento 4769 sia attivo e che i log arrivino a chi li analizza.
In sintesi: il Kerberoasting sfrutta il funzionamento normale di Kerberos per portare fuori dalla rete i ticket degli account di servizio e decifrarne la password. È efficace quando password deboli, RC4 e privilegi elevati si sommano. La dismissione di RC4 avviata da Microsoft nel 2026 riduce il rischio, ma non lo toglie: servono account di servizio gestiti o password lunghe e casuali, privilegi minimi e un monitoraggio dell'evento 4769 che qualcuno guardi davvero.
Se vuoi mettere in ordine identità e accessi, trovi come lavoriamo nella pagina identity management e compliance.