Kerberoasting: How Attackers Crack Active Directory Service Accounts

Kerberoasting is one of the most frequently used techniques in attacks on Windows networks - and one of the most underestimated, because it only requires one regular domain account. This is an almost routine step in Active Directory testing: in many organizations it allows you to take over a high-privileged account in a matter of hours. Let’s see why it works and how to defend against it.

A little about Kerberos

In an Active Directory domain, authentication is based on the Kerberos protocol. Simplified flow:

1. The user logs in and receives a TGT (Ticket Granting Ticket) from the domain controller (KDC) - a ticket confirming identity.
2. When he wants to use a service (e.g. SQL Server, IIS, shared file), he asks the KDC for a *service ticket (TGS) for that specific service.
3. The service is identified by the SPN (Service Principal Name) associated with the service account under which it is running.

Key detail: The KDC encrypts the service ticket (TGS-REP) with a key derived from the service account password. This means that anyone who obtains such a ticket holds data encrypted with the password of the service account.

Attack mechanism

This is where the design flaw that Kerberoasting exploits comes into play:

1. Any authenticated user of the domain can list accounts with SPN set (this is public information in the directory) and request a service ticket from the KDC for any of them. KDC will do this - it does not check whether the user actually intends to use the service.
2. The attacker receives a ticket (TGS-REP), a fragment of which is encrypted with the key from the service account password.
3. Cracks passwords offline. It has the material encrypted in-house, so it can dictionary/brute-force attack it on its own hardware (GPU), without any interaction with the domain - so no account lockouts, no alarms about failed logins, no attempt limits. Tools like hashcat do this en masse (mode 13100 for RC4 tickets, 19700 for AES).
4. If the password is weak or too short, it fails - and the attacker gains the credentials of a service account, often with broad privileges.

The entire attack does not require elevation of privileges at the start: any domain account will do. That’s why it’s so popular.

Why service accounts are a tasty morsel

Service accounts are an ideal target for several reasons:

• Strong permissions. They often have access to databases, application servers, and sometimes they belong to administration groups (which is a configuration error, but a common one).
• Old, weak passwords. Set once “to make it work” and left untouched for years - because changing it may result in a service failure. Perfect for offline cracking.
• RC4 encryption. If the account allows the weaker RC4 algorithm instead of AES, the ticket cracks much faster. Many environments still allow RC4 for compatibility.

Defense: What makes Kerberoasting really difficult

You can’t “turn off” service ticketing - that’s the basis of Kerberos. The defense is that breaking the ticket is impossible and the attempt is visible.

1. Strong, long passwords for service accounts - preferably managed automatically. This is the most important defense. Since the attack is offline cracking, password entropy wins. Manually keeping track of 25+ character passwords is unrealistic, so use gMSA/dMSA (group/delegated Managed Service Accounts): Windows generates very long, random passwords for them and rotates them automatically. The ticket of such an account is virtually unbreakable within a reasonable time. This is the most effective single step.

2. Force AES, disable RC4. Configure your accounts and domain so that tickets are AES encrypted rather than RC4. This significantly increases the cost of cracking and eliminates the easiest path.

3. Least permissions. A service account should have exactly the permissions the service needs - and nothing more. A service account in the Domain Admins group is an invitation to disaster. This is part of a broader Active Directory hardening.4. Detection. Although the cracking is offline, the ticket request itself is visible. Monitor event 4769 (service ticket request), especially when one account requests tickets from multiple different SPNs in a short period of time or requests RC4 encryption. This is the signature pattern of Kerberoasting. Effective detection requires log collection - see security monitoring.

5. Trap accounts (honeypot SPN). Create an attractive-looking service account with SPN that no real service uses. Any request for a ticket to him is an almost certain reconnaissance signal - a silent early warning alarm.

Summary

Kerberoasting works because it combines two things: a design feature of Kerberos (any user can download a service ticket encrypted with an account password) and human error (weak, old service account passwords with too broad permissions). The defense is familiar and effective: auto-managed, very long passwords (gMSA/dMSA), AES enforcement, least privilege, and post-Event 4769 detection. Implementing these four things turns a “routine step in every pentest” into a dead end.

Want to check if your domain is vulnerable to Kerberoasting and other AD techniques? Active Directory Penetration Test shows these exact paths - schedule a consultation. We write about how to prepare for such a test in a separate guide .

Frequently asked questions (FAQ)

Does Kerberoasting require administrator privileges? No - and that is the essence of its menace. Any authenticated domain account will do, even a regular user. Therefore, a single account compromised (e.g. by phishing) is often enough to trigger privilege escalation using this technique.

How does the attacker know which accounts to attack? Service accounts have an SPN attribute set in the directory, which is visible to any authenticated user. The attacker simply lists accounts from SPN and requests tickets for them - he doesn’t have to guess.

What are gMSAs and why do they help? gMSA (group Managed Service Account) are service accounts for which Windows automatically generates a very long, random password and rotates it regularly, without administrator involvement. Since Kerberoasting involves offline password cracking, a high-entropy password makes the attack unfeasible in practice. This is the most effective single defense.

Will we detect Kerberoasting if the cracking is done offline? You won’t see the breaking, but demanding tickets - you will. Event 4769 on the domain controller shows requests for service tickets; an unusual pattern (one account asking for many different SPNs, RC4 requests) is a strong signal. An account trap with SPN gives an additional, very clean alarm.