Pentest Tales #001: You Spent How Much on security?
Welcome to the first edition of Pentest Tales, a blog series that walks through real-world pentests we’ve performed in the past. The purpose of this blog is not just to share the “owning” of a domain, but to provide education as to why a domain was owned in the first place. If even one domain administrator takes away information from this post and uses it to better their environment, I’ll be incredibly happy.
Now, let’s set the scene for our engagement:
Pentest Type: Internal Network
Client: Large US hospital. Well-funded and has invested millions in security measures.
Defenses: IPv6 disabled, Intrusion Detection and Prevention (IDS/IPS), CyberArk (Privilege Access Management), and Symantec Endpoint Security on all devices. Patching is also current through a solid patch management system.
The defenses in place immediately eliminate some common attacks and change the methodology mindset. An example of this is the common use of LLMNR poisoning in internal environments, which graciously presents a domain user’s NTLMv2 hash to an attacker in a man-in-the-middle scenario (If you’re interested in learning more about this attack or seeing it in action, I have a video on it here: https://www.youtube.com/watch?v=Fg2gvk0qgjM). With the use of CyberArk, a Privilege Access Management (PAM) tool, in the network, our chances of capturing an NTLMv2 hash worth cracking are slim to none. This is because one of the key purposes of a PAM tool is to utilize long (see: 15-30+ character) passwords on accounts. While we might be able to capture a hash, we’re certainly not cracking it at 15+ characters. Tools like CyberArk can also rotate domain passwords every X amount of hours and utilize check-in/check-out features where the password is only utilized once. This, in theory, eliminates a big attack surface internally.
When it comes to the attacker mindset from within a network, the big thought (at least for me) is “How do I gain a foothold?”. Once you have a shell on a machine, navigating around the network can become a lot easier. The challenge is getting that initial shell, or even credential, that can be utilized as leverage later to move laterally and vertically within a network. In our case, detection mechanisms are in place, which would likely pick up vulnerability scans. Even with vulnerability scans, the client has a good patch management process, which is honestly incredible for a hospital. IPv6 is disabled within the network, which prevents attacks like IPv6 DNS takeovers (see: https://www.youtube.com/watch?v=zzbIuslB58c).
Given the limitations, my thoughts move to combing services, such as web sites, to look for information leaks or potential web shells or looking into other Active Directory attacks, such as SMB relay attacks. I decide to first set up an attempt at an SMB relay as it can work in the background while I comb through services.
Let’s briefly talk about SMB relay attacks. Want to see the attack in action? You guessed it, you can see it on my YouTube: https://www.youtube.com/watch?v=b31KbDb-5DA. Above, we discussed the common use of LLMNR poisoning during internal network assessments. With LLMNR poisoning, we get back an NTLMv2 hash for the poisoned user that we can take offline and try to crack. If the password is strong (see: CyberArk), we’re just stuck with a hash. But wait! Instead of trying to crack the hash, we can actually relay the hash to another machine and pretend we are the captured user, which would provide us shell access given certain conditions. The requirements of SMB relay are:
1) SMB signing must be disabled on the target. By default, SMB signing is enabled on Windows Servers and disabled on Windows Workstations.
2) The relayed user credential must be an admin on the machine it is being relayed to. This is not entirely true, however we get significantly more benefits out of a machine admin.
Now, let me break this down to basic terms. Say we have Bob. Bob is a user who has admin rights on his machine. Bob also has admin rights on another machine. These machines have SMB (think file shares) open, which is common in a domain network. These machines are workstations and do not have SMB signing enabled. If an attacker is sitting in a man-in-the-middle position, the attacker can intercept Bob’s NTLMv2 hash via LLMNR poisoning and relay that hash to another machine in a SMB relay attack. Because SMB signing is disabled, the machine trusts the relay to be Bob and does not require proof. Which means that we can get a shell on a machine without ever having a password (yay default Windows “features”!):
The above image is the successful relay attack. As you can see, we gained access to the machine and were able to dump the SAM hashes on the machine. We now have the Administrator hash along with three users: “techsupport”, “TechSupport2”, and “___admin”. I have obfuscated any sensitive data. If we look at the hash information, we can see that the Administrator user and both tech support users have the exact same hash (and same password). That immediately screams password reuse.
We now have a couple of options when we have captured a local hash. We can take the hash offline and try to crack it. It might give us some insight to the strength of passwords they are using in the environment and possibly the ability to use that password elsewhere. We can also take the hash, without cracking it, and pass it around the environment. I did both. Here’s what happened:
The above image shows the cracked password, which was “Power10”. The password has since been changed and password re-use eliminated, so I am okay with revealing it. I am using a tool above called CrackMapExec to perform a Pass the Hash attack. Any instance where you see “Pwn3d!” is an instance where the credentials work on that machine as an administrator. This isn’t every machine that was owned, but it is what I could reasonably fit into a screenshot. The entire network was loaded with password re-use.
Now, there was also endpoint protection in place to navigate if I wanted to try and gain access to these machines. Luckily, I could issue a command remotely and disable the endpoint protection. Why? Because the admin password for that, too, was Power10.
I will give some credit in that the password of Power10 did not log into the domain controller directly. However, with access to as many servers as I had, it was only a matter of time before I found a way in. I logged into various machines and dumped the hash data. Eventually, one of the hashes worked on the domain controller:
Above is a system shell on a domain controller utilizing a hash. I did not need the password, but I cracked it anyways. It was “Welcome1”. Another facepalm in the password department.
Here we have a company that was doing so many things right, but yet went down within a few hours of an internal engagement. A hospital, nonetheless, which is scary in its own right. There are several important lessons to be learned here, many of which could have stopped me in my tracks:
1) Enable SMB Signing (and disabled LLMNR) – If I do not have the ability to perform the relay attack, I don’t get my initial shell. While the possibility of other footholds exist, eliminating any potential foothold can slow down or completely prevent an attacker (motivation dependent, of course).
2) Least privilege – I know this is easier said than done, but preventing users from being administrators on their machine (and especially multiple machines) goes a long way in regards to properly securing your network.
3) Account tiering – If Bob is a domain admin, then Bob should have at least two domain accounts. One account for everyday use and one account that one logs into the domain controller with when absolutely necessary. Having a domain admin be part of an LLMNR or relay attack could signal game over immediately if weak policies are in place.
4) DON’T REUSE YOUR PASSWORDS – This should make sense by now, yeah? Not only should you have strong passwords, but you should also only being using the passwords one time only. If an attacker gets shell access to a machine and dumps the hash, the hash/password should work nowhere else. It certainly shouldn’t work on nearly every computer in the network and it certainly shouldn’t disable endpoint protection.
That’s all for this Tale! I hope you have found the information useful. I have attempted to keep it very high level for a broader audience. I strongly encourage reading further (or watching YouTube videos 😉 if you are interested in the technical attacks and defenses).
Until next time…happy hacking!
Want to connect? You can reach me at: