Kerberoasting: Cracking Service Accounts Offline

Kerberoasting is the attack that turns a single ordinary domain account into a path toward service account passwords, and it does so using a feature of Kerberos that is working exactly as designed. There is no exploit and no malware in the classic sense. An attacker with any valid domain login asks the domain controller for something it is meant to hand out, takes that response home, and grinds on it offline until a password falls out.

For defenders, the uncomfortable part is that the request looks legitimate because it is legitimate. The domain controller is doing its job. The defense is not about blocking the request, it is about making the thing the attacker receives worthless to crack, and about spotting the request pattern that betrays an attacker sweeping the domain.

A quick refresher on service tickets

In Kerberos, when a user wants to use a service, they ask the domain controller for a service ticket for that service. The service is identified by a service principal name, an SPN, which is registered against the account the service runs under. The domain controller issues a ticket and encrypts part of it with the password hash of that service account. The idea is that only the real service, which knows its own password, can decrypt and use the ticket.

That design has an unintended consequence. The encrypted portion of the ticket is a value derived directly from the service account's password. If an attacker can obtain the ticket, they hold an offline oracle for guessing that password. Guess a password, derive the key, try to decrypt, and check whether the result is valid. Repeat until it works.

Why any user can start the attack

The step that makes kerberoasting so accessible is that requesting a service ticket does not require permission to use the service. Any authenticated account in the domain can ask for a ticket for any SPN. Kerberos issues it. That is normal behaviour, because the ticket is useless without the service's password. Or it was supposed to be useless.

So the attack path is short. Enumerate the accounts that have an SPN, which is a normal directory query. Request service tickets for them. Extract the encrypted portions. Walk away and crack them offline. This whole sequence sits under MITRE ATT&CK T1558.003.

Why the offline crack is the whole point

The crucial property of kerberoasting is that the guessing happens offline. Once the attacker has the ticket, they never talk to the domain controller again. There is no stream of failed logons, no account lockout, no authentication traffic to alert on. The attacker can run millions or billions of guesses on their own hardware for as long as they like.

This changes the math on password strength completely. Account lockout policies, which protect against online guessing, do nothing here. The only thing standing between the attacker and the password is how expensive it is to guess, which comes down to two factors: how long and random the password is, and how strong the encryption on the ticket is.

The offline setting also removes any time pressure. An online attacker races the clock, because every failed guess risks lockout or detection. An offline attacker can pause, resume, buy more hardware, rent cloud capacity, or share the captured material with others who have better rigs. The ticket does not expire in any way that helps the defender, because the password behind it is what the attacker is really after, and that password is valid until someone rotates it. A ticket captured today can be cracked next month, or next year, against a password that never changed, which is why stale service accounts with fixed passwords are such a durable liability across the whole domain. The defender's only lever is the cost of a single guess multiplied by the number of guesses required, and both of those come back to password length, randomness, and encryption strength.

The related AS-REP roasting risk

Kerberoasting has a close relative worth handling in the same breath. Kerberos normally requires pre-authentication, where the client proves knowledge of its password before the domain controller returns anything crackable. Some accounts have pre-authentication disabled, often for compatibility with older systems. For those accounts, the domain controller will return a response encrypted with the account's password hash to anyone who asks, with no proof of identity required at all.

That response is crackable offline in the same way a service ticket is, and it is called AS-REP roasting. The exposure is any account flagged to not require Kerberos pre-authentication. Because the two attacks share both a root cause, an offline-crackable value tied to a password, and a fix, strong or managed passwords and tight account hygiene, a team hardening against kerberoasting should audit for pre-authentication-disabled accounts at the same time and remove the flag wherever it is not genuinely required.

Encryption type matters

Kerberos can encrypt tickets with different algorithms. Older RC4-based encryption derives its key in a way that is comparatively cheap to attack, so RC4 tickets crack faster. AES-based encryption is significantly more expensive to grind through. Attackers often request tickets specifically with weaker encryption when they can, precisely because it speeds up the offline crack.

For defenders this means the encryption an account supports is part of its exposure. An account that still permits RC4 hands the attacker an easier target than one restricted to AES.

How managed passwords end the attack

The clean way to defeat kerberoasting is to remove the crackable secret. If the service account's password is long and random enough, offline cracking becomes infeasible within any useful timeframe, no matter how many tickets the attacker collects.

Group managed service accounts do this automatically. Active Directory generates and rotates their passwords, using very long random values well beyond anything a human would choose, and it manages the rotation without an administrator ever handling the password. An attacker who kerberoasts a group managed service account walks away with a ticket they cannot crack, because there is no dictionary or realistic brute force that reaches a 120-plus character random password. Microsoft's group managed service accounts documentation covers how to move services onto them.

