Kerberos delegation flaws expose privilege escalation in Active Directory

At a glance

What this is: This analysis examines CVE-2025-60704, a Kerberos constrained delegation flaw that could let an attacker impersonate arbitrary users and escalate privileges in Active Directory environments.

Why it matters: It matters because identity teams must treat delegation paths as high-risk control boundaries, not just authentication plumbing, across human, NHI, and hybrid identity programmes.

By the numbers:

• As part of responsible disclosure, our research team reported the Kerberos constrained delegation vulnerability to Microsoft, and on November 11, 2025 they issued an update as part of Patch Tuesday, where it received a CVSS score of 7.5.

👉 Read Silverfort's analysis of CVE-2025-60704 and Kerberos delegation abuse

Context

CVE-2025-60704 is a Kerberos constrained delegation flaw in Windows Active Directory that breaks a core identity assumption: delegation is supposed to extend access in a controlled way, not let an attacker change who they are mid-flow. For identity teams, that makes Kerberos delegation a governance boundary, not just an authentication feature.

The security problem is not delegation itself. The problem is that validation failures in S4U2Self and S4U2Proxy can turn a legitimate trust mechanism into a privilege escalation path. That is relevant to human IAM, service account governance, and any environment where applications act on behalf of users across trust domains.

Key questions

Q: What breaks when Kerberos delegation validation is weakened?

A: When Kerberos delegation validation is weakened, attackers can manipulate the identity carried through the delegation path and cause a system to accept a different user than intended. That turns constrained delegation from a controlled impersonation mechanism into a privilege escalation route that can support lateral movement and broader domain compromise.

Q: Why does Kerberos delegation create such a large risk in Active Directory?

A: Kerberos delegation matters because Active Directory uses it as a core trust mechanism for applications acting on behalf of users. If the delegation chain can be altered, the blast radius is not limited to one application. It can extend to privileged accounts, domain admin access, and other connected systems.

Q: How do security teams know whether delegation paths are too risky?

A: Delegation paths are too risky when they are broadly enabled, poorly monitored, and reachable through legacy validation behaviour. Teams should look for systems that rely on delegated tickets, service accounts with wide reach, and unusual impersonation activity. Those are signs that the trust boundary is larger than the programme assumes.

Q: Who is accountable when a Kerberos delegation flaw leads to domain compromise?

A: Accountability sits with the teams responsible for patching, identity governance, and detection across Active Directory and dependent applications. If delegated access is not inventoried, monitored, and remediated quickly, the organisation is effectively accepting a domain-wide trust risk that a single flaw can exploit.

Technical breakdown

How S4U delegation normally binds identity to a request

Kerberos delegation uses Service for User to let a service obtain a ticket on behalf of a user. In a healthy flow, S4U2Self first gets a service ticket for the user, then S4U2Proxy exchanges that for access to a backend resource. The security model depends on the client and the KDC preserving the binding between the original identity, the delegated identity, and the resulting ticket. When that binding is validated correctly, delegation extends trust without letting the service invent a new identity.

Practical implication: review every place where applications rely on delegated Kerberos tickets and treat those paths as privileged trust zones.

Why validation flaws turn constrained delegation into privilege escalation

CVE-2025-60704 emerged from weaknesses in how S4U identity was cryptographically bound to a request and how the client validated KDC reply integrity in legacy reachable modes. If an attacker can interfere in the middle, they can tamper with the delegation path and cause the recipient to accept a different identity than intended. That is why this class of flaw is dangerous: it does not merely expose a ticket, it breaks the identity proof carried by the ticket itself.

Practical implication: prioritise patching and telemetry on any legacy-reachable Kerberos delegation flow where reply integrity is not strongly enforced.

How Active Directory expands the blast radius of delegation abuse

Active Directory makes Kerberos delegation a broad enterprise control plane, which is why the impact of a single validation flaw is so large. Once a delegated identity can be altered, attackers can pivot from one application context into broader lateral movement, impersonate more privileged users, and in the worst case reach domain-admin level access. The architecture assumes the delegation chain is trustworthy. When that assumption fails, the blast radius is not local to one application but spreads across the domain.

Practical implication: map Kerberos delegation paths to business-critical systems and monitor them as potential domain-wide escalation routes.

Threat narrative

Attacker objective: The objective is to convert a single compromised foothold into arbitrary user impersonation, lateral movement, and ultimately domain-wide control.

1. Entry occurs when an attacker gains initial access to an Active Directory environment with compromised credentials and can interact with Kerberos delegation.
2. Escalation happens through man-in-the-middle manipulation of S4U2Self and S4U2Proxy validation so the attacker can impersonate a different user than intended.
3. Impact follows as the attacker moves laterally, impersonates privileged accounts, and can reach domain-admin level control over the environment.

Breaches seen in the wild

• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Kerberos delegation validation is a governance boundary, not just a protocol detail. The article shows that the trust model behind S4U delegation can be subverted when identity binding and reply integrity are not enforced tightly enough. That means the control gap is not simply missing patching, it is treating delegation as safe by default. Identity teams should classify delegated Kerberos paths as high-risk trust infrastructure, not routine authentication plumbing.

Ticket binding assumptions fail when an attacker can alter who the delegation flow says the user is. S4U2Self and S4U2Proxy were designed for controlled impersonation, where the application acts only within an authorised identity envelope. That assumption fails when a man-in-the-middle can manipulate the exchange and cause the system to accept a different principal. The implication is that access governance built on stable identity assertions loses reliability the moment the assertion itself can be rewritten.

Delegated identity drift: Kerberos delegation becomes an escalation primitive when the actor can switch from one identity to another inside the same trust path. That is the specific failure mode this research exposes. It is not a generic authentication weakness, but a break in the premise that delegated access remains identity-bound from start to finish. Practitioners should treat this as proof that trust-path integrity must be governed like privileged access.

This flaw widens the identity blast radius across human and machine accounts. The article notes that the same delegation capability can apply to applications acting on behalf of users and, by extension, to service-account-driven flows in enterprise environments. When identity proof collapses in the delegation layer, both human IAM and NHI governance inherit the same exposure pattern. Security programmes should therefore review delegated access as a shared risk surface across actor types, not as separate silos.

Patchable protocol flaws still expose structural dependency on legacy-reachable modes. The research makes clear that older reachable behaviour in Kerberos validation remains a meaningful attack surface even in modern environments. That creates a durable lesson for identity architecture: legacy compatibility often survives as latent trust debt. Organisations should treat such pathways as a lifecycle problem, not a one-off bug fix.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
• From our research: Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• For the broader control picture, The 52 NHI breaches Report helps teams connect weak lifecycle governance to real-world compromise patterns.

What this signals

Delegated identity drift: organisations should expect identity programmes to face more attack paths where the identity itself is changed inside the trust flow, not merely stolen at the edge. That shifts the focus from authentication success to trust-path integrity, which is a different governance problem entirely.

The programme implication is straightforward. If your Active Directory estate still depends on legacy Kerberos delegation without tight monitoring, you should assume the blast radius includes both human identity abuse and machine-account abuse. That is why identity lifecycle controls, privileged access review, and ITDR need to be aligned before attackers find the gap.

Teams should also treat this as a signal that protocol compatibility can outlive the security assumptions it was built on. As environments modernise, the harder question is not whether a control works in isolation, but whether it still holds when an attacker can alter identity inside the session.

For practitioners

• Patch Kerberos delegation paths first Apply Microsoft fixes to all Active Directory environments using Kerberos delegation and prioritise systems where S4U flows are exposed to business-critical applications.
• Alert on constrained delegation usage Set up ITDR detection for all Kerberos constrained delegation activity, especially where impersonation events or unusual ticket exchange patterns appear.
• Inventory legacy-reachable delegation modes Catalogue where legacy-reachable Kerberos reply validation still exists and remove or isolate those pathways before attackers can manipulate identity binding.
• Map delegated trust to domain risk Tie each delegated service to the identities and resources it can reach so you can see which paths could turn a single compromise into broader lateral movement.
• Review service accounts that depend on impersonation Check application and service-account workflows that rely on impersonation so you can identify where a delegation flaw could rewrite the effective user identity.

Key takeaways

• CVE-2025-60704 shows that Kerberos delegation can become an escalation path when identity validation fails inside the trust flow.
• The impact is broad because Active Directory delegation can turn a local compromise into impersonation, lateral movement, and domain-level control.
• The most relevant control is rapid patching plus delegated-access monitoring, because the flaw exploits broken trust-path integrity rather than weak passwords.

Key terms

• Kerberos Constrained Delegation: A Kerberos pattern that lets a service act on behalf of a user, but only to specified downstream resources. It is used when applications need delegated access without sharing the user's credentials. In practice, its security depends on identity binding and reply validation staying intact throughout the exchange.
• S4U2Self: The Kerberos step where a service requests a ticket for a user without needing the user's password. It is part of delegated authentication flows and is meant to preserve controlled impersonation. If this step is not validated correctly, the identity asserted in the ticket can be abused or altered.
• S4U2Proxy: The Kerberos step where a service exchanges a user ticket for access to a backend resource on that user's behalf. It is how constrained delegation extends trust to another service. Security teams must treat it as a privileged trust decision because it can become an escalation point if validation fails.
• Identity Trust Path: The full chain of identity checks, ticket exchanges, and policy decisions that proves who a user or service is across systems. In delegated environments, the trust path is as important as the final authentication result. When that path can be manipulated, the resulting access can no longer be assumed reliable.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Silverfort covering CVE-2025-60704: validation flaws in Windows Kerberos S4U from protocol transition to privilege escalation. Read the original.