reconFTW: the bash layer that decides what gets run against a domain

One entry point in front of twenty separate programs

The useful thing about reconFTW is not a discovery technique, because it does not have one. It is a bash layer that decides which of the existing security tools run, in what order, with what arguments, and where each tool's output lands. The repository tree shows that structure plainly: `reconftw.sh` is the entry point, `modules/` holds the per-task scripts, `config/` the auxiliary configuration, and `reconftw.cfg` the main switchboard. `lib/` sits alongside them for shared helpers.

GitHub reports the primary language as Shell, which matches that layout. The same tree also carries `Docker/`, `Terraform/`, `Proxmox/` and `install.sh`, so the project has grown deployment paths faster than it has grown a package manifest. There is no `package.json` or `pyproject.toml` at the root because there is nothing to install in the dependency-manager sense.

The README groups what it drives into six families: OSINT, subdomains, hosts, web analysis, vulnerability checks and extras. Under those headings sit checks for XSS, SSRF, SQLi, LFI and SSTI, plus directory fuzzing, port scanning and screenshotting. What the orchestrator adds over running those tools by hand is consistency of output, not new capability, and that framing matters if you are deciding whether it duplicates something you already script yourself.

Four discovery paths that v4.1 turned on

The v4.1 release notes are the most concrete documentation in the repository, and they read like an engineering changelog rather than a marketing post. Four additions target asset discovery, and three of them are controlled by named config flags with named output files, which makes the behaviour of a run predictable from the config alone.

`sub_srv` enumerates SRV records through dnsx, looking for service hosts such as `_ldap._tcp` and `_sip._tcp`. It is off unless `SRV_ENUM=true`, writes to `subdomains/srv_records.txt`, and draws its prefix list from `data/wordlists/srv_prefixes.txt`, which the notes describe as roughly 27 prefixes.

`sub_ptr_cidrs` goes sideways rather than deeper. It takes the ASN CIDR ranges found by `sub_asn`, expands them with mapcidr, runs reverse PTR lookups through dnsx and filters for in-scope results. It ships disabled, with `PTR_SWEEP=false` and a ceiling of `PTR_SWEEP_MAX_IPS=50000`, because expanding an ASN into individual addresses is the kind of step that turns a recon run into an outbound flood if nobody bounds it.

`sub_ns_delegation` looks for delegated zones, meaning subdomains carrying their own NS records, then attempts an AXFR zone transfer against each delegated nameserver. The release notes are candid that the existing `zonetransfer()` only checked the main domain's NS records, so this is a gap being closed rather than a duplicate. The same set of notes adds `tls_ip_pivots`, which harvests certificates from raw IPs rather than only from known subdomains, in three phases starting with a passive SAN and CN harvest via `tlsx -json` and moving into SNI brute forcing.

Bash v4.1 and the Go rewrite are two different products

Two facts about reconFTW's versioning sit side by side and a reader can easily take the wrong one at face value. The README's table of contents advertises a section called Trying the v2 beta (Go rewrite). The newest GitHub release is tagged v5.0.0-beta.1. Those are the same rewrite described under two names, and the repository does not reconcile the naming.

The v5.0.0-beta.1 release notes are the most honest document in the project about where that rewrite stands, and they open by saying the release is opt-in: `releases/latest` still resolves to bash v4.1, because GitHub does not point `latest` at a pre-release. So a reader who follows the obvious install path gets the bash line, which is what most people want today.

Those notes then list three things that are not done. Parity was measured against one target rather than the three to five the plan calls for, so differences elsewhere are unmeasured rather than disproved. Throughput is unmeasured, with no claim in either direction about speed. And the output tree is wrong: the `Recon/<domain>/` directory the bash version produces is not created, and the bash-shaped tree is written under a `_compat/` directory at the workspace root instead. If anything downstream reads that path, the release notes say plainly that it will find nothing.

The Makefile targets are the honest entry point for contributors

