How Kerberoasting works

Kerberoasting (MITRE ATT&CK T1558.003) is one of those techniques that survives because it abuses the protocol exactly as designed. Any authenticated domain user can request a service ticket for an account that has a Service Principal Name, and part of that ticket is encrypted with a key derived from the service account’s password. Request it, take it offline, and crack it - no elevated rights, no touching the target service.

The protocol detail it leans on

In Kerberos, when a user wants to reach a service, the KDC issues a TGS (service ticket). A portion of that ticket is encrypted with the service account’s long-term key. For a machine account that key is random and effectively uncrackable. But when the SPN is registered to a regular user account - a SQL service running as svc_sql, say - the key derives from a human-chosen password. That’s the whole game.

The attacker never needs to authenticate to the service. They just ask the KDC for the ticket, which the KDC will hand to any valid domain principal:

1. Enumerate accounts that have an SPN set (LDAP: servicePrincipalName=*).
2. Request a TGS for each SPN.
3. Extract the encrypted blob and crack it offline against a wordlist.

Because step 3 is offline, there’s no lockout, no failed-logon noise on the target, and no rate limit.

Why RC4 makes it worse

Tickets encrypted with RC4-HMAC (etype 23) are far faster to crack than AES, and a downgrade to RC4 is often possible. Defenders should watch for a spike in TGS requests (event 4769) for RC4 etype, especially many distinct SPNs from one principal in a short window.

Cutting it off