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.
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
- Windows SMB Kerberos reflection elevation of privilege
- ResetNightmare, kpasswd bypasses PAC_REQUESTOR_SID
Sources
Related identity CVEs and breaches
Related on Start with Identity
- CVEOkta Verify for Windows local privilege escalation
Okta Verify on Windows could be turned into a local privilege escalation. The MFA app on the endpoint is part of the identity plane. Pair with Okta's 2024 FastP
- CVEVault root privilege escalation via policy-name normalization
Vault normalized policy names in a way that let a lower-privilege token become root. CVSS 7.2. Part of the August 2025 VaultFault set.
- TechniqueAD CS certificate template abuse
A certificate template with permissive enrollment rights or a misconfigured extension turns Active Directory Certificate Services into a path to domain compromi
- CVECheckSum, Kerberos S4U missing cryptographic step
The KDC skipped a cryptographic step in PA-S4U-X509-USER (CWE-325). An attacker can forge an identity via S4U2self and escalate to domain compromise. Presented
- TechniqueFederation trust abuse and SAML forgery
A service provider that accepts a SAML assertion it should have rejected treats a forged identity as authenticated, because the failure sits in signature valida
- BlogJalisco and OmegaLord: phishing kits built around device-code abuse
ReliaQuest found two Microsoft 365 phishing kits. Jalisco abuses the OAuth device authorization grant, generating fresh codes in real time to beat the 15-minute