Kerberos delegation abuse

Kerberos delegation abuse is the use of Active Directory's delegation settings, or flaws in the protocol paths that implement them, to impersonate a privileged user against services that trust the delegating account. Delegation exists so a web front end can query a database as the signed-in user. An attacker who controls an account trusted for delegation, or who can write the attribute that grants it, inherits that impersonation power. Microsoft Defender for Identity describes the risk of unsecure delegation bluntly: "the possibilities with unsecure delegation are nearly endless."

How it works

Active Directory has three delegation models, and each fails differently.

A common RBCD chain runs like this:

1. Write access. The attacker obtains a write right on a target computer object through an ACL misconfiguration or a relayed authentication.
2. An account with an SPN. They create or compromise an account they hold the key for.
3. Grant delegation. They add that account to the target's allowed-to-act list.
4. S4U2self, then S4U2proxy. They request a ticket for an administrator to themselves, then forward it to the target's services. Microsoft's own documentation notes that with RBCD "the KDC always allows protocol transition," so the administrator never has to authenticate.
5. Use it. Administrative access to the target, which may be a server that holds further credentials.

Microsoft moved control of constrained delegation to the resource owner in Windows Server 2012 for good reasons, but that shifted the decision to whoever can write the resource's attribute.

Protocol flaws on the same paths make the configuration question worse. CVE-2025-60704 (CheckSum) was a KDC that skipped a cryptographic step in PA-S4U-X509-USER on the S4U2self path, letting an attacker forge the identity being impersonated; Microsoft rated it Important (CVSS 7.5). CVE-2025-33073 was a Kerberos authentication reflection against SMB that let a client be tricked into authenticating to itself with elevated rights; CISA added it to the Known Exploited Vulnerabilities catalog on October 20, 2025. CVE-2025-58726 showed the reflection still worked through Ghost SPNs created by DNS self-registration. CVE-2026-27912 (ResetNightmare) is a Kerberos change-password flaw where kpasswd did not check PAC_REQUESTOR_SID, letting a user who could modify their own UPN reset a Domain Admin's password. All four are failures in how Kerberos verifies who is really asking.

Why it works

Delegation is a standing grant of impersonation. The control assumption that fails is that the grant is scoped as narrowly as the application needs and that only administrators can change it. Unconstrained delegation fails the first by design: any user who authenticates to the host leaves a reusable TGT behind, including a domain controller that an attacker coerces into connecting. RBCD fails the second whenever ordinary write rights on computer objects are broader than anyone realizes. A second assumption, that every protocol path enforces the same identity checks as the main ticket path, failed four times in 2025 and 2026 in the edge paths (S4U2self, SMB reflection, kpasswd) that receive less scrutiny. Privileged accounts are only safe if they are marked as unable to be delegated, and many are not.

How to detect it

• Delegation changes. Event 4742 ("A computer account was changed") shows a new AllowedToDelegateTo list and changes to the 'Trusted For Delegation' and 'Trusted To Authenticate For Delegation' account control flags; Microsoft recommends investigating every such change to confirm it was approved. RBCD writes do not appear in 4742's field list, so audit msDS-AllowedToActOnBehalfOfOtherIdentity with Directory Service Changes auditing (event 5136) and a SACL on computer objects.
• S4U in ticket requests. Event 4769 carries a Transited Services field listing the SPNs involved when constrained delegation was used. Delegated tickets for Domain Admins, or delegation by an account with no history of it, deserve a look.
• Configuration inventory. Defender for Identity's "Unsecure Kerberos delegation" and "Ensure privileged accounts are not delegated" posture assessments list non-domain-controller accounts with unconstrained delegation and privileged accounts missing the sensitive flag. An unreviewed unconstrained host is a finding whether or not it has been abused.
• Coercion. Inbound authentication from a domain controller to a non-DC host with unconstrained delegation, which is how the TGT gets captured.
• kpasswd resets of privileged accounts where the requester is not the account owner or a help desk role.

The gap is that delegation is meant to impersonate users all day. Distinguishing abuse requires knowing which grants were approved and why, which most environments have never written down, so start by building that inventory.

How to stop it

Ranked by effect:

1. Mark every privileged account "Account is sensitive and cannot be delegated" (NOT_DELEGATED), or add human administrators to Protected Users, whose members cannot be delegated with unconstrained or constrained delegation and cannot use RC4. Never add service or computer accounts to Protected Users. This makes the most valuable targets unimpersonatable regardless of misconfiguration elsewhere.
2. Eliminate unconstrained delegation on everything except domain controllers, replacing it with constrained delegation or RBCD scoped to the exact target services.
3. Lock down who can write computer objects and the delegation attributes, and remove inherited write ACLs that nobody can justify.
4. Patch the Kerberos train: CVE-2025-60704, CVE-2025-33073 together with CVE-2025-58726, and CVE-2026-27912. Restrict UPN self-write and insecure dynamic DNS updates, which those flaws depend on.
5. Treat any account trusted for delegation as tier zero, and re-audit delegation on a schedule, because grants accumulate like any other entitlement. See lateral movement, privilege escalation, and Kerberoasting, which often supplies the service account key that constrained delegation abuse needs.

Seen in the wild

No incident in the SWI Identity Breach Database is attributed to delegation abuse in a victim's or responder's published account. The evidence of real-world use is the vulnerability record:

• Windows SMB Kerberos reflection elevation of privilege, on CISA's Known Exploited Vulnerabilities catalog since October 20, 2025.
• SMB Server Kerberos reflection via Ghost SPNs
• CheckSum, Kerberos S4U missing cryptographic step
• ResetNightmare, kpasswd bypasses PAC_REQUESTOR_SID

Delegation abuse usually appears in incident timelines as a step after initial access, which is why it is rarely named in public disclosures.

Sources

• MITRE ATT&CK T1558: Steal or Forge Kerberos Tickets. ATT&CK has no sub-technique specific to delegation, so this brief maps to the parent.
• Microsoft: Kerberos constrained delegation overview
• Microsoft: Protected Users security group
• Microsoft Defender for Identity: accounts security posture assessments
• Microsoft: 4742(S) A computer account was changed
• Microsoft: 4769(S, F) A Kerberos service ticket was requested
• CISA: Known Exploited Vulnerabilities catalog