Kerberoasting Explained

Kerberoasting is requesting a Kerberos service ticket for an account that has a service principal name, then cracking that ticket offline. It works because the ticket is encrypted with a key derived from the service account's password, and because any authenticated domain user is allowed to request one. No exploit, no elevated rights, no further contact with the domain once you have the ticket.

Why it exists

Kerberos is designed so that a user can prove to a service that they are authorised, without the service having to call the domain controller. To do that the controller issues a ticket encrypted with the service account's key.

That design is fine. The problem is two things layered on top of it: any authenticated user can ask for a ticket for any service, and service account passwords are frequently set by a human once and never changed.

The flow

1. Enumerate. Find domain accounts that have a service principal name set. These are the roastable ones.
2. Prioritise. A service account that is also in a privileged group is worth far more than one that runs a print service. Check group membership before you crack anything.
3. Request. Ask the domain controller for a service ticket for the chosen account. This is a normal, allowed operation.
4. Extract. Pull the encrypted portion out of the ticket.
5. Crack offline. Run a wordlist against it on your own machine. Nothing further touches the network.
6. Use it. A cracked service account password is a valid domain credential, often with more privilege than a normal user.

Why offline cracking is the dangerous part

Once you hold the ticket, everything after that is invisible to the domain. No failed logons, no lockouts, no alerts. You can run for days against a long wordlist and the defenders see nothing.

That is what makes this quiet and why it sits early in the order of operations in Active Directory attacks.

What decides whether it succeeds

A twenty five character random password is not getting cracked. A company name with a year on the end is getting cracked in minutes. That is the entire difference.

Detection

You cannot see the cracking, but you can see the request. What defenders look for:

• A single account requesting service tickets for many different services in a short window
• Ticket requests specifying a weaker encryption type than the environment normally uses
• Requests from a host that has no business talking to that service
• Honeypot service accounts: an account with an SPN, a strong password and no real use, which nobody legitimate would ever request

That last one is the highest signal detection in the list and it costs nothing to deploy. Detection engineering for it is in the SOC analyst syllabus.

Prevention

1. Group managed service accounts. The password becomes long, random and automatically rotated. This alone removes the attack.
2. Least privilege. A service account in a domain admin group turns a medium finding into a critical one.
3. Disable weak encryption types where legacy systems allow it.
4. Audit SPNs regularly. Remove the ones set on accounts that no longer run a service.
5. Deploy a honeypot service account. Cheap, and it turns a quiet attack into a loud one.

How to answer this in an interview

Keep it to one sentence, then wait for the follow up: requesting a service ticket for an account with an SPN and cracking it offline, because the ticket is encrypted with a key derived from that account's password.

The follow up is almost always why it is quiet. The answer is that cracking happens off the network. More in VAPT interview questions.

Practise this

Build a two machine domain, create a service account with an SPN and a weak password, roast it, and then fix it with a group managed service account and try again. The before and after is the lesson.