Reconnaissance

Step 1: Passive Reconnaissance

Before you probe the target directly, find out what's visible without touching it. Passive reconnaissance is intelligence gathering that leaves no trace on the target system. WHOIS lookups, DNS queries, Google dorking — each one asks a specific question about the target's public footprint.

Open materials/scope-document.md again. The target is the DVWA instance running locally, so the usual internet-facing passive recon (WHOIS on a domain, DNS enumeration) is limited. But the principle matters: you always start with what you can learn without alerting the target.

Direct Claude to gather passive information about the target:

Using the scope document in materials/scope-document.md, perform passive reconnaissance on the DVWA target. Check what's publicly visible — DNS records, any exposed configuration details, anything discoverable without directly probing the application. Document what you find and what each piece of information tells us.

Notice how Jean-Marc's booking page looks from the outside. A login form, a web server, an IP address. This is what an attacker sees first — not the internal architecture, not the database schema, just what the system shows to anyone who looks.

Step 2: Review Passive Findings

Claude will return results. Some will be useful, some won't. The raw data from passive recon requires interpretation — a DNS record or an exposed server header is a fact, not a conclusion.

Read what Claude found. For each item, ask: what does this tell us about the target? An Apache version string tells you what software is running and whether known vulnerabilities exist for that version. An exposed port tells you a service is listening. Neither one tells you the system is vulnerable — they tell you where to look next.

If Claude presents any finding as a definitive vulnerability at this stage, push back. Reconnaissance produces observations, not conclusions. A finding without investigation is an assumption.

Check what Claude scanned against materials/scope-document.md. Everything should be within the authorized boundaries. If Claude suggested checking anything outside the scope — a different IP range, a DNS server not listed, an adjacent service — that suggestion crosses the line defined in the scope document, regardless of how useful it might seem.

Step 3: Active Reconnaissance

Passive recon tells you what's visible without touching the system. Active reconnaissance goes further — you send packets to the target and analyze what comes back. This is where Nmap comes in.

Active scanning is different in kind, not just degree. Every probe you send appears in the target's logs. The Nmap scan you're about to run will show up in Grafana later. Reconnaissance is not invisible.

Direct Claude to scan the target:

Run an Nmap service version scan against the DVWA target specified in materials/scope-document.md. Use the -sV flag to detect service versions. Only scan the target and ports authorized in the scope document. Show me the full output.

Notice the prompt. It specifies the target from the scope document, requests version detection, and explicitly limits the scan to authorized targets. If you'd just said "scan the network," Claude would decide what to scan, and that decision might include targets outside scope. The prompt shapes the result.

Step 4: Review Nmap Results

Claude will show you a port table — rows listing port numbers, states, services, and versions. This is the raw reconnaissance data for the target.

Look at what's open. Port 80 running Apache means there's a web server — that's expected for a booking page. Port 3306 running MySQL means the database is directly accessible from the network. That's unusual. A production web application typically keeps its database behind the web server, not exposed on its own port. Jean-Marc's developer left the database port open to the network, and that means someone could potentially connect to MySQL directly, bypassing the web application entirely.

This is what reconnaissance gives you: not a list of vulnerabilities, but an understanding of what the system exposes. The open MySQL port isn't a vulnerability by itself — it's an observation that shapes what you investigate next.

If Claude states that open ports are vulnerabilities, or that the system is "at risk" based on the scan alone, that's an overstatement. Nmap tells you what services are listening. Whether those services are vulnerable requires further testing. The TTP selection document in materials/ttp-selection.md specifies which attack techniques apply and why — that's where the next unit picks up.

Step 5: Document Findings

Direct Claude to compile the reconnaissance results into a structured summary:

Document our reconnaissance findings. For each finding, include: what was discovered, how it was discovered (passive or active), and what it means for the assessment. Cross-reference everything against the scope document to confirm we stayed within authorized boundaries.

Documentation is the beginning of the evidence chain. A finding without methodology — without recording what tool was used, what target was scanned, what the output showed — is an assertion, not evidence. When you write the final report for Jean-Marc, every claim needs to trace back to something you observed and recorded here.

Review what Claude produces. The documentation should separate observations (port 80 is open running Apache) from interpretations (the web server is the primary attack surface). It should note the exposed MySQL port as a significant finding worth investigating. And every target and method listed should appear in the scope document.