Furto e Forgiatura di Ticket Kerberos: Steal or Forge Kerberos Tickets (T1558)

L'abuso di Kerberos in un red team engagement inizia quasi sempre da un contesto di privilegi già acquisiti su un endpoint del dominio. Il punto di partenza tipico è l'enumerazione dei ticket in cache tramite l'utility nativa Windows klist, che elenca i TGT e i TGS presenti nella sessione corrente senza richiedere privilegi elevati. Un semplice klist mostra tutti i ticket dell'utente attivo, mentre klist sessions enumera le sessioni logon attive sul sistema.

Per l'estrazione vera e propria, Mimikatz (open source) resta lo strumento di riferimento. Il comando sekurlsa::tickets /export estrae tutti i ticket presenti in memoria LSASS e li salva come file .kirbi nella directory corrente, mentre kerberos::list /export opera sulla cache della sessione utente. L'operazione richiede privilegi di SeDebugPrivilege, quindi tipicamente un contesto amministrativo locale o SYSTEM.

Per la forgiatura di ticket, la catena classica prevede prima l'estrazione dell'hash NTLM dell'account KRBTGT dal domain controller — operazione ottenibile tramite lsadump::dcsync /user:krbtgt con privilegi di Domain Admin o account con diritti di replica. Ottenuto l'hash, la costruzione del Golden Ticket avviene con kerberos::golden /user:Administrator /domain:target.local /sid: /krbtgt: /ptt, dove il flag /ptt inietta immediatamente il ticket nella sessione corrente.

Un'alternativa più moderna e cross-platform è Rubeus (open source), che offre operazioni Kerberos native in .NET evitando le chiamate LSASS più rumorose. I comandi principali includono Rubeus.exe dump per estrarre ticket dalla memoria, Rubeus.exe kerberoast per richiedere TGS di service account con SPN configurato e successivo cracking offline, e Rubeus.exe asktgt /user:target /rc4: per l'overpass-the-hash. Il modulo tgtdeleg consente inoltre di ottenere un TGT delegabile senza toccare LSASS.

In ambiente Linux, Impacket (open source) fornisce la suite di riferimento: GetUserSPNs.py per il Kerberoasting remoto, GetNPUsers.py per l'AS-REP Roasting su account con pre-autenticazione disabilitata, e ticketer.py per la forgiatura offline di Golden e Silver Ticket a partire da hash noti. Il ticket generato viene poi caricato in variabile d'ambiente KRB5CCNAME e utilizzato con psexec.py -k -no-pass o wmiexec.py per il movimento laterale.

Per scenari di lab, ambienti come GOAD (Game of Active Directory) (open source) offrono un dominio vulnerabile preconfigurato ideale per esercitarsi su tutte le varianti della tecnica senza rischi.

La detection di T1558 richiede una combinazione di analisi dei log Kerberos, monitoraggio della memoria LSASS e baseline comportamentali sui ticket. La sorgente primaria su Windows è il Security Log del domain controller, con particolare attenzione agli EventCode 4768 (Kerberos TGT request), 4769 (Kerberos service ticket request) e 4771 (Kerberos pre-authentication failed).

Un primo indicatore ad alto valore è il downgrade di cifratura: nei campi Ticket Encryption Type degli eventi 4768 e 4769, il valore 0x17 (RC4-HMAC) su un dominio moderno che dovrebbe usare AES (0x11 o 0x12) è fortemente sospetto e correlato a Kerberoasting o a ticket forgiati con Mimikatz nelle configurazioni di default. La mitigazione M1041 raccomanda proprio di forzare AES a livello di dominio, rendendo qualunque richiesta RC4 un'anomalia investigabile.

Un secondo pattern critico è la richiesta di TGS senza TGT precedente per lo stesso account nell'intervallo di validità: un evento 4769 senza un 4768 correlato entro il ticket lifetime tipico indica l'uso di un Golden Ticket forgiato offline. Analogamente, ticket con lifetime superiore ai default del dominio (tipicamente 10 ore per TGT, rinnovabili fino a 7 giorni) sono sintomo di forgiatura, dato che Mimikatz imposta di default una validità di 10 anni.

