Kerberoasting, explained for defenders

Kerberoasting is one of the most dependable techniques in internal testing: from any ordinary domain account, with no special privileges, an attacker can walk away with crackable credentials for service accounts — and service accounts are often powerful. Understanding why it works is the first step to making it stop.

The mechanism

In Active Directory, any service that runs under a domain account can register a Service Principal Name (SPN). Kerberos lets any authenticated user request a service ticket for any SPN — that's by design, it's how clients reach services. The catch: part of that ticket is encrypted with a key derived from the service account's password. So an attacker requests tickets for every SPN in the domain, takes them offline, and cracks them at leisure. Nothing is logged as suspicious; requesting tickets is normal activity.

Why it's so effective

• No privileges required. One foothold account is enough to roast the whole domain.
• Offline cracking. There's no lockout and no network noise — the attacker cracks on their own hardware.
• Service accounts are old and over-privileged. Their passwords are frequently set once, years ago, never rotated, and the account is often a member of a powerful group. On real engagements we've found domain-admin service accounts whose passwords hadn't changed in over a decade.

How to make Kerberoasting fail

• Long, random passwords. A 25+ character random password is effectively uncrackable offline. For service accounts, use group-managed service accounts (gMSAs), which handle this automatically.
• Least privilege. A roasted service account should not be a domain admin. Remove service accounts from privileged groups.
• Strong encryption. Ensure accounts don't fall back to RC4 for tickets; require AES.
• Hunt the pattern. A single account requesting service tickets for many SPNs in a short window is a strong signal — watch for it.

Kerberoasting is a password-strength problem wearing a protocol costume. Fix the passwords — ideally by removing humans from the loop with gMSAs — and the technique quietly stops paying off.

AS-REP roasting, the quieter cousin

Kerberoasting needs a foothold account to request tickets. AS-REP roasting needs even less. Any account with Kerberos pre-authentication disabled can have crackable material requested for it without any authentication at all — a fully unauthenticated attacker on the network can collect it. We routinely find dozens of such accounts, usually legacy or service identities where someone turned pre-auth off years ago to fix a compatibility problem and never turned it back on. Require pre-authentication on every account, and hunt for the few that have it disabled.

Detecting the roast

Kerberoasting is quiet by design, so you have to look for it deliberately. The signals are specific: one account requesting service tickets for many different SPNs in a short window, or tickets requested with weak RC4 encryption. Alert on both. You won’t get a lockout or a failed-logon spike to tip you off — the request itself is legitimate — so the detection has to be built, not assumed.

How SPNs are discovered, and why the lookup looks ordinary

Every domain-joined account that runs a service advertises a Service Principal Name so that clients can locate the right ticket to request. Those names live in a directory attribute that any authenticated account is permitted to read. That permission is not a misconfiguration; it is how Kerberos is designed to work. A workstation needs to resolve the SPN for a database or web service before it can authenticate to it, so the directory must answer SPN queries for ordinary users all day long.

The uncomfortable consequence for defenders is that enumerating accounts with SPNs is almost indistinguishable from legitimate directory browsing. A single query that returns every user account carrying an SPN produces exactly the shortlist an attacker wants: the human-owned service accounts whose passwords are most likely to be weak and static. Because the read is authorised and unremarkable, the enumeration step rarely generates a useful alert on its own. The signal worth chasing is not the lookup but what follows it.

RC4 versus AES tickets, and the economics of cracking

The encryption type of a service ticket decides how expensive the offline attack is. Legacy RC4 tickets are derived from an unsalted NT hash of the account password, so a cracking rig can test enormous numbers of candidate passwords per second against them. AES tickets use a salted, iterated key derivation that is deliberately slower to compute, cutting the attacker's guessing rate by orders of magnitude. The password has not changed; only the cost of each guess has.

This is why attackers will try to obtain RC4 tickets even in an environment that supports AES. A client can signal which encryption types it is willing to accept, and if the account and domain still permit RC4, the KDC may issue the weaker ticket. Downgrading the ticket to RC4 turns a password that would survive AES cracking into one that may fall in hours.

Managed service accounts: gMSA and dMSA in depth

The structural fix for the roastable human service account is to stop a human from knowing the password at all. A group-managed service account (gMSA) has its password generated and rotated automatically by the domain, typically on a short cycle, using a key that is long, random and never typed. A ticket for a gMSA is still encrypted with the account's key, so a ticket can still be requested — but the password behind it is not a word a human chose, so offline cracking is no longer economic. Access to the password is itself restricted to the specific hosts authorised to retrieve it.

Newer delegated managed service accounts (dMSA) extend the idea by allowing a legacy standard account to be migrated into a managed, machine-bound identity, letting defenders retire long-lived static credentials without rebuilding every service. The defensive goal is the same in both cases: shift service identities to passwords no attacker can meaningfully guess and no administrator can leak.

Delegation exposure and honeypot SPNs

SPNs matter even more when they sit on an account trusted for delegation. Cracking a service account that can impersonate other users onward turns a single offline win into broad reach, so delegation-trusted accounts are the highest-value roasting targets and warrant the strongest passwords and the tightest scoping.

Defenders can also turn the mechanism around. A honeypot SPN is a decoy account that carries a service name but runs no service and is used by nobody. No legitimate client has any reason to request its ticket, so a service-ticket request for that account is almost certainly reconnaissance. It is a rare detection that produces a clean, high-confidence signal with very little noise.