The Problem I Was Solving

When you start a bug bounty engagement or a penetration test, the first 3–4 hours are always the same: you’re hopping between terminals, running Subfinder, checking DNS records, probing for live hosts, scanning ports, crawling URLs — all manually, all disconnected from each other.

Results pile up in scattered .txt files across your desktop. You forget which subdomains you already checked. You re-run the same tool twice. You miss a live host because it disappeared from your terminal scroll.

I wanted one dashboard that ran everything in the right order, stored every result neatly per target, and let me see what’s happening in real time.

That’s what this project is.

What the Project Is — In One Sentence

A self-hosted, browser-based recon dashboard that runs 10 automated phases of attack surface reconnaissance against a target domain, storing all results locally in a structured workspace, with a React frontend that polls the backend live as scans run.

GitHub: https://github.com/sidharthsmenon2003/recon-framework

The 10-Phase Pipeline — What Each One Does and Why

This is the core of the project. Every phase has a reason for existing and a specific place in the recon kill chain.

PH-01 — Subdomain Enumeration

Tools: Subfinder, Amass, Assetfinder, CRT.sh, Sublist3r

What it does: Hits 5 different subdomain discovery sources simultaneously and merges the results. Each tool has a different data source — Subfinder uses passive DNS APIs, Amass does both passive and active brute-force, Assetfinder scrapes certificate transparency logs, CRT.sh queries the crt.sh database directly, and Sublist3r uses search engines.

Why 5 tools instead of 1: No single tool finds everything. In testing, running all 5 together consistently finds 30–40% more subdomains than using Subfinder alone. The overlap is deduplicated; only the unique discoveries get saved.

Output: workspace/<target>/subdomain/merged.txt

When to use this: Always — this is your foundation. Every subsequent phase depends on the subdomain list. Skip this and you’re testing blind.

PH-02 — DNS Resolution

Tools: dnsx

What it does: Takes the merged subdomain list and resolves each entry to find its A records (IPv4), CNAME records (where it points), MX records (mail servers), and TXT records (SPF, DKIM, verification tokens). Only domains that actually resolve get passed forward.

Why this matters: A subdomain that doesn’t resolve is dead — testing it wastes time. More importantly, CNAME records pointing to services like Heroku, GitHub Pages, or Fastly that no longer have a claim registered on them are subdomain takeover vulnerabilities — an often critical finding.

Output: workspace/<target>/dns/records.json

When to use this: Immediately after PH-01. Always before PH-03. The DNS data also tells you a lot about the infrastructure — AWS? Cloudflare? Azure? That context shapes your later phases.

PH-03 — Live Host Detection

Tools: httpx

What it does: Probes each resolved subdomain over HTTP and HTTPS to check which ones actually respond to web requests. It records the status code, title, content length, and web technology fingerprint for each live host.

Why this matters: DNS resolving doesn’t mean a web server is running. This phase is the real filter — on a large program, you might go from 2,000 resolved subdomains to 400 live web hosts. Those 400 are your actual attack surface.

Output: workspace/<target>/live/merged.txt and live/hosts.txt

When to use this: Before any active testing. You should never fire a vulnerability scanner at a host until you’ve confirmed it’s live and understood what it’s serving.

PH-04 — Port Scanning

Tools: Naabu (fast scan), Nmap (service detection)

What it does: Naabu does a rapid TCP SYN scan across common ports for all live hosts. Then Nmap runs service version detection on the open ports found. The combination gives you speed (Naabu) plus depth (Nmap service banners).

Why this matters: Most bug bounty programs only want web vulnerabilities, but their scope includes the IP ranges. An exposed MongoDB on port 27017, a Redis instance on 6379, or a VNC server on 5900 — none of these would show up in a web scan. Port scanning catches the forgotten services.

Output: workspace/<target>/ports/open_ports.json

When to use this: After live host detection. Also run it when you suspect the target has cloud infrastructure — AWS security groups misconfigured to allow :5432 or :3306 to the world are extremely common.

PH-05 — URL Crawling

Tools: gau (passive), katana (active), gospider, waybackurls

What it does: Discovers every URL associated with the target. gau and waybackurls pull from the Wayback Machine and Common Crawl passively — no requests touch the target's servers. katana actively spiders live hosts by following links. gospider crawls for JavaScript-linked endpoints.

Why this matters: URLs reveal the application’s internal structure — API endpoints, admin paths, file upload handlers, legacy pages that developers forgot to remove. JavaScript files in particular often contain hardcoded API keys, internal hostnames, and undocumented endpoints.

Output: workspace/<target>/urls/merged.txt

When to use this: Before any manual testing. The URL list is your map of the application. You’ll use it to decide where to spend your time.

PH-06 — Screenshots

Tools: Chromium (headless)

What it does: Takes a browser screenshot of every live host. Runs headless Chrome against each URL and saves the rendered page as a PNG.

Why this matters: This phase saves enormous time during triage. Instead of manually visiting 400 subdomains, you scroll through screenshots in 15 minutes and immediately spot: login panels you didn’t know existed, default server pages (IIS, nginx, Apache) that indicate misconfiguration, internal tools accidentally exposed, dashboards with no authentication, and error pages that leak software versions.

