ADKERB-008: Protocol Transition Abuse Paths
- Platform
- Active Directory
- Category
- AD Kerberos Security
- Severity
- High
- Zero Trust pillar
- Identity (weight 3)
- Golden fixtures
- 3
- Branch coverage
- Observed: fixtures prove the verdicts they exercise
- Provenance
- baseline
What it checks
The check runs an LDAP query against the domain naming context using a bit-test on userAccountControl: (&(objectCategory=user)(userAccountControl:1.2.840.113556.1.4.803:=16777216)) The matching rule 1.2.840.113556.1.4.803 is LDAP_MATCHING_RULE_BIT_AND. 16777216 (0x1000000) is the TRUSTED_TO_AUTH_FOR_DELEGATION bit (UF_TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION). This bit is the on-disk representation of the "Use any authentication protocol" radio button in the Delegation tab. The query is repeated against computer objects with the same bit-test against (objectCategory=computer). For every match the check captures: sAMAccountName, distinguishedName, objectClass, userAccountControl, msDS-AllowedToDelegateTo, servicePrincipalName, memberOf, adminCount, pwdLastSet, lastLogonTimestamp, msDS-SupportedEncryptionTypes, and whether the account is marked "Account is sensitive and cannot be delegated" (NOT_DELEGATED, 0x100000). Each msDS-AllowedToDelegateTo entry is parsed into service class and target host so the analyst can immediately see what services on what hosts the account can impersonate any user to. The check explicitly flags any delegation target whose host portion resolves to a domain controller, an AD CS server, an Exchange server, or an account tagged in the Protected Users group, because those targets convert a delegation primitive into a domain-compromise primitive.
Why it matters
Standard Kerberos Constrained Delegation (KCD) without protocol transition (the "Use Kerberos only" radio button, msDS-AllowedToDelegateTo populated but T2A4D not set) still requires the user to have presented a forwardable TGT to the front-end service before the front-end can call S4U2Proxy. Protocol transition removes that requirement. With T2A4D set, the account can call S4U2Self with any username in the domain (the KDC trusts the PA-FOR-USER structure on the basis of the requesting account having the T2A4D flag, not on any proof that the named user authenticated) and the KDC returns a forwardable service ticket. That ticket is then fed into S4U2Proxy to obtain a TGS to any SPN listed in msDS-AllowedToDelegateTo. The net effect: any attacker who compromises the long-term key of the delegating account (RC4 hash, AES key, password, or a TGT for the account) can immediately impersonate the Domain Admin, the krbtgt, or any other user to any service in the allow-list. There is no second-factor, no password prompt, no event indicating the named user did anything. The blast radius is the union of every users authorization on every service in msDS-AllowedToDelegateTo. When the allow-list contains LDAP/dc01, HOST/dc01, or CIFS/dc01, the path is direct DCSync or remote command execution on a domain controller as Domain Admin. When it contains HTTP/cs01 on an AD CS Enterprise CA, the path leads to certificate enrollment as any principal (chains with ESC1/ESC6/ESC8). When it contains MSSQL/sqlprod, the path leads to credential extraction from linked-server contexts. Crucially, the standard sensitivity protections only fire when the target user is in Protected Users or has the NOT_DELEGATED bit (0x100000) set. Default-built domains have neither protection on Domain Admins or service accounts, which is why protocol-transition delegation paths are a top-five finding in nearly every BloodHound collection against an enterprise forest.
Attack path
1. Discover the delegating account. The attacker enumerates accounts with T2A4D set using the same LDAP bit-test the check uses, or runs BloodHound which surfaces the AllowedToDelegate edge with the protocol-transition flag in node properties. Example: Get-ADObject -LDAPFilter "(userAccountControl:1.2.840.113556.1.4.803:=16777216)" -Properties userAccountControl, msDS-AllowedToDelegateTo, servicePrincipalName. 2. Compromise the delegating account. Any of the standard credential-access primitives apply: Kerberoasting if the account has an SPN (ADKERB-002), AS-REP roasting if pre-auth is disabled (ADKERB-003), ACL abuse via GenericAll/GenericWrite/WriteDACL on the account object (ADACL family), password spraying, or extraction from a compromised host where the account has logged on. The attacker needs the accounts password, NTLM hash, AES key, or a TGT. 3. Request a forwardable S4U2Self ticket for a high-value target. With Rubeus: Rubeus.exe s4u /user:svc_delegated /rc4:<NTLM> /impersonateuser:Administrator /msdsspn:CIFS/dc01.corp.contoso.com /ptt. With Impacket: getST.py -spn CIFS/dc01.corp.contoso.com -impersonate Administrator corp.contoso.com/svc_delegated:<password>. Because T2A4D is set, the AS-REP from S4U2Self carries the forwardable flag without any proof that Administrator authenticated. Rubeus then automatically chains S4U2Proxy to issue a TGS for CIFS/dc01 as Administrator. 4. Use the impersonated ticket. With the TGS injected (/ptt or kirbi loaded), the attacker accesses the target service as the impersonated user: dir \\dc01.corp.contoso.com\C$, secretsdump.py -k -no-pass dc01.corp.contoso.com, or psexec.py -k -no-pass dc01. The DC sees an authenticated Administrator session; there is no failed-logon event for Administrator, no NTLM authentication, no password prompt anywhere on the wire. 5. Escalate. If the allow-list contains LDAP/dc01, the same flow produces a TGS that secretsdump uses for DCSync of krbtgt. From krbtgt the attacker forges a Golden Ticket (ADKERB-004) and obtains permanent, domain-wide access. If the allow-list contains HTTP/ca01 on an AD CS server, the attacker chains to ESC8/ESC11 to enroll a certificate as a Domain Admin (ADCS family). If the allow-list contains MSSQL/sqlprod, the attacker pivots into the database with sysadmin context. 6. Persist. The delegating account itself becomes a persistence vector: as long as it retains T2A4D and the allow-list, every credential rotation upstream is irrelevant. Mature operators add a new SPN to a low-noise computer object and grant it AllowedToActOnBehalfOfOtherIdentity on a target (resource-based constrained delegation, ADKERB-009) to mirror the same primitive on a different account.
How Guerrilla assesses it
Guerrilla performs a single LDAP bit-test query against every domain in the forest, scoped to both user and computer objects. The filter is: (&(|(objectCategory=user)(objectCategory=computer))(userAccountControl:1.2.840.113556.1.4.803:=16777216)) The LDAP_MATCHING_RULE_BIT_AND OID against userAccountControl with the value 0x1000000 (16777216) matches every object with the TRUSTED_TO_AUTH_FOR_DELEGATION bit set. This is the identical predicate that BloodHound, PowerView (Get-DomainUser -TrustedToAuth), and ADRecon use, and is equivalent to the AD PowerShell module call Get-ADObject -Filter {TrustedToAuthForDelegation -eq $true}. For each match the check pulls msDS-AllowedToDelegateTo and parses each entry into service-class and host components. It then performs a second LDAP lookup against each target host to determine whether the host is a domain controller (member of Domain Controllers, or DC=Configuration container holds an NTDS Settings child), an AD CS server (registered as an Enterprise CA in CN=Configuration), an Exchange server, or a tier-zero asset by tag. Each delegating account is ranked: HIGH if any target is a DC or holds an Enterprise CA role, MEDIUM if any target is Exchange or a tier-one server, LOW otherwise. The check requires only authenticated LDAP read of the domain NC; no elevated rights are needed, which mirrors the attacker view.
Recommended value
Protocol transition (TrustedToAuthForDelegation) disabled on all accounts unless explicitly required and documented. No protocol transition accounts that can delegate to domain controller services
Remediation
Identify accounts with protocol transition using Get-ADObject -Filter {TrustedToAuthForDelegation -eq $true} -Properties TrustedToAuthForDelegation,msDS-AllowedToDelegateTo. For each account, evaluate whether protocol transition is truly required (only needed when the initial authentication does not use Kerberos). Disable protocol transition where not needed. For remaining accounts, strictly limit the delegation targets and ensure no DC services are in scope
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
- CIS AD Benchmark
- 7.3.5
- MITRE ATT&CK
- T1550.003