Anatomy of a Kerberoasting Attack — and How to Detect It

Kerberoasting detection is a behavioural problem, not a patching one. Kerberoasting is one of the most reliable privilege-escalation techniques in Active Directory, and it has nothing to do with an unpatched bug — it abuses a core Kerberos design decision. That is exactly why it is worth understanding as a defender: you cannot patch it away, so you have to detect it at the moment of ticket request and make the offline crack economically worthless. This guide walks the technique conceptually, then ships the detections, the tuning, the triage runbook, and the hardening.

What is Kerberoasting?

Kerberoasting is an attack in which an authenticated domain user requests Kerberos service tickets for accounts that have a Service Principal Name, then cracks those tickets offline to recover the service account’s password. It requires no special privilege, exploits no vulnerability, and produces no errors on the target service.

In Active Directory, services run under accounts identified by a Service Principal Name (SPN). When a user wants to talk to a service, they ask the Key Distribution Center for a service ticket (a TGS). The KDC returns that ticket encrypted with the service account’s password hash — and crucially, the KDC does not check whether the requesting user can actually reach the service, or has any business doing so.

So any authenticated domain user can request a TGS for any SPN. An attacker with a single low-privilege foothold enumerates accounts that have SPNs set, requests tickets for the valuable ones, and takes the encrypted tickets offline. There, with no rate limit and no logging on the target, they brute-force the service account’s password against the ticket — the same offline-cracking economics that make WPA2 PMKID capture dangerous. If the service account has a weak password, it falls — and service accounts are frequently over-privileged, which is what turns a foothold into a domain compromise.

The MITRE ATT&CK mapping is T1558.003 (Steal or Forge Kerberos Tickets: Kerberoasting), typically followed by T1550.003 (Use Alternate Authentication Material: Pass the Ticket) once a credential is recovered.

Kerberoasting, targeted Kerberoasting, and AS-REP roasting

Three related techniques get conflated, and they produce different telemetry:

Targeted Kerberoasting is worth a dedicated detection because it leaves a distinctive precursor: the attacker writes a servicePrincipalName onto an account that never had one. Directory change auditing (Event ID 5136) on the servicePrincipalName attribute catches this before any ticket is requested, and legitimate SPN changes are rare and schedulable.

AS-REP roasting deserves a mention because it needs no credentials whatsoever. Audit for accounts with DONT_REQ_PREAUTH set — that list should be empty, and if it is not, those accounts are crackable by anyone who can reach a domain controller and guess a username.

What does Kerberoasting look like in telemetry?

The offline cracking is invisible to you, so detection has to happen at the moment of ticket request. The signal lives in Windows Security Event ID 4769 (A Kerberos service ticket was requested).

The encryption types you will see: 0x17 is RC4-HMAC, 0x12 is AES256, and 0x11 is AES128. Anything older than RC4 in a modern domain is a misconfiguration worth fixing regardless of this attack.

Machine accounts (names ending in $) are the dominant false positive and should be filtered early — computers request service tickets constantly as part of normal operation.

How to detect Kerberoasting

Layer three detections. Each catches something the others miss, and the third is close to free.

Signal 1: RC4 requests in an AES environment

title: Potential Kerberoasting via RC4 Service Ticket Request
id: 4a1b9e2c-darkpwn-illustrative
status: experimental
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4769
    TicketEncryptionType: '0x17'   # RC4-HMAC
    Status: '0x0'                  # successful issuance only
  filter_machine:
    ServiceName|endswith: '$'       # ignore machine accounts
  filter_krbtgt:
    ServiceName: 'krbtgt'
  condition: selection and not filter_machine and not filter_krbtgt
falsepositives:
  - Legacy services that genuinely require RC4
  - Some backup and monitoring agents
level: medium

Signal 2: SPN fan-out relative to a per-account baseline

A single 4769 event is noise. The durable detection is behavioural: baseline how many distinct SPNs each account normally requests, then alert on the accounts that suddenly fan out.

index=windows EventCode=4769 Status="0x0"
| where NOT match(ServiceName, "\$$") AND ServiceName!="krbtgt"
| bin _time span=10m
| stats dc(ServiceName) AS distinct_spns,
        values(ServiceName) AS spns,
        sum(eval(if(TicketEncryptionType=="0x17",1,0))) AS rc4_count,
        dc(IpAddress) AS src_hosts by _time, TargetUserName