Sul fronte dell'accesso a LSASS, Sysmon (open source, Microsoft) con EventCode 10 (ProcessAccess) è essenziale: si monitorano handle a lsass.exe con GrantedAccess pari a 0x1010 o 0x1410, tipici del dumping di memoria. Una allowlist dei processi legittimi che accedono a LSASS (antivirus, agent EDR, servizi Windows firmati) riduce i falsi positivi. La mitigazione M1043 con Windows Defender Credential Guard sposta i segreti in un container VBS, neutralizzando la maggior parte delle tecniche di dumping tradizionali.

Su Linux, dove Kerberos è usato tramite MIT Kerberos o SSSD, la detection si basa su auditd con regole SYSCALL sui file ~/.krb5cc_, /tmp/krb5cc_*, /var/lib/sss/secrets/ e /etc/krb5.keytab. Accessi a questi path da parte di processi non standard (shell interattive, script Python) devono generare alert.

Su macOS, il Unified Logging System consultabile tramite log show --predicate 'subsystem == "com.apple.Kerberos"' traccia le operazioni di kinit e klist. Sequenze anomale — ad esempio richieste TGS senza TGT precedente o multipli kinit con SPN diversi in rapida successione — vanno investigate.

La correlazione SIEM ideale combina anomalie di lifetime, downgrade di cifratura, accessi LSASS e attività di autenticazione da IP non abituali per l'account. La mitigazione M1047 enfatizza l'audit continuo delle configurazioni di dominio come base per rendere queste anomalie visibili.

L'analisi forense di un incidente Kerberos richiede la ricostruzione di una timeline che intersechi log del domain controller, artefatti di memoria degli endpoint e cache locali dei ticket. Il primo pilastro è il Security Log dei DC, dove gli eventi 4768, 4769, 4770 (ticket renewal) e 4771 forniscono la sequenza cronologica delle richieste. L'analista deve estrarre l'intero storico correlato agli account sospetti, prestando attenzione a Client Address, Ticket Encryption Type e Ticket Options.

Sugli endpoint compromessi, l'analisi della memoria è decisiva. Uno snapshot RAM acquisito con WinPmem (open source) o Magnet RAM Capture (gratuito) può essere processato con Volatility 3 (open source) usando il plugin windows.lsadump per estrarre segreti LSA e il plugin windows.pslist per identificare processi che hanno acceduto a LSASS. Se Mimikatz o Rubeus sono stati eseguiti in memoria (fileless), tracce residue possono emergere in stringhe di memoria del processo genitore o in AmCache.hve e ShimCache.

Gli artefatti di esecuzione classici da esaminare includono i Prefetch files in *C:\Windows\Prefetch* per evidenze di mimikatz.exe, rubeus.exe, psexec.exe; l'hive di registro AmCache.hve in *C:\Windows\AppCompat\Programs* che conserva hash SHA1 degli eseguibili lanciati; e i log PowerShell Operational (EventCode 4104) per script di dumping o moduli Invoke-Mimikatz caricati in memoria. I log Sysmon EventCode 1 (Process Creation) e 10 (ProcessAccess) forniscono la timeline delle interazioni con LSASS.

Sulla cache ticket locale, il file *%SystemRoot%\System32\config* non contiene direttamente i ticket, che risiedono in memoria kernel. Tuttavia, l'output di klist eseguito live durante il triage cattura ticket ancora validi. Su Linux, la cache in /tmp/krb5cc_ o nel keyring del kernel (visibile con klist -c KEYRING:persistent:) può essere esportata per analisi offline.

Per identificare Golden Ticket persistenti, la verifica della data di ultima modifica della password dell'account KRBTGT tramite Get-ADUser krbtgt -Properties PasswordLastSet è fondamentale: se la password non è stata ruotata due volte dopo il sospetto compromesso, tutti i ticket forgiati con l'hash precedente restano validi. La mitigazione M1015 raccomanda esplicitamente la doppia rotazione forzata come procedura di contenimento.

