Challenges of Procuring Penetration Tests

Organizations change continuously and it’s harder than ever to know what the current status quo looks like. Many are looking at penetration tests to help solve the problem of uncertainty, allowing an external team to assess the situation and provide pointers on where defensive focus must be made, e.g. patching, segmentation and vulnerabilities in general.

The high-level methodology of penetration testing constitutes reconnaissance, discovery, scanning and exploitation.

Unfortunately, procuring an off-the-shelf penetration test has many challenges attributed to it. With experience from both sides both procuring penetration tests, and delivering hundreds of penetration tests to clients, the challenges became evident. For example, as a client there’s the following issues when procuring a penetration test:

• You don’t necessarily know what the scope of a motivated attacker would be. You might have ideas of what your attack surface looks like, but what about shadow IT and other assets and services you don’t know about? They all expose your risks to the outside world like everything else.
• You don’t necessarily understand how attackers operate, hence you’re not the best to state what work penetration testers should perform.

What about the challenges the penetration testing team have during engagements? They have also gotten used to several cumbersome problems during engagements:

Sponsorships Available

Sponsorships Available

Sponsorships Available

• The scope of the engagement is either set by the client, or during scoping meetings. However, this is not how attackers work. Often, penetration testers will identify assets they would like to test after the engagement starts, turning it into a scope-creep situation, making the situation potentially sour for both the client and the testers. These scoping meetings also tend to drag out and delay the process.
• The scope often depends on how much the client is willing to invest, and most companies can’t accept everything as part of the scope. The question is, how do you prioritize which assets to keep in scope and which to exclude? And what will the price tag be?
• Often the client wants to focus on a selected few applications, instead of real-world scenarios.

As you might’ve guessed, I present a solution to the problems above. A proposed change to an old methodology, practiced by hundreds of companies. It’s not complex and in it’s simplicity lies the elegance.

A more efficient way of doing penetration tests

For a motivated attacker, the most valuable phase of a penetration test is the reconnaissance, discovery and scanning. As the most valuable phase, it’s also the most overlooked and ignored phase, due to issues with scoping as mentioned in the previous section. Since attackers commonly break in via the path least traveled, often unmaintained assets clients do not already know about or weren’t properly managed, it comes down to penetration testers to provide the best overview of the target company in advance of a penetration test.

By splitting a penetration test into two deliveries, one where the digital footprint is mapped out, and a second, where the actual penetration test is done, both sides of the engagement are improved. A report on the digital footprint, that is, a report containing results from the reconnaissance, discovery and scanning processes in advance of starting a penetration testing engagement, provides incredible value in many ways.

Let’s look at some of the great benefits of doing a multi-part delivery of a penetration test, providing the results of reconnaissance, discovery and scanning in a separate report.

The client will be able to pick and choose which assets they consider in-scope. Perhaps most importantly, the client will be able to make a conscious decision on which assets not to include in scope. The client might have ideas on what to include in scope, but with the advent of a Digital Footprint report, their opinions might change.

Often, by just doing OSINT (Open Source Intelligence Gathering), vulnerabilities are identified. By simply just looking for the target organization’s assets, you might find leaked credentials, sensitive information indexed by search engines and systems that are clearly not maintained and look juicy and vulnerable to a penetration tester. When identifying a client’s digital footprint, almost every time, the client is left with actionable things to fix in advance of a penetration test.

Allowing the client earlier returns on the investment is great and having them fix the low-hanging vulnerabilities before the penetration test starts is a good idea too. That way the penetration testers can focus on the more advanced and harder to exploit findings.

Doing the split in the engagement allows clients to easier commit to having work done. Doing reconnaissance, discovery and scanning doesn’t include that much effort from the penetration testers, hence it will be cheaper and more affordable for clients to start engaging with the team and getting actionable results in the process.

For organizations whom want to have the entire scope tested, it’s now easier to guarantee that it has in fact been tested, as the digital footprint is handed over in advance, it’s also easier to agree on the price of having everything in scope.

