Web CTF Reconnaissance

Web reconnaissance is the deliberate collection of visible and semi-visible information about a web application before exploitation. In CTFs, the goal is to identify the application stack, exposed files, routes, cookies, and debug clues so you can narrow the challenge to a likely vulnerability class.

Think of recon as the answer to a simple question: what does this site already reveal about itself, and where should you look next?

Core Tools

These are the main tools and interfaces you will use during web recon:

• Burp Suite: primary web proxy for intercepting, modifying, and replaying HTTP requests.
• Browser DevTools: inspect JavaScript, requests, storage, cookies, and rendered DOM behavior.
• Wireshark: packet-level visibility when protocol behavior or unusual traffic needs inspection.
• OWASP ZAP: alternative intercepting proxy and active/passive scanner for quick validation.
• Postman / Insomnia: API workflow testing and repeatable endpoint probing.
• Supporting CLI tools: curl, whatweb, ffuf, and gobuster for fast scripted recon.

Recommended Methodology

Formal definition: A methodology is an ordered process used to gather information efficiently and consistently. For beginner web recon, the order matters because each step makes the next one more specific.

Start broad, then narrow down:

1. Check the page source and visible UI for obvious clues.
2. Inspect JavaScript files and network requests for hidden endpoints.
3. Review headers, cookies, and error messages for stack information.
4. Look at robots.txt, sitemap.xml, and other well-known files.
5. Fuzz for hidden directories and common backup files.
6. Use the clues you found to infer the likely vulnerability category.

Before attempting any exploit, spend 5–10 minutes mapping the target web application. Good recon often reveals the vulnerability category immediately.

Recon Checklist

Use the checklist below as a practical version of the methodology above. Each item explains what the tool is checking and why it matters.

- HTML comments: <!-- flag: ... --> or <!-- TODO: remove auth bypass -->
- Hidden form fields: <input type="hidden" name="role" value="user">
- Inline JavaScript with API endpoints or credentials
- References to JavaScript files: /js/admin.js, /js/config.js
- Base64 encoded data in comments or attributes

// Open DevTools (F12) → Sources → browse JS files
// Look for:
// - API endpoints (/api/v1/admin, /internal/flag)
// - Hardcoded credentials ("admin", "password123")
// - Secret keys ("secret_key = 'ctf2024'")
// - Debug flags (if (debug) { return flag; })
// - AJAX calls to interesting endpoints
// - Source maps (.map files) → may expose minified source

# Download and search all JS files
curl -s http://target.com/ | grep -oE 'src="[^"]+\.js"' | \
  sed 's/src="//;s/"//' | while read js; do
    curl -s "http://target.com/$js" | grep -iE "(flag|key|pass|admin|secret)"
  done

curl -I http://target.com/
# X-Powered-By: PHP/7.4
# Server: Apache/2.4.51
# Set-Cookie: session=... (check for flags in cookie values!)
# X-Frame-Options, X-XSS-Protection (tells you what they're worried about)
# Custom headers: X-CTF-Hint, X-Debug-Info

# All headers including redirects
curl -I -L http://target.com/

curl http://target.com/robots.txt
# Common finds:
# User-agent: *
# Disallow: /admin/
# Disallow: /flag.txt       ← !
# Disallow: /backup/
# Disallow: /.git/

curl http://target.com/.git/HEAD          # exposed git repo
curl http://target.com/.env               # environment variables
curl http://target.com/backup.zip         # backup archives
curl http://target.com/config.php.bak     # backup config
curl http://target.com/phpinfo.php        # PHP info
curl http://target.com/sitemap.xml        # site structure
curl http://target.com/api/swagger.json   # API documentation
curl http://target.com/api/docs           # API docs

# Trigger errors intentionally
curl "http://target.com/page?id='"    # SQL error?
curl "http://target.com/page?id={{7*7}}"  # SSTI?
curl "http://target.com/page?id=%0a"  # Command injection?

# Error pages reveal:
# - Framework (Django, Flask, Express)
# - Version numbers
# - File paths (traceback)
# - Database type

# whatweb CLI
whatweb http://target.com

# Manual indicators:
# X-Powered-By: Express → Node.js
# PHPSESSID cookie → PHP
# .aspx URLs → ASP.NET
# /wp-admin → WordPress
# Django CSRF token → Django/Python
# Traceback with "flask" → Flask/Python

Directory Fuzzing

# Basic fuzz
ffuf -u http://target.com/FUZZ -w /usr/share/seclists/Discovery/Web-Content/common.txt -fc 404

# With extensions
ffuf -u http://target.com/FUZZ -w common.txt -e .php,.html,.txt,.bak,.zip

# API paths
ffuf -u http://target.com/api/FUZZ -w api-endpoints.txt

API Endpoint Discovery

# Common API paths to try manually:
/api/v1/flag
/api/admin
/api/users
/graphql
/swagger.json
/openapi.json
/.well-known/

Cookie Analysis

Technology → Likely Vulnerabilities

Checklist

• View page source → comments, hidden fields, JS references
• curl -I → HTTP headers, X-Powered-By, custom headers
• curl /robots.txt → disallowed paths
• curl /.git/HEAD → exposed git repository?
• curl /.env → environment variables?
• DevTools → Sources → browse all JS files
• Trigger errors intentionally → framework identification
• whatweb → technology fingerprinting
• Decode cookies → role manipulation opportunity?
• ffuf/gobuster → hidden directories

Last updated on Aug 1, 2025