During Penetration Tests, SecureState’s profiling team attempts to penetrate through an external site’s defenses and gain control of our client’s internal network. This happens all too often. Some of the techniques used by SecureState are password guessing, SQL injection, social engineering, vulnerable web applications, and a seemingly endless list of other vulnerabilities.
Simple Anatomy of a Data Breach
Take the following scenario, Example.com has several websites: a standard web page, a web based email client, Citrix, and a jobs application site. These types of websites are all extremely common in today’s environments. We start by looking around at the various applications and checking patch levels and so on, checking for injection and all at the same time attempting to guess passwords. The most common username schema is first initial last name, such as jdoe. So far example.com is fully patched and practices secure coding. Good for them, but our goal is to penetrate. SecureState selects what would be a guessable password. Depending on what we have seen, we can assume password complexity is being used. That assumption can come from how sites are created; if there is a registration page that enforces complexity, we can assume that complexity is used inside the company as well. SecureState starts brute forcing usernames against the web email client with a password of “Example1” which by definition meets the complexity requirements set by Microsoft in a standard deployment. Any positive logins are then attempted on the Citrix server, and emails are combed for sensitive information that may help aid in further access. We now have access to the Citrix server and are presented with the standard access, a limited user and a desktop. Even if escalating privileges cannot be done, most of the time these types of servers have connection to the internal network. Using the Citrix box as a launch pad, we can start looking at internal machines for vulnerabilities. For this example, we will say we found a missing Microsoft patch which allowed us to gain system level access on a machine. Eventually, the domain will be compromised, and we start our hunt for valuable information.
The Case for Network Segmentation… or Forensics
What went wrong? In essence, it is fairly simple. There was no segmentation that prevented the hop into the internal network. With the large attack surface in the example, getting into a system in the DMZ may have been inevitable. If an attacker compromises the DMZ, it is important to stop them there. Firewalls and segmentation is the key to this. Should a user have unlimited access to the internal network from a Citrix server or VPN? Should a user be able to connect to file shares, internal web applications, or databases? These are questions you need to ask yourself and determine the answers. Maybe, they only need access to one file share and one internal application, not the entire internal network. Only allow the users to see what they need. They probably don’t need to see an open SQL server port. Segment your networks to protect the backbone of your company, ensure you have egress filtering enabled. Does an internal Domain Controller really need to have internet access connection so an attacker can send reverse shells over it? As penetration testers, we love flat networks— it makes our job easy! Thus, if we love it, so do attackers. Don’t fall victim to poor segmentation, unless you would like to use our forensics team.