Recon Tool
Recon Tool
The Story
Recon Tool is a personal security reconnaissance application I built during 2021–2022 to gain hands-on experience with security tooling, Python, Flask, and Docker while building something useful for practical reconnaissance workflows.
The tool combines multiple existing open-source reconnaissance utilities into a single local application. Instead of manually running individual tools and correlating their output, a user provides a domain and the application orchestrates the reconnaissance workflow, collects the results, and makes them available through a web interface for review and download.
The project was designed specifically for personal and local use. It was not intended to be deployed as a production security service.
The Problem
Reconnaissance is often distributed across many independent tools, each focused on a different part of a target’s external attack surface. Running these tools individually introduces repetitive setup and execution work and makes it harder to maintain a consolidated view of the findings.
I wanted an all-in-one workflow that could take a domain as input and systematically gather information about its externally observable surface area.
The goal was not to automatically exploit findings. Instead, the tool was intended to help narrow a target down to interesting assets, services, URLs, technologies, and other observations that could be investigated further during a security assessment.
Architecture & Design
I designed the application around a simple orchestration model:
flowchart TD
A[Domain Input] --> B[Flask Web Application]
B --> C[Reconnaissance Toolchain]
C --> D[Subdomain Enumeration]
C --> E[HTTP Server Discovery]
C --> F[Subdomain Takeover Checks]
C --> G[Port Scanning]
C --> H[WAF Detection]
C --> I[Technology Detection]
C --> J[JavaScript Discovery & Secret Detection]
C --> K[Wayback URL Discovery]
D --> L[File-Based Results]
E --> L
F --> L
G --> L
H --> L
I --> L
J --> L
K --> L
L --> M[Results Web Interface]
M --> N[Review Findings]
M --> O[Download Results]The application itself was implemented in Python using Flask and packaged with Docker. I deliberately avoided introducing a database because the project was intended for local use and the reconnaissance output could be represented effectively as files.
The workflow accepts a domain and invokes a collection of existing open-source tools for different reconnaissance tasks. Their results are collected into a file-based result structure and exposed through the Flask application.
This kept the architecture relatively small:
- Flask provides the web interface and request handling.
- Python handles orchestration and application logic.
- Docker packages the application and its toolchain into a reproducible local environment.
- Files provide persistent storage for reconnaissance results without requiring database setup.
- Existing open-source security tools perform the individual reconnaissance operations.
The main engineering contribution was integrating the individual tools into a coherent workflow rather than reimplementing their underlying functionality.
Reconnaissance Workflow
Given a target domain, the tool performs several stages of surface-area enumeration:
- Subdomain enumeration to identify additional externally visible assets.
- HTTP server discovery to determine which discovered hosts expose web services.
- Subdomain takeover checks to identify potentially interesting dangling subdomain configurations.
- Port scanning to identify exposed network services.
- Web Application Firewall detection to identify apparent WAF protections.
- Web technology detection to fingerprint technologies exposed by web applications.
- JavaScript discovery and secret searching to inspect discovered JavaScript resources for potentially sensitive information.
- Wayback Machine URL discovery to recover historical or cached URLs that may reveal older endpoints, APIs, or other useful surface-area information.
- Result review and download through the web application.
The output gives the user a consolidated view of the target’s externally observable footprint. From there, the user can manually investigate the findings and focus subsequent security testing on more interesting portions of the surface.
Engineering Decisions
Dockerized Toolchain
The project depended on multiple external security utilities. Packaging the environment with Docker reduced the amount of local setup required and provided a consistent execution environment for the toolchain.
This was also an intentional learning objective of the project: I wanted practical experience packaging and running a security-oriented application and its dependencies using Docker.
File-Based Storage
I chose not to introduce a database.
For a local reconnaissance utility where each execution produces a collection of files, a file-based result structure was sufficient and avoided adding database configuration, migrations, schemas, and operational overhead.
The tradeoff is that this architecture is not designed for multi-user persistence, centralized storage, or production-scale workloads. That limitation was intentional given the project’s scope.
Tool Composition
Rather than rebuilding established reconnaissance capabilities, I focused on composing existing open-source tools into a single workflow.
This allowed the project to concentrate engineering effort on orchestration, execution, result collection, containerization, and presentation while still producing a useful security workflow.
Security & Usage Considerations
The tool was built strictly for personal use and was not intended to be hosted on a production server.
Its purpose is reconnaissance and target surface-area gathering. The results can contain sensitive information discovered during scanning, so the application should be treated as a local security utility rather than a publicly exposed service.
The tool’s role in the workflow is to support enumeration and prioritization: identify what is exposed, inspect the resulting surface, and determine which findings warrant further investigation.
My Contribution
I built the entire system, including the application, orchestration workflow, Docker packaging, file-based result handling, and web interface for viewing and downloading reconnaissance results.
The project gave me hands-on experience integrating security tooling rather than treating each utility as an isolated command-line workflow.
Impact & Metrics
No quantitative performance, user, or business metrics were collected for this personal project.
The primary outcome was a reusable local reconnaissance workflow that consolidated multiple surface-area enumeration tasks into a single tool, reducing the need to manually execute and review each individual utility.
Lessons Learned
The project reinforced the value of tool composition in security engineering. Mature security utilities can provide substantial capabilities individually, but integrating them into a coherent workflow can make the overall process significantly easier to operate.
I also gained practical experience with Docker-based packaging, particularly around building an environment that contains an application and its supporting command-line tooling.
Another important lesson was choosing architecture according to the actual scope of the system. Because this was a personal, local-use utility, a Flask application with file-based results was simpler and more appropriate than introducing a database or production-oriented infrastructure.
Most importantly, the project helped me understand reconnaissance as a pipeline rather than a collection of unrelated scans: discover assets, identify reachable services, enrich them with technology and historical information, consolidate the results, and use that information to narrow the surface for deeper security investigation.