Last updated
Last updated
As we saw in the previous two examples of constrained delegation, there are two S4U (Service for User) extensions. S4U2Self (Service for User to Self) and S4U2Proxy (Service for User to Proxy). S4U2Self allows a service to obtain a TGS to itself on behalf of a user, and S4U2Proxy allows the service to obtain a TGS on behalf of a user to a second service.
When we abused constrained delegation, we did: Rubeus s4u /impersonateuser:nlamb /msdsspn:cifs/dc-2.dev.cyberbotic.io /user:sql-2$. From the output, we saw Rubeus first builds an S4U2Self request and obtains a TGS for nlamb to sql-2/dev.cyberbotic.io. It then builds an S4U2Proxy request to obtain a TGS for nlamb to cifs/dc-2.dev.cyberbotic.io.
This is obviously working by design because SQL-2 is specifically trusted for delegation to that service. However, there's another particularly useful way, published by , to abuse the S4U2Self extension - and that is to gain access to a computer if we have its TGT.
In the Unconstrained Delegation module, we obtained a TGT for the domain controller. If you tried to pass that ticket into a logon session and use it to access the C$ share (like we would with a user TGT), it would fail.
This is because machines do not get remote local admin access to themselves. What we can do instead is abuse S4U2Self to obtain a usable TGS as a user we know is a local admin (e.g. a domain admin). Rubeus has a /self flag for this purpose.