Kerberoasting: cos’è, come funziona e come difendersi

Il Kerberoasting abusa di Kerberos per estrarre hash di password da Active Directory e craccarli offline. Scopri come funziona l’attacco e come difendersi.

Active Directory, qualsiasi utente di dominio, anche il più privo di privilegi, può richiedere un ticket Kerberos per accedere a un servizio. È un comportamento by design, parte integrante del funzionamento dell’autenticazione in rete. Il problema è che quel ticket viene cifrato con l’hash della password dell’account di servizio associato. Se quella password è debole, l’hash può essere craccato offline, lontano dai sistemi di monitoraggio, senza generare un solo evento di accesso fallito.

1. Cos’è il Kerberoasting
2. Come funziona il Kerberoasting
3. Il caso Ascension e la questione RC4
4. Come difendersi dal Kerberoasting

Questa è la logica alla base del Kerberoasting, un attacco che sfrutta l’abuso di un meccanismo legittimo. È per questo che rimane tra le tecniche di credential theft più efficaci e più usate nel 2026. Active Directory è presente nell’infrastruttura di oltre il 90% delle aziende Fortune 1000 e gli account di servizio con password deboli e mai ruotate sono ancora la norma in molti ambienti

Ma come sempre, andiamo con ordine e affrontiamo per gradi l’argomento.

Cos’è il Kerberoasting

Il Kerberoasting è una tecnica di post-exploitation che prende di mira gli account di servizio in ambienti Active Directory, sfruttando il protocollo Kerberos per estrarre hash di password craccabili offline. Per avviare l’attacco è sufficiente un qualsiasi account di dominio valido, anche il più ordinario.

I bersagli principali sono gli account che hanno un Service Principal Name (SPN) registrato. Un SPN è un identificatore univoco che associa un account di dominio a un servizio specifico, come un’istanza SQL Server, un server web o un servizio di backup. Quando un utente richiede un ticket Kerberos per accedere a quel servizio, il domain controller emette un Ticket Granting Service (TGS) cifrato con l’hash della password dell’account di servizio. L’attaccante estrae quel ticket e lo porta offline: da quel momento, il cracking avviene interamente sul proprio hardware, senza più interagire con la rete bersaglio.

A differenza di un attacco Pass-the-Hash, il Kerberoasting non richiede di compromettere prima un account privilegiato. Chiunque sia già dentro il dominio può eseguirlo. È questa accessibilità a renderlo una delle prime tecniche che un attaccante testa dopo aver ottenuto un accesso iniziale, spesso subito dopo una campagna di phishing o la compromissione di una credenziale esposta.

Come funziona il Kerberoasting

Per comprendere il funzionamento dell’attacco, procederemo a descriverlo tramite una simulazione completa ed esaustiva, suddivisa in quattro fasi.

Fase 1 – Accesso iniziale al dominio

L’attaccante che intende mettere a segno un attacco basato su Kerberoasting deve aver già ottenuto accesso a un account di dominio valido. L’accesso iniziale avviene tipicamente tramite phishing, credential stuffing su VPN o portali esposti, o acquisto di credenziali sul dark web. Una volta dentro il dominio, l’attaccante dispone di tutto il necessario per avviare la fase successiva.

Fase 2 – Enumerazione degli SPN

Con l’account di dominio a disposizione, l’attaccante interroga Active Directory via LDAP (Lightweight Directory Access Protocol) per identificare tutti gli account utente che hanno un SPN registrato. Questa operazione non richiede privilegi elevati, poiché qualsiasi utente autenticato può eseguire query LDAP sul dominio. Gli strumenti più usati in questa fase sono BloodHound per la visualizzazione delle relazioni di privilegio, GetUserSPNs.py di Impacket per l’enumerazione diretta, uniti a PowerView per le query PowerShell. Il risultato è una lista di account di servizio con i relativi SPN, da cui l’attaccante seleziona i bersagli più interessanti, quelli con privilegi elevati o con accesso a sistemi critici come SQL Server, sistemi di backup o domain controller.

Fase 3 – Richiesta e estrazione del TGS

Per ogni SPN identificato, l’attaccante usa le proprie credenziali per richiedere al KDC (Key Distribution Center) un Ticket Granting Service. Il domain controller emette il ticket senza verificare se l’utente richiedente abbia effettivamente i permessi per accedere al servizio. Si tratta di un comportamento legittimo e normalmente previsto dal protocollo. Il ticket viene cifrato con l’hash della password dell’account di servizio associato allo SPN. Con Rubeus, l’estrazione dei ticket avviene con un singolo comando:

Rubeus.exe kerberoast /outfile:tickets.txt

I ticket estratti vengono salvati in formato leggibile da strumenti di cracking. Da questo momento, l’attaccante non ha più bisogno di interagire con la rete bersaglio.

Fase 4 – Cracking offline del ticket

Con i ticket in mano, l’attaccante avvia il cracking offline usando strumenti come Hashcat o John the Ripper contro dizionari di password o in modalità brute force. Il tempo necessario dipende da due fattori: la lunghezza e la complessità della password dell’account di servizio, a cui si aggiunge l’algoritmo di cifratura usato per proteggere il ticket.

Se il cracking ha successo, l’attaccante ottiene la password in chiaro dell’account di servizio. A quel punto può autenticarsi come quell’account, accedere ai sistemi su cui ha privilegi e procedere con l’escalation verso il domain controller.

RC4 contro AES: perché l’algoritmo cambia tutto

