Getting Started with Web Reconnaissance

Reconnaissance is the first phase of a web security assessment. Done well, it tells you what exists, what is in scope, and which hypotheses deserve active testing. Done poorly, it burns hours on out-of-scope assets or noisy scans that teach you nothing.

This tutorial covers a beginner-friendly, authorization-first workflow: passive OSINT → disciplined scope → light active mapping → handoff to vulnerability testing. Commands are illustrative for lab targets you own (DVWA, local apps, intentionally vulnerable VMs) or engagements with written permission.

Learning objectives

• Distinguish passive vs active reconnaissance and when each is appropriate.
• Build a minimal target inventory (domains, hosts, ports, apps) without spray-and-pray scanning.
• Use DNS, HTTP, and content discovery tools carefully.
• Capture notes that another tester (or future you) can reuse.

Prerequisites: basic networking (DNS, HTTP, ports), comfort with a Linux shell.
Suggested tools: curl, browser + proxy (Burp/ZAP), nmap, dig/drill, ffuf (or similar fuzzer), whois/OSINT sources as allowed by scope.

Passive OSINT before active probes

Passive recon gathers information without sending packets to the target’s application stack (or with negligible, normal-looking requests such as public DNS). Goals:

1. Confirm legal entity and brand domains.
2. Find documented subdomains, cloud buckets naming patterns, and public repos.
3. Note technologies from job posts, changelogs, status pages, and certificate transparency — where policy allows.

Example passive habits:

# Public DNS (usually acceptable; still respect engagement rules)
dig +short example.com A
dig +short www.example.com CNAME
dig +short example.com MX
dig +short example.com TXT

# Certificate transparency / subdomain datasets — use sources allowed by your program
# (Do not scrape locked APIs or violate ToS; prefer official program scope lists.)

Record findings in a simple table: asset, source, confidence, in-scope? (Y/N/Ask).

Ethics: Some “OSINT” techniques cross into unauthorized access (open cloud buckets with private data, scraped employee PII dumps). Stay on public marketing/DNS/CT data unless the program explicitly allows more.

If a name pattern points at cloud storage, the next authorized check is identity, not object access: what to audit and how to detect IAM privilege escalation.

Mapping attack surface with disciplined scope

Before any port scan or content discovery:

1. Read the scope document: domains, wildcards, exclusions, rate limits, forbidden tests.
2. Expand only what scope permits (e.g., *.lab.example.com ≠ *.example.com).
3. Prefer a seed list from the program over unbounded subdomain brute force.

Active mapping ladder for a single in-scope host:

# 1) Reachability & TLS
curl -sI https://target.lab.example

# 2) Focused Nmap (see also the Nmap cheat sheet)
nmap -Pn -sS -F -sV -oA recon/fast target.lab.example

# 3) Only then deepen ports on confirmed VIP hosts
nmap -Pn -sS -p- --min-rate 200 -oA recon/alltcp target.lab.example

Avoid starting with -A -p- -T5 against entire CIDRs. You want a map, not a denial-of-service ticket.

HTTP fingerprinting without heavy scanning

curl -sI https://target.lab.example | sed -n '1,20p'
curl -sk https://target.lab.example/robots.txt
curl -sk https://target.lab.example/sitemap.xml | head

Note:

• Server / CDN headers (may be lies; still useful hypotheses).
• Redirect chains (apex → www → regional).
• Auth walls vs fully public marketing sites.
• API hints in JavaScript bundle URLs on the marketing page.

In the browser proxy, browse as a normal user would. Manual click-paths often beat blind fuzzing for understanding business logic.

Content discovery (careful active recon)

Directory and virtual-host discovery can find forgotten panels — and can also trigger WAF bans or break fragile staging boxes.

# Low-and-slow wordlist example (lab only)
ffuf -u https://target.lab.example/FUZZ -w wordlist-small.txt -mc 200,204,301,302,401,403 -t 10 -o recon/ffuf.json

Rules of thumb:

• Start with small wordlists; escalate only when justified.
• Exclude static asset paths that create megabytes of noise.
• Cap threads; honor program rate limits.
• Triage hits: 403 on /admin is a lead, not a root shell.

Virtual host fuzzing (when scope includes it):

ffuf -u https://<ip>/ -H "Host: FUZZ.lab.example" -w vhosts.txt -mc 200,301,302 -t 5

From recon to hypotheses

Good recon ends as a hypothesis list, not a folder of XML:

Hand this table to the exploitation phase. If you cannot state a hypothesis, keep reconciling — do not random-payload the login form yet.

Note-taking that survives the engagement

Minimum artifacts:

• Scope excerpt + date/time + tester identity.
• Asset inventory CSV/markdown.
• Nmap -oA outputs per wave.
• Proxy project / sitemap export.
• Hypothesis table with “tested / not tested” flags.

Screenshots without context waste space; pair them with URLs and timestamps.

Common beginner mistakes

• Scanning neighbors because DHCP or shared hosting confused the IP.
• Trusting a single OSINT subdomain list as complete and in-scope.
• Running authenticated spidering before understanding session handling (logout CSRF, token binding).
• Skipping passive sources and jumping straight to aggressive fuzzing.
• Not verifying HTTPS certificate subjects when using IP-based scans.

Safety and legal reminder

Only assess systems you own or are explicitly authorized to test. When unsure whether an asset is in scope, ask — do not probe first. Recon is still interaction; treat it with the same professionalism as exploitation.

Next steps

• Practice the ladder on a local vulnerable app.
• Deepen port/service skills with the Nmap Cheat Sheet.
• When APIs appear, continue with API Security Testing and BOLA-focused tutorials.
• For SPA-heavy targets, read Security Posture of Modern SPA Routing.

Related on Andrax

• Nmap Cheat Sheet
• Penetration Testing Checklist
• Web & API Penetration Testing Masterclass