Setting up the workstation: methodology and tooling choices#
When diving into the Bug Bounty ecosystem, the first critical technical decision is not picking a specific target on HackerOne or Bugcrowd, but establishing your workstation methodology and tooling.
I built my hunting environment on an Asus TUF F16 running CachyOS (a performance-optimized Arch Linux distribution). With its optimized kernel and task scheduling, the OS delivers snappy parallel execution and fast Go package builds.
However, a fundamental dilemma quickly emerged: should you hunt bugs manually or attempt full AI automation? And how do you chain terminal utilities into an effective Reconnaissance (Recon) funnel?
Below, I share the architectural choices, the Go toolchain installed, and the custom Bash automation script I built to map attack surfaces.
1. The dilemma: manual hunting vs. AI automation#
The temptation to build an autonomous LLM agent to collect bounties on autopilot is strong, but offensive security reality quickly dispels that fantasy:
- Noise and false positives: Fully automated scanners and generic LLMs generate high hallucination rates and low-context reports, damaging your platform reputation.
- Business logic requires human context: Critical vulnerabilities (such as IDOR/BOLA broken access controls or multi-step logic bypasses) require human intuition and holistic application understanding.
- Tooling asymmetry: Obvious vulnerabilities surfaced by basic one-click tools have already been patched by internal security pipelines or reported by mass-scale scanners.
Positioning AI as a technical co-pilot#
Instead of autonomous hunting, I use LLMs strictly as assistive technical co-pilots:
- Assisted static analysis (SAST): In whitebox targets, using AI to accelerate reviews of dense source code blocks for logic flaws.
- Rapid PoC script generation: Generating lightweight Python scripts to fuzz specific HTTP parameters and validate response codes.
- Technical dissection: Rapidly breaking down unfamiliar cryptographic implementations or legacy third-party libraries identified in target assets.
2. The recon toolset on CachyOS / Arch Linux#
Approximately 70% of Bug Bounty success occurs during Reconnaissance (Recon): discovering forgotten subdomains, exposed staging environments, and non-standard open ports.
Leveraging the AUR (Arch User Repository), I installed native Go and C binaries without virtual machine bloat:
# Passive subdomain discovery and DNS tools
yay -S subfinder amass assetfinder findomain
# Active HTTP probing and port scanning
yay -S httpx-bin nmap naabu-bin
# Directory and file fuzzing
yay -S gobuster dirsearch-git
3. The recon funnel architecture#
To minimize bandwidth usage and avoid noisy scanning, the workflow follows a three-stage funnel:
[ Root Domain ]
│
▼ (1. Passive Subdomain Gathering)
[ Raw Subdomain List ]
│
▼ (2. HTTP Probing with httpx)
[ Live Hosts + Status Codes + Tech Stacks ]
│
▼ (3. Fast Port Scanning with Naabu)
[ Filtered Attack Surface ]
Stage 1: Passive subdomain gathering#
Queries public record databases (SSL transparency logs via crt.sh, historical DNS, and public APIs) without sending direct packets to the target:
# Run passive tools
subfinder -d domain.com -silent > subs_subfinder.txt
assetfinder --subs-only domain.com > subs_assetfinder.txt
# Merge and deduplicate
cat subs_subfinder.txt subs_assetfinder.txt | sort -u > subs_unique.txt
Stage 2: Live host validation with httpx#
httpx probes ports 80 and 443, returning HTTP status codes, page titles, and detected technologies:
httpx -l subs_unique.txt -silent -status-code -title -tech-detect -o live_hosts.txt
- Key focus areas:
403 Forbiddenresponses (potential admin panels accessible via header bypasses) and500 Internal Server Errorendpoints (which often leak stack traces).
Stage 3: Fast port scanning with naabu and nmap#
To avoid slow full-subnet scans with nmap, naabu performs an asynchronous scan across top ports, piping open ports into nmap for detailed service fingerprinting:
# Fast asynchronous port scan
naabu -list subs_unique.txt -top-ports 100 -o open_ports.txt
# In-depth service detection on filtered hosts
nmap -sV -sC -p 80,443,8080,8443 -iL subs_unique.txt -oN scan_nmap.txt
4. The automation script: recon.sh#
To automate this workflow cleanly against authorized targets:
#!/bin/bash
DOMAIN=$1
if [ -z "$DOMAIN" ]; then
echo "[-] Error: Missing domain parameter."
echo "Usage: ./recon.sh domain.com"
exit 1
fi
echo "[+] Starting Recon for target: $DOMAIN"
# 1. Passive Subdomain Discovery
echo "[+] Gathering subdomains passivamente..."
subfinder -d "$DOMAIN" -silent > subs.txt
assetfinder --subs-only "$DOMAIN" >> subs.txt
sort -u subs.txt -o subs_clean.txt
echo "[+] Unique subdomains found: $(wc -l < subs_clean.txt)"
# 2. Live HTTP Probing and Metadata
echo "[+] Probing live hosts and collecting HTTP metadata..."
httpx -l subs_clean.txt -silent -sc -title -td -o active.txt
echo "[+] Recon completed. Results saved to 'active.txt'."
Execution:#
chmod +x recon.sh
./recon.sh domain.com
Next steps and bug bounty best practices#
With a solid recon pipeline in place:
- Hands-on practice: Train manual exploitation techniques on platforms like PortSwigger Web Security Academy and master the OWASP Top 10.
- Strict scope adherence: On HackerOne and Bugcrowd, review program rules before launching active scanners to respect rate limits and out-of-scope assets.
- Start with VDPs: Vulnerability Disclosure Programs (focusing on points and reputation rather than immediate cash) have lower competition and are ideal for refining reporting quality.
Automating repetitive terminal workflows leaves you free to focus on what matters most: in-depth application logic analysis.
Was this article helpful?
Leave a quick reaction to help prioritize future technical guides:
This post is licensed under CC BY-NC.



Comments
Join the discussion below.
0 comments