So Many Hosts, So Little Time

Every now and then, while performing a penetration assessment, we’ll get a large set of hosts considered in scope. This is often a nice change of pace from the compliance-based penetration assessment where the scope is smaller and more focused on the Cardholder Data Environment (CDE). With the larger scope, we can come a bit closer to simulating an actual attacker from the perspective of the internal network. I say closer because as security consultants we are still limited by time, often only having a week to perform an assessment. If the scope is big enough, we will typically send two or more consultants. This blog will detail just one of those assessments and will hopefully give insight into effective time management for large scopes that offer more than one method of compromise.


Let me set up the scenario a bit. My co-worker Adam Steffes and I were tasked with performing an assessment with a few thousand hosts in scope. We were quite excited to work on such a large scope and after reviewing the last report, we were confident we would find at least a few attack vectors that would lead to initial compromise. We also knew, based on past experience, that sometimes all it takes is exploiting one system to be able to compromise the entire network or domain. Initial information gathering revealed several outdated web servers, misconfigured services, and outdated software. Vulnerability discovery showed that the number of hosts suffering from one or more of these vulnerabilities would continue to grow, and given the large scope, automated vulnerability scanning tools would take a while to complete. This gave us an opportunity to split the work.

Penetration Assessment War Story

Halfway through the week, our automated vulnerability discovery tools were still grinding away. Adam found one host worth investigating, and I had about five. When I say, “worth investigating,” I mean a host that had vulnerabilities we knew would lead to successful exploitation. These were found with manual discovery techniques. After all, we didn’t have time to wait for the scanner to finish before we started looking for vulnerabilities. While Adam was working on a way to exploit his host, I quickly ran into roadblocks exploiting my five hosts. The anti-virus (AV) tool on each of these hosts was actually doing a great job at picking up my exploitation attempts. Even normal AV evasive techniques were getting blocked. I decided to narrow my focus to two hosts, because each had at least three different vulnerabilities leading to administrative access. This is where effective time management came into play.

We were nearly done with Wednesday at this point and had until midday Friday before we wrapped up. We had essentially a day and a half to figure out a way past the defenses. Early Thursday, Adam got into his host, and I was still fiddling with the same vulnerabilities on the same two hosts. This can happen once in a while, where you become so focused on trying to exploit one vulnerability that you sometimes forget to revisit another vulnerability on the same system. I decided to step away from those hosts to help Adam focus his attacks. This resulted in him pulling hashes from the system, and me mentoring him on some post exploitation tasks to try. With him set on a task, I went back to those two systems, but this time decided to focus on the other vulnerability. These hosts both had the JMX Console exposed with no authentication required. There were several exploits available for this vulnerability and once again I was running into the AV on each system flagging the exploit attempts, or at least that’s what appeared to be happening. I continued to try the usual AV evasion techniques, changing the shell code a bit, and all of it resulted in a whole lot of nothing. Meanwhile, Adam was pulling somewhat sensitive information off of the system, but was running into tool failure when trying to pull cached password hashes off the host to see if he could get cached accounts for domain users. One thing we noticed on this project was that the local Administrator account was not shared across every host and was actually changed on each. This gave us an added challenge but didn’t make our task impossible.

With about 30 minutes left in our testing window for the day, I found an exploit written in perl that worked against both hosts running the vulnerable JMX Console. This succeeded on the first attempt for each host. Excellent. I now had “NT Authority/SYSTEM” level access to both vulnerable hosts. I quickly made a local administrator account on each so that I could get back in, just in case the connections proved unreliable. From here, I perused the system for something useful. I looked for credentials, sensitive client information, anything. I came up short. The last thing I did before leaving was to dump the system’s local hashes. This actually paid off but was the last thing I could do as the end of Thursday’s testing window had been reached. Adam and I went back to the hotel and worked on a battle plan. He too had finally managed to dump local account hashes from the system he had initially compromised.

The last day of testing arrived, and Adam and I had a battle plan. He would investigate other hosts that the now finished vulnerability scanners flagged as having a plethora of vulnerabilities leading to compromise. I would work on compromising a domain user and then see if I could elevate to a domain administrator, or, alternatively would see if I could gather any sensitive/confidential information that could prove to be a huge hit to the company’s reputation/business. I know firsthand that sometimes a successful penetration assessment means not getting domain admin, but instead demonstrating the ability to completely compromise a company’s intellectual property and communicating the severe business impact this could have. At this point in the assessment, either would work well.

By mid-morning, and with some additional information gathering, we discovered a local administrative account that shared account details with a domain account. We didn’t have the password but we had a hash we could pass. Using a tool called SMBExec, I checked to see if this account was shared between any other in scope hosts. Sure enough, I had used this account to dump local account hashes and cached domain account hashes off about 30 additional systems. This worked because this particular domain account also had local administrative privileges on these hosts. Going through the data dump, I noticed that one host had a domain account in memory, which provided a clear-text password. Finally! Now with one hour left in the assessment, we had a domain user along with a password. I checked this user’s permissions by running a tool called enum4linux with the user’s account credentials against one of the domain controllers in scope. I used the primary domain controller, but any of the domain controllers should have provided the same information. The information from this tool told me exactly what I needed to know. It showed me that this user was not a domain administrator but it did give me additional information about the domain, including the password policy, domain usernames, domain groups, etc.

Lessons Learned

I’m not going to give a “hindsight is 20/20” viewpoint about what I should’ve or could’ve done differently, but I will say this: sometimes it is easy to get wrapped up in one task. My personality especially is such that if I start feeling defeated, I keep pressing on the same task until I beat it. In situations where the scope is small and there are only a handful of exploitable vulnerabilities leading to initial compromise, this is often a great use of time. In situations where the scope is large and nearly half of the hosts have some form of vulnerability, spending so much time on one exploit can make the difference between successfully penetrating the environment or not.

So, if you’re a budding penetration tester, my advice would be: If something is taking you an incredible amount of precious time, move on to something else with plans to return later. Examine the other vulnerabilities and exploits available, especially if you know they all lead to an initial compromise once successfully exploited.