Welcome to the second 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.
About the Target
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: LLMNR and IPv6 disabled, SMB Signing enabled, Intrusion Detection and Prevention (IDS/IPS), and A/V 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 LLMNR disabled in the environment, it quickly eliminates the ability to steal hashes and possibly crack passwords. It also eliminates the ability to perform SMB Relay attacks (you can see an example here: https://www.youtube.com/watch?v=b31KbDb-5DA) as we need LLMNR to perform the attack. Additionally, IPv6 is disabled within the network, which prevents attacks like IPv6 DNS takeovers (see: https://www.youtube.com/watch?v=zzbIuslB58c).
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.
Default Credentials
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. All it takes is one initial mistake to take down an entire network and we are about to see that play out.
While browsing the various web portals in the environment, I came across many login pages. On a time-limited engagement, the first thing that I attempt to do is log into these web portals using their default credentials. For example, if I came across an iDRAC server, I would do a quick Google search of “iDRAC default credentials” and would quickly discover that those credentials are “root:calvin”.
During this pentest, I bounced around from login portal to login portal and was having trouble finding any at all with default credentials. That’s great for the client and terrible for me. Eventually, I found what appeared to be a network application that was being tested out in a dev environment. The application was using default credentials and was on a free trial license.
Within this application, for whatever reason, was a cleartext credential. See below:
Password Spraying
Now we have a password. I have no idea if this password will work in our environment, but it’s the farthest I’ve managed to get at this point. The next thought that crosses my mind is “where does this password work?” In order to answer that, we can attempt to spray the password around the network as a local administrator user and see if it hits for us anywhere. I prefer to use crackmapexec for this:
Any instance where you see “Pwn3d!” is an instance where the credentials work on that machine as an administrator. We literally owned one machine, but this is one machine more than we had before. Once a machine has been compromised, I personally like to use a tool called secretsdump.py to dump out the local SAM hashes and possibly cleartext credentials (we’ll get to that later).
Running secretsdump.py on the machine resulted in the following:
If you look carefully, we only dump out four accounts: Administrator, Guest, an admin account, and a Sophos account. The hashes for the Administrator account and this partially obfuscated admin account are identical. That means the passwords are identical. We now have a new account name to work with and we know there is Sophos on these machines.
Given the new account name, we can perform the same sweep as before with crackmapexec and see if the results change. While I am somehow (and unfortunately) missing the screenshot for this, please imagine that the crackmapexec results lit up like a Christmas tree, because they absolutely did.
What had happened in the network was local admin password reuse and quite a bit of it. The hospital was not reusing this password on the traditional Administrator account, but on a local admin account they set up. In fact, I got a bit lucky that the password existed on one machine and allowed me to uncover a new username since that was the only machine it worked on. If that machine had been off that day, this could be a different story. Yet, it wasn’t and the hospital proceeded to get owned.
Once I know a password works on several machines, I repeat the process of using secretsdump.py to dump out credentials. We can often find new local user accounts and hashes that can be leveraged to gain access to other machines. We can also often find cleartext credentials. Sometimes, these cleartext credentials show up in the form of WDigest, which is enabled by default on Windows 7, Windows 8, Windows Server 2008 R2, and Windows Server 2012.
WDigest
What’s so special about WDigest? It stores the credentials of any user that has logged into that machine since it has been turned on in clear text. Imagine an environment where devices are still running on older versions of Windows. This is pretty common in hospitals. Now imagine we log onto a machine that is vulnerable and a domain administrator has logged into it as well.
We’ll capture a domain administrator’s password in clear text, as such:
As you can see above, we have managed to dump out two accounts. Both of which were domain admins. The above has not been obfuscated because the overly permissive service account was removed and all passwords were changed, which makes for even better pictures and storytelling!
Once we have our domain administrator password, we can go log into the domain controller:
Lessons Learned
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) No default creds, please – The initial phase of the attack relied on using default credentials on a web application to log in. From here, we were able to obtain our password and we were off to the races. Ensure that all web portals have non-default credentials.
2) Turn off WDigest – Or, you know, upgrade from Windows 7. If WDigest was disabled, we would have had a harder time discovering domain admin credentials in the network. It’s a simple patch, too.
3) Don’t give service accounts Domain Admin access – In this attack, we were able to leverage an overly permissive service account to gain access to the domain controller. Friends do not let friends use service accounts as Domain Admin. Please ensure you aren’t doing so and tell your friends while you’re at it.
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. Unfortunately, we see this way too often.
Conclusion
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:
Twitter: https://twitter.com/thecybermentor
LinkedIn: https://linkedin.com/heathadams
YouTube: https://youtube.com/thecybermentor
Twitch: https://twitch.tv/thecybermentor
About the Author
Heath Adams, also known as “The Cyber Mentor,” is the CEO of TCM Security. While Heath is an ethical hacker by trade, he also loves to teach! Heath has taught courses to over 1,000,000 students on multiple platforms, including TCM Academy, Udemy, YouTube, Twitch, and INE.
Heath has held many certifications, including CISSP, PNPT, QSA, GSNA, OSCP, ECPTX, and eWPT. He also holds an MBA degree.
Finally, Heath is also a husband, animal dad, tinkerer, and military veteran.
About TCM Security
TCM Security is a veteran-owned, cybersecurity services and education company founded in Charlotte, NC. Our services division has the mission of protecting people, sensitive data, and systems. With decades of combined experience, thousands of hours of practice, and core values from our time in service, we use our skill set to secure your environment. The TCM Security Academy is an educational platform dedicated to providing affordable, top-notch cybersecurity training to our individual students and corporate clients including both self-paced and instructor-led online courses as well as custom training solutions. We also provide several vendor-agnostic, practical hands-on certification exams to ensure proven job-ready skills to prospective employers.
Pentest Services: https://tcmdev.tcmsecurity.com/our-services/
Follow Us: Blog | LinkedIn | YouTube | Twitter | Facebook | Instagram
Contact Us: sales@tcm-sec.com
See How We Can Secure Your Assets
Let’s talk about how TCM Security can solve your cybersecurity needs. Give us a call, send us an e-mail, or fill out the contact form below to get started.