Output: workspace/<target>/screenshots/imgs/*.png

When to use this: Right after live host detection. It’s your first visual pass across the entire attack surface.

PH-07 — Confidential File Discovery

Tools: ffuf (fuzzing), passive checks, git metadata probing

What it does: Actively probes every live host for sensitive paths that are commonly exposed by misconfiguration:

• .env files (database credentials, API keys, secrets)
• .git/ directories (full source code)
• backup.zip, backup.sql, db.sql (database dumps)
• config.php, config.json, settings.py (configuration files)
• wp-config.php, .htaccess, web.config

Why this matters: Finding a .env file exposed on a production server is an instant critical vulnerability on most bug bounty programs. These files typically contain database URLs with credentials, cloud provider API keys (AWS_ACCESS_KEY_ID, etc.), and JWT secrets. A single .env exposure can mean full application compromise.

Output: workspace/<target>/confidential/findings.json

When to use this: During any engagement. On bug bounty programs, run this early — it’s one of the highest-value, lowest-effort phases.

PH-08 — Origin IP Discovery

Tools: DNS/certificate history analysis, Shodan lookups

What it does: Attempts to find the real IP address of the web server behind a CDN (Cloudflare, Akamai, Fastly, etc.). Methods include: querying old DNS records before CDN was implemented, checking SSL certificate history databases (Censys, crt.sh), looking for mail server IPs that point to the same origin, and checking subdomains that might not be behind the CDN.

Why this matters: Cloudflare hides the real server IP and provides a WAF. If you can find the origin IP and it accepts direct connections, you bypass the WAF entirely and test the application without any firewall protection. This is one of the most valuable techniques in a pentest against a Cloudflare-protected application.

Output: workspace/<target>/originip/results.json

When to use this: When you find a target hiding behind a CDN and want to test for WAF bypass. Also valuable when you find vulnerabilities that Cloudflare is blocking — reaching the origin lets you confirm they’re real.

PH-09–403 Bypass

Tools: Custom header/path manipulation

What it does: When a URL returns HTTP 403 (Forbidden), this phase tries 20+ techniques to bypass the restriction:

• Header injection: X-Original-URL, X-Rewrite-URL, X-Forwarded-For: 127.0.0.1
• Path manipulation: /admin/ → /admin%2F, /%2e/admin, /admin/.
• Method switching: GET → POST, HEAD, OPTIONS
• Protocol tricks and double encoding

Why this matters: Many web applications enforce access control in the application layer but not at the reverse proxy or CDN layer. A 403 is not always a hard block — it’s often a misconfigured restriction that can be trivially bypassed. A 403 → 200 bypass on an admin panel is typically a high severity finding.

Output: workspace/<target>/bypass403/results.json

When to use this: Whenever you encounter a 403 during manual testing or when URL crawling finds paths that return 403. It’s a quick check with potentially high rewards.

PH-10 — Intelligence / Nuclei CVE Scan

Tools: Nuclei (with community template library), JavaScript analysis

What it does: Two sub-phases run here. First, the intelligence engine analyzes the URLs discovered in PH-05 to extract JavaScript files and scan them for hardcoded secrets (API keys, tokens, credentials) using pattern matching. Second, Nuclei runs its full template library against every live host — this includes known CVEs, exposed panels, misconfigurations, default credentials, and hundreds of vulnerability checks.

Why this matters: Nuclei’s template library is maintained by a community of thousands of security researchers and covers everything from Log4Shell to exposed Grafana dashboards to default Jenkins credentials. Running it against your discovered attack surface often produces findings within minutes on larger programs.

Output: workspace/<target>/nuclei/findings.json

When to use this: At the end of the pipeline after you have a confirmed list of live hosts. Also run it on any newly discovered subdomains during continuous monitoring.

The Architecture — How It All Connects

Browser (localhost:5173)
│
│ REST API calls
▼
Express Server (localhost:8000)
│
├── POST /api/scan → triggers PH-01
├── POST /api/dns → triggers PH-02
├── POST /api/live → triggers PH-03
├── POST /api/ports → triggers PH-04
├── POST /api/urls → triggers PH-05
├── POST /api/screenshots → triggers PH-06
├── POST /api/confidential → triggers PH-07
├── POST /api/originip → triggers PH-08
├── POST /api/bypass403 → triggers PH-09
└── POST /api/nuclei → triggers PH-10
│
▼
workspace/<target>/
├── subdomain/merged.txt
├── dns/records.json
├── live/merged.txt
├── ports/open_ports.json
├── urls/merged.txt
├── screenshots/imgs/*.png
├── confidential/findings.json
├── originip/results.json
├── bypass403/results.json
└── nuclei/findings.json

Each phase runs as a child process spawned by Express. The backend streams output to disk while the frontend polls the GET endpoint every few seconds to show live progress. This means you can close the browser, come back 30 minutes later, and your scan is still running.

How to Run It

# Clone the repo
git clone https://github.com/sidharthsmenon2003/recon-framework.git
cd recon-framework

# Install Go tools (see README for full list)
go install github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest
# … (install all tools from README)

# Install npm dependencies
npm install

# Terminal 1 — start backend
node server.cjs

# Terminal 2 — start frontend
npm run dev

Open http://localhost:5173, enter a target domain you have permission to test, and click through each phase in order.

Ethical and Legal Note

This framework is a tool. Tools have no ethics — users do.

Only scan targets you have explicit written permission to test. For bug bounty, that means targets listed in an active program’s scope. For pentesting, that means a signed engagement agreement.

Unauthorized scanning is illegal in most jurisdictions under laws like the Computer Fraud and Abuse Act (US), Computer Misuse Act (UK), and equivalent statutes globally. The README includes this notice. Follow it.

Conclusion

Building this framework taught me more about the recon phase of penetration testing than any course I’ve taken. When you have to write the code that orchestrates 12 security tools, pipe their outputs together, store results cleanly, and surface them in a UI — you understand why each tool exists and when to reach for it.

The framework is open source, MIT licensed, and lives at: https://github.com/sidharthsmenon2003/recon-framework

If you’re a security student building your portfolio, a bug bounty hunter who wants a structured recon workflow, or a pentester tired of scattered terminal windows — clone it, modify it, and make it yours.