Hardening Enterprise Identity by Deciphering Kerberos Authentication Vulnerabilities and Forensic Signatures

In a post-compromise scenario, the first 60 minutes of log preservation are critical for detecting the silent propagation of a Golden Ticket. As security architects, we often witness environments where Kerberos authentication is treated as a “black box,” leaving the most sensitive Ticket Granting Ticket (TGT) transactions unmonitored.

Modern adversaries no longer crack passwords; they “pivot on identity,” abusing the very protocols designed to secure them. This guide dismantles the technical intricacies of Kerberos auth, providing Blue Teams with the forensic telemetry and logic required to eradicate persistence.

Achieving true Kerberos security requires moving beyond simple alert monitoring. It demands a granular understanding of how Kerberos identity is asserted, delegated, and potentially forged across the Active Directory fabric.

Defending the Kerberos authentication cycle is the highest-priority task for any identity-centric SOC. Adversaries exploit the protocol’s reliance on symmetric encryption and legacy compatibility to move laterally.

• Encryption Downgrade Hunting: Attackers force RC4 (Type 23) encryption to facilitate faster offline cracking during Kerberoasting.
• PAC Validation Logic: Forged tickets often lack a valid Privilege Attribute Certificate (PAC) signature, a key forensic indicator.
• Delegation Risks: Unconstrained and Resource-Based Constrained Delegation (RBCD) remain the primary vectors for full domain escalation.
• KRBTGT Rotation: The only definitive way to invalidate a Golden Ticket is a double rotation of the KRBTGT account password.

The Technical Anatomy of Kerberos Authentication

The Kerberos protocol operates on a trusted third-party model, utilizing the Key Distribution Center (KDC). The KDC is typically hosted on a Domain Controller and consists of two primary services: the Authentication Service (AS) and the Ticket Granting Service (TGS).

When a user initiates Kerberos authentication, the process begins with an AS-REQ. This packet contains the user’s identity and a timestamp encrypted with their secret key (derived from their password). If the KDC can decrypt this, it issues a Ticket Granting Ticket (TGT) via the AS-REP.

The TGT is the “passport” of the network. It allows the user to request access to specific services without re-entering their credentials. This is where Kerberos identity is solidified, but also where the most significant risks reside.

Forensic Artifact Analysis: Which Data Matters and Why?

For a DFIR specialist, the Kerberos protocol produces specific Event IDs that reveal the intent of an actor. We must distinguish between “Normal Noise” and “Adversarial Signal” within the Security Log.

1. Event ID 4768: TGT Request (The AS Phase)

This log is generated when a user requests a TGT. Key fields to monitor include the “Ticket Options” and “Pre-Authentication Type.” An AS-REQ without pre-authentication (Type 0) is a primary indicator of AS-REP Roasting vulnerabilities.

2. Event ID 4769: Service Ticket Request (The TGS Phase)

This is the most critical log for detecting Kerberoasting. If a user requests an unusually high volume of Service Tickets for different Service Principal Names (SPNs) in a short window, an automated attack is likely underway.

3. Event ID 4771: Kerberos Pre-Authentication Failure

A spike in 4771 events for a single user suggests a brute-force or password-spraying attempt. However, pay close attention to the Failure Code. Code 0x18 indicates a wrong password, while 0x25 suggests a clock skew issue, often seen during ticket injection.

4. The Role of the PAC (Privilege Attribute Certificate)

The PAC is an extension in the Kerberos ticket that includes the user’s SIDs and group memberships. When a service receives a ticket, it should (but doesn’t always) verify the PAC signature with the KDC to ensure the Kerberos identity hasn’t been tampered with.

Advanced Hunting: KQL and Sigma Strategies

To scale your Kerberos security operations, you must automate the detection of encryption downgrades. Adversaries prefer RC4 encryption for TGS-REPs because the hash is easier to crack offline compared to AES-256.

KQL: Identifying Kerberoasting via RC4 Downgrade

This query runs in Microsoft Sentinel or Defender for Endpoint. It filters for TGS requests where the encryption type is 0x17 (RC4-HMAC), which is rare in modern, hardened environments.

Code snippet

// Hunting for Kerberoasting via RC4 Encryption Downgrade
DeviceEvents
| where ActionType == "KerberosServiceTicketRequest"
| extend TicketEncryptionType = tostring(AdditionalFields.TicketEncryptionType)
| where TicketEncryptionType == "0x17" // RC4-HMAC
| where ServicePrincipalName !contains "$" // Filter out machine accounts
| project Timestamp, DeviceName, InitiatingProcessAccountName, ServicePrincipalName, TicketEncryptionType
| summarize RequestCount = count() by InitiatingProcessAccountName, bin(Timestamp, 1h)
| where RequestCount > 10

Sigma Rule: Golden Ticket Detection

A Golden Ticket is a forged TGT. Because it is created offline using the stolen KRBTGT hash, the initial AS-REQ (Event 4768) is missing. We look for a 4624 (Logon) event where the ticket was presented, but no corresponding TGT request exists in the logs.