La timeline consolidata deve incrociare: eventi 4624 (logon) con Logon Type 3 senza corrispondente 4768 sul DC, esecuzioni di tool di dumping su endpoint privilegiati, e uso successivo di account privilegiati da workstation non abituali. Akira è documentato per l'uso di script di dumping delle credenziali Kerberos, quindi in incidenti attribuiti a questo gruppo l'analisi dovrebbe concentrarsi sulla ricerca di script batch o PowerShell orchestrati per estrazione massiva.

Il panorama degli attori che abusano di Kerberos è storicamente vasto, ma i dati MITRE per questa tecnica documentano formalmente un unico gruppo, che merita quindi un'analisi approfondita nel contesto della sua operatività.

Akira (G1024) è un gruppo ransomware emerso come una delle operazioni più prolifiche del panorama double-extortion. L'uso documentato di script per il dumping delle credenziali Kerberos si inserisce in una catena d'attacco tipica dei ransomware moderni: accesso iniziale tramite credenziali VPN compromesse o vulnerabilità di edge device, escalation su domain controller, estrazione massiva di credenziali per movimento laterale e infine deployment del payload di cifratura su scala di dominio. La preferenza per lo scripting dell'estrazione credenziali — anziché l'esecuzione interattiva di Mimikatz — è coerente con l'obiettivo di operare rapidamente su molte macchine minimizzando l'interazione manuale. Questo pattern rende cruciale la detection basata su comportamento (accessi anomali a LSASS, esecuzione di script PowerShell con encoding base64) piuttosto che su signature statiche.

Sul piano più ampio, l'abuso di Kerberos è un pilastro condiviso tra ransomware group, APT statali e access broker. Le tecniche derivate — Golden Ticket, Silver Ticket, Kerberoasting, AS-REP Roasting — sono standard nel toolkit di qualunque operatore che raggiunga privilegi di dominio. Il Kerberoasting, in particolare, si è affermato come tecnica preferita perché non richiede privilegi elevati (qualsiasi utente di dominio può richiedere TGS per service account con SPN) e permette il cracking offline dell'hash senza generare failure di autenticazione visibili.

Un trend osservabile è la migrazione degli attaccanti verso strumenti .NET nativi come Rubeus al posto di Mimikatz, motivata dalla minore rilevabilità: le operazioni Kerberos native evitano le API LSASS più monitorate e possono essere eseguite in memoria tramite loader C2 come Cobalt Strike o Sliver. Parallelamente, l'adozione crescente di Windows Defender Credential Guard e di baseline di dominio che forzano AES sta erodendo l'efficacia delle tecniche più classiche, spingendo i gruppi verso approcci alternativi come l'abuso di certificati AD CS (ESC1-ESC15) o il furto di token OAuth in ambienti ibridi.

Sul piano geografico, l'abuso di Kerberos è geograficamente agnostico ed è documentato in operazioni di gruppi originari di aree diverse, con vittimologia trasversale a settori (manifatturiero, sanitario, servizi finanziari, pubblica amministrazione). Il vettore comune è la presenza di Active Directory come infrastruttura di autenticazione, che rende qualunque organizzazione enterprise potenzialmente esposta.

Dal punto di vista di priorità difensiva, la combinazione di rotazione periodica del KRBTGT (ogni 180 giorni come da M1015), enforcement di AES-only, adozione di Protected Users group per account privilegiati e monitoraggio continuo degli eventi 4768/4769 rappresenta la baseline minima per contenere il rischio associato a questa famiglia di tecniche.

MITRE ATT&CK T1558 (Steal or Forge Kerberos Tickets), tattica TA0006. Gruppo documentato: Akira (G1024). Mitigazioni M1015, M1026, M1027, M1041, M1043, M1047. Detection: DET0522 con analytics AN1443 (Windows), AN1444 (Linux), AN1445 (macOS). MITRE D3FEND per artefatti Kerberos Ticket e Authentication Service. Per comandi operativi e artefatti forensi è stata integrata conoscenza professionale di cybersecurity relativa a tool open source consolidati (Mimikatz, Rubeus, Impacket, Volatility, Sysmon).