📰 Originally published on SecurityElites — the canonical, fully-updated version of this article.
🖥️ KALI LINUX COURSE
FREE
Part of the Kali Linux Course — 180 Days
Day 21 of 180 · 11.7% complete
The OSINT phase is where most ethical hackers underperform. They run theHarvester, get some emails, run Maltego, get a graph, and call it done. Meanwhile, recon-ng is sitting in their Kali install with 90+ modules they’ve never opened — modules that chain together to build intelligence profiles that single-purpose tools can’t match.
Here’s what changed my approach to reconnaissance: I ran recon-ng on a target during a corporate pentest and in 20 minutes had more verified employee emails, associated domains, and network ranges than I’d collected manually in two hours. The workspace kept it all organised by engagement. The module chain handled the repetitive lookups automatically. I spent my time analysing, not copying and pasting between tabs.
Recon-ng Tutorial on Kali Linux Day 21 is the day recon-ng becomes your primary reconnaissance framework. Leave this lab with workspaces configured, modules installed, API keys wired in, and your first full domain intelligence collection run completed.
How are you currently handling passive OSINT collection?
Manually — copy-pasting between tools theHarvester — works for basics Maltego — GUI graph approach No structured process yet
🎯 What You’ll Master in Day 21
Recon-ng workspace creation and management — one workspace per engagement, data never bleeds
Marketplace module installation and the naming convention that tells you exactly what each module does
Running your first domain-to-contacts module chain and reading the results table
API key configuration for Shodan, Hunter.io, and FullContact — the keys that multiply your output
Exporting intelligence to HTML/CSV reports for client deliverables
⏱️ Day 21 · 3 exercises · Kali Linux terminal ### ✅ Prerequisites - Kali Linux running (any install method) — see Kali Linux Post-Installation Steps - theHarvester experience from Day 9 — recon-ng extends everything you learned there - Maltego basics from Day 13 — helps contextualise recon-ng’s relationship-mapping approach ### 📋 Recon-ng Tutorial Day 21 – Contents 1. Recon-ng Architecture — Why Workspaces and Modules Change Everything 2. Installation and First Launch 3. Workspaces — Professional Engagement Isolation 4. Marketplace — How Modules Get Into Your Install 5. Your First Module Run — Domains to Contacts 6. API Keys — Multiplying Your Intelligence Output 7. Module Chaining — Building the Full Intelligence Picture 8. Exporting and Reporting ## 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.
RECON-NG DATABASE TABLESCopy
Core tables in every recon-ng workspace
domains → target domain names
hosts → IP addresses and hostnames
contacts → names, emails, phone numbers
companies → organisation names and descriptions
credentials → usernames, passwords, hashes
ports → open ports and services
locations → physical addresses
vulnerabilities → CVEs and weaknesses found
View any table
db query SELECT * FROM contacts
db query SELECT * FROM hosts WHERE host LIKE ‘%.target.com’
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.
INSTALL AND LAUNCHCopy
Check if installed
which recon-ng
/usr/bin/recon-ng
Install if missing
sudo apt update && sudo apt install recon-ng -y
Launch
recon-ng
/// _//// /// _/// _/ _/ _/ _/ _///
_/ _/ _/ _/ _/ _/ _// / _/// _// / _/
_/// _/// _/ _/ _/ _/ _/ _/ _/ _/ _/ _// / _//
/ _/ _/ _/ _/ _/ _/ _// / _/ _/ _/ _/ _/
_/ _/ _//// /// _/// _/ _/ _/// _/ _/ _//_/
v5.x.x
[recon-ng][default] >
Core commands
help # full command list
marketplace search # browse available modules
workspaces list # show all workspaces
exit # quit recon-ng
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.
WORKSPACE MANAGEMENTCopy
📖 Read the complete guide on SecurityElites
This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on SecurityElites →
This article was originally written and published by the SecurityElites team. For more cybersecurity tutorials, ethical hacking guides, and CTF walk-throughs, visit SecurityElites.
Top comments (0)