Unconstrained Delegation Permissions

Unconstrained Delegation Permissions

AD Permissions Attack #4: Unconstrained Delegation Permissions

In this series, we’ve explored a few ways to take advantage of weak Access Control Lists (ACLs) to compromise Active Directory accounts and elevate our privileges. In this post, I will dive deeper into a more complex attack against Active Directory and show how permissions are once again critical to protecting yourself from a complete domain compromise. This particular attack leverages the delegation controls that can be applied to user and computer objects within Active Directory. This area of attack (unconstrained delegation permissions) is often overlooked by administrators—but can be extremely effective for an attacker to exploit. Let’s take a look.

What is Delegation?

Delegation is a feature of Active Directory that allows a user or a computer to impersonate another account. This has several practical applications, which Microsoft covers in this blog post.

This feature can be configured through the Delegation tab on a user or computer account. By selecting “Trust this computer for delegation to any service (Kerberos only),” you are enabling “unconstrained delegation”. Alternatively, you can specify a set number of Service Principal Names (SPNs) to restrict exactly what services a user or computer can impersonate, which would be considered “constrained delegation”.

The ability to manage this setting is controlled by permissions and user rights, which we will be exploring later in the post. Enabling unconstrained delegation or constrained delegation on an Active Directory user or computer account with permissions and user rights

What’s the Risk of Unconstrained Delegation?

There are several attacks against delegation that can be perpetrated. Once you turn on unconstrained delegation to a computer, any time an account connects to that computer for any reason, their ticket-granting ticket (TGT) is stored in memory so it can be used later by the computer for impersonation. Let’s say you enable this option on a computer you have administrative access to and then get a Domain Admin user to access the computer over the Common Internet File System (CIFS) by accessing a shared folder. Without unconstrained delegation on, only the ticket-granting server (TGS) would be stored in memory on your compromised machine. This ticket gives access only to the CIFS service on your machine so you can’t use it to move laterally. However, with unconstrained delegation enabled, when the privileged user connects to your machine, their TGT will be stored in memory, which can be replayed to move laterally and compromise a domain controller.

To illustrate, let’s use Mimikatz to export all tickets in memory with the command sekurlsa::tickets /export. Without delegation enabled, when the Administrator user connects to my server, all I get is the TGS ticket and no TGTs: TGS ticket captured on a computer without unconstrained delegation enabled

However, by enabling unconstrained delegation and connecting to the system again, now I get the TGT for the Administrator: TGT ticket captured on a computer with unconstrained delegation enabled to use Kerberos::ptt command to pass-the-ticket and get Domain Admin rights

Now I can use the Kerberos::ptt command to pass-the-ticket and get Domain Admin rights to my domain controller, leading to a complete domain compromise.

There are also several other ways to attack the delegation settings. Some are covered in this blog post by harmj0y and more on unconstrained delegation from Sean Metcalf can be found here.

How Permissions Control Delegation

As with anything in Active Directory, delegation on computers and users can be controlled through permissions. There are two sets of rights needed for a user to be able to manage the delegation controls of an object:

  • SeEnableDelegationPrivilege user right
  • Object permissions to msDS-AllowedToDelegateTo attribute, userAccountControl, and/or servicePrincipalName

SeEnableDelegationPrivilege is a user right that is controlled within the Local Security Policy of a domain controller and is managed through Group Policy. This setting is named “Enable computer and user accounts to be trusted for delegation”. It is very important to understand who has been granted this right within Active Directory because all they will need is write access to a computer to turn on delegation and begin to harvest TGTs from any user that connects to the system. Using SeEnableDelegationPrivilege to enable computer and user accounts to be trusted for delegation user right assignment

Besides the SeEnableDelegationPrivilege right, you will need the ability to update msDS-AllowedToDelegateTo and userAccountControl attributes for a computer, which is where these settings are stored.

Discovering Who Can Delegate

One of the first things you may want to do is find out where unconstrained delegation has already been enabled. To do so, you can use the following PowerShell script that will search for the User Account Control (UAC) value of all computers to see where delegation is turned on without restrictions. Using PowerShell command Get-ADComputer to return all computers with unconstrained delegation

Also, you may want to look at who has been granted the SeEnableDelegationPrivilege right. To do this, you can use PowerSploit and the Get-DomainPolicy command. Below you can see the default Administrators group is there, as well as a domain group Security Identifier (SID). PowerSploit Get-DomainPolicy command to identify who has the SeEnableDelegationPrivilege right in the Default Domain Controllers Policy

Protections from Unconstrained Delegation

It is rare that unconstrained delegation is needed. In most cases, you should be able to turn on constraints to limit the SPNs delegation can work for. Also, placing privileged users in the Protected Users group will prevent them from being used in delegation and keep their TGTs off these computers after they authenticate. The same goes for the Account, which is sensitive and cannot be a delegate option.

This is the final installment in our blog series, 4 Attacks that Exploit Active Directory Permissions and How to Protect Against Them. To view the previous blogs, please click on the links below.

To watch the AD Permissions Attacks webinar, please click here.

Don’t miss a post! Subscribe to The Insider Threat Security Blog here:

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Start a Free StealthAUDIT® Trial!

No risk. No obligation.

Privacy Preference Center

      Necessary

      Advertising

      Analytics

      Other