hackweb
notes on hacking and technology
IT EN
main menu
user menu
you are not logged in

Kerberoasting: cracking service accounts without touching them

August 18, 2026 · 3 min read · #active-directory #windows #post-exploitation

Kerberoasting is among the most feared techniques in an Active Directory domain because it exploits no vulnerability: it exploits the intended behaviour of Kerberos. All it takes is valid credentials for any user — even the most insignificant — and the rest happens offline, on the attacker's machine, invisible to agents on the target's endpoint.

The piece of Kerberos that matters: the TGS

In Active Directory, when a user wants to use a service (a SQL database, an internal web server, a file share) it asks the Domain Controller for a service ticket, technically a TGS (Ticket Granting Service). The DC returns it encrypted with the service account's long-term key, which is derived directly from that account's password.

The logic is: only the service, which knows its own password, can decrypt the ticket and trust its contents. But the DC does not verify that whoever requests the ticket has any right to talk to that service. It issues the ticket to anyone who asks. And the ticket, once in your hands, is encrypted with something you can brute-force.

SPNs are the map of targets

Every kerberized service account has one or more SPNs (Service Principal Names) registered in its LDAP attribute. A normal user account has none; a service account does. So the first step is trivial: ask LDAP for all users with an SPN.

# enumeration: users with an SPN = roasting candidates
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName

# or with impacket, from Linux, with only domain credentials:
GetUserSPNs.py DOMAIN/user:password -dc-ip 10.0.0.1 -request

The -request flag does both things in one shot: it finds the accounts with an SPN and requests the TGS for each.

The ticket becomes a crackable hash

The tool extracts the part of the ticket encrypted with the account's key and formats it as an offline hash ($krb5tgs$ format). From there it is an ordinary dictionary/brute-force attack, with no further contact with the domain:

hashcat -m 13100 hashes.txt wordlist.txt -r rules/best64.rule

Mode 13100 is exactly Kerberoasting with RC4 encryption. Each attempt is: take a candidate password, derive its NTLM key, try to decrypt the ticket, and see whether the internal structure is well-formed. Millions of attempts per second on a GPU.

Why RC4 is the gift

Kerberos supports several encryption types for tickets. With RC4-HMAC (etype 23) the key is the NTLM hash of the password, and cracking is very fast. With AES (etype 17/18) key derivation goes through 4096 iterations of PBKDF2, which slows brute-force by orders of magnitude. Many attackers explicitly force the request to RC4 if the domain still allows it, precisely for this. Disabling RC4 in the domain is one of the most effective mitigations.

Why it is so hard to detect

  • Requesting a TGS is a legitimate, constant operation: it happens thousands of times a day in a healthy domain. A roasting hides in the background noise.
  • The cracking happens offline: after obtaining the tickets the attacker can disconnect. No telemetry on the service's endpoint.
  • The one useful signal is event 4769 (service ticket request) on the DC, filtered for RC4 etype and for a single account requesting many different SPNs in a short time. It is a weak signal, not a certain alarm.

The real defence

Because the attack is offline brute-force, the defence is to make brute-force impractical:

  • Long, random passwords for service accounts: 25+ machine-generated characters. A 30-character random passphrase defeats any dictionary and makes AES brute-force economically absurd.
  • Group Managed Service Accounts (gMSA): Windows generates and rotates a 120-character password automatically that no human knows. It is the structural fix: it makes roasting pointless because there is nothing to crack in human time.
  • Disable RC4 at the domain level, forcing AES.
  • Remove needless SPNs: every SPN on a privileged account is a target. Service accounts should never be in Domain Admins.

The broader lesson: in Active Directory the most valuable attack surface is not bugs, but legitimate configurations. Kerberoasting, AS-REP roasting, unconstrained delegation, weak ACLs — all are protocol features turned against whoever left them open.


« back to home

latest posts
 
your IP address:
216.73.216.108
visitor #1
MOTD:
Every abstraction leaks somewhere.
Here we look at where.
topics