Kerberos delegation flaws expose privilege escalation in Active Directory

At a glance

What this is: Silverfort's analysis of CVE-2025-60704 shows how Kerberos constrained delegation validation flaws in Active Directory can turn controlled impersonation into arbitrary-user impersonation and privilege escalation.

Why it matters: It matters because IAM and PAM teams relying on Active Directory delegation need to treat protocol trust paths as attack surface, not just authentication plumbing.

By the numbers:

• The vulnerability received a CVSS score of 7.5 in Microsoft’s November 11, 2025 update.

Context

Kerberos delegation is a way for a service to authenticate on a user's behalf when it needs to reach another resource. In Active Directory environments, that trust boundary is supposed to stay narrow, but CVE-2025-60704 shows how validation failures can let the delegation path itself become the abuse path.

The issue matters to identity programmes because constrained delegation is often treated as controlled impersonation rather than privileged access. Once an attacker gets initial access with compromised credentials, the protocol can be abused to impersonate other users, escalate privileges, and move laterally inside the domain.

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 on machine accounts create higher-risk escalation paths?

A: Because machine identities often hold authority equivalent to privileged users, delegation on those objects can convert a weak entry point into domain-level control. The risk rises when the identity can reset passwords, replicate directory data, or mediate identity services. That makes delegated computer objects a direct escalation path, not a configuration footnote.

Q: What are the signs that Kerberos delegation is being abused in a Windows domain?

A: Look for services using unconstrained delegation, unexpected delegation flags on service accounts, and tickets being issued for users that should not be delegable. Packet size changes, modified ticket fields, and suspicious S4U2Self or S4U2Proxy activity can also indicate tampering or misuse. In practice, abnormal delegation patterns matter more than a single event because abuse often blends into normal authentication traffic.

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 S4U2Self and S4U2Proxy create the delegation path

Kerberos delegation commonly relies on Service for User to Self, or S4U2Self, and Service for User to Proxy, or S4U2Proxy. S4U2Self lets a service obtain a ticket for a user, while S4U2Proxy lets that service present the ticket to another backend service. That structure is meant to preserve user context across applications without exposing the user's password. In CVE-2025-60704, the problem was not delegation itself but the integrity checks around that chain. If identity binding or reply validation is weak, the service can end up asserting a user context that was not properly constrained by the original authentication flow. Practical implication: treat S4U paths as privileged trust relationships, not ordinary application plumbing.

Practical implication: Treat S4U paths as privileged trust relationships, not ordinary application plumbing.

Where validation failures turn impersonation into escalation

Kerberos depends on cryptographic binding between the request, the ticket, and the key material that proves the exchange is legitimate. When legacy reachable modes allow weaker client-side validation of KDC replies, an attacker positioned in the path can manipulate the trust decision and alter who the service believes it is acting for. That matters because delegation is not just about access to one resource. It becomes an identity substitution mechanism. In the Silverfort analysis, the flaw allowed arbitrary-user impersonation, which is why the impact extends from access abuse into privilege escalation and domain-level compromise. Practical implication: any delegation design that accepts unverified identity assertions becomes a candidate escalation path.

Practical implication: Any delegation design that accepts unverified identity assertions becomes a candidate escalation path.

Why Active Directory delegation widens the blast radius

Active Directory makes Kerberos delegation attractive because many enterprise applications depend on it for backend access, ticket forwarding, and service-to-service interaction. That convenience also means a single validation flaw can reach far beyond one application boundary. If the attacker can impersonate a user through the delegation mechanism, they can pivot toward sensitive resources, broaden access, and potentially inherit higher privilege than intended. The article also notes that the mechanism can be abused for lateral movement, ransomware, and data theft. Practical implication: Active Directory teams should model delegation as a lateral-movement surface and not as a narrowly scoped authentication feature.

Practical implication: Model delegation as a lateral-movement surface and not as a narrowly scoped authentication feature.

Threat narrative

Attacker objective: The attacker aims to swap user identity inside the delegation path and turn that into domain-wide privilege escalation.

