Recon-ng Tutorial 2026 — Modular OSINT Framework for Professional Reconnaissance | Tools Day21

Recon-ng Architecture — Why Workspaces and Modules Change Everything

Most OSINT tools do one thing. Sublist3r finds subdomains. theHarvester finds emails. Shodan finds open ports. You run them separately, copy results between them, maintain a spreadsheet to track what came from where. It works, but it doesn’t scale.

Here’s what makes the architecture different. At the core is a SQLite database — one per workspace — with tables for domains, hosts, contacts, credentials, ports, and vulnerabilities. Modules read from those tables, do their work, and write back to them. The output of a domains module automatically becomes input for the next hosts module. Everything in one place, queried with SQL, exported in one step.

The naming convention encodes the entire module’s purpose: category/input_table-output_table/module_name. So recon/domains-contacts/whois_pocs tells you it’s a recon module, it reads from the domains table, writes to the contacts table, and uses WHOIS point-of-contact data. You know what it does before you run it.

Installation and First Launch

It ships with Kali Linux. If you’re on a minimal install or it’s missing, one apt command brings it in. The launch drops you into a Metasploit-style console — that resemblance is deliberate. Most red teamers run both tools in the same session and the interface similarity cuts the context-switch overhead.

Workspaces — Professional Engagement Isolation

The default workspace is called “default” and you should never use it for real work. Every engagement gets its own workspace. The reason is simple: if you run recon-ng against Client A in the same workspace as Client B, their domains end up in the same domains table, their contacts mix, and your output reports are a mess. More seriously, you risk including Client A’s data in a deliverable for Client B.

I create the workspace before I write a single module command. It takes five seconds and it’s the difference between a professional engagement and a data hygiene problem.

Marketplace — How Modules Get Into Your Install

When you first install recon-ng, almost no modules are present — they’re in the marketplace and you pull them as needed. This is deliberate: installing only what you need keeps the tool lean and means you’re not dragging in dependencies for 90 modules you’ll never run.

The marketplace search is powerful. Search by module name, category, or the API it requires. I always install the same core set at the start of every engagement and add specialised modules as the reconnaissance develops.

Your First Module Run — Domains to Contacts

The first module I run on every new engagement is whois_pocs. WHOIS point-of-contact records give you names, emails, and sometimes phone numbers directly associated with domain registrations. Not every domain exposes this — privacy protection shields many — but when it does, it’s a guaranteed-accurate primary contact with no ambiguity about their association with the target.

API Keys — Multiplying Your Intelligence Output

Without API keys, recon-ng uses public data only. With the right keys, every module run returns 3-10× more data from the same target. The free tiers from Shodan, Hunter.io, and SecurityTrails are enough for learning — pay tiers are worth it for client work.

Module Chaining — Building the Full Intelligence Picture

The real power is running these in sequence. Start with domains, discover hosts, resolve those hosts to IPs, then run Shodan against the IPs for service banners and open ports. Each step feeds the next and the database grows with every module run. I don’t move to active scanning until recon-ng has populated all five core tables with solid passive data.

Exporting and Reporting

At the end of a recon session, you need the data out of the database and into a format clients can read. The reporting modules handle this. HTML gives you a professional-looking report. CSV lets you import into spreadsheets or feed other tools. The full SQL query capability means you can also export exactly the subset of data you need for a specific deliverable.

Advanced Module Chaining — Building a Full Intelligence Baseline

The basic chain gets you contacts and hostnames. The professional chain extends further: company relationships, network ranges, social profiles, and technology stack fingerprinting. Each additional data point narrows your attack surface and prioritises your manual testing time.

Here’s the chain I run on every corporate penetration test engagement before I touch a single active scanning tool. Start from a domain and end with a structured intelligence picture across all tables.

The credentials table is the most operationally significant output. When HIBP (Have I Been Pwned) confirms that specific employee emails appeared in data breaches, it tells you two things: those email addresses are valid and actively used, and those users may still be using compromised passwords on the target network. That’s a phishing simulation shortlist and a password spraying candidate list generated purely from passive OSINT.

Recon-ng vs Maltego vs theHarvester — When to Use Each

These three tools cover overlapping intelligence domains but have distinct strengths. Knowing which to reach for in which scenario saves time and produces better intelligence than defaulting to the same tool every engagement.

theHarvester — fastest single-purpose tool for quick email and hostname discovery. Run it first because it completes in 2-3 minutes with no configuration. The intelligence quality is good for known sources. No workspace concept — results are a dump to stdout. Use for: quick pre-engagement check, confirming a domain is live, initial contact harvest before setting up a full recon-ng workspace.

Recon-ng — my primary tool for the main reconnaissance phase on every structured engagement. The workspace keeps engagement data isolated, the SQL interface pulls exactly what I need for any specific deliverable, and the module chain handles what would otherwise be manual copy-paste between five different tools. Use it when you need to document methodology and present outputs — not just collect them.

Maltego — best for visualising relationship graphs between entities. The GUI interface makes it easy to show non-technical stakeholders how a single employee LinkedIn profile connects to their work email, corporate network, personal social accounts, and prior employer. Use for: client debriefs, threat intelligence presentations, and any situation where visualising the connection map matters more than raw data volume.