Penetration testing is just like being a cybercriminal, right?

Honestly, it feels weird writing this, however I feel there’s a real issue with penetration testing and some myths that (for understandable and obvious reasons) exist in some people’s minds. So I’ve taken to trying to explain to people what an external penetration test actually entails in the real world of business. So here goes!

What is an external infrastructure penetration test?

The word penetration test is best used as an adjective. Penetration testing (therefore security testing) is an activity/process rather than “a thing or item”. Commonly however the terms are used in a manner that describes as an item. “We had a penetration test” or “we want a penetration test” etc. This however presidents a significant number of challenges. Security testing and assurance comes in possibly a near infinite number of flavours. Traditionally we have types of penetration tests that at a macro level are commonly categorised in manners such as:

External Infrastructure
External Web Application
Internal Wireless Assessment
Internal Network
Mobile Application
Radio
Physical

With these we also have different styles such as:

Black Box
Grey Box
White Box/Crystal Box

When we look at activities, we also must consider test approach e.g.

Objective Based
Use Case Based
Time Boxed

When we consider the scope and rules of engagement of a penetration test, the objectives and test approach options, you hopefully are seeing the breadth, depth, and variables.

The subject and activity of designing and scoping a penetration test can be an activity which may take considerable time and may involve a range of stakeholders. In practise for the majority, however, doesn’t often work out this way, but that’s another blog post.

I will however say this, if you think black box testing is “the BEST” method of pentesting then I’d suggest you be misled. The most efficient (think value for money) method of testing is white box / crystal box from a ability to identify vulnerabilities, it does however come with a caveat that it will more likely create more work around reporting as more will be found, so work out a strategy that suits the outcomes you are trying to achieve thorugh testing (you have documented them right?)

Key Phases and Activities

It should be made clear that there is no single list or path that mandates what MUST be included or what must not be included. The activities listed here are common areas of activity, a tester will generally adjust activity to meet the objectives, timescales, rules of engagement, constraints, and customer requirements.

Common Indsutry Standards include:

PTEST – http://www.pentest-standard.org/
OWAS – https://owasp.org/

What a pentest is

A penetration test is a set of security testing activities looking to identify:

Common Vulnerabilities
Security Misconfigurations
Security Bad Practises
Vulnerabilities with exploitation potential
A view of impact of risk (from a testers perspective)

It is a point in time snapshot based on a tester or testers perspective and is a view that is built up from constraints (e.g. time, knowledge, scope restrictions, perspective restrictions e.g. black box is can be very constraining)

What a petnest is not

A penetration test is NOT a garentee of security. It is not a garentee that you have no vulnerabilities in any component.

What is external infrastructure?

External infrastructure will include:

Server platforms and services such as:
Firewalls
Server/System Management/Administerative Interfaces (SSH, WINRM)
File Services (e.g., SMB)
VPN Services
HTTP Platforms
File Transfer Systems (FTP)
SSH/Telnet
Remote Desktop Protocols (e.g., RDP, Citrix ICA, VNC etc.)
SNMP
Proxies
Mail Services (e.g., SMTP, IMAP, POP3)
Database Services

It’s important here to talk about what is commonly NOT included in scope for external infrastructure testing (there’s a clue in the name):

Web Application Testing
- Limited testing may be conducted to bypass authentication or use obtained logon credentials
API Testing
Denial of Services/Distributed Denial of Service
Load Testing
Phishing and other forms of social engineering
Reverse Engineering (RE)
0-Day Exploit development

Scope

Discuss and Agree Scope
Agree rules of engagement
Define communication plan
Ensure authorisation is signed
Exchange credentials (if grey/white box testing is being conducted)

Recon and Enumeration

Open-Source Intelligence Gathering
Company Research
Breach Searching
Username and Email Enumeration
DNS Enumeration
1. Subdomain Enumeration
TLS Enumeration
Asset Discovery
Threat Modelling
Attack Mapping/Attack Trees/Diagraming
Supply Chain Discovery
Passive Scanning
Active Scanning
Port Scanning
Fingerprinting
Vulnerability Scanning
1. E.g., using NMAP, NESSUS or other automated tools
1. Using manual techniques

Targeting

Environment/System Analysis
Vulnerability Analysis
Payload Creation

Exploitation

It should be noted that whilst a penetration test simulates some activity of criminal activity, it’s a legal activity, it’s conducted with consideration to impact and is not the same as a criminal or nation state threat actor engaging in computer network attacks (CAN) or computer network exploitation (CNE). As such, penetration testing may include high level of comms with internal teams, tests may be skipped due to potential business impact or to suit customer requirements. Activity may also be conducted with a tester and a system admin/developer on hand (or even the SOC the validate monitoring). So, when it comes to exploitation there may be a lot of variance based on tester approach, organisational appetite for risk and consideration to the whole exercise objective and scope.

Vulnerability Exploitation Attempts
Information Disclosure
System Access

