How to Scope a Network Penetration Test: Tips from an Expert Pentester

During a network pentest engagement, time is of the essence. A penetration tester has a fixed amount of time, typically two weeks, to evaluate an application. The key to meeting that deadline while delivering the highest quality test is proper scoping.

In my work with Cobalt and their variety of different customers, I’ve seen several ways to scope a network pentest as well as the impact these methods have had on testing results.

Based on that vast experience, the following are three tips for how to improve scoping your pentests:

1. Understand the Customer’s Priorities

No network pentest project can cover everything. If a large number of ports must be tested in a limited timeframe, it’s impossible to perform in-depth testing on each one.

Instead, take the time to understand why you’re performing the particular test and what your priorities are. For example, are you testing as part of an effort to comply with SOC 2? Do you need to look at a new feature or application? Are you aiming to secure sensitive data or ensure your security controls are actually secure? If you’re testing for SOC 2, you’ll include all of the assets that are in scope for your audit. But when you evaluate a new feature or application, you should focus your pentesting cycles on what’s new.

Next, think about what are the most important, IPs, ports or services that need to be tested. Knowing this, the pentester can take a more in-depth approach when testing these “crown jewels,” investigating multiple payloads, analyzing all the services running on them, performing edge case tests, testing additional endpoints, enumerating the target, and so on.

Scoping also helps manage expectations. You may want confirmation that the pentester has done all the testing. Without careful scoping, it’s difficult for them to give you a definitive answer. Even if the test covers all the required IP addresses, the pentester may be unable to test each one comprehensively. With a clear scope, you can be confident that you’re on the same page with the pentester and that they will thoroughly test what’s most important to you.

2. Determine how many IP addresses to assign to each pentester

Once you’ve determined what you’ll be testing, the pentester will need to assign testers to the project. How many individuals are needed? In my experience, 100 IP addresses per individual pentester is a manageable number. But that doesn’t mean that if you’re testing 800 IP addresses, the pentester will need 8 testers.

For starters, not all of the 800 IP addresses will require extensive testing since not all will have a significant attack surface. Some IP addresses might only host a couple of ports or services that are only exploitable in the event of a zero-day attack, which is extremely rare. I generally assume that about half of the ports will require minimal testing, leaving the rest for more extensive exploration. So, if I’m manually testing 800 IP addresses, I’d need about 4 pentesters.

I often prefer manual testing. But pentesters can cover more ports with fewer people — perhaps eliminating one of the pentesters — if they automate some of the initial reconnaissance and overall scope discovery. But there are security risks. Some automated tools cannot interpret custom protocols or custom webservices. When those tools encounter anomalies they can’t interpret, they may give a false positive or no results at all.

3. Consider whether your pentest is internal or external

The type of testing performed and the number of testers necessary will vary depending on whether the test will be looking at internal- or external-facing resources.

Generally, internal resources require more extensive testing, which means the pentester will need to assign each individual tester to fewer hosts. Here’s why. Almost all internal networks use Active Directory. When Active Directory is attacked, a breach of one component of the network can impact the entire network, including all communications, IP addresses, and servers as well as other connected networks. Therefore, testing internal networks requires a larger scope and a more complex approach.

Because of the greater complexity of internal pentests, I recommend that you involve the pentesters in the scope definition process so they can ask you about your vision and how they should approach the testing. For instance, pentesters may ask you whether to do a simple vulnerability scan or take a more advanced, stealth approach to see if your monitoring systems will detect the pentester as they travel inside the network.

External pentests, in contrast, are often faster and easier, and usually require fewer pentesters for several reasons. External IP addresses are usually less exposed. They don’t typically offer as many services as internal hosts so testing can cover more of them more quickly. And there’s a good chance you have already done a few pentests that have covered some of the targets.

One word of caution, however. If you determine that a large number of previously tested IP addresses are in scope, the pentester will need more testers. When a target has already been tested, it will require a more in-depth look because previous tests will have picked up all the “low hanging fruits” that are relatively easy to find. The pentester will need to perform more granular tests to dig deeper into these ports and services to find issues.

Pulling Network Security Together: An Example of a Recent Network Pentest

Now let’s look at how Cobalt scoped and implemented a recent pentest so you can see how all the pieces fits together.

We started by scoping the project. In this particular case, we had around 800 IP addresses to test with three pentesters for execution over a two-week period.

We decided to start from an external attacker’s perspective, targeting issues that would have the highest impact, for example, looking for default credentials for web servers or web applications exposed to unauthorized access. With that in mind, we would try to access the Web server to breach the underlying system.

Next, we executed the test. We initially divided up the IP addresses into three groups and assigned them to the testers. For each group, we defined specific initial tests. For each IP, we started by testing any web applications, then the common web service ports, and finally additional common ports that might be vulnerable to publicly known exploits. In parallel, we did a slow scan on all the ports for all the IP addresses in scope to give everyone a complete perspective. As a result, we found numerous web applications that were vulnerable to cyberattacks like SQL Injection and found many web servers with default credentials that provided us with access to the OS.

Usually in projects like this, we see services interacting with each other and add tests of those interactions to the scope of those particular services and IP addresses. But in this case, the IP addresses weren’t linked. The point is, the pentester should adjust their testing to take their findings into consideration. They can’t simply make a list of services or ports that face the internet or perform tests based on what they think the scope should be.

During testing we also took advantage of several methodologies to simplify and streamline our efforts. Because we had a lot of IP addresses to test, we limited network traffic. Since the scope was large, if the client’s internal teams were monitoring the network traffic, that monitoring would have added noise that could have hidden some of the malicious traffic. In addition, because we were evaluating the network from a single virtual machine, we had to limit the traffic to prevent network throttling. Moreover, the machine we used inside the network as a pivot to identify critical services and resources to attack was a virtual machine, and therefore had limited processing power.

We also developed a tool that could access the web application and take a screenshot of the front page so we could see what could be hosted on the web app — whether that was a default webserver or a custom-made web application.

Conclusion

Pentesting any network is a complex process. To ensure the test meets your timeframe and improves your security posture, you need to work closely with your pentester to define the appropriate project scope.

For more information on how Cobalt can help you scope a pentest contact us today or schedule a demo of the Cobalt Pentest as a Service Platform.