Kerberoasting: Steal or Forge Kerberos Tickets — Kerberoasting (T1558.003)

Il Kerberoasting è uno dei primi passi post-compromise in qualsiasi engagement Active Directory, e per buone ragioni: è silenzioso, non richiede privilegi elevati e produce risultati tangibili. La catena operativa si sviluppa in tre fasi: enumerazione degli SPN, richiesta dei TGS ticket e cracking offline degli hash.

Fase 1 — Enumerazione e richiesta ticket con Impacket (open source). Da una macchina Linux con accesso di rete al domain controller, Impacket è il punto di partenza naturale. Il modulo GetUserSPNs combina enumerazione e richiesta in un unico passaggio:

impacket-GetUserSPNs DOMINIO/utente:password -dc-ip 10.0.0.1 -request -outputfile kerberoast_hashes.txt

Questo comando si autentica al DC, enumera tutti gli account utente con SPN registrato (escludendo gli account macchina, già protetti da password complesse generate automaticamente) e richiede un TGS per ciascuno. L'output viene formattato direttamente per Hashcat o John the Ripper. Se si dispone di un TGT già ottenuto via pass-the-ticket, si può usare il flag -k -no-pass per autenticarsi via Kerberos senza password in chiaro.

Fase 2 — Approccio Windows con Rubeus (open source). Quando si opera da una sessione su un host Windows joined al dominio, Rubeus offre granularità superiore:

Rubeus.exe kerberoast /stats

Questo primo comando restituisce una panoramica degli account kerberoastable, indicando il tipo di cifratura supportato — informazione cruciale per prioritizzare i target. Gli account che supportano solo RC4 sono i più vulnerabili. Per la richiesta effettiva:

Rubeus.exe kerberoast /format:hashcat /outfile:hashes.txt

Rubeus utilizza il metodo KerberosRequestorSecurityToken.GetRequest per le richieste, integrandosi nativamente con le API Windows. Per evitare detection basate su volume, si può operare su singoli SPN con il flag /spn:MSSQLSvc/dbserver.dominio.local:1433.

Fase 3 — Alternative PowerShell. Il modulo Invoke-Kerberoast di PowerSploit (open source) — lo stesso utilizzato da Empire (open source) — offre un'opzione fileless:

Invoke-Kerberoast -OutputFormat Hashcat | Select-Object -ExpandProperty Hash

Fase 4 — Cracking offline. Con Hashcat (open source) gli hash di tipo Kerberos 5 TGS-REP etype 23 corrispondono al mode 13100:

hashcat -m 13100 hashes.txt wordlist.txt -r rules/best64.rule

Un buon dizionario combinato con regole di mutazione può spezzare password deboli in minuti. Per account di servizio configurati con password forti (25+ caratteri), il cracking diventa computazionalmente proibitivo — motivo per cui la mitigazione funziona. Brute Ratel C4 (a pagamento) offre una funzionalità integrata che decodifica i ticket Kerberos 5 e li converte direttamente in formato Hashcat, eliminando passaggi intermedi. Anche SILENTTRINITY (open source) contiene un modulo dedicato al Kerberoasting, utile come alternativa C2-native.

La detection del Kerberoasting ruota attorno a un evento cardine: l'Event ID 4769 nel Security log di Windows, che registra ogni richiesta di Kerberos Service Ticket. Il problema è che questo evento si genera migliaia di volte al giorno in qualsiasi ambiente Active Directory — ogni autenticazione a un servizio lo produce. La chiave è filtrare il rumore con precisione chirurgica.

Il primo indicatore ad alta fedeltà è il tipo di cifratura. Nelle infrastrutture moderne, la cifratura AES (etype 0x11 o 0x12) dovrebbe essere lo standard. Una richiesta TGS con etype 0x17 (RC4) rappresenta un'anomalia significativa, perché i client moderni negoziano automaticamente AES quando disponibile. I tool di Kerberoasting forzano deliberatamente RC4 perché l'hash risultante è più veloce da crackare. La regola di detection principale dovrebbe quindi filtrare gli eventi 4769 dove il campo Ticket Encryption Type è 0x17 e il campo Service Name non è krbtgt.

