`full-hunt-pipeline`: The Bash Glue That Turns Recon Into a One-Command Workflow

A compact shell orchestrator that chains subdomain discovery, content hunting, and vulnerability scanning into a file-driven bug bounty pipeline, with quick mode and authenticated testing built in.

8 min read • View on GitHub • More from shuvonsec

A long mechanical conveyor belt carries labeled containers from raw domain input to finished findings. The scene explains how the script turns scattered recon tools into a staged workflow with handoffs between phases. — The point is not one perfect scanner. It is the assembly line that keeps each stage fed with the right output from the last one.

Key Takeaways

`full-hunt-pipeline` matters because it turns recon into a staged, file-backed workflow instead of a pile of copied terminal commands.
Its real advantage is orchestration, not novelty, because it lets specialized tools hand off cleanly through timestamped outputs.
The script is practical by design, with quick mode, auth headers, and graceful skipping when tools are missing.
The result is faster time-to-signal, not magical detection, which is exactly why the pipeline is useful.

Most recon scripts are command lists. This one behaves more like a small operating system for a single target. The difference is subtle until you use it: every phase writes to disk, and every later phase reads from those files instead of from your memory.

The Recon Conveyor Belt

`full_hunt.sh` treats bug bounty work as a sequence of state changes. First it finds surface area, then it filters noise, then it escalates the best candidates into active checks. That is the whole trick, and it is why the repo feels more disciplined than a pile of aliases.

# Core idea: each phase leaves an artifact for the next one
./full_hunt.sh target.com --quick

# Example outputs
recon/2026-04-08/subdomains.txt
recon/2026-04-08/live_hosts.txt
recon/2026-04-08/gf_sqli.txt
recon/2026-04-08/findings.txt

The pipeline matters because handoffs are where recon usually gets messy. A good hunter can run subfinder, httpx, katana, ffuf, nuclei, and dalfox by hand. The problem is not capability. The problem is continuity.

Why Glue Code Wins

Approach	Strength	Weakness	Best for	State handling
Manual terminal chaining	Maximum flexibility in the moment	High cognitive overhead and easy to lose context	One-off experiments	Mostly in the operator's head
Single-purpose tools	Excellent at one job	Poor at handoffs and sequencing	Narrow tasks	Usually one file or one stdout stream
`full-hunt-pipeline`	Built-in workflow discipline across phases	Depends on the ecosystem it orchestrates	Repeatable bug bounty recon	File-backed and timestamped

A split editorial scene contrasts a cluttered desk full of terminals and sticky notes with a tidy shell script feeding orderly folders into the next step. The image explains why workflow design reduces missed handoffs. — Glue code wins when the hard part is not finding tools, but making them behave like one system.

Inside the Shell Orchestrator

The repo is deliberately flat. One main script does most of the work, with README guidance wrapped around it. That shape is a clue: the author wants portability more than abstraction.

The architecture is simple on purpose. Inputs enter once, files carry state forward, and each phase only needs to know what the last one left behind.

[ ! -f "$WL_DIRS" ] && WL_DIRS="/usr/share/wordlists/dirb/common.txt"

check_tool() {
  command -v "$1" >/dev/null 2>&1
}

[ -n "$TOKEN" ] && AUTH_HEADERS="$AUTH_HEADERS -H 'Authorization: Bearer $TOKEN'"

That fallback logic is more important than it looks. It means the script can survive differences between lab machines and real operator machines without breaking the workflow. Resilience is the feature.

AI-powered bug bounty hunting from your terminal - recon, 20 vuln classes, autonomous hunting, and report generation. All inside Claude Code.

shuvonsec, Project Creator · GitHub - shuvonsec/claude-bug-bounty

Phase 1: Find the Surface Area

The first phase is intentionally broad. It leans on passive recon, certificate transparency data, DNS discovery, and live host checks. The goal is not precision. The goal is coverage without making noise too early.

A telescope scans a city skyline while a notebook fills with discovered subdomains. The scene explains how passive recon gathers broad surface area before any active testing begins. — Phase one is about finding the house before you start checking the doors.

This is where the project shows its bias. It prefers a wide first pass, then makes later stages earn the right to spend time. That is a better default than brute forcing everything from the start.

Phase 2: Turn Noise Into Targets

Once the live surface is known, the pipeline starts narrowing. Crawling, fuzzing, and pattern matching transform a noisy URL dump into candidate vulnerabilities. The filters matter as much as the scanners.

Step	Input	Output	Why it matters
Crawl	Live hosts	Endpoint inventory	Finds real paths instead of guesses
Fuzz	Base URLs	Parameter and directory candidates	Expands coverage around known surfaces
gf filtering	Mixed URLs	Pattern-matched leads	Separates signal from clutter

A sorting machine drops a flood of URLs through labeled filters, leaving only a few precise candidates in bins marked for specific vulnerability classes. The image explains how pattern matching converts raw crawl data into focused leads. — This is the real filtering step. Discovery creates volume, but pattern matching creates priority.

Phase 3: Escalate With Purpose

The last phase is about selective pressure. Live hosts and filtered parameters go into nuclei and dalfox, but only after the earlier stages have reduced the search space. The script is not trying to scan everything. It is trying to scan the right things.

# Conceptually: only promote the best leads
if [ "$QUICK" = true ]; then
  run_nuclei_with_fast_templates
else
  run_nuclei_with_full_templates
  run_dalfox_on_promising_params
fi

That trade-off is smart. Quick mode is not a weaker version of the workflow. It is a different operating mode that prioritizes speed and low-hanging fruit, which is often the right move in a live engagement.

Two branching road signs show a short path labeled quick and a longer path labeled full. The visual explains the trade-off between speed and coverage in the pipeline. — Quick mode trims branches. Full mode keeps the long route open when the target deserves it.

What It Replaces, and What It Doesn’t

Workflow	What you gain	What you give up
Manual chaining	Maximum ad hoc control	Repeatability and clean state
Single-purpose scanners	Best-in-class point solutions	End-to-end handoff discipline
`full-hunt-pipeline`	Coordination and time-to-signal	Some flexibility at each step

This repo does not claim to outperform every tool it wraps. It does something more practical. It makes a batch of good tools easier to use together, which is often where real operational leverage lives.

That is why the project feels bigger than its size. The code is short, but the workflow is opinionated. It encodes a way of thinking about recon: broad first, narrow second, active last.