Kerberoasting: Cracking Service Passwords Offline

Kerberoasting turns an ordinary domain user account into a credential harvesting operation. There is no exploit, no malware, and no privilege escalation required. The attacker asks Active Directory for something it is designed to hand out, walks away with it, and breaks it open at their leisure on hardware the organisation will never see.

That combination of low prerequisites and high reward is why the technique appears constantly in real incidents, and it makes a wider point worth carrying into any scenario: a system behaving exactly as designed can still be the vulnerability.

This is the final article in the Kerberos attack chain series. It builds on the Kerberos authentication guide, because Kerberoasting abuses steps 3 and 4 rather than breaking them.

What is Kerberoasting?

Kerberoasting exploits the ordinary service ticket exchange. An authenticated domain user sends a TGS-REQ asking for a ticket to a service account that has a Service Principal Name. The Ticket Granting Server responds with a service ticket encrypted using that account’s password derived key. The attacker extracts the encrypted portion and attacks it offline until the password falls out.

Nothing here is broken. The ticket is encrypted with the service’s key because only the service should be able to read it, and the TGS has no way of knowing the requester will never actually connect.

Key concept: the locked box

Kerberoasting is like asking a warehouse for a locked box you know holds something valuable, receiving it without argument because you were entitled to ask, then driving it home and spending a week on the lock. The service ticket is the box, the service account password is the combination, and the warehouse never finds out whether you opened it.

Why Kerberoasting works so well

Three properties compound.

First, the attack requires no privileges. Any domain user can enumerate SPNs and request tickets, so the attack surface is every account in the directory, including the one belonging to whoever just clicked a phishing link.

Second, the expensive part happens offline. Once the ticket is in hand the attacker is off the network, and no monitoring inside the environment observes the cracking because it is not happening there.

Third, service accounts are unusually good targets. They frequently hold elevated privileges because that was easier than working out the minimum required, and their passwords are frequently weak, ancient, and exempt from rotation because changing them breaks an application nobody wants to touch.

Unlike forgery attacks such as Golden Tickets, Kerberoasting produces perfectly ordinary Kerberos traffic. The danger arrives after the password is recovered: the attacker authenticates as the service account directly, with no forged artefact anywhere and no further alerts.

CISSP Exam Note

Kerberoasting needs only standard domain user privileges. This is the crucial distinction from Golden Ticket attacks, which require domain admin. Exam questions frequently present several Kerberos attacks and ask which one an attacker could perform with the access described. Read the stated privilege level first: it usually decides the answer on its own.

Prerequisites and attack requirements

The prerequisites are thin. The attacker needs authenticated domain access, typically from phishing or password spraying, and network reachability to a domain controller. From there they identify service accounts worth targeting, such as SQL databases, web applications, and file shares, and request tickets with standard tooling.

Technical note

No elevated privileges are required at any stage, which makes this an attractive early move for gaining additional credentials rather than a late stage technique. Note also which accounts are worth roasting: computer accounts and Group Managed Service Accounts carry machine generated random passwords that will not crack, so attackers concentrate on ordinary user accounts that have been given an SPN. Those are the ones with human chosen passwords.

How Kerberoasting attacks work

The attack runs in four steps, turning routine ticket requests into credential theft.

Step 1: Service account enumeration

The attacker queries Active Directory for accounts carrying Service Principal Names. This is an ordinary directory lookup available to any domain member, and it returns a target list with useful context: account names, group memberships, and when each password was last set. Targets are then prioritised. A SQL Server account that also sits in Domain Admins, with a password set eight years ago, goes straight to the top.

Step 2: Service ticket request

The attacker requests service tickets for the identified SPNs using the standard Kerberos protocol. Because the requests use normal mechanisms, they are indistinguishable from a user opening a shared folder. Attackers commonly request tickets for every SPN they found in one pass, maximising the material available for cracking.

Where the environment permits it, they will specifically request RC4 encrypted tickets. An RC4 ticket is protected with a key derived directly from the account’s NTLM hash, which makes it dramatically cheaper to attack than an AES protected ticket.

Why the domain controller cannot help

The service ticket request is identical to legitimate activity because it uses the same protocol messages a real user generates. The domain controller cannot determine intent. It sees a valid request from a valid principal and fulfils it, exactly as designed. This is why the defence lives in password strength and encryption policy rather than in blocking the request.

Step 3: Offline password cracking

This is where the attacker spends their effort and where the organisation has no visibility at all. Extracted tickets are fed to cracking tools using dictionary attacks, rule based mutations of wordlists, and brute force against short passwords, with modern GPU hardware providing enormous throughput.

Success depends entirely on password strength. A service account created years ago with a memorable password, never rotated because rotation was thought risky, may fall in minutes. A genuinely random 25 character password will not fall at all.

Step 4: Credential validation and exploitation

With a recovered password the attacker validates it and assesses what it reaches. A compromised service account typically opens lateral movement, direct database access, and a route to persistence. If the account is over privileged, and many are, this single step can end the engagement.

It also feeds the previous article in this series. Holding the service account password means holding its hash, which is exactly what a Silver Ticket attack needs to forge service tickets for that service indefinitely.

Best practice

Treat any service account with a weak or unrotated password as already compromised. Auditing your own service account passwords against a cracking wordlist is a legitimate defensive exercise, and it is far better for you to find them first.

Detection challenges and indicators

Why Kerberoasting is difficult to detect

The attack hides inside normal behaviour. Ticket requests look like ticket requests. The cracking is invisible because it happens outside the network. Many organisations have no Kerberos monitoring beyond default logging, which leaves nothing to correlate even in hindsight.

CISSP Exam Note

