Back to Articles

reconFTW: Building a 50-Tool Reconnaissance Pipeline with Bash Orchestration

[ View on GitHub ]

reconFTW: Building a 50-Tool Reconnaissance Pipeline with Bash Orchestration

Hook

A single bash script orchestrates 50+ specialized security tools, generates gigabytes of reconnaissance data, and can scale across cloud instances to map entire corporate attack surfaces in hours. Welcome to industrial-scale reconnaissance automation.

Context

Bug bounty hunters and penetration testers face a paradox: the security tooling ecosystem has never been richer, with hundreds of specialized tools for subdomain enumeration, port scanning, web analysis, and vulnerability detection. Yet this abundance creates friction. A comprehensive reconnaissance workflow might require running subfinder for passive subdomain discovery, massdns for DNS bruteforcing, httpx for HTTP probing, nuclei for vulnerability scanning, and dozens more tools—each with different installation requirements, output formats, and optimal configurations.

The traditional approach meant writing custom bash scripts to chain these tools together, parsing outputs, handling failures, and manually correlating results. Every security professional ended up maintaining their own fragile collection of automation scripts. reconFTW emerged as a community answer to this problem: a production-ready orchestration framework that codifies best practices from thousands of bug bounty engagements into a single, configurable pipeline. With over 7,500 GitHub stars, it represents the collective wisdom of the offensive security community about which tools work best together and in what sequence.

Technical Insight

At its core, reconFTW is a bash orchestration framework built around a modular workflow engine. The main reconftw.sh script implements a state machine that progresses through distinct reconnaissance phases: OSINT gathering, subdomain enumeration (passive, active, and bruteforce), host discovery, web analysis, vulnerability scanning, and reporting. Each phase is implemented as a bash function that can be toggled via the central reconftw.cfg configuration file.

The architectural genius lies in how it handles tool chaining and result correlation. Rather than treating tools as isolated executables, reconFTW implements a pipeline pattern where each tool's output becomes the input for subsequent stages. For example, the subdomain enumeration phase might look like this:

function subdomain_enum() {
    # Passive enumeration using multiple sources
    subfinder -d $domain -o $output/passive_subdomains.txt
    amass enum -passive -d $domain -o $output/amass_passive.txt
    
    # Combine and deduplicate
    cat $output/*_passive.txt | sort -u > $output/all_subdomains.txt
    
    # Active DNS resolution
    puredns resolve $output/all_subdomains.txt -r resolvers.txt -w $output/resolved.txt
    
    # HTTP probing on resolved domains
    httpx -l $output/resolved.txt -o $output/http_alive.txt
    
    # Feed live HTTP hosts to web analysis phase
    web_analysis $output/http_alive.txt
}

This pattern ensures data flows consistently through the pipeline while maintaining isolation between stages. If one tool fails, the pipeline continues with available data rather than crashing entirely.

The configuration management system deserves special attention. The reconftw.cfg file isn't just a key-value store—it's a declarative workflow definition. You can toggle entire scanning phases, configure API keys for commercial services (SecurityTrails, Shodan, VirusTotal), set resource limits, and define custom tool parameters:

# reconftw.cfg excerpt
OSINT=true
SUBDOMAINS_GENERAL=true
SUBBRUTE=true
PERMUTATIONS=true
NMAP=false  # Disable noisy port scanning

# API keys for enhanced enumeration
securitytrails_key="YOUR_KEY"
shodan_key="YOUR_KEY"

# Resource limits
MAX_THREADS=10
RATE_LIMIT=150  # requests per second

# Notification settings
slack_channel="#recon-alerts"
discord_webhook="https://discord.com/api/webhooks/..."

One of reconFTW's most powerful features is its integration with the AX Framework (formerly Axiom) for distributed scanning. When you're mapping a large attack surface—say, enumerating subdomains for a Fortune 500 company—running everything sequentially on a single machine can take days. The AX integration allows you to spawn multiple cloud instances (AWS, DigitalOcean, GCP) and distribute subdomain bruteforce operations across them:

# Distributed subdomain bruteforce across 10 cloud instances
reconftw -d target.com -m distributed -i 10

Under the hood, this splits your DNS wordlist into chunks, deploys reconFTW to ephemeral cloud instances, runs bruteforce operations in parallel, and aggregates results back to your control node. This horizontal scaling can reduce reconnaissance time from days to hours.

The result management system organizes output into a consistent directory structure that makes post-processing tractable. Each target gets its own directory tree with subdirectories for subdomains, web analysis, vulnerabilities, and screenshots. Results are stored in both raw format (for re-processing) and filtered format (for immediate analysis). The tool also implements diff-based change detection for continuous monitoring:

reconftw -d target.com -m diff
# Compares current scan results against previous baseline
# Alerts on new subdomains, new open ports, new vulnerabilities

This makes reconFTW valuable not just for one-time assessments but for ongoing attack surface monitoring—crucial for both bug bounty hunters tracking their targets and red teams maintaining persistence awareness.

The integration with Faraday (a collaborative penetration testing platform) demonstrates production-grade thinking. Rather than leaving results scattered across text files, reconFTW can push structured findings directly into Faraday's database, where they become queryable, taggable, and shareable across team members. This bridges the gap between automated reconnaissance and manual exploitation phases.

Gotcha

The bash architecture that makes reconFTW flexible also makes it fragile. You're managing dependencies for 50+ tools written in Go, Python, Ruby, and C. When httpx updates its output format or nuclei changes its template structure, your reconnaissance pipeline can break silently—producing incomplete results without obvious errors. The installation script helps, but keeping everything synchronized across tool updates requires ongoing maintenance. Docker deployment mitigates this but adds its own complexity and resource overhead.

More critically, reconFTW generates massive network footprints. A full scan against a moderate-sized domain can make hundreds of thousands of DNS queries, thousands of HTTP requests, and trigger every intrusion detection system in sight. This is fine for bug bounty programs with explicit permission, but problematic for stealth engagements. The tool also hammers APIs—if you're using free tiers of SecurityTrails or Shodan, you'll hit rate limits quickly. On the resource side, expect multi-gigabyte result directories and significant bandwidth consumption. I've seen full scans generate 10+ GB of data for complex targets. If you're working from a bandwidth-capped connection or limited storage, you'll need to carefully tune which phases to enable.

Verdict

Use if: You're conducting authorized reconnaissance for bug bounty programs or penetration tests where comprehensive attack surface mapping matters more than stealth. It excels when you need to quickly establish a baseline of all discoverable assets for a target organization, especially if you have API keys for commercial intelligence services and the infrastructure to handle large result sets. The continuous monitoring mode makes it valuable for long-term bug bounty engagements where you want automated alerts on infrastructure changes. Also ideal if you're already familiar with the underlying tools and want proven orchestration rather than building your own glue scripts.

Skip if: You need surgical, low-noise reconnaissance that won't trigger every IDS on the network. Also avoid if you're on resource-constrained infrastructure (limited bandwidth, storage, or compute), lack authorization to perform aggressive scanning, or are just starting in offensive security—you'll learn more by mastering individual tools like amass and nuclei before abstracting them away. If you need Windows-native operation or require precise control over scanning techniques for research purposes, use the underlying tools directly instead.

// ADD TO YOUR README
[![Featured on Starlog](https://starlog.is/api/badge/cybersecurity/six2dez-reconftw.svg)](https://starlog.is/api/badge-click/cybersecurity/six2dez-reconftw)