Golden Ticket: Steal or Forge Kerberos Tickets – Golden Ticket (T1558.001)

La simulazione di un Golden Ticket in laboratorio richiede due fasi distinte: l'estrazione dell'hash KRBTGT e la successiva forgiatura del TGT. Entrambe vanno eseguite esclusivamente in ambienti autorizzati.

Fase 1 — Estrazione dell'hash KRBTGT. Il prerequisito è disporre di privilegi Domain Admin o equivalenti sul Domain Controller. Con Mimikatz (open source), il comando classico opera tramite DCSync, evitando di toccare il file NTDS.dit direttamente:

mimikatz # lsadump::dcsync /domain:lab.local /user:krbtgt

L'output restituisce l'hash NTLM e le chiavi AES dell'account KRBTGT. Annota il SID del dominio (visibile nell'output) e l'hash — serviranno entrambi per la forgiatura.

Fase 2 — Forgiatura del Golden Ticket. Sempre con Mimikatz, il modulo kerberos consente di creare il TGT in memoria o su file:

mimikatz # kerberos::golden /user:administrator /domain:lab.local /sid:S-1-5-21-XXXXXXXXXX /krbtgt:<HASH_NTLM> /ptt

Il flag /ptt (pass-the-ticket) inietta il ticket direttamente nella sessione corrente. A questo punto, un semplice dir \dc01.lab.local\c$ conferma l'accesso amministrativo al Domain Controller senza alcuna richiesta di credenziali.

Con Rubeus (open source), l'approccio è analogo ma con sintassi differente. Rubeus, incluso anche nel framework Sliver (open source), permette la forgiatura tramite:

Rubeus.exe golden /aes256:<AES256_KEY> /user:administrator /domain:lab.local /sid:S-1-5-21-XXXXXXXXXX /ptt

L'uso della chiave AES256 al posto dell'hash RC4/NTLM è preferibile in laboratorio perché riflette scenari reali in domini moderni dove RC4 è disabilitato — e aiuta a testare se le detection dell'organizzazione coprono anche le encryption più robuste.

In contesto red team con Empire (open source), il modulo dedicato richiama internamente Mimikatz. Il workflow prevede l'uso di un agente già attivo su un host compromesso, dalla cui shell si invoca il modulo golden_ticket specificando gli stessi parametri (dominio, SID, hash).

Un dettaglio operativo spesso trascurato: il Golden Ticket ha una validità di default di 10 anni (impostata da Mimikatz). In un esercizio red team è buona pratica ridurla a poche ore con il flag /endin:60 per limitare l'esposizione del lab e simulare un attaccante più cauto.

Rilevare un Golden Ticket è una sfida specifica perché il TGT forgiato è crittograficamente valido — il KDC lo accetta senza errori. La detection deve quindi concentrarsi sulle anomalie indirette che il ticket porta con sé.

Log source primari. I dati essenziali provengono da WinEventLog:Security e WinEventLog:Sysmon sui Domain Controller. Senza un logging Kerberos adeguato, la tecnica è sostanzialmente invisibile. Assicurati che la policy di audit includa Account Logon → Audit Kerberos Authentication Service e Audit Kerberos Service Ticket Operations.

Il primo indicatore comportamentale riguarda le richieste TGS senza un TGT precedente. In un flusso Kerberos legittimo, l'evento 4768 (TGT Request) precede sempre un 4769 (TGS Request). Un Golden Ticket iniettato in memoria salta la fase AS-REQ: il sistema presenta direttamente il TGT forgiato per ottenere un TGS. Correla questi due EventCode con una finestra temporale e cerca sessioni in cui 4769 compare senza un corrispondente 4768 per lo stesso account.

Il secondo indicatore è il tipo di encryption. In domini configurati con AES (la norma per ambienti moderni), un TGT cifrato con RC4-HMAC (etype 0x17) è un forte segnale di anomalia. Molti operatori usano l'hash NTLM per forgiare il ticket, e questo produce inevitabilmente RC4. Nel tuning, il parametro AllowedEncryptionTypes va calibrato sull'effettiva configurazione del dominio: se RC4 è ancora abilitato per compatibilità, questo indicatore perde efficacia.

Terzo pilastro: la durata anomala del ticket. I Golden Ticket di default hanno lifetime di 10 anni, enormemente superiore alla policy standard (tipicamente 10 ore). L'evento 4768 nel campo Ticket Options e Ticket Encryption Type rivela queste discrepanze. Il parametro TicketLifetimeThreshold va impostato rispetto alla Kerberos policy del dominio.

Sul fronte Sysmon, monitora gli accessi al processo lsass.exe. L'evento Sysmon EventID 10 (ProcessAccess) con target lsass.exe da processi inusuali — qualsiasi eseguibile fuori dal ProcessAllowlist — è un precursore della fase di credential dumping che precede il Golden Ticket. Strumenti come Mimikatz accedono a lsass per estrarre hash e chiavi: intercettare questa fase è spesso più efficace che cercare il ticket già forgiato.

Per i falsi positivi, il parametro PrivilegedAccountPatterns è fondamentale: costruisci una baseline degli account che legittimamente eseguono operazioni Kerberos privilegiate (account di servizio, admin schedulati) e genera alert solo per le deviazioni.

L'analisi forense di un Golden Ticket si sviluppa su due momenti distinti: la compromissione dell'hash KRBTGT (precursore) e l'uso effettivo del ticket forgiato (impatto). Ricostruire la timeline richiede la correlazione di artefatti distribuiti tra Domain Controller, endpoint compromesso e sistemi target.

