Bash › Bash for Bug Bounty Hunting
A complete bug bounty workflow in Bash
This capstone assembles the Bash course into one repeatable bug-bounty recon workflow: domain in, attack surface out. Each stage uses skills you’ve built; together they form the pipeline experienced hunters run on every target. The goal is breadth covered automatically, so your manual time goes to the interesting findings.
You'll learn to
- Chain the full recon flow end to end
- Save and dedupe every stage
- Know where each stage's output leads
The full flow
#!/usr/bin/env bash
set -euo pipefail
TARGET="$1"
DIR="bounty/$TARGET"; mkdir -p "$DIR"; cd "$DIR"
echo "[*] 1. Subdomains"
subfinder -d "$TARGET" -silent | sort -u > subs.txt
echo "[*] 2. Live hosts"
httpx -l subs.txt -silent > live.txt
echo "[*] 3. Historical URLs"
gau "$TARGET" 2>/dev/null | sort -u > urls.txt
echo "[*] 4. JavaScript files"
grep -E "\.js(\?|$)" urls.txt | sort -u > js_urls.txt
echo "[*] 5. Parameters (for fuzzing wordlist)"
grep -oE "[?&][a-zA-Z0-9_]+=" urls.txt | tr -d "?&=" | sort -u > params.txt
echo "[*] Done: $(wc -l < subs.txt) subs, $(wc -l < live.txt) live, $(wc -l < urls.txt) urls"
Five stages, each saving and deduplicating its output: subdomains, live hosts, historical URLs, JavaScript files, and observed parameters. One command turns a root domain into a folder of structured attack surface.
Where each stage leads
subs.txt -> the breadth of the target's footprint
live.txt -> what's actually reachable to test
urls.txt -> historical endpoints, including forgotten ones
js_urls.txt -> feed to JS analysis for endpoints + secrets
params.txt -> a TARGET-SPECIFIC fuzzing wordlist (beats generic lists)
Checkpoint
Why is the params.txt file (parameters observed on the specific target) more valuable for fuzzing than a generic parameter wordlist?
Because it contains the parameter names the target application actually uses, harvested from its real historical URLs, rather than generic guesses. Fuzzing with real, observed parameters tests the application's genuine surface and is far more likely to hit live functionality and hidden parameters than a one-size-fits-all list. It's target-specific intelligence the application itself generated, which makes it a much sharper input for finding parameter-based bugs.
Try it yourself
On an authorised, in-scope target, build the workflow up to stage 3: subdomains to a file, live hosts from that file, and historical URLs. Save and dedupe each stage. Then add stage 5 to extract observed parameter names into params.txt. Review how each saved file feeds the next phase of testing.
Key takeaways
- One workflow turns a domain into structured attack surface.
- Five stages: subs, live hosts, URLs, JS files, parameters — each saved and deduped.
- Observed parameters make a target-specific fuzzing wordlist that beats generic ones.
- Make it resumable; keep strictly within authorised scope.
Quick quiz
Finally, how professional pentesters and consultants weave Bash into their daily engagements.