Unconstrained Delegation
Last updated
Last updated
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.
Domain Controllers are always permitted for unconstrained delegation.
There are two main attack scenarios to abuse Unconstrained Delegation:
Using a cached ticket or waiting for a user to authenticate into a owned host
Leveraging the Printer Bug
Now we can simply extract this TGT and leverage it via a new logon session.
And use it to create a process to steal the token from
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.
Next, run SharpSpoolTrigger.
If the attack worked Rubeus will then capture the ticket.
REMEMBER
To stop Rubeus on a beacon you have to kill the underlying task / job.