Golden Ticket: Le Chiavi del Tuo Dominio

Cos'è un attacco Golden Ticket?

Un attacco Golden Ticket è un Ticket Granting Ticket (TGT) Kerberos forgiato che garantisce a un attaccante un accesso illimitato e persistente a tutte le risorse di un dominio Active Directory — senza bisogno della password di alcun utente.

L'attacco sfrutta l'account KRBTGT, il cui hash viene usato per firmare ogni TGT emesso nel dominio. Se un attaccante ottiene questo hash, può fabbricare TGT validi per qualsiasi utente, inclusi gli amministratori di dominio, con qualsiasi appartenenza a gruppi e qualsiasi data di scadenza a sua scelta.

Questo rende il Golden Ticket una delle tecniche di post-exploitation più gravi in Active Directory: un singolo hash rubato si traduce in un controllo indefinito dell'intero dominio.

Come funziona un attacco Golden Ticket

L'autenticazione Kerberos si basa su una terza parte fidata: il Key Distribution Center (KDC), che gira su ogni domain controller.

Il flusso normale:

1. Un utente si autentica presso il KDC e riceve un TGT, firmato con l'hash KRBTGT.
2. L'utente presenta il TGT per richiedere Service Ticket (TGS) per risorse specifiche.
3. I servizi convalidano il TGS e concedono l'accesso.

L'account KRBTGT è la radice di fiducia per ogni TGT del dominio. Nessun servizio convalida i TGT direttamente presso il KDC al momento dell'uso: si fidano della firma. Questo significa che un TGT forgiato, firmato con il vero hash KRBTGT, è indistinguibile da uno legittimo.

La Catena di Attacco

Fase 1 - Ottenere i Domain Admin (o equivalenti)

L'attaccante ha bisogno di privilegi sufficienti per estrarre l'hash KRBTGT. Questo comporta tipicamente la compromissione di un domain controller o di qualsiasi account con i diritti DS-Replication-Get-Changes-All (DCSync).

Percorsi di escalation comuni che portano fin qui: Kerberoasting di un account di servizio privilegiato, abuso di ADCS ESC1/ESC8, o sfruttamento della delega non vincolata.

Fase 2 - Estrarre l'Hash KRBTGT via DCSync

L'attaccante esegue un attacco DCSync con Mimikatz o Impacket per estrarre l'hash NTLM dell'account KRBTGT senza toccare il disco del DC né generare un evento di logon:

# Mimikatz
lsadump::dcsync /domain:corp.local /user:krbtgt

# Impacket (da remoto, da Linux)
impacket-secretsdump -just-dc-user krbtgt corp.local/admin:[email protected]

L'output include l'hash NTLM e il SID del dominio — entrambi necessari per forgiare il ticket.

Fase 3 - Forgiare il Golden Ticket

Con l'hash KRBTGT e il SID del dominio, l'attaccante fabbrica un TGT per l'utente che sceglie:

# Mimikatz — forgiare e iniettare direttamente nella sessione corrente
kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-XXXXXXXXXX /krbtgt:HASH /ptt

Parametri chiave:

Fase 4 - Accesso Totale al Dominio e Persistenza

Il TGT forgiato viene accettato da tutti i servizi del dominio. L'attaccante può ora:

• Accedere a qualsiasi condivisione file, sessione RDP, endpoint WMI o servizio DCOM
• Creare nuovi account backdoor e aggiungerli a gruppi privilegiati
• Distribuire GPO malevole su tutte le macchine
• Persistere indefinitamente — il reset della password di qualsiasi account utente non ha alcun effetto

Rilevamento

I Golden Ticket sono difficili da rilevare perché i TGT forgiati assomigliano a traffico Kerberos legittimo. Il KDC non viene consultato al momento dell'uso del ticket, quindi non viene generato alcun evento di autenticazione sul DC quando il ticket viene presentato a un servizio.

Il rilevamento si basa sull'analisi delle anomalie piuttosto che sulla correlazione diretta degli eventi.

Event ID di Windows

Anomalie Comportamentali

• Durata del ticket superiore a 10 ore - il massimo predefinito di Microsoft è 10 ore; i ticket forgiati hanno spesso una durata di anni
• Nomi utente inesistenti negli eventi Kerberos - i Golden Ticket possono essere forgiati per account che non esistono in AD
• Crittografia RC4 quando il dominio impone solo AES - gli strumenti più vecchi usano RC4 (0x17) di default
• Richiesta TGS senza un AS-REQ precedente - una richiesta di service ticket su un DC senza una corrispondente richiesta di TGT è un indicatore forte
• Mismatch del SID - il SID incorporato nel ticket non corrisponde a nessun account AD reale

Query SIEM (Elastic KQL)

event.code: "4769" AND
winlog.event_data.TicketEncryptionType: "0x17" AND
NOT winlog.event_data.ServiceName: ("krbtgt" OR "*$")

event.code: "4768" AND
winlog.event_data.TicketEncryptionType: "0x17" AND
winlog.event_data.PreAuthType: "0"

Remediation

Risposta Immediata

Ruota la password KRBTGT due volte, con un ritardo tra le rotazioni pari alla durata massima del ticket Kerberos (predefinita: 10 ore).

• La prima rotazione invalida tutti i ticket forgiati attualmente attivi.
• La seconda rotazione rimuove il vecchio hash dalla memoria dei DC, impedendo l'uso di ticket forgiati con il vecchio hash.

Usa lo script di reset KRBTGT attivamente mantenuto, che gestisce automaticamente i controlli di replica multi-DC:

# Scaricare ed eseguire Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1
# https://github.com/zjorz/Public-AD-Scripts/blob/master/Reset-KrbTgt-Password-For-RWDCs-And-RODCs.md