Action on Target

If access to systems is obtained a test may include:

Persistence
Data Exfiltration
Demonstration of impact
Privilege Escalation
Lateral Movement

As with the exploitation activates, the systems being tested may be live production systems, it commonly is not appropriate to fire exploits off and to make changes to systems which may affect confidentiality, integrity, or availability (subject to the scope and rules of engagement).

Reporting

The reporting phase is arguably the most vital phase of a penetration test, without this there is no formal documented evidence of testing, findings, and recommendations. Reporting (from my perspective) should be more than just copy and pasting tool output into a custom word document. My approach is to provide appropriate tool output in raw formats where it makes sense to supplement a report). The report is a record keeping and communication tool, reporting is not a two-minute activity.

Report Creation
Quality Assurance
Report Submission

Debrief

Following a testing activity, it is common for a customer debrief to occur. This will typical cover:

The test narrative
Exploitation demonstration
Key findings and recommendations

Clean up

Where appropriate target scope activities may need clean-up activities.
Sensitive data on penetration testing systems will need to be removed

A typical external infrastructure penetration test

We break in and get root everywhere, right? Right?

Think about the scenario and the constraints and scope as described above. These are LIVE systems that are exposed to the internet (and may have been for some time). Now it’s not impossible, but if the systems are significantly vulnerable and exploitable from an external network perspective that they would already be compromised if they have commonly exploitable vulnerabilities facing the internet.

When it comes to exposed services such as RDP, Microsoft say the average brute force “attack” lasts 2-3 days.

So, excluding findings a known remote code execution vulnerability where a public exploit exists the likely methods for gaining access will involve authentication attacks.

For a simulated attack (we are pentesting) to be successful it requires:

A vulnerable service
Controls such as account lockout or IPS/firewalls not being configured to respond
The tester having a valid username
The testing having valid credentials

It’s not in my experience common to find this scenario in a position where you are conducting a controlled test in a black box scenario with scope limitations (scope limitation are there to protect the tester and the organisation as well as ensure the testing is not service disrupting).

Common Findings

Ok so it’s possible but not highly likely an external penetration test will give the tester system/r00t access from a time and scope constrained position.

Typically, the activity and findings will be focused on this space:

Open-Source Intelligence
Asset Discovery
Attack Surface Enumeration
DNS Mail Security
- SPF/DMARC/DKIM
DNS Subdomain Enumeration
- DNS Vulnerabilities e.g., Subdomain Takeovers
Sensitive Information Disclosure
Email and Username enumeration
- Clear Web
- Dark Web
- Breach Data
Identification of transport layer security weaknesses
Identification of platform versions and applications
- Identification of unpatched or out of support systems
Detection of IPS/Web Application Firewalls
- Attempting to bypass these
Identification of control gaps
- E.g., lack of CDN/WAF/IPS
- Lack of MFA
- Username enumeration through features such as forgotten password functions or password reset functions
Vulnerability Identification through automated scanning tools
Vulnerability identification through manual discovery and assessment
Limited authentication testing (subject to scope)
- Credential Stuffing
- Password Spraying
- Brute Force (if agreed and often when test accounts have been supplied)

It’s not to say you can’t find a weakness that exploits to access ever, it’s just not very common (especially during limited time testing windows).

Summary

Hopefully this post helps people understand the realities of penetration testing from an external infrastructure perspective and helps people be aware of the benefits, constraints and realities of likely findings.

Penetration testing is NOT the only security assurance activity, it’s not always the right tool for the job. Don’t forget activities such as:

Vulnerability Assessments
Configuration Audits & Health Checks
Code Reviews
Dynamic Analysis/Static Analysis
Purple Team Activities
System Security Architecture Reviews
Control On/Off Testing
Red Team/Tiger Team Assessments
Attack Simulation/Attack Emulation
Scenario Based War Games
Table Top Excercises

Penetration testing activity is a great tool in the toolbox but it’s only one of many and it’s an activity not an item. If you want to have a strong security posture, it’s important you understand the strengths and weaknesses of different approaches as well as being realistic with expectations. If you are expecting to get wrecked from an external infrastructure test then you should probably do some threat hunting, some system hardening and invest your effort in other spaces because it would be likely a wiser move. Penetration testing should support your security assurance program that includes, governance, management, policies, processes, procedures and practises. A penetration test should be far down the list and should be a component of your service lifecycle, not the whole of your security assurance and defence activities!

Peer Review and Feedback

I gave the password to this post to a few well respected industry colleagues who gave feedback such as:

Thats really good – its basically a course in a post
@tazwake SANS instructor/author. CPP CISSP (etc) certified

I like the focus on recon – often overlooked by people rushing to pwn
@tazwake

I really like how you sectioned off the definitions of different phases, tech, etc in pentests and what to expect
@shotgunner101 Computer Security Professional

UK NCSC Active Cyber Defence (ACD)

How to use Putty as a SOCKS Proxy