Il secondo indicatore è il volume di richieste. Un utente normale richiede TGS per i servizi che effettivamente utilizza — poche decine al giorno, con pattern prevedibili. Un attaccante che enumera tutti gli SPN genera decine o centinaia di richieste in una finestra temporale ristretta. Per configurare questa soglia è necessario stabilire una baseline: monitora per due settimane il numero medio di richieste TGS per account, poi imposta l'alert a 3 deviazioni standard sopra la media. I parametri di tuning chiave sono:

• TGSRequestThreshold: numero di richieste TGS per account in una finestra temporale (partire da 15-20 richieste in 10 minuti)
• AllowedEncryptionTypes: etype consentiti nell'ambiente (idealmente solo 0x11 e 0x12)
• ServiceAccountBaselines: SPN normalmente richiesti da ciascun account
• TimeWindow: finestra di correlazione per burst di richieste (5-15 minuti)

Il terzo livello di detection è la correlazione con Sysmon. L'Event ID 1 (Process Create) può rivelare l'esecuzione di tool noti: processi come Rubeus.exe, caricamento di System.IdentityModel.dll da PowerShell (usata da Invoke-Kerberoast), o invocazioni sospette di klist.exe. L'Event ID 10 (Process Access) con target lsass.exe da processi inattesi segnala possibili interazioni dirette con il sottosistema Kerberos, pattern tipico di Mimikatz.

Per i falsi positivi, le fonti principali sono: applicazioni legacy che richiedono RC4 per compatibilità, scansioni di vulnerability assessment che enumerano SPN, e account di monitoring che interrogano servizi multipli. La strategia è creare una whitelist di account e host autorizzati a generare volumi elevati di richieste TGS, revisionandola trimestralmente. Uno strumento complementare efficace è Purple Knight (freemium) di Semperis, che consente audit periodici degli account con SPN esposti e cifratura debole, permettendo di ridurre la superficie d'attacco prima ancora che la detection entri in gioco.

L'analisi forense di un Kerberoasting ha un vantaggio rispetto a molte altre tecniche: il protocollo Kerberos lascia tracce strutturate e timestamped nei log di sicurezza del domain controller. Il punto di partenza è sempre il Security Event Log del DC, dove ogni Event ID 4769 registra account richiedente, SPN target, indirizzo IP sorgente e tipo di cifratura.

La ricostruzione della timeline inizia estraendo tutti gli eventi 4769 con etype 0x17 in un intervallo temporale sospetto. Il campo Account Name identifica l'account compromesso usato dall'attaccante, mentre Client Address rivela l'host da cui è partita la richiesta. Un pattern tipico mostra lo stesso account che richiede TGS per numerosi SPN diversi in una finestra di pochi minuti — un comportamento che un account legittimo non produce praticamente mai.

Sul workstation sorgente, gli artefatti dipendono dal tool utilizzato. Se l'attaccante ha usato Rubeus, la memoria del processo contiene i ticket in formato kirbi e l'hash estratto. Un dump della memoria con strumenti come Volatility 3 (open source) può rivelare stringhe compatibili con hash Kerberos 5 (identificabili dal prefisso $krb5tgs$23$). Per operazioni PowerShell-based come Invoke-Kerberoast, i log di PowerShell Script Block Logging (Event ID 4104) catturano il contenuto completo dello script eseguito, inclusi i parametri e l'output.

I log Sysmon sull'endpoint arricchiscono ulteriormente la timeline. L'Event ID 1 fornisce la command line completa del processo, con hash e parent process — essenziale per ricostruire la catena di esecuzione. Se Sysmon era configurato con il monitoraggio degli accessi a processo (Event ID 10), qualsiasi interazione con lsass.exe da parte di tool come Mimikatz sarà registrata con il relativo GrantedAccess mask.

Un artefatto spesso trascurato sono i file di output. Tool come Impacket scrivono gli hash su file di testo; Rubeus può fare lo stesso con il flag /outfile. L'analisi del filesystem tramite la MFT (Master File Table) e i $UsnJrnl permette di identificare la creazione di file sospetti anche se successivamente cancellati. Cerca file con estensioni .txt o .hash creati in prossimità temporale degli eventi 4769 anomali, specialmente nelle directory temp o nella working directory dell'utente compromesso.

