Kerberoasting: Steal Service Account Passwords (T1558.003)

Il primo passo per replicare Kerberoasting in laboratorio è enumerare gli account di servizio con SPN configurati. Su Windows, puoi utilizzare PowerShell nativo con il comando: setspn -Q / | findstr /C:"CN=Users". Questo ti mostrerà tutti i service principal names associati ad account utente, i target ideali per l'attacco.

Per automatizzare il processo, PowerSploit rimane uno degli strumenti più efficaci. Il modulo Invoke-Kerberoast richiede semplicemente: Import-Module Invoke-Kerberoast.ps1 seguito da Invoke-Kerberoast -OutputFormat Hashcat. L'output sarà formattato per tool di cracking come Hashcat, rendendo immediato il passaggio successivo.

Se preferisci operare da Linux, Impacket offre GetUserSPNs.py che funziona eccellentemente:

python GetUserSPNs.py DOMAIN/user:password -dc-ip DC_IP -request

Questo comando richiederà automaticamente tutti i TGS ticket disponibili e li salverà in formato craccabile.

Una volta ottenuti gli hash, il cracking offline diventa questione di potenza computazionale. Hashcat supporta nativamente il formato Kerberos 5 TGS-REP etype 23 con il modo 13100: hashcat -m 13100 hash.txt wordlist.txt. Per aumentare l'efficacia, considera dizionari specifici per password di servizio che spesso includono il nome del servizio stesso.

Rubeus rappresenta l'evoluzione moderna del tooling, integrandosi perfettamente in ambienti C2 come Cobalt Strike. Il comando Rubeus.exe kerberoast /format:hashcat /outfile:hashes.txt esegue l'intera catena d'attacco in un singolo passaggio.

Per simulazioni più realistiche, Brute Ratel C4 include funzionalità native per decodificare ticket Kerberos 5 e convertirli automaticamente in formato hashcat, replicando esattamente le tecniche osservate in campagne APT reali.

La detection efficace di Kerberoasting richiede un approccio comportamentale piuttosto che basato su signature. Il log Event ID 4769 (Kerberos Service Ticket Operations) diventa la tua fonte primaria, ma devi filtrare intelligentemente per evitare l'overload di falsi positivi.

Configura alert per rilevare burst di richieste TGS da un singolo account. Un utente normale raramente richiede più di 5-10 ticket in un'ora, mentre un attacco Kerberoasting può generarne centinaia in pochi minuti. Implementa una soglia dinamica basata sul comportamento storico dell'account.

Un indicatore chiave è l'uso di crittografia RC4 (etype 0x17) nelle richieste TGS moderne. Se la tua organizzazione ha migrato ad AES, qualsiasi richiesta RC4 dovrebbe generare un alert immediato. Puoi verificare questo nel campo Ticket Encryption Type dell'evento 4769.

Correla gli eventi Kerberos con l'attività dei processi tramite Sysmon. Tool come Mimikatz o Rubeus spesso accedono a LSASS per manipolare i ticket. Eventi Sysmon ID 10 (ProcessAccess) verso lsass.exe precedenti a burst di richieste TGS sono altamente sospetti.

Per ridurre i falsi positivi, crea una whitelist degli account di servizio legittimi e dei loro pattern di richiesta tipici. Applicazioni come SQL Server o Exchange generano traffico Kerberos prevedibile che puoi escludere dalle regole di detection.

Implementa una detection rule che triggera quando:

• Un account richiede più di 20 TGS in 5 minuti
• Le richieste includono SPN per account con privilegi elevati
• L'encryption type è RC4 in ambienti che supportano AES
• L'account richiedente non ha mai richiesto quei particolari SPN in precedenza

Durante l'analisi post-compromissione, Kerberoasting lascia tracce specifiche che permettono di ricostruire con precisione la timeline dell'attacco. Il Security Event Log di Windows conserva tutti gli eventi 4769, ma attenzione: la retention policy standard potrebbe non essere sufficiente per catturare l'intero scope dell'attività.

Inizia filtrando gli eventi 4769 per Ticket Encryption Type 0x17 (RC4). Questo ridurrà drasticamente il dataset da analizzare. Presta particolare attenzione al campo Service Name che indica quale account di servizio era il target dell'attacco.

La correlazione temporale è cruciale: cerca pattern di richieste multiple in rapida successione. Operation Wocao mostrava tipicamente burst di 50-100 richieste TGS nell'arco di 2-3 minuti, un pattern impossibile da generare con attività legittima.

Esamina i prefetch files e le tracce di esecuzione di tool comuni. PowerSploit lascia artefatti distintivi in \Windows\Prefetch\POWERSHELL.EXE-[hash].pf con timestamp che corrispondono agli eventi Kerberos. Anche la presenza di moduli PowerShell in directories temporanee può indicare l'uso di Invoke-Kerberoast.

Per ricostruire quali account sono stati compromessi con successo, cerca successive autenticazioni anomale. Se un service account inizia ad autenticarsi interattivamente o da workstation inusuali dopo un evento Kerberoasting, è probabile che la password sia stata craccata.

Gli attaccanti sofisticati come quelli del SolarWinds Compromise spesso cancellano i log locali. In questi casi, i log forwarded al SIEM o i backup del domain controller diventano essenziali. Verifica anche i Kerberos ticket cache files (*C:\Users[username]\AppData\Local*) per tracce di ticket manipulation.

FIN7 utilizza Kerberoasting come parte di una catena d'attacco finanziariamente motivata. Il gruppo tipicamente compromette prima endpoint con malware Carbanak, poi escalate a domain admin attraverso Kerberoasting di service account privilegiati. I loro target preferenziali sono account SQL Server e backup services che spesso hanno password deboli.

Wizard Spider, operatori del ransomware Ryuk, ha evoluto le proprie tecniche includendo sia Rubeus che moduli Mimikatz personalizzati. La loro metodologia prevede Kerberoasting massivo seguito da lateral movement rapido per massimizzare l'impatto del ransomware prima della detection.

Indrik Spider si distingue per l'uso di moduli Kerberoasting scaricati direttamente da GitHub durante l'operazione, minimizzando le tracce forensi. Questo gruppo target specificamente istituzioni finanziarie dell'Europa dell'Est e utilizza le credenziali compromesse per accedere a sistemi SWIFT.

I pattern geografici mostrano che gruppi APT russi e cinesi preferiscono Kerberoasting per la sua natura "low and slow". La tecnica permette di mantenere persistenza a lungo termine senza generare alert, ideale per operazioni di spionaggio come Leviathan Australian Intrusions.

L'overlap nei tool è significativo: tutti i gruppi documentati utilizzano varianti di Mimikatz o Impacket, suggerendo che il monitoring di questi tool specifici può fornire early warning di campagne in corso. La tendenza emergente è l'integrazione di capacità Kerberoasting direttamente nei framework C2 commerciali, rendendo la detection sempre più challenging.

Framework MITRE ATT&CK T1558.003. Campagne documentate: Operation Wocao (FOX-IT 2019), SolarWinds Compromise (FireEye 2020), Leviathan Australian Intrusions (2022). Tool analysis: PowerSploit framework, Impacket suite, Rubeus documentation. Detection: Microsoft Defender for Identity Kerberoasting detection playbook.