5 Times I Gained Admin due to Misconfiguration – Part 1

‍

The cybersecurity industry spends a lot of time focusing on zero-day vulnerabilities and advanced nation-state threat actors. But the reality is there is a lot of low-hanging fruit with regards to misconfiguration. We’ve heard time and time again how important hardening, and secure configurations are, but I thought it might be interesting to dissect some real-world attacks I have taken place in that resulted in full compromise of the target environment using nothing but misconfiguration flaws. So, let’s get started with our first of five examples!

‍

Hospital Network Compromise

The first example I will look at in this initial blog post is a large hospital I was hired to assess from an internal penetration testing standpoint. I was granted access to a conference room at their administrative offices, with a Cisco VOIP phone, HP printer and 4 ethernet ports mounted to the conference room table, but no other information was provided. My objective, like so many assessments, was to gain domain administrator. I normally like to get better testing objectives than “get DA” but this is common. I was instructed specifically to only use “safe” attacks and to cause no harm, especially in areas related to patient care.

Note: Before we get into the details, while we will cover the stages of attack used in this scenario, this is not intended as a walkthrough of how to duplicate these attacks, so some details around system commands are not included. This was an assessment I performed a few years ago and some of those details are muddy, but the point of this article is to highlight the areas where misconfiguration might lead to compromise. We will cover specific hardening guidance in a future article. As you will see, there are many opportunities for future articles to cover network, operating system, software and Active Directory hardening, as well as effective monitoring and response capabilities.

Physical Access

While I was granted access by hospital management, and the security desk knew I was an authorized visitor, nobody but my contact in cybersecurity knew why I was there. Not once was I challenged, which is somewhat concerning given all the computers and equipment I was using, and the computers I physically explored that were obviously assigned to employees that were out of the office. But this is one of the least interesting things I discovered.

NAC Bypass

‍

Part of the reason I was hired, is the hospital had just implemented an 802.1x Network Access Control solution that they were very proud of and were confident that it would stop a determined attacker such as myself. I was there to justify their investment. Unfortunately, their implementation took some shortcuts. The first thing I noticed was the Cisco VOIP phone in the conference room. While the network jacks were protected by NAC, the phone was on a voice VLAN and I decided to explore the security of that network and determine if I could use a VLAN hopping attack to gain access, since my suspicion was the phones were not protected in this way. That technique has worked in the past, but in this instance, the hospital had implemented effective security controls to prevent that route.

The second avenue I explored though, was that of the HP printer in the conference room, which was also connected by ethernet cable. That connection too was protected by NAC. But what I realized quickly was the HP printers were not enrolled in the NAC implementation, which is not uncommon for IoT devices that do not work well with 802.1x. Especially for older printers, this is the case. In their NAC installation, they created an allowlist for HP devices, such that any network interface that started with the OUI prefix for HP, was allowed to bypass the NAC. Fantastic! Now all I need to do is change the MAC address for my laptops network interface so that it appeared to be an HP device using the first 3 bytes of the MAC OUI string, and NAC is bypassed. This was not the objective I was given, but within 30 minutes of starting the assessment, I had already bypassed a control they had spent $millions on due to a misconfiguration. Thankfully they were assigning IP addresses with DHCP, and there were no DHCP filtering controls enforced which could have restricted which MAC addresses could request IP addresses.

• Misconfiguration 1 – Overly Permissive NAC Allowlist - It is worth noting that most NAC implementations are more robust than this.
• Misconfiguration 2 – Did not enroll Printer in 802.1x
• Misconfiguration 3 – Did not implement DHCP Filtering
• Misconfiguration 4 – Lack of network or DHCP log monitoring (this was never discovered by client)
• Impact – Unauthorized Network Access

Python Responder

Now that I had access to the network, it’s time to really get started. One of my favorite tools for doing internal assessments is the amazing tool responder.py, originally created by Trustwave Spiderlabs and now maintained at https://github.com/lgandx/Responder. It abuses Link Local Multicast Name Resolution (LLMNR) in most versions of Windows, and it’s such a juicy target that Googling for LLMNR results in dozens of exploitation references before you can ever find what it was even used for. The long and short of it, is you should just disable it. There are some great articles on that from Black Hills Information Security, and I’ll talk more about this in future articles. But this hospital had not done so, therefore firing up responder resulted in a stream of encrypted file hashes to crack and other interesting data as my broadcast traffic was being responded to. This is a noisy attack but there are many applications that will respond to it.

• Misconfiguration 5 – LLMNR was not disabled
• Misconfiguration 6 - Lack of network or system monitoring (this was never discovered by client)
• Impact – Unauthorized access to encrypted credential hashes