.\Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1 -modeOfOperation resetModeKrbTgtProdAccountsResetOnce -targetedADforestFQDN corp.local -targetedADdomainFQDN corp.local -targetKrbTgtAccountScope allRWDCs
# Attendere almeno 10 ore (durata massima del ticket)
.\Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1 -modeOfOperation resetModeKrbTgtProdAccountsResetOnce -targetedADforestFQDN corp.local -targetedADdomainFQDN corp.local -targetKrbTgtAccountScope allRWDCs

Hardening per Prevenire la Compromissione Iniziale

Verificare l'Esposizione a DCSync

# Trovare gli account con diritti DCSync (account non-DC con permessi di replica)
Get-ADObject -Filter * -Properties nTSecurityDescriptor | Where-Object {
    $_.nTSecurityDescriptor.Access | Where-Object {
        $_.ObjectType -eq "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2" -and
        $_.IdentityReference -notmatch "Domain Controllers"
    }
}

Come EtcSec Rileva Questo

EtcSec verifica le condizioni che rendono possibili e persistenti gli attacchi Golden Ticket nel tuo ambiente.

La detection GOLDEN_TICKET_RISK segnala gli ambienti in cui la password dell'account KRBTGT non è stata ruotata di recente — un indicatore diretto che un Golden Ticket forgiato in precedenza potrebbe essere ancora valido.

Controlli correlati aggiuntivi:

• WEAK_KERBEROS_POLICY - impostazioni di durata e rinnovo dei ticket Kerberos che estendono la finestra di esposizione ai ticket forgiati
• KERBEROS_RC4_FALLBACK - crittografia RC4 ancora consentita sul dominio, necessaria per forgiare ticket con strumenti più vecchi e che rende più difficile il rilevamento
• UNCONSTRAINED_DELEGATION - account con delega non vincolata che possono essere usati per catturare TGT, un precursore comune degli attacchi Golden Ticket

Priorità di Revisione

Golden Ticket: Le Chiavi del Tuo Dominio deve essere trattato come un'esposizione reale all'interno del tuo ambiente Active Directory, non come un singolo parametro isolato. Inizia definendo il perimetro di revisione: quali gruppi privilegiati, account di servizio, ACL, collegamenti GPO, trust, deleghe, template dei certificati e workstation di amministrazione sono coinvolti, quali flussi di lavoro aziendali ne dipendono, quali privilegi espongono e quali eccezioni di emergenza sono state aggiunte nel tempo. Questo passaggio di definizione del perimetro previene una remediation superficiale, perché il sintomo tecnico è spesso più piccolo del raggio d'impatto operativo. Documentando il percorso completo dalla configurazione al privilegio, il team può dare priorità ai cambiamenti che riducono il rischio rapidamente senza interrompere l'accesso in produzione. Questo crea anche una base difendibile per la validazione successiva e offre alla leadership una spiegazione chiara del perché il problema conta ora.

Controlli Adiacenti da Revisionare

Quando gli attaccanti raggiungono il tuo ambiente Active Directory, raramente si fermano al primo punto debole. Attorno a Golden Ticket: Le Chiavi del Tuo Dominio, normalmente testano se il percorso esposto può essere concatenato con account privilegiati obsoleti, nesting di gruppi non sicuro, deleghe eccessive, impostazioni di password deboli, percorsi GPO scrivibili e abuso di ACL ereditate. Questo significa che i difensori devono revisionare non solo la debolezza principale, ma ogni dipendenza vicina che trasforma l'accesso in persistenza o escalation di privilegi. Conferma quali identità, ruoli, permessi e assunzioni di trust possono essere riutilizzati da un operatore motivato. Se una correzione chiude un solo oggetto lasciando intatti i percorsi di privilegio adiacenti, il rischio effettivo cambia poco. Una revisione disciplinata delle opportunità di concatenamento è ciò che trasforma questo argomento in un esercizio di hardening pratico piuttosto che in una semplice casella da spuntare.

Letture Correlate

Rivedi questo argomento insieme a Attacchi di Delega Kerberos: Dalla Non Vincolata all'RBCD, Kerberoasting: Come gli Attaccanti Craccano le Password degli Account di Servizio, Abuso di ACL e DCSync: I Percorsi Silenziosi verso il Domain Admin, Attacchi ai Trust di Active Directory: dal Dominio Figlio alla Radice della Foresta e AS-REP Roasting: Raccogliere Hash Senza Credenziali. Questi articoli correlati mostrano come le stesse debolezze di identità si concatenano solitamente in una valutazione reale, invece di apparire come riscontri isolati.

• Attacchi di Delega Kerberos: Dalla Non Vincolata all'RBCD
• Kerberoasting: Come gli Attaccanti Craccano le Password degli Account di Servizio
• Abuso di ACL e DCSync: I Percorsi Silenziosi verso il Domain Admin
• Attacchi ai Trust di Active Directory: dal Dominio Figlio alla Radice della Foresta
• AS-REP Roasting: Raccogliere Hash Senza Credenziali

Usare questi riferimenti mantiene la discussione sulla remediation focalizzata sull'intero percorso di attacco piuttosto che su una singola lacuna di controllo.

Checklist di Validazione

Prima di chiudere la revisione, riesegui gli stessi controlli che hanno rivelato il problema e conferma che il percorso a rischio non esiste più dal punto di vista dell'attaccante. Verifica le identità, i privilegi, i percorsi di ereditarietà e i controlli compensativi rilevanti in produzione, non solo in staging o nella documentazione. Registra il proprietario tecnico, la dipendenza aziendale attesa e le prove che dimostrano che la nuova configurazione è al contempo più sicura e operativamente sostenibile. Questo passaggio finale di validazione è ciò che mantiene l'articolo ancorato a come i team riducono realmente il rischio di identità.