Kerberoasting: Turning One Domain Account into a Pile of Service Passwords

Picture a penetration tester on their first morning inside a client network. They have been handed one ordinary account, the kind a new starter in the finance team would get. No admin rights, no special access, nothing exciting. Within about twenty minutes, that same tester is holding the plaintext password of an account that runs a critical database, and that account happens to be a member of Domain Admins. They never ran an exploit. They never crashed anything. They simply asked the network a polite, completely normal question, and the network answered honestly.

That is Kerberoasting. It is one of those techniques that feels like cheating the first time you watch it work, because nothing is technically broken. You start as a single low privilege domain user, you ask the domain controller a question it is designed to answer, and it hands you back something you can quietly crack offline into the plaintext password of a service account. No exploit, no crash, no alert in most environments. Just Kerberos doing exactly what it was built to do.

This is a defensive walk through the mechanics, so you understand why it works and, more importantly, how to close it off.

First, a plain language tour of Kerberos

Before the attack makes sense, you need a mental model of the machinery it abuses. Do not worry, we can keep this simple.

Kerberos is the system Windows uses to prove who you are across a network without sending your password around. Think of it like a theme park. When you arrive in the morning, you show your ID at the front gate once and receive a wristband. That wristband proves you are a paying guest for the day. From then on, whenever you want to go on a specific ride, you do not show your ID again. You show your wristband and get a single use ride pass for that ride.

In Kerberos terms:

• The Key Distribution Centre (KDC) is the front gate. In a Windows network it lives on the domain controller, the central server that holds all the accounts.
• The Ticket Granting Ticket (TGT) is your wristband. You get it once when you log in, and it proves you are a valid user.
• A service ticket, formally a Ticket Granting Service reply or TGS, is a ride pass. You present your TGT and ask for a ticket to a specific service, and the KDC issues you one.

Here is the piece that matters most. When the KDC builds that ride pass for a service, it locks part of it with a key made from the password of the account that runs the service. That way, when you hand the ride pass to the service, the service can unlock it and trust that the KDC vouched for you. The password of the service account is baked into the lock.

The one design fact that makes it possible

In Active Directory, a Service Principal Name (SPN) is a label that links a service, such as a SQL Server instance, a web application pool, or a file service, to the account that runs it. If an account has an SPN set on it, the network is announcing "this account runs a service, and here is its name."

Here is the catch, and it is the whole game: any authenticated domain user can request a service ticket for any SPN. That is not a bug, it is how Kerberos distributes tickets. The domain controller does not stop to check whether you are actually allowed to use that database or that web app. You have a valid wristband, so it hands you the ride pass.

That ride pass contains a blob that is encrypted with a key derived from the service account's password. So the moment you can request the ticket, you are holding an offline, crackable representation of that account's password. You have not touched the service. You have not logged into anything sensitive. You just collected the lock and walked away to work on it in private.

