Skip to content
Home/Blog/CRTE Tradecraft: Golden Ticket Chains and Detectio...
Back to blog

CRTE Tradecraft: Golden Ticket Chains and Detection Gaps

2026-07-02

14 min

crteactive-directorylateral-movement

The Certified Red Team Expert (CRTE) certification is a hands-on course in multi-forest Active Directory exploitation. It focuses on techniques for lateral movement across trust boundaries, forging Kerberos tickets, and evading modern detection. The lab spans multiple forests with varying trust relationships, simulating real enterprise infrastructure.

One of the most powerful techniques taught is the golden ticket: a forged Ticket Granting Ticket (TGT) that allows you to impersonate any principal in the domain. But the real power is not in the ticket alone-it is in chaining forged tickets across forest boundaries to build a path to domain dominance.

Understanding the Kerberos Ticket

Before exploiting Kerberos, you need to understand what a TGT is:

  • A TGT is encrypted with the KRBTGT account's NTLM hash
  • KRBTGT is the Kerberos ticket granting service account in every domain
  • If you know the KRBTGT hash, you can forge a TGT for any user, in any domain, with any group memberships

The attack surface: the KRBTGT account's hash is stored in the NTDS.dit database. If you achieve domain admin, you can dump the KRBTGT hash. If you cannot, you can attack the KDC directly.

Golden Ticket Attack: The Basics

The attack is mechanical:

  1. Compromise a domain admin account or dump NTDS.dit
  2. Extract the KRBTGT hash
  3. Use Mimikatz to forge a TGT with golden ticket syntax: kerberos::golden /domain:corp.com /sid:S-1-5-21-xxxxx /krbtgt:aes256hash /user:Administrator /ticket:golden.kirbi
  4. Use the forged ticket to access any resource in that domain

The catch: modern detection flags golden tickets through several mechanisms:

  • Ticket Timestamp Analysis: forged tickets often have invalid timestamps (e.g., created in the future, or from years ago)
  • Ticket Validity Periods: golden tickets can be crafted with decade-long validity; real tickets are shorter
  • Authentication Patterns: using a golden ticket to access multiple resources across the domain in rapid succession is anomalous

In CRTE, I learned that the detection gap is in the timeline. A well-crafted golden ticket uses realistic timestamps, validity periods that match the domain policy, and access patterns that mimic legitimate user behavior.

Multi-Forest Golden Ticket Chains

The real power is not forging a ticket in one forest. It is forging tickets across forest trusts to move laterally.

Scenario: You have compromised corp.com. You need to access trusted.com (another forest). The trust relationship exists: corp.com trusts trusted.com for external trusts.

Attack steps:

  1. Dump KRBTGT hash from corp.com
  2. Forge a TGT for corp.com claiming you are a user in corp.com
  3. Use that TGT to request a referral ticket (inter-realm ticket) to trusted.com
  4. The KDC in corp.com issues a referral, but the referral is encrypted with a shared secret between the two forests
  5. Use Mimikatz to forge a TGT in trusted.com, claiming you are a user in trusted.com (SIDHistory attack)

The SIDHistory attack is the key:

  • Windows allows a user's SIDHistory to contain SIDs from trusted domains
  • If you forge a TGT claiming to be a trusted.com user with a corp.com admin SID in SIDHistory, you inherit permissions from both forests
  • Access control entries (ACEs) that reference corp.com admins will grant access to your forged principal

In practice:

mimikatz # kerberos::golden /domain:trusted.com /sid:S-1-5-21-yyyyy /krbtgt:trustedkrbtgt /user:Administrator /sids:S-1-5-21-xxxxx-519 /ticket:interrealm.kirbi

The /sids parameter adds the corp.com domain admins SID to your forged ticket. When you use this ticket to access resources in trusted.com, your token includes both trusted.com and corp.com permissions.

The Detection Reality

Modern SOCs look for:

  • Authentication Across Forest Boundaries: inter-realm ticket requests are logged. A spike in these requests is suspicious.
  • SID History Anomalies: SIDHistory is a legitimate historical artifact, but SIDHistory populated for current users is red-flag material.
  • Forged Kerberos Tickets: the Kerberos Key Distribution Center (KDC) can detect tickets with invalid cryptographic properties, but only if the verification is enabled (it is not by default).

In CRTE labs, detection was minimal. In real enterprise networks:

  • Splunk or Sumo Logic: correlate Kerberos event IDs (4768 for TGT requests, 4769 for service ticket requests) against baseline behavior
  • Zeek or Suricata: detect Kerberos traffic patterns that indicate mass ticket requests or unusual inter-realm activity
  • EDR (CrowdStrike, Sentinel One): detect process behavior that follows immediately after a golden ticket is injected (e.g., accessing admin shares, modifying group policy)

Evasion: Slow and Steady Movement

The detection gap is time. A compromised forest admin moving slowly through the second forest, accessing a few resources over days or weeks, will not trigger batch detection rules.

The tradeoff: slower access means longer time-to-objective. In a CRTE exam or security test, you have constraints (time limit, analyst watching). In a real APT, patience is an advantage.

Techniques for evasion:

  1. Spacing out ticket requests: instead of accessing 100 resources in one evening, spread access over several days
  2. Using legitimate access patterns: admins access certain resources regularly; mimic that pattern
  3. Avoiding sensitive accounts: instead of forging the Administrator account TGT, forge a service account TGT that still has high permissions
  4. Limiting ticket scope: forge tickets for specific services (file shares, print servers) rather than domain-wide access

The Critical Detection Gap: KRBTGT Hash Not Required

One technique often overlooked: you do not always need the KRBTGT hash to forge a TGT. If you control a domain-joined computer, you can extract the krbtgt hash from memory of the KDC itself, or you can perform a DC sync attack to force the DC to replicate the KRBTGT hash to your attacker machine.

The DC sync attack is particularly dangerous:

  1. Compromise any account with directory replication permissions (domain admins, enterprise admins, or certain custom groups)
  2. Use Mimikatz to perform a directory replication sync: lsadump::dcsync /domain:corp.com /user:krbtgt
  3. Extract all domain user password hashes and the KRBTGT hash in one attack

Detection:

  • The DC sync request is logged as event ID 4662 (LDAP operations) if auditing is enabled
  • But by default, auditing is not enabled for LDAP operations
  • Even with auditing enabled, the signal is noisy: legitimate replication traffic is constant

Lesson: The Ticket is Just the First Step

A golden ticket is a primitive. The real attack is chaining it with other techniques:

  • Credential theft: once you have access, dump credentials to compromise additional systems
  • Persistence: install persistence mechanisms (skeleton keys, DSRM backdoors, forest-wide backdoors via GPOs)
  • Covering tracks: remove event logs, disable auditing, clear DNS cache

In CRTE, these chains took the place of individual techniques. The exam required not just forging a ticket, but demonstrating a full attack path from initial compromise to forest-wide persistence.

Resources and Further Reading

  • CRTE course materials (eLearnSecurity)
  • Harmj0y's blog on Kerberos and Golden Tickets
  • Will Schroeder's research on forest trust exploitation
  • Microsoft documentation on Kerberos authentication and SIDHistory

The CRTE certification taught me that Active Directory exploitation is about understanding trust relationships, abusing delegation, and moving silently through the forest. Golden tickets are a tool; the art is knowing when and how to use them without triggering detection.