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 –
  • OWAS –

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


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

Recon and Enumeration

  1. Open-Source Intelligence Gathering
  2. Company Research
  3. Breach Searching
  4. Username and Email Enumeration
  5. DNS Enumeration
    1. Subdomain Enumeration
  6. TLS Enumeration
  7. Asset Discovery
  8. Threat Modelling
  9. Attack Mapping/Attack Trees/Diagraming
  10. Supply Chain Discovery
  11. Passive Scanning
  12. Active Scanning
  13. Port Scanning
  14. Fingerprinting
  15. Vulnerability Scanning
    1. E.g., using NMAP, NESSUS or other automated tools
    1. Using manual techniques


  1. Environment/System Analysis
  2. Vulnerability Analysis
  3. Payload Creation


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.

  1. Vulnerability Exploitation Attempts
  2. Information Disclosure
  3. System Access

Action on Target

If access to systems is obtained a test may include:

  1. Persistence
  2. Data Exfiltration
  3. Demonstration of impact
  4. Privilege Escalation
  5. 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).


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.

  1. Report Creation
  2. Quality Assurance
  3. Report Submission


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:

  1. A vulnerable service
  2. Controls such as account lockout or IPS/firewalls not being configured to respond
  3. The tester having a valid username
  4. 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
  • 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).


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


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

@shotgunner101 Computer Security Professional