For using reconFTW the README points at docs.reconftw.com and at Docker, Terraform and Ansible deployment paths. For working on it, the root `Makefile` says more than any badge. It separates unit tests, integration tests and a release gate, which is a distinction most shell projects skip.

make test-unit
make test-integration-smoke
make test-release-gate
make test-security
make lint
make fmt
make setup-dev

`make lint` runs shellcheck and `make fmt` runs shfmt, and the repository carries both a `.shellcheckrc` and a `.pre-commit-config.yaml`, so formatting is enforced rather than suggested. `make test-integration-smoke` and `make test-integration-full` are separate targets, which implies the project knows full integration runs are expensive and wanted a cheaper gate.

One recipe is worth reading for what it says about threat model. The `bootstrap` target creates a private repository to hold data, and it validates the repository name before using it:

repo="$${PRIV_REPO:-reconftw-data}"
case "$$repo" in (*[!A-Za-z0-9._/-]*|'') echo "invalid repo name: $$repo"; exit 2;; esac
gh repo create "$$repo"

The comment above it explains the reason: shell metacharacters in an environment variable must not be interpreted by the shell running the recipe. For a tool whose whole job is to execute other people's binaries with attacker-influenced arguments, seeing the maintainers guard their own Makefile is a reasonable signal about the project's priorities.

AX Framework, Faraday and two hosting paths

reconFTW distributes work and collects results through two named integrations, and both matter for how a run behaves at scale.

AX Framework, called Axiom in earlier versions and renamed in this one, is how a single recon run is spread over several machines. The README lists distributed scanning through it as a key feature and gives it its own section, alongside Faraday for reporting and visualization. The pairing is sensible: AX is about spreading work out, Faraday is about turning the results into something a person can read. Neither is required for a small scope, which is the case where reconFTW is at its most straightforward.

Deployment has three documented paths in the README's contents: local installation on a PC, VPS or VM, a Docker image, and a Terraform plus Ansible combination. The tree adds a `Proxmox/` directory on top of that, so bare metal and Proxmox hosts are a supported shape as well. The README also has a Data Management section covering both the Makefile targets and a manual path, which tells you the project expects people to move results between machines rather than treating a run as self-contained.

`secrets.cfg.example` at the root is a reminder of what a run depends on. Passive sources and API-backed enumeration are part of the feature list, and API-backed enumeration means keys, which means a credentials file that should never be committed. `tools.lock` at the root points the other way, toward pinning versions of the external tools so a run is reproducible.

What the README settles and what it does not

The README is an index more than a manual. It names the six feature families, lists the deployment paths, links to docs.reconftw.com, and stops there. Every question that actually affects a run, which flags exist, what each one defaults to, what the output tree looks like, is answered in the configuration file or in the hosted documentation.

That is a reasonable division, and it is also a limit on what you can learn before installing. The evidence that config flags are the real interface is the release notes themselves, where each v4.1 addition arrives as a flag name, a default value, an output path and a data file. A reader who wants to predict what a run will do should read `reconftw.cfg` before the first execution rather than after discovering the behaviour from a directory listing.

The release notes are also where the honest limits are. `PTR_SWEEP` ships off with a hard address ceiling, `SRV_ENUM` and `NS_DELEGATION` need explicit enabling, and the Go rewrite is labelled incomplete on three named counts. A project that documents its own unfinished work this plainly is easier to adopt than one that does not, and the practical starting point is the bash v4.1 line with its `Recon/<domain>/` output, since that is the version `releases/latest` still points at.

Editorial conclusion

reconFTW is worth your time if your bottleneck is running twenty tools in the right order and writing their output somewhere consistent, because that layer is exactly what the project owns. It is the wrong tool when you need one vulnerability check done carefully, since it delegates every check to a separate program and the config surface is far larger than any single scanner's. Install the bash v4.1 line, read reconftw.cfg before your first run rather than after it, and if a pipeline reads Recon/<domain>/ stay on v4.1 until the rewrite's own release notes say that path exists again.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. six2dez/reconftw on GitHub