Golden Ticket: Forgiatura di Ticket-Granting Ticket Kerberos (T1558.001)

L'esecuzione di un Golden Ticket in laboratorio parte sempre dal presupposto di aver già ottenuto privilegi di Domain Admin o accesso SYSTEM su un domain controller. Il primo step è l'estrazione dell'hash NTLM dell'account KRBTGT, tipicamente tramite DCSync o dump diretto del database NTDS.dit.

Con Mimikatz (open source), la sequenza classica in una sessione elevata prevede:

lsadump::dcsync /domain:corp.local /user:krbtgt

L'output restituisce l'hash NTLM del KRBTGT e il SID del dominio. Con questi due elementi si procede alla forgiatura vera e propria:

kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-XXXX /krbtgt:HASH /id:500 /ptt

Il flag /ptt inietta il ticket direttamente nella sessione corrente (pass-the-ticket), rendendo immediatamente utilizzabili strumenti come dir \\dc01\c$ o psexec verso qualsiasi host del dominio.

Rubeus (open source) offre un approccio più moderno e OPSEC-friendly, evitando alcune signature di Mimikatz. La sintassi è:

Rubeus.exe golden /user:Administrator /domain:corp.local /sid:S-1-5-21-XXXX /krbtgt:HASH /ptt

Rubeus permette di personalizzare campi come ticket lifetime, encryption type (fondamentale per evitare RC4 in domini con AES abilitato) e struttura del PAC, riducendo drasticamente gli artefatti anomali che i SOC monitorano.

Empire (open source, mantenuto dalla community BC-Security) integra Mimikatz nei propri moduli PowerShell, utile per operazioni post-exploitation in ambienti dove è già presente un agent. Sliver (open source, di Bishop Fox) incorpora la libreria Rubeus permettendo la forgiatura di Golden Ticket direttamente dall'implant C2, opzione preziosa in scenari red team estesi.

In laboratorio è essenziale simulare anche varianti realistiche: forgiatura di ticket con lifetime ridotto (10 ore invece del default di 10 anni) per bypassare regole di detection basate su durate anomale, uso di encryption type AES256 per mimare traffico legittimo, e inserimento del ticket in sessioni utente non privilegiate per testare l'efficacia del Protected Users group. Un esercizio completo dovrebbe includere anche il tentativo di Silver Ticket come confronto, per apprezzare la differenza di blast radius tra le due tecniche. Ricordarsi sempre di operare in ambiente isolato: la persistenza garantita da un Golden Ticket è tale che una dimenticanza in produzione richiede la doppia rotazione KRBTGT per essere rimossa.

La detection dei Golden Ticket è uno dei problemi più sfidanti per un SOC che difende un ambiente Active Directory, perché i ticket forgiati sono crittograficamente validi e transitano attraverso i flussi Kerberos ordinari. L'unica strategia efficace è la correlazione comportamentale su più eventi.

La detection AN0405 di MITRE indica quattro segnali chiave da monitorare in parallelo. Il primo è la durata anomala del TGT: Mimikatz di default forgia ticket con validità di 10 anni, mentre la policy standard di dominio è 10 ore. Un TGT con lifetime superiore alla policy è un forte indicatore. Su Windows i log rilevanti sono EventCode 4769 (richiesta TGS) e EventCode 4768 (richiesta TGT), disponibili nel WinEventLog:Security del domain controller.

Il secondo segnale è l'encryption type: in domini moderni con msDS-SupportedEncryptionTypes configurato su AES128/AES256, la comparsa di ticket con Ticket Encryption Type 0x17 (RC4-HMAC) è sospetta. Questo campo è presente nell'evento 4769 e va confrontato con la baseline del dominio.

Il terzo indicatore, spesso decisivo, è la presenza di TGS request senza TGT request preceduta. In un flusso Kerberos legittimo, ogni 4769 è preceduto da un 4768 per lo stesso account. Il Golden Ticket, essendo iniettato direttamente nella sessione, salta la fase di richiesta TGT: correlare i due EventCode per Account Name e Client Address entro una finestra temporale ristretta espone l'anomalia.

Il quarto segnale è l'anomalia sul PAC: campi malformati, SID history sospette, o account name che non esistono in AD ma appaiono in richieste TGS. Query LDAP comparative aiutano a validare l'esistenza reale dell'utente.

Allineandosi al framework difensivo D3FEND, le contromisure preventive includono il Credential Hardening tramite abilitazione del gruppo Protected Users per gli account amministrativi (che forza AES e disabilita la delega), l'audit continuo dell'accesso a lsass.exe tramite Sysmon EventID 10 con ProcessAllowlist definito, e la gestione rigorosa dei processi che interagiscono con il KDC.

Sul fronte SIEM, regole custom in Splunk, Sentinel o QRadar dovrebbero implementare le tuning specifiche: TicketLifetimeThreshold, AllowedEncryptionTypes, PrivilegedAccountPatterns. I falsi positivi principali derivano da account di servizio con lifetime esteso configurato via policy, da sistemi legacy che ancora negoziano RC4, e da tool di amministrazione che generano pattern Kerberos inusuali. Una baseline accurata per almeno 30 giorni è indispensabile prima di alzare regole in blocking mode.

L'analisi forense di un Golden Ticket è un esercizio di ricostruzione indiretta: il ticket in sé è un blob crittografico che non lascia "impronte" evidenti sul filesystem, e l'indagine deve concentrarsi sugli artefatti collaterali generati dalla forgiatura, dall'iniezione e dall'uso successivo.

Sul domain controller compromesso, la timeline parte dall'evento di credential dumping che ha permesso l'estrazione dell'hash KRBTGT. Gli artefatti chiave includono: eventi 4662 nel Security log relativi ad accessi al naming context del dominio con maschere di replica (indicativi di DCSync), eventi 4624 Logon Type 3 da workstation non tipicamente amministrative, e ombre volume o dump del file NTDS.dit nella cartella %SystemRoot%\NTDS\.