Any domain user  --->  "Give me a ticket for SPN: MSSQLSvc/db01"
Domain controller --->  Here is your ticket (part of it locked
                        with the SQL service account's password key)

The attack in four steps

Conceptually the whole thing is short:

1. Enumerate accounts that have an SPN set.
2. Request a Kerberos service ticket (TGS) for each SPN.
3. Extract the encrypted portion of each ticket.
4. Crack it offline to recover the service account password.

Step one is simply asking Active Directory a normal directory question: which accounts have an SPN? That query is something even a brand new low privilege user is allowed to run.

In practice a single tool does steps one to three in one go. Impacket's GetUserSPNs is the classic:

# From a domain-joined position with any valid credentials
GetUserSPNs.py -request -dc-ip 10.10.10.10 sauravlab.local/analyst:'Password123'

That returns ticket hashes ready for a cracker. The word "hash" here is loose but useful: it is the scrambled, password locked portion of each ticket, written out in a format a cracking tool understands. Then a tool such as hashcat does step four, hammering through a wordlist to find the password that unlocks it:

# RC4 encrypted TGS-REP tickets
hashcat -m 13100 tickets.txt rockyou.txt

The -m 13100 tells hashcat which kind of ticket it is looking at. If the tickets come back using the stronger AES encryption instead of the older RC4, the mode changes (19600 for AES128, 19700 for AES256), and cracking is slower, but the process is identical. Same steps, tougher lock.

A concrete walk through

It helps to imagine the timeline as a story rather than a list.

09:00  Tester logs in as "analyst", a normal finance user.
09:05  Asks the domain controller: which accounts have SPNs?
       Answer includes svc_sql, svc_backup, svc_web.
09:07  Requests a service ticket for each of those SPNs.
       The domain controller happily issues all three.
09:08  Saves the encrypted portions to a file.
09:10  Starts hashcat against a wordlist on a laptop GPU.
09:24  svc_sql cracks. Its password was "Summer2021!".
       svc_sql turns out to be in Domain Admins.
09:25  The domain is effectively over.

Nothing in that sequence looks like an attack to a casual observer. Requesting service tickets is what every user does all day. The only unusual thing is the volume and the timing, and we will come back to that when we talk about detection.

Why it succeeds so often

The technique is old, yet it still lands in the large majority of internal assessments. The reasons are cultural, not technical:

• Service accounts have weak passwords. Many were set once, years ago, by a tired administrator, and never changed. Something like Company2019! is not a rare find, it is close to a default.
• They rarely expire. Service account passwords are often exempted from the rotation policy that applies to normal staff, because changing them risks breaking whatever the service does. So a weak password from 2019 is still a weak password today.
• They are over privileged. Far too many service accounts sit inside Domain Admins or carry rights well beyond what the service actually needs to function. That means cracking one is frequently a straight path to owning the whole domain.
• RC4 is still enabled. Tickets encrypted with the older RC4 algorithm use a key derived directly from the account's NT hash, and they crack faster than AES. If RC4 is available, an attacker will ask for it on purpose.

Put those four together and Kerberoasting becomes a reliable route from "I have one ordinary account" to "I own a privileged account." It is not luck. It is the predictable outcome of how most domains have grown over the years.

Shutting it down

You cannot stop domain users requesting tickets. That is Kerberos itself, and turning it off would break authentication for everyone. So the defence is twofold: make the tickets useless to crack, and shrink the blast radius so that a cracked ticket does not hand over the kingdom.

1. Use long, random passwords on service accounts. Twenty five characters or more of genuine randomness pushes offline cracking out of practical reach. This is the single biggest win, and it directly defeats the whole technique because the lock is now protecting a secret that no wordlist contains.
2. Move to group Managed Service Accounts (gMSA) or delegated managed service accounts. These use very long random passwords that Active Directory generates and rotates automatically. There is no human chosen password to guess and nothing memorable to recover, so even a cracked ticket yields nothing usable.
3. Enforce AES and disable RC4 where you can, so that any ticket which is stolen is at least the slower kind to attack. This buys time and closes the shortcut that RC4 offers.
4. Practise least privilege. A cracked service account should not equal domain takeover. Keep service accounts out of high privilege groups, give each one only the access its service genuinely needs, and follow a tiering model so that compromise of one account stays contained.
5. Watch for the tell. Event ID 4769 is logged whenever a Kerberos service ticket is requested. A single account requesting tickets for many different SPNs in a short window, especially requesting the weaker RC4 encryption (ticket encryption type 0x17), is a strong Kerberoasting signal worth alerting on.

The takeaway

Kerberoasting is not a hole to be patched, it is a feature to be managed. The domain will always hand out those tickets, because handing out tickets is its entire job. Your task is to make sure that what comes back is a long random secret protecting a low privilege account, not Summer2021! protecting Domain Admin. Do the two things that matter, strong or managed passwords on service accounts and strict least privilege, and the technique quietly stops working against you even though nothing about Kerberos has changed.

If you want to understand why a long random password defeats offline cracking while a short one falls in seconds, read the companion primer on how password hashing works. And if you want to see the other classic route through an Active Directory network, one where the attacker never bothers cracking anything at all, read up on pass the hash.