OSINT Recon Lab: Map an Attack Surface with Shodan, Amass and theHarvester

🔎 Last updated 25 Oct 2026 · Editorial policy · Report an error

Chain passive OSINT (theHarvester, Shodan) with subdomain enumeration (Amass), then validate what’s actually live before any active probing. Start with theHarvester for emails and hosts, run Amass in passive mode for subdomain breadth, resolve findings to weed out dead records, enrich with Shodan for exposed services, and only then touch targets with light active verification—against lab or explicitly authorized domains only.

Reconnaissance has a well-established playbook in offensive security—but modern attack surfaces sprawl across cloud providers, forgotten subdomains, and misconfigured services that never show up in a traditional network diagram. Open-source intelligence (OSINT) recon lets you map that sprawl without sending a single packet at the target, which is exactly why it belongs at the front of every assessment. This walkthrough gives you a repeatable, hands-on workflow you can run today against a lab domain.

What Is OSINT Reconnaissance and Why Does It Matter?

OSINT reconnaissance is the collection and analysis of publicly available information about a target—DNS records, certificate transparency logs, search engine indexes, and internet-wide scan databases. It matters because attackers do it first, and so should you. The OWASP Web Security Testing Guide dedicates an entire category (WSTG-INFO) to information gathering because a forgotten staging subdomain or an unpatched Jenkins instance exposed to the internet is a sitting door into your environment. CISA’s Known Exploited Vulnerabilities Catalog is full of internet-facing services that were found precisely this way.

The three tools in this lab play distinct roles:

• theHarvester — harvests emails, hostnames, and IPs from public search engines, certificate transparency logs (crtsh), and other passive sources. Breadth-first discovery.
• Amass (by OWASP) — the heavyweight subdomain enumeration framework, pulling from dozens of APIs and data sources, with graphing and investigation features built in.
• Shodan — a search engine for internet-connected devices. You query it to see banners, open ports, and exposed services tied to your target’s IPs, all from Shodan’s own scan data—not yours.

Passive sources tell you what probably exists. Active verification tells you what actually exists. You need both—sequenced correctly.

Lab Setup and Rules of Engagement

Before you type a single command, nail down scope. This is non-negotiable:

• Authorization: Only run this workflow against domains you own or domains explicitly in scope (a HackTheBox machine, a bug bounty program’s in-scope assets, your own lab domain). Passive queries to third parties are generally safe; active scanning without written permission is not.
• Environment: Kali Linux or Parrot OS have all three tools packaged. Otherwise, any Linux box with Go, Python 3, and pip works. Docker is fine too—Amass ships an official image.
• Documentation: Keep a scope file and log every command you run. If anyone asks what you touched, you’ll have the answer.

For this walkthrough, substitute labdomain.com with your authorized target.

Installing and Configuring the Tools

Install Amass via Go or your package manager:

# Via Go (Amass v4+)
go install -v github.com/owasp-amass/amass/v4/...@master

# Or on Kali
sudo apt install amass

Install theHarvester (v4.x) and the Shodan CLI via pip:

pipx install theHarvester
pipx install shodan

Configure Shodan with your API key—grab a free one after registering at shodan.io:

shodan init YOUR_API_KEY
shodan info   # verify your plan and query credits

Amass and theHarvester run without keys, but both yield significantly more data when you feed them API keys for sources like Censys, SecurityTrails, and Shodan itself. Configure Amass data sources in ~/.config/amass.ini; theHarvester reads api-keys.yaml in its install directory.

Step 1: Passive Email and Host Discovery with theHarvester

Start broad and cheap. theHarvester queries third-party sources, so nothing touches the target:

theHarvester -d labdomain.com -b crtsh,bing -f harvester_results

Useful switches:

• -b — comma-separated data sources. crtsh (certificate transparency) is reliably productive for subdomains.
• -f — save output to HTML/XML for your report.
• -l 500 — raise the result limit on some engines.

Expect a mix of emails (useful for phishing-surface awareness), hostnames, and IP addresses. Treat everything here as an unverified lead—not fact. Certificate logs in particular accumulate long-dead entries.

Step 2: Subdomain Enumeration with Amass (Passive Mode)

Amass passive mode is your workhorse. It queries dozens of data sources—PassiveTotal, VirusTotal, Censys, and many more—without touching the target:

amass enum -passive -d labdomain.com -o amass_passive.txt

For structured output you’ll feed into other tools:

amass enum -passive -d labdomain.com -json amass_passive.json

Tips that matter:

• Configure API keys first—the difference between 50 and 500 discovered names is usually key coverage, not tooling.
• Run amass enum -d labdomain.com -passive -min-for-enum 3 style thresholds only if you understand DNS wildcard behavior (more on that below).
• Log your data sources. Amass shows which source surfaced each name with -log or in JSON output—useful when you need to justify findings later.

Step 3: Resolving and Validating Discovered Hosts

Raw subdomain lists are 30–60% noise: wildcard records, expired hosts, CNAMEs pointing at decommissioned cloud buckets. Validate before you probe anything. Merge your lists and resolve:

cat harvester_results.txt amass_passive.txt | sort -u > all_hosts.txt

# dnsx (ProjectDiscovery) resolves and returns live hosts
cat all_hosts.txt | dnsx -silent -a -resp > resolved.txt

# httprobe checks for live HTTP/HTTPS services
cat resolved.txt | httprobe > live_web.txt

