Kerberoasting Detection: How to Find It Before the Password Gets Cracked

Kerberoasting is one of those techniques that's been around for over a decade and still appears in the majority of Active Directory compromise cases. The reason is simple — it abuses a completely legitimate Kerberos feature, requires no special tools beyond standard Windows functionality in its basic form, and the actual cracking happens offline where your detections can't see it.

The detection window is narrow. An attacker requests a service ticket — a completely normal operation — takes it offline, and starts cracking. Your detection has to fire during the ticket request phase, before the password has been compromised. Here's how to do that reliably.

How Kerberoasting Works

Any authenticated domain user can request a Kerberos service ticket (TGS) for any account that has a Service Principal Name (SPN) set. The TGS is encrypted with the service account's password hash. Request the ticket, take the encrypted blob offline, run a password cracker against it — if the service account has a weak password, you have plaintext credentials without ever touching the service account itself or logging into the system it runs on.

What makes it detectable is the encryption type. Modern Kerberos environments use AES-256 (0x12) or AES-128 (0x11) encryption by default. Kerberoasting tools specifically request RC4-HMAC (0x17) encryption because it's significantly faster to crack offline. That RC4 request for a service account that should be using AES is your primary detection signal.

Detection 1: RC4 Service Ticket Requests (Primary Signal)

Event ID 4769 fires on the domain controller every time a Kerberos service ticket is requested. The encryption type field is what separates Kerberoasting from legitimate ticket requests.

SecurityEvent
| where TimeGenerated > ago(1d)
| where EventID == 4769
| where TicketEncryptionType == "0x17"
// RC4-HMAC — modern environments use 0x12 (AES-256)
| where TicketOptions == "0x40810000"
// Exclude machine accounts — they end with $
| where ServiceName !endswith("$")
// Exclude built-in accounts that legitimately use RC4
| where ServiceName !in~(
    "krbtgt", "kadmin/changepw")
| summarize
    RequestCount = count(),
    TargetServices = make_set(ServiceName),
    SourceIPs = make_set(IpAddress),
    ServiceCount = dcount(ServiceName)
    by AccountName, bin(TimeGenerated, 1h)
| order by ServiceCount desc, RequestCount desc

index=win_* sourcetype="WinEventLog:Security"
EventCode=4769 Ticket_Encryption_Type=0x17
earliest=-1h latest=now
| where NOT match(Service_Name, "\$$")
| where Service_Name != "krbtgt"
| stats
    count as TicketRequests
    dc(Service_Name) as UniqueServices
    values(Service_Name) as ServiceList
    values(Client_Address) as SourceIPs
    by Account_Name
| where UniqueServices >= 3
    OR TicketRequests >= 10
| sort - UniqueServices

Detection 2: SPN Enumeration Before the Ticket Request

Before requesting tickets, attackers enumerate which accounts have SPNs set. This shows up as LDAP queries against AD and can be detected via CrowdStrike or Sysmon before any 4769 event fires — giving you an earlier warning.

// setspn.exe or PowerShell AD module SPN queries
#event_simpleName=ProcessRollup2
| regex("(?i)(setspn|get-aduser.*spn|
    ldap.*serviceprincipalname)",
    field=CommandLine)
| where UserName != "SYSTEM"
| groupBy([UserName, ComputerName],
    function=count(), as=QueryCount)
| sort(QueryCount, order=desc)

Detection 3: Correlate Ticket Request with Subsequent Lateral Movement

The real-world value of Kerberoasting detection isn't just finding the ticket request — it's connecting the ticket request to what happens next. A cracked service account will eventually be used. Correlating 4769 RC4 requests with subsequent 4624 Type 3 logons from those same service accounts is how you confirm a successful crack and catch the lateral movement that follows.

let KerberoastWindow = 48h;
let SuspectAccounts = SecurityEvent
    | where TimeGenerated > ago(KerberoastWindow)
    | where EventID == 4769
    | where TicketEncryptionType == "0x17"
    | where ServiceName !endswith("$")
    | summarize make_set(ServiceName) by AccountName
    | mv-expand ServiceName = make_set_ServiceName
    | project tostring(ServiceName);
SecurityEvent
| where TimeGenerated > ago(KerberoastWindow)
| where EventID == 4624
| where LogonType == 3
| where SubjectUserName in(SuspectAccounts)
| project TimeGenerated, Computer,
    SubjectUserName, IpAddress, LogonType
| order by TimeGenerated desc

Hardening: Reduce the Attack Surface

Detection is the reactive layer. The proactive work is reducing how many service accounts are Kerberoastable in the first place.

• Audit all SPNs — run `setspn -T yourdomain -Q */*` and review every account with an SPN set. Remove SPNs that aren't actively needed.
• Move to Managed Service Accounts (gMSA) — gMSAs use 240-character random passwords that rotate automatically and are computationally infeasible to crack even with RC4 tickets. The most effective Kerberoasting mitigation available.
• Enforce AES encryption on service accounts — set "This account supports Kerberos AES 256 bit encryption" on all service accounts in AD. This forces AES tickets even when an attacker requests RC4, making the ticket computationally infeasible to crack offline.
• Audit service account password age — any service account with a password older than 1 year that can't be moved to gMSA should be force-rotated and put on a 90-day rotation schedule. Old passwords are crackable passwords.