If your company runs Windows infrastructure, someone on your team has probably heard the word “Kerberoasting”. It comes up in almost every internal network and Active Directory assessment, and it often sits near the top of the report.
This post explains what it is, why it works, and what you can do about it, without assuming you have spent years administering domain controllers.
The short version
Kerberoasting is a way for an attacker who already has any ordinary domain account to obtain material that lets them guess the passwords of service accounts, offline, at their own pace.
If a service account has a weak password, the attacker recovers it. If that service account has broad privileges, which they often do, the attacker has just moved from “one compromised laptop” to “control over important systems”.
Why it works
Kerberos tickets and service accounts
Active Directory uses Kerberos for authentication. When a user wants to access a service, such as a database or an internal web application, they ask the domain for a service ticket for that service.
Part of that ticket is protected with a key derived from the service account’s password. That is by design: the service uses its own password to read the ticket.
The weakness
Any authenticated user can request a service ticket for any service registered in the domain. That is normal behaviour, not a bug.
The problem is what happens next. Because part of the ticket is protected by the service account’s password, an attacker can take the ticket away and try password guesses against it on their own hardware. Nothing touches the domain during that guessing, so it generates no failed logins and no lockouts.
The strength of the whole thing therefore rests on one question: how strong is the service account’s password?
Why it shows up so often
Kerberoasting is a common finding because it combines several habits that are easy to fall into:
- Old service accounts. Accounts created years ago for an application, often with passwords set once and never changed.
- Human-chosen passwords. Service account passwords that someone had to type into a configuration screen, so they were made memorable.
- Too much privilege. Service accounts added to powerful groups “to make it work” during setup.
- Nobody owns them. The person who created the account has moved on, so nobody feels safe changing it.
None of these is a dramatic mistake on its own. Together, they turn a low-privilege foothold into a serious incident.
What to do about it
The good news is that the fixes are well understood. Most are operational rather than architectural.
1. Find your service accounts
You cannot fix what you cannot see. Ask your team for a list of accounts that have service principal names registered, who owns each one, and what it is used for. Expect some surprises, including accounts nobody can explain.
2. Use managed service accounts where you can
Windows supports group managed service accounts, where the domain generates and rotates long, random passwords automatically. Nobody needs to know the password, and it is far too long to guess. Moving eligible services to managed accounts removes the problem at the root.
3. Make the remaining passwords long and random
Where a managed account is not possible, use a long, randomly generated password stored in a password manager or vault, and rotate it on a schedule. Length matters most: a long random password makes offline guessing impractical.
4. Cut privilege back
A service account should have exactly the access its service needs. Membership of highly privileged groups should be rare, justified and reviewed. If a cracked password only opens one application’s database, the impact is contained.
5. Prefer stronger encryption types
Older encryption types make offline guessing easier. Your infrastructure team can review which encryption types service accounts support and remove legacy options where applications allow it.
6. Watch for unusual ticket requests
A single user requesting service tickets for many services in a short period is unusual. If you have security monitoring, it is worth a detection rule.
What a good assessment tells you
In an internal network and Active Directory assessment, testers look for Kerberoastable accounts, check whether their passwords would withstand offline guessing, and, crucially, show what an attacker could reach if they did not. That last part is what turns a technical finding into a business decision: “this account would give access to payroll” is easier to prioritise than “weak password on service account”.
If you want to understand how we approach this safely, our internal network and Active Directory testing page explains the assumed-breach approach, and our methodology covers how we rate findings.
A simple checklist for this quarter
- List every service account and give each one an owner.
- Move what you can to managed service accounts.
- Replace remaining human-chosen passwords with long random ones.
- Remove service accounts from privileged groups unless there is a documented reason.
- Retire accounts nobody can justify.
Want to know how far one compromised account could go in your environment? Tell us what you need tested.