Key elements of penetration tests that actually work for you.

Everyone seems to have a different idea of what a penetration test is.

Does it involve phishing employees? What about running port scans? Is it just checking for vulnerabilities and reporting them to management? Is the creepy, hooded person just going to “get in” from the outside and tell you what they could steal?

The true answer can include any of those things, but those activities are only so helpful on their own. No matter what a pentest includes (and don’t get me wrong, different environments require different things), it should always be productive. In other words, you should always walk away with a pentest report that you can use to better your security posture.

Here are five key things to look for in your next penetration test report to ensure that you’re receiving the best service possible:

#1: Identified Strengths

Few things are more nerve-racking than letting a professional hacker loose on your environment. Even if you know they’re not going to steal information or install ransomware, you work hard to keep your networks and applications running smoothly and securely. That hard work should be validated in the report.

If a penetration tester can find weaknesses, they should be able to identify strengths. At first, reporting on what parts of a target scope are secured well might seem like a consolation prize, but the real purpose is more meaningful than that.

Reporting on strengths indicates a few things:

  • Penetration testers didn’t just follow a single chain of compromise and call it a day. If there are three potential ways in, it helps to know that they were all tested, not just the first one that worked.
  • Best practices exist that can be applied elsewhere. If the pentester reported rate-limiting as a strength for one of two web APIs, but rate-limiting would have helped protect the other, the strength serves as an implicit improvement step.
  • Security is worth investing in. If there are measures in place that prevented a pentester from attacking other resources or going further into an environment, this is a testament to the effectiveness of existing tools and processes.

#2: Strategic Next Steps

Let’s imagine that, during an engagement, pentesters find a high number of critical vulnerabilities. Several of them resulted in the compromise of a domain controller and those same vulnerabilities exist on a couple of other Windows servers, not to mention most of the user endpoints.

The least a pentester can tell you is which vulnerabilities they found. This is marginally helpful, but simply fixing them is retroactive and doesn’t ensure that you’re insulated against future vulnerabilities.

Fun Fact:

Less than a month passed between the leak of the EternalBlue exploit and the WannaCry ransomware attacks that utilized it. Quarterly vulnerability scanning and patching would not effectively protect against a similar attack in the future.

In this situation, the strategic next step would be to implement a patching program that involves regular updates to key systems.

These sorts of recommendations shouldn’t be riddled with technical jargon. Getting executive buy-in to improve a security program is vital, so having an actual strategy that can be understood (and tracked) is vital also.

#3: Detailed Narratives

The largest section of any risk3sixty pentest report is the attack narrative.

This is the part of the report where we describe everything we did throughout the engagement, from recon and vulnerability scanning to privilege escalation and pivoting.

If the report you receive doesn’t contain a narrative section, you don’t have any guarantee that the pentester you hired did anything substantial. If the narrative that is in the report isn’t detailed enough, replicating what the pentester found will be difficult.

For example, if a pentester finds a SQL injection vulnerability in one of your web applications, they should at least provide:

  1. The vulnerable parameter/field
  2. The payload(s) used to exploit the vulnerability
  3. Screenshots of the exploit succeeding

#4: Technical Vulnerability Inventory

Luckily, many scanning tools can export their results to common formats like XML and be aggregated. We accomplish this with our vulnerability management platform and GRC tool, Phalanx.

Even if a vulnerability isn’t directly relevant to the pentest results (think medium-severity or lower), it still might be something you want to fix. This is especially true if a vulnerability could be leveraged with information an insider would have that a pentester wouldn’t.

For example, if a pentester finds an open SMB share with large amounts of data that hasn’t been used in a long time, it will take them a long time to look through it to find anything interesting. Since there are potentially more severe vectors to check, that pentester moves on. Regardless, they note the open SMB share and include it in the report.

Because you know the contents of that SMB share include sensitive database backups from five years ago, located deep down in a complicated folder structure, you can still triage the issue and remediate it.

Additionally, if a particular vulnerability exists on more than one host or application, all affected targets should be listed to make remediation easier.

#5: Realistic Risk Scoring

When dealing with a long list of findings or vulnerabilities, the most common first step to remediating them is identifying which ones constitute the highest risk.

Scoring frameworks like the Common Vulnerability Scoring System (CVSS) are useful when triaging issues and drafting remediation plans. Though attack names like SQL injection and remote code execution sound scary, context must still be applied to understand the severity.

Consider the following:

  • A SQL injection vulnerability in the front page of a website that dumps the entire table of usernames and passwords:

  • A SQL injection vulnerability in the admin panel of a web application that only dumps database table names while the contents are encrypted:

Both vulnerabilities are important to report, but they don’t constitute the same level of risk. If another vulnerability ranks higher than the second example, it should probably be remediated sooner depending on its nature.

A Final Word

Penetration testers get tunnel vision sometimes. It’s easy (speaking from experience) for them to see a pentesting engagement as a chance to demonstrate hacker bravado, but the only beneficiary of this approach is the pentester’s ego.

Productive hacking goes beyond the act of breaking into an application or system. The results of a quality pentest should clearly communicate risk and assist in building strategies that improve security.

In short, every pentester should do what they can to make the job of the next pentester as difficult as possible. If the path to sustainable security improvement isn’t obvious following a pentest engagement, you might not be getting the return on investment you deserve.

Let’s Get Started

Are you interested in the services of a red team? Not sure where to start with penetration testing? Allow one of our world-class consultants to guide you by contacting us!

Also, if you’d like to know more about what goes on during a risk3sixty penetration test, check out our whitepaper, Pillars of Pentesting: A Guide to the Risk3sixty Attack Strategy.