Kerberoasting

What is Kerberoasting?

Kerberoasting is an Active Directory attack in which an attacker with a valid domain account can crack arbitrary service-account passwords offline. The technique relies on a basic principle of Kerberos. Any authenticated user may request a ticket for any service. That ticket is encrypted with the password hash of the service account. An attacker who captures the ticket has an offline crack target, without ever needing to log in to the account.

The attack was first demonstrated in 2014 by Tim Medin at DerbyCon. MITRE ATT&CK categorizes it under T1558.003 Steal or Forge Kerberos Tickets: Kerberoasting.

How does Kerberoasting work?

The attack runs through four steps.

1. The attacker has a valid domain user account, no matter how few privileges it has. Even a standard user account works.
2. From that account he queries LDAP for a list of all accounts with a Service Principal Name (SPN). SPNs are typically assigned to service accounts (SQL Server, IIS, scheduled task).
3. For each SPN he requests a Ticket Granting Service ticket (TGS) from the domain controller. That is a normal Kerberos flow and triggers no alarm.
4. The domain controller returns a TGS encrypted with the password hash of the service account. The attacker extracts the encrypted blob and cracks it offline with hashcat.

The encryption type matters for cracking speed. An RC4-HMAC TGS (etype 23) is a SHA1-HMAC over the NT hash of the password, and goes into hashcat as mode 13100. On a modern GPU that cracks an 8-character lowercase password in seconds to minutes. AES-encrypted tickets (etype 17 for AES128, etype 18 for AES256) are heavier. Hashcat mode 19600 or 19700 handles those.

What makes the attack possible is that obtaining the TGS requires no authentication against the service account itself. The domain controller hands it to any authenticated domain user. A weak service-account password can therefore be cracked offline and unnoticed.

What can an attacker do with Kerberoasting?

Kerberoasting yields service-account passwords. Their value depends directly on the rights those accounts hold.

In an AD environment that applies least privilege correctly, a service account has only the rights its service technically needs, nothing more. A cracked hash from such an environment grants access to the matching service and not much further. With a strong password and periodic rotation the attack stays largely theoretical.

In practice, service accounts are often set up more carelessly. Many sit in privileged groups such as Domain Admins or Backup Operators, or have a delegated role over a whole OU, because it seemed simple at creation time. It regularly happens that a cracked SQL service account hands over Domain Admin rights directly. The pain is not in Kerberoasting itself, but in service accounts that have far more rights than their service ever needed. With BloodHound we map that wrong distribution of rights.

A final property is that the attack leaves almost no traces. A TGS request is part of the normal traffic in an AD domain. Only by alerting specifically on RC4-HMAC tickets does it become visible.

Kerberoasting in a pentest

In an Active Directory pentest, Kerberoasting is an early standard step as soon as we have a valid domain account. We run Impacket’s GetUserSPNs.py or Rubeus, write the TGS hashes to a file, and put that against our GPU rig in hashcat.

# Linux: enumerate all SPNs and request TGSs
GetUserSPNs.py -dc-ip 10.0.0.1 -request acme.local/jdoe -outputfile tgs.hashes

# Hashcat: RC4 tickets (mode 13100) against a wordlist
hashcat -m 13100 tgs.hashes /usr/share/wordlists/rockyou.txt

Weak service-account passwords fall within the hour, sometimes within minutes. If cracking does not work, we combine the SPN list with other findings. Which groups are these accounts in, which services run on which hosts, and which of those can we exploit further?

In our report we name not only which passwords we cracked, but also which service accounts sat in privileged groups for no reason. For most clients that is the most durable fix.

How do you prevent Kerberoasting?

You cannot block the attack entirely without abolishing Kerberos, but its impact can be contained well. Least privilege and long random passwords are the two fundamental measures.

Give a service account only the rights its service technically needs, nothing more. No Domain Admin, no wildcard delegations, no “just in case”. A cracked hash from a least-privilege account has limited value, while the same compromise on a service account with Domain Admin rights is immediately catastrophic.

Length and randomness are the criteria for the password. Nobody has to remember a service password, so we advise 64 bytes random. That makes offline cracking unfeasible, even with modern GPUs or dedicated rigs. Use a password generator instead of a recognizable pattern.

Group Managed Service Accounts (gMSA) are the modern replacement for traditional service accounts. Windows rotates the password automatically every 30 days, with a length of 240 bytes. A cracked gMSA hash has already changed within a month, and the chance an attacker cracks it in that time is negligible.

Turn off RC4-HMAC in your domain. With the Group Policy setting “Network security: Configure encryption types allowed for Kerberos” you force AES as the only allowed etype. That makes cracking considerably heavier, though it offers no complete protection.

Clean up unneeded SPNs. Many domain accounts were given an SPN years ago for a service that no longer runs. An unnecessary SPN is a free crack target for an attacker. Audit periodically which accounts actually need SPNs and remove the rest.

Honeypot SPNs and logging catch Kerberoasting attempts. Create a service account with a tempting name such as svc_db_admin, without an actual service behind it. Configure an alert on every TGS request for that account. On top of that, Windows Event ID 4769 with an RC4-HMAC encryption flag helps you spot regular Kerberoasting attempts.