I Built a Bug Bounty Recon Tool That Automates the Boring Parts (So I Don’t Have To)

If you’ve ever done bug bounty hunting, you know the drill: before you get to the actually interesting part — finding a real vulnerability — you spend a huge chunk of time on repetitive setup. Enumerate subdomains. Check which ones are alive. Scan ports. Run vulnerability templates. Dig through JS files for leaked endpoints. Check if that “access denied” page really denies access. Rinse and repeat for every target in scope.

So I built a tool to automate all of it. Code’s on GitHub: **kushalbhattarai5/Bug-Bounty-Recon**.

The core pipeline

At the center is a chain of well-known, open-source security tools — mostly from Project Discovery — run in sequence with one command:

subdomains (subfinder) → live hosts (httpx) → open ports (naabu)
→ CVE/misconfig scan (nuclei) → report.md
→ optional: JS secrets, subdomain takeover, 403 bypass, screenshots, historical URLs

1. **subfinder** passively enumerates every subdomain it can find for a target.
2. **httpx** probes that list and tells you which hosts are actually online right now.
3. **naabu** scans those live hosts for open ports beyond the obvious 80/443.
4. **nuclei** runs thousands of community-maintained templates against everything, checking for known CVEs and common misconfigurations.

A Python script turns all of that into one clean report.md, grouped by severity, so I'm not digging through four separate text files after every scan.

That was the whole tool originally. It didn’t stay that way.

It kept growing

Once the core loop worked reliably, the obvious next question was: what else do I do manually, every single time, that could just be another stage? A few months later, the tool now offers five optional follow-up checks after the core scan, each with a simple yes/no prompt:

• JS secret scanning — crawls every JS file off live hosts and regex-scans them for leaked API keys, tokens, and internal endpoints. A surprising number of real findings in bug bounty come from things developers accidentally leave in client-side JavaScript.
• Subdomain takeover detection — checks the full subdomain list (not just live hosts) for dangling CNAMEs pointing at unclaimed cloud resources. This is one of the best value-per-effort bug classes out there: easy to detect, often a real, payable finding.
• 403/401 bypass testing — tries header, path, and safe-method variations against access-controlled pages to see if the restriction actually holds up. Deliberately limited to read-only methods (GET/HEAD/OPTIONS) — never PUT/DELETE/PATCH — since those can genuinely modify or delete real data if access control turns out to be broken, and I didn’t want automated testing doing that unattended.
• Screenshot capture — screenshots every live host so I can visually skim 100+ hosts instead of reading a wall of URLs.
• Historical URL triage — pulls archived URLs from the Wayback Machine, automatically filters out dead links, categorizes survivors into sensitive-files / admin-panels / API-docs / worth-testing-params, and re-scans whatever’s still alive with nuclei. Old, forgotten endpoints often run older and more vulnerable software than what’s currently deployed.

On top of that: a diffing tool that shows only what’s new since the last scan of the same target, a severity-based webhook notifier so I only get pinged for high/critical findings, an ignore.txt for suppressing template matches I've already decided aren't useful, and scheduling support via cron for ongoing monitoring of a program's scope.

The important caveat

None of this finds new vulnerabilities. Every tool here is pattern matching against known signatures — CVEs, common misconfig patterns, dangling-CNAME fingerprints, regex shapes that look like API keys. Everything it outputs is a lead, not a confirmed bug. The tool doesn’t replace the actual skill of bug bounty hunting; it clears away repetitive setup so I can spend my time on the part that actually requires a human — verifying impact and deciding what’s worth reporting.

I also built in a hard rule for myself from day one: the script makes me retype the target domain before every scan, as a forced pause to double check I’m actually authorized to test it. Scanning something without permission isn’t a gray area — it’s the fastest way to turn a hobby into a legal problem.

What actually broke (and what I learned)

A few things bit me while building this out, worth mentioning because they look like tool bugs but are actually environment quirks:

Two different tools named httpx. Kali Linux ships a Python package also called httpx — a general-purpose HTTP client library, completely unrelated to ProjectDiscovery's recon tool of the same name. Depending on PATH order, typing httpx could silently run the wrong one, and the error it throws (No such option: -l) doesn't make that obvious at all. Fixed by resolving each tool by its explicit install path instead of trusting PATH.

**naabu doesn't want full URLs.** Feeding it https://api.example.com instead of just api.example.com fails with a vague "no valid targets found" error. Easy to miss, wastes ten minutes the first time it happens.

**nuclei -jsonl makes your terminal unreadable.* I originally used -jsonl for structured output — which works, but it also* forces raw JSON into the terminal instead of nuclei's normal colorized findings. Fixed with -o for readable output plus the separate -je flag to export JSON on the side.

CLI flags drift between tool versions. Hit an “unknown flag” error from gowitness because I'd used an older flag name than what the installed version expected. Lesson: don't trust remembered flag names for fast-moving tools — check --help against what's actually installed.

The fix I’m most glad I added: resume support

The one that actually came from a real “oh no” moment: closing the terminal mid-scan after subfinder, httpx, and naabu had already finished, with only nuclei left — and realizing the only option was to start the entire scan over from scratch.

So now each stage drops a hidden marker file the moment it completes. If a scan gets interrupted, running the exact same command again auto-detects the unfinished run and asks whether to resume it — skipping every stage that already finished instead of redoing 20 minutes of subdomain enumeration to get back to the 30 seconds of nuclei that was actually left. Small feature, biggest quality-of-life improvement in the whole project.

Where it’s headed next

Still on the list: cloud storage bucket enumeration, GraphQL introspection checks, API spec discovery (hunting for exposed swagger.json/openapi.yaml files), and moving from timestamped folders to a proper database so I can query findings across every target I've scanned instead of digging through directories.

The goal was never to make this “fully automated” in the sense of removing me from the loop — verifying findings and deciding what’s worth reporting will always need a human. The goal is just to stop spending limited hunting time on setup, and spend it on the part that actually pays.