Hunting Kerberos Ticket Attacks: Golden Tickets, Kerberoasting, and DCSync in Your Own Logs

The quietest domain compromise has no malware

No exploit lands. No file drops. No alert fires. An attacker who already holds a foothold requests a few Kerberos tickets, cracks one offline, and walks back into your domain as a service account with a fifteen-year-old password. Days later, a forged ticket grants them domain admin, and the only evidence is a handful of ordinary-looking authentication events on your domain controllers.

This deep-dive covers the four attacks in the chain — Kerberoasting, AS-REP roasting, DCSync, and Golden/Silver ticket forgery — with the event IDs, fields, and queries to hunt each one.

Kerberos in sixty seconds

Every Windows domain runs on Kerberos. When a user logs in, the Key Distribution Center (KDC) on a domain controller issues a Ticket-Granting Ticket (TGT). The user presents that TGT to request a service ticket for each resource they touch — a file share, a database, a web app. Each service ticket is encrypted with the secret of the account that owns the service.

Three properties of that design are what attackers abuse: any authenticated user can request a service ticket for any service; the encrypted part of a service ticket is sealed with the service account's password hash, so whoever holds the ticket can try to crack it offline with no lockouts and no further contact with your network; and tickets are trusted on their face — a service accepts a ticket that decrypts correctly without asking the domain controller whether it was legitimately issued.

Kerberoasting: the lowest bar in the chain

Kerberoasting (MITRE ATT&CK T1558.003) needs nothing more than a valid domain user account. The attacker enumerates accounts with a Service Principal Name (SPN) — typically service accounts running SQL Server, IIS, or scheduled tasks — requests a service ticket for each one, and cracks the tickets offline with hashcat.

The signal is not any single request: a service ticket request is normal Kerberos traffic. The signal is the pattern — one account, many distinct SPNs, in a short window, asking for RC4.

Two fields in Event ID 4769 (Kerberos service ticket requested, logged on domain controllers) do the work:

Ticket Encryption Type. 0x17 is RC4-HMAC, the legacy cipher whose tickets are far cheaper to crack than AES. Roasting tools request RC4 deliberately. In a domain that otherwise issues AES (0x12 AES256, 0x18 AES128), a burst of RC4 requests is a downgrade attempt, not a configuration quirk.
Volume and target selection. A real user touches one or two services. A roasting tool touches dozens of distinct SPNs in minutes, and it targets user service accounts, not machine accounts.

A note on honesty: RC4 is not proof by itself. Legacy applications still request RC4 legitimately, and some Linux-joined hosts receive RC4 tickets despite correct configuration. Baseline your environment first — know which accounts legitimately request RC4 — or the alert will drown you in false positives. The detection below filters machine accounts and the krbtgt account out, and sets the threshold at five distinct SPNs in ten minutes. Tune it to your baseline.

Hunt: Kerberoasting burst (KQL, Microsoft Sentinel / Defender)

SecurityEvent
| where EventID == 4769
| where TicketEncryptionType == "0x17"
| where ResultCode == "0x0"
| where TargetUserName !endswith "$"
| where TargetUserName != "krbtgt"
| summarize DistinctSPNs = dcount(ServiceName),
            Services = make_set(ServiceName),
            FirstSeen = min(TimeGenerated)
    by TargetUserName, IpAddress, bin(TimeGenerated, 10m)
| where DistinctSPNs >= 5
| order by DistinctSPNs desc

The fix that removes the attack

Detection is second prize. The root cause is service accounts with SPNs, weak passwords, and RC4. The durable fixes, in order of impact: move service accounts to Group Managed Service Accounts (gMSAs) — long, random, automatically rotated passwords that cannot be cracked from a roasted ticket in any practical timeframe; set msDS-SupportedEncryptionTypes to AES-only on service accounts and retire RC4 domain-wide, so any RC4 request becomes an anomaly by definition; and audit which accounts hold SPNs regularly — every SPN you delete is one less roastable target.

AS-REP roasting: no password required

AS-REP roasting targets accounts with Kerberos pre-authentication disabled. Without pre-authentication, an attacker can request authentication data for such an account without knowing — or having — any credentials at all, then crack the response offline.

