What Is Kerberoasting?

Figure 1: A service ticket leaks a crackable form of the service account password

The attack that turns any domain account into a cracking target

Kerberoasting is one of the most dependable moves in an internal penetration test, and it needs nothing more than an ordinary domain account to begin. No admin rights, no exploit, just a feature of Kerberos behaving exactly as designed. That is what makes it dangerous, and why defenders need to understand it.

This post explains what the attack is, the design quirk it leans on, and how to close it off.

What Kerberoasting is

In an Active Directory domain, services such as SQL Server or a web app run under a service account. Kerberos lets a user request a service ticket, a TGS, to reach one of these services. The catch is that part of that ticket is encrypted with a key derived from the service account's password. Anyone in the domain can ask for the ticket, carry it away, and try to crack that password offline at their own pace.

The offline step is the whole game. The attacker never keeps hammering the domain controller, so nothing looks unusual, and a weak service password falls in minutes.

Why it works

Three design facts line up to make this easy:

• Any authenticated user can request a ticket for any service with a registered name. The domain hands it over without question.
• The ticket is encrypted with the service account's key, which comes straight from its password.
• Cracking happens offline, so there is no lockout, no rate limit, and no alarm from repeated guesses.

Put together, a service account with a human-chosen password is a soft target sitting in plain view.

SPNs and service accounts

A service is located through its Service Principal Name, or SPN, a label like MSSQLSvc/db01.corp.local:1433. Accounts with an SPN are exactly the ones an attacker lists first, because every SPN points at a crackable ticket. Service accounts are the usual victims, since they often carry old, rarely rotated passwords that someone picked by hand years ago.

RC4 versus AES tickets

The encryption type on the ticket decides how fast cracking goes. Older RC4 tickets, Kerberos etype 23, are quick to attack and map to Hashcat mode 13100. AES tickets, etypes 17 and 18, are far slower to crack and use different modes. Attackers prefer RC4 and will even request it where allowed, so forcing AES raises the cost of the whole attack.

A worked example

A captured ticket is converted into a crackable string that opens with a recognizable marker:

$krb5tgs$23$*svc_sql$CORP.LOCAL$MSSQLSvc/db01.corp.local:1433*$a1b2c3...  (long ciphertext truncated)

The Kerberos ticket converter turns a raw ticket into this format, and the hash identifier flags a $krb5tgs$ string on sight. During an authorized engagement that value goes to a cracker as mode 13100:

hashcat -m 13100 tickets.txt rockyou.txt

The 23 after $krb5tgs$ marks it as the fast RC4 type, which is why this example cracks far quicker than an AES equivalent.

How to defend against it

The fixes are practical and well proven:

• Give service accounts long, random passwords, 25 characters or more, so offline cracking fails.
• Use group Managed Service Accounts, which rotate a 120-character password automatically.
• Disable RC4 for Kerberos and require AES, removing the fast path.
• Watch for ticket requests, event ID 4769, especially one account pulling many SPNs at once.
• Audit your SPNs and strip any attached to accounts that no longer need them.

The takeaway

Kerberoasting works because Kerberos trusts any user to request a service ticket, and that ticket leaks a crackable form of the service account's password. The protocol is behaving correctly, so the defense is operational: long random service passwords, managed accounts, AES over RC4, and monitoring. Harden those accounts and the attack has nothing left to chew on.