unicornAll work
← All theoryFoundations

Stages of a pentest

Scope, recon, scanning, exploitation, post-exploitation, reporting — the repeatable method.

In a nutshell A penetration test isn't random button-mashing — it follows the same stages every time: agree the scope, gather information, find weak spots, get in, dig deeper, and write it all up. Knowing the stages means you always know what to do next, even on a target you've never seen.

01Scope02Recon03Scan04Exploit05Post06Report loops back — each machine feeds new recon
A pipeline that loops: post-exploitation of one host becomes recon for the next.

Why a method at all

Under pressure it's tempting to jump straight to "hacking." But without a method you miss things, repeat yourself, and can't hand the work to anyone else. The stages are a map: each one has a goal and feeds the next.

Analogy — a burglar casing a house. First they learn the neighbourhood and which house (scope + recon), then walk around checking doors and windows (scanning), then find the unlocked one (exploitation), then look for the safe and spare keys inside (post-exploitation), and — for a legal pentest — leave a note listing every way in so the owner can fix it (reporting).

The stages

  1. Scoping & rules of engagement. Before anything. What's allowed, what's off-limits, when, and in writing. Testing outside scope isn't a pentest — it's a crime. This is the step that separates a professional from an attacker.
  2. Reconnaissance. Learn the target: domains, IPs, employees, tech used. Passive first (public sources, no touching), then active. See Network recon utilities and OSINT basics.
  3. Scanning & enumeration. Touch the target methodically: which hosts are up, which ports open, which services and versions (nmap), which web paths exist (directory brute-forcing). Enumeration is where most findings actually come from — the patient squeezing of detail out of every service.
  4. Exploitation. Turn a weakness into access: a vulnerable service, a weak login, an injectable form.
  5. Post-exploitation. You're in — now what? Escalate privileges (see Privilege escalation), find other reachable machines (pivoting), and show what a real attacker could steal.
  6. Reporting. The actual product. Every finding, how to reproduce it, how bad it is, and how to fix it — written so both an engineer and a manager understand.

The same acts, a different name

The techniques a pentester uses are identical to an attacker's. Exactly one thing separates them — and it's not skill:

Attacker

  • no permission
  • hides tracks, avoids logs
  • keeps access, causes harm
  • goal: profit / damage

Pentester

  • written authorization + scope
  • documents everything, preserves logs
  • reports and helps fix
  • goal: reduce the owner's risk

Named methodologies

You'll meet formal frameworks that put flesh on these bones: PTES (Penetration Testing Execution Standard), the OSSTMM, and for web specifically the OWASP Testing Guide. They differ in detail but all follow the same recon → exploit → report spine.

The stage people skip Beginners rush to exploitation and treat reporting as an afterthought. In real work it's reversed: a client pays for the report, not the root shell. A finding you can't explain and can't help fix is worthless — and unexplained access you can't reproduce isn't even a finding.

The mindset

The goal isn't "root" for its own sake — it's to show the owner realistic risk and how to remove it. Methodology is what turns a lucky break into a repeatable, defensible result you can put your name on.

All theory