Constrained Delegation

Breaking down, arguably the most complex of the three delegation type attacks
kerberos-constrained-delegation-kcd-l

Constrained delegation allows you to configure which services an account can delegate to, which can possible 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 in the domain.
  • The msDS-AllowedToDelegateTo attribute contains the SPNs that are allowed to user (S4u2proxy), meaning that a service account obtain 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 compromise 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:[email protected] /outfile:constrained-user.kirbi

TextDescription automatically generated

Using 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 impersonate a TGS ticket for 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, 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.

Share on social media

Share on linkedin
Share on facebook
Share on twitter

Get A Service Quote

Stay Connected

Test the effectiveness of your security controls before malicious parties do.
We pride ourselves on being unique and thorough.
We understand the need of your organisation and yours too.​

Social & Contact INFO

Drop us a message