Every credible penetration test follows the same arc: reconnaissance, scanning, exploitation, post-exploitation, and reporting. These five phases come straight out of formal methodologies like the Penetration Testing Execution Standard (PTES), and they exist so that two testers attacking the same target arrive at consistent, defensible results instead of random pokes at a login page.
This post walks through each phase, what the tester is actually doing, and the real tools they reach for. Whether you're scoping your first engagement or reviewing a report, knowing the phases tells you what good work looks like.
The five phases are reconnaissance, scanning, exploitation, post-exploitation, and reporting. They run roughly in order, though good testers loop back, fresh access in post-exploitation often kicks off new recon against internal systems.
Think of it as a funnel. Recon and scanning widen the picture of what exists, exploitation narrows down to what's actually breakable, and post-exploitation plus reporting measure and communicate the damage. This structure mirrors the broader penetration testing methodology that Strobes follows on every engagement.
Reconnaissance is intelligence gathering: the tester maps the target's footprint before touching it aggressively. Passive recon uses OSINT (WHOIS records, certificate transparency logs, LinkedIn, Google dorks) to find subdomains, email formats, and exposed assets without sending a single packet that looks hostile.
Active recon goes a step further, using tools like Amass and subfinder for subdomain enumeration and theHarvester for emails and hosts. The output is a target map: what's exposed, who works there, and where the soft spots probably are. Strong recon is what separates a thorough test from a shallow one, and it's the foundation of attack surface discovery.
Scanning turns the recon map into a precise inventory of live hosts, open ports, services, and versions. nmap is the workhorse here: a scan like nmap -sV -sC -p- target finds open ports, fingerprints service versions, and runs default scripts. For web apps, the tester crawls the site with Burp Suite and fuzzes for hidden paths using ffuf or feroxbuster.
Vulnerability scanners like Nessus, OpenVAS, or Nuclei run here too, flagging candidate issues by matching versions against known CVEs. This is the phase that overlaps most with automated scanning, but a pentester treats the output as leads, not conclusions.
Exploitation is the phase where the tester actually breaks in by turning a candidate vulnerability into real access. This might mean SQL injection with sqlmap, a deserialization bug, a misconfigured S3 bucket, or simply reusing leaked credentials. Metasploit handles known exploits; custom payloads handle the rest.
The discipline here is proof without damage. A good tester demonstrates impact (pulling one record, capturing one session token) rather than dumping a production database. Every successful exploit is documented with the exact request, response, and steps to reproduce, because that's what makes the eventual penetration testing report credible.
Post-exploitation answers the question that actually matters to the business: now that I'm in, how far can I go? The tester escalates privileges, harvests credentials, and moves laterally. On a Windows network that means tools like BloodHound to map attack paths to Domain Admin and Mimikatz to pull credentials from memory.
This is where a single foothold becomes a full compromise, and it's why post-exploitation drives the real risk rating. The tester also tests persistence and measures detection: did the blue team notice? For internal environments, this maps closely to Active Directory penetration testing.
Reporting is the deliverable you actually pay for. The tester converts everything into a prioritized list of findings, each with a severity (scored with CVSS), reproduction steps, evidence, and clear remediation guidance. A good report leads with an executive summary for leadership and a technical section your engineers can act on.
The best reports prioritize by exploitability and business impact, not just raw CVSS, so your team fixes what attackers would actually use first. Many teams now augment point-in-time reports with continuous coverage; see pentesting vs PTaaS vs automated pentesting for how delivery models compare.
