EtcSecBeta
🏢Active DirectoryKerberosAttack PathsMonitoring

Attacco Silver Ticket: ticket di servizio Kerberos forgiati in Active Directory

Un Silver Ticket è un ticket di servizio Kerberos forgiato con il segreto di un account di servizio. Scopri prerequisiti reali, limiti di visibilità KDC e hardening AD efficace.

ES
EtcSec Security Team
11 min read
Attacco Silver Ticket: ticket di servizio Kerberos forgiati in Active Directory

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 il valore della tecnica. 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 è Kerberos in Windows Active Directory. Il focus sono i prerequisiti reali, le differenze rispetto a Golden Ticket e le misure sugli account di servizio che riducono davvero l’opportunità.


Come funziona l’attacco Silver Ticket

In un flusso Kerberos normale, il Key Distribution Center emette un ticket di servizio dopo che il client presenta un TGT valido. Silver Ticket rompe questo flusso forgiando direttamente il ticket di servizio.

MITRE 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 e al sistema che la ospita. Ma possono essere creati senza interazione con il KDC.

Questo produce due conseguenze:

  • il ticket è limitato a uno specifico service principal
  • il rilevamento è più difficile perché manca il normale percorso di emissione lato domain controller

Perché il segreto dell’account di servizio è centrale

Silver Ticket funziona solo se l’attaccante conosce la chiave dell’account di servizio target. Quel segreto può arrivare da:

Senza il segreto dell’account di servizio, non è possibile forgiare un Silver Ticket utilizzabile per quel servizio.

La PAC va descritta con cautela

La documentazione Microsoft sulla PAC mostra che l’elaborazione può dipendere dal modello applicativo e dalle assunzioni di trust. Microsoft nota che la validazione PAC può essere opzionale per un’applicazione autonoma.

Questa nuance è utile, ma non va sovrainterpretata. Il prerequisito centrale resta il possesso del segreto dell’account di servizio e un percorso service-side che accetti il ticket presentato. La PAC è una parte dell’elaborazione lato servizio, non una spiegazione universale di ogni Silver Ticket riuscito.


Silver Ticket vs Golden Ticket, Kerberoasting e Pass-the-Ticket

Questi termini vengono spesso confusi, ma descrivono cose diverse.

  • Silver Ticket: ticket di servizio forgiato per un servizio specifico dopo aver ottenuto il segreto dell’account di servizio
  • Golden Ticket: TGT forgiato con il segreto krbtgt, con impatto molto più ampio sul dominio. Vedi Golden Ticket: Le Chiavi del Tuo Dominio
  • Kerberoasting: richiesta di ticket di servizio legittimi al KDC e cracking offline per recuperare segreti di account di servizio
  • Pass-the-Ticket: riuso di un ticket Kerberos reale rubato, non forgiato

Silver Ticket spesso arriva dopo un’altra tecnica. Kerberoasting o credential dumping fornisce il segreto; Silver Ticket trasforma quel segreto in accesso non autorizzato al servizio.


Perché Silver Ticket conta ancora

Silver Ticket è meno famoso di Golden Ticket, ma colpisce una debolezza diffusa: segreti di account di servizio gestiti male.

Gli account di servizio vivono troppo a lungo

Gli account di servizio spesso restano per anni, supportano più applicazioni e accumulano SPN, diritti locali ed eccezioni operative. Sono esattamente i segreti stabili che un attaccante cerca.

L’attacco è più silenzioso di un normale flusso KDC

MITRE evidenzia il problema: Silver Ticket può essere creato senza interazione con il KDC. Una parte della visibilità normale del domain controller manca dal momento in cui il ticket viene forgiato.

L’igiene degli account di servizio resta debole

Microsoft documenta gli account di servizio gestiti perché la gestione manuale delle password di servizio è fragile. Un normale account utente usato come servizio resta un luogo comune per segreti vecchi, rotazione debole e cifratura incoerente.

La cifratura Kerberos legacy aumenta l’esposizione

