Che cos'è un attacco Silver Ticket?
Un attacco Silver Ticket consiste nel forgiare un ticket di servizio Kerberos (TGS) usando il segreto dell'account di servizio target. MITRE traccia la tecnica come T1558.002, Silver Ticket.
Il perimetro è più stretto rispetto a un Golden Ticket, ma il meccanismo è importante. Un attaccante che conosce l'hash della password o la chiave Kerberos di un account di servizio può forgiare un ticket per quel servizio e presentarlo direttamente all'host che lo esegue. MITRE è esplicita su tre punti:
- l'attaccante ha bisogno dell'hash della password dell'account di servizio target
- il ticket forgiato è un ticket di servizio, non un TGT
- il ticket può essere creato senza interagire con il KDC
Quest'ultimo punto spiega perché i Silver Ticket restano preziosi. L'attaccante non chiede a un domain controller di emettere il ticket di servizio in tempo reale. Lo forgia offline e poi lo presenta al servizio target.
Il perimetro di questo articolo sono gli ambienti Kerberos di Windows Active Directory. Il focus è la catena reale di prerequisiti, il comportamento di protocollo che distingue l'attacco dai Golden Ticket, e le misure di hardening sugli account di servizio che riducono davvero l'opportunità.
Come funziona l'attacco Silver Ticket
Kerberos si basa normalmente sul fatto che il Key Distribution Center emette un ticket di servizio dopo che il client presenta un TGT valido. Silver Ticket rompe questo flusso atteso forgiando direttamente il ticket di servizio.
La pagina MITRE sulla tecnica Silver Ticket afferma che avversari con l'hash della password di un account di servizio target possono forgiare Kerberos ticket granting service tickets, cioè ticket di servizio. A differenza dei Golden Ticket, questi ticket sono limitati a una risorsa specifica e al sistema che la ospita. Ma a differenza di un Golden Ticket, l'attaccante può creare il ticket senza interagire con il KDC.
Questa differenza di design produce due conseguenze dirette:
- il ticket forgiato è limitato a uno specifico service principal invece che all'intero dominio
- il rilevamento è spesso più difficile perché manca il normale percorso di emissione lato domain controller
Perché il segreto dell'account di servizio è centrale
Silver Ticket funziona perché l'attaccante conosce la chiave usata dall'account di servizio target. Quel segreto può derivare da:
- credential dumping diretto dopo una compromissione
- estrazione dell'hash della password di un account di servizio da un server dove il servizio gira
- Kerberoasting: Come Craccano gli Account di Servizio, che MITRE cita esplicitamente come una via per ottenere l'hash target
Se l'attaccante non riesce a ottenere il segreto del servizio target, non può forgiare un Silver Ticket utilizzabile per quel servizio.
Perché alcuni ticket forgiati raggiungono comunque il percorso del servizio
La documentazione Microsoft su Kerberos mostra che l'elaborazione della PAC dipende dal modello applicativo e dalle assunzioni di trust. In particolare, Microsoft nota che la validazione PAC può essere opzionale per un'applicazione autonoma.
Questa sfumatura è importante, ma non va sopravvalutata. Il prerequisito centrale di Silver Ticket resta il possesso del segreto dell'account di servizio target e un percorso di servizio target disposto ad accettare il ticket presentato. Il comportamento della PAC è una parte del modello di elaborazione lato servizio, non una spiegazione completa di ogni caso di successo di un ticket forgiato.
Silver Ticket vs. Golden Ticket, Kerberoasting e Pass-the-Ticket
Questi termini vengono spesso confusi. Non dovrebbero esserlo.
- Silver Ticket: ticket di servizio forgiato per un servizio specifico dopo aver ottenuto il segreto dell'account di servizio
- Golden Ticket: TGT forgiato a partire dal segreto
krbtgt, con un impatto molto più ampio a livello di dominio. Vedi Golden Ticket: Le Chiavi del Tuo Dominio - Kerberoasting: richiedere ticket di servizio legittimi al KDC e craccarli offline per recuperare segreti di account di servizio. Vedi Kerberoasting: Come Craccano gli Account di Servizio
- Pass-the-Ticket: rigiocare o riutilizzare un ticket Kerberos reale che è stato rubato anziché forgiato
Silver Ticket si colloca spesso dopo un altro attacco prerequisito. Kerberoasting o il credential dumping ottengono il segreto dell'account di servizio. Silver Ticket trasforma quel segreto in accesso non autorizzato al servizio.
Perché i Silver Ticket contano ancora
I Silver Ticket sono meno famosi dei Golden Ticket, ma restano importanti perché colpiscono una debolezza aziendale comune: segreti di account di servizio gestiti male.
Gli account di servizio sono spesso più ampi e più vecchi di quanto i team pensino
Gli account di servizio tendono a sopravvivere per anni, sostenere più applicazioni e accumulare SPN, diritti locali ed eccezioni operative. Questo crea esattamente il tipo di segreto longevo che un attaccante cerca.
L'attacco è più silenzioso di un normale flusso di servizio emesso dal KDC
MITRE evidenzia direttamente il problema di rilevamento più importante: i Silver Ticket forgiati possono essere creati senza interagire con il KDC. Questo significa che parte della normale visibilità del domain controller su cui i difensori fanno affidamento manca fin dal momento in cui il ticket viene forgiato.
L'igiene debole degli account di servizio esiste ancora
La guida Microsoft sugli account di servizio gestiti esiste perché la gestione manuale delle password di servizio è soggetta a errori. Un normale account utente che esegue un servizio resta uno dei luoghi più facili per accumulare chiavi vecchie, rotazione debole e impostazioni di cifratura incoerenti.
La cifratura Kerberos legacy continua ad aumentare il rischio
Microsoft è ora andata oltre la semplice eliminazione progressiva di RC4. Nell'ambito del rollout della CVE-2026-20833, gli aggiornamenti dal 13 gennaio 2026 hanno aggiunto eventi di audit, quelli dal 14 aprile 2026 hanno cambiato il valore predefinito del KDC per DefaultDomainSupportedEncTypes a solo AES-SHA1 (0x18), e gli aggiornamenti rilasciati a partire da luglio 2026 hanno rimosso la sottochiave di registro RC4DefaultDisablementPhase che consentiva un rollback. Un domain controller senza configurazione esplicita ora assume solo AES. Questo è rilevante perché gli account di servizio con una postura di cifratura vecchia sono spesso gli stessi account che restano mal gestiti operativamente, e sono quelli che si rompono o mantengono silenziosamente una chiave RC4 non appena il default cambia.
Prerequisiti di un attacco Silver Ticket riuscito
Silver Ticket non è un trucco Kerberos a un clic. Diverse condizioni devono allinearsi.
1. L'attaccante deve ottenere il segreto dell'account di servizio target
Questo è il prerequisito non negoziabile. MITRE afferma esplicitamente che l'attaccante ha bisogno dell'hash della password dell'account di servizio target. Le vie di acquisizione comuni sono il credential dumping e il Kerberoasting.
2. Il servizio target deve dipendere da quel service principal
Il ticket forgiato deve corrispondere a un'identità di servizio reale accettata dall'host. Il perimetro è quindi più stretto rispetto a un Golden Ticket.
3. Il ticket forgiato deve essere accettato dal percorso di servizio preso di mira
La documentazione Microsoft sulla PAC mostra perché l'elaborazione lato servizio può variare in base al design dell'applicazione. Questa sfumatura è utile per capire il protocollo, ma non elimina la necessità che l'attaccante colpisca il service principal giusto con il segreto giusto.
4. L'account di servizio deve avere abbastanza valore da contare
Un ticket forgiato per un servizio a basso valore resta comunque un problema, ma la vera preoccupazione riguarda un account di servizio legato a un'applicazione sensibile, un workflow amministrativo o un host privilegiato.
5. L'ambiente presenta ancora un'igiene debole degli account di servizio
Account di servizio basati su utente e longevi, mancata adozione di gMSA, rotazione debole, account di servizio sovraprivilegiati o chiavi vecchie dipendenti solo da RC4 rendono i prerequisiti di Silver Ticket più realistici di quanto dovrebbero essere.
La catena di attacco
Una catena pratica di intrusione Silver Ticket di solito appare così.
Step 1 - Identificare un account di servizio che valga la pena colpire
L'attaccante mappa SPN, servizi e sistemi per trovare un service principal che darebbe accesso utile se compromesso.
Step 2 - Ottenere l'hash o la chiave dell'account di servizio
L'attaccante ottiene il segreto tramite dumping, cracking offline dopo Kerberoasting o un altro percorso di accesso alle credenziali.
Step 3 - Forgiare offline il ticket di servizio
Usando il segreto del servizio, l'attaccante crea un ticket di servizio Kerberos per il service principal scelto.
Step 4 - Presentare il ticket forgiato direttamente al servizio
È qui che Silver Ticket diverge dal normale percorso Kerberos. MITRE indica che il ticket forgiato può essere usato senza interagire con il KDC.
Step 5 - Usare l'accesso risultante entro il perimetro del servizio
L'accesso è più ristretto di quello di un Golden Ticket, ma può comunque essere grave dal punto di vista operativo se il servizio gira su un host sensibile, espone funzioni amministrative o abilita il movimento laterale.
Per questo Silver Ticket rientra nella stessa revisione di Percorsi di Attacco AD: Catene di Configurazioni Errate. Anche un ticket di servizio limitato può diventare parte di una catena molto più ampia.
Rilevamento
Rilevare Silver Ticket è difficile per un motivo semplice: l'attaccante potrebbe non chiedere mai al KDC il ticket di servizio che usa.
Il modello corretto è quindi anomaly detection più rilevamento dei prerequisiti, non un singolo Event ID che dimostri il caso in modo miracoloso.
Cercare un uso di ticket di servizio che non si allinea con l'attività attesa del KDC
La detection strategy MITRE per Silver Ticket (DET0241) descrive uno dei migliori approcci di alto livello: cercare attività anomala di ticket di servizio Kerberos, inclusi campi malformati negli eventi di logon e richieste TGS senza interazione con il KDC.
Operativamente, questo significa indagare i casi in cui:
- un account di servizio viene usato su un host o una risorsa fuori dal suo perimetro atteso
- il servizio target vede attività autenticata Kerberos che non si allinea in modo pulito con i normali pattern di emissione TGS lato KDC
- compaiono campi malformati o insoliti nei dati di logon o di elaborazione dei ticket
Non è una regola banale da implementare. Richiede una baseline di quali host e risorse ogni account di servizio dovrebbe effettivamente toccare.
Monitorare gli attacchi prerequisito, non solo il ticket forgiato in sé
La detection strategy MITRE indica anche direttamente l'accesso sospetto a LSASS e il credential dumping come fonti di dati utili. Questo è rilevante perché il segreto dell'account di servizio di solito deve essere rubato prima che il Silver Ticket esista.
Se già monitori:
- accesso sospetto a LSASS
- comportamento di credential dumping
- Kerberoasting: Come Craccano gli Account di Servizio
- pattern di autenticazione insoliti degli account di servizio
allora sei molto più vicino a intercettare la catena di attacco reale rispetto a cercare solo un unico indicatore finale del ticket forgiato.
Usare il contesto degli eventi Kerberos con prudenza
La guida Microsoft su Kerberos relativa all'evento 4769 resta utile perché documenta che una normale richiesta di ticket di servizio è visibile al KDC come evento di ticket di servizio. Questo rende 4769 un contesto prezioso per l'attività Kerberos normale.
Per le indagini su Silver Ticket, il punto non è allertare in astratto quando manca 4769. Il punto è capire che un ticket di servizio forgiato potrebbe non seguire lo stesso percorso di emissione del KDC di un ticket di servizio legittimo. Qualsiasi rilevamento basato su questa idea richiede un contesto di baseline, non una regola semplicistica su un singolo evento.
Osservare gli account di servizio fuori dal loro blast radius atteso
La detection strategy MITRE per Silver Ticket cita specificamente i tentativi di accesso con account di servizio fuori da host o risorse attesi. Questo è uno dei rilevamenti più utili sul piano operativo perché è comprensibile per i difensori e legato al vero perimetro dell'account di servizio.
Correlare con l'attività privilegiata successiva
Se il ticket forgiato raggiunge un servizio con impatto amministrativo, i segnali successivi possono apparire come:
- accesso insolito a funzioni amministrative dell'applicazione target
- logon all'host del servizio da identità che non dovrebbero essere presenti lì
- azioni privilegiate successive dopo l'accettazione del ticket
- anomalie circostanti già coperte in Monitoraggio Sicurezza AD: Event ID e SIEM
Rimedio
La mitigazione di Silver Ticket è soprattutto hardening degli account di servizio. Se l'attaccante non può ottenere un segreto di account di servizio riutilizzabile, non può forgiare il ticket.
1. Migrare i servizi idonei a gMSA
La guida Microsoft sui group Managed Service Accounts è qui la mitigazione da fonte primaria più chiara.
Microsoft documenta che i gMSA:
- lasciano che Windows gestisca la gestione delle password per gli account di servizio
- cambiano periodicamente le chiavi usate per l'account
- permettono agli host membri di ottenere i valori di password attuale e precedente dal domain controller
- riducono la necessità che gli amministratori gestiscano manualmente la sincronizzazione delle password
Questo affronta direttamente uno dei maggiori prerequisiti di Silver Ticket: segreti di account di servizio statici o mal gestiti.
2. Configurare il supporto AES per gli account di servizio gestiti
La documentazione Microsoft sui gMSA è esplicita: gli account di servizio gestiti dipendono dai tipi di cifratura Kerberos supportati, e AES dovrebbe sempre essere configurato per gli MSA. Il domain controller legge l'attributo msDS-SupportedEncryptionTypes dell'account per decidere cosa supporta il server, e quando quell'attributo non è impostato tratta l'account come se non supportasse i tipi più forti. Quindi, se hai irrobustito l'host per rifiutare RC4 mentre l'attributo resta non definito, l'autenticazione fallisce sempre. Per questo la postura di cifratura deve essere esplicita e non presunta.
3. Reimpostare le vecchie password degli account di servizio per generare chiavi AES
La guida Microsoft sulla remediation RC4 in Kerberos spiega che gli account creati prima del supporto AES potrebbero non avere chiavi AES se le loro password non sono mai state reimpostate dopo l'introduzione del supporto AES. Microsoft è esplicita nel dire che cambiare la password dell'account genera queste chiavi.
Questo è rilevante perché molti account di servizio legacy sono abbastanza vecchi da portarsi dietro esattamente questo problema.
4. Eliminare la dipendenza residua da RC4
Questo non è più opzionale lato Microsoft: dagli aggiornamenti di luglio 2026, il KDC assume solo AES-SHA1 quando non è configurato alcun tipo di cifratura esplicito, e la sottochiave di registro per il rollback temporaneo è scomparsa. La guida RC4 di Microsoft fornisce i passaggi di audit e remediation per trovare gli account che lo usano ancora, inclusi gli script List-AccountKeys.ps1 e Get-KerbEncryptionUsage.ps1 e gli eventi 4768 e 4769. Questo non rende Silver Ticket impossibile da solo, ma rimuove un'altra debolezza legacy dalla gestione Kerberos degli account di servizio e migliora la baseline Kerberos complessiva. Si lega inoltre direttamente ad AS-REP Roasting: Raccogliere Hash Senza Credenziali e ad altri lavori di hardening Kerberos.
5. Minimizzare privilegio e perimetro degli account di servizio
Un ticket forgiato è utile solo quanto l'account di servizio dietro di esso. Anche se l'account di servizio deve esistere, non dovrebbe portare anche diritti admin locali non necessari, appartenenza a gruppi privilegiati o accesso ampio a sistemi non correlati.
6. Inventariare SPN e ownership degli account di servizio
Non puoi difendere segreti di account di servizio che non comprendi. Un vero programma di hardening dovrebbe sapere:
- quali SPN corrispondono a quali account
- quali host ci si aspetta usino quegli account
- chi possiede operativamente ogni account di servizio
- se l'account può essere migrato a gMSA
- se l'account dipende ancora da RC4 o da impostazioni legacy
Per questo Auditare la sicurezza di Active Directory: checklist pratica va affiancato a questo argomento. Se stai scalando questa revisione su tutto il patrimonio, è rilevante anche Confronto tra strumenti di audit AD.
7. Trattare credential dumping e Kerberoasting come precursori diretti di Silver Ticket
Se un attaccante può dumpare o craccare offline il segreto di un account di servizio, il percorso Silver Ticket è ormai aperto. Per questo questo articolo va letto insieme a Kerberoasting: Come Craccano gli Account di Servizio, Attacchi Delega Kerberos: Non Vincolata a RBCD e Golden Ticket: Le Chiavi del Tuo Dominio.
Validazione dopo l'hardening
Non chiudere il rischio Silver Ticket solo perché hai cambiato una password una volta. Valida direttamente il modello degli account di servizio.
- confermare quali service principal usano ancora account utente tradizionali invece di gMSA
- verificare se ogni account di servizio ha chiavi AES e se RC4 è ancora in uso
- verificare
msDS-SupportedEncryptionTypesdove rilevante e confrontarlo con l'uso Kerberos reale osservato sui domain controller - rivedere i dati dell'evento
4769sui KDC per capire quali account di servizio richiedono ancora ticket di servizio e con quali tipi di cifratura - verificare che i servizi sensibili non dipendano da identità di servizio obsolete, condivise o non documentate
- confermare che agli account di servizio non vengano concessi privilegi più ampi di quelli di cui il servizio ha realmente bisogno
Il vero criterio di successo non è solo una policy Kerberos migliore. È che la compromissione di un account di servizio non fornisca più un segreto stabile e riutilizzabile con un ampio valore operativo.
Come EtcSec rileva l'esposizione correlata
Non esiste un vulnerability type esatto per Silver Ticket nel catalogo attuale, quindi i finding più utili sono i prerequisiti e le debolezze Kerberos circostanti che rendono pratica la tecnica.
I finding più rilevanti sono:
KERBEROASTING_RISK, perché il recupero offline di un segreto di account di servizio è uno dei precursori più chiari di Silver TicketKERBEROS_RC4_FALLBACK, perché la postura di cifratura Kerberos legacy spesso si sovrappone alla stessa popolazione di account di servizio mal gestiti- account di servizio privilegiati o con perimetro eccessivo che rendono un ticket di servizio forgiato molto più dannoso
- condizioni di attack path circostanti già catturate in Percorsi di Attacco AD: Catene di Configurazioni Errate
Questo è il modello mentale corretto: Silver Ticket è una tecnica di ticket forgiato, ma la vera superficie di correzione è l'igiene degli account di servizio.
Controlli correlati
Se rivedi il rischio Silver Ticket, rivedi anche Golden Ticket: Le Chiavi del Tuo Dominio, Kerberoasting: Come Craccano gli Account di Servizio, AS-REP Roasting: Raccogliere Hash Senza Credenziali, Attacchi Delega Kerberos: Non Vincolata a RBCD, Monitoraggio Sicurezza AD: Event ID e SIEM, Percorsi di Attacco AD: Catene di Configurazioni Errate, Auditare la sicurezza di Active Directory: checklist pratica e Confronto tra strumenti di audit AD.
Riferimenti principali
- MITRE ATT&CK: Silver Ticket (T1558.002)
- MITRE ATT&CK: Detect Forged Kerberos Silver Tickets (DET0241)
- Microsoft Learn: Kerberos PAC Validation
- Microsoft Learn: Group Managed Service Accounts overview
- Microsoft Learn: Detect and remediate RC4 usage in Kerberos
- Microsoft Support KB5073381: Kerberos KDC usage of RC4 for service account ticket issuance (CVE-2026-20833)
Esplora le pagine di identity security collegate a questo tema