Unconstrained

All information found below has been adapted from Attl4s video-presentation and its corresponding slide deck.

Theory

To configure a service to have Unconstrained Delegation (UD) the option Trust this user for delegation to any service (Kerberos only) (Trusted_For_Delegation) must be enabled (Figure 1).

Figure 1: The Trusted_For_Delegation setting (image taken from here).

Below we can see step-by-step what happens under the hood (Figure 2).

Figure 2: Delegation process under the hood (image taken from here).

In Step 2 () the will notice that the service (HTTP/sharebrowser) is set with and the resulting will have the ok-as-delegate flag. This way the client will also know that the service is suitable for delegation (Figure 3).

Figure 3: The ST contains the ok-as-delegate flag (image taken from here).

The delegation which the client asks for in Step 3 () will have the forwarded flag set (Figure 4).

Figure 4: The delegation ticket has the forwarded flag set (image taken from here).

Once the service receives the delegation TGT (Step 4), then it can request a ST for any service from the KDC while impersonating the user (Figure 5).

Figure 5: The service requests a ST for another service impersonating the user (image taken from here).

The TGT-REQ in Step 5 will request a ST for another service (cifs) as the user (vegeta) and the corresponding TGT-REP from the KDC will be issued for that user (vegeta) (Figure 6).

Figure 6: The TGT-REQ and TGT-REP containing the user's details (image taken from here).

Exploitation

If we control a service with UD set, then all clients talking to that service will drop their TGTs, therefore, we will be ablle to impersonate them. We can even force a privileged client to connect to our service, for example, through phishing.

If we are able to impersonate the DC01$, which has DCSync rights, then we will be able to perform a DCSync attack and get the administrator's hash.