Shodan for Defenders: Finding Your Exposed Attack Surface

Shodan is often described as a search engine for internet-connected devices. Attackers use it to find targets. Security teams should be using it first — to find their own exposed services, understand what the internet sees when it scans their IP ranges, and get alerted when something new becomes visible. If you are not already using Shodan as part of your attack surface management workflow, you are ceding reconnaissance advantage to attackers.

Understanding What Shodan Sees

Shodan continuously crawls the internet, connecting to IP addresses on common ports and recording the banners, certificates, and response data. Unlike Google, which indexes content, Shodan indexes services — the raw TCP/UDP responses that tell you what is running and how it is configured.

A single Shodan result for an IP address might include:

Open ports and the service running on each
TLS certificate details including SANs (which reveal hostnames)
HTTP response headers and page titles
SSH host key fingerprints
Vulnerability data from CPE/CVE matching
Geographic and ASN information
Historical scan data

This is exactly the data an attacker would collect during reconnaissance — and you can see it too, for your own infrastructure, before they do.

Finding Your Organization's Exposure

Start by identifying all IP ranges your organization owns. This includes cloud provider allocations (AWS, GCP, Azure), on-premises ranges, and co-location ranges. Your WHOIS records and BGP ASN data are good starting points.

# Basic Shodan search operators for your org
org:"Acme Corporation"
net:203.0.113.0/24
ssl.cert.subject.cn:"*.acme.com"

The org: filter searches Shodan's organizational metadata (derived from WHOIS). The net: filter searches a specific CIDR range. The ssl.cert.subject.cn: filter finds any host presenting a certificate with your domain — extremely useful for discovering cloud instances and CDN endpoints that might not be in your IP inventory.

Searching for Specific Dangerous Services

Once you have identified your IP ranges, search for commonly exposed dangerous services:

Exposed Remote Desktop (RDP):

port:3389 net:203.0.113.0/24

VNC without authentication:

port:5900 "authentication disabled" net:203.0.113.0/24

MongoDB without authentication:

port:27017 -authentication net:203.0.113.0/24

Elasticsearch with open access:

port:9200 net:203.0.113.0/24

Kubernetes API server:

port:6443 net:203.0.113.0/24

Exposed admin interfaces:

http.title:"Grafana" net:203.0.113.0/24
http.title:"Kibana" net:203.0.113.0/24
http.title:"phpMyAdmin" net:203.0.113.0/24

For each of these, any result within your IP range is an immediate investigation priority.

Reading a Shodan Result

Understanding what you are looking at is essential for prioritizing response. A typical Shodan result for a web service includes:

{
  "ip_str": "203.0.113.45",
  "port": 8080,
  "transport": "tcp",
  "product": "Apache Tomcat",
  "version": "9.0.31",
  "http": {
    "title": "Apache Tomcat/9.0.31",
    "server": "Apache-Coyote/1.1",
    "status": 200
  },
  "vulns": {
    "CVE-2020-1938": {
      "cvss": 9.8,
      "summary": "AJP Request Injection (Ghostcat)"
    }
  }
}

This tells you: a Tomcat instance is exposed on port 8080, running a version with a critical (CVSS 9.8) known vulnerability. Shodan has already done the CVE matching for you.

Setting Up Shodan Alerts

The most operationally valuable feature for defenders is Shodan Alerts, which notify you whenever a new result appears for an IP range or search query. This means you learn about newly exposed services within hours, not months.

import shodan

api = shodan.Shodan("YOUR_API_KEY")

# Create an alert for your IP range
alert = api.create_alert(
    name="Acme Corp IP Range",
    filters={"ip": "203.0.113.0/24"}
)

# List existing alerts
alerts = api.alerts()
for alert in alerts:
    print(f"{alert['name']}: {alert['id']}")

You can also set alerts via the Shodan web interface. Configure notifications via email or webhook. A good practice is to route Shodan alerts into your SIEM or ticketing system so every new exposure generates an investigation ticket.

Monitoring for Exposed Credentials and Config Files

Shodan indexes HTTP responses, which means it captures exposed configuration files, credential dumps, and sensitive admin pages if they are served over HTTP/HTTPS. Search specifically for these patterns:

http.html:"password" http.html:"database" net:203.0.113.0/24
http.title:"Index of /" net:203.0.113.0/24

The Index of / pattern catches Apache/nginx directory listing pages that may expose source code, configuration files, backup archives, or other sensitive data.

Using the Shodan CLI for Automation

The Shodan CLI integrates well into security automation workflows:

# Install
pip install shodan
shodan init YOUR_API_KEY

# Search and output JSON
shodan search --fields ip_str,port,product "net:203.0.113.0/24" > exposure.json

# Count results (quick overview)
shodan count "net:203.0.113.0/24"

# Get all info for a specific IP
shodan host 203.0.113.45

Run these as part of a weekly cron job and diff the output against the previous week to detect new exposures:

#!/bin/bash
shodan search --fields ip_str,port,product "net:203.0.113.0/24" | sort > current_week.txt
diff previous_week.txt current_week.txt | grep "^>" | mail -s "New Shodan exposures" security@acme.com
cp current_week.txt previous_week.txt

Defensive Workflow: Close the Loop

Finding exposure is only half the job. For each finding, document it and track remediation:

Verify the service is actually yours — Shodan data can be hours to days old, and IP addresses change hands.
Determine if it should be public — Some services are legitimately internet-facing. Document them.
For services that should not be public: add firewall rules, move to a private subnet, or implement authentication.
Re-scan after remediation — Use shodan host <ip> to confirm the port is no longer reported open. Note that Shodan may take 24-72 hours to reflect changes.
Add to your asset inventory — Every service you find on Shodan should be in your CMDB.

Key Takeaways

Shodan indexes your exposed services whether you know about them or not — you should see them before attackers do.
Search your IP ranges and certificate SANs to discover the full extent of your public exposure.
Exposed MongoDB, Elasticsearch, VNC, and RDP without authentication are critical-priority findings.
Set up Shodan Alerts on your IP ranges for continuous monitoring.
Diff weekly scan output to detect newly exposed services within days of their appearance.