Sull'endpoint dell'attaccante o sui sistemi da cui è stato lanciato Mimikatz/Rubeus, la telemetria Sysmon è cruciale. L'EventID 1 (process creation) può rivelare esecuzioni sospette; EventID 10 (process access) mostra apertura di handle verso lsass.exe con GrantedAccess elevate (0x1010, 0x1410); EventID 11 (file create) può catturare artefatti temporanei come file .kirbi prodotti da Rubeus. Le chiavi di registro HKLM\SYSTEM\CurrentControlSet\Control\Lsa meritano verifica per configurazioni alterate.

Sui sistemi target raggiunti tramite Golden Ticket, l'evidenza si concentra nei log Kerberos. Un elemento diagnostico potente è l'incoerenza tra il campo Account Name nell'evento 4624 e l'assenza di un corrispondente 4768 nei DC per la stessa sessione — l'account ha effettuato logon senza aver mai richiesto un TGT al dominio. Anche i log NTLM possono mostrare fallback anomali quando il ticket forgiato viene rifiutato.

Per la timeline complessiva, incrociare Windows Event Forwarding, log Sysmon centralizzati e telemetria EDR permette di ricostruire: momento del dump KRBTGT sul DC, prima apparizione del ticket forgiato in una richiesta TGS, sistemi contattati con quel ticket, e persistenza dell'attaccante nel tempo. Tool come Volatility (open source) per memory forensics permettono di cercare in dump RAM la presenza di ticket Kerberos in cache LSA tramite plugin come kerberoast o hashdump.

Attribuzione: il gruppo Ke3chang (G0004) è documentato aver utilizzato Mimikatz per generare Golden Ticket. Elementi utili all'attribuzione includono la scelta del tool (Mimikatz "nudo" vs. Rubeus custom-compiled), i pattern di lifetime scelti, l'encryption type usato, e la nomenclatura degli account fittizi impersonati (spesso Administrator o account con SID 500).

Il panorama degli attori che sfruttano Golden Ticket è ampio, ma MITRE ATT&CK documenta formalmente un solo gruppo per questa sotto-tecnica: Ke3chang (G0004), noto anche come APT15, Vixen Panda o Mirage, attivo da oltre un decennio con focus su target diplomatici, governativi e nel settore energetico principalmente in Europa e America Latina. L'utilizzo di Mimikatz per la generazione di Golden Ticket da parte di Ke3chang riflette una scelta operativa comune negli attori state-sponsored: sfruttare tool pubblici e mantenuti per ridurre lo sviluppo interno e beneficiare dell'evoluzione continua della community offensiva.

Sul fronte del tooling, MITRE mappa quattro strumenti principali per questa tecnica, che coprono l'intero spettro delle capacità offensive moderne. Mimikatz (S0002) resta il riferimento storico, con il modulo kerberos che ha sostanzialmente definito la tecnica dopo la ricerca originale di Benjamin Delpy. Empire (S0363), framework post-exploitation PowerShell/Python, integra Mimikatz nativamente e ha visto ampia adozione da parte di threat actor sia criminali sia state-sponsored, anche dopo il passaggio di manutenzione a BC-Security. Sliver (S0633), framework C2 di Bishop Fox scritto in Go, rappresenta l'evoluzione moderna: cross-platform, difficile da rilevare, e con integrazione della libreria Rubeus per operazioni Kerberos avanzate. Rubeus (S1071), sviluppato originariamente da Will Schroeder di SpecterOps, è oggi lo standard de facto per manipolazione Kerberos in operazioni red team e viene frequentemente incorporato in tooling proprietario di threat actor.

Il pattern strategico dietro l'uso di Golden Ticket è chiaro: si tratta di una tecnica di persistenza pluriennale utilizzata da attori che pianificano campagne di lungo periodo con obiettivi di spionaggio. La forgiatura di un Golden Ticket non è mai un'azione opportunistica ma un investimento post-compromise che presuppone accesso già consolidato al domain controller. Per questo motivo è più tipica di APT che di gruppi ransomware, sebbene alcune operazioni ransomware sofisticate (Conti, LockBit affiliati) l'abbiano adottata per garantire ri-accesso dopo eventuale bonifica parziale.

Il trend osservabile riguarda l'evoluzione OPSEC: gli attori più maturi hanno abbandonato Mimikatz "vanilla" per compilazioni custom di Rubeus con lifetime ridotti e encryption AES, proprio per evadere le detection sui parametri anomali. Le mitigazioni M1015 e M1026 — rotazione periodica KRBTGT ogni 180 giorni con doppio cambio, Protected Users group, tiering amministrativo — restano gli unici controlli davvero efficaci nel ridurre l'impatto di questa tecnica. L'adozione di soluzioni PAM come CyberArk o BeyondTrust (a pagamento) o alternative open source come HashiCorp Vault riduce la superficie di esposizione delle credenziali privilegiate necessarie al pre-requisito.

MITRE ATT&CK: tecnica T1558.001 (Steal or Forge Kerberos Tickets: Golden Ticket), tattica TA0006, gruppo G0004 (Ke3chang), software S0002 (Mimikatz), S0363 (Empire), S0633 (Sliver), S1071 (Rubeus), mitigazioni M1015 e M1026, detection DET0144 (AN0405). MITRE D3FEND per contromisure difensive su Credential Hardening e Process Analysis. Il documento integra conoscenza professionale su sintassi comandi Mimikatz/Rubeus, EventCode Windows e telemetria Sysmon, verificata su documentazione ufficiale dei rispettivi tool open source.