Per le campagne documentate, il pattern forense è coerente. Durante la SolarWinds Compromise (C0024), APT29 ha ottenuto TGS ticket per SPN di Active Directory e li ha crackati offline — il che implica esfiltrazione degli hash verso infrastruttura esterna. Durante Operation Wocao (C0014), gli attori hanno utilizzato specificamente il modulo Invoke-Kerberoast di PowerSploit, lasciando tracce nei log PowerShell. Le Leviathan Australian Intrusions (C0049) hanno impiegato la tecnica come parte di una catena più ampia di credential capture focalizzata sull'esfiltrazione di credenziali valide.

Il Kerberoasting rappresenta un punto di convergenza tattico dove gruppi APT con motivazioni e sofisticazione molto diverse si incontrano sullo stesso terreno operativo. La tecnica è attraente universalmente: basso rischio di detection, nessun prerequisito di privilegio elevato, e potenziale per escalation significativa.

Wizard Spider (G0102) è il gruppo che mostra la maggiore maturità tecnica nell'esecuzione del Kerberoasting. Il loro arsenale include Rubeus, il modulo Kerberos di Mimikatz e il cmdlet Invoke-Kerberoast — tre tool distinti per la stessa tecnica, il che suggerisce ridondanza operativa deliberata. Significativo che il gruppo punti al furto di hash AES e non solo RC4: questo indica consapevolezza che molti ambienti moderni hanno disabilitato RC4, e che gli hash AES, sebbene più costosi da crackare, possono comunque essere vulnerabili a password deboli. Wizard Spider, noto per le operazioni ransomware (Ryuk, Conti), utilizza il Kerberoasting come trampolino verso il domain dominance necessario per il deployment ransomware su larga scala.

FIN7 (G0046), gruppo a motivazione finanziaria, adotta un approccio più snello basato su comandi PowerShell come Invoke-Kerberoast. L'uso esplicito per abilitare il lateral movement conferma il ruolo del Kerberoasting nella loro catena d'attacco: compromissione iniziale → Kerberoasting → credenziali di servizio → movimento laterale verso sistemi con dati finanziari. La preferenza per PowerShell è coerente con il profilo operativo di FIN7, che storicamente predilige tool living-off-the-land e fileless.

Indrik Spider (G0119) ha condotto attacchi Kerberoasting utilizzando un modulo scaricato da GitHub, suggerendo un approccio più opportunistico. Questo pattern — scaricare tool pubblici piuttosto che sviluppare capability custom — posiziona Indrik Spider a un livello di sofisticazione inferiore rispetto a Wizard Spider su questa specifica tecnica.

Dal punto di vista delle campagne, la distribuzione geografica è notevole. La SolarWinds Compromise (C0024), condotta da APT29 e attribuita all'SVR russo, ha colpito organizzazioni in Nord America, Europa, Asia e Medio Oriente — il Kerberoasting serviva per espandere l'accesso post-compromise supply chain. Operation Wocao (C0014), con possibile overlap con APT20 e sospetta matrice cinese, ha colpito target in 10 paesi tra governi, MSP e settori critici. Le Leviathan Australian Intrusions (C0049) si sono concentrate sull'Australia con focus sull'esfiltrazione di dati sensibili e credenziali valide.

Il trend emergente è chiaro: il Kerberoasting non è più appannaggio di pentest e red team, ma è strumento operativo standard per APT di primo livello in operazioni di spionaggio e cybercrime. La convergenza tra gruppi russi (APT29), cinesi (Leviathan, possibile APT20) e cybercriminali (Wizard Spider, FIN7, Indrik Spider) sulla stessa tecnica suggerisce che qualsiasi organizzazione con Active Directory è potenzialmente nel mirino. La contromisura più efficace — password di servizio lunghe e cifratura AES obbligatoria — riduce drasticamente l'utilità della tecnica indipendentemente dall'attaccante.

Framework MITRE ATT&CK v16 — T1558.003 (Kerberoasting), TA0006. Campagne: C0049 (Leviathan Australian Intrusions), C0014 (Operation Wocao), C0024 (SolarWinds Compromise). Detection: analisi DET0157/AN0444 basata su Event ID 4769, Sysmon, PowerShell Script Block Logging. Integrato con conoscenza professionale per tool e procedure operative.