Hunt it in Event ID 4768 (TGT requested) on the domain controller: look for requests where the pre-authentication type is 0, especially at volume or against accounts that never log on interactively. The remediation is a configuration check, not a patch: find accounts with pre-authentication disabled, re-enable it, and treat any account that cannot have it enabled as a high-value target to watch and isolate.

DCSync: the domain controller hands over its own keys

DCSync (T1003.006) is the step that turns a privileged account into total compromise. It abuses the Directory Replication Service Remote Protocol (DRSUAPI): an account holding the "Replicating Directory Changes" and "Replicating Directory Changes All" extended rights asks a domain controller to replicate credential data — NTLM hashes and Kerberos keys — as if it were another domain controller. The tools are Mimikatz (lsadump::dcsync) and Impacket's secretsdump.py.

What makes DCSync nasty is what it doesn't do: it runs remotely from a workstation, needs no code execution on the domain controller, and never touches LSASS or disk, so endpoint controls built to catch credential dumping see nothing. The prize is usually the krbtgt account hash — the key that signs every TGT in the domain, and the raw material for a Golden Ticket.

Detection is one of the cleanest signals in Active Directory hunting, because the request itself is logged. Enable the Audit Directory Service Access subcategory and place a SACL on the domain object, and a replication request generates Event ID 4662 with a control-access GUID in the Properties field. Three GUIDs matter:

1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 — DS-Replication-Get-Changes
1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 — DS-Replication-Get-Changes-All
89e95b76-444d-4c62-991a-0facbeda640c — DS-Replication-Get-Changes-In-Filtered-Set

The rule is simple: alert on any of those GUIDs from an account that is not a legitimate domain controller. Use an explicit allowlist of your DC computer accounts — do not just exclude every account ending in $, because an attacker who controls a computer account with replication rights can DCSync from it. Also watch Event ID 5136 for changes to the domain root security descriptor that grant replication rights to a new principal; that is the setup step, and it happens before the theft.

Hunt: DCSync request from a non-DC (Splunk)

index=wineventlog EventCode=4662
  (Properties="*1131f6aa-9c07-11d1-f79f-00c04fc2dcd2*"
   OR Properties="*1131f6ad-9c07-11d1-f79f-00c04fc2dcd2*"
   OR Properties="*89e95b76-444d-4c62-991a-0facbeda640c*")
| stats count values(ComputerName) as DCs by SubjectUserName, IpAddress

Then compare SubjectUserName against your known DC list. Anything that is not a DC is the incident. (Field names vary with your Splunk TA for Windows; the GUIDs and the event ID are the stable part.)

Audit the rights today

DCSync needs the rights before it can be used, so the cheapest preventive control is an audit: list every principal holding Replicating Directory Changes (All) on the domain object. The legitimate set is small — domain controllers, Enterprise Domain Controllers, and any sync service account such as Entra Connect. Anything else is a finding; remove it, and the attack cannot run from that account.

Golden Tickets: forging trust at the root

A Golden Ticket (T1558.001) is a forged TGT, created offline with the stolen krbtgt hash. It grants access to any service in the domain, for any user — including accounts that do not exist — typically with a ten-year lifetime. The attacker never needs to authenticate again until the krbtgt password changes twice.

The classic detection exploits the ticket's origin story: a forged ticket was never issued by a domain controller, so the initial request never happened. If you see Event ID 4769 (service ticket requested) for a user, but no corresponding Event ID 4768 (TGT requested) within the ticket's lifetime, the TGT was forged. Other tells: ticket lifetimes far beyond your domain's configured maximum (default ten hours), and tickets presented for disabled or nonexistent accounts.

// Hunt hypothesis: service tickets with no preceding TGT request.
// Correlate 4769 against 4768 per account over your ticket lifetime window.
SecurityEvent
| where EventID == 4769
| where TargetUserName !endswith "$"
| where ResultCode == "0x0"
| join kind=leftanti (
    SecurityEvent
    | where EventID == 4768
    | where ResultCode == "0x0"
    | project TargetUserName, TGTTime = TimeGenerated
) on TargetUserName

Treat this as a hunt hypothesis, not a production alert: the join is expensive at domain scale and the time-window alignment needs care. Run it scoped to a suspicious account or a short window first, then promote what works.

