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.
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:
However, by enabling unconstrained delegation and connecting to the system again, now I get the TGT for the Administrator:
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.
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.
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.
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).
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.
- Active Directory Permissions Attack #1 – Exploiting Weak Active Directory Permissions with PowerSploit
- Active Directory Permissions Attack #2 – Attacking AD Permissions with Bloodhound
- Active Directory Permissions Attack #3 – Persistence using AdminSDHolder and SDProp
To watch the AD Permissions Attacks webinar, please click here.