Our clients often hire us to as a part of their process for acquiring other businesses. We’ve played a quiet role in the background of some of the largest acquisitions to hit the news and some of the smallest that you’ve never heard of. In general, we’re tasked with determining how well secured the networks of the organization to be acquired are prior to the acquisition. This is important because the acquisitions are often focused on sensitive intellectual property like patents, drug formulas, technology, etc. Its also important because in many cases networks are merged after an acquisition and merging into a vulnerable situation isn’t exactly ideal.
Recently we performed one of these tests for a client but post rather than pre-acquisition. While we can’t (and never would) disclose information that could be used to identify one of our clients, we do share the stories in a redacted and revised format. In this case our client acquired an organization (we’ll call it ACME) because they needed a physical presence to help grow business in that region of the world. ACME alleged that their network had been designed with security best practices in mind and provided our client with several penetration testing reports from three well known vendors to substantiate their claims.
After the acquisition of ACME our client was faced with the daunting task of merging components of ACME’s network into their own. This is when they decided to bring our team in to deliver a Realistic Threat Penetration Test
against ACME’s network. Just for perspective, Realistic Threat Penetration Testing uses a methodology called Real Time Dynamic Testing which is derived from our now infamous zeroday vulnerability research and exploit development practices. In simple terms it allows our team to take deep research-based approach to penetration testing and provides greater depth than traditional penetration testing methodologies.
When we deliver a Realistic Threat Penetration Test we operate just like the bad guys but in a slightly elevated threat context. Unlike standard penetration testing methodologies, Real Time Dynamic Testing can operate entirely devoid of automated vulnerability scanning. This is beneficial from a quality perspective because automated vulnerability scanners produce generally low-quality results. Additionally, automated vulnerability scanners are noisy, increase overall risk of outages and damage, and generally can’t be used in a covert way. When testing in a realistic capacity being discovered is most certainly disadvantageous. As master Sun Tzu said, “All warfare is based on deception”.
When preparing to beach an organization accurate and actionable intelligence is paramount. Good intelligence can often be collected without sending any packets to the target network (passive reconnaissance). Hosts and IP addresses can be discovered using services like those provided by domaintools.com or via google dorks. Services, operating systems, and software versions can be discovered using other tools like censys.io, shodan and others. Internal information can often be extracted by searching forums, historical breaches, or pulling metadata out of available materials on the Internet. An example of how effective passive reconnaissance can be is visible in the work we did for Gizmodo related to their story about Crosscheck.
Using passive reconnaissance against ACME we discovered a total of three externally connectable services. One of those services was a VPN endpoint, the other was a web service listening on port 80, and the other was the same service listening on port 443. According to passive recon the services on 80 and 443 were provided by a web-based database management software package. This was obviously an interesting target and something that shouldn’t be internet exposed. We used a common web browser to connect to the service and were presented with a basic username and password login form. When we tried the default login credentials for this application (admin/admin) they worked.
At this point you might be asking yourself why we were able to identify this vulnerability when the three previous penetration testing reports made no mention of it. As it turns out, this vulnerability would have been undetectable using traditional methodologies that depend on automated vulnerability scanning. This is because the firewall used by ACME was configured to detect and block the IP addresses (for 24 hours) associated with any sort of automated scan. It was not configured to block normal connection attempts. Since we did passive reconnaissance, the first packet we sent to the target was the one that established the connection with the database software. The next series of packets were related to successful authentication.
After using the default credentials to authenticate to the management application, we began exploring the product. We realized that we had full control over a variety of databases that varied from non-sensitive to highly sensitive. These included customer databases, password management, internal chat information, an email archive, and much more. We couldn’t find any known vulnerabilities for the management software, but it didn’t seem particularly well written from a security perspective. In short time we found a vulnerability in an upload function and used that to upload a back door to the system. When we connected to the backdoor, we found that it was running with SYSTEM privileges. What’s even more shocking is that we quickly realized we were on a Domain Controller. Just to be clear, the Internet connectable database management software that was accessible using default credentials was running on a domain controller.
The next step was for us to determine what the impact of our breach was. Before we did that though we exfiltrated the password database from the domain controller for cracking. Then we created a domain admin account called “Netragard” in an attempt to get caught. While we were waiting to get caught by the networking team we proceeded with internal reconnaissance. We quickly realized that we were dealing with a flat network and that not everything on the network was domain connected. So, while our compromise of the domain controller was serious it would not provide us with total control. To accomplish that we needed to compromise other assets.
Unfortunately for ACME this proved to be far too easy of a task. While exploring file shares we found a folder aptly named “Network Passwords”. Sure enough, contained within that folder was an excel spreadsheet containing the credentials for all the other important assets on the network. Using these credentials we were able to rapidly escalate our access and take full control of ACME’s infrastructure including but not limited to its firewall, switches, financial systems, and more.
Here are a few important takeaways from this engagement:
- The penetration testing methodology matters. Methodologies that depend on automated scanners, even if whitelisted, will fail to detect vulnerabilities that won’t be missed by attackers using a hands-on research based approach.
- Default configurations should always be changed as a matter of policy to avoid easy compromise.
- Use two factor authentication for all internet connectable services.
- Do not expose sensitive administrative applications to the internet. Instead, configure a VPN with two factor authentication and use that to access sensitive applications.
- Domain controllers should be treated like Domain controllers and not like web application servers.
- Domain controllers should not be Internet connectable or offer internet connectable services.
- Do not store passwords in documents even if they are encrypted (we can crack them).
- Always doubt your security posture and never allow yourself to feel safe. The moment you feel safe is the moment that you’ve adopted a false sense of security.
The post Industry standard penetration testing and the false sense of security. appeared first on Netragard.
