Kerberoasting

Kerberoasting lets any authenticated domain user request the material to crack service-account passwords offline, using Kerberos. There is no exploit, no privilege escalation to start, and no contact with the target service. It is one of the most reliable privilege-escalation paths in Active Directory, and it exists because of one design decision about how service tickets are encrypted.

The mechanism

Services in Kerberos are identified by Service Principal Names (SPNs), registered against the account that runs each service. To access a service, a user asks the KDC for a service ticket (TGS) for that SPN. The KDC returns a ticket encrypted with the service account's password-derived key, so the service can decrypt tickets meant for it. Notice how nothing is wrong with this process, since this is the intended design.

The exploitable part: any authenticated domain user can request a service ticket for any SPN, and the KDC hands it over without checking whether the requester should access that service. The user now holds a blob encrypted with the service account's key. This can then be taken offline and brute-forced; guess the password, derive the key, attempt decryption, and a valid result means the guess was correct. Crack it and you have the service account's plaintext password.

Service Accounts

Service accounts make ideal victims since they are frequently privileged (SQL Server, IIS app pools, and enterprise apps often run with extensive rights, sometimes Domain Admin). Their passwords are often old, weak, and manually set, because a someone picked an easy-to-remember password years ago and rotation never happened in case it broke the app. And because these accounts are non-interactive, nobody notices a weak password the way they would for a user login.

A privileged account with a crackable password allows Kerberoasting to turn into a domain compromise. It also pairs directly with Silver Ticket forging: crack the service account, then mint unlimited service tickets for it.

Encryption downgrade

Modern AD supports AES for tickets, which is difficult to crack because the key is derived through a salted, iterated function. Attackers therefore try to force the legacy RC4 cipher, where the key is simply the account's NT hash and cracking is way faster. A request specifying RC4 is both a Kerberoasting enabler and a useful detection signal. Disabling RC4 domain-wide helps decrease the chances of the attack succeeding.

Detection and defense

• Strong service-account passwords: 25 or more random characters make offline cracking infeasible regardless of everything else.
• Group Managed Service Accounts: AD generates and auto-rotates a 240-character password nobody knows, so a cracked ticket isn't a threat. Use these wherever the application supports them.
• Least privilege: A cracked service account should not be Domain Admin. Scope accounts properly so a crack yields little.
• Disable RC4: Force AES and remove the fast-cracking path.
• Detection. Monitor event ID 4769, but baseline first, since legitimate apps request many tickets. The high-signal triggers are the RC4 etype and honey SPNs that fire on any request, catching the reconnaissance process.

Kerberoasting is very clear example of abusing a protocol's intended behaviour since nothing is broken and nothing is being bypassed, so the fix is not a patch but hygiene.