| name | exploiting-constrained-delegation-abuse |
| description | Exploit Kerberos Constrained Delegation misconfigurations in Active Directory to impersonate privileged users via S4U2self and S4U2proxy extensions for lateral movement and privilege escalation. |
| domain | cybersecurity |
| subdomain | red-teaming |
| tags | ["red-team","active-directory","kerberos","constrained-delegation","s4u2proxy","privilege-escalation","lateral-movement"] |
| version | 1.0 |
| author | mahipal |
| 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"] |
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
Most Often Missed & How to Confirm
- Confusing the delegation flavors. Constrained (msDS-AllowedToDelegateTo) vs. constrained + protocol transition (TRUSTED_TO_AUTH_FOR_DELEGATION) vs. RBCD behave differently. Without protocol transition, S4U2self yields a non-forwardable ticket and S4U2proxy fails — check
userAccountControl for the 0x1000000 flag before assuming you can impersonate arbitrary users.
- Impersonating a protected/sensitive account. Targets in "Protected Users" or flagged "Account is sensitive and cannot be delegated" won't be delegatable; pick a different DA-equivalent.
- Missing the altservice trick. The SPN isn't cryptographically bound, so a CIFS ticket can be rewritten to LDAP for DCSync — operators forget
/altservice and assume the path is dead.
- Wrong SPN host format (FQDN vs short name) causing KDC errors.
- How to confirm a hit:
getST.py/Rubeus s4u returns a service ticket for the impersonated user, then that ticket works — KRB5CCNAME=administrator.ccache smbclient.py -k -no-pass lists the DC share, or an ticket drives into a DCSync. Don't conclude the account can't escalate until you've checked for protocol transition and tried the alternate-service-name substitution against a high-value SPN.