From setup to recon: building a bug bounty pipeline on CachyOS and Arch Linux
Back to blog

From setup to recon: building a bug bounty pipeline on CachyOS and Arch Linux

9/1/2026 · 3 min · Cybersecurity

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:

  1. Noise and false positives: Fully automated scanners and generic LLMs generate high hallucination rates and low-context reports, damaging your platform reputation.
  2. 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.
  3. 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:


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

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:

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:

CC BY-NC

This post is licensed under CC BY-NC.

Comments

Join the discussion below.

0 comments