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.
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.
Jeff Warren is Stealthbits’ General Manager of Products. Jeff has held multiple roles within the Technical Product Management group since joining the organization in 2010, initially building Stealthbits’ SharePoint management offerings before shifting focus to the organization’s Data Access Governance solution portfolio as a whole. Before joining Stealthbits – now part of Netwrix, Jeff was a Software Engineer at Wall Street Network, a solutions provider specializing in GIS software and custom SharePoint development.
With deep knowledge and experience in technology, product and project management, Jeff and his teams are responsible for designing and delivering Stealthbits’ high quality, innovative solutions.
Jeff holds a Bachelor of Science degree in Information Systems from the University of Delaware.
Thank you. Thats a really nice article. Well explained.
Also within the “What’s the Risk of Unconstrained Delegation?” Section you mention without the unconstrained delegation enabled, the TGS (Ticket Granting Server) is stored in memory.
Shouldnt this be the service granting ticket (SGT) which is what you have shown in your mimikatz screenshot Server : CIFS xxxx
Thanks for the comments! In that section I am illustrating without unconstrained delegation enabled on that computer, we capture the service ticket only, which is the CIFS ticket you see. This is commonly referred to as the TGS but the basic concept is this ticket gives access to a user for a specific service on a specific host. With unconstrained delegation enabled, you see the second screenshot where we get the krbtgt ticket which is the TGT and can be used to request new TGS tickets for that user which enables lateral movement so much riskier. Hopefully that helps and if not happy to go deeper into this!