Finally, having a 3^rd party propose their understanding of an organization’s attack surface is greatly valuable. It’s also much more convenient for the penetration testers while they do their work. Less scope-creep, a better understanding of the scope of work, and even the opportunity for fixed pricing engagements is an all around win-win for all parties involved.

What should a report on the Digital Footprint contain?

The report can contain many things, ranging from servers, services, technologies, leaked credentials and more. In this section I’ll describe the different elements you might add to such a report. I’ll leave it to you on what type of design and presentation you go for.

Technical Summary

Start with the right side up; the most important facts and findings from the activities. It might not be a lot, but if there’s something, list it here. Typical discoveries to include here would also be things like:

• Malicious domains identified, e.g. phishing domains, look-a-like domains and similar.
• Any vulnerabilities identified, even though no penetration testing activity was done yet, sometimes you still find vulnerabilities.
• Any leaked credentials found.
• Any other information that can be used against the company in the event of a hacker attacking them.

You want to share as much actionable information as you can. What can the company do to better ready themselves for an incoming penetration test? It’s also a good idea to include some statistics in this section, summing up what has been identified as the total attack surface.

Server Asset Overview

This is where you want to produce a nice and detailed overview of all the domains and IP-addresses you find which are hosting services for the target company. I like to break this into an overview of:

• Provider, e.g. Amazon, Telenor, Rackspace
  • IP-address
• Domain
• Comment from tester
• Estimated size

Under each provider I would list all the different IP-addresses and domains if applicable. The comments help the penetration tester provide value in how they consider the systems attack surface. In terms of estimating size, I suggest you set up a qualitative way of defining if an asset is considered micro, small, medium, large or extra-large. This can then be used to provide fixed pricing schemes, if that is what your team and client prefers.

Color coding can help here as well. E.g. marking assets in red, yellow, green or white for how critical or how high priority the asset is to be included in scope. This could be used as a working document between you and your client to find the appropriate scope for this engagement.

Emails and Personal Data

In this section I like to highlight a couple of things. Primarily I want to list out the employees of the company, their emails and what type of role they have in the company. I split the roles into 3 different areas, each which have their own kind of attack surface, and should be addressed differently in attacks:

• Management and management related functions, e.g. executive assistants.
• IT, developers, security and similar personnel.
• Receptionists, customer support and other support roles.
• Other roles not contained in the previous functions.

Especially IT specific roles have an interesting attack surface for hackers. You might target them more directly in terms of looking for blog posts, stack overflow accounts, code repositories and more. I like to highlight the different roles with color codes, allowing a better visualization of the functions.

You also want to identify any shared email accounts which have been identified, and might pose a risk of having weak passwords or other threats. Typical accounts you might find are:

• incoming@
• sales@
• post@
• security@

You should also do your best in showing which accounts have leaked credentials. Depending on your engagement, you might extend this into employee’s private accounts, if you’ve identified those emails too.

Mobile Applications

Apps developed and used by the company should also be listed as part of the potential attack surface of companies. Many applications have direct connections via API’s to the internals of the organization, or the applications pose risks if credentials are lost, e.g. a mobile device management solution allowing devices to be managed without authorization.

Social Media Accounts

Yes, these are also considered a prominent attack vector for some attackers. Can you imagine the pain of having attackers log into your social media account, using the password “CompanyName123!”, allowing the attacker to communicate to all of your 20.000 followers? It’s important to keep social media accounts under a good lock down, especially those whom require a company specific login, and is not tied to other individual user accounts.

Other

In a digital footprint report you can include many things, just make sure what you include is high quality and of use for the target organization. You might discover sensitive information exposed like budget plans, blueprints or configurations. These things would be obvious to share with the client.

Closing

By utilizing win/win relationships between providers and clients, better and more efficient ways of testing can happen. If the procuring company can take on a slight risk in onboarding a digital footprint report in advance of a penetration test, the engagements are much more likely to be mutually beneficial. Onboarding a company to assess the digital footprint is in fact convenient, as you will be able to test your provider in advance of using them for more complex and thorough penetration testing engagements.