Kerberoasting: cracking service accounts offline

How a service ticket leaks its own password

Kerberos lets a user ask a domain controller for a ticket to reach a service, and every service that runs under a domain account is registered with a service principal name, or SPN. The catch is who is allowed to ask. Any authenticated account in the domain can request a service ticket for any SPN, and the domain controller does not check whether the caller is entitled to use that service before it hands one over. That check happens later, at the service itself.

The ticket the domain controller returns carries a portion sealed with a key derived from the service account's own password. Capture that ticket and you hold an offline oracle for the password: you can guess against it on your own hardware, at the speed of your rig, with nothing further sent to the domain. This is the technique catalogued as T1558.003 in MITRE ATT&CK, and it is a staple of the credential-access phase on an internal infrastructure penetration test.

The chain, from one low-privilege login

The chain starts with a single valid domain account at any privilege level. On an internal test that account often comes from an earlier step, such as an LLMNR poisoning and SMB relay capture, but a temporary contractor login serves just as well. With it, the first move is to ask LDAP which accounts carry an SPN, because those are the only ones worth roasting.

With the target list in hand, the operator requests a service ticket for each one and writes the sealed portion to disk. The tooling requests RC4 encrypted tickets by preference, for a reason the next section explains. What comes back is a $krb5tgs$ string, one per account, and the 23 in the prefix marks the RC4 encryption type.

From here the domain is done with. An RC4 ticket cracks in hashcat mode 13100, and a weak or aged service password falls to a common wordlist in minutes. The result is the account's password in clear, and the operator can log in as a service identity that frequently holds local admin across many hosts.

$ GetUserSPNs.py corp.example/jdoe:'Winter2026!' -dc-ip 10.0.0.10

ServicePrincipalName         Name     MemberOf                     PasswordLastSet
---------------------------  -------  ---------------------------  -------------------
MSSQLSvc/sql01.corp.example  svc_sql  CN=SQL Admins,OU=Service...  2021-03-14 09:12:41
HTTP/intranet.corp.example   svc_web  CN=Web Ops,OU=Service...     2020-11-02 16:44:03

$ GetUserSPNs.py corp.example/jdoe:'Winter2026!' -dc-ip 10.0.0.10 -request -outputfile roast.txt
[*] Requesting TGS for svc_sql
[*] Requesting TGS for svc_web

$ head -c 90 roast.txt
$krb5tgs$23$*svc_sql$CORP.EXAMPLE$MSSQLSvc/sql01*$a1b2c3d4...<truncated>

$ hashcat -m 13100 -a 0 roast.txt rockyou.txt
$krb5tgs$23$*svc_sql$...:Summer2019

Status...........: Cracked
Recovered........: 1/2 (50.00%) Digests

Why any user can ask, and why RC4 is the gift

Two design facts make this work. The first is that the domain controller issues a service ticket to any authenticated principal and relies on the service to authorise use afterwards, so requesting a ticket is not itself a privileged act and raises no alarm on its own. The second is the encryption. An RC4 ticket is sealed with a key that is simply the account's NT hash, a single unsalted MD4 of the password, so cracking the ticket is cracking the password at raw hashing speed. That is why the tooling asks for RC4: an AES ticket derives its key through 4096 iterations, which slows guessing by orders of magnitude.

The rest is human. Service accounts tend to be created once, given a memorable password so an engineer can stand the service up, and then left with that password for years because rotating it risks an outage. That is the weakness the chain turns on, recorded as CWE-521 weak password requirements and CWE-262 not using password aging. The password guidance in NIST SP 800-63B is written for exactly this case: length beats complexity, and a long random secret is what defeats an offline guess. The related AS-REP roasting technique attacks the same password weakness from a different ticket.

Breaking the chain

The durable fix is to make the password uncrackable, which means taking it away from humans. A group managed service account, or gMSA, holds a 120 character password that Active Directory rotates automatically, and no wordlist reaches it. Where an application cannot use one, a random password of 25 characters or more with enforced rotation has the same effect. Disabling RC4 for Kerberos removes the fast path and forces any attacker onto AES, but it should be paired with strong passwords rather than trusted on its own.

Detection is the second layer, because the request itself is legitimate traffic. Windows logs each service ticket request as event 4769, and the signal is the shape of the activity: RC4 requests (encryption type 0x17) in an environment that should be AES, or one account pulling tickets for many SPNs in a short window. A honeypot service account with an SPN and no real use is a clean tripwire, since any ticket request for it is suspicious. If this is the exposure you need measured before an attacker finds it, an infrastructure pentest scoped to internal Active Directory is where it surfaces, and the same foothold often chains onward to certificate abuse such as ADCS ESC1.

SecurityEvent
| where EventID == 4769
| where TicketEncryptionType == "0x17"   // RC4, requested to ease cracking
| summarize Tickets = count() by Account, bin(TimeGenerated, 1h)
| where Tickets > 10

What roastable service accounts mean for UAE networks

Kerberoasting is not exotic. It is a default risk in any organisation running Active Directory, which covers most banks, government bodies and large enterprises across the UAE. For a bank supervised by the Central Bank of the UAE, or a Dubai government entity and its suppliers under DESC, the service accounts that run databases and internal web front ends are exactly the privileged, long-lived credentials these frameworks expect to be controlled and monitored. An Abu Dhabi healthcare provider under ADHICS faces the same exposure on the systems that hold patient data, and the federal Information Assurance regime published through NESA sets the same baseline expectations elsewhere.

Whether an entity sits in a Dubai free zone or on the mainland in Abu Dhabi, the internal Active Directory is usually shared plumbing that a perimeter test never touches. Finding roastable accounts before an attacker does is internal work, and it is a natural objective inside a broader red team engagement as well as a standalone internal test. The market difference between the two emirates is mostly in who authorises the test and how findings are reported, not in whether the weakness is present.

Frequently asked questions