Artefatti sul Domain Controller. Inizia dai Security Event Log. Cerca eventi 4768 con anomalie: encryption type RC4 in un dominio AES-only, lifetime del ticket non conforme alla policy, oppure account richiedenti che non dovrebbero generare TGT (account disabilitati, inesistenti nel dominio, o con SID storico). Gli eventi 4672 (Special Privilege Logon) associati ad account non amministrativi sono un ulteriore segnale — un Golden Ticket può attribuire privilegi arbitrari a qualunque utente.

Artefatti sull'endpoint attaccante. La cache Kerberos locale è il primo elemento da acquisire. Su un sistema Windows live, il comando:

klist tickets

elenca i ticket correnti in sessione. Su un'immagine disco, i ticket possono essere estratti dalla memoria del processo lsass o dal file di paginazione. Cerca file con estensione .kirbi — il formato di export di Mimikatz — nella directory di lavoro dell'attaccante, nelle cartelle temporanee e nel profilo utente.

Nel registro eventi Sysmon dell'endpoint, l'evento EventID 10 con target lsass.exe rivela il momento esatto dell'accesso alla memoria del processo di autenticazione. Correla il timestamp con eventuali EventID 1 (Process Create) che mostrano l'esecuzione di Mimikatz, Rubeus o altri tool. Attenzione ai nomi rinominati: gli operatori sofisticati non lanciano "mimikatz.exe" ma binari con nomi arbitrari. L'hash del file e la riga di comando sono più affidabili del nome processo.

Ricostruzione della timeline. La sequenza tipica prevede:

1. DCSync o accesso NTDS.dit — evento 4662 (Directory Service Access) con proprietà di replica richieste dall'endpoint attaccante verso il DC
2. Forgiatura del ticket — nessun evento diretto; cercare l'esecuzione del tool sull'endpoint
3. Iniezione e uso del TGT — eventi 4769 senza corrispondente 4768, seguiti da accessi 4624 (Logon) di tipo 3 (Network) su sistemi target multipli in rapida successione

La fase di lateral movement post-Golden Ticket è spesso identificabile dalla sua velocità e ampiezza: un singolo account che accede a decine di server in pochi minuti, con logon di tipo Network, rappresenta un pattern raro in contesti legittimi. Verifica la coerenza con il PrivilegedAccountPatterns della baseline aziendale.

Per determinare se il KRBTGT è stato compromesso, confronta l'ultimo timestamp di reset della password dell'account KRBTGT (attributo pwdLastSet in AD) con l'inizio della finestra di attività sospetta.

Il Golden Ticket rappresenta una tecnica di alta sofisticazione che presuppone un accesso privilegiato già consolidato all'infrastruttura Active Directory della vittima. Il suo utilizzo da parte di un threat actor segnala una fase avanzata dell'intrusione, ben oltre l'Initial Access — siamo nel territorio della persistenza a livello di dominio e del movimento laterale illimitato.

Ke3chang (G0004) è il gruppo documentato per l'uso di questa tecnica, impiegando specificamente Mimikatz per la generazione dei Golden Ticket. Questo gruppo, associato ad attività di cyber-espionage, dimostra come la tecnica non sia appannaggio esclusivo di operatori ransomware ma serva anche a attori state-sponsored che necessitano di persistenza silenziosa e duratura all'interno di reti governative e diplomatiche.

Dal punto di vista dell'ecosistema di strumenti, il quadro è dominato dal binomio Mimikatz-Rubeus. Mimikatz resta il tool di riferimento storico, mentre Rubeus offre un'implementazione più moderna e modulare, integrata nativamente nel framework C2 Sliver. Questa integrazione è significativa: un operatore che utilizza Sliver può eseguire l'intera catena — dal DCSync alla forgiatura del ticket — senza mai toccare disco, riducendo l'esposizione agli EDR. Empire, dal canto suo, richiama internamente l'implementazione di Mimikatz, rappresentando un'alternativa per operatori che preferiscono un framework PowerShell-based.

L'analisi dei pattern rivela un elemento critico per il triage: il Golden Ticket è quasi sempre preceduto da una fase di credential dumping (T1003) e spesso accompagnato da tecniche di lateral movement via pass-the-ticket. Un threat intelligence analyst che osserva indicatori di DCSync dovrebbe immediatamente alzare il livello di allerta, poiché il Golden Ticket è la naturale evoluzione di quella catena.

Sul piano delle contromisure strategiche, la rotazione periodica della password KRBTGT (consigliata ogni 180 giorni, con doppio reset per invalidare i ticket esistenti) è la misura più efficace per limitare la finestra di validità di un eventuale ticket forgiato. Questa pratica, combinata con la segmentazione degli account privilegiati e l'uso di Authentication Silos, riduce drasticamente la superficie di attacco disponibile.

Il trend emergente è l'adozione di chiavi AES256 per la forgiatura, che rende obsolete le detection basate esclusivamente su RC4. Le organizzazioni mature devono aggiornare le proprie regole di correlazione per coprire anche ticket AES con anomalie di lifetime o di SID.

Framework MITRE ATT&CK v16 — T1558.001, TA0006, G0004, S0002, S0363, S0633, S1071, M1015, M1026, DET0144/AN0405. Tool di detection: Sysmon, Windows Security Event Log (EventID 4768, 4769, 4672, 4662, 4624), Sysmon EventID 10. Integrato con conoscenza professionale per tool e procedure operative.