Alternatively, amass intel and Amass’s built-in DNS resolution can do much of this. The goal is a short, defensible list of hosts that actually resolve—because every host you carry forward into Shodan enrichment or active probing costs time and (eventually) scope goodwill.

Watch for DNS wildcards: if randomgarbage123.labdomain.com resolves, the zone likely has a wildcard record, and enumeration tools will happily flood you with junk. Test with a deliberately nonsense hostname first and subtract accordingly.

Step 4: Enriching Findings with Shodan

Shodan lets you see your target’s exposure as the internet sees it—using Shodan’s scan data, not your packets. Find the IPs behind your live hosts, then query:

# Look up a specific host
shodan host 203.0.113.42

# Search your domain's SSL certificates and exposed services
shodan search 'ssl.cert.subject.CN:labdomain.com' --fields ip_str,port,org,product

# Hunt for common misconfigurations
shodan search 'hostname:labdomain.com port:22'

What you’re looking for:

• Unexpected services — RDP or databases exposed to the internet.
• Stale banners — old Jenkins, Grafana, or VPN appliance versions with known CVEs.
• Forgotten hosts — assets appearing in Shodan that weren’t in your client’s asset inventory.

Caveat: Shodan data has a refresh lag. A service showing as open may be closed today, and vice versa—that’s exactly why active verification comes next.

Step 5: Active Recon on Live Hosts (Carefully)

Now—and only now, on authorized targets—verify with minimal, targeted traffic:

# Light top-port scan against confirmed in-scope IPs
nmap -sV --top-ports 100 -T3 203.0.113.42

# Web fingerprinting on live hosts
cat live_web.txt | httpx -title -tech-detect -status-code

Keep it minimal: no aggressive timing (-T4/-T5), no full 65,535-port sweeps unless scope explicitly allows, no exploitation. You’re confirming that passive findings match reality and fingerprinting tech stacks—not attacking. Every command goes in your log.

Mapping the Attack Surface: Turning Output into a Picture

Raw lists don’t persuade anyone. Build a defensible inventory:

• Graph it: Amass’s amass viz -d3 or its Neo4j integration maps relationships between domains, subdomains, and IPs—excellent for spotting shared infrastructure.
• Tabulate it: A simple table with columns for hostname, resolved IP, source(s), live status, exposed ports/services, and notes turns output into an asset inventory.
• Prioritize: Rank by exposure—internet-facing admin panels and outdated services first; stale TXT records last.

A good rule: if you can’t state where a finding came from (source, date, command), it doesn’t go in the report.

Common Mistakes and How to Avoid Them

• Scanning out of scope. Shared hosting means one IP can host dozens of unrelated domains. Verify what lives on an IP before scanning it.
• Ignoring wildcard DNS noise. Always test for wildcards before trusting an enumeration list.
• Trusting stale Shodan data. Shodan’s last scan date matters—check the timestamp before reporting a service as live.
• Not documenting sources. Undocumented findings are unreproducible and unactionable. Log tool, command, source, and date for everything.

Automating the Workflow and Next Steps

Once the manual workflow feels natural, chain it:

#!/bin/bash
DOMAIN=$1
theHarvester -d $DOMAIN -b crtsh,bing -f recon_$DOMAIN.html
amass enum -passive -d $DOMAIN -o amass_$DOMAIN.txt
cat amass_$DOMAIN.txt | sort -u | dnsx -silent -a -o resolved_$DOMAIN.txt
shodan search "ssl.cert.subject.CN:$DOMAIN" --fields ip_str,port,org,product > shodan_$DOMAIN.csv

Run it on a schedule against your own assets and you’ve crossed from one-time recon into continuous attack surface monitoring—which is where this discipline earns its keep defensively. From here, dig into the OWASP Amass documentation, Shodan’s query operators reference, and ProjectDiscovery’s tooling for the validation stage. Recon is the phase where assessments are won or lost; build the muscle now.

Frequently Asked Questions

Is OSINT reconnaissance legal?

Passive OSINT—querying public data sources like certificate logs, search engines, and Shodan—is generally legal. Active scanning requires explicit written authorization. Only test domains you own or are permitted to test, and always confirm bug bounty scope before touching anything.

What’s the difference between passive and active reconnaissance?

Passive recon uses third-party data sources without sending traffic to the target—the target never knows you looked. Active recon sends traffic directly to target systems (port scans, HTTP requests), which is detectable and requires authorization.

Do I need API keys for these tools?

Shodan requires a free API key for CLI use. Amass and theHarvester work without keys but return substantially more data when you add optional keys for sources like SecurityTrails, Censys, and Shodan.

Which tool should I run first?

Start with theHarvester and Amass in passive mode for breadth, then use Shodan to enrich the picture with exposed services and banners. Active verification comes last.

Can I use this workflow in CTFs and bug bounties?

Yes—stay within the program’s defined scope and rules of engagement, and avoid brute-force-heavy techniques unless explicitly allowed. Passive OSINT is welcomed in virtually every program.

Related reading

• Build a Deception Layer with Canarytokens and OpenCanary: Real Alerts, Real Scripts
• Weekly Threat Intel: Agentic AI Tool Abuse, Autumn 2026 CVE Surge, and Infostealer Trends

Published by Hmmnm

Hands-on cybersecurity tutorials, CVE breakdowns, and guided learning paths — written and lab-tested by the Hmmnm team.

Learning Paths · About Hmmnm · Editorial policy