Kerberoasting: How Any Domain User Turns a Service Account Into an Offline Cracking Job

#Any Authenticated User Can Pull a Crackable Copy of Your Service Account Password#link

Tim Medin stood up at DerbyCon in 2014 and showed a packed room how to turn a completely normal Kerberos ticket request into a password-cracking job. A decade later, the technique — Kerberoasting — still shows up in incident response reports, mapped by MITRE as T1558.003, with a group list running from ransomware crews to state-nexus actors. The uncomfortable part isn't that it works. It's that nothing is broken. The protocol behaves exactly as RFC 4120 says it should, and the attack lands because of decisions most of us made years ago and never revisited: passwords set once at install time, service accounts stacked into privileged groups, and an encryption downgrade path left open for compatibility.

How a Legitimate Request Becomes an Oracle

Kerberos in an Active Directory domain works in two steps. First you prove who you are to the domain controller and get a ticket-granting ticket (TGT). Then, for every service you touch, you ask the KDC for a service ticket, naming the service by its SPN — something like MSSQLSvc/sql01.corp.local:1433. The KDC looks up which account owns that SPN, encrypts the ticket with a key derived from that account's password, and hands it over. You can't read it; the service can. That design is sound. The flaw in practice is that the KDC issues that encrypted ticket to any authenticated user who asks — no rights on the server required, no network access to the service required, and the service doesn't even have to be running. Once you have the blob, verification never happens, because you never intend to use the ticket. You take it offline and attack the password that produced it.

Step One Costs the Attacker Nothing: Build the Target List

Every account with an SPN registered is kerberoastable by definition, and finding them is a single LDAP query any domain user can run. Attackers sort the results by whatever signals privilege: adminCount=1, protected group membership, or SPNs that simply look important. The filter (servicePrincipalName=*)(adminCount=1) alone usually hands back the keys to the back door — service accounts someone, at some point, dropped into privileged groups. Defenders should run the exact same query first, because if you can't answer "which of my SPN'd accounts could a junior helpdesk tech roast right now?", that's the gap.

Look at the PasswordLastSet column before anything else — 2019, 2020, 2021. That's not an anomaly; it's the norm. Service account passwords get set during an installation window by whoever runs the installer, then never touched again, because nobody wants to find out which app breaks on rotation. The hash blob at the bottom is the payoff: with RC4-HMAC (etype 23), the Kerberos key is derived directly from the account's NT hash, so every guess tested against that ticket tests the same material an NTLM cracker would attack — no salt, no per-user stretching. RFC 3962's AES path changes that equation substantially, but as the warning below covers, most networks let attackers pick RC4 anyway.

Fourteen seconds. Now the real question: what does svc-backup own? This is where Kerberoasting stops being a password problem and becomes a privilege problem. In most domains I've reviewed, the kerberoastable list and the privileged-access list overlap far more than anyone would design on purpose — not because anyone decided a backup service account belongs in Domain Admins, but because SPNs get attached to whatever account the installer was using that day, and nobody audits the combination afterward. Crack one weak password, and the domain's own ticket service vouches for you everywhere that account can go.

What Actually Fixes It

gMSA (Group Managed Service Accounts) is the control that ends this attack class rather than slowing it down. The DC's KDS component generates a 240-byte random password, rotates it on a schedule (30 days by default), never exposes it to a human, and only releases it to the hosts you explicitly list in PrincipalsAllowedToRetrieveManagedPassword. There's nothing to crack in any practical sense — 240 random bytes isn't a password, it's a key. Windows handles the plumbing: services log on as CORP\svc-sql-prod$ (note the dollar sign) and never see the secret. Where the platform can't use a gMSA, a 25+ character random string in a vault is the fallback — long beats complex, always. And one cheap trick worth knowing: marking an account "Smart card is required for interactive logon" forces a random password nobody knows, making the NT hash effectively uncrackable — a stopgap for accounts that can't move to gMSA yet, though it breaks interactive logon by design.

Detection Worth Its Keep — and One Default That Betrays You

Event 4769 (Kerberos service ticket requested) is the core signal, and the first surprise is that most domains aren't logging it: the "Audit Kerberos Service Ticket Operations" subcategory is off by default on domain controllers, so enable it before assuming you're covered. Three signals earn their keep. Volume: one client address pulling dozens of distinct SPN tickets in minutes is a roast in progress. Encryption-type mismatch: 0x17 (RC4) requests in a domain where the accounts carry AES keys — that's the downgrade path being walked, and it's rarely legitimate in a modern estate. Canary SPNs: decoy accounts with SPNs no legitimate workflow would request; any 4769 against one is an automatic incident. Expect noise: legacy apps genuinely still request RC4 tickets, so allowlist known-legacy accounts before tuning by source host.

One more thing worth saying plainly: service accounts deserve their own password policy. Complexity rules that produce "memorable compliant" passwords — SeasonYear! and its thousand cousins — are exactly the patterns rule-based attacks encode first. Fine-grained password policies exist precisely so you can demand 25+ random characters for SPN'd accounts while leaving human passwords alone. Length is the whole game here: RC4 cracking is fast, but it's still linear in the keyspace, and a vault-generated 30-character string sits outside every realistic keyspace.

• ▪Run GetUserSPNs.py or Rubeus kerberoast /stats against your own domain this week with a read-only account and export the list — that's your real exposure inventory.
• ▪Check PasswordLastSet on every SPN'd account; treat anything older than a year as compromised pending rotation.
• ▪Migrate every kerberoastable account to gMSA where the platform supports it; vault-stored 25+ character randoms where it doesn't.
• ▪Enable "Audit Kerberos Service Ticket Operations" on all DCs and get 4769 into the SIEM.
• ▪Plant two or three canary SPNs and alert on any ticket request against them.
• ▪Start the RC4 deprecation sequence from Microsoft's KB5021131 guidance — on your schedule, not when a compatibility update forces it.