Kerberoasting

Kerberoasting is an attack against Active Directory in which any authenticated domain user requests a Kerberos service ticket for an account that carries a Service Principal Name (SPN), then cracks that ticket offline to recover the service account’s password. It needs no elevated privileges and no exploit — a single valid domain login is enough — which is exactly why it turns up on almost every internal Active Directory assessment. The tickets come from the KDC over Kerberos on port 88, and the accounts most worth roasting are the high-privilege service accounts behind SQL Server, IIS, and scheduled tasks.

Why It Happens

Kerberoasting isn’t a bug; it’s Kerberos working as designed. Any authenticated principal is allowed to request a service ticket (TGS) for any SPN, and that ticket is encrypted with the target service account’s password hash so the service can validate it. The weakness is human: service accounts get created once, handed a memorable password, granted broad rights “to make the app work,” and then never rotated for years. Add legacy RC4 encryption — still enabled in many domains for compatibility — and the ticket becomes fast to crack offline. Because the whole attack is a normal ticket request followed by offline cracking, nothing else hits the domain controller, so there are no failed logons and no lockouts to trip an alert.

Common Techniques

• SPN discovery. An attacker — or an auditor — enumerates every account with an SPN through a single LDAP query, no special rights required, to build the target list.
• Ticket extraction. A TGS is requested for each SPN and pulled from the KDC response, ready to crack offline at leisure.
• RC4 downgrade roasting. Where AES isn’t enforced, tickets are requested with RC4 (etype 0x17), which cracks orders of magnitude faster than AES.
• Targeted roasting. Rather than roast everything, an attacker cherry-picks accounts that are both crackable and privileged — a sysadmin SQL service account is the jackpot.
• AS-REP roasting (sibling). Accounts with Kerberos pre-authentication disabled leak a crackable blob without even needing a domain login — a close cousin worth checking in the same sweep.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Detection & Testing

Audit which accounts are roastable

Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName,PasswordLastSet

Any enabled account with an SPN is a candidate — pay special attention to ones that are highly privileged or whose password hasn’t changed in years.

Alert on the ticket requests (Event ID 4769)

Windows Security log → Event ID 4769 (Kerberos service ticket requested)
  Ticket Encryption Type = 0x17 (RC4)          ← suspicious
  One account requesting many distinct SPNs    ← roasting in progress

Hunt with a detection query

-- Splunk-style: many 4769s, RC4, from a single requestor
EventCode=4769 Ticket_Encryption_Type=0x17
| stats dc(Service_Name) AS spns by Account_Name
| where spns > 10

Plant a honeypot SPN

Create an unused account, give it an SPN, and never authenticate with it. Any 4769 for that account is a near-zero-false-positive alarm.

Log every roastable account you find and its time-to-crack under test, so the evidence lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Notable Incidents

Kerberoasting was introduced by researcher Tim Medin at DerbyCon 2014 and has since become a staple of both criminal and state-sponsored playbooks. Microsoft and CISA have repeatedly flagged it in advisories on human-operated ransomware, where operators behind families like Ryuk and Conti used it to escalate from a single phished workstation to domain-wide control before deploying their payload. MITRE ATT&CK catalogs the technique as T1558.003, and it stays effective for one simple reason: most domains still run service accounts with weak, un-rotated passwords.

Mitigation

• Use managed passwords. Move service accounts to Group Managed Service Accounts (gMSA) or give them 25+ character random passwords, which makes offline cracking infeasible.
• Enforce AES, retire RC4. Require AES for Kerberos and disable RC4 wherever compatibility allows, removing the fast-crack path.
• Least privilege. A service account should never sit in Domain Admins — scope its rights to exactly what the app needs so a crack isn’t catastrophic.
• Rotate and audit. Rotate service-account passwords on a schedule and periodically enumerate SPNs to remove stale or unnecessary ones.
• Monitor 4769. Alert on RC4 ticket requests and bulk-SPN requests, and keep a honeypot SPN for early warning.

FAQ

What is Kerberoasting?

It’s an Active Directory attack where any authenticated user requests a Kerberos service ticket for an account with a Service Principal Name, then cracks that ticket offline to recover the account’s password — no admin rights or exploit needed.

Is Kerberoasting still a threat?

Yes. As long as domains run service accounts with weak, long-lived passwords and allow RC4 encryption, it works. It’s common in ransomware intrusions and tracked as MITRE ATT&CK T1558.003.

How do I detect Kerberoasting?

Watch Windows Event ID 4769 for service-ticket requests using RC4 encryption and for a single account requesting many SPNs in a short window. A honeypot service account with an SPN gives a high-confidence alert.

How do I prevent Kerberoasting?

Use gMSA or 25+ character passwords for SPN accounts, enforce AES and disable RC4, keep service accounts out of privileged groups, and rotate their passwords regularly.

TL;DR

• Attack: offline cracking of Kerberos service tickets to recover service-account passwords
• Needs: one authenticated domain user — no admin, no exploit
• Biggest risk: weak, un-rotated, over-privileged service accounts (worse with RC4)
• Detect: Event ID 4769 with RC4 or bulk SPN requests; honeypot SPN
• Fix: gMSA or long random passwords, enforce AES, least privilege, rotate SPNs