Smap: How to Port Scan 200 Hosts Per Second Without Touching a Single Target
Hook
What if you could scan an entire /24 network in under a second without sending a single packet to any target? Smap does exactly that by querying Shodan’s historical data instead of actively probing hosts—making it invisible to intrusion detection systems.
Context
Traditional port scanning is a game of patience and risk. Nmap, the gold standard for network reconnaissance, works by actively probing target hosts—sending packets, waiting for responses, and fingerprinting services. This approach is thorough but comes with downsides: it’s slow, noisy (IDS/IPS systems flag scanning activity), and legally precarious (active scanning without authorization can violate computer fraud laws).
Shodan.io changed the reconnaissance landscape by continuously scanning the entire IPv4 internet and indexing the results. Instead of scanning targets yourself, you query a database of ports, services, and vulnerabilities that Shodan has already discovered. Smap bridges these worlds by wrapping Shodan’s free API in an Nmap-compatible interface. It accepts the same command-line arguments as Nmap and produces the same output formats, allowing security professionals to drop it into existing workflows while gaining the speed and stealth advantages of passive reconnaissance.
Technical Insight
Smap’s architecture is deceptively simple: it’s a translation layer between Nmap’s CLI interface and Shodan’s REST API. Written in Go for portability and compiled to a single binary, it parses Nmap-style arguments, queries Shodan for each target, and reformats responses into Nmap’s various output formats.
The command-line interface mirrors Nmap’s syntax exactly. Scanning multiple targets with custom ports and XML output looks identical:
# Traditional Nmap scan (active probing)
nmap -p22,80,443 example.com -oX output.xml
# Smap equivalent (passive lookup)
smap -p22,80,443 example.com -oX output.xmlUnder the hood, Smap queries Shodan’s free API for each target. This doesn’t require API keys and returns recent scan data including open ports, service banners, and detected vulnerabilities. The 200 hosts/second throughput is achievable because Smap only performs lightweight API requests rather than active network probing—there’s no need to wait for TCP handshakes or service responses.
The tool supports six output formats including -oX (XML), which produces Nmap-compatible XML that existing parsers can consume. This means tools like Metasploit, vulnerability scanners, and custom scripts expecting Nmap output work with Smap:
# Scan targets from a file, output in all Nmap formats
smap -iL targets.txt -oA scan_results
# Generates: scan_results.xml, scan_results.gnmap, scan_results.nmapThe -oS format adds Smap-specific enrichments like vulnerability data and tags that Shodan associates with services. This is where Smap exceeds Nmap’s default capabilities—vulnerability detection comes for free because Shodan’s data includes identified vulnerabilities. Standard Nmap requires NSE scripts and manual configuration to achieve similar results.
Port specification uses Nmap’s range syntax but operates differently. While Nmap’s -p flag determines which ports to probe, Smap’s -p filters Shodan’s results. By default, Shodan scans these ~4000 ports and Smap displays all of them. Specifying -p21-30,80,443 doesn’t trigger scans of those ports—it filters the cached results to show only those ports if they’re in Shodan’s data:
# Show only web and SSH ports from Shodan's data
smap -p22,80,443,8080,8443 company.com -oG company.gnmapThis distinction is critical: Smap cannot discover services on ports Shodan hasn’t scanned. If you need data on port 9999 and Shodan’s crawlers don’t regularly scan it, Smap will return no results even if the service is running. The tool is constrained by Shodan’s scan coverage, which focuses on common services rather than exhaustive port ranges.
Gotcha
Smap’s passive approach comes with hard limitations that make it unsuitable for many scenarios. The most significant is data freshness—results can be up to 7 days old according to the project documentation. If a service was deployed yesterday or a port was recently closed, Smap won’t reflect that change. This makes it unreliable for verifying current security posture or confirming remediation efforts.
IPv6 support is completely absent. Shodan’s dataset overwhelmingly covers IPv4 addresses, and Smap inherits this limitation. As IPv6 adoption increases, this becomes a more serious gap. Similarly, internal networks and RFC 1918 private addresses won’t appear in Shodan’s database—the tool only works for internet-facing hosts that Shodan’s crawlers can reach. Trying to scan 192.168.1.0/24 or any private infrastructure returns empty results because Shodan has never seen those addresses.
False negatives are inevitable. If Shodan hasn’t scanned a host recently, or if a service runs on a port outside Shodan’s default port list, Smap will miss it. Newly registered domains, recently allocated IP addresses, and ephemeral cloud infrastructure may not be in Shodan’s index yet. The tool also can’t perform OS fingerprinting or advanced service detection that requires active probing—it only knows what Shodan’s data reveals. For reconnaissance requiring certainty about the current state of a network, traditional Nmap remains necessary despite being slower and noisier.
Verdict
Use Smap if you need fast reconnaissance of internet-facing infrastructure where stealth matters more than real-time accuracy—ideal for red team OPSEC, bug bounty initial enumeration, or batch scanning large IP ranges without triggering SOC alerts. It’s particularly valuable when you want vulnerability data without running NSE scripts or when existing workflows expect Nmap output formats. The 200 hosts/second speed makes it perfect for scanning thousands of targets during time-limited engagements. Skip it when you need current service state guarantees, must scan IPv6 or internal networks, require verification of remediation efforts, or are dealing with recently deployed infrastructure. Also avoid it for compliance scanning where audit trails must show active verification rather than database queries, and when targets are unlikely to be in Shodan’s dataset (unusual ports, private services, or newly allocated IPs).