| eventstats avg(distinct_spns) AS baseline_avg,
             stdev(distinct_spns) AS baseline_sd by TargetUserName
| eval threshold = max(5, baseline_avg + (3 * baseline_sd))
| where distinct_spns > threshold
| eval severity = if(rc4_count > 0, "high", "medium")
| table _time, TargetUserName, distinct_spns, threshold, rc4_count, src_hosts, spns

Signal 3: the honeypot SPN — the one to build first

// Decoy accounts with an SPN set, no privileges, and no real service behind them.
let honeypotSpns = dynamic(["svc-backup-legacy", "svc-sql-archive"]);
SecurityEvent
| where EventID == 4769
| where ServiceName has_any (honeypotSpns)
| extend Requester = TargetUserName, Src = IpAddress,
         EncType = TicketEncryptionType
| project TimeGenerated, Requester, ServiceName, Src, EncType, Status
| order by TimeGenerated desc

What telemetry do you need?

1. Event ID 4769 collected from every domain controller. This is the common failure. Ticket requests are served by whichever DC the client contacts, so collecting from a subset means you see a random fraction of the attack. Verify coverage against your DC inventory, not your assumptions.

2. Kerberos audit policy enabled. “Audit Kerberos Service Ticket Operations” must be on for success events. Failure-only auditing misses the successful issuance that constitutes exposure.

3. Sufficient retention for baselining. Thirty days minimum, or the fan-out baseline has nothing to learn from.

4. Event ID 5136 with directory-change auditing on servicePrincipalName, if you want to catch targeted Kerberoasting before the ticket request.

5. A parsed TicketEncryptionType field. Some pipelines store it as a decimal integer rather than the 0x17 hex string, which silently breaks every rule copied from the internet. Check a real event.

Which false positives will you actually see?

The scanner row is the one to get right. Allowlisting a scanner account alone makes it the most attractive identity in your domain — an attacker who compromises it gets to enumerate the entire SPN inventory invisibly. Always scope the exclusion to account and source host.

How do you triage a Kerberoasting alert?

1. Check the honeypot first. If the honeypot SPN was requested, skip straight to treating this as a confirmed compromised account. Nothing else needs establishing.
2. Identify the requesting account and source host. This is your foothold, and the source host is where the attacker is operating from.
3. List every SPN whose ticket was successfully issued. Those service accounts are the exposure — the attacker holds crackable material for each one, right now.
4. Rank that list by privilege. A cracked account matters in proportion to what it can reach. Domain-admin-equivalent service accounts are an emergency; a scoped app account is not.
5. Assume the passwords are recoverable and reset them, hardest-hitting first. Treat weak or old passwords as already cracked — offline cracking is silent and you cannot know when it finishes.
6. Check for pass-the-ticket activity. Authentication by those service accounts on hosts they have no history of touching means a crack already succeeded (lateral movement detection covers the follow-on).
7. Investigate how the foothold account was compromised. Kerberoasting is a step, not an entry point — something granted the attacker a valid domain credential first.
8. Migrate the exposed accounts to gMSAs rather than just rotating them, so the next enumeration produces nothing worth cracking.

Step 5 is where teams hesitate, because rotating a service account password risks breaking the service. Rehearse it: know which application owns each SPN account and how its credential is updated, before the incident. A password reset you cannot perform under pressure is not a remediation option.

How to test your Kerberoasting detection

In a lab domain you own:

1. Request service tickets for several SPNs from a standard domain account and confirm the fan-out rule fires at your threshold.
2. Request a ticket with RC4 explicitly and confirm the encryption-type rule fires.
3. Request a ticket for the honeypot SPN and confirm the alert is high severity and immediate.
4. Confirm normal workstation activity does not trip the fan-out rule over a full working day.
5. Set an SPN on a test account and confirm the Event ID 5136 targeted-Kerberoasting rule fires.
6. Verify the rules fire regardless of which domain controller served the request.

Step 6 catches the single most common deployment gap in this detection class.

How to prevent Kerberoasting

• Use (Group) Managed Service Accounts. gMSAs use 120-character, automatically rotated passwords that are not realistically crackable. This is the single highest-leverage fix.
• Enforce long, random passwords on every SPN account that cannot be a gMSA — 25+ characters, generated, never reused.
• Disable RC4 domain-wide and require AES, removing the attacker’s fast path. Audit first; some legacy services break.
• Apply least privilege. A cracked service account should not be a domain admin. Most Kerberoasting wins come from over-privileged service accounts.

