Lion Cipher Lab
Detect Kerberos ticket forgery (Golden Ticket + DCSync) from telemetry
- SOC Analyst / Blue Team
- Advanced
- ~75 min
- Free · no account required
Why it matters
A Golden Ticket is one of the highest-severity findings in enterprise security: an attacker who has stolen the krbtgt account's password hash can forge a ticket-granting ticket for ANY user, including a domain admin, entirely OFFLINE -- no interaction with the KDC. That forged TGT then unlocks service tickets across the domain and survives ordinary password resets, so it is a persistence and privilege-escalation primitive at the same time. Its close cousin, DCSync, abuses the directory-replication protocol: a principal with the replication rights can ask a domain controller to hand over…
What you'll learn
- reading a Windows Kerberos event stream: 4768 (AS-REQ, TGT issued), 4769 (TGS-REQ, service ticket), 4624 (logon), 4672 (special privileges), 4662 (directory-object access)
- the core Golden Ticket detection idea: a 4769 service-ticket request for an account with NO preceding 4768 means the TGT it presented was never issued by the KDC -- it was forged offline
- spotting DCSync in telemetry: a 4662 carrying a directory-replication control-access GUID requested by a principal that is NOT a domain controller
- spotting an encryption downgrade: a 4769 using ticket encryption type 0x17 (RC4-HMAC) in an environment whose baseline is 0x12 (AES256) -- an overpass-the-hash / forged-ticket artifact
- writing a from-scratch, stdlib-only telemetry generator and a from-scratch correlating hunter that ranks accounts by risk and tags each finding with ATT&CK
- how this differs from Kerberoasting: Kerberoasting cracks a SERVICE ticket offline; this lab detects a FORGED TGT and replication abuse -- post-compromise persistence, not offline cracking
- naming the false positives honestly: legacy apps that legitimately negotiate RC4, a genuine second DC that replicates, and clock-skew that pushes an AS-REQ outside the correlation window
- the judgment of when to hunt versus when to prevent, and why the true fix is KDC-side: rotate krbtgt TWICE, enforce AES-only, and rely on the 2022+ enforced PAC signatures rather than log-hunting alone
Steps in this lab
- What you are detecting -- and how it differs from Kerberoasting
- Tell #1 -- a Golden Ticket: a TGS-REQ with no AS-REQ
- Tell #2 -- DCSync: a replication GUID from a non-DC
- Tell #3 -- an encryption downgrade to RC4
- Set up your local, disposable lab
- Build the telemetry generator (gen_krb_telemetry.py)
- Build the hunter and run it (hunt_krb_forgery.py)
- Name the false positives -- and the windowing trap
- The judgment: when to hunt, and when to prevent