Penetration Testing Phases and Methodology: A Practitioner Reference

Professional penetration testing follows a structured sequence that maps roughly to how real attackers operate, with the critical addition of documentation and authorization at every step.

Phase 1 — Scoping and Rules of Engagement: Before any testing begins, the engagement scope is defined in writing: which IP ranges, domains, applications, and physical locations are in scope; which are explicitly out of scope; what techniques are authorized (social engineering, physical access, destructive testing); notification requirements (who must be informed before testing begins); and emergency contacts if critical systems are inadvertently affected. This document, signed by both parties, is what distinguishes authorized penetration testing from criminal activity.

Phase 2 — Reconnaissance: Passive and active information gathering about the target. Passive reconnaissance uses OSINT sources (WHOIS, certificate transparency, LinkedIn, Shodan, DNS enumeration) without touching target systems. Active reconnaissance initiates contact with target systems: port scanning, service enumeration, and web crawling. The intelligence gathered here drives all subsequent phases.

Phase 3 — Scanning and Enumeration: Systematic mapping of discovered attack surface. Network scanning (Nmap for host discovery, port identification, and service fingerprinting), vulnerability scanning (Nessus, OpenVAS, or Nuclei for known vulnerability identification), and application enumeration (directory brute-forcing, API endpoint discovery, authentication mechanism identification).

Phase 4 — Exploitation: Attempting to leverage identified vulnerabilities to gain unauthorized access. This is where penetration testing diverges most clearly from vulnerability assessment — testers actively attempt exploitation, not just identification. Exploitation may chain multiple vulnerabilities (low-severity misconfiguration plus known CVE plus credential reuse) to demonstrate realistic attack paths.

Phase 5 — Post-Exploitation: After gaining initial access, demonstrating the impact of that access. This includes privilege escalation, lateral movement, persistence establishment, data access, and exfiltration simulation. Post-exploitation is often where the most valuable findings emerge — the difference between what a vulnerability theoretically enables and what an attacker could realistically accomplish.

Phase 6 — Reporting: Documentation of all findings with evidence, business impact analysis, CVSS scoring, and remediation guidance. The report is the deliverable that provides lasting value after the engagement concludes.

Three frameworks dominate professional penetration testing methodology, each with different emphases and use cases.

The Penetration Testing Execution Standard (PTES) is the most comprehensive methodology for general-purpose enterprise penetration testing. It covers intelligence gathering, threat modeling, exploitation, post-exploitation, and reporting in detail. PTES is practitioner-authored and reflects real-world attack progression rather than theoretical frameworks. Its weakness is limited maintenance since its initial publication.

The OWASP Web Security Testing Guide (WSTG) v4.2 is the authoritative methodology for web application penetration testing. It covers 91 distinct test cases across authentication, authorization, input validation, error handling, cryptography, and business logic. For application security teams, WSTG is the de facto standard. Its test case format provides clear pass/fail criteria that map to specific vulnerability classes and CWEs.

NIST SP 800-115 is the framework of record for federal and regulated industry penetration testing. It emphasizes documentation, authorization procedures, and risk assessment integration that compliance programs require. It is less technically detailed than PTES or WSTG but provides the process rigor that auditors expect.

For most enterprise engagements, practitioners use PTES as the overarching methodology, WSTG for web application components, and NIST 800-115 for compliance documentation requirements.

The quality of a penetration test is determined by the tester's skill in interpreting and chaining findings — not by the tools themselves. That said, specific tools have become standard for each phase because they produce reliable, reproducible results.

Reconnaissance: Maltego (relationship mapping and OSINT pivoting), Shodan and Censys (internet exposure intelligence), theHarvester (email and subdomain enumeration), Amass (comprehensive DNS reconnaissance and asset discovery).

Scanning and Enumeration: Nmap (network discovery and service identification, the universal baseline), Nessus or OpenVAS (vulnerability identification), Nikto (web server misconfiguration detection), Gobuster or FFuf (directory and endpoint brute-forcing), Nuclei (template-based vulnerability scanning with community-maintained check library).

Exploitation: Metasploit Framework (exploit development and delivery platform, post-exploitation modules), Burp Suite Professional (web application attack platform, the standard for application testing), CrackMapExec (Windows network exploitation and lateral movement), Impacket (Python library for Windows protocol exploitation, particularly useful for SMB and Kerberos attacks).

Post-Exploitation and Privilege Escalation: BloodHound (Active Directory attack path analysis), Mimikatz (credential extraction from Windows memory — requires appropriate authorization), PowerSploit and PowerView (PowerShell-based AD enumeration and exploitation), LinPEAS and WinPEAS (automated privilege escalation enumeration on Linux and Windows respectively), Cobalt Strike (commercial C2 framework for advanced adversary simulation — typically reserved for red team engagements rather than standard penetration tests).

The scope of a penetration test determines what you learn from it. Poorly scoped engagements produce findings that do not reflect real attack risk; well-scoped engagements surface the vulnerabilities that matter most to your specific threat model.

Test type selection is the first scoping decision: black box (no prior knowledge, simulating an external attacker with no insider information), grey box (partial knowledge such as network diagrams, application documentation, or a standard user account), or white box (full knowledge including source code, architecture diagrams, and internal credentials). Black box tests are most realistic for external attacker simulation but are the least time-efficient — testers spend significant time on reconnaissance that defenders could shortcut. White box tests are most comprehensive for finding all vulnerabilities in an application. Grey box tests balance realism with efficiency for most enterprise engagements.

Scope exclusions are as important as inclusions. Systems that cannot tolerate testing (production databases, OT/ICS equipment, real-time safety systems) should be explicitly excluded with documented justification. Vague exclusions like 'do not cause outages' are not testable and create liability ambiguity — specify exactly which systems are excluded and why.

Authentication scope determines whether the test includes pre-authentication attack surface (what can an unauthenticated attacker do?) and/or post-authentication testing (given a legitimate user account, what can they access that they should not?). Both should be included in comprehensive application security assessments.

The penetration test report is the output that provides lasting value, and report quality varies enormously across testing providers. Before committing to a firm, request a sample report from a previous engagement (redacted for client confidentiality) and evaluate it against these criteria.

Findings should include: vulnerability title, affected system or component, CVSS base score with the justification for each metric, step-by-step reproduction instructions with screenshots or tool output as evidence, business impact narrative explaining what an attacker could accomplish using the finding, and specific remediation guidance with the exact configuration change or patch required.

Findings that lack reproduction evidence are not findings — they are hypotheses. A vulnerability listed without a screenshot showing successful exploitation, or a tool output demonstrating exploitability, cannot be independently verified and should not receive the same priority as evidenced findings.

The executive summary should communicate business risk, not technical findings. A summary that leads with CVE numbers and CVSS scores is not written for executive decision-makers. The summary should explain what the engagement's most significant findings mean for the organization in business terms: what data could be accessed, what operations could be disrupted, and what the priority remediation actions are.

Remediation guidance must be specific and actionable. 'Update all software to the latest version' is not remediation guidance. The specific package, the specific configuration change, or the specific architectural mitigation — with a reference to the vendor's fix documentation — is remediation guidance.