Analyzing Kerberos Delegation Chains for Privilege Escalation

In the modern enterprise, identity is the new perimeter. As traditional network boundaries dissolve due to cloud integration and remote work, the security of the authentication protocols governing internal movement becomes paramount. Within an Active Directory (AD) ecosystem, Kerberos stands as the foundational pillar of identity. While Kerberos is robust, its feature set-specifically delegation-introduces a complex web of transitive trust.

For security practitioners, understanding Kerberos delegation is not merely about knowing how authentication works; it is about understanding how an attacker can stitch together a chain of legitimate service permissions to achieve unauthorized privilege escalation.

The Fundamentals: Delegation as a Double-Edged Sword

Kerberos delegation is a mechanism that allows a service to impersonate a user to access a secondary backend resource. Imagine a web application (Service A) that needs to fetch data from a backend database (Service B) on behalf of a logged-in user. To do this, Service A must present a credential to Service B that proves the user has authorized the request.

There are three primary flavors of delegation in Active Directory, each with varying levels of risk:

1. Unconstrained Delegation: The most dangerous form. When a user authenticates to a service configured with unconstrained delegation, their Ticket Granting Ticket (TGT) is sent to the service and stored in memory (LSASS). If an attacker compromises this service, they can extract the TGTs of any user who has recently connected, effectively becoming that user across the entire domain.
2. Constrained Delegation: Introduced to mitigate the risks of unconstrained delegation, this allows an administrator to specify exactly which services a service account can impersonate users to. This is controlled via the `msDS-AllowedToDelegateTo` attribute.
3. Resource-Based Constrained Delegation (RBCD): A more granular approach where the target resource (the backend) specifies which accounts are allowed to delegate to it via the `ms/msDS-AllowedToActOnBehalfOfOtherIdentity` attribute.

The Anatomy of a Delegation Chain

The true complexity-and the primary vector for advanced lateral movement-arises when these delegations are chained. A delegation chain occurs when Service A is permitted to impersonate a user to Service B, and Service B is further permitted to impersonate that same user to Service C.

The vulnerability lies in the S4U (Service for User) extensions, specifically S4U2self and S4U2proxy.

S4U2self and S4U2proxy: The Engine of Impersonation

To understand the chain, one must understand these two extensions:

• S4U2self (Service for User to Self): This allows a service to request a service ticket for itself on behalf of a user, even if that user did not originally authenticate via Kerberos (e.'g., they used NTLM or a web form). This is known as Protocol Transition. Crucially, the service can use this to obtain a service ticket that contains the user's identity, which it then uses to "upgrade" to the next step.
• S4U2proxy (Service for User to Proxy): This allows a service to use the ticket obtained via S4U2self to request a new ticket for a different, downstream service.

An attacker who has compromised a service account configured with Constrained Delegation can use S4U2self to forge a ticket for a high-privilege user (like a Domain Admin) and then use S4U2proxy to present that forged identity to a secondary service. If that secondary service also has delegation rights, the chain continues, potentially reaching a high-value target like a Domain Controller or a sensitive file server.

Practical Example: The Multi-Hop Escalation

Consider the following environment:

1. WebSrv01 (Compromised): A web server running under a service account. It is configured with Constrained Delegation to `SQLSrv01`. It also has the `TrustedToAuthForDelegation` flag (Protocol Transition) enabled.
2. SQLSrv01: A database server. It is configured with Constrained Delegation to `FileSrv01`.
3. FileSrv01: A sensitive file server containing financial records.

The Attack Path:

1. Initial Access: The attacker gains control of `WebSrv01` via a web exploit.
2. S4U2self Forgery: Using a tool like `Rubeus`, the attacker uses the `WebSrv01` service account to perform an S4U2self request. They request a service ticket for `DomainAdmin@WebSrv01` to itself. Because Protocol Transition is enabled, the KDC issues a service ticket for the Domain Admin.

Conclusion

As shown across "The Fundamentals: Delegation as a Double-Edged Sword", "The Anatomy of a Delegation Chain", "Practical Example: The Multi-Hop Escalation", a secure implementation for analyzing kerberos delegation chains for privilege escalation 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 behavior-chain detection across process, memory, identity, and network 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.