How do you detect Kerberoasting?

Detect Kerberoasting from Domain Controller Event ID 4769. Alert when a single account requests service tickets for several distinct SPNs within minutes, especially with RC4 encryption (0x17) for accounts that support AES, and exclude machine accounts and krbtgt. Add a honeytoken service account with a realistic SPN, since no legitimate process requests it. Reduce the attack surface with gMSAs, AES-only service accounts and SPN cleanup. Baseline scanners and legacy services first, because they produce the same pattern.

Detecting Kerberoasting: RC4 Service-Ticket Bursts and SPN Abuse

Kerberoasting lets a low-privilege user request service tickets for accounts with a Service Principal Name and crack them offline. The Domain Controller sees only ordinary-looking TGS requests, so detection depends on how many tickets one account asks for, which encryption type it accepts, and whether it touches an account nobody should ever request. This pack covers all three.

Signals at a Glance

Signal	Where	ATT&CK
One account requests service tickets for many distinct SPNs in minutes	DC Security 4769	T1558.003
Ticket encryption type 0x17 (RC4-HMAC) for accounts that support AES	DC Security 4769	T1558.003
Any request for a honeytoken SPN account	DC Security 4769	T1558.003
LDAP query for servicePrincipalName=* from a workstation	DC 1644, MDI, network	T1087.002
Weak or old password on a user account that holds an SPN	AD audit, PingCastle	T1558.003

Ticket Volume and Encryption Type

Event ID 4769 (a Kerberos service ticket was requested) records the requester, the service name and the ticket encryption type. Real roasting tools request RC4 (0x17) because it is cheaper to crack, and they ask for many SPNs in a short window. Exclude machine accounts, krbtgt and failures, then count distinct services per requester:

index=wineventlog sourcetype="WinEventLog:Security" EventCode=4769
    Ticket_Encryption_Type=0x17 Failure_Code=0x0
| where Service_Name!="krbtgt" AND NOT match(Service_Name, "\\$$")
| bin _time span=10m
| stats dc(Service_Name) AS spn_count, values(Service_Name) AS spns,
        values(Client_Address) AS src by _time, Account_Name
| where spn_count >= 5
# tune/validate: raise the threshold for vulnerability scanners and
# service-inventory tools; field names depend on your Splunk TA version.

The same logic in KQL, scored against a rolling baseline so that a noisy backup or inventory service does not page you every night:

SecurityEvent
| where EventID == 4769 and TicketEncryptionType == "0x17" and Status == "0x0"
| where ServiceName !endswith "$" and ServiceName !~ "krbtgt"
| summarize spns = dcount(ServiceName), svc = make_set(ServiceName, 20)
          by TargetUserName, IpAddress, bin(TimeGenerated, 10m)
| where spns >= 5
// tune/validate: join to a 14-day per-account baseline and alert on deviation.

Honeytokens and Hygiene

Volume rules catch the noisy tools. A honeytoken catches the careful one. Create a user account with a realistic SPN, a long random password and no real use, then alert on any 4769 for that service. Nothing legitimate requests it, so a hit is a high-fidelity alert:

SecurityEvent
| where EventID == 4769
| where ServiceName =~ "svc_sqlbackup"   // your honeytoken account name
| project TimeGenerated, Computer, TargetUserName, IpAddress, TicketEncryptionType
// tune/validate: keep the account out of any vulnerability-scanner scope.

Move service accounts to group Managed Service Accounts (gMSA), which rotate 240-character passwords automatically and are not practically crackable.
Set msDS-SupportedEncryptionTypes to AES-only on service accounts and plan to retire RC4 domain-wide; RC4 requests then become anomalies by definition.
Inventory user accounts that hold SPNs and remove the SPN where the service no longer exists.
Make sure 4769 is collected from every Domain Controller, not only the primary.

Vetted sources

Start from the SigmaHQ and Elastic Kerberos service-ticket rules, the Splunk ESCU Kerberoasting analytics and Microsoft’s Kerberos hardening guidance. Baseline your own environment first — Linux and Java services, load balancers and scanners legitimately request RC4 tickets, and the volume threshold must reflect that.

Build Detections That Fire

Mjolnir Security helps blue teams turn threat intelligence into high-fidelity detections across endpoint, network, identity and cloud telemetry.

Detection EngineeringManaged Detection & ResponseThreat HuntingIncident ResponsePurple Teaming

Detection Engineering We build and tune detections mapped to ATT&CK from your own telemetry.
Threat Hunting as a Service Hypothesis-driven hunts for the behaviours on this page.
24/7 Incident Response Containment when a detection fires. Call +1 833 403 5875.

Written by: Mjolnir Threat Research (MTAC)  |  Published: October 12, 2026  |  Last reviewed: October 12, 2026

Signals at a Glance

Ticket Volume and Encryption Type

Honeytokens and Hygiene

Build Detections That Fire

Active Directory Attack Detection

Detection Hub

AS-REP Roasting Detection