Analyzing Kerberos Constrained Delegation via PAC Validation Failures

In the complex ecosystem of Active Directory (AD) security, Kerberos Constrained Delegation (KCD) stands as a double-edged sword. While it provides the necessary mechanism for middle-tier services to impersonate users to backend resources-enabling seamless Single Sign-on (SSO) experiences-it also introduces a sophisticated attack surface. For security practitioners, the challenge is not merely detecting the use of delegation, but identifying the subtle indicators of its abuse.

One of the most potent, yet often overlooked, signals for detecting Kerberos-based lateral movement and privilege escalation is the analysis of Privilege Attribute Certificate (PAC) validation failures.

The Mechanics of Kerberos Delegation

To understand the failure modes, we must first dissect the mechanics of the two primary extensions used in KCD: S4U2self (Service for User to Self) and S4U2proxy (Service for User to Proxy).

S4U2self: The Identity Forgery Vector

S4U2self allows a service to request a service ticket (TGS) on behalf of a user to itself, even if the user did not provide Kerberos credentials to that service (e.g., via NTLM or web authentication). This is the foundational step for an attacker who has compromised a service account with `TrustedToAuthForDelegation` enabled. By using S4U2self, an attacker can "self-issue" a ticket for a high-privileged user (like a Domain Admin) to the service they control.

S4U2proxy: The Leap to the Backend

Once the service holds a TGS for the user (via S4U2self), it uses S4U2proxy to request a new TGS for a different, backend service (e_g_, CIFS or LDAP). This is where the "constrained" part of KCD manifests: the service can only delegate to the specific SPNs (Service Principal Names) explicitly listed in the `msDS-AllowedToDelegateTo` attribute.

The PAC: The Source of Truth

The Kerberos ticket is more than just a proof of identity; it contains the Privilege Attribute Certificate (PAC). The PAC is an extension within the Kerberos ticket that carries the user's authorization data, specifically their Security Identifiers (SIDs) and group memberships.

The integrity of the PAC is paramount. When a Key Distribution Center (KDC) issues a ticket, it signs the PAC using its own secret key. When a service receives a ticket, it can-and in many hardened environments, should-validate this PAC. This validation involves checking the cryptographic signatures to ensure the SIDs within the PAC have not been tampered with or injected.

Anatomy of a PAC Validation Failure

A PAC validation failure occurs when the cryptographic or structural integrity of the PAC is called into question during the TGS exchange or when the service verifies the ticket against the KDC.

There are two primary scenarios where these failures manifest as actionable security telemetry:

1. Signature Mismatches (The Forgery Signal)

In a sophisticated "Silver Ticket" or forged S4U2self attack, an attacker attempts to manipulate the PAC to include the SID of a highly privileged group (e.g., Enterprise Admins). While the attacker can create a seemingly valid ticket structure, they cannot re-sign the PAC with the KDC's long-term key.

When the backend service or the KDC performs a validation check, the mismatch between the provided PAC signature and the calculated signature results in a failure. In Windows environments, this often manifests as `KDC_ERR_POLICY` or specific errors within the KDC's audit logs indicating that the PAC signature is invalid.

2. The "Unconstrained" vs. "Constrained" Discrepancy

In environments where users are transitioning between unconstrained and constrained delegation, discrepancies in the PAC's structure-such as missing or unexpected SIDs-can trigger validation errors. If an attacker attempts to use a service ticket obtained via S4T2self to perform S4U2proxy, but the PAC does not contain the necessary authorization data expected by the target service, the KDC may reject the request.

Practical Detection: Monitoring the Telemetry

Detecting these failures requires moving beyond standard "Success" logs. You must focus on the anomalies within the Kerberos auditing subsystem.

Event ID 4769: The TGS Request

The primary source of truth is Event ID 4769 (A Kerberos service ticket was requested). While this event is ubiquitous, you should hunt for specific attributes:

• Service Name Mismatches: Look for TGS requests where the `Service Name` is an unusual target for the `Client Name` (the service account).
• Large PACs: An unusually

Conclusion

As shown across "The Mechanics of Kerberos Delegation", "The PAC: The Source of Truth", "Anatomy of a PAC Validation Failure", a secure implementation for analyzing kerberos constrained delegation via pac validation failures 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 certificate lifecycle governance with strict chain/revocation checks. 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 certificate hygiene debt (expired/weak/mis-scoped credentials), then use those results to tune preventive policy, detection fidelity, and response runbooks on a fixed review cadence.