Recon-ng Tutorial: Workspaces, Modules and a Short Walkthrough for Authorised Recon

Key takeaways

• Recon-ng keeps recon data in workspaces and database tables.
• Modules are installed from a marketplace, and many need API keys.
• Treat results as leads to verify, not a finished asset list.
• Use it only on authorised targets, and on your own domain for defence.

What Recon-ng is

Recon-ng is an open-source reconnaissance framework written in Python, with a console that feels like Metasploit's. Instead of exploits it holds modules that collect public information such as subdomains, hosts, contacts and leaked credentials, and stores results in a database. It is part of Kali Linux and its source is on GitHub. See also the Kali tools page.

Use it only against domains and organisations you own or have written permission to assess. Even passive collection can matter legally when you use the data for contact or access.

Core ideas

• Workspaces keep each engagement's data separate.
• Marketplace modules are installed on demand, since many are not included by default.
• Tables such as domains, hosts, contacts and credentials hold the data modules read and write.
• API keys unlock modules that use third-party services. Keys are stored locally, so protect them.

A short walkthrough

This example uses the commands of Recon-ng version 5. Run it against a domain you own. Names and options can differ between versions, so use help to confirm.

$ recon-ng
[recon-ng][default] > workspaces create demo
[recon-ng][demo] > marketplace search hackertarget
[recon-ng][demo] > marketplace install recon/domains-hosts/hackertarget
[recon-ng][demo] > modules load recon/domains-hosts/hackertarget
[recon-ng][demo][hackertarget] > options set SOURCE yourdomain.example
[recon-ng][demo][hackertarget] > run
[recon-ng][demo][hackertarget] > show hosts

What this does: it creates a workspace, installs a module that queries a public host-search service, sets the target domain, runs the module and lists the hosts found in the database. The output is a table of hostnames and, where available, addresses. Which results appear depends on the target and on the service at the time, so treat any listing as a lead to verify, not a finished asset list.

Where it fits in a workflow

1. Scope. Write down the domains and organisations in scope.
2. Collect. Run domain, host and contact modules.
3. Resolve and verify. Check which hosts exist and who owns them.
4. Export. Use the reporting modules to produce CSV or HTML for the team.
5. Hand off. Feed confirmed hosts to scanning tools such as Nmap, within scope.

Strengths and limits

Defender's view

What Recon-ng finds is what any outsider can find. Run it on your own domain, then remove forgotten subdomains, retire exposed test hosts, check DNS records and remove staff contact details that should not be public. Reconnaissance is a defensive exercise as much as an offensive one.

Next steps

Read our deeper guides on Recon-ng commands and API setup and advanced reconnaissance, plus the roundup of best OSINT tools. To learn recon within a full methodology, see the CEH v13 course.

Related reading

• How can I automate recon and detect subdomain takeovers using tools like Amass, Subfinder, and Nuclei?