Thread by @_nwodtuhs

[thread 🧵] this is a sub-thread about Kerberos Constrained Delegation (KCD) and abuse scenarios.

Similarly to Unconstrained Delegations, service account configured for KCD can act on behalf of other principals on other services. The difference is that with KUD, it’s possible to delegate to any service whereas with KCD it’s possible to delegate to a specific set of services

User granted with the SeEnableDelegationPrivilege right in the domain (really high priv ⚠️) can configure service accounts for delegation (unconstrained or constrained).

Principals « sensitive for delegation » or member of the « Protected Users » group cannot be delegated

There are two types of Kerberos Constrained Delegations
- with protocol transition (« Use any authentication protocol »)
- without protocol transition (« Use Kerberos only »)

Let’s see how KCD-with-protocol-transition works
1. Service (A) configured for delegation can obtain a ticket to itself, on behalf of a user through a legitimate technique called S4U2self, which is a Kerberos extension
(S4U2self = service for user to self)

2. Service (A) obtains a Service Ticket and uses it in an S4U2proxy request, which is another Kerberos extensions. This allows the service to obtain an ST to another service (B), on behalf of the user impersonated previously.

3. (A) can access (B) on behalf of the user.

With KCD-without-protocol-transition, the process is a bit different: the S4U2self produces a non-forwardable Service Ticket.

The thing is S4U2proxy needs to use the ST obtained with S4U2self in order to work. And that ST needs to be forwardable*. With KCD-without-protocol-transition, since S4U2self results in a non-forwardable ST, S4U2proxy doesn’t work

*except with RBCD, but this is another topic

https://twitter.com/_nwodtuhs/status/1454048919579676676

And if S4U2proxy doesn’t work, service (A) cannot obtain a ticket to service (B) on behalf of another user.
So how does KCD-without-PT works?

Instead of being able to obtain a forwardable ST, the KCD-without-PT service (A) is supposed to wait for for a user to send his Service Ticket. Service (A) then has a ST than can be used for S4U2proxy.

Now let’s get to the funny parts. How can we abuse Kerberos Constrained Delegations? 😈

Abusing KCD-with-protocol-transition is straight forward: S4U2self + S4U2proxy + pass the ticket. The S4U2* steps can be done with getST on UNIX-like systems and with Rubeus on Windows.
More info on The Hacker Recipes thehacker.recipes/ad/movement/ke…

Abusing KCD-without-PT is a bit trickier. While waiting for users to send their Service Tickets and use those for S4U2proxy would work, @elad_shamir found and shared a trick to bypass the « S4U2self doesn’t produce a forwardable ST » limitation shenaniganslabs.io/2019/01/28/Wag…

This trick relies on the fact that S4U2proxy always produces a forwardable ticket. So, what if there was a way to do what S4U2self does, but with S4U2proxy (i.e. service obtains a ST for a user to itself)? Well there is.

The trick relies on the following requirement: another service account (C) that has an SPN, can delegate to service (A)
This can be done by configuring service (A) for RBCD (Resource-Based Constrained Delegation), but it’s another topic.

If service (C) can delegate, through RBCD, to service (A)
And service (A) can delegate, through KCD-without-PT, to service (B), the the following drawing shows what steps to follow to act on (B) as another user.

All of this can be done with getST or Rubeus.
More info on The Hacker Recipes thehacker.recipes/ad/movement/ke…

ICYMI

https://twitter.com/_nwodtuhs/status/1454049627255279626