PW-005Attack pathControl and privilege paths

Unconstrained delegation outside domain controllers

A server or account that isn't a domain controller is trusted to impersonate anyone who connects to it, anywhere.

Category: Attack Path
Severity: At least High.
Typical owner: AD / identity team with the server or application owner
Data needed: Any collection: the delegation setting is part of each computer and user object.

Most useful toDefensive engineers Identity and access engineers Offensive operators

On this page

In plain language

Delegation lets a service act on a user's behalf: a web server fetching a user's files from a file server, for instance. The oldest and broadest form, unconstrained delegation, has each connecting user leave a reusable Kerberos ticket on the server.

If an attacker controls such a server, they can make a domain controller connect to it and capture the domain controller's own ticket, then use it to take over the domain. That makes the server as sensitive as a domain controller. Modern constrained and resource-based delegation do the legitimate job without this risk.

What Pathwarden flags

A computer or user that is not a domain controller is "trusted for delegation to any service" (unconstrained delegation). Every account that authenticates to it with Kerberos leaves a forwardable ticket (TGT) in its memory. That makes the computer as sensitive as a domain controller.

How attackers use it

An attacker with admin rights on the computer coerces a domain controller to authenticate to it (PrinterBug / MS-RPRN, PetitPotam / MS-EFSR), captures the DC's TGT from memory and uses it to DCSync the domain (Steal or Forge Kerberos Tickets, T1558). No credentials of the victim DC are needed; only control of this computer.

Find it with Pathwarden

Data needed: Any collection: the delegation setting is part of each computer and user object.

In the web UI or the HTML report, open the Findings tab and expand PW-005: each finding shows who can use it (its exposure), the attack path drawn out, the affected objects, and the fix. The remediation path tells you whether a single plan step closes it. On the command line:

Shell

# every finding of this rule, with its path and fix
pathwarden findings -i .\collect --rule PW-005
# the step-by-step guide on this page, offline
pathwarden guide PW-005
# after the fix: collect again, then check it is gone
pathwarden retest -i .\collect-after --rule PW-005

Exit codes make retest easy to script: 0 Fixed, 1 Still open, 3 Can't tell. See findings lifecycle and retest.

Before you change anything

Ask the application owner why delegation was enabled. Common legacy reasons: IIS or SQL Server front ends that access back-end services as the user.
Identify which back-end services the computer must delegate to (SPNs). Kerberos service ticket events 4769 on domain controllers with this computer as the requesting service show what it actually requests.
Constrained or resource-based constrained delegation (RBCD) supports nearly all such scenarios; plan the replacement before removing the flag.

How to fix it

Option A: Switch to constrained delegation (recommended)

Active Directory Users and Computers > the computer (or service account) > Properties > Delegation.
Select Trust this computer for delegation to specified services only, then Use Kerberos only where possible.
Add only the back-end services (SPNs) the application needs, OK.

Option B: Remove delegation entirely

If nothing needs it, select Do not trust this computer for delegation.

Option C: Resource-based constrained delegation

Configure delegation on the back-end resource instead (its PrincipalsAllowedToDelegateToAccount), which keeps control with the resource owner.

Until unconstrained delegation is removed, treat the computer as Tier Zero, with the same administrative controls and monitoring as domain controllers. Turn off the Print Spooler on domain controllers where you can, against coercion through the print service (PrinterBug). Keep domain controllers up to date against other coercion such as PetitPotam.

PowerShell

Import-Module ActiveDirectory

# Find all non-DC accounts with unconstrained delegation
Get-ADComputer -Filter { TrustedForDelegation -eq $true -and PrimaryGroupID -ne 516 -and PrimaryGroupID -ne 521 } -Properties TrustedForDelegation
Get-ADUser -Filter { TrustedForDelegation -eq $true } -Properties TrustedForDelegation

# Remove unconstrained delegation from one computer
Set-ADAccountControl -Identity "<Computer>$" -TrustedForDelegation $false

# Optional: constrained delegation to a specific back-end service
Set-ADComputer -Identity "<Computer>" -Add @{ 'msDS-AllowedToDelegateTo' = 'MSSQLSvc/<backend>.<domain>:1433' }

# Resource-based alternative, set on the back-end computer
Set-ADComputer -Identity "<BackendComputer>" -PrincipalsAllowedToDelegateToAccount (Get-ADComputer "<Computer>")

Verify the fix

Get-ADComputer "<Computer>" -Properties TrustedForDelegation must show False. Test the application end to end as a normal user. Collect again (or use Retest on the finding) and confirm the finding ID is gone.

Roll back

Set-ADAccountControl -Identity "<Computer>$" -TrustedForDelegation $true restores the previous setting. Clear any added constrained delegation with Set-ADComputer "<Computer>" -Clear msDS-AllowedToDelegateTo.

References

Microsoft: Kerberos constrained delegation overviewlearn.microsoft.com
SpecterOps BloodHound docs: CoerceToTGTbloodhound.specterops.io
SpecterOps: Hunting in Active Directory: unconstrained delegation and forest trustsspecterops.io
MITRE ATT&CK T1558: Steal or Forge Kerberos Ticketsattack.mitre.org
MITRE ATT&CK T1187: Forced Authenticationattack.mitre.org