reconFTW: Building a Repeatable Reconnaissance Workflow

Why I use reconFTW

Reconnaissance gets repetitive. I collect candidate hostnames, resolve DNS, check reachable services, and review what changed. reconFTW helps coordinate that work so I can spend more time on the results.

The project is maintained by six2dez and integrates a collection of reconnaissance and security tools. I think of it as a workflow around those tools. Its output still needs scope checks and manual review.

My original post listed many integrations by name. Those dependencies have changed over time, so I now organize the workflow by what I need to learn rather than by a fixed tool inventory. The project repository is the source for the current integration list.

Install and setup

I use a dedicated assessment environment with enough disk space and a clear record of installed dependencies. The installer can change the toolchain and paths, so I review it before running it.

For the Bash workflow described here:

git clone https://github.com/six2dez/reconftw
cd reconftw
git rev-parse HEAD
less install.sh
./install.sh
./reconftw.sh -h

The project also documents other deployment methods. I match the instructions to the checkout I am using. A different entry point or release can have different configuration and output conventions.

Before the first scan, I check which configuration file that checkout loads. I review enabled modules, concurrency, resolvers, output locations, and any external API credentials. I keep secrets out of shared scan archives.

An API-backed module can return little data because a key is absent, expired, or rate limited. That is different from a completed search that found nothing.

Choose a workflow before choosing a target

I divide the work into a few questions:

This keeps the final report from becoming a list of scanner messages. It also helps me notice when a stage did not run successfully.

Basic usage

The documented Bash entry point accepts a domain with -d. A passive workflow is a useful place to begin:

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

For an approved active reconnaissance run:

./reconftw.sh -d example.com -r -o ./assessment-output

Both commands use a placeholder domain. I replace it with the agreed target and confirm the behavior of the selected mode in local help before running it. Passive collection still involves external services and their data-handling rules.

For several approved domains, I use a file with one domain per line:

./reconftw.sh -l domains.txt -r -o ./assessment-output

These examples follow the project's usage instructions. I do not assume a discovered domain or a redirect destination is automatically in scope.

A run I can review

I begin with one approved domain and keep its outputs separate. After the run, I inspect what was actually created:

find ./assessment-output -type f | sort

I compare those files with the enabled modules and the execution log. If I expected DNS resolution but see only passive candidates, I investigate that gap before using the list for active testing.

For a useful example in a report, I keep the chain small: a hostname from a named source, a current DNS answer, a reachable service, and one manually verified observation. I include dates because reconnaissance data ages quickly.

Tips and gotchas

Wildcard DNS can make invented hostnames look valid. A shared IP can host unrelated customers. An archived URL can point to infrastructure the organization no longer controls. I check those cases before broadening a target list.

Resume support is useful after an interrupted run, but a resumed job is not necessarily a fresh baseline. I record the original start time and identify stages that reused earlier results.

I also resist enabling every optional module at once. Missing dependencies and noisy output are easier to diagnose in a small workflow.

Detection and defence

For a coordinated assessment, I share the approved source addresses and test window with defenders. I compare DNS, web, and network logs against the stages I ran.

The useful output is a short set of verified assets and observations, with enough provenance to repeat the work. The framework helps me gather evidence; deciding what that evidence means remains my job.