(KCD) Constrained
Theory
If a service account, configured with constrained delegation to another service, is compromised, an attacker can impersonate any user (e.g. domain admin, except users protected against delegation) in the environment to access another service the initial one can delegate to.
If the "impersonated" account is "is sensitive and cannot be delegated" or a member of the "Protected Users" group, the delegation will fail.
Nota bene: the native, RID 500, "Administrator" account doesn't benefit from that restriction, even if it's added to the Protected Users group (source: sensepost.com).
Constrained delegation can be configured with or without protocol transition. Abuse methodology differs for each scenario. The paths differ but the result is the same: a Service Ticket to authenticate on a target service on behalf of a user.
Once the final Service Ticket is obtained, it can be used with Pass-the-Ticket to access the target service.
On a side note, a technique called AnySPN or "service class modification" can be used concurrently with pass-the-ticket to change the service class the Service Ticket was destined to (e.g. for the cifs/target.domain.local SPN, the service class is cifs).
Practice
With protocol transition
If a service is configured with constrained delegation with protocol transition, then it can obtain a service ticket on behalf of a user by combining S4U2self and S4U2proxy requests, as long as the user is not sensitive for delegation, or a member of the "Protected Users" group. The service ticket can then be used with pass-the-ticket. This process is similar to resource-based contrained delegation exploitation.
page(RBCD) Resource-based constrainedFrom UNIX-like systems, Impacket's getST (Python) script can be used for that purpose.
When attempting to exploit that technique, if the error above triggers, it means that either
the account was sensitive for delegation, or a member of the "Protected Users" group.
or the constrained delegations are configured without protocol transition
Without protocol transition
If a service is configured with constrained delegation without protocol transition (i.e. set with "Kerberos only"), then S4U2self requests won't result in forwardable service tickets, hence failing at providing the requirement for S4U2proxy to work.
This means the service cannot, by itself, obtain a forwardable ticket for a user to itself (i.e. what S4U2Self is used for). A service ticket will be obtained, but it won't be forwardable. And S4U2Proxy usually needs an forwardable ST to work.
There are two known ways attackers can use to bypass this and obtain a forwardable ticket, on behalf of a user, to the requesting service (i.e. what S4U2Self would be used for):
By operating an RBCD attack on the service.
By forcing or waiting for a user to authenticate to the service while a "Kerberos listener" is running.
While the "ticket capture" way would theoretically work, the RBCD approach is preferred since it doesn't require control over the service's SPN's host (needed to start a Kerberos listener). Consequently, only the RBCD approach is described here at the moment.
RBCD approach
The service account (called serviceA) configured for KCD needs to be configured for RBCD (Resource-Based Constrained Delegations). The service's msDS-AllowedToActOnBehalfOfOtherIdentity attribute needs to be appended with an account controlled by the attacker (e.g. serviceB). The attacker-controlled account must meet the necessary requirements for service ticket requests (i.e. have at least one SPN, or have its sAMAccountName end with $).
1. Full S4U2 (self + proxy)
The attacker can then proceed to a full S4U attack (S4U2self + S4U2proxy, a standard RBCD attack or KCD with protocol transition) to obtain a forwardable ST from a user to one of serviceA's SPNs, using serviceB's credentials.
2. Additional S4U2proxy
Once the ticket is obtained, it can be used in a S4U2proxy request, made by serviceA, on behalf of the impersonated user, to obtain access to one of the services serviceA can delegate to.
Computer accounts can edit their own "rbcd attribute" (i.e. msDS-AllowedToActOnBehalfOfOtherIdentity). If the account configured with KCD without protocol transition is a computer, controlling another account to operate the RBCD approach is not needed. In this case, serviceB = serviceA, the computer account can be configured for a "self-rbcd".
Around Aug./Sept. 2022, Microsoft seems to have patched the "self-rbcd" approach, but relying on another account for the RBCD will still work.
Resources
Last updated
