Anatomy of a Kerberoasting Attack — and How to Detect It

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 and harden against it. This post walks the technique conceptually, then closes the loop with detection and prevention.

How the technique works

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.

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 juicy 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.

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.

Detection

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 high-fidelity indicators:

• Ticket encryption type 0x17 (RC4) in an otherwise AES environment.
• A single account requesting tickets for many distinct SPNs in a short window.
• Requests for SPNs the requesting account has no business using.

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
  filter_machine:
    ServiceName|endswith: '$'       # ignore machine accounts
  filter_known:
    TicketOptions: '0x40810000'     # tune to your environment
  condition: selection and not filter_machine
falsepositives:
  - Legacy services that genuinely require RC4
  - Some backup and monitoring agents
level: medium

Prevention and hardening

• 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.

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). Understand the attack; build the defense.

For more identity- and telemetry-side defense, browse the Defensive Research and Detection Engineering pillars.