Constrained Delegation Abuse: Abusing Constrained Delegation to Achieve Elevated Access

Kerberos Delegation Recap

Previously, I gave an overview of all of the various types of Kerberos delegation, how they’re configured, and how they can potentially be abused. Prior to that, I wrote about abusing resource-based constrained delegation and Jeff Warren has written about abusing unconstrained delegation. To round out the Kerberos delegation topic, I wanted to write a quick blog on how constrained delegation can be abused to get elevated access to a specific configured service. If you’re not familiar with Kerberos delegation, I’d suggest checking out my other post here for an overview.

Constrained Delegation

In case you didn’t read my previous blog, I’ll do a quick overview of the specifics of constrained delegation. More secure than unconstrained delegation, constrained delegation is configured on a computer or user account within Active Directory under the Delegation tab for the object. Constrained delegation allows you to configure which services an account can delegate to, which in theory would limit the potential exposure if a compromise occurred. See the screenshot below:

When constrained delegation is set on an account, two things happen under the covers:

1. The userAccountControl attribute for the object gets updated with the “TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION” flag
2. The msDS-AllowedToDelegateTo attribute gets populated with the SPN configured on the delegation tab (see the screenshot above)

Abusing Constrained Delegation

So 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, in theory, can impersonate any user in the environment to access that service. For example, if constrained delegation is configured to a MSSQL SPN you could get privileged access to the database.

Setting the Stage

Let’s assume the following:

1. I’ve already gained a foothold in an environment
2. I was able to compromise an account with local administrator privileges on a workstation
3. I was able to compromise an account with constrained delegation configured, by using Mimikatz to get the hash of the account that was in memory after a logon.

Beyond having access to the one machine I’ve landed on, and the hash of the account configured with constrained delegation, I have nothing.

Recon

The account I’ve compromised with constrained delegation configured is the ‘notadmin’ account. Let’s see what the constrained delegation is configured for:

Now let’s understand exactly what the SBPMLAB-DC2 host is, even though the name somewhat gives it away. Maybe the group membership of the computer will tell us something.

And would you look at that, the machine this user is able to delegate access to, is a domain controller! Now let’s do some reconnaissance to understand what user we’ll want to impersonate when accessing this service. Let’s see if we can enumerate the members of the Domain Admins group. With the following PowerShell I was able to determine that an account ‘KevinJ’ is a member of Domain Admins:

Get-ADGroup ‘Domain Admins’ | Get-ADGroupMember

So I now have all the pieces I would want to exploit constrained delegation:

1. A compromised account configured with constrained delegation
2. A target privileged account to impersonate when requesting access to the service
3. Information on the machine hosting the service I’ll be gaining access to

Gaining Access

Using a tool like Kekeo I’m able to request the ticket granting ticket for the account with constrained delegation configured, execute the ticket granting service request for the account you want to impersonate, and then access the target service.

To start, you can see below that I currently do not have access to the C$ admin share on the target host.

Using Kekeo, I can request the TGT for the ‘notadmin’ account since I have the NTLM hash:

Now that I have the TGT, I can execute the TGS request for the account I want to impersonate for the target service the ‘notadmin’ account is constrained to.

Switching over to Mimikatz again I am able to pass-the-ticket and gain access to the cifs service on the target host:

As you can see in the screenshot above, I was able to successfully navigate to the C$ admin share on the domain controller after the ticket was imported. If an attacker were able to gain access to the domain controller via CIFS, they could potentially take a copy of the NTDS.dit file and try to gain access to it offline.

Protections

One fool-proof way you can protect yourself from abuse on the various types of delegation (unconstrained, constrained and resource-based constrained) is to put sensitive accounts that should not be delegated in the Protected Users group, or to mark the ‘Account is sensitive and cannot be delegated’ checkbox in Active Directory Users and Computers on the Account tab.

If you’re looking to easily understand where Kerberos delegation is configured in your environment, be sure to check out StealthAUDIT for Active Directory. Reports that highlight where unconstrained and constrained delegation is configured, and what services accounts are constrained to can help you understand what’s out there already and where you can look to reduce risk.