Golden Ticket attacks bypass part of the authentication flow, so the anomaly is structural. Kerberoasting uses the flow exactly as designed, so there is no protocol anomaly to find. That difference is why baseline behavioural analysis is the correct detection answer for Kerberoasting and log correlation is the correct answer for Golden Tickets.

Key detection indicators

With monitoring in place, several behavioural signals stand out:

• Bulk requests: many service ticket requests from one account in rapid succession
• Breadth: requests for many distinct services from an account that normally touches two or three
• Timing: ticket requests outside the user’s normal working hours
• Novelty: requests for services the account has never accessed before
• RC4 preference: requests specifying RC4 encryption in an environment that supports AES

Detection strategy

Build a baseline of normal service ticket behaviour per account, then alert on deviation. Monitor Windows Event ID 4769, Kerberos service ticket operations, and pay attention to the encryption type field. Bulk requests, and any RC4 request where AES is available, deserve investigation. Without a baseline these events are simply noise, which is why the tuning matters more than the collection.

Mitigation and defence strategies

Immediate response and prevention

The defence is service account hygiene. Reset the passwords of any account showing suspicious ticket activity, coordinating with application owners so the change does not take a production system down. Then fix the underlying condition: service account passwords should be long and random, with 25 characters or more the usual recommendation for accounts a human has to set.

Advanced protection measures

Beyond passwords, monitor service account authentication patterns and bring service credentials under Privileged Access Management rather than leaving them in configuration files. Network segmentation limits what a compromised service account reaches, and deliberately Kerberoasting your own directory finds the weak accounts before an attacker does.

Best practice: Managed Service Accounts

A Group Managed Service Account uses a long random password that Active Directory generates and rotates automatically, with no administrator ever knowing it. An attacker can still request the ticket, but no wordlist or rule set recovers a random secret of that length, so the cracking step fails. This should be the default for every new service deployment. Note the precise claim: gMSAs make the attack computationally futile, they do not prevent the ticket request itself.

Kerberoasting compared with other Kerberos attacks

The attack progression

Read the table downward and you have the attack chain. Kerberoasting is the most accessible, needing only a standard user. Success yields a service account hash, which enables Silver Tickets. Full domain compromise yields the krbtgt hash and enables Golden Tickets. Stopping the cheapest attack removes the rung an attacker was planning to climb next. A close relative is AS-REP roasting, which targets accounts with Kerberos pre-authentication disabled and needs no credentials at all.

Conclusion

Kerberoasting exploits the design of Kerberos itself, not a flaw in it, to enable offline password attacks against service accounts. It demonstrates something worth carrying into practice: when a protocol hands out material encrypted with a long term secret, the strength of that secret becomes the whole of the control.

The fixes are unglamorous and they work. Strong random passwords, Managed Service Accounts, AES enforcement, and least privilege on service accounts remove the attack’s economics entirely, and they improve Active Directory security far beyond this one technique.

For the exam, remember that Kerberoasting requires only standard user privileges, that Service Principal Names are the targeting mechanism, that detection depends on behavioural baselines rather than protocol anomalies, and that Managed Service Accounts are the strongest single control.

Candidates lose marks telling the three Kerberos attacks apart under time pressure, because scenarios describe privileges and evidence rather than naming techniques. The LSM CISSP practice tests drill exactly that discrimination across Domain 5.

Quick reference for the CISSP exam

Kerberoasting abuses normal Kerberos authentication to obtain service tickets encrypted with service account password hashes, then cracks them offline. Unlike Golden Tickets, it needs only standard domain user privileges. The protocol itself is covered in the Kerberos glossary entry.

Attack prerequisites

• Domain user access: any authenticated domain account
• SPN enumeration: the ability to query Active Directory for accounts with Service Principal Names
• Cracking resources: computing power for offline password attacks
• No elevated privileges: standard user rights are sufficient

Attack execution steps

1. Service account enumeration: query Active Directory for accounts with SPNs
2. Service ticket request: request TGS tickets for the identified services
3. Offline cracking: extract the encrypted portion and attempt password recovery
4. Credential exploitation: validate and use the recovered password

Detection indicators

• Bulk ticket requests: many TGS requests from a single account
• RC4 preference: requests for weaker encryption where AES is available
• Timing anomalies: requests outside the account’s normal hours
• Atypical access: requests for services the account never uses
• Event ID 4769: the Kerberos service ticket event to baseline and alert on

Key defence measures

• Strong passwords: 25 characters or more, randomly generated, for service accounts
• Managed Service Accounts: automatic generation and rotation of long random passwords
• AES enforcement: disable RC4 and require AES-256
• Privilege minimisation: service accounts should never sit in privileged groups by default

Exam tips

• Kerberoasting needs only standard user privileges, the key distinction from Golden Tickets
• Offline cracking leaves no network evidence during the attack
• Managed Service Accounts make the cracking step computationally futile
• Detection relies on behavioural analysis, not protocol anomalies
• A cracked service account hash is what makes a Silver Ticket possible

Exam focus: the executive risk perspective

Do not just memorise the attack. Manage the business impact.

The low barrier problem. Where a Golden Ticket needs domain admin, Kerberoasting needs any compromised user. Your attack surface therefore includes every phishing victim and every weak password in the organisation, which is a direct argument for user security awareness investment.

Technical debt is security debt. Legacy service accounts with weak, unchanged passwords are accumulated technical debt that converts straight into risk. The managerial fix is service account governance: an inventory, an owner, mandatory strength requirements, and a rotation schedule.

The Managed Service Account business case. Migrating to Managed Service Accounts removes the Kerberoasting payoff while also removing the operational burden of manual password management. Frame it as a security improvement and an efficiency gain, because it genuinely is both.