Detecting Anomalous Kerberos Ticket Requests via SIEM

In the modern enterprise, the perimeter has dissolved. As organizations shift toward cloud-hybrid models, identity has become the primary battleground. Within an Active Directory (AD) ecosystem, the Kerberos protocol serves as the bedrock of authentication. Because Kerberos is fundamentally designed to facilitate seamless access through a trusted third party-the Key Distribution Center (SEC)-it is a prime target for attackers.

The challenge for Security Operations Center (SOC) analysts is that many Kerberos-based attacks do not involve malware or exploit-driven code execution. Instead, they leverage "Living-off-the-Land" (LotL) techniques, using legitimate protocol flows to move laterally, escalate privileges, or harvest credentials. Detecting these anomalies requires moving beyond simple signature-based detection and into the realm of behavioral analysis within a SIEM (Security Information and Event Management) platform.

The Mechanics of the Target: Kerberos Flows

To detect anomalies, one must first understand the "golden path" of a Kerberos exchange. The process involves several critical steps, each leaving a distinct footprint in the Windows Event Logs on Domain Controllers (DCs):

1. AS-REQ / AS-REP (Authentication Service): A user provides credentials to the Authentication Service. If valid, the KDC issues a Ticket Granting Ticket (TGT). In the logs, this is represented by Event ID 4768.
2. TGS-REQ / TGS-REP (Ticket Granting Service): The user, possessing a TGT, requests a Service Ticket (ST) for a specific resource (e.g., a file share or SQL server). This is represented by Event ID 4769.

Attackers target these specific exchanges to perform AS-REP Roasting, Kerberoasting, or to forge Golden/Silver tickets.

Identifying Attack Patterns through Log Analysis

Effective SIEM detection relies on monitoring specific attributes within Event IDs 4768 and 4769.

1. AS-REP Roasting Detection

AS-REP Roasting targets accounts where the `DONT_REQ_PREAUTH` flag is enabled. An attacker can request an authentication ticket and, because pre-authentication is disabled, receive an encrypted part of the response that can be cracked offline via brute force.

Detection Logic:

Monitor Event ID 4768 where the `Pre-Authentication Type` is not `0x2` (Kerberos pre-authentication) or specifically look for instances where the authentication request succeeds without the initial encrypted timestamp exchange.

2. Kerberoasting: The TGS-REQ Storm

Kerberoasting is perhaps the most prevalent Kerberos attack. An attacker requests a large volume of Service Tickets (TGS-REPs) for service accounts with high-privilege SPNs (Service Principal Names). Once the tickets are received, the attacker extracts the encrypted part of the ticket and attempts to crack the service account's password offline.

Detection Logic:

The signal here is not a single event, but a statistical deviation. You are looking for a single user or source IP requesting an unusual number of distinct service tickets within a short temporal window.

• Anomaly Indicator: `count(distinct ServiceName) by User, SourceIP > Threshold`
• SIEM Implementation (Pseudo-KQL):

```kusto

SecurityEvent

| where EventID == 4769

| summarize TicketCount = dcount(Service) by TargetUserName, IpAddress, bin(TimeGenerated, 10m)

| where TicketCount > 20

```

3. Encryption Downgrade Attacks

Modern Kerberos implementations use AES (Advanced Encryption Standard). However, attackers often attempt to force the use of RC4-HMAC (Encryption Type `0x17`). RC4 is cryptographically weak and significantly easier to crack via brute force. A sudden influx of RC4-based requests in an environment that primarily uses AES is a high-fidelity indicator of potential Kerberoasting or credential manipulation.

Detection Logic:

Monitor Event ID 4768 and 4769 for the `Ticket Encryption Type` field. Filter for `0x17`.

• High-Fidelity Alert: `EventID == 4769 AND EncryptionType == 0x17`

Operationalizing Detection in the SIEM

Deploying these detections is not as simple as writing a query. It requires a structured approach to data engineering and baseline creation.

Data Ingestion and Normalization

The first hurdle is the volume of logs. Domain Controllers generate massive amounts of 4768/4769 events. If you ingest every single event without filtering, you will quickly exhaust your SIEM's ingestion license and degrade query performance.

• Strategy: Use a log forwarder (like Winlogbeat or Splunk Universal Forwarder) to filter out "noise" at the source. Focus on

Conclusion

As shown across "The Mechanics of the Target: Kerberos Flows", "Identifying Attack Patterns through Log Analysis", "Operationalizing Detection in the SIEM", a secure implementation for detecting anomalous kerberos ticket requests via siem depends on execution discipline as much as design.

The practical hardening path is to enforce deterministic identity policy evaluation with deny-by-default semantics, certificate lifecycle governance with strict chain/revocation checks, and host hardening baselines with tamper-resistant telemetry. 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 mean time to detect and remediate configuration drift, then use those results to tune preventive policy, detection fidelity, and response runbooks on a fixed review cadence.