Detecting Kerberoasting via Kerberos Service Ticket Monitoring
In the landscape of Active Directory (AD) exploitation, few techniques are as persistent, stealthy, and devastating as Kerberoasting. Unlike many modern exploits that rely on memory corruption or complex buffer overflows, Kerberoasting leverages the fundamental design of the Kerberos protocol itself. It is not a "bug" in the traditional sense; it is an exploitation of how service tickets are encrypted and distributed.
For security practitioners, the challenge lies in the fact that the attack occurs entirely within the legitimate bounds of Kerberos operations. An attacker does not need to interact with the target service directly; they only need to interact with the Domain Controller (DC). This makes traditional network-based intrusion detection systems (IDS) largely blind to the activity. To catch a Kerberoasting attack, we must shift our focus from the network perimeter to the deep inspection of Kerberos Service Ticket (TGS) requests within the Windows Event Logs.
The Mechanics of the Attack: Why It Works
To understand the detection strategy, we must first dissect the attack lifecycle.
In a healthy Kerberos environment, a user authenticates to the Authentication Service (AS) and receives a Ticket Granting Ticket (TGT). When that user needs to access a specific resource (e.g., an MSSQL database), they present their TGT to the Key Distribution Center (KDC) and request a Ticket Granting Service (TGS) ticket specifically for that service. The KDC validates the TGT and issues a TGS, which is encrypted using the long-term key (the NTLM hash) of the service account associated with the Service Principal Name (SPN).
Kerberoasting exploits this specific encryption step. An attacker, having already gained a foothold in the domain with any valid user context, iterates through all SPNs in the directory and requests a TGS for each one. The attacker then extracts the encrypted TGS blob from the response. Because the blob is encrypted with the service account's password hash, the attacker can move the data offline and use massive GPU clusters to perform brute-force or dictionary attacks against the encrypted blob. If the service account has a weak password, the attacker recovers the plaintext password, potentially gaining administrative access to the underlying service or the domain.
The Detection Gold Mine: Event ID 4769
The primary telemetry source for detecting Kerberoasting is Windows Event ID 4769: A Kerberos service ticket was requested. This event is logged on the Domain Controller whenever a TGS is issued.
While the sheer volume of 4769 events in a medium-to-large enterprise can be overwhelming, specific attributes within this event provide the signal necessary to identify malicious activity.
1. Encryption Type Downgrade (The 0x17 Signal)
Modern Kerberos implementations prefer AES-128 (0x12) or AES-256 (0x1a) encryption. However, attackers often attempt to force or specifically look for RC4-HMAC (0x17) encryption. RC4 is significantly easier to crack offline because it lacks the computational complexity of AES.
While some legacy systems may still use RC4, a sudden spike in TGS requests using `0x17` from a non-legacy workstation is a high-fidelity indicator of Kerberoasting.
2. Anomalous Request Volume (The "Burst" Pattern)
A legitimate user typically requests a handful of service tickets during a session-perhaps for an email server, a file share, and a print server. An attacker, however, needs to sweep the entire environment. This manifests as a single source IP or user account requesting a large number of unique SPNs within a very short temporal window (e.g., 50+ requests in 60 seconds).
3. Service Account Entropy
Monitoring the "Service Name" field is critical. Attackers target accounts with SPNs, which are often high-privilege service accounts. Detecting requests for sensitive services (like `MSSQLSvc`, `HTTP`, or `CIFS`) originating from unusual user accounts can highlight the reconnaissance phase of an attack.
Practical Implementation: Detection-as-Code
If you are using a SIEM (such as Splunk, Microsoft Sentinel, or an ELK stack), you should implement detection logic that correlates these attributes. Below is a conceptual Kusto Query Language (KQL) example for Microsoft Sentinel that identifies potential Kerberoasting by looking for high-volume RC4 requests.
```kusto
// Detect potential Kerberoasting via high volume of RC4 TGS requests
SecurityEvent
| where EventID == 4769
| where TicketEncryptionType == "0x17" // RC4-HMAC
| summarize
RequestCount = count(),
TargetServices = make_set(ServiceName),
DistinctServiceCount = dcount(ServiceName)
by IpAddress, SubjectUserName, bin(TimeGenerated, 5m)
| where RequestCount > 20 or DistinctServiceCount > 10
| project TimeGenerated, IpAddress, SubjectUserName, RequestCount, DistinctServiceCount, TargetServices
| order by RequestCount desc
```
In this query, we are not just looking for any RC4 request, but rather a burst of RC4
Conclusion
As shown across "The Mechanics of the Attack: Why It Works", "The Detection Gold Mine: Event ID 4769", "Practical Implementation: Detection-as-Code", a secure implementation for detecting kerberoasting via kerberos service ticket monitoring depends on execution discipline as much as design.
The practical hardening path is to enforce strict token/claim validation and replay resistance, deterministic identity policy evaluation with deny-by-default semantics, and admission-policy enforcement plus workload isolation and network policy controls. This combination reduces both exploitability and attacker dwell time by forcing failures across multiple independent control layers.
Operational confidence should be measured, not assumed: track false-allow rate and time-to-revoke privileged access and detection precision under peak traffic and adversarial packet patterns, then use those results to tune preventive policy, detection fidelity, and response runbooks on a fixed review cadence.