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

Run these commands only in an owned lab or a sanctioned assessment with written scope. Replace the placeholders with lab values; do not point broad authentication tests at production ranges without explicit approval.

Terminal window
# 1. Enumerate SPNs (Service Principal Names)
impacket-GetUserSPNs -request -dc-ip <DC_IP> <LAB_DOMAIN>/<USER>:<PASSWORD>


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


# 3. Verify only against in-scope lab hosts
crackmapexec smb <LAB_SUBNET> -u '<SERVICE_ACCOUNT>' -p '<RECOVERED_PASSWORD>'

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'
  filter_machine_spn:
    ServiceName|endswith: '$'
  filter_machine_requestor:
    AccountName|endswith: '$'
  condition: selection and not 1 of filter_*
falsepositives:
  - Legacy systems requiring RC4
  - User-backed service accounts that have not migrated to AES or gMSA
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.

Kerberoasting rarely operates in isolation. Once a service account is cracked, attackers typically chain to LSASS dumping for local credentials and ADCS abuse for certificate-based privilege escalation — often using LOLBins for lateral movement throughout. In hybrid environments, on-premises credential access is usually a stepping stone toward Entra ID and cloud resources.

Sources