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?
🎯 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
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 TABLES
# 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.
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 MANAGEMENT
# Create workspace for engagement
workspaces create megacorp_pentest
[recon-ng][megacorp_pentest] >
# Prompt now shows active workspace
# List all workspaces
workspaces list
Workspaces
———-
default
megacorp_pentest
# Switch between workspaces
workspaces load megacorp_pentest
# Delete a workspace when engagement is complete
workspaces remove old_engagement
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.
MARKETPLACE — SEARCH AND INSTALL
# Search all available modules
marketplace search
# Search by keyword
marketplace search domains
marketplace search email
marketplace search shodan
# Check module details before installing
marketplace info recon/domains-contacts/whois_pocs
OUTPUT: hosts with IP addresses mail.megacorp.com → 203.0.113.44
↓ reporting/html
OUTPUT: Full intelligence report — contacts + hosts + IPs
📸 Recon-ng module chain showing how domain input transforms into a full intelligence picture across three module runs. Each module reads from one database table and writes to another — the output of whois_pocs populates contacts, hackertarget populates hosts, resolve enriches hosts with IP addresses. The final reporting/html module exports everything in one structured report. This chain produces more comprehensive data than running each equivalent tool manually, because every result feeds the next module automatically.
🧠 EXERCISE 1 — THINK LIKE A HACKER (15 MIN · NO TOOLS)
Map the Reconnaissance Chain for a Corporate Target
⏱️ 15 minutes · No tools needed
Before running a single module, professional recon planners map what they want to find and which modules will get them there. Your job here is to design the chain, not run it.
SCENARIO: You’re beginning a penetration test engagement against
a mid-sized financial services company. Your scope: the company’s
primary domain and all subdomains. Your goal: build an intelligence
baseline before active scanning.
QUESTION 1 — What do you want to collect?
List 5 types of intelligence that would be most valuable
for the subsequent active testing phase. For each one, identify
which recon-ng table it would live in.
QUESTION 2 — Which modules get you there?
Using the module naming convention (category/input-output/name),
predict which module categories would produce each of your 5
intelligence types. Don’t look them up — reason from the names.
QUESTION 3 — What order do you run them?
Some modules depend on output from previous modules.
Order your 5 modules from first to last run, explaining
why each depends on the previous one’s output.
QUESTION 4 — Which API keys matter most?
You have budget for 2 API key subscriptions (free tiers don’t count).
Which 2 paid API integrations would most expand your intelligence
output for a financial services target specifically?
QUESTION 5 — What doesn’t recon-ng find?
Name 2 intelligence types that passive OSINT tools including
recon-ng cannot collect, and explain why active techniques
are required for each.
✅ You just designed a professional recon plan before touching the keyboard. That planning step is what separates a systematic reconnaissance phase from a tool-spamming session. When you run Exercise 2, you’ll execute a real version of the chain you just designed. The intelligence categories you mapped — contacts, hosts, technologies, network ranges — are exactly what the modules in Exercise 2 will collect. The order matters: you can’t resolve hostnames until you’ve discovered them, and you can’t enrich contacts until you have them.
📸 Write out your module chain order and share in #kali-linux-course
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.
FIRST MODULE RUN — DOMAIN TO CONTACTS
# Create workspace and add target domain
workspaces create practice_run
db insert domains
domain (TEXT): example.com
# Verify domain is in database
db query SELECT * FROM domains
+—-+————-+
| rowid | domain |
+—-+————-+
| 1 | example.com |
# Load and run whois_pocs module
modules load recon/domains-contacts/whois_pocs
run
[*] Retrieving point of contact information for example.com…
[*] Country: US
[+] [contact] REDACTED FOR PRIVACY: None (None)
# Check contacts table for results
db query SELECT * FROM contacts
# On domains with public WHOIS you’ll see
[+] [contact] John Smith: jsmith@targetcorp.com
[+] [contact] DNS Admin: dnsadmin@targetcorp.com
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.
API KEY CONFIGURATION
# View all available API key slots
keys list
# Add a key (global — available across all workspaces)
shodan.io → network intelligence, open ports, banners
hunter.io → professional email discovery
securitytrails.com → DNS history, subdomains
fullcontact.com → contact enrichment
builtwith.com → technology stack fingerprinting
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.
FULL MODULE CHAIN — DOMAIN TO INTELLIGENCE BASELINE
db query SELECT first_name, last_name, email, title FROM contacts ORDER BY title
+————+———-+—————————+—————–+
| first_name | last_name | email | title |
+————+———-+—————————+—————–+
| Jennifer | Walsh | j.walsh@megacorp.com | CISO |
| David | Park | d.park@megacorp.com | IT Manager |
📸 Recon-ng running the hunter_io module against a target domain, returning verified professional email addresses with associated job titles. The CISO and IT Manager entries with their direct emails are the highest-value contacts for a spear-phishing simulation or social engineering component of a red team engagement. The db query command lets you filter and sort the collected contacts table — in this case ordering by job title to prioritise high-value targets immediately after collection.
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.
REPORTING AND EXPORT
# HTML report (full intelligence summary)
modules load reporting/html
options set FILENAME /home/kali/megacorp_recon_report.html
options set CREATOR “Mr Elite / SecurityElites”
options set CUSTOMER “MegaCorp Inc”
run
[*] Compiling report…
[+] /home/kali/megacorp_recon_report.html created
# CSV export for contacts
modules load reporting/csv
options set TABLE contacts
options set FILENAME /home/kali/contacts.csv
run
# Custom SQL query export
db query SELECT host, ip_address, region FROM hosts WHERE ip_address IS NOT NULL
⚡ EXERCISE 2 — KALI TERMINAL (20 MIN)
Run a Full Recon-ng Domain Intelligence Collection
⏱️ 20 minutes · Kali Linux required
You designed the chain in Exercise 1. Now run it against a real domain you have authorisation to test — use your own domain, your lab domain, or a domain specifically set up for OSINT practice like reconng.com (a recon-ng demo target). Work through the full collection sequence.
Step 3: Add your practice target domain
db insert domains
# Enter: your-practice-domain.com
Step 4: Run the domain-to-contacts chain
modules load recon/domains-contacts/whois_pocs
run
db query SELECT * FROM contacts
Step 5: Run domain-to-hosts
modules load recon/domains-hosts/hackertarget
run
db query SELECT * FROM hosts
Step 6: Resolve hosts to IPs
modules load recon/hosts-hosts/resolve
run
db query SELECT host, ip_address FROM hosts WHERE ip_address IS NOT NULL
Step 7: Check database summary
db summary
Step 8: Export HTML report
modules load reporting/html
options set FILENAME /home/kali/day21_report.html
run
# Open /home/kali/day21_report.html in Firefox
✅ You just ran a professional passive OSINT collection chain — zero active contact with the target, all public data sources, full database populated in under 20 minutes. The HTML report you generated is the starting deliverable for a reconnaissance phase. From here, the hosts and IP addresses feed into Nmap and Shodan scanning, the contacts feed into phishing simulations, and the subdomains feed into subdomain takeover checks. Recon-ng is the foundation layer every subsequent tool builds on.
📸 Screenshot your db summary output showing populated tables. Share in #kali-linux-course
⚡ EXERCISE 3 — KALI TERMINAL (15 MIN)
Add API Keys and Compare Output
⏱️ 15 minutes · Free API key required (5 min to register)
Register a free Hunter.io API key and wire it into recon-ng. Then rerun the same target and compare how many contacts you get with vs without the key. The difference demonstrates exactly why API keys matter.
Step 1: Register free Hunter.io API key
Go to: hunter.io
Create free account
Dashboard → API Key → copy your key
Step 2: Add key to recon-ng
keys add hunter_api YOUR_KEY_HERE
keys list
# Confirm hunter_api is set
Step 4: Run against same target from Exercise 2
workspaces load day21_practice
modules load recon/domains-contacts/hunter_io
run
Step 5: Compare contact count
db query SELECT COUNT(*) FROM contacts
# Compare: whois_pocs alone vs whois_pocs + hunter_io
Step 6: Check email format pattern
db query SELECT email FROM contacts WHERE email IS NOT NULL
# What email format does this company use?
# firstname.lastname? flastname? firstname only?
# Note the format — it’s used for generating target email lists
✅ The email format pattern discovery is one of the most practically useful outputs from this exercise. Once you know a company uses firstname.lastname@company.com, you can generate email addresses for anyone whose name you find on LinkedIn — even if Hunter.io doesn’t have them specifically. That’s the intelligence multiplication effect: one data point (email format) unlocks a much larger capability (full employee email list generation from public name sources).
📸 Screenshot the contact count comparison (before and after Hunter.io key). Share in #kali-linux-course
📋 Recon-ng Commands — Day 21 Reference Card
Create workspaceworkspaces create name
Load workspaceworkspaces load name
Search marketplacemarketplace search [keyword]
Install modulemarketplace install module/path
Load modulemodules load module/path
Run modulerun
Add domaindb insert domains
Query resultsdb query SELECT * FROM contacts
Database summarydb summary
Add API keykeys add keyname value
HTML exportmodules load reporting/html → run
Module optionsoptions list → options set KEY value
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.
[+] alice.johnson@targetcorp.com found in: LinkedIn breach (2021)
# Final: Full database summary
db summary
domains : 1
companies : 2
hosts : 14
contacts : 23
netblocks : 3
credentials: 7
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.
securityelites.com
Recon-ng HIBP Module — Breach Data Against Discovered Contacts
[*] 7 contacts found in breach databases, 16 clean
Actionable: Sarah Chen (Marketing Director) has credentials in 3 breaches — top phishing simulation and credential-stuffing candidate
📸 Recon-ng HIBP module cross-referencing discovered contacts against breach databases. The output shows which employees have appeared in known data breaches — Sarah Chen’s presence in three separate breach datasets makes her the highest-priority phishing simulation target. The CISO (Jennifer Walsh) appearing in the LinkedIn breach means her corporate email is confirmed valid, which is useful for social engineering assessments regardless of the password status. This level of context turns raw email addresses into a prioritised target list for the social engineering component of a red team engagement.
securityelites.com
Recon-ng Shodan Net Module — Network Range Intelligence
[*] 6 hosts discovered in netblock 198.51.100.0/24
📸 Recon-ng Shodan module running against a target network range, returning server software versions and open ports for each discovered host — passively, without sending a single packet to the target. The Apache/2.2.14 finding is immediately actionable: version 2.2.14 is end-of-life with multiple critical CVEs. Before active scanning has started, recon-ng has already identified a likely critical finding on a specific IP address. This is the intelligence advantage of passive OSINT over jumping straight to Nmap — you arrive at the active scanning phase with a prioritised target list rather than scanning blindly.
✅ Day 21 Complete — Recon-ng Operational
Workspaces, marketplace, module chaining, API keys, reporting. Day 22 adds Shodan to the chain — passive network intelligence that tells you what services are running on every IP address recon-ng just discovered, without sending a single packet to the target.
🧠 Day 21 Check
You run recon/domains-hosts/hackertarget and get 12 hostnames. You then run recon/hosts-hosts/resolve. What does the second module do and why does it need to run after the first?
❓ Recon-ng FAQ
What is recon-ng used for in ethical hacking?
Recon-ng is a modular OSINT framework for passive reconnaissance. It collects domain registration data, email addresses, employee names, subdomains, network ranges, and technology stack information from public sources only. Its 90+ modules chain together — output from one becomes input for the next — building comprehensive intelligence profiles from a single starting domain, without touching the target’s systems.
How is recon-ng different from Maltego?
Recon-ng is terminal-based, free, open-source, and better for automated bulk collection and scripting. Maltego is GUI-based with graph visualisation, has free and paid tiers, and excels at visually mapping relationships for presentation. Professionals use both: recon-ng for collection, Maltego for visualisation and client reporting.
Does recon-ng require API keys?
Some modules work without keys using purely public data. Many powerful modules — Shodan, Hunter.io, FullContact, SecurityTrails — need API keys. All offer free tiers sufficient for learning. Add keys with ‘keys add keyname value’. Without keys you still collect useful data; with keys the output multiplies substantially.
Is recon-ng legal to use?
Recon-ng performs passive OSINT using public data sources — legal when targeting systems you have authorisation to assess or your own infrastructure. All reconnaissance should be within your signed engagement scope. Recon-ng doesn’t exploit systems or access non-public data.
How do recon-ng workspaces work?
Workspaces are isolated SQLite databases storing all data per engagement. Create with ‘workspaces create name’, switch with ‘workspaces load name’. Each has its own tables for domains, hosts, contacts, credentials, ports, and vulnerabilities. One workspace per engagement — data from different clients never mixes.
What are the best recon-ng modules for domain recon?
Core chain: recon/domains-contacts/whois_pocs (WHOIS contacts), recon/domains-hosts/hackertarget (subdomains), recon/hosts-hosts/resolve (DNS resolution), recon/domains-contacts/hunter_io (email discovery, API key needed), recon/companies-contacts/bing_linkedin_cache (employee discovery). Run in that order — each module’s output feeds the next.
← Previous
Day 20 — Medusa Tutorial
Next →
Day 22 — Shodan Tutorial
📚 Further Reading
Day 9 — theHarvester Tutorial— The single-purpose email and domain harvester that recon-ng extends. Understanding theHarvester first makes the module architecture of recon-ng click immediately.
Day 13 — Maltego Tutorial— The GUI-based OSINT graph tool that complements recon-ng. Use recon-ng for bulk collection, Maltego for visualising the relationship map for clients.
Subdomain Enumeration Tools 2026— Amass, Subfinder, and Assetfinder compared — the active subdomain discovery tools that extend what recon-ng’s passive modules collect.
Recon-ng GitHub Repository— Official source, module documentation, and contribution guidelines. The wiki has the complete module reference with input/output table specifications for every installed module.
Kali Linux — Recon-ng Tool Page— Official Kali documentation for recon-ng including package version, dependencies, and the full command reference for the current Kali release.
ME
Mr Elite
Owner, SecurityElites.com
The engagement that converted me to recon-ng as a primary reconnaissance tool was a corporate penetration test where theHarvester had returned 8 emails after 20 minutes of running. I switched to recon-ng, added the Hunter.io key, ran three chained modules, and had 47 verified employee emails with job titles in 12 minutes. The IT Manager’s email was in the list. His password was his kid’s name plus a number — I found the kid’s name on his LinkedIn profile, which recon-ng’s LinkedIn cache module had surfaced in the same session. That’s the intelligence multiplier effect in practice: each tool feeds the next, and recon-ng is the hub that connects all of them.
