Kerberoasting explained: how any domain user can steal a service account password

Most attacks on Active Directory need some kind of privilege to get started. Kerberoasting does not. Any ordinary domain account, such as one taken over through a single phishing email, is enough to ask a domain controller for material that can reveal the passwords of service accounts. And the part of the attack that does the real work happens on the attacker's own computer, where your logs cannot see it.

MITRE ATT&CK tracks the technique as T1558.003. It has been public for over a decade and still works in many networks, because it abuses normal Kerberos behavior rather than a bug that can be patched.

Why it works

In Active Directory, services such as SQL Server, web applications and backup software are registered with a Service Principal Name (SPN), usually on a dedicated service account. When a user wants to reach one of those services, their computer asks a domain controller for a service ticket. Part of that ticket is encrypted with a key derived from the service account's password, so that only the service can read it.

Two design decisions make this exploitable:

• Any authenticated user can request a ticket for any SPN. The domain controller does not check whether the user is actually allowed to use the service; that check happens later, at the service itself.
• The ticket can be taken offline. An attacker can save it and try millions of password guesses against it on their own hardware, with no account lockout and no logs.

If the ticket is encrypted with the older RC4 algorithm and the service account has a human-chosen password, cracking can take minutes.

How an attack unfolds

1. A foothold with any domain account

   The attacker controls one ordinary user account, often from phishing. No administrator rights are needed.

2. List the service accounts

   They query Active Directory, which any user can read, for accounts that have an SPN. Publicly available tools automate this.

3. Request tickets

   They request a service ticket for each interesting account. To the domain controller, these look like normal requests.

4. Crack offline

   They take the tickets to their own machines and run password-cracking tools against them. Weak or old passwords fall quickly.

5. Use the account

   With the cracked password they sign in as the service account, which is often far more privileged than it needs to be, sometimes even a domain administrator.

How defenders spot it

The request step leaves a trace on the domain controllers: event 4769, a Kerberos service ticket was requested, recorded in the Security event log. Normal activity generates huge numbers of these events, so the signal is in the pattern: one account requesting tickets for many different services in a short time, especially with RC4 encryption (encryption type 0x17).

This Microsoft Sentinel query looks for that pattern in the SecurityEvent table:

SecurityEvent
| where TimeGenerated > ago(1d)
| where EventID == 4769
| parse EventData with * 'Name="ServiceName">' ServiceName '<' * 'Name="TicketEncryptionType">' EncryptionType '<' *
| where EncryptionType == "0x17"
| where ServiceName !endswith "$" and ServiceName !~ "krbtgt"
| summarize Services = dcount(ServiceName), ServiceList = make_set(ServiceName, 20),
    FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by TargetUserName, IpAddress
| where Services >= 5
| order by Services desc

The highlighted lines keep only RC4 tickets and drop computer accounts (names ending in $) and the krbtgt account, which account for most of the noise. Tune the threshold to your environment, and adapt the field extraction if your events are collected in a different format. Microsoft Defender for Identity, if you have it, raises its own alert for this behavior.

A trap that almost never lies

A very effective complement is a honeypot service account: an account with an attractive-looking SPN, a long random password and no real use. No legitimate user or application will ever request a ticket for it, so a single 4769 event for that SPN is a high-confidence sign that someone is enumerating and roasting service accounts.

How to make it fail

• Use group managed service accounts (gMSA) wherever the application supports them. Windows generates and rotates their long, random passwords automatically (Microsoft Learn).
• Give remaining service accounts long random passwords, stored in a password vault and rotated, rather than memorable ones that never change.
• Prefer AES over RC4 for service accounts, so tickets are far slower to crack.
• Apply least privilege: a service account that runs a reporting tool should not be a domain administrator. Many Kerberoasting incidents become domain compromises only because of that.
• Remove SPNs that are no longer used, and review regularly which accounts have them.

Why it matters for a SOC analyst

Kerberoasting is a reminder that attackers love techniques that look like normal traffic. You will rarely catch the cracking, but you can catch the burst of ticket requests, and you can make the cracked passwords worthless. When you see it, treat it as active lateral movement: identify the requesting account and host, check which service accounts were targeted, and reset those passwords quickly, starting with the most privileged.