Pentest Methodology & Recon · beginner · ~12 min
**What you will learn** - Name and order the phases of a professional penetration test, from reconnaissance through remediation and retest, and describe what each phase *produces*. - Explain why the methodology is **iterative** (you loop back) and **evidence-driven** (every claim is backed by reproducible proof). - Tell recon apart from enumeration, and validation apart from scanning — and know why confusing them produces false findings. - Map each phase to the defensive side: which logs and alerts a blue team uses to *detect* that phase happening. - Keep every phase inside authorization and scope, and know the cleanup/reset steps a lab engagement requires. - Understand where post-exploitation stops: measuring impact, never causing destruction.
Security objective. This lesson protects the client's systems and data. The threat is an unauthorized attacker who works through the same stages a tester does — but without permission and without stopping to measure impact safely. As a learner you will build a repeatable mental map of those stages so you can (a) test a system you are authorized to test in a way that is thorough and defensible, and (b) recognise, from the defender's seat, which stage an attacker is in by the traces they leave.
A penetration test is not random poking. It moves through a fixed sequence of phases:
recon → enumeration → vulnerability discovery → exploitation →
privilege escalation → post-exploitation → evidence →
risk rating → reporting → remediation / retest
The process is iterative — new information sends you back to an earlier phase — and evidence-driven — nothing goes in the report without proof you can reproduce.
This builds directly on your prerequisite, Authorization, scope, and rules of engagement (ROE). Every phase below happens inside the scope, time window, and authorization that lesson defined. Recon respects the target list. Exploitation respects the "don't touch production data" clause. Reporting delivers on the agreed contract. Methodology without authorization is just an attack — the ROE is what makes this legal, ethical work. Where these phases feed forward, the next lesson, Passive vs active reconnaissance, zooms into the very first stage.
In real, authorized professional work, a clear methodology gives an engagement three qualities a client actually pays for:
Each phase's output becomes the next phase's input and the evidence in the final report. That chain is why methodology matters: a finding you can't trace back through the phases is a finding you can't defend in a remediation meeting. Ad-hoc poking misses things and produces claims you can't stand behind. On the defensive side, the same phase map is a detection tool — a SOC analyst who knows the phases can look at scattered alerts and say "this looks like enumeration, expect discovery next," and respond before impact.
Each phase below gets a definition, a plain explanation, how it works, when it applies (and when it doesn't), and a common pitfall.
The phases loop. A detail found during enumeration can send you back to recon. A new foothold can expose an internal network you then re-scan. Good testers loop back whenever they learn something new — the arrow diagram is a default path, not a cage.
AUTHORIZED LAB — trust boundary = the signed ROE + scope list
┌───────────────────────────────────────────────────────────────┐
│ ASSETS (what we protect / measure risk to): │
│ - Target hosts on the scope list (lab VMs / containers) │
│ - Data those hosts hold (in a lab: synthetic data only) │
│ - The evidence you collect (may contain sensitive detail) │
│ │
│ ENTRY POINTS (where phases interact with the target): │
│ recon/enum → network services (HTTP, SMB, SSH…) │
│ exploitation → a specific vulnerable endpoint │
│ privesc/post-ex → a foothold host │
└───────────────────────────────────────────────────────────────┘
▲ │
│ MUST stay inside scope (the trust boundary) │
│ ▼
TESTER (authorized) DEFENDER / logs & alerts
detect each phase by its traces
OUTSIDE the boundary (NEVER touch): third-party hosts, cloud
provider infra, systems not on the scope list, real user data.
Knowledge check
There is no programming syntax here — the "structure" of this lesson is the phase pipeline and the artifact each phase hands to the next. Read this as the shape you follow.
PHASE → ARTIFACT IT PRODUCES (input to next phase / report)
---------------------------------------------------------------------------
reconnaissance → list of assets in scope (hosts, domains, services)
enumeration → per-service detail (versions, users, endpoints)
vulnerability discovery → validated candidate weaknesses (not raw scan hits)
exploitation → confirmed access (proof the flaw is real)
privilege escalation → higher-privilege access (shows real reach)
post-exploitation → impact map (what an attacker could reach)
evidence collection → reproducible proof (screens, req/resp, timestamps)
risk rating → severity per finding (likelihood × impact, CVSS)
reporting → the deliverable (exec + technical)
remediation & retest → verified fix (bad input now rejected)
A minimal, lab-safe engagement log line — the atomic unit of evidence you write during every phase — looks like this:
[2026-07-07T14:03:11Z] phase=enumeration host=10.0.0.5(lab) \
action="http banner grab" result="Server: Apache/2.4.x" \
scope=YES corr_id=ENG-42-0007
Every field earns its place: the timestamp and correlation id make it reproducible and traceable; scope=YES is your own guardrail; the action/result pair is the proof.
A penetration test follows a repeatable workflow. Each phase feeds the next and produces evidence for the report.
The phases are not a one-way street.
Good testers loop back whenever they learn something new.
Gather proof during testing, not after. Note every command, the time it ran, and its result.
The report is only as strong as the evidence behind it. A finding you can't reproduce isn't a finding.
This is a concept lesson, so the "code" is a worked example of the methodology in motion on a local, authorized lab — plus the INSECURE → SECURE → VERIFY shape applied to one finding the phases would surface. Nothing here touches a real system.
WARNING: intentionally vulnerable — use only in a local, isolated, authorized lab. Do not deploy.
Suppose recon + enumeration on a lab VM (10.0.0.5, on your scope list) surface a small login endpoint. Discovery flags it, and manual validation confirms it builds SQL by string concatenation:
# INSECURE — lab target under test. Do NOT deploy.
# A login handler that concatenates user input into SQL.
def login(conn, username, password):
q = "SELECT id FROM users WHERE name = '" + username + \
"' AND pass = '" + password + "'"
return conn.execute(q).fetchone() # classic SQL injection
During exploitation you confirm the flaw with the least disruptive proof — a benign input like username = "' OR '1'='1' -- " returns a row it shouldn't. You capture that request/response as evidence, rate it, and report it. Then the SECURE fix the report recommends:
# SECURE — parameterized query; input can never change the SQL structure.
def login(conn, username, password):
q = "SELECT id FROM users WHERE name = ? AND pass = ?"
return conn.execute(q, (username, password)).fetchone()
And the VERIFY / retest step — the remediation phase in miniature — proving the fix rejects bad input and still accepts good input:
# RETEST — run after the fix. Rejects the attack, accepts the legit user.
def retest(conn):
# bad input must NOT authenticate
assert login(conn, "' OR '1'='1' -- ", "x") is None, "FAIL: injection still works"
# good input must still work (seed a known lab user first)
assert login(conn, "alice", "correct-horse") is not None, "FAIL: legit login broke"
print("RETEST PASS: injection rejected, valid login accepted")
Expected result when run against the fixed code: the first assert holds (the injection string is now just a literal username that matches nobody), the second holds (Alice still logs in), and you see RETEST PASS: injection rejected, valid login accepted. Run it against the insecure version and the first assert fails — which is exactly the before/after evidence the report needs. This whole arc — discover → validate → exploit safely → evidence → report → fix → retest — is the methodology on a single finding.
Walking the login example through the phases:
| Step | Phase | What happens | Why it matters |
|---|---|---|---|
| 1 | Recon → enumeration | You learn a login endpoint exists on the in-scope lab host and note the app framework | Establishes there's something to test, inside scope |
| 2 | Discovery | A scanner hints at SQL injection | A hint only — not yet a finding |
| 3 | Discovery (validate) | You read/observe that input is concatenated into q |
Manual validation removes false positives |
| 4 | Exploitation | "' OR '1'='1' -- " returns a row without valid creds |
Proves the flaw is real, with the least disruptive input |
| 5 | Evidence | You save the request, the response, timestamp, corr_id | The report stands on this proof |
| 6 | Risk rating | Auth bypass on a login = high likelihood × high impact | Justifies the severity honestly |
| 7 | Reporting | Finding written with reproduction + the parameterized fix | Engineers can act on it |
| 8 | Remediation | Team switches to execute(q, (username, password)) |
Input is now data, never SQL structure |
| 9 | Retest | retest() shows bad input rejected, good input accepted |
Confirms the fix — the loop closes |
How the key value changes: in the insecure version, the string ' OR '1'='1' -- becomes part of the SQL command, so the WHERE clause is always true and a row comes back. In the secure version the exact same string is passed as a parameter — the database treats it purely as a value for name, looks for a user literally named ' OR '1'='1' -- , finds none, and returns None. Same input, completely different meaning: that difference is the fix, and the retest is what proves it.
| Wrong approach | Why it's wrong | Corrected approach | How to recognise / prevent |
|---|---|---|---|
| Skipping recon and jumping to exploitation | You attack blind, miss assets, and risk touching something out of scope | Always recon first; build the asset list before probing | If you can't name the host's role and why it's in scope, you skipped recon |
| Reporting a raw scanner hit as a confirmed finding | Scanners produce false positives; "passing a scan" also doesn't prove security | Validate every candidate by hand before it becomes a finding | Ask: "Have I reproduced this myself?" If no, it's a lead, not a finding |
| Treating post-exploitation as a chance to cause damage | Destroys client systems/data and breaks the ROE and the law | Post-ex = measure reach and impact, read-only mindset, no persistence/exfiltration of real data | If an action changes or removes data, stop — that's not impact assessment |
| Marking every finding "critical" | Buries the real risks and destroys client trust | Rate by likelihood × impact (e.g., CVSS + business context) | If everything is critical, nothing is — spread reflects reality |
| "Decoding" a JWT and calling it "verified" | Base64-decoding a token reveals its contents but proves nothing about its signature | State clearly: decoding ≠ verifying; a valid signature check is a separate step | If you didn't check the signature with the key, you haven't verified anything |
| Writing evidence up from memory afterward | Details drift; findings become unreproducible | Log command + time + result during the work | A finding you can't reproduce isn't a finding |
| Assuming the fix worked, skipping retest | The patch may be partial or wrong | Re-run the exact reproduction: bad input rejected, good input accepted | No retest = an assumption, not a closed finding |
| Probing a host because it was "probably in scope" | Out-of-scope access is unauthorized, even in a friendly network | Check the scope list before every new target | If the host isn't on the list, it's out — no exceptions |
When an engagement stalls or a phase gives confusing results, debug the methodology, not just the tool:
Questions to ask when a phase fails: Is this target on the scope list? Have I reproduced this myself, or is it a tool's claim? What artifact should this phase hand to the next one — do I have it? Would my evidence let a stranger repeat this exactly? Am I about to change data (stop) or just observe (continue)?
Security & safety — detection, logging, and the defender's view. Every offensive phase leaves traces; the defensive skill is knowing what to log to catch it and what to never log.
What to log for each finding and action (the evidence trail):
What defenders watch, phase by phase:
| Phase | Detectable trace | Where it shows up |
|---|---|---|
| Active recon / enumeration | Many varied requests, port sweeps, odd user-agents from one source | IDS/IPS alerts, web/access logs, firewall logs |
| Vulnerability discovery | Bursts of probing paths, error-triggering inputs | App error logs, WAF logs |
| Exploitation | Anomalous request that yields unexpected auth/data | App logs, auth logs, sudden 200 on a protected path |
| Privilege escalation | New admin/root session, unusual privilege change | OS/audit logs, sudo logs |
| Post-exploitation | Lateral connections, unusual internal access | Network flow logs, EDR |
NEVER log (in your evidence or the app): passwords, tokens, session cookies, private keys, full payment card numbers (PANs), or unneeded PII. If proof requires a sensitive value, redact/mask it in the report and store the raw evidence encrypted and access-controlled.
Which events signal abuse: a spike of distinct source IPs or usernames in access logs (the mechanic behind the related exercise, Count suspicious IPs), repeated auth failures then a sudden success, privilege changes outside a change window, access to resources a user never touches.
How false positives arise: legitimate scanners/health checks, a busy admin, or a load test can all look like recon or brute force. That's why detection pairs volume/pattern with context (known source? change window? expected behavior?) before anyone raises an incident — the same discipline as validating a scanner hit before calling it a finding.
Authorization & lab hygiene. Run every phase only on systems you own or are explicitly authorized to test: localhost, containers, deliberately-vulnerable VMs, or CTF ranges. Minimal authorization checklist before you start: (1) signed ROE covering these exact targets; (2) written scope list; (3) agreed time window; (4) emergency contact and stop conditions; (5) a place to store evidence securely. Cleanup / reset for a lab: revert VM snapshots or rebuild containers, remove any test accounts/files you created, close footholds, and securely delete or archive evidence per the ROE — leave the lab exactly as you found it.
Concrete authorized use case. A company hires a firm for an internal network penetration test. The tester signs the ROE, gets the scope list, and works the phases: recon and enumeration map the in-scope subnet; discovery + manual validation confirm a handful of real issues; controlled exploitation and privilege escalation demonstrate reach on a lab-equivalent staging host; post-exploitation shows which sensitive shares an attacker could reach without touching real data; evidence is logged throughout; findings are CVSS-rated; the report goes to executives and engineers; and weeks later a retest verifies each fix actually closed the hole. The deliverable isn't "we got in" — it's a prioritized, verified path to a more secure network.
Professional best-practice habits (carry these into every phase):
| Level | What the phases look like |
|---|---|
| Beginner | Follow the pipeline in order on a deliberately-vulnerable lab (DVWA-style app, a CTF box). Focus on producing the right artifact at each phase and logging clean evidence. |
| Advanced | Loop fluidly — chain a foothold into fresh recon of an internal segment, correlate findings across hosts, tailor severity to real business impact, and align reporting to frameworks/standards the client uses. |
All tasks are lab-only — localhost, containers, deliberately-vulnerable VMs, or CTF. Each ends defensively: remediate and verify.
Beginner 1 — Order the pipeline.
Beginner 2 — Recon vs enumeration sort.
Intermediate 1 — Validate, don't trust.
Intermediate 2 — Detection mapping.
Challenge — Full mini-engagement on one finding, INSECURE → SECURE → VERIFY.