YAML

title: Potential Golden Ticket Usage
status: experimental
description: Detects logon events with Kerberos where no TGT request was recently observed for that user.
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4624
        LogonType: 3
        AuthenticationPackageName: 'Kerberos'
    condition: selection and not (Event 4768 seen in last 10 hours)
falsepositives:
    - Long-lived tickets in specific legacy apps
level: high

Step-by-Step Incident Response Workflow

When a high-confidence Kerberos authentication alert triggers, your response must be rapid to prevent domain dominance. Follow this L3-specific workflow to contain and eradicate the threat.

Phase 1: Triage and Scoping

Identify the source IP and account involved. Use BloodHound or SharpHound to visualize the attack path. If a user account was Kerberoasted, determine if that user has local admin rights on sensitive servers or “GenericAll” permissions over other objects.

Phase 2: Containment

If a TGT has been compromised, simply changing the user’s password will not invalidate the existing ticket. You must disable the account or perform a “Purge” of all Kerberos tickets on the affected endpoints using klist purge.

Phase 3: Eradication (The KRBTGT Reset)

If a Golden Ticket is suspected, the entire Kerberos identity infrastructure is compromised. You must reset the KRBTGT password twice. This is a high-risk operation; the first reset invalidates half the tickets, and the second reset (after replication) invalidates all tickets issued before the first reset.

Automating Kerberos Defense with AI and LLMs

In 2026, the volume of Kerberos auth logs is too vast for human analysts. We leverage LLMs to perform “Contextual Identity Analysis.” By feeding the LLM a stream of SPN requests and historical user behavior, it can identify anomalies that a static threshold would miss.

Log Logic Enrichment

Traditional SIEMs look for “Count > X.” An AI-driven approach asks: “Is it normal for this ‘Junior Developer’ to request a TGS for the ‘Production SQL Cluster’ at 3 AM from a non-standard workstation?”

Python: Extracting IoCs for MISP Integration

Automate the extraction of suspicious SPNs and source IPs from your logs to ingest them into your Threat Intel Platform (TIP). This allows you to share the “Identity-based IoC” across your security stack.

Python

import json
import requests

def push_to_misp(ioc_data):
    misp_url = "https://your-misp-instance/events"
    headers = {"Authorization": "YOUR_API_KEY", "Content-Type": "application/json"}
    payload = {
        "info": "Suspicious Kerberos SPN Request",
        "Attribute": [{"value": ioc_data, "type": "target-user"}]
    }
    response = requests.post(misp_url, headers=headers, data=json.dumps(payload))
    return response.status_code

# Example usage with parsed log data
push_to_misp("service_admin_account_01")

Tooling Landscape: Enterprise vs. Open Source

Selecting the right tools for Kerberos security depends on your organization’s maturity. While enterprise tools offer automation, open-source tools are essential for deep forensic analysis.

Understanding Kerberos Delegation Vulnerabilities

Delegation allows a service to impersonate a user to access a second service. This is a massive surface area for Kerberos identity theft.

1. Unconstrained Delegation: The service is trusted to impersonate the user to any other service. If the server is compromised, the attacker can harvest TGTs from any user who connects.
2. Constrained Delegation: Restricted to specific services.
3. Resource-Based Constrained Delegation (RBCD): The target service decides who can delegate to it. This is often abused via the msDS-AllowedToDelegateTo attribute.

FAQs: Answering Long-Tail Technical Queries

Q: Can Kerberos work without a Domain Controller?

A: No. The DC acts as the Key Distribution Center (KDC). If the KDC is offline, no new Ticket Granting Ticket can be issued, although existing tickets may still work until they expire.

Q: What is the difference between a Golden Ticket and a Silver Ticket?

A: A Golden Ticket is a forged TGT, giving access to the entire domain (requires the KRBTGT hash). A Silver Ticket is a forged Service Ticket, giving access only to a specific service (requires that service’s computer account hash).

Q: How does “Protect Users” group help Kerberos security?

A: Adding sensitive accounts to the “Protected Users” group in AD forces the use of AES encryption and prevents the caching of credentials, significantly reducing the success of PtT attacks.

Strengthening Kerberos Auth Today

To solidify your Kerberos security posture, you must implement these technical controls immediately:

1. Audit SPNs: Identify all accounts with an SPN and enforce 25+ character passwords or transition to Group Managed Service Accounts (gMSAs).
2. Enforce AES: Disable RC4 at the domain level via Group Policy (Network security: Configure encryption types allowed for Kerberos).
3. Tiered Administration: Ensure that Domain Admins never log into lower-tier workstations where their TGT can be harvested.
4. Monitor for 4769 Spikes: Set a threshold in your SIEM to alert when a single user requests more than 15 unique SPNs within 5 minutes.

Mastering Kerberos authentication is not a destination but a continuous forensic discipline. By understanding the underlying “ticket logic” and encryption requirements, you position your SOC to defeat the most sophisticated identity-based adversaries.