La guida Microsoft continua a spingere audit e riduzione di RC4 in Kerberos. È rilevante perché gli account di servizio vecchi con cifratura legacy spesso appartengono alla stessa popolazione mal gestita.


Prerequisiti di un attacco Silver Ticket riuscito

Silver Ticket non è un trucco Kerberos senza condizioni.

1. L’attaccante deve ottenere il segreto dell’account di servizio

È il prerequisito non negoziabile. MITRE afferma che serve l’hash della password dell’account di servizio target. Le vie comuni sono credential dumping e Kerberoasting.

2. Il servizio target deve usare quel service principal

Il ticket forgiato deve corrispondere a un’identità di servizio reale accettata dall’host. Il perimetro è quindi più stretto di Golden Ticket.

3. Il percorso del servizio deve accettare il ticket

La documentazione Microsoft sulla PAC spiega perché l’elaborazione lato servizio può variare per applicazione. Ma questo non elimina la necessità di colpire il service principal giusto con il segreto giusto.

4. L’account di servizio deve avere valore

Un ticket per un servizio a basso valore resta un problema, ma il rischio reale riguarda applicazioni sensibili, workflow amministrativi o host privilegiati.

5. L’igiene degli account di servizio è debole

Account utente usati come servizi, assenza di gMSA, password vecchie, privilegi eccessivi o dipendenza da RC4 rendono più realistici i prerequisiti.


Catena di attacco

Una catena Silver Ticket pratica spesso appare così.

Step 1 - Identificare un account di servizio interessante

L’attaccante mappa SPN, servizi e sistemi per trovare un service principal utile.

Step 2 - Ottenere hash o chiave dell’account

Il segreto deriva da dumping, cracking offline dopo Kerberoasting o un altro percorso di credential access.

Step 3 - Forgiare offline il ticket di servizio

Con il segreto, l’attaccante crea un ticket di servizio Kerberos per il service principal scelto.

Step 4 - Presentare il ticket direttamente al servizio

Qui Silver Ticket diverge dal percorso Kerberos normale. MITRE indica che il ticket forgiato può essere usato senza interazione con il KDC.

Step 5 - Usare l’accesso nel perimetro del servizio

L’accesso è più ristretto di Golden Ticket, ma può essere serio se il servizio gira su un host sensibile, espone funzioni amministrative o abilita movimento laterale.

Per questo Silver Ticket va collegato a Percorsi di Attacco AD: Catene di Configurazioni Errate.


Rilevamento

Rilevare Silver Ticket è difficile perché l’attaccante potrebbe non chiedere mai al KDC il ticket che usa.

Il modello corretto è anomaly detection più rilevamento dei prerequisiti, non un singolo Event ID miracoloso.

Cercare uso di service ticket che non si allinea al KDC

La detection strategy MITRE DET0241 raccomanda di cercare attività anomala di ticket di servizio, inclusa attività senza pattern attesi di validazione o emissione KDC.

Indaga casi in cui:

  • un account di servizio appare su host o risorse fuori dal suo scope atteso
  • il servizio target vede attività Kerberos che non si allinea con normali pattern TGS lato KDC
  • compaiono campi insoliti o malformed nei dati di logon o ticket

Non è una regola semplice. Serve una baseline degli host e risorse che ogni account di servizio deve toccare.

Monitorare gli attacchi prerequisito

MITRE indica anche accesso sospetto a LSASS e credential dumping come fonti utili. Il segreto dell’account di servizio di solito viene rubato prima del Silver Ticket.

Monitora quindi:

È spesso più realistico individuare la catena prima del ticket finale.

Usare il contesto Kerberos con prudenza

L’evento 4769 è utile perché rappresenta una richiesta normale di ticket di servizio al KDC. Per Silver Ticket, il punto non è allertare banalmente quando manca 4769. Il punto è capire che un ticket forgiato può non seguire il percorso normale di emissione KDC. Serve baseline.

Osservare account di servizio fuori dal loro perimetro

MITRE cita esplicitamente accessi con account di servizio fuori da host o risorse attese. È spesso più azionabile di un segnale puramente di protocollo.

Correlare attività privilegiata successiva

