Kerberos is how almost every Windows domain proves who you are - a ticket-based dance between a client, the domain controller, and the service you want to reach. Nearly every serious AD attack abuses a specific message in that dance. Play the flow, then drop an attack onto it and watch exactly where the chain gets poisoned.
Kerberos solves one problem: how do you prove your identity to a hundred different services without sending your password to each one? The answer is a trusted broker - the KDC, which runs on the domain controller - that vouches for you with signed, encrypted tickets.
You authenticate once to get a TGT, then trade that TGT for individual service tickets as you go. Crucially, each ticket is encrypted with the recipient's own secret key: the TGT with the krbtgt key, a service ticket with the target service account's key. That elegant design is also the attack surface: steal or crack the right key, and you can forge tickets the KDC and services will happily trust.
Every step in the diagram above maps to a real message on the wire, and every attack in the chips abuses one of them. Understanding which message an attack touches tells you what the attacker needed, what they walked away with, and where you can catch them.
| Attack | Abuses | Needs | Yields |
|---|---|---|---|
| AS-REP Roasting T1558.004 | AS-REP for pre-auth-disabled accounts | No credentials | A user's password (offline crack) |
| Kerberoasting T1558.003 | TGS-REP for a service SPN | Any domain account | A service account's password (offline crack) |
| Pass-the-Ticket T1550.003 | Stolen TGT/service ticket from memory | Local admin on a host | The victim's live access |
| Silver Ticket T1558.002 | Forged service ticket (no KDC) | One service account hash | Quiet access to one service |
| Golden Ticket T1558.001 | Forged TGT | The krbtgt hash | Domain-wide persistence as anyone |
| DCSync T1003.006 | Domain replication protocol | Replication rights | Any hash, including krbtgt |
In the SecIntel domain, SI-DC-01 (192.168.1.2) is the KDC. IRON CHIMNEY reached it with remote authentication after LSASS access, but the investigation does not show Kerberoasting, Pass-the-Ticket, DCSync, or a Golden Ticket. Those techniques are realistic next moves on this diagram, not claimed campaign events: Kerberoast service SPNs, reuse a harvested ticket, or - only after obtaining replication rights - DCSync the krbtgt hash.
That is why domain-controller hardening and krbtgt rotation matter: a single cracked service password is an annoyance, but a stolen krbtgt hash is game over until you rotate it twice. Hunt for these in the SIEM (4769 spikes), Identity, and EDR (LSASS access).
Encryption downgrade & roasting: Kerberoasting and AS-REP roasting both leave Kerberos events on the DC. Hunt Event 4769 (service ticket requested) for bursts from a single account, especially with RC4 encryption (type 0x17) when your domain otherwise uses AES. Hunt Event 4768 with pre-authentication type 0 for AS-REP roasting. Seed a honeypot service account with a fake SPN and alert on any ticket request for it.
Ticket forgery: Golden and Silver tickets forge their own tickets, so look for the seams. Golden Tickets often carry anomalous lifetimes or a TGS request with no preceding AS-REQ. Silver Tickets never touch the KDC at all, so the tell is on the target host: a service logon with no matching 4768/4769 on any DC.
Ticket theft & replication abuse: Pass-the-Ticket shows up as tickets used from an unexpected host - correlate ticket use with LSASS access (Sysmon Event 10) on the source. DCSync is a replication request (Event 4662 with the DS-Replication-Get-Changes GUID) originating from something that is not a domain controller - one of the highest-fidelity alerts you can build.
| Tool | What to hunt |
|---|---|
| SIEM | 4769 bursts + RC4 (0x17) from one user; 4768 pre-auth type 0; 4662 replication from a non-DC |
| EDR | LSASS handle access (Sysmon 10); Mimikatz/Rubeus indicators; ticket injection into a session |
| Identity | Accounts with pre-auth disabled; service accounts with SPNs and weak/old passwords; unexpected admin logons |