Where a managed account is not possible, the fallback is a manually set password that is long and random enough to be equivalent in practice, treated as a secret in a vault rather than something anyone types.

The difference between account choices maps directly to the attack's outcome:

Account type	Password	Kerberoast outcome
Legacy account, human-set password	Short or reused, rarely changed	Frequently cracked
Manually hardened account	Long random, stored in a vault	Impractical to crack
Group managed service account	120-plus character, auto-rotated	Not crackable in practice

The trend is clear. The further an account sits from a human-chosen password, the less a captured ticket is worth to an attacker.

How to detect and defend against kerberoasting

Because the request is legitimate, defense combines removing the crackable target with watching for the enumeration pattern.

Remove the target.

1. Move services to group managed service accounts wherever the service supports them. This is the strongest single control because it eliminates the crackable password.
2. For accounts that cannot be managed, set long random passwords, well beyond normal user length, stored in a secrets vault and rotated on a schedule.
3. Audit for unnecessary SPNs. Every SPN on a human-managed account is exposure. Remove SPNs that are no longer needed, and question SPNs on highly privileged accounts.

Raise the cost.

4. Force AES and retire RC4 for Kerberos where your environment allows, so any ticket an attacker does capture is more expensive to crack.
5. Reduce privilege on service accounts. An account with an SPN that is also a member of a high-privilege group is a priority to fix, so that even a successful crack yields limited access.

Detect the pattern.

6. Alert on a single account requesting many service tickets in a short window, especially across accounts it has no relationship with. Service ticket requests are logged, and a normal user needs tickets only for services they actually use. A sweep across dozens of SPNs is the roasting signature.
7. Flag tickets requested with weak encryption. A request that specifically asks for RC4 when the account supports AES is a strong indicator of an attacker optimising for a faster crack.
8. Baseline normal ticket volume per account so the anomaly stands out. The attacker looks like one identity suddenly interested in every service in the domain.

A worked walkthrough of a roast

It helps to follow the attack as a sequence, because each step is mundane on its own and only the whole chain reveals the intent.

The starting position is any authenticated domain account. That can be a low-privilege user whose password was phished, a service account whose credential leaked into a script, or a machine account. Nothing about this foothold needs administrative rights. Kerberoasting is one of the few high-value Active Directory techniques that begins from the bottom of the privilege ladder.

The first step is enumeration. The attacker queries the directory for accounts that carry a service principal name. This is an ordinary LDAP read that any domain member can perform, because SPN data is not secret. The query returns a list of accounts, and the attacker notes which of them are user accounts rather than computer accounts. Computer accounts also have SPNs, but their passwords are machine-generated and long, so they are a poor target. User accounts with SPNs are the prize, because a human likely set their password.

The second step is requesting service tickets. For each interesting SPN, the attacker asks the domain controller for a service ticket, exactly as any client would before contacting that service. The domain controller has no basis to refuse, because requesting a ticket is a normal precursor to using a service. It returns a ticket whose encrypted portion is derived from the target account's password.

The third step is extraction. The attacker pulls the encrypted portion of each ticket out of memory or off the wire and writes it to a file in a format a cracking tool understands. At this point the attacker has everything they need and can disconnect. No further contact with the domain is required.

The fourth step is the offline crack. On separate hardware, often a machine with strong graphics processors, the attacker runs a wordlist or a brute-force campaign against the captured material. Each candidate password is turned into a key, the key is tried against the ticket, and a successful decryption reveals that the guess was correct. Weak passwords fall in seconds. A long random password never falls at all.

The fifth step is use. A cracked service account password is a real credential. The attacker logs in as that account, and because service accounts frequently hold elevated rights, the reward is often a jump in privilege rather than a lateral step sideways. The roast that started from an ordinary user can end at an account with rights over databases, file shares, or the domain itself.

How kerberoasting evolved

The mechanics of service tickets have existed as long as Kerberos itself. What changed was the public understanding of how to abuse them. The realisation that any domain user could request tickets for any SPN, extract the encrypted material, and crack it offline was popularised by the security research community, and tooling quickly made the whole sequence a single command. Once the technique moved from theory into standard toolkits, it became part of the baseline playbook for anyone operating inside a Windows domain.

The defensive story evolved in parallel. Group managed service accounts gave administrators a way to remove the crackable secret entirely by handing password management to Active Directory. Guidance to retire RC4 in favour of AES raised the cost of cracking any ticket that was captured. Detection matured from nothing toward baselining ticket requests per account and flagging anomalies. The attack itself did not change, because there is no flaw to fix. The environment around it hardened.

Kerberoasting next to related Kerberos attacks

Kerberoasting is one of a family of Kerberos abuses, and confusing them leads to the wrong defense. This table places it against its neighbours.

