Pentest Tales #002: Digging Deep​

  • Home
  • Blog
  • Pentest Tales #002: Digging Deep​
Pentest Tales #002: Digging Deep​

Pentest Tales #002: Digging Deep

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.

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. 

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:

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.

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
Patreon: https://patreon.com/thecybermentor

Leave a Reply

Your email address will not be published. Required fields are marked *