Thread by @_nwodtuhs

[thread 🧵] this is a sub-thread about Kerberos Resource-Based Constrained (RBCD) and abuse scenarios.

While configuring accounts for Unconstrained and Constrained delegations requires high privileges in the domain, configuring RBCD is simpler. RBCD is configured on the service others delegate to.

This can be done by filling the service’s msDS-AllowedToActOnBehalfOfOtherIdentity attribute with other services SIDs. This allows other services to delegate to it.
Abusing high-priv users to edit that attribute on another account is an Access Control abuse and is another topic

Let’s say a service (A) has it’s msDS-AllowedToActOnBehalf[…] attribute filled with the SID of another service (B), here are the steps followed by service (B), controlled by the attacker, to access (B) on behalf of another principal.

1. Service (B) 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 (B) 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 (A), on behalf of the user impersonated previously.

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

Interesting thing to know: machine accounts can edit their own msDS-AllowedToActOnBehalf[…] attribute, hence heightening NTLM relay attacks. A machine account’s authentication can be triggered, relayed to a domain controller’s LDAP service, and the relayed session can be abused

The attacker can then allow another service account of his choosing to act on behalf of others on this machine account (i.e. Administrator).

More info on The Hacker Recipes
thehacker.recipes/ad/movement/ke…

ICYMI

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