Kerberoasting: Attacking Service Accounts in Active Directory

• 4 min read

Kerberoasting is a powerful Active Directory attack technique that allows attackers to extract and crack service account credentials offline. In this post, we break down how Kerberoasting works, why it’s dangerous, and how to detect and mitigate it.

Idea

In Kerberos, when a user wants to access a service (like MSSQL, HTTP, CIFS), the Domain Controller (KDC) issues a TGS (service ticket) for that service. The ticket is encrypted using the service account’s secret (derived from its password). Attackers abuse this by requesting TGS tickets for any SPN they can see, then cracking the encrypted portion offline—no lockouts, no noisy login failures.

Why it works (and why it’s so common)

Kerberoasting succeeds because: - SPNs are discoverable to authenticated users in many environments. - Service accounts often have long-lived passwords that rarely change. - Service accounts are frequently over-privileged (local admin on servers, delegated rights, or even DA by accident). - Offline cracking means defenders don’t see a “password spray” pattern—just normal-looking ticket requests.

Prerequisites

Attackers usually need: - A foothold as a domain user (even low privilege). - Network reachability to the DC (to request TGS). - Visibility of SPNs (often via LDAP queries).

No admin rights required.

High-level attack flow

  1. Enumerate SPNs
  2. Request TGS tickets for selected SPNs
  3. Extract ticket hashes into crackable format
  4. Offline crack with a wordlist / rules / GPU
  5. Use recovered creds (pass-the-password) to pivot or escalate

Quick glossary (so you don’t get lost)

  • KDC: Key Distribution Center, usually the DC.
  • TGT: Ticket Granting Ticket (logon ticket).
  • TGS: Service ticket issued to access a service (the one we roast).
  • SPN: Service Principal Name, maps a service to an account (often a service account).

What defenders should look for

Kerberoasting leaves fewer “loud” traces than brute force, but it does generate patterns.

1) Windows Security Event ID 4769 (TGS Request)

This is the core signal. Watch for: - Spikes in 4769 from a single user or workstation - Requests for many different SPNs in a short time - Unusual service names or services not typically accessed by that user - Encryption type clues (legacy types are more crackable)

Practical heuristic:

“One user requests TGS for 20+ distinct SPNs within 5–10 minutes.”

2) Unusual LDAP / AD enumeration patterns

If you have LDAP query auditing (or EDR telemetry), SPN enumeration often shows up as: - Queries for servicePrincipalName=* - Enumeration from non-admin user contexts

3) Service account logon behavior after cracking

After a successful roast: - Service account starts logging in interactively or from new hosts - Lateral movement patterns (WMI, SMB, WinRM, PsExec-style artifacts)

Defensive strategy (what actually moves the needle)

1) Strong service account passwords (the #1 fix)

Kerberoasting is mostly an offline cracking problem. - Use long, random passwords (e.g., 25–30+ chars) for service accounts - Rotate regularly (or automate rotation)

2) Prefer gMSA where possible

Group Managed Service Accounts (gMSA) rotate automatically and are harder to “roast into usefulness” because you don’t manage a human-chosen password.

3) Reduce service account privilege

Even if cracked, the blast radius should be limited: - Remove local admin where unnecessary - Avoid Domain Admin memberships (yes, people still do this) - Apply least privilege + delegated rights carefully

4) Kerberos hardening: remove legacy where you can

If older encryption types are enabled/used, cracking becomes easier in practice. - Audit and phase out weak/legacy crypto settings - Modernize service configurations that still rely on older auth behavior

5) Detection engineering: alert on patterns, not single events

A single 4769 is normal. A burst of unusual 4769s is not. - Baseline normal TGS volumes per user/machine - Alert on high-cardinality SPN requests from a single principal

Example: simple detection logic (pseudocode)

  • If count_distinct(ServiceName) by AccountName over 10 minutes > N
  • and the workstation is not a known admin jump box
  • then alert: Possible Kerberoasting

Common misconceptions

“Kerberoasting needs admin rights”

Nope. Any domain user can request TGS for SPNs they can discover.

“If I disable pre-auth, it stops Kerberoasting”

That’s a different attack class (AS-REP roasting). Kerberoasting targets service tickets.

“Account lockout policies stop it”

Offline cracking doesn’t trigger lockouts.

Practical checklist

  • Inventory all accounts with SPNs
  • Move eligible services to gMSA
  • Enforce long random passwords for remaining service accounts
  • Rotate service account secrets on a schedule
  • Monitor 4769 for high-volume / high-cardinality TGS requests
  • Review and reduce service account privileges

Final thoughts

Kerberoasting isn’t “new”—it’s just consistently effective because many domains still run services on human-managed accounts with predictable passwords. If you fix service account password hygiene and watch for TGS request anomalies, you cut the legs out from under this technique.