Kerberoasting

Kerberos issues a service ticket to any authenticated domain user who asks for one. Part of that ticket is encrypted with a key derived from the password of the account the service runs under, which is why the ticket is useful to an attacker: it is a password hash that the domain hands over on request.

The sequence is short. The attacker enumerates accounts that carry a service principal name, asks the key distribution centre for a service ticket for each one, and saves the encrypted portion. Nothing else happens on the network. The cracking runs offline, on the attacker’s own hardware, against a wordlist. If the account password is weak, it falls; if it is a long random string, it does not.

Two details decide the outcome. The first is the encryption type: a ticket issued with the legacy RC4 type cracks far faster than one issued with AES, and many domains still allow the legacy type for compatibility. The second is who owns the account. A service account created years ago by an administrator, with a password chosen by a human and never rotated, is the usual winner.

Enumeration itself is trivial, and that is worth stating plainly to a client. The list of accounts with a service principal name is readable from Active Directory by any authenticated user. There is no privilege required to know exactly which accounts are worth asking for.

The failure is not in Kerberos. Kerberos is doing exactly what it was designed to do. The failure is that organisations create service accounts the way they create people, with a password someone typed, and then grant those accounts far more than they need.

On an internal test this is often the shortest route from a standard user to something that matters. We authenticate as an ordinary domain account, ask for every service ticket we are entitled to, and crack offline. The account that falls is rarely the one anyone was watching. It is a reporting service, a backup agent, or a scheduled task that was granted membership of a privileged group years ago because it was quicker than working out the right permissions.

The reason this survives is that the request itself is legitimate. There is no exploit, no malware, no privilege boundary crossed at the moment of the request. Controls built around blocking bad actions do not see a user asking for a ticket they are allowed to ask for.

The second reason is that the cracking is invisible. It happens on hardware the defender cannot see, at a speed the defender cannot influence, with no further contact with the network. By the time the password is used, the event that produced it is days old and buried.

Both recover a crackable blob from Kerberos without touching the target host, and they are routinely confused. They are not the same attack and they do not have the same fix.

The practical consequence: AS-REP roasting is something an attacker can try before they have any foothold, so it belongs in external and initial access discussion. Kerberoasting needs a foothold first, which is why it shows up in the middle of an internal test rather than at the start.

Treating it as a Kerberos vulnerability to be patched. There is nothing to patch. The fix is account hygiene and encryption policy.

Rotating the password without lengthening it. A new human-chosen password cracks as fast as the old one. Length and randomness are what change the outcome, not freshness.

Forcing AES and stopping there. AES makes cracking slower, not impossible. A short password under AES is still a short password.

Assuming the service accounts are all known. Service principal names accumulate. On most estates we test, the list contains entries nobody present can account for.

Alerting on ticket requests generally. Ordinary activity generates a continuous stream of them. The rule that works is about the pattern, not the event, and a rule written against the event alone gets disabled within a fortnight for noise.

Inventory every account with a service principal name and confirm each one is still in use. Move the accounts you control to managed passwords that are long, random and rotated by the directory rather than by a person. Remove service principal names from accounts that no longer run a service. Disable the legacy RC4 encryption type where the estate can take it, and measure what breaks before you do.

Then check group membership: the damage from a cracked service account is decided entirely by what that account was allowed to reach, which is where least privilege earns its keep. A service account with a weak password and no privileges is an observation. The same password on an account in a privileged group is the whole engagement.

On detection, the signal is not the ticket request itself but the pattern: one account requesting tickets for many distinct services in a short window, and requests that specify the legacy encryption type when the rest of the estate has moved on. A second, cheaper signal is a honeypot account: create an account with a service principal name, no privileges and no real service behind it, and alert on any ticket request for it. Nothing legitimate ever asks.

In an internal report, kerberoasting rarely appears as a standalone finding. It appears as a step in an attack path, between initial domain access and whatever the recovered account unlocked, and the finding is written against the account, not against Kerberos.

The evidence we hand over is the reproduction, not a screenshot of a tool: the account name and its service principal name, the encryption type the ticket was issued with, the fact that the password was recovered offline, and the group memberships that made it matter. We do not include the recovered password in the report body.

Severity moves with one question: what did the account reach. The same technique against a forgotten account with no privileges is an observation; against an account in a privileged group it is the finding the whole report is built around. Where the recovered account also enabled lateral movement to another tier, the path is written out step by step so the client can see which single change breaks it.

This is part of what we look at in a penetration test performed from inside the network.

Is kerberoasting still relevant? Yes. It needs no exploit and no unpatched software, so it does not age the way a vulnerability does. It stops working in an estate where every service account has a long random managed password, which is still uncommon.

Do you need admin rights to kerberoast? No. Any authenticated domain account can request the tickets. That is the whole point of the technique and the reason it is hard to distinguish from normal activity.

Does AES stop kerberoasting? No. It slows the offline cracking down considerably, which raises the cost, but a weak password still falls. Encryption type and password strength are two separate controls and you need both.

How is kerberoasting different from pass-the-hash? Kerberoasting recovers a password by cracking it offline. Pass-the-hash does not recover the password at all: it reuses the hash directly to authenticate. One produces a credential you can type; the other reuses a credential you cannot read.