Which control should you deploy first?

The honest sequence: honeypot SPN today (it costs nothing and detects the technique immediately), audit for preauth-disabled accounts this week, set long generated passwords on every SPN account this month, then work gMSA migration and RC4 removal as the quarter-scale projects they genuinely are.

Note the RC4 row carefully. Disabling RC4 is frequently presented as the Kerberoasting fix and it is not — AES tickets are still issued and still crackable, merely much more slowly. A weak service-account password remains recoverable against an AES ticket. RC4 removal raises the attacker’s cost; only password strength removes the payoff.

Common Kerberoasting detection mistakes

• Collecting 4769 from only some domain controllers. You see a random fraction of the attack.
• Alerting on single RC4 events. Noisy, gets muted, and misses AES-based roasting entirely.
• Treating RC4 removal as the fix. It removes the fast path, not the technique.
• No honeypot SPN. Skipping the cheapest, highest-fidelity detection available.
• Allowlisting scanner accounts without pinning the host. You just created the ideal identity for an attacker to compromise.
• Ignoring AS-REP roasting. It needs no credentials at all and lives in a different event ID.
• Forgetting targeted Kerberoasting. An attacker who can write an SPN creates their own target.
• Rotating passwords without knowing which app owns the account. The reset you cannot perform is not a remediation.

Kerberoasting detection checklist

1. Collect Event ID 4769 from every domain controller; verify against DC inventory.
2. Enable Kerberos service-ticket auditing for success, not failure only.
3. Confirm TicketEncryptionType is parsed in the form your rules expect.
4. Filter machine accounts ($) and krbtgt before anything else.
5. Deploy a honeypot SPN account today — realistic name, 100+ char password, zero privileges.
6. Alert at high severity on any 4769 naming the honeypot; treat it as a confirmed foothold.
7. Baseline distinct SPNs per account per window; alert on fan-out with a floor of five.
8. Escalate severity when fan-out coincides with RC4.
9. Allowlist scanners and agents by account and source host, never account alone.
10. Audit for accounts with DONT_REQ_PREAUTH (AS-REP roasting); the list should be empty.
11. Audit Event ID 5136 on servicePrincipalName changes for targeted Kerberoasting.
12. Inventory SPN accounts by privilege; least-privilege the over-scoped ones.
13. Set 25+ character generated passwords on every SPN account that cannot be a gMSA.
14. Migrate to gMSAs application by application; track it as a programme.
15. Document which application owns each SPN account and how to rotate its credential.

What should you fix before you detect?

Detection is the right investment once the attack surface is irreducible, and here a meaningful part of it is reducible first — which is cheaper than any rule.

Three preventive moves, in order of leverage. Audit which accounts actually need an SPN, because the attack requires one and service accounts accumulate them long after the service is decommissioned. Removing an unused SPN removes the target entirely. Move the accounts that must have one to managed service accounts, where the password is machine-generated, long, and rotated automatically — which makes an offline crack computationally uninteresting rather than merely slow. And where a managed account is not possible, enforce a genuinely long passphrase, since the entire economics of this attack rest on the ticket being crackable offline at leisure.

The framing worth carrying: this is one of the few Active Directory attacks where prevention is largely achievable, so detection should be the backstop for the residue, not the primary control. A detection rule watching a hundred crackable service accounts is defending a problem you could have deleted.

The takeaway

Kerberoasting is a clean example of darkpwn’s thesis: the same knowledge that describes an attack is what lets you defend against it. You cannot patch a design decision, but you can make it worthless (gMSA + AES + least privilege) and you can see it coming (behavioral 4769 detection, and a honeypot SPN that costs ten minutes and produces a verdict rather than an alert). Understand the attack; build the defense.

Once an attacker lands a credential, the fight moves to the host — see Linux privilege escalation: defensive lessons. The same Active Directory tradecraft continues with detecting LSASS credential dumping, detecting NTLM relay attacks, detecting AD CS abuse (ESC1–ESC8) and detecting DCSync attacks. For more identity- and telemetry-side defense, browse the Defensive Research and Detection Engineering pillars.