Unconstrained Delegation
Last updated
Last updated
Delegation allows a user or machine to act on behalf of another user to another service. A common implementation of this is where a user authenticates to a front-end web application that serves a back-end database. The front-end application needs to authenticate to the back-end database (using Kerberos) as the authenticated user.
\
\
We know how a user performs Kerberos authentication to the Web Server, but how can the Web Server authenticate to the DB and perform actions as the 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.
This query will return all computers that are permitted for unconstrained delegation.
Domain Controllers are always permitted for unconstrained delegation.
\
If we compromise WEB$ and wait or socially engineer a privileged user to interact with it, we can steal their cached TGT. Interaction can be via any Kerberos service, so something as simple as dir \\web\c$ is enough. Rubeus triage will show all the tickets that are currently cached. TGTs can be identified by the krbtgt service.
There is a scheduled task running on Workstation 1 as nlamb that will interact with WEB$ every 5 minutes. If the ticket is not there, wait a minute or so and try again.
\
We can simply extract this TGT and leverage it via a new logon session.
\
\
We can also obtain TGTs for computer accounts by forcing them to authenticate remotely to this machine. As mentioned in the NTLM Relaying module of the Pivoting chapter, several tools exist to facilitate this. This time, we will force the domain controller to authenticate to the web server to steal its TGT.
We will also utilise Rubeus' monitor command. This will drop into loop and continuously monitor for and extract new TGT as they get cached. It's 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.
Where:
DC-2 is the "target".
WEB is the "listener".
\
Rubeus will then capture the ticket.
\
Machine TGTs are leveraged slightly differently - see the S4U2Self Abuse module. To stop Rubeus, use the jobs and jobkill commands.
