Kerberoasting and AS-REP Roasting: Kerberos Attacks and Defenses

Kerberos attacks are among the most common findings in Active Directory assessments, and almost none of them exploit a software vulnerability. They abuse features the protocol offers to any authenticated domain user. That is what makes them hard to patch away and why the defenses are configuration and monitoring rather than an update.

If the protocol itself is unfamiliar, start with how Kerberos issues tickets, because every attack below is a twist on the normal ticket flow.

Kerberoasting

Any authenticated domain user may request a service ticket for any service principal name in the domain. That is not a bug — it is how a client obtains access to a service. The ticket it receives is encrypted with the password hash of the account the service runs under.

So an attacker with any valid domain account enumerates service principal names, requests tickets for the ones tied to user accounts rather than machine accounts, and takes the tickets offline to crack. Nothing is tried against the domain controller, so there is no lockout, no failed logon, and no rate limit. If the service account password is weak, it falls.

The reason this works so often is that service accounts historically got human-chosen passwords that were never rotated because rotating them breaks the service. Machine accounts are immune because their passwords are 120 random characters rotated automatically — which is exactly the property you want for service accounts too.

AS-REP roasting

This one needs no domain account at all. If an account has Kerberos pre-authentication disabled, the domain controller will return an authentication response encrypted with that account's password hash to anyone who asks for it, simply on the strength of the username. The attacker collects those responses and cracks them offline.

Pre-authentication exists precisely to prevent this, and it is enabled by default. Accounts with it disabled are almost always legacy exceptions someone set years ago for an application that no longer exists.

Ticket theft and forgery

Once an attacker has local administrative rights on a host, tickets sitting in memory can be extracted and reused — pass-the-ticket. The stolen ticket authenticates as the user who owned it, with no password involved.

Worse are forged tickets. With the krbtgt account's hash, an attacker can mint a golden ticket: a ticket-granting ticket for any user, with any group membership, valid for as long as they choose. With a service account's hash, they can mint a silver ticket granting access to that one service. Golden tickets mean full domain compromise, and the only real remediation is resetting the krbtgt password twice, which invalidates every ticket in the domain.

Defenses that work

For roasting, the fix is the password. Use group managed service accounts wherever the application supports them, so Windows generates and rotates a long random password automatically. Where that is not possible, enforce 25-plus character random passwords on service accounts — length defeats offline cracking in a way that complexity rules never did.

Audit for and remove pre-authentication exceptions, and audit service principal names so that privileged accounts are never the ones running services. A domain admin account with an SPN is a Kerberoast away from domain compromise.

Force AES encryption and disable RC4 for Kerberos, since RC4-encrypted tickets crack dramatically faster. Constrain where privileged accounts may log on so their tickets never land in memory on an ordinary workstation, and make sure privileged access is brokered through a vault with just-in-time elevation rather than standing rights — the model covered under privileged access management.

Detection

Kerberoasting shows up as event 4769 — a service ticket request — in unusual volume from a single account, especially with RC4 encryption requested when the domain otherwise uses AES. One account requesting tickets for many distinct services in a short window is the clean signal, and it is straightforward to alert on once those events reach your SIEM.

AS-REP roasting appears as event 4768 for accounts with pre-authentication disabled. Golden tickets are harder, but anomalies such as a ticket lifetime far beyond policy, or a ticket for an account that does not exist, are detectable.

A decoy service account with a deliberately weak-looking password and an enticing SPN is an excellent trap: no legitimate process requests a ticket for it, so any request is an incident. That is the same logic as a honeytoken, applied to Active Directory.

Exam angles

Know that Kerberoasting targets service accounts and is cracked offline, that AS-REP roasting requires pre-authentication to be disabled, and that neither generates failed logons. Recognize golden tickets as krbtgt compromise and silver tickets as single-service forgery. When asked for the best mitigation for Kerberoasting, the answer is long random service account passwords or managed service accounts — not account lockout, which offline cracking never touches.