Reconnaissance is where engagements are won or lost. The best exploit in the world is useless if you aimed it at the wrong target. This post breaks down my web recon process — what I run, in what order, and what I’m actually looking for.

Philosophy First Link to heading

Recon is not about running every tool you have. It’s about building an accurate mental model of the target:

  • What does it expose?
  • What tech stack is running?
  • Where does user input reach the application?
  • What’s the authentication model?
  • What’s non-obvious that might be juicy?

The goal is attack surface map, not a pile of tool output.

Phase 1: Passive Recon (No Touch) Link to heading

Start here. Learn as much as possible without sending a single packet to the target.

Domain and Certificate Recon Link to heading 

# Certificate transparency logs — reveals subdomains
curl "https://crt.sh/?q=%.target.com&output=json" | jq '.[].name_value' | sort -u

# Historical DNS records
# Use dnsdumpster.com, SecurityTrails, or RiskIQ

Google Dorking Link to heading 

site:target.com filetype:pdf
site:target.com inurl:admin
site:target.com "password" OR "secret" OR "api_key"
site:target.com ext:env OR ext:config OR ext:bak

Shodan / Censys Link to heading 

# Shodan CLI
shodan search "hostname:target.com"
shodan host TARGET_IP

# What ports are open? What services? What certs?

ASN and IP Range Discovery Link to heading 

# Find the target's ASN
whois -h whois.radb.net -- '-i origin AS12345' | grep route

# Or use bgp.he.net — search by company name

Phase 2: Subdomain Enumeration Link to heading

This is often where the interesting targets live — forgotten staging environments, admin panels, internal tools accidentally exposed.

# Passive: aggregating public sources
subfinder -d target.com -all -o subdomains-passive.txt

# Active: brute force DNS
gobuster dns -d target.com -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt -o subdomains-brute.txt

# Alternative: amass
amass enum -d target.com -passive -o subdomains-amass.txt

# Combine and deduplicate
cat subdomains-*.txt | sort -u > all-subdomains.txt

Resolve and Probe Link to heading 

# Resolve which subdomains are actually live
massdns -r resolvers.txt -t A all-subdomains.txt -o S | grep -v NXDOMAIN > resolved.txt

# HTTP probe on all live hosts
cat resolved.txt | httprobe > live-http.txt

# Or use httpx for richer output
httpx -l resolved.txt -title -tech-detect -status-code -o httpx-output.txt

Phase 3: Content Discovery Link to heading

Now you’re actively talking to the target. Map what’s exposed.

# Directory and file brute force
gobuster dir -u https://target.com -w /usr/share/seclists/Discovery/Web-Content/raft-large-files.txt -x php,html,txt,js,json,bak -o dirs.txt

# Faster with ffuf
ffuf -w /usr/share/seclists/Discovery/Web-Content/raft-large-directories.txt -u https://target.com/FUZZ -mc 200,301,302,401,403

# Don't forget the API surface
ffuf -w /usr/share/seclists/Discovery/Web-Content/api/api-endpoints.txt -u https://target.com/api/FUZZ

Files worth flagging immediately:

  • .env, config.php, database.yml, secrets.json
  • backup.zip, dump.sql, .git/HEAD
  • swagger.json, openapi.yaml — full API spec
  • robots.txt, sitemap.xml — path hints

Phase 4: Technology Fingerprinting Link to heading

Understanding the stack guides your attack selection.

# whatweb — passive tech detection
whatweb -v https://target.com

# wappalyzer CLI
npx wappalyzer https://target.com

# Check headers manually
curl -si https://target.com | grep -i "server\|x-powered\|x-generator"

# Inspect JS files for framework hints, API keys, internal endpoints
cat js-files.txt | while read f; do curl -s "$f" | grep -E "api[_-]key|secret|token|endpoint|internal" ; done

Phase 5: Manual Browsing + Burp Link to heading

All the automated stuff has run. Now open Burp Suite and browse the application manually.

What I’m building in Burp:

  • Site map — every endpoint and parameter the app exposes
  • Parameter list — every place user input touches the backend
  • Auth flow — how session management works
  • Business logic — what the app actually does, where the value is

Turn on Burp’s passive scanner during this phase. It catches low-hanging fruit while you explore.

Questions to answer during manual browse:

  • How does authentication work? JWT? Session cookies? OAuth?
  • Are there role-based endpoints accessible without the right role?
  • Does the app use predictable IDs? (IDOR surface)
  • Is there file upload? What types? Where are files served?
  • Are there any CORS headers? What origins are trusted?

Phase 6: Organize and Prioritize Link to heading

Before you start exploiting anything, sort your surface by risk.

High priority:

  • Admin panels / privileged functionality
  • File upload endpoints
  • Any endpoint taking URLs or file paths as input (SSRF)
  • Search / filter endpoints (SQLi, XSS)
  • Authentication bypass candidates
  • Endpoints touching sensitive data

Medium:

  • Subdomains with 403s (often bypassable)
  • Legacy API versions
  • Public-facing but auth’d endpoints

Low / later:

  • Information disclosure
  • Missing security headers
  • Content-type sniffing issues

Recon is the discipline that separates methodical security testing from lucky guessing. The more time you invest here, the more your exploitation phase becomes focused and efficient rather than random.

Take notes. Everything you find during recon is a data point. The interesting bugs are usually at the intersection of two data points you didn’t think mattered individually.