How To Scope a Penetration Test (The Right Way)

How To Scope a Penetration Test (The Right Way)

Dissecting The Twitter Hack With A Cybersecurity Evangelist final

How to Define the Scope of Your Next Pentest Engagement

One of the most important factors in the success of a penetration test is its scope.  Scope limitations are an understandable and even common desire.  However, they can make the results of a pentest worse than useless by providing a false sense of security.  Read on to learn why it is important to work with and trust your pentest provider when scoping your next pentest engagement.

How to Scope a Penetration Test Flow

Scope Limitation

One of the common challenges encountered when defining the terms of a penetration test is scope limitation.  When defining what techniques and systems are “fair game” and which ones are “off limits”, many organizations often narrow the scope of the engagement too far.

In some cases, implementing scope limitations make sense.  For example, limiting the use of destructive techniques on production systems is an understandable limitation since they can negatively impact business operations.

However, other scope limitations are more harmful than helpful.  A common example of this is forbidding the use of social engineering during a penetration test to avoid hurting the feelings of employees that might fall for the attack.  Since social engineering is one of the tactics most commonly used by cybercriminals, ignoring it as a potential attack vector places the company at risk.

Scope limitations enable an organization to decrease the cost of a penetration test and avoid uncomfortable attack vectors.  However, this comes at the cost of the effectiveness of the exercise and the accuracy of the results.

The Crown Jewels

Often, customers will focus on their “crown jewels” when defining the scope of their pentest engagement.  This focus on the security of the crown jewels makes perfect sense since these databases and systems are essential to the company’s ability to do business.  Additionally, like the layers of an onion, the further you go from the core (crowned jewels), the larger the scope can get and the more expensive the pentest engagement can become.

The problem is that, while limiting the scope of an engagement to a few security-hardened servers may be sufficient for compliance purposes, it could also give a false sense of security.

Inside the Head of an Attacker

Attackers are lazy. They will almost always choose the path of least resistance.

Compromise rarely begins by attacking directly a fully-patched Active Directory server. Creating a zero-day exploit is time-consuming, expensive, and not worth the effort for attacking most organizations.

Instead, an attacker will likely start their search for an entry point by looking at an organization’s legacy systems.  Even if these systems contain little of value, they are more likely to contain vulnerabilities that make it easier for an attacker to compromise them.  Once they have established a foothold inside the network, it is much easier for an attacker to move laterally within the network and pivot to better-secured systems.

We take the same approach when planning and performing a penetration test.  Any vulnerability scanner can check to see if your “crown jewel” systems have an exploitable vulnerability, and you’ve probably already performed the scan and fixed the issues before calling us in.  As penetration testers, we look for the easy but often-overlooked attack vectors that a real attacker is likely to take advantage of.  In the past, we’ve fully compromised networks via printers, IoT devices, legacy systems ready to be decommissioned, etc.

Your Network is Only as Secure as Your Least Secure Asset

If you don’t believe this, take a look at these two real-world examples from previous penetration testing engagements.

From a Public Printer to Full Control

One pentest engagement started with an audit of the security of an organization’s open guest network and ended with full access to the domain.

From this guest network, we connected to an MFP printer that was configured with an email account to be able to send scanner documents via email.  It turned out that the email account was also a valid domain user account.  We also established that this user account was added to the “Remote Access” domain group.

Using that compromised account, we were then able to connect to the corporate VPN (no 2FA), after discovering a few configuration files accessible in open network shares.  We were able to pivot, escalate privilege and gain full admin access to the domain.

All this from an insecure printer connected to the guest WiFi network…

Taking Advantage of Legacy Applications

From a legacy application, we managed to compromise the corporate network of a client (SaaS provider).

The corporate network was only used for office applications, and all their SaaS applications were hosted by a separate cloud provider. They put a lot of thought and effort into segmenting the corporate network (less critical) from their SaaS network (hosting all their customers’ information).

However, having access to the corporate environment, we also had access to their emails. We then proceeded to reset the password of one of their users that had access to the cloud provider hosting their SaaS environment. By timing the attack, we were able to recover the password reset link from that user’s email and reset his password on the cloud service provider.

This granted us access to the support ticket system for that cloud provider, and, browsing through the old tickets, we found several VPN configurations (including credentials and seeds to generate OTP for 2FA).

In the end, from a legacy application, we were able to pivot through the corporate network, gain access to the email server, and then pivot again to their cloud service provider.

Properly Scoping a Pentest Engagement

Engaging with a service provider for a penetration test requires trust in that provider.  No network is 100% secure, which means – with high probability – a good pentester will be able to find a vulnerability that gives them access to and control over your network, systems, and data.

If you trust your pentest provider with that level of access, it makes sense to trust them to help you to define the scope of your engagement with them.  Sit down with your provider and tell them your vision for the engagement, then ask for their opinion.  If there are things that you are wanting to place “out of scope”, a good pentester should be able to tell you the associated risks and help you to make an informed decision.

A pentest engagement should be a partnership, and this includes the planning stages of the engagement.  If, when talking to a potential provider, you don’t feel comfortable with letting them help you define the scope of the engagement (based upon their knowledge and experience), then don’t let them anywhere near your networks.