Cos'e un Golden Ticket?
Un Golden Ticket e un Ticket Granting Ticket (TGT) Kerberos forgiato con il segreto dell'account KRBTGT del dominio. Se un attaccante possiede quel materiale, puo costruire TGT che il dominio considera validi e usarli per richiedere service ticket verso risorse interne senza passare dal normale processo di autenticazione dell'utente.
Microsoft documenta nei dettagli che l'evento 4768 rappresenta l'emissione di un TGT e che il servizio coinvolto e tipicamente krbtgt. Microsoft documenta inoltre che KRBTGT e l'account usato dal KDC del dominio per emettere i ticket Kerberos e che la sua password va reimpostata due volte, con un intervallo minimo superiore alla massima durata dei ticket, per invalidare in modo affidabile i vecchi segreti ancora in history.
Questa e la ragione per cui il Golden Ticket e un rischio Tier 0 puro: non dipende da una singola password utente, ma dal segreto che firma l'intero meccanismo di autenticazione Kerberos del dominio.
Dove nasce davvero il rischio
Il rischio Golden Ticket non inizia quando qualcuno esegue uno strumento di forgery. Inizia quando un attaccante ottiene uno di questi prerequisiti:
- compromissione di un domain controller
- diritti di replica directory sufficienti a leggere dati segreti del dominio
- esposizione persistente di credenziali amministrative Tier 0
- percorsi di delega, trust o workstation amministrative che permettono di arrivare a KRBTGT indirettamente
Microsoft documenta l'extended right DS-Replication-Get-Changes-All come il diritto che consente la replica dei dati segreti del dominio. Per questo una review seria del rischio Golden Ticket deve includere non solo i DC, ma anche chi possiede diritti di replica equivalenti a DCSync.
Come funziona il flusso tecnico
1. Il KDC emette i TGT usando KRBTGT
L'evento 4768 mostra che il servizio usato per emettere un TGT e krbtgt. In pratica, il dominio si fida di quel segreto per stabilire che il TGT sia stato generato dal KDC legittimo.
2. I servizi non interrogano il KDC per ogni decisione sul TGT
Nella pratica operativa, se il ticket e firmato correttamente con il materiale che il dominio considera valido, il resto della catena Kerberos lo tratta come autentico. Questo e il punto centrale del Golden Ticket: l'attaccante non deve conoscere la password di ogni admin. Deve ottenere il segreto che rende credibili i TGT.
3. La password history di KRBTGT spiega la doppia rotazione
Microsoft specifica che l'account KRBTGT mantiene una password history di 2. Per questo la procedura corretta richiede due reset, separati da almeno il tempo massimo di vita dei ticket. Con un solo reset, un ticket firmato con il precedente segreto puo ancora restare valido in determinati casi di replica o history.
Cosa deve verificare un team tecnico
Inventario minimo
Get-ADUser krbtgt -Properties pwdLastSet, msDS-SupportedEncryptionTypes |
Select-Object SamAccountName, pwdLastSet, msDS-SupportedEncryptionTypes
Get-ADObject -LDAPFilter "(objectClass=domainDNS)" -Properties nTSecurityDescriptor |
Select-Object DistinguishedName
L'obiettivo non e solo leggere pwdLastSet. Bisogna anche sapere:
- quali account o gruppi mantengono diritti di replica
- quali admin entrano ancora in sistemi non Tier 0
- quali account privilegiati non usano protezioni aggiuntive come Protected Users o workstation dedicate
Perche Protected Users aiuta ma non risolve tutto
Microsoft documenta che i membri di Protected Users:
- non possono autenticarsi con NTLM
- non possono usare DES o RC4 in pre-auth Kerberos
- non possono delegare con constrained o unconstrained delegation
- non possono rinnovare TGT oltre il limite iniziale di quattro ore
Questo e utile per gli account amministrativi umani, ma Microsoft specifica anche che non bisogna aggiungere account di servizio o computer a Protected Users. Quindi il gruppo e una misura di riduzione del rischio per gli admin, non una remediation diretta del segreto KRBTGT.
RODC, replica e chiavi effettivamente disponibili
La guida Microsoft sul reset KRBTGT ricorda che la procedura standard si applica ai writeable domain controller e che gli RODC usano account krbtgt_<numero> separati. In ambienti con siti remoti o recovery incompleta, questa distinzione conta davvero.
In parallelo, gli eventi moderni 4768 e 4769 mostrano non solo gli encryption types supportati ma anche le Available Keys. Questo consente di verificare se, dopo rotazioni password e cleanup, i DC e gli account sensibili hanno davvero materiale AES disponibile o stanno ancora trascinandosi dietro una postura legacy che rende piu difficile interpretare i segnali Kerberos.
Detection
Eventi da usare nel modo giusto
I tre eventi piu utili per questo tema sono:
- 4768 per l'emissione dei TGT
- 4769 per le richieste di service ticket
- 4672 per privilegi speciali assegnati a sessioni anomale
Il punto importante e che non esiste un singolo IOC perfetto per un Golden Ticket ben costruito. La detection migliore nasce da correlazione e contesto.
Cosa cercare in 4768 e 4769
Dopo gli aggiornamenti moderni, Microsoft documenta che 4768 e 4769 espongono campi molto piu utili, tra cui:
TicketEncryptionTypeServiceSupportedEncryptionTypesServiceAvailableKeysAccountAvailableKeysClientAdvertizedEncryptionTypes
Questo permette una lettura piu precisa del rischio. Un RC4 non e automaticamente Golden Ticket, ma va considerato sospetto se l'account o il servizio dovrebbero gia usare AES e i relativi key material risultano disponibili.
Perche "RC4 = Golden Ticket" e una scorciatoia sbagliata
Microsoft documenta che 0x17 rappresenta RC4-HMAC, che era la suite predefinita nei sistemi piu vecchi. Quindi RC4 e un segnale utile, ma non basta da solo. Va interpretato insieme a:
msDS-SupportedEncryptionTypesAvailableKeys- percorso di provenienza della richiesta
- host di origine
- presenza di account privilegiati coinvolti
In altre parole: RC4 puo essere un forte indizio di igiene Kerberos debole, ma non una prova sufficiente di Golden Ticket.
Detection operativa da non dimenticare
La parte piu redditizia spesso resta fuori dal log puro di Kerberos:
- review dei soggetti con diritti di replica
- controllo dei sistemi da cui partono richieste Kerberos privilegiate
- verifica delle workstation amministrative
- verifica della rotazione effettiva di KRBTGT dopo incidenti o recovery
Remediation
1. Contenere la compromissione iniziale
Se sospetti Golden Ticket, il primo obiettivo non e "ruotare KRBTGT il piu presto possibile" in modo cieco. Il primo obiettivo e contenere l'accesso che ha permesso di leggere il segreto o i diritti di replica. Se l'attaccante mantiene Domain Admin, DCSync o accesso a un DC, puo semplicemente rigenerare il problema.
2. Rivedere i diritti di replica
Qualsiasi account che conserva diritti equivalenti a Replicating Directory Changes e Replicating Directory Changes All deve essere giustificato e monitorato. Per un ambiente sano, questo elenco deve restare molto corto e molto noioso da spiegare, perche tutto il resto e anomalo.
3. Reimpostare KRBTGT due volte
Microsoft e esplicita:
- il reset va eseguito due volte
- bisogna aspettare almeno 10 ore tra i reset nel valore predefinito, o comunque piu del massimo lifetime dei ticket configurato
- il reset documentato si applica ai writeable DC, mentre gli RODC hanno account
krbtgt_<numero>separati
Questo e il centro della remediation. Finche non completi correttamente la doppia rotazione, non hai una prova seria che i vecchi TGT forgiati siano stati invalidati.
4. Ridurre l'esposizione amministrativa
Le misure piu utili, oltre a KRBTGT, sono:
- workstation amministrative dedicate
- tiering degli accessi
- riduzione dei diritti di replica
- uso di Protected Users per gli admin umani dove sostenibile
- eliminazione di RC4 e verifica della disponibilita delle chiavi AES
5. Preparare l'operazione prima di eseguirla
Una doppia rotazione KRBTGT fatta male puo creare impatti operativi. Prima del cambio bisogna sapere:
- durata massima dei ticket nel dominio
- dipendenze legacy ancora presenti
- stato dei DC e della replica
- presenza di account migrati o senza chiavi AES aggiornate
6. Validare il dominio, non solo il singolo DC
Dopo la doppia rotazione, la validazione deve coprire tutto il dominio:
- replica completata tra DC
- assenza di diritti di replica non giustificati
- verifica di ticket nuovi emessi con i key material attesi
- test di accesso amministrativo legittimo su sistemi Tier 0
- conferma che eventuali RODC o segmenti remoti non mantengano eccezioni fuori controllo
Questo e il punto in cui una remediation passa da "operazione eseguita" a "rischio realmente ridotto".
Validazione
La validazione corretta non e "il comando e andato a buon fine". Deve dimostrare che:
pwdLastSetdi KRBTGT e cambiato due volte nella finestra corretta- non restano diritti di replica anomali non giustificati
- gli admin umani critici sono protetti con misure piu forti di prima
- l'ambiente usa AES dove dovrebbe e non dipende da RC4 per inerzia
- i ticket precedentemente forgiati non danno piu accesso
Per i team maturi, questa validazione diventa una checklist di incident recovery, non un intervento improvvisato dopo il primo allarme.
Fonti primarie
- Active Directory Forest Recovery - Reset the krbtgt password
- 4768(S, F): A Kerberos authentication ticket (TGT) was requested
- 4769(S, F): A Kerberos service ticket was requested
- Protected Users security group
- DS-Replication-Get-Changes-All extended right
Come EtcSec rileva questo
EtcSec guarda il rischio Golden Ticket nei punti che contano davvero:
- GOLDEN_TICKET_RISK
- WEAK_KERBEROS_POLICY
- KERBEROS_RC4_FALLBACK
- esposizioni adiacenti su diritti di replica, delega e identita Tier 0
La domanda utile non e se hai un bel diagramma Kerberos. La domanda utile e se qualcuno puo ancora ottenere il materiale o i privilegi necessari per firmare TGT credibili.
Letture correlate
Continue Reading
Fallback Kerberos RC4 Active Directory: come rilevarlo, perché continua a verificarsi e come rimuoverlo
CVE-2026-31431 (Copy Fail): cosa interessa la vulnerabilita del kernel Linux e come mitigarla