1. Entry occurs after initial access with compromised credentials in an environment that has Kerberos delegation enabled.
2. Credential abuse follows when the attacker uses the delegation path and a Man-in-the-Middle position to manipulate S4U validation.
3. Escalation occurs as the attacker impersonates arbitrary or more privileged users and can move laterally across machines.
4. Impact is domain-level control, with possible data theft, impersonation, ransomware, and domain administrator access.

Breaches seen in the wild

• Entra ID actor token flaw (CVE-2025-55241): Hidden Actor tokens plus an Azure AD Graph validation flaw could have let attackers become Global Admin in any Entra ID tenant (CVE-2025-55241).

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 trust was designed for controlled impersonation, not identity substitution. That assumption fails when validation defects let an attacker change who the service is acting for after the trust decision has already been made. The implication is that delegation governance must be treated as a high-risk privilege path, not a convenience feature.

Validation gaps in delegation are effectively privilege-amplification gaps. S4U2Self and S4U2Proxy only remain safe when the identity binding survives every hop in the exchange. Once reply integrity can be weakened, the protocol stops enforcing intended scope and starts enabling arbitrary-user impersonation, which is exactly the kind of failure that turns authentication design into privilege escalation.

Active Directory delegation expands identity blast radius across both human and service contexts. This is not just a Kerberos problem or just an application problem. It is a lifecycle and trust-boundary problem because delegated access can let one compromised credential become many identities, many sessions, and eventually domain-level reach.

Kerberos delegation abuse belongs in the same governance conversation as PAM and lateral movement control. The protocol creates a sanctioned path for one identity to act as another, so the control question is not whether delegation exists but whether its scope is continuously bounded and observable. Practitioners should treat delegation paths as privileged intermediaries with explicit ownership and review.

Identity control planes fail when they assume trust is static after initial authentication. Kerberos delegation shows that the dangerous moment is often after the login, when a service begins to speak for a user. The broader lesson for identity teams is that post-authentication authority must be governed with the same rigor as primary authentication.

What this signals

Kerberos delegation should be treated as a privileged trust boundary, not a convenience layer. The protocol exists to support legitimate impersonation, but its security value depends on identity binding staying intact across each hop. Once that assumption weakens, the control problem shifts from authentication to privilege containment, which is why delegation scope and ownership need explicit governance.

Delegation paths deserve the same lifecycle discipline as privileged accounts. If a service can act on behalf of users, it needs an owner, a review cadence, and a narrow purpose. That is not an application detail, it is identity governance over a high-trust execution path.

For practitioners

• Patch Kerberos delegation flaws immediately Prioritise Windows and Active Directory patching for CVE-2025-60704 in any environment that uses Kerberos constrained delegation, especially where privileged accounts or sensitive backend services are in scope.
• Monitor constrained delegation activity Use ITDR detections to alert on unusual Kerberos constrained delegation flows, including unexpected S4U2Self and S4U2Proxy patterns that could indicate impersonation abuse.
• Inventory delegation paths and owners Map every application and service account that can delegate on behalf of users, then assign an explicit business owner and review cadence for each trust path.
• Reduce the blast radius of delegated identities Limit which services can request delegated tickets, separate high-privilege workloads from general application tiers, and remove delegation where backend access does not genuinely require it.
• Test for impersonation assumptions in legacy modes Validate whether any legacy-reachable Kerberos settings still rely on weaker reply verification or permissive delegation behaviour, then treat those paths as escalation candidates.

Key takeaways

• Kerberos delegation can be abused when validation fails, turning a controlled impersonation feature into a privilege-escalation path.
• Silverfort says the flaw affected Active Directory environments with Kerberos delegation enabled and earned a CVSS score of 7.5.
• Patching, delegation-path inventory, and monitoring of constrained delegation are the practical controls that reduce exposure.

Key terms

• Kerberos Delegation: A Kerberos feature that allows one service to obtain access on behalf of another identity so downstream systems can authorise the call in the original caller’s context. In practice, it expands the trust boundary across tiers and can become a privilege escalation path if the delegated target is sensitive.
• 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.
• Delegated Trust Path: A route into an environment created by an already-approved relationship such as OAuth, service account delegation, or API connectivity. These paths are attractive to attackers because they often inherit trust from the original configuration and can bypass direct user interaction.

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.