Technique	Starting requirement	What it targets	Core defense
Kerberoasting	Any domain user	Service account password via its SPN ticket	Managed or long passwords, AES
AS-REP roasting	Any domain user	Password of accounts with pre-auth disabled	Require pre-authentication, strong passwords
Pass the ticket	A stolen ticket	Reuse of an existing ticket	Protect tickets, limit privilege
Golden ticket	The krbtgt hash	Forged tickets for any account	Protect and rotate krbtgt
Overpass the hash	A stolen NTLM hash	A Kerberos ticket derived from the hash	Protect the hash, tier admin access

The pattern to notice is that kerberoasting and AS-REP roasting both produce an offline-crackable value tied to a password, so both are defeated by strong or managed passwords. The ticket-forging attacks lower down the table depend on already holding powerful secrets, so their defenses centre on protecting those secrets rather than on password strength.

Common mistakes defenders make

The first mistake is trusting password policy. A complexity requirement that satisfies an auditor does nothing against an offline crack if the resulting password is still within reach of a wordlist. Service account passwords need to be long and random, well beyond the length a policy typically enforces for humans.

The second mistake is leaving SPNs on accounts that no longer run a service. An SPN is exposure whether or not the service still exists. Stale SPNs on forgotten accounts are frequently the ones with the oldest, weakest passwords, which makes them the easiest roast in the domain.

The third mistake is ignoring privilege on service accounts. An SPN account that also sits in a high-privilege group is the worst case, because a successful crack yields both a valid credential and elevated rights. Reducing the privilege of service accounts limits the damage even when a password does fall.

The fourth mistake is assuming AES alone solves the problem. Forcing AES raises the cost of cracking, and that is worth doing, yet a short AES-protected password can still be brute-forced. Encryption strength buys time. Password length and randomness are what actually make the crack infeasible.

The fifth mistake is treating detection as sufficient. Alerting on ticket sweeps is valuable, and it catches noisy attackers. A patient attacker who requests a handful of tickets slowly can stay under the threshold, which is why removing the crackable target matters more than watching for the request pattern.

Frequently asked questions

Does kerberoasting require administrative access?

No. Any authenticated domain account can request service tickets for any SPN, which is what makes the technique so accessible. The attacker needs only an ordinary foothold to begin, and the reward can be a privileged credential.

Can I patch kerberoasting?

There is no patch, because the attack abuses a supported Kerberos feature working as designed. The domain controller is meant to issue service tickets to authenticated users. The defense is to make the issued ticket worthless to crack and to watch for the request pattern that betrays a sweep.

Will forcing AES stop the attack?

Forcing AES and retiring RC4 raises the cost of cracking a captured ticket, and it is a control worth applying. It does not by itself make a weak password safe. A short password protected by AES can still be brute-forced. Long random or managed passwords are the durable answer.

Why do group managed service accounts defeat it?

They remove the crackable secret. Active Directory generates and rotates a password well over a hundred characters long and manages it without a human ever choosing or typing it. An attacker who roasts such an account captures a ticket they cannot crack, because no realistic wordlist or brute force reaches a password of that length and randomness.

How would I know kerberoasting is happening?

The clearest signal is a single account requesting service tickets for many different SPNs in a short window, especially services it has no reason to use. Requests that specifically ask for weaker encryption when the account supports stronger are another indicator. A honey SPN account, one that no real service uses, turns any ticket request against it into a near-certain sign of roasting.

Is AS-REP roasting the same thing?

They are close relatives with the same root cause and the same fix, so audit for both together. Kerberoasting targets service accounts through their SPN tickets. AS-REP roasting targets accounts that have Kerberos pre-authentication disabled, and it needs no service ticket at all. Both hand the attacker an offline-crackable value tied to a password.

Do computer accounts get roasted?

Computer accounts carry SPNs, so they appear in enumeration, yet their passwords are machine-generated, long, and rotated automatically. That makes them a poor target. Attackers focus on user accounts with SPNs, because those are the ones a human is likely to have given a weak password.

Kerberoasting is a favourite of intrusion sets working inside Active Directory precisely because it needs so little to begin and leaves so little behind. You can see which actors lean on Kerberos abuse and credential access in our Threat Groups directory, which helps prioritise whether managed accounts or detection tuning is your more urgent gap.

The attack exploits a genuine Kerberos feature, so you will not patch it away. What you can do is make the prize worthless and the hunt visible: retire crackable service passwords in favour of managed accounts, force strong ticket encryption, and alert on the account that suddenly wants a ticket for everything. Do that and kerberoasting collects a pile of tickets that never turn into a password.

Related guides

• How Kerberos Works
• Pass the Ticket Explained
• Golden Ticket Attack Explained
• Active Directory Security Basics