Endpoint Management Compromise

But I did not actually need to crack any hashes at all. Responder provided me many options including basic authentication strings sent over the network in cleartext. One of these, or rather, THOUSANDS of these, were from a popular endpoint management software by Altiris, now owned by Broadcom/Symantec. Basically, every client, which was really every Windows desktop on the network, had the software agent installed for remote administration and patch management by IT. But every machine also suffered from a single configuration weakness. There is a checkbox in the configuration that says to send management commands over TLS. This was not checked. So that meant that when I masqueraded as the server with responder, every response included a domain administrator authentication configured at the time of implementation, in cleartext. My logs were filling up with domain administrator credentials!

• Misconfiguration 7 – Altiris Endpoint did not enforce encryption for administrative commands
• Impact – Unauthorized Access to Domain Administrator accounts

Interlude

OK, so what do I do now? I’ve spent less than one hour on an assessment that was supposed to take two weeks. Do I just go home now, the objective accomplished? I do need to write the report. But let’s go a little farther and see what else we can accomplish, still staying within the rules of engagement of “safe exploits”.

Active Directory Reconnaissance

Now that I have domain access, and domain admin at that, let’s look at Active Directory and see what I can discover. It appears that there’s only a single domain, with a few organizational units (OUs) identified that seem tied to business areas, most importantly, to very critical areas of the network. I should not be seeing OUs named “PatientFloor” or “NICU” inside an AD focused on the enterprise network and users that frequently go to the internet.

OK, so we’ve established that the Active Directory is wide open, what about the network? Normally I would have already performed network reconnaissance by this point, but due to how quickly I gained access to AD, I got ahead of myself a little bit. Normally I’d fire up nmap and do some scanning, but the hospital IT staff was very helpful, and the computers found in these other OUs had excellent (for me) computer naming and network documentation, complete with networks associated with that business unit.

I spent most of the rest of the first day just exploring AD and doing random network scans with nmap to see what I could access and documenting the results. From my machine, I was not able to access very much, but as you will see, that did not make much of a difference.

• Misconfiguration 8 – AD is not architected securely, and should have been isolated with one-way trusts in place
• Misconfiguration 9 – AD was too verbosely documented given that every user in the domain had access to view AD Users and Computers and associated OUs. This is an OpSec failure.
• Kudos – Excellent governance in the management of this infrastructure. It was very consistent. This attention to detail will be very valuable once they start configuring for security
• Impact – Information Disclosure valuable in performing additional attacks

Jumphost Compromise

When exploring AD,  I found a host called “jumphost99” that appeared to have access to every network segment, even though my machine did not. And of course, it was joined to AD so my domain admin account worked to gain access to it, and did not require MFA. This is the first time I needed to “compromise”a computer owned and managed by the hospital. Up to this point, it’s just been me interacting with the environment, and sending traffic that really should not have been trusted.

Now that I have network access to everything, and domain administrator access to almost everything except for assets not joined to the domain, where do I go from here? I started dumping local administrator account passwords, and discovered that they were set globally, not just for Windows, but for IoT devices as well. The same password used for the default admin account, was also root on the Linux servers, and admin on building management controls and HVAC systems. Even more concerning was controls for negative pressure pumps and other monitoring devices on the patient care floor that did not even require a password, or in the nurse’s station and hospital pharmacy.

• Misconfiguration 10 – Shared admin password
• Misconfiguration 11 – Allowing root login
• Misconfiguration 12 – Medical devices joined to network that probably do not need to be
• Misconfiguration 13 – Lack of network segmentation or unidirectional traffic enforcement
• Misconfiguration 14 – Single point of failure for jumphost, that was trusted by every network
• Misconfiguration 15 - No MFA required on administrative access such as jumphost and other high trust systems
• Misconfiguration 16 - Lack of network or system monitoring (this was never discovered by client)
• Misconfiguration 17 - Some OT systems did not require a password
• Impact - At this point, there is very little that cannot be done. Complete hospital compromise, that could have led to patient death or major financial or reputation damage. From a conference room. In less than 2 days. Without exploiting a single CVE.

I hope you enjoyed this foray into the first in our series on “Five Times I Gained Admin due to Misconfiguration”. Before we explore the next instance, we will publish a companion piece on configuration hardening you can use to examine how to resolve these types of issues. We will also go quite a bit deeper as we explore the above misconfiguration topics, to include other good security practices and when they should be applied. We've been hard at work on a couple sister projects in this area and can't wait to share them with you!