Detecting Kerberos Golden Ticket Attacks via TGT Lifetime Anomalies

In the hierarchy of Active Directory (AD) compromises, nothing commands more dread than the "Golden Ticket." When an adversary successfully extracts the NTLM hash of the `KRBTGT` account, the security boundary of the entire domain effectively dissolves. At this stage, the attacker is no longer just a user within the network; they are a master of identity, capable of forging Ticket Granting Tickets (TGTs) that grant any level of access to any resource, indefinitely.

While traditional detection focuses on the theft of the `KRBTGT` hash (e.g., monitoring for LSASS memory dumps or DCSync activity), detecting the use of a forged ticket is significantly more challenging. Because a Golden Ticket is generated offline, the Domain Controller (DC) does not log a TGT creation event (Event ID 4768) when the attacker crafts the ticket. Instead, the first time the DC becomes aware of the forged credential is when the attacker presents it to request a Service Ticket (TGS).

This post explores a high-fidelity detection strategy: identifying Kerberos TGS requests that exhibit anomalous lifetimes-specifically, TGTs whose expiration timestamps deviate from the domain's established Kerberos policy.

The Anatomy of a Golden Ticket

To understand the detection, we must understand the forgery. The Kerberos protocol relies on a trusted third party, the Key Distribution Center (KDC), to issue tickets. The KDC uses its `KRBTGT` secret to encrypt TGTs, ensuring that any ticket it can decrypt is authentic.

An attacker possessing the `KRBTGT` hash can use tools like Mimikatz to forge a TGT offline. This forged TGT contains a Privilege Attribute Certificate (PAC) that the attacker can manipulate to include arbitrary Group SIDs (e.g., Domain Admins, Enterprise Admins).

Crucially, the attacker has total control over the metadata within the TGT, including:

1. The User Identity: Any valid or even non-existent user.
2. The Ticket Lifetime: The `StartTime` and `EndTime` fields.
3. The Renewal Period: How long the ticket can be renewed.

While an attacker could set a lifetime of 10 hours to mimic legitimate behavior, doing so requires frequent re-forging, which increases the attacker's operational noise. To achieve long-term persistence with minimal effort, attackers frequently set the `EndTime` to years or even decades in the future. This is the "anomaly" we can exploit.

The Detection Logic: Identifying Lifetime Deviations

In a standard, healthy Kerberos environment, the `MaxTicketAge` is governed by Group Policy. In most Windows domains, the default TGT lifetime is 10 hours, with a maximum renewal period of 7 days.

When an attacker uses a Golden Ticket to request a Service Ticket (TGS), the KDC processes the presented TGT. During this process, the KDC generates Event ID 4769: A Kerberos service ticket was requested. This event contains critical metadata, including the `Ticket End Time`.

The detection strategy is straightforward but powerful: Identify any Event ID 4769 where the `Ticket End Time` exceeds the domain's configured `MaxTicketAge`.

Practical Implementation

To implement this, you need access to Kerberos authentication logs (Security logs on Domain Controllers) ingested into a SIEM or a centralized logging platform like Splunk, Sentinel, or ELK.

#### KQL Implementation (Azure Sentinel/Microsoft Defender)

If you are using Microsoft's security stack, you can use Kusto Query Language (KQL) to hunt for these anomalies.

```kusto

SecurityEvent

| where EventID == 4769

| extend TicketEndTime = todatetime(TargetUserName) // Note: Field mapping depends on your log parser

// In a real scenario, you must parse the 'Service Ticket End Time' from the event data

| extend TicketEnd = parse_datetime(EventData.TicketEndTime)

| extend MaxAllowedLifetime = 10h

| extend TicketDuration = TicketEnd - TimeGenerated

| where TicketDuration > MaxAllowedLifetime

| project TimeGenerated, Computer, TargetUserName, TicketEnd, TicketDuration

|

```

Conclusion

As shown across "The Anatomy of a Golden Ticket", "The Detection Logic: Identifying Lifetime Deviations", a secure implementation for detecting kerberos golden ticket attacks via tgt lifetime anomalies 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.