Everything You Need to Know About an Internal Penetration Test

When most people think about penetration testing, or securing their network in general, they tend to focus on their external perimeter that is exposed to the Internet. But as an organization matures from a security perspective and wants to truly understand their risk, they have to look at their network from other angles. The next most important step here is conducting an internal penetration test. Not only does this help complement external penetration testing by giving you a more clear picture of your risk as a whole, an internal penetration test also helps additional threat vectors that you may not have considered, such as an insider threat or privilege escalation following a breach.

What is an Internal Penetration Test?

So first and foremost, it’s important to understand what an internal penetration test is and what types of questions it can help your organization answer. At a high level, this test starts from within your network, with the attack team plugging in a laptop to test from but they are not provided any credentials. From this position, their goal is to emulate a malicious insider, an adversary that has plugged a malicious device into the network, or an external adversary that has gained an initial foothold on the network. We’ve covered the definition and basics of an internal penetration test in another blog here, and how to decide between an external and internal penetration test, so check those out. But the primary questions answered by this type of assessment are:

• Can an attacker move laterally to other sensitive systems?
• Is an adversary able gain access to the organization’s most sensitive information?
• Can data be exfiltrated without being detected?
• Can an adversary escalate from that initial foothold to “own the network” or become a Domain Administrator?
• How easy is it for them to achieve these goals and what are the easiest ways to reduce this risk?
• How effective are the current preventative and detective security controls?

What is the Typical Methodology for an Internal Penetration Test?

We’ve detailed our full methodology here if you’re interested, but as a brief overview the activities involved in an internal penetration test are similar to that of an external penetration test. Our methodology us based off best practice industry standards, including NIST 800-115, the Penetration Testing Execution Standard (PTES), and Payment Card Industry (PCI) Penetration Testing Guidance (where applicable). We’ll still be going through a discovery and enumeration phase to understand and document the attack surface of your internal network using things like port scans. As a starting point we’ll look to identify weaknesses through vulnerability scans, in order to accelerate the testing time and uncover all the issues present. While a real adversary likely won’t do this because it is very noisy, we want to give you the most bang for your buck in the amount of time we have to test. We’re going to look to identify ALL the vulnerabilities on your network and ALL the different ways we can gain access to sensitive information or administrative control.

In addition to those recognizable activities, there are many additional attack vectors that will need to be explored from the internal perspective. Spoofing attacks are a great example, where we can take advantage of misconfigurations of workstations on the internal network in order to collect password hashes (which can then be taken offline and cracked). Another would be enumerating usernames from the domain controller to facilitate password attacks. Or searching for admin consoles with default credentials. Or searching for open network shares. The list goes on, but you get the idea.

The Different “Flavors” of Internal Penetration Test

The exact methodology and end goal of an internal penetration test can vary slightly depending on the organization, environment, and standard being followed. For example, internal penetration testing in the cloud will have some unique set-up involved, loading a published AMI in your cloud environment or connecting to your environment via VPC. In addition to the setup, a lot of common attacks on a traditional network are going to be ineffective against cloud environments, such as spoofing attacks.

Another “flavor” would be a PCI internal penetration test. For this testing, the attack team would obviously focus on following the prescribed PCI penetration testing guidance. But more than that, the end goal of the assessment is a little more granular in that you are trying to gain access to credit card data specifically. You’ve also go to consider the Cardholder Data Environment (CDE) design in your testing setup, testing critical systems within the CDE but also attempting to break into the CDE from outside networks (through techniques like pivoting).

Most of the other examples of internal penetration testing will simply revolve around the standard chosen, such as NIST or HIPAA, and the organization’s setup and compromise goals. The steps will be roughly the same but tools and techniques will change with defensive measures in place, organizational maturity, and the type of data or access that is the ultimate goal of testing.

What Can Go Wrong During an Internal Penetration Test?

As experienced penetration testers, we have a pretty good idea of what could cause problems on the network and how to avoid them. But anyone that doesn’t tell you there is the potential for problems is lying. Most of these problems can be avoided with an ounce of prevention, which we detail in our article here. The test team is conducting a real penetration test, however, so the short summary is: let your test team know about any old systems on your network that could cause problems if scanned (old switches, old workstations/servers, etc.), any particularly sensitive networked assets (mainframes, printers, SCADA/ICS, etc.), and any of your systems that are absolutely mission critical.

For the mission critical systems, those can usually be scanned and assessed during off-business hours to reduce impact of downtime. The old and sensitive systems may have to skip on a traditional vulnerability scan and be restricted to manual enumeration. There are many ways to further reduce these risks. You just want to avoid your test team finding this stuff out the hard way, and give them a heads-up.

How Much Does an Internal Penetration Test Cost?

The primary factor for determining the cost of an internal penetration test is the size of your internal network, although there may be other factors involved. The size of your network is usually determined by the number of live hosts and devices on your network. In some cases where the workstation population is largely homogeneous, the server count may be important, as well. Both of these numbers are used to adequately allocate a bucket of time to provide you with a thorough and robust internal penetration test.

How Can You Improve The Results of Your First Internal Penetration Test?

The finally item we’ll cover in this blog are some ways that you can improve the results of your first foray into internal penetration testing. Taking care of some of the most common issues that are considered low hanging fruit may allow for your test team to go more in-depth within the time allotted for the assessment. Additionally, fixing or mitigating these issues will provide you a better first time score, with a shorter list of to-do items, more than likely. You can find more detail about each of the issues below, here:

• Turn off Netbios Name Service (NBNS) over TCP/IP on all Windows hosts
• Turn Link-Local Multicast Name Resolution (LLMNR) on all Windows hosts
• Patch your operating systems and the software running on them
• Use unique local administrator passwords across the network (see LAPS)
• Increase your minimum password length required for domain accounts
• Make sure your users are not local administrators on their workstations
• Implement multi-factor authentication (MFA) – at least for administrative accounts!
• Utilize network segmentation to restrict parts of your network.

Hopefully this helped to answer a lot of your questions (or at least point you to the right place to get them answered) about an internal penetration test. If this isn’t something you have done in your organization, it should probably be on your radar and at least a part of your future plans. This will give you valuable information about the risks you face on your network and give you guidance on how to fix these issues, before you become the low hanging fruit and another data breach statistic. Reach out if you have any questions or want to talk about how to get started.