ADKERB-005: Unconstrained Delegation - Users
- Platform
- Active Directory
- Category
- AD Kerberos Security
- Severity
- Critical
- Zero Trust pillar
- Identity (weight 2)
- Golden fixtures
- 3
- Branch coverage
- Observed: fixtures prove the verdicts they exercise
- Provenance
- baseline
What it checks
The check binds to the default naming context and issues an LDAP query (&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=524288)) which matches user objects whose userAccountControl bit 0x80000 (TRUSTED_FOR_DELEGATION, also known as ADS_UF_TRUSTED_FOR_DELEGATION) is set. For each match it captures sAMAccountName, distinguishedName, servicePrincipalName, userAccountControl, pwdLastSet, lastLogonTimestamp, adminCount, primaryGroupID, memberOf, and the nTSecurityDescriptor. The check explicitly excludes computer objects (those are evaluated by ADKERB-004) and explicitly includes msDS-GroupManagedServiceAccount and msDS-ManagedServiceAccount objects, since those classes derive from user. It also cross-references the account against Protected Users group membership and the NOT_DELEGATED flag (0x100000), because either of those should have prevented delegation from being meaningful in the first place. The presence of any matching record is treated as a finding; there is no benign threshold.
Why it matters
Unconstrained delegation grants the service running under the account a copy of every authenticating user TGT. With a computer account the attacker must first gain SYSTEM on that host, which usually requires admin rights. With a user account the attacker only needs the user password or NTLM hash, which can be obtained via Kerberoasting if the account has an SPN, via password spray, via help-desk reset abuse, via the GPP cpassword vulnerability, via DPAPI, or via phishing. Once the attacker can log on as the delegated user and stand up a service under that identity, they wait for or coerce an authentication from a high-privilege principal. Coercion is trivial in default AD environments: MS-RPRN (PrinterBug), MS-EFSR (PetitPotam), MS-DFSNM (DFSCoerce), and MS-FSRVP (ShadowCoerce) all force a target computer to authenticate to an attacker-chosen UNC path with the computer account TGT. Targeting a Domain Controller via this primitive yields a DC machine account TGT, which can be used immediately for DCSync (replicating directory changes), producing a krbtgt hash and a Golden Ticket. The blast radius is the entire forest, and the time from initial user compromise to Domain Admin is measured in minutes.
Attack path
Step 1: Discovery. The attacker, holding any authenticated foothold, runs Get-ADUser -Filter {TrustedForDelegation -eq $true}, or BloodHound MATCH (u:User {unconstraineddelegation:true}) RETURN u, or PowerView Get-NetUser -Unconstrained, to list user accounts with TRUSTED_FOR_DELEGATION set. ADKERB-005 surfaces the same set. Step 2: Account compromise. The attacker obtains credentials for the delegated user. Common paths: Kerberoast the account if it has a servicePrincipalName (Rubeus kerberoast), password spray weak passwords, abuse a stale help desk reset right, recover the password from a GPP XML file (MS14-025), or harvest from a phishing payload. Step 3: Service registration. The attacker registers a servicePrincipalName under the compromised user account if one is not already present (setspn -A HTTP/attacker.contoso.local svc_delegated). The SPN is required so that other principals can request service tickets against the account. Step 4: Coercion. The attacker triggers an authentication from a high-value computer (typically a Domain Controller) to the SPN they control. Tools: PetitPotam.py DC01 ATTACKER for MS-EFSR, SpoolSample.exe DC01 ATTACKER for MS-RPRN, dfscoerce.py for MS-DFSNM, Coercer for an aggregate sweep. The target DC authenticates to the attacker SPN with its machine account TGT. Step 5: TGT extraction. The attacker, logged on interactively or via WMI/PSRemoting as the delegated user, runs Rubeus monitor /interval:1 or Rubeus harvest, or executes mimikatz sekurlsa::tickets /export, and captures the DC TGT that was forwarded into LSASS as part of the unconstrained delegation handshake. Step 6: Pass the ticket. The attacker injects the DC TGT into a new logon session with Rubeus ptt /ticket:DC01.kirbi or mimikatz kerberos::ptt DC01.kirbi. Step 7: DCSync. With the DC machine account context the attacker runs mimikatz lsadump::dcsync /user:DOMAIN\krbtgt to retrieve the krbtgt NTLM hash, then forges a Golden Ticket (Rubeus golden /user:Administrator /rc4:<krbtgt hash> /sid:<domain SID> /domain:contoso.local /ptt) and has persistent Domain Admin equivalent access across the forest.
How Guerrilla assesses it
Guerrilla performs an authenticated LDAP search against the default naming context using the bitwise AND OID 1.2.840.113556.1.4.803 to evaluate the TRUSTED_FOR_DELEGATION bit (decimal 524288, hex 0x80000) in userAccountControl. The filter (&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=524288)) returns only user-class objects, deliberately excluding computer objects which are covered by ADKERB-004. For each returned object the check pulls userAccountControl, servicePrincipalName, memberOf, adminCount, pwdLastSet, lastLogonTimestamp, and nTSecurityDescriptor. The collected attributes are used to enrich the finding with whether the account has an SPN (and is therefore Kerberoastable), whether it is Tier 0 by adminCount or group membership, the age of the password (a stale password compounds the risk), and which non-default principals hold write rights on the object. The check then cross-references Protected Users group membership and the NOT_DELEGATED bit (0x100000) on the account, since either should have stopped delegation use; their absence is logged as additional context but does not change the finding (the flag itself is the issue). No event log is required for the primary detection because the misconfiguration is a persistent directory state, not an event.
Recommended value
No user accounts with unconstrained delegation. All user account delegation migrated to constrained or resource-based constrained delegation
Remediation
Identify users with unconstrained delegation using Get-ADUser -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation. This is almost never a legitimate configuration for user accounts. Remove the unconstrained delegation flag and configure constrained delegation to specific services if delegation is required. Rotate the account password immediately as the account may have been targeted
Fixture-proven verdicts
Every verdict below is proven by a golden fixture in the module's gating test suite. This table derives from the last green run; it cannot be edited by hand.
| Scenario | Expected verdict |
|---|---|
| clean | PASS |
| known-bad | FAIL |
| throttled | Not Assessed |
Framework mappings
- NIST SP 800-53
- AC-6
- ANSSI
- R35
- CIS AD Benchmark
- 7.3.2
- MITRE ATT&CK
- T1558.001