Start with Identity

Kerberos delegation abuse

Delegation lets a service act as the user who called it, which is necessary for multi-tier applications and dangerous the moment the service or the delegation scope is not exactly what an administrator intended.

TargetedHard to detect to detect
First observed: 2013ATT&CK T1558

How it works

Kerberos delegation lets a service that a user has authenticated to turn around and act as that user against a second service, which is what makes multi-tier applications work: a web front-end authenticates the user, then needs to query a database or file share as that same user rather than as itself. Active Directory supports this through unconstrained delegation, where a trusted service can obtain a ticket-granting ticket for any user who authenticates to it and use it against any other service, and constrained or resource-based constrained delegation, which narrows that trust to specific named services.

A service configured for unconstrained delegation, or a delegation scope broader than the application actually needs, becomes a high-value target: compromising that one service inherits the ability to act as every user who has ever authenticated to it, against whatever it is trusted to reach. CVE-2025-33073 is a related class of flaw in Windows SMB and Kerberos, where an authentication reflection issue let a client be tricked into authenticating to itself in a way that elevated privilege, later found to be incompletely closed and reachable through an evasion Microsoft termed Ghost SPNs. CVE-2026-27912 (ResetNightmare) is a Kerberos Change Password flaw where the protocol did not check the PAC_REQUESTOR_SID field the rest of Active Directory relies on, letting a low-privileged user who could modify their own User Principal Name reset a Domain Administrator's password. All three are trust-boundary failures in how Kerberos protocols verify who is really asking, rather than password or ticket theft in the conventional sense.

Why it works

Delegation exists because a multi-tier application genuinely needs to act as its caller, and Kerberos has to decide, for every delegation request, whether the requesting service is actually entitled to impersonate that user against that target. The control assumption that fails is that the trust granted to a delegating service is scoped as narrowly as the application's real needs, and that every protocol path that establishes identity, including edge cases like password change and cross-realm requests, enforces the same identity checks the primary authentication path does. Unconstrained delegation configured broadly, or a verification step skipped in a less-scrutinized protocol path like kpasswd, both grant more trust than the application needs, and an attacker only has to find the one service or path where that gap exists.

How to detect it

  • Accounts or computer objects configured for unconstrained delegation, which should be rare and individually justified; any unreviewed instance is a standing finding regardless of whether it has been used maliciously.
  • Ticket-granting ticket requests or reuse patterns inconsistent with a single service's normal call pattern, particularly a service using delegated credentials to reach a target it has no documented business need to reach.
  • Password reset events through the Kerberos Change Password protocol for privileged accounts, correlated against whether the requester's PAC data is consistent with their claimed identity.

Be honest about the limits: delegation is used constantly by legitimate multi-tier applications, and a service authenticating on behalf of many different users throughout a business day is exactly what correctly configured constrained delegation looks like. Distinguishing that from abuse requires knowing which delegation scopes were deliberately approved and why, which most environments do not document well enough to make this detectable from logs alone.

How to stop it

  • Eliminate unconstrained delegation wherever possible, replacing it with resource-based constrained delegation scoped to the specific target services an application actually needs.
  • Treat any service with delegation rights as tier-0 infrastructure, since compromising it inherits the identity of every user who has authenticated through it.
  • Patch the SMB and Kerberos reflection issue behind CVE-2025-33073 and verify the fix holds against the Ghost SPN evasion path, since the first patch alone was shown to be incomplete.
  • Patch the kpasswd PAC_REQUESTOR_SID gap behind CVE-2026-27912 promptly, and restrict which accounts can modify their own User Principal Name, since that write permission is the precondition the flaw depends on.
  • Audit delegation configuration on a recurring schedule, not only at initial deployment, since delegation rights tend to accumulate the same way excess entitlements do elsewhere in the directory. See lateral movement and privilege escalation.

Seen in the wild

Sources

Related identity CVEs and breaches

Last reviewed By SWI Community TeamSuggest a correctionHow we research
Seeing this technique used differently, or have a detection rule that works better? Email [email protected]. See all briefs in the technique catalog, or volunteer as a CVE Analyst.
Mapped to MITRE ATT&CK where a technique ID exists. Independent, community-driven analysis, not a substitute for the ATT&CK knowledge base. See the disclaimer.