What is Kerberoasting?

Definition

Kerberoasting is an Active Directory attack technique in which an attacker with any authenticated domain user account requests Kerberos service tickets (TGS) for accounts that have a Service Principal Name (SPN) registered, then cracks those tickets offline to recover the service account's password.

It is MITRE ATT&CK T1558.003.

In simple terms:

Any user can ask for a ticket. Any ticket can be cracked offline. Weak service account passwords become Domain Admin.

---

Why Kerberoasting Matters

• Requires only standard domain user privileges to start.
• No alerts in default configurations.
• Service account passwords are often old, weak, and rarely rotated.
• Service accounts are frequently over-privileged — many are Domain Admin.
• Cracking is offline — no rate limits, no lockouts, just GPU horsepower.

Kerberoasting has been a top finding in penetration tests and red team engagements for over a decade and remains highly effective.

---

How Kerberoasting Works

1. Discover SPN-Enabled Accounts

Any authenticated user can query LDAP for accounts with SPNs:

(&(objectCategory=user)(servicePrincipalName=*))

2. Request Service Tickets

Using Rubeus, Impacket, or built-in setspn/PowerShell, request TGS for each SPN. The KDC returns service tickets encrypted with the service account's NTLM/AES key derived from its password.

3. Extract Tickets

Tools save tickets in a format suitable for cracking (e.g., $krb5tgs$23$*...$*).

4. Offline Cracking

Run Hashcat / John the Ripper on the tickets:

• RC4-HMAC tickets crack fast.
• AES tickets are slower but still vulnerable to weak passwords.

Modern GPUs crack 8-character RC4 service tickets in hours; longer or AES tickets need stronger passwords.

5. Use the Recovered Password

Authenticate as the service account. If the account is Domain Admin (very common), it's game over.

---

Why It's So Effective

• Service accounts often have:
  • Passwords set 5+ years ago and never rotated.
  • No password policy enforcement.
  • Membership in privileged groups for "convenience."
  • Documentation in wikis, scripts, and config files.
• RC4-HMAC tickets are still issued in many environments.
• No native preventive control prevents requesting tickets.

---

Real-World Examples

1. SQL Service Account in Domain Admins

An attacker with a low-privilege account requests TGS for MSSQLSvc/sql01.corp.local. The service account's password (set in 2017) cracks overnight on a single RTX 4090. The account is in Domain Admins. Result: full domain compromise.

2. IIS Service Account

A web service runs under a domain account with a weak 10-character password. Kerberoasting recovers it. The account has access to several internal databases, leading to data exfiltration.

3. Backup Service

A backup product's service account has rights across the entire infrastructure (read all files, restore anywhere). Kerberoasting + cracking gives the attacker effective full-environment access.

4. Penetration Test

In nearly every penetration test of a Windows enterprise, Kerberoasting yields at least one cracked service account; in most, it leads to Domain Admin.

---

Defense Against Kerberoasting

Strong Service Account Passwords

1. Minimum 25-character random passwords for service accounts.
2. Use group Managed Service Accounts (gMSA) — passwords are 240 random bytes, rotated automatically.
3. Audit service accounts for weak/old passwords (look at pwdLastSet).

Right-Size Privileges

4. Remove service accounts from privileged groups. No service account in Domain Admins.
5. Apply least privilege to service accounts.

Cryptography

6. Disable RC4 Kerberos encryption types where possible. Force AES.
7. Set msDS-SupportedEncryptionTypes to AES on accounts and trusts.

Detection

8. Detect anomalous TGS requests — Event ID 4769 with RC4 from non-server hosts.
9. Detect mass TGS requests for many SPNs from a single account.
10. Honeypot SPN accounts — create fake SPN-enabled accounts; any TGS request for them is a high-fidelity alert.
11. Use ITDR products that ship Kerberoasting detections.

Account Hygiene

12. Inventory all SPN-enabled accounts and their owners.
13. Decommission unused service accounts.
14. Enable PreAuth and disable any that have it disabled.
15. Move sensitive service accounts to Protected Users group (note: prevents RC4 use).

---

Kerberoasting Defense Checklist

• All service accounts using gMSA where supported?
• Static service account passwords ≥ 25 characters and random?
• Service accounts removed from Domain Admins / privileged groups?
• RC4 disabled / AES enforced where possible?
• msDS-SupportedEncryptionTypes set explicitly?
• Honeypot SPN accounts in place?
• Kerberoasting detections live (4769 anomalies)?
• Unused SPN-enabled accounts decommissioned?
• SPN inventory documented and reviewed?

---

How Forestall Helps

Forestall identifies Kerberoasting risk continuously:

• Lists every SPN-enabled account, age of password, and group memberships.
• Highlights service accounts in privileged groups.
• Surfaces accounts still using RC4-eligible configurations.
• Maps attack paths from cracked service account → Tier 0.
• Tracks remediation progress (e.g., gMSA migrations).

---

Frequently Asked Questions

Can I prevent Kerberoasting entirely?

You can't prevent ticket requests (it's normal Kerberos behavior), but you can make tickets useless to crack — strong passwords (gMSA), AES, no privileged service accounts.

Is AES Kerberoasting-proof?

Not entirely — weak passwords still crack. AES makes cracking 10–100x harder, which combined with a 25+ char password is effectively secure.

What if my legacy app needs RC4?

Isolate it, monitor closely, and plan replacement. Don't allow RC4 forest-wide for one app.

Does the Protected Users group help?

Yes — members can't use RC4. But test carefully; some legacy interactions break.

Should I be Kerberoasting myself regularly?

Yes — periodic internal Kerberoast exercises (with permission) prove your password and gMSA strategy is working.

---

Conclusion

Kerberoasting turns weak service account passwords into Domain Admin in days. It thrives on three problems: standing privilege for service accounts, weak/old passwords, and lack of detection. The solution is equally direct: gMSA wherever possible, long random passwords elsewhere, no service account in privileged groups, AES-only where you can, and detections that catch ticket-request anomalies. Eliminating Kerberoasting closes one of the most reliable paths attackers use to escalate from "any user" to "every user."