Constrained Delegation Abuse – S4U Impersonation

Constrained delegation restricts which services an account can delegate to, unlike unconstrained delegation which allows any service. Accounts with constrained delegation configured use S4U2Self and S4U2Proxy to impersonate users when accessing the allowed services.

If you compromise an account or machine configured with constrained delegation, you can invoke S4U2Self to get a forwardable service ticket for any user, including domain admins, and then S4U2Proxy to present that ticket to the target service. The result is access to the delegated service as any user you choose.

You need the NT hash, AES key, or TGT of the delegation account. Local admin or SYSTEM on the machine is sufficient if it is the delegating host.

Finding Constrained Delegation Accounts

From a Windows foothold with PowerView:

The msds-allowedtodelegateto attribute lists the specific SPNs the account can delegate to. Those are your targets.

Abusing Constrained Delegation with Rubeus

Rubeus runs S4U2Self and S4U2Proxy in a single command. You need the delegation account's hash or TGT and the SPN from its delegation list:

With NT hash:

With AES256 key (more opsec-safe):

With an existing TGT (base64):

/ptt injects the resulting TGS directly. Verify with klist.

Substituting the Service Class

The SPN in msds-allowedtodelegateto specifies both the service class and the host. You can often substitute the service class while keeping the same host, because the target machine validates the host but the KDC does not strictly enforce the service class in the ticket. Use /altservice to request access to a different service on the same host:

This gives tickets for CIFS, HTTP (WinRM), HOST (PsExec), and WSMAN in a single run.

Abusing Constrained Delegation from Linux with Impacket

Request a service ticket impersonating a target user using impacket-getST:

With a hash instead of password:

This saves Administrator.ccache. Use it:

Protocol Transition vs. Without Protocol Transition

Constrained delegation comes in two variants:

With protocol transition (TRUSTED_TO_AUTH_FOR_DELEGATION): the account can call S4U2Self to get a forwardable ticket for any user without that user having a Kerberos session. This is the standard abuse path above.

Without protocol transition: S4U2Self returns a non-forwardable ticket. S4U2Proxy requires a forwardable ticket as input. You need to already have a forwardable TGS for the impersonated user from another source, often obtained via ticket dumping or from another delegation chain.

Check which variant you have:

TRUSTED_TO_AUTH_FOR_DELEGATION in the UAC flags means protocol transition is enabled.