Kerberoasting in 2025: Why It Still Works and How to Stop It

Kerberoasting was publicly documented by Tim Medin at DerbyCon in 2014. That's over a decade ago. Yet in 2025, it remains one of the first techniques we execute in nearly every internal penetration test and red team engagement — and it consistently produces exploitable results.

How Kerberoasting Works

When a domain user requests access to a service registered with a Service Principal Name (SPN), the domain controller returns a Ticket Granting Service (TGS) ticket encrypted with the service account's NTLM hash. Any authenticated domain user can request this ticket for any SPN. No special privileges required.

The ticket is encrypted with the service account's password hash. An attacker captures the ticket and cracks it offline at full GPU speed — no domain interaction required, no lockout risk.

# Enumerate all SPNs in the domain
python3 GetUserSPNs.py DOMAIN/user:password -dc-ip 10.10.10.1

# Request tickets and output hashes
python3 GetUserSPNs.py DOMAIN/user:password -dc-ip 10.10.10.1 -request -outputfile hashes.txt

# Crack offline with hashcat
hashcat -m 13100 hashes.txt rockyou.txt --rules-file best64.rule

Why It Still Works in 2025

The attack hasn't changed. What also hasn't changed is how organisations manage service accounts:

• Weak passwords on service accounts — set once during application deployment, never rotated
• Over-privileged service accounts — accounts with Domain Admin membership because it was "easier"
• No monitoring of TGS requests — Event ID 4769 is generated but most SIEMs don't alert on high-volume requests
• Legacy application constraints — teams say changing passwords will "break something"

Real-World Example

In a recent financial sector assessment, we enumerated 23 SPNs within two minutes of gaining a low-privilege foothold. Six had passwords that cracked within 30 minutes. Two accounts were Domain Admins. Total time from initial access to domain compromise: under two hours. The organisation had a mature security programme, deployed EDR, and a 24/7 SOC. None of these controls detected the attack.

What Actually Stops It

1. Group Managed Service Accounts (gMSAs)

gMSAs use 120-character random passwords rotated automatically by the domain. Computationally infeasible to crack. If your application supports them, this is the most effective control available.

2. Long, Random Passwords

If gMSAs aren't feasible, generate a 30+ character random password for every service account. Store it in a PAM solution. At that length, wordlist-based attacks become impractical.

3. Targeted SIEM Detection

Alert on Event ID 4769 with encryption type 0x17 (RC4-HMAC). Modern environments should request AES tickets — RC4 requests are a strong signal of Kerberoasting. Alert on more than five such requests from a single source in a short window.