Se il ticket raggiunge un servizio amministrativo, possono apparire:

  • accessi insoliti a funzioni admin dell’applicazione
  • logon o accessi all’host del servizio da identità inattese
  • azioni privilegiate successive
  • anomalie coperte in Monitoraggio Sicurezza AD: Event ID e SIEM

Mitigazione

La mitigazione Silver Ticket è soprattutto igiene degli account di servizio. Se l’attaccante non può ottenere un segreto riutilizzabile, non può forgiare il ticket.

1. Migrare i servizi idonei a gMSA

La documentazione Microsoft sui group Managed Service Accounts è la mitigazione primaria più chiara. I gMSA lasciano a Windows la gestione delle password di servizio, ruotano le chiavi e riducono la sincronizzazione manuale. Questo colpisce direttamente segreti statici o mal gestiti.

2. Configurare AES per Managed Service Accounts

Microsoft indica che i Managed Service Accounts dipendono dai tipi di cifratura Kerberos supportati e raccomanda di configurare sempre AES per gli MSA. Se l’host non supporta RC4, l’autenticazione fallisce quando l’account non ha postura AES corretta.

3. Reimpostare vecchie password di account di servizio

La guida Microsoft su RC4 spiega che account vecchi possono non avere chiavi AES se la password non è mai stata cambiata dopo l’introduzione di AES. Cambiare la password genera queste chiavi.

4. Ridurre la dipendenza da RC4

Microsoft fornisce passaggi attuali per audit e remediation di RC4 in Kerberos. Non rende Silver Ticket impossibile da solo, ma rimuove una debolezza legacy dalla stessa popolazione di account di servizio. Si collega anche a AS-REP Roasting: Raccogliere Hash Senza Credenziali.

5. Minimizzare privilegi e scope

Un ticket forgiato è utile quanto l’account dietro di esso. Gli account di servizio non dovrebbero avere diritti admin locali, gruppi privilegiati o accessi ampi se non necessari.

6. Inventariare SPN e ownership

Un programma serio deve sapere:

  • quali SPN corrispondono a quali account
  • quali host devono usare quegli account
  • chi possiede operativamente ogni account
  • se l’account può migrare a gMSA
  • se dipende ancora da RC4 o legacy

Questo rientra in Auditare la sicurezza di Active Directory: checklist pratica.

7. Trattare Kerberoasting e dumping come precursori diretti

Se un attaccante può dumpare o crackare il segreto di un account di servizio, il percorso Silver Ticket è aperto. Rivedi 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 dopo un solo cambio password.

  • confermare quali servizi usano ancora account utente tradizionali invece di gMSA
  • verificare che gli account abbiano chiavi AES e se RC4 è ancora in uso
  • controllare msDS-SupportedEncryptionTypes quando pertinente
  • confrontare la configurazione con l’uso Kerberos osservato sui domain controller
  • analizzare eventi 4769 per capire quali account richiedono ticket e con quale cifratura
  • confermare che servizi sensibili non dipendano da identità condivise, vecchie o non documentate
  • rimuovere privilegi superiori al necessario

Il successo reale non è solo una policy Kerberos migliore. È che la compromissione di un account di servizio non produca più un segreto stabile e riutilizzabile di alto valore.


Come EtcSec rileva esposizione correlata

Non esiste un vulnerability type esatto per Silver Ticket nel catalogo attuale. I finding più utili sono quindi prerequisiti e debolezze Kerberos che rendono pratica la tecnica.

I più rilevanti sono:

  • KERBEROASTING_RISK, perché il recupero offline di un segreto di account di servizio è un precursore diretto
  • KERBEROS_RC4_FALLBACK, perché la postura Kerberos legacy si sovrappone spesso agli stessi account mal gestiti
  • account di servizio sovraprivilegiati o troppo ampi
  • condizioni di attack path in Percorsi di Attacco AD: Catene di Configurazioni Errate

Il modello corretto: Silver Ticket è una tecnica di ticket forgiato, ma la superficie reale 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

Attacco Silver Ticket in AD: rilevamento e mitigazione | EtcSec