Silver Tickets and Diamond Tickets: the quieter variants

A Silver Ticket forges a service ticket directly, using the password hash of a specific server's computer account instead of the domain-wide krbtgt hash. It grants access only to that one server — but it is stealthier than a Golden Ticket, because it never touches the domain controller at all. Domain controller logs will not show it. Detection depends on logging at the target service itself: service-level access logs showing authentication patterns inconsistent with the account's established behaviour. If you only collect DC logs, you are blind to Silver Tickets. Collect from the high-value services too.

A Diamond Ticket modifies a legitimate TGT's Privilege Attribute Certificate (PAC) rather than forging a ticket wholesale. The defence is Microsoft's PAC signature validation enforcement (KB5020805, CVE-2022-37967): set the validation level to full enforcement so modified PACs are rejected.

The lab walkthrough: run the whole chain in an afternoon

You can build this detection capability in a lab before you need it in production. The setup is deliberately small: two domain controllers, one member server, and a SIEM or log forwarder.

Turn on the logging first. Enable Advanced Audit Policy on the DCs: Kerberos Authentication Service, Kerberos Service Ticket Operations, Directory Service Access, and Directory Service Changes — all success and failure. Without 4768, 4769, 4771, 4662, and 5136 flowing to your SIEM, there is nothing to hunt.
Baseline a normal week. Count distinct SPNs per requester per day, list every account that requests RC4, and enumerate who holds replication rights. These three lists are your allowlist — every detection above is a deviation from them.
Simulate Kerberoasting. From a domain-joined workstation as a standard user, request service tickets for several SPNs and watch the 4769 burst land in your SIEM. Confirm your query fires and your threshold is right.
Simulate DCSync. Grant a test account replication rights, run the request, and confirm the 4662 event appears with the right GUID — then confirm the alert fires when the source is not a DC, and stays quiet during legitimate DC-to-DC replication.
Simulate the Golden Ticket tell. Forge a ticket in the lab and confirm the 4769-without-4768 correlation surfaces it. This is the detection you will be glad you tested before an incident, not during one.
Write the runbook while it is fresh. For each detection: what the analyst checks first, what confirms it, and what the containment step is.

That last step matters more than the queries. The queries take an afternoon; the runbook is what turns an alert at 2 a.m. into a contained incident instead of a debate.

Remediation: burning the attacker out

Detection without a remediation plan is just a faster way to watch the domain fall. The sequence, once ticket forgery is confirmed:

Reset the krbtgt password twice. Active Directory keeps a two-password history so existing tickets keep working during rotation, which means a single reset leaves the stolen hash usable. Reset once, wait for replication and for the maximum ticket lifetime to elapse (default ten hours), then reset again. The second reset purges the compromised key. Do not run both resets back-to-back without the wait, or every active session in the domain drops at once.
Reset the passwords of every account the attacker touched, starting with the roasted service accounts and any account used in the DCSync. A krbtgt rotation invalidates forged tickets; it does not remove the attacker's foothold or the credentials they already cracked.
Reset the computer account passwords of the affected servers to kill Silver Tickets forged from them, and remove the access path: revoke the replication rights, disable pre-authentication exemptions, and remove the SPNs that made roasting possible. Then re-audit — a krbtgt reset alone will not stop an attacker who still holds a privileged account from simply doing it again.

Defensive takeaways

Collect DC logs like they are the crown jewels, because they are. 4768, 4769, 4771, 4662, and 5136 cover this entire chain. If they are not in your SIEM, you are not hunting Kerberos attacks — you are hoping.
RC4 is the tell. In an AES domain, RC4 ticket requests are an anomaly by definition. Retiring RC4 converts a noisy heuristic into a high-confidence signal.
Allowlist, don't denylist. DCSync detection works because the set of legitimate replicators is tiny and known. The same applies to RC4 requesters and SPN counts: baseline first, alert on deviation.
Silver Tickets are invisible from the DC. If your logging stops at the domain controller, a Silver Ticket is undetectable. Log at the services that matter.
Hygiene beats detection. gMSAs, AES-only enforcement, and a minimal replication-rights list remove these attacks at the root. Detection is for the attacks hygiene missed — and for proving hygiene is working.