09 - Recon Automation

Recon Automation - Script Analysis & Improvements

Course warning (important)

• Bug bounty programs often ban automated scanners - always read the rules first
• Automated scanners find maybe 10-20% of findings - most bugs are found manually

---

boringrecon - custom tool built from the above analysis

Source: /opt/boringrecon/boringrecon (1312-line bash script) Repo: https://github.com/g1nt0n1x/boringrecon/

boringrecon implements most of the improvements listed above. It is not a replacement for manual testing - it maps out the target so you can focus on the actual hunting.

What it covers from the proposed improvements

Proposed improvement	Status in boringrecon
httpx instead of httpprobe	Done - fingerprints with status, title, tech stack
katana crawling	Done - crawls alive hosts, re-crawls feroxbuster discoveries
Directory brute-forcing	Done - feroxbuster with seclists wordlists
Vhost discovery	Done - ffuf with auto re-scan of found vhosts
nuclei vuln scanning	Done - low-critical severity templates
Parameter extraction	Done - extracts params and JS files from crawl results
gowitness screenshots	Done - screenshots every discovered endpoint
nmap port scanning	Done - full scan or top-100 in quick mode
Error handling	Done - check_tool guards skip missing tools gracefully
Quick mode	Done - -q flag skips nuclei, vhosts, runs top-100 nmap
Subdomain enum (optional)	Done - -d flag enables subfinder/amass
Deduplication	Done - merged unique endpoints across all discovery sources

Not yet implemented: notify integration, subdomain takeover checks (subzy support is listed as optional dependency but not wired into the main pipeline).

What boringrecon adds beyond the course script

• Feroxbuster re-crawl loop - directories found by feroxbuster get fed back into katana for a second crawl pass, catching content the initial crawl missed
• Vhost auto-discovery - ffuf finds virtual hosts, then each vhost goes through the full pipeline automatically
• Interactive HTML report - tree-map visualization with tech stacks, vuln badges, discovery source tags, screenshots, search/filter. Much better than raw text output for triaging
• Custom headers - -H flag for authenticated scanning (cookies, bearer tokens, etc.), supports both inline values and header files
• Organized output structure - crawl/, scans/, screenshots/, subdomains/ directories with consistent naming

Usage examples

# HTB box - quick scan on an IP (skips nuclei/vhosts, top-100 nmap)
boringrecon -q http://10.10.11.5
 
# HTB box with a hostname - standard full scan
boringrecon permx.htb
 
# Bug bounty target - full scan with subdomain enumeration
boringrecon -d target.com
 
# Authenticated scan - pass session cookies
boringrecon -H 'Cookie: session=abc123' http://target.local
 
# Authenticated scan - headers from file (one per line)
boringrecon -H headers.txt target.com
 
# Quick recon on a bug bounty target (faster, less noise)
boringrecon -q -d target.com

Output structure

target/
  report.html              <- open this first, interactive tree-map
  crawl/
    endpoints.txt          All unique in-scope URLs
    params.txt             URLs with parameters (your injection points)
    param_names.txt        Unique parameter names
    js_files.txt           JavaScript files (check for secrets/API routes)
  scans/
    nmap_full.txt          Port scan
    nuclei.txt             Vulnerability findings
    feroxbuster.txt        Directory brute-force
    vhosts.json            Virtual host discovery
  screenshots/             Full-page screenshots
  subdomains/
    alive.txt              Alive hosts
    httpx.txt              Fingerprint data (status, tech, title)
    vhosts.txt             Discovered virtual hosts

Typical workflow

1. Run boringrecon against the target
2. Open report.html in browser - triage visually using the tree-map
3. Check params.txt for injection points (SQLi, XSS, SSRF)
4. Check js_files.txt for leaked secrets/endpoints
5. Review nuclei.txt for any flagged vulns
6. Check httpx.txt for tech stacks - pick your attacks based on the stack
7. Start manual testing on the most interesting findings