L’algoritmo di cifratura usato per il TGS è il fattore più determinante nella resistenza al cracking. I ticket cifrati con RC4-HMAC (tipo di cifratura 0x17) usano una chiave derivata dall’hash NTLM della password dell’account, che Hashcat può attaccare a velocità molto elevate, nell’ordine di miliardi di tentativi al secondo su hardware moderno. I ticket cifrati con AES-256 (tipo 0x12) sono computazionalmente molto più resistenti, tant’è che la stessa macchina impiega un tempo enormemente superiore per lo stesso numero di tentativi.

Il problema è che, per retrocompatibilità, molti ambienti Active Directory accettano ancora RC4 come algoritmo di negoziazione. Quando un client richiede un TGS senza specificare una preferenza, il KDC può emettere il ticket in RC4. Questo significa che un attaccante può forzare attivamente la negoziazione RC4 durante la richiesta, ottenendo un ticket molto più vulnerabile anche in ambienti che teoricamente supportano AES. Strumenti come Rubeus permettono di specificare esplicitamente RC4 nella richiesta proprio per questo motivo.

Il caso Ascension e la questione RC4

Nel maggio 2024, il gruppo sanitario Ascension Health, uno dei più grandi negli Stati Uniti con 140 ospedali e oltre 134.000 dipendenti, è stato colpito da un attacco ransomware che ha causato settimane di disservizi, con sistemi clinici offline e interruzione delle operazioni in numerose strutture. Le indagini hanno stabilito che il vettore di accesso iniziale e di escalation dei privilegi includeva il Kerberoasting su ticket RC4, che ha permesso agli attaccanti di craccare le credenziali di account di servizio privilegiati e muoversi lateralmente fino ai sistemi critici.

Il caso è diventato un punto di riferimento nel dibattito sulla sicurezza di Active Directory. Nel 2025, il senatore statunitense Ron Wyden ha inviato una lettera alla FTC (Federal Trade Commission) citando esplicitamente Ascension come prova che Microsoft aveva mantenuto RC4 abilitato per default in Active Directory per ragioni di retrocompatibilità, esponendo milioni di organizzazioni a un rischio evitabile. Microsoft ha risposto affermando che RC4 rappresenta meno dello 0,1% del traffico Kerberos totale, una posizione criticata da molti ricercatori come fuorviante. Infatti, il dato percentuale non riflette la gravità delle conseguenze, se quell’0,1% riguarda account privilegiati.

A partire dal 2026, le nuove installazioni di Active Directory in ambienti Windows Server 2025 hanno RC4 disabilitato per default. La misura, tuttavia, non si applica retroattivamente ai domini esistenti, che mantengono RC4 abilitato per garantire la compatibilità con sistemi e applicazioni legacy. In assenza di un intervento esplicito degli amministratori, la stragrande maggioranza degli ambienti Active Directory oggi attivi rimane esposta.

Come difendersi dal Kerberoasting

La difesa contro il Kerberoasting richiede interventi su più livelli, dalla configurazione degli account di servizio al monitoraggio del traffico Kerberos.

• Usare password lunghe e complesse per tutti gli account di servizio.
  La resistenza al cracking dipende direttamente dalla complessità della password. Password di almeno 25 caratteri generate casualmente rendono il brute force computazionalmente impraticabile anche con RC4, indipendentemente dalla potenza hardware disponibile.
• Migrare da RC4 ad AES per l’autenticazione Kerberos.
  Configurare i domain controller e gli account di servizio per supportare esclusivamente AES-128 e AES-256, eliminando RC4 dalla negoziazione. Questa modifica richiede un’analisi di compatibilità preventiva per identificare eventuali sistemi legacy che richiedono ancora RC4.
• Adottare Group Managed Service Accounts (gMSA).
  I gMSA sono account gestiti automaticamente da Active Directory, con password di 240 caratteri randomizzati ruotate automaticamente ogni 30 giorni. Questa caratteristica li rende resistenti al Kerberoasting per design: anche se l’attaccante estrae il ticket, craccare una password di quella lunghezza è computazionalmente impossibile con gli strumenti attuali.
• Applicare il principio del minimo privilegio agli account di servizio.
  Gli account di servizio non devono avere privilegi superiori a quelli strettamente necessari per la loro funzione. Un account di servizio con diritti di Domain Admin è un bersaglio ad altissimo valore: se craccato, consegna all’attaccante il controllo dell’intero dominio.
• Monitorare l’Event ID 4769 con focus sul tipo di cifratura.
  Le richieste TGS vengono registrate nei log del domain controller con l’Event ID 4769. Il campo Ticket Encryption Type con valore 0x17 indica RC4: richieste multiple in rapida successione con questo valore da un singolo account non privilegiato sono un segnale di Kerberoasting in corso. Le soluzioni SIEM e le piattaforme di identity threat detection come Microsoft Defender for Identity rilevano automaticamente questi pattern anomali.
• Rimuovere gli SPN non necessari.
  Gli SPN inutilizzati o dimenticati su account privilegiati sono bersagli silenziosi. Un audit periodico degli SPN registrati nel dominio permette di identificare ed eliminare quelli non più necessari, riducendo la superficie di attacco.

In conclusione

Il Kerberoasting è efficace non perché sia sofisticato, ma perché sfrutta un meccanismo che nessuna organizzazione può semplicemente spegnere. Finché esistono account di servizio con password deboli e RC4 abilitato, chiunque abbia un account di dominio valido ha tutto il necessario per avviare l’attacco. Il caso Ascension del 2024 ha dimostrato dove questa catena può portare.

Nel 2026, la deprecazione di RC4 nelle nuove installazioni di Windows Server è un passo nella direzione giusta, ma non risolve il problema per i milioni di domini già esistenti. La risposta passa da password robuste, gMSA, disabilitazione esplicita di RC4 e un monitoraggio attivo del traffico Kerberos. Sono misure tecniche precise, non particolarmente complesse, ma che richiedono una decisione: agire prima che qualcuno lo faccia al posto nostro.