Silver Ticket: Forgiatura di Service Ticket Kerberos (T1558.002)

L'attacco Silver Ticket richiede quattro elementi: il dominio FQDN, il SID del dominio, il nome dell'account di servizio target e l'hash NTLM (o chiave AES128/AES256) di tale account. In un lab Active Directory, la catena tipica parte dall'ottenimento dell'hash tramite Kerberoasting o dumping da LSASS.

Con Rubeus (open source, GitHub GhostPack) l'estrazione via Kerberoasting si esegue con:

Rubeus.exe kerberoast /outfile:hashes.txt

L'hash TGS estratto viene poi crackato offline con Hashcat (open source) usando la modalità 13100 per ticket RC4. Ottenuto l'NT hash del service account, la forgiatura del Silver Ticket con Rubeus si effettua indicando servizio, utente da impersonare, dominio, SID e hash:

Rubeus.exe silver /service:MSSQLSvc/sql01.corp.local:1433 /rc4:HASH /domain:corp.local /sid:S-1-5-21-... /user:Administrator /ptt

Il flag /ptt inietta il ticket nella sessione corrente. A quel punto un semplice sqlcmd -S sql01.corp.local -E autentica come amministratore sul database.

Con Mimikatz (open source) l'equivalente è il modulo kerberos::golden usato con il parametro /service per generare un Silver Ticket anziché un Golden:

kerberos::golden /domain:corp.local /sid:S-1-5-21-... /target:sql01.corp.local /service:MSSQLSvc /rc4:HASH /user:Administrator /ptt

Empire (open source, versione BC-Security mantenuta) integra il modulo Mimikatz e permette di orchestrare l'attacco tramite agent già presenti sul target. AADInternals (open source, PowerShell) estende il concetto agli ambienti ibridi Azure AD forgiando ticket con l'hash dell'account AZUREADSSOACC, permettendo impersonation di qualsiasi utente sincronizzato via Seamless SSO.

Per un red team engagement realistico, considera queste varianti operative. Cambia il tipo di servizio a CIFS/ per accesso a file share, HTTP/ per SharePoint o siti IIS interni, HOST/ per esecuzione comandi via WMI o PsExec. Usa chiavi AES256 anziché RC4 quando il dominio ha disabilitato RC4, con il flag /aes256: al posto di /rc4:. Imposta la durata del ticket con /startoffset e /endin per evitare TGS con lifetime sospetti di dieci anni, valore di default che è indicatore banale di forgiatura.

Documenta sempre nel report l'accountname target, l'ora di forgiatura e le azioni eseguite con il ticket, così il blue team può correlare gli eventi durante il debrief.

La detection del Silver Ticket è intrinsecamente difficile perché la richiesta TGS non transita dal KDC: mancano quindi gli eventi 4768 (TGT request) e 4769 (TGS request) sul Domain Controller. L'evidenza si sposta sul server membro che riceve il ticket forgiato, dove il log Security registra un evento 4624 di logon Kerberos senza il corrispondente 4769 correlabile sul DC.

La strategia di detection DET0241 si basa su tre pilastri complementari. Il primo è la correlazione cross-source tra eventi di logon sui member server e richieste TGS sui DC. Configurare Splunk o Sentinel per estrarre da WinEventLog:Security tutti gli eventi 4624 con LogonType 3 e AuthenticationPackageName Kerberos, poi verificare l'assenza del corrispondente 4769 sul DC entro una finestra di dieci minuti prima del logon. La query deve filtrare per TargetUserSid e IpAddress del client per ridurre falsi positivi legati a ticket cached legittimi.

Il secondo pilastro è l'analisi delle anomalie nei campi del ticket. I ticket forgiati da Mimikatz e Rubeus con parametri di default presentano indicatori sospetti: lifetime di dieci anni, encryption type RC4-HMAC (0x17) quando il dominio è configurato per AES, o campi PAC malformati. L'evento 4769 legittimo mostra TicketEncryptionType pari a 0x12 (AES256) nei domini moderni; la presenza di 0x17 su account che dovrebbero usare AES è un red flag. Configurare alert su Sysmon EventID 1 per processi come rubeus.exe, mimikatz.exe o loader PowerShell che invocano Invoke-Mimikatz.

Il terzo pilastro riguarda il monitoring dell'accesso a LSASS. Sysmon EventID 10 con TargetImage pari a lsass.exe e GrantedAccess con maschera 0x1010 o 0x1410 indica tentativo di dumping credenziali, precursore comune del Silver Ticket. Escludere dalla baseline i processi legittimi come antivirus e agent EDR autorizzati.

Per il tuning, mantenere una ServiceAccountScope map che associ ogni service account ai server dove dovrebbe autenticarsi. Una connessione dell'account sql_svc verso un file server, quando storicamente accede solo al cluster SQL, è anomalia comportamentale forte. Analogamente, definire una TicketValidationBaseline dei pattern normali di emissione TGS per ogni SPN.

I falsi positivi principali derivano da service account con ticket cached di lunga durata dopo riavvii del DC, task schedulati che rinnovano ticket in modo non standard e agent di backup che accedono a share multipli. Ridurre il rumore aggiungendo allowlist per host e process signature verificate.

L'analisi forense di un incidente Silver Ticket richiede un approccio multi-sorgente perché l'artefatto primario, il ticket stesso, risiede in memoria e viene distrutto al reboot. La timeline si costruisce partendo dagli eventi endpoint del server compromesso e risalendo verso l'origine.

Sul member server target l'evento 4624 con LogonType 3 e AuthenticationPackage Kerberos è l'ingresso in scena del ticket forgiato. Estrarre da Security.evtx tutti i logon dell'account di servizio nell'intervallo dell'incidente, correlando TargetLogonId con eventi 4672 (Special Privileges Assigned) e successivi 4688 di process creation per ricostruire le azioni post-autenticazione. Il campo IpAddress dell'evento 4624 rivela l'host attaccante.

Sul Domain Controller cercare l'assenza di eventi 4769 corrispondenti. Questa asimmetria è la firma forense più solida del Silver Ticket. Estrarre da tutti i DC del dominio (necessario perché la richiesta potrebbe essere andata a qualsiasi DC) gli eventi 4769 filtrati per ServiceName del SPN target e confrontare con i 4624 sul member server. I logon Kerberos privi di TGS request sono candidati Silver Ticket.

Sulla workstation dell'attaccante, se identificata, cercare artefatti di Mimikatz, Rubeus o loader PowerShell. Prefetch (C:\Windows\Prefetch*.pf) rivela esecuzioni recenti; AmCache (C:\Windows\AppCompat\Programs\Amcache.hve) conserva hash SHA1 dei binari eseguiti anche dopo cancellazione. Il registro ShimCache (SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache) fornisce evidenza aggiuntiva. Per esecuzione fileless via PowerShell analizzare Microsoft-Windows-PowerShell/Operational EventID 4104 per script block logging contenenti stringhe come KerberosRequestorSecurityToken, Invoke-Mimikatz, o pattern di forgiatura ticket.

Se l'attaccante ha esportato il ticket con Rubeus (/nowrap /outfile:), possono esistere file .kirbi su disco o in share temporanei. Cercare file con estensione .kirbi, .ccache o dump LSASS (.dmp) nei percorsi utente e temp.

Gli artefatti digitali chiave per la timeline includono i Kerberos Ticket in memoria (recuperabili con volatility plugin mimikatz su dump RAM), i Process che hanno interagito con LSASS (Sysmon EventID 10), i File di output dei tool di forgiatura, e le Authentication Log cross-referenced tra DC e member server.

Per determinare la finestra di compromissione, l'attaccante deve aver ottenuto l'hash del service account precedentemente. Ricercare eventi di Kerberoasting (4769 con TicketEncryptionType 0x17 verso SPN inusuali) o dumping LSASS nelle settimane precedenti al primo utilizzo del ticket forgiato.

I dati MITRE ATT&CK forniti per T1558.002 non associano gruppi APT specifici alla tecnica, ma il toolkit documentato permette comunque un'analisi rilevante del panorama.

Mimikatz (S0002), sviluppato originariamente come proof-of-concept da Benjamin Delpy, è divenuto lo strumento di riferimento per operazioni Kerberos-based. Il modulo kerberos implementa nativamente Silver Ticket dal 2014 ed è integrato in decine di framework offensivi, sia commerciali che open source. La sua ubiquità rende difficile qualsiasi attribuzione basata solo sulla presenza del binario: praticamente ogni operatore, dal ransomware crew al nation-state actor, lo ha nel toolkit.

Empire (S0363), inizialmente PowerShell Empire di PowerShellEmpire team e ora mantenuto da BC-Security, integra le funzioni Kerberos di Mimikatz nei propri moduli. La sua adozione è particolarmente diffusa tra threat actor di livello intermedio e red team commerciali, grazie alla facilità di orchestrare campagne multi-stage tramite agent post-exploitation.

Rubeus (S1071), parte della suite GhostPack di SpecterOps, ha guadagnato popolarità come alternativa nativa .NET a Mimikatz per operazioni Kerberos. Il suo design modulare, focalizzato esclusivamente su Kerberos, offre maggiore granularità nella forgiatura: supporto AES nativo, controllo fine dei campi PAC, esportazione ticket in formato .kirbi. È diventato lo standard de facto per operazioni Kerberos moderne, spesso preferito in ambienti con EDR aggressivi che rilevano signature Mimikatz.

AADInternals (S0677), sviluppato da Nestori Syynimaa, estende l'attacco agli ambienti ibridi Azure AD. La capacità di forgiare ticket usando l'hash dell'account computer AZUREADSSOACC, creato automaticamente quando si abilita Seamless SSO, apre uno scenario di impersonation cloud particolarmente insidioso. Un attaccante con accesso al DC on-premises può estrarre l'hash di AZUREADSSOACC e forgiare ticket Kerberos accettati da Azure AD, ottenendo accesso arbitrario a risorse Microsoft 365 senza triggerare MFA.

Il trend evolutivo vede uno spostamento da Mimikatz verso Rubeus per operazioni endpoint e crescente interesse verso AADInternals per target cloud-hybrid. Le campagne ransomware moderne integrano frequentemente Silver Ticket nella fase di privilege escalation e lateral movement, sfruttando service account con password mai ruotate per persistere su database e application server critici.

Dal punto di vista della threat intelligence, gli indicatori strategici da monitorare includono richieste di dump LSASS non autorizzate, esecuzione di binari .NET compilati con signature Rubeus (hash noti nel dataset VirusTotal), e traffico Kerberos anomalo verso SPN di alto valore. Il monitoring continuo delle password age degli account di servizio è mitigazione strategica: account con password non ruotate da oltre 180 giorni sono target prioritari.

MITRE ATT&CK T1558.002 (Silver Ticket), tattica TA0006 Credential Access. Software: S0002 Mimikatz, S0363 Empire, S0677 AADInternals, S1071 Rubeus. Mitigazioni: M1026 Privileged Account Management, M1027 Password Policies, M1041 Encrypt Sensitive Information. Detection strategy DET0241 con analytic AN0675 su Windows Security, Kerberos e Sysmon event log. Il contenuto operativo su comandi, artefatti forensi e procedure di detection integra conoscenza professionale di cybersecurity verificabile su documentazione ufficiale dei tool citati.