reconFTW: Recon Orchestration from Domain to Findings

How six2dez/reconFTW orchestrates subdomain enum, port scanning, and Nuclei against a target — setup, config, triage, and when to skip it.

Manually chaining twenty recon tools across a multi-hour session is a solved problem — the question is which orchestration framework you trust with the job. six2dez/reconFTW has 7,700+ GitHub stars as of early 2025 and active maintenance. That’s a reasonable baseline for confidence. What follows is how it actually works, where it fits, and where it doesn’t.

What reconFTW Does

reconFTW is a Bash framework that conducts a curated collection of third-party tools against a target domain. It doesn’t replace those tools — it sequences them, normalizes output into a predictable directory tree, and optionally pushes completion alerts to Slack, Discord, or Telegram. The entire pipeline is configurable through a single reconftw.cfg file; modules can be toggled without touching the core script.

The pipeline covers:

• Subdomain enumeration — passive (certificate transparency, DNS datasets) and active (brute force, permutation)
• DNS analysis — resolution, wildcard detection, zone transfer probing
• Web probing — live HTTP/HTTPS identification across discovered hosts
• Port scanning — full-port and targeted scans on live hosts
• Content discovery — directory and file enumeration
• Screenshot capture — visual fingerprinting of web services
• Vulnerability scanning — Nuclei templates against live targets
• Google dorking and OSINT — passive intelligence from public sources
• JavaScript analysis — endpoint and secret extraction from JS files
• GitHub dorking — public repositories searched for exposed credentials or config

Dependencies installed during setup include Amass, Subfinder, httpx, Nuclei, ffuf, naabu, and dnsx, among others. That list is reconFTW’s main operational constraint and its main operational advantage simultaneously.

Where It Fits in a Recon Workflow

Think of recon in three layers: passive OSINT (no target contact, public data only), active enumeration (DNS queries, port scans, HTTP probing), and vulnerability identification (template scanning, fuzzing). reconFTW spans all three. That breadth is the point.

On an external pentest, reconFTW slots between initial scoping and exploitation. Hand it a root domain, let it run, then triage the structured output — Nuclei findings and live hosts first — to build a prioritized target list for manual work.

For bug bounty, it earns its keep on wide-scope programs. The Nuclei integration flags low-hanging CVEs and misconfigurations automatically, which frees time for chained and logic-based vulnerabilities that automated tooling won’t catch.

For attack surface monitoring, reconFTW can run on a schedule against a fixed domain list to surface new subdomains or newly exposed services. That said, dedicated ASM platforms handle alerting and historical trending better for that specific use case — reconFTW isn’t architected around diffing runs over time.

reconFTW vs. Recon-ng vs. Spiderfoot

Recon-ng is a modular, console-driven framework that integrates cleanly with OSINT APIs. It’s the right tool for structured, analyst-directed investigations where you want explicit control over each module. It doesn’t orchestrate active scanners like Nuclei or naabu — its scope stops at intelligence gathering.

Spiderfoot offers a web UI and strong passive OSINT coverage, particularly for building relationship graphs across IPs, domains, emails, and ASNs. Like Recon-ng, it isn’t designed to run the active scanning ecosystem reconFTW depends on.

reconFTW wins when you need end-to-end coverage through vulnerability identification in a single run, the target scope is broad, and you’re running on a VPS where a long-running process is acceptable.

Skip it when you need a lightweight passive lookup, when network controls block active scanning, when your workflow requires a UI or API for team collaboration, or when the engagement requires audit-grade logging.

Before You Run It

Authorization. reconFTW does active scanning — DNS brute force, port scanning, HTTP probing, Nuclei vulnerability checks. Running it without explicit written authorization is illegal in most jurisdictions and violates every major bug bounty platform’s terms. Confirm scope before execution, every time.

Resource footprint. A full run against a large domain takes several hours and generates significant outbound traffic. Run it on a dedicated VPS. The project’s README calls out that full-run mode is not recommended on low-bandwidth connections.

Notifications. Configure a Slack, Discord, or Telegram webhook in reconftw.cfg before a long run. Polling a terminal for hours is unnecessary friction.

Reproducible Setup on Ubuntu 22.04

All commands below come from the official installation documentation in the reconFTW repository.

Step 1 — Clone the Repository

git clone https://github.com/six2dez/reconftw.git
cd reconftw

Step 2 — Run the Installer

./install.sh

The installer pulls and compiles all dependencies into ~/go/bin and related paths. On a 2-core / 4 GB VPS, budget 5–15 minutes depending on network speed. Start it, then handle configuration while it runs.

Step 3 — Configure the Tool

cp reconftw.cfg.sample reconftw.cfg
nano reconftw.cfg

First-run values worth reviewing:

• NOTIFY — set to true and populate your webhook URL
• DEEP — set to false for a faster initial run
• API keys for Shodan, SecurityTrails, Chaos — passive enumeration quality improves materially with these populated

Step 4 — Run a Scoped Test

For a passive-only smoke test against an authorized domain:

./reconftw.sh -d example.com -p

The -p flag skips active scanning modules. Output lands in ~/reconftw/Recon/example.com/.

For a full run (confirm authorization before executing):

./reconftw.sh -d example.com -r

Add -s to constrain scope to the target domain and direct subdomains, which prevents aggressive expansion on wildcard scopes.

Step 5 — Triage the Output

reconFTW writes to a predictable directory tree:

~/reconftw/Recon/example.com/
├── subdomains/       # Enumerated subdomain lists
├── webs/             # Live web hosts
├── nuclei/           # Vulnerability scan results
├── screenshots/      # Web screenshots
├── ports/            # Port scan data
└── osint/            # Passive intelligence

Start with nuclei/ — findings are categorized by severity. Cross-reference webs/ and ports/ to build a prioritized target list for manual follow-up. Don’t treat automated findings as ground truth; treat them as a triage queue.

Strengths and Honest Limitations

Where it holds up:

• Single-command orchestration of a mature, community-vetted toolset
• Active maintenance with a responsive issue tracker
• Modular config means noisy or slow modules can be disabled per engagement
• Structured output ingests cleanly into downstream workflows — feeding the subdomain list into a custom Nuclei pipeline, for example, is straightforward

Where it falls short:

• Dependency sprawl makes reproducible environments harder without containerization; there’s no first-party Docker image, and community images are unofficial
• A silent failure in one dependency degrades output quality without obvious indication — worth validating key tool versions after install
• Not built for low-and-slow assessments; it optimizes for coverage, not evasion

I’ve seen the dependency chain break on Ubuntu installs where Go version mismatches caused naabu or dnsx to compile incorrectly. The output directories still populate, but port and DNS data is incomplete. Run naabu -version and dnsx -version after install to confirm the binaries are functional before a real engagement.

Integration Patterns for Existing Pipelines

If you’re already running a custom recon pipeline, reconFTW’s config file makes it straightforward to isolate specific module groups. Setting SUBDOMAINS_ACTIVE=true and HTTP_PROBE=true while disabling everything else turns reconFTW into a subdomain-to-live-hosts resolver — useful if you want its passive source coverage without the full scanning stack.

For team environments, point the output directory at a shared NFS mount or sync it to an S3-compatible bucket via a post-run script. That makes findings immediately available without requiring SSH access to the scan host.

For broader context on the tools reconFTW orchestrates: the Nuclei documentation from ProjectDiscovery covers template-based scanning and severity interpretation, which directly applies to reading reconFTW’s nuclei output. The Amass User Guide covers the DNS enumeration methodology driving a significant portion of subdomain discovery.

The first concrete step after reading this: spin up a fresh Ubuntu 22.04 VPS, run the installer, and point reconFTW at a domain in an authorized bug bounty scope with -p (passive only). Validate the subdomain output against what you’d get from a manual Subfinder or Amass run. If the counts are comparable, your install is healthy and you have a working baseline for scoped active runs.