Shodan Attack Surface Monitoring: Asset Discovery, Exposure Alerts, and Vulnerability Correlation
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
The first Shodan search on the organization's IP ranges after joining a new security team surfaced a Jupyter Notebook instance with no authentication on a cloud IP, accessible to the entire internet. The internal asset inventory had no record of it. The AWS account tag was an engineer's personal test account that had been granted production VPC access for debugging six months earlier. The instance contained API credentials for three production services in its notebook history, accessible to anyone who had found the same open Jupyter instance in Shodan.
Shodan's value is not primarily in the advanced analysis features — it is in showing you exactly what attackers see when they search for your organization. The basic net: search on your CIDR ranges is sufficient to surface the shadow IT, forgotten deployments, and accidental firewall openings that are the most likely initial access vectors for attacks against your infrastructure. The Shodan Monitor continuous alerting closes the gap between point-in-time discovery and ongoing exposure visibility.
Initial discovery: building the external asset inventory from Shodan data
The external asset inventory built from Shodan data is typically 20-40% larger than the internal asset inventory in organizations that have not previously run an external attack surface assessment. Cloud deployments that bypass the standard provisioning process, development environments that were never decommissioned, and third-party services using the organization's domain names are the categories most commonly missed by internal inventory processes and most commonly found through Shodan.
Cross-reference Shodan results against the internal asset inventory to identify unknown internet-facing hosts
Export all Shodan results for the organization's IP ranges and compare them against the internal CMDB or asset inventory using IP address as the join key. For each IP in Shodan results that has no matching entry in the internal inventory, create a shadow asset investigation ticket that identifies the cloud account or network segment the IP belongs to (use AWS/GCP/Azure console IP lookup or BGP reverse lookup), determines what service is running (from the Shodan banner and port data), and assigns ownership to a specific team for investigation. Within one week of discovery, each shadow asset should be either brought into the formal asset management process with an owner and patching SLA, or decommissioned and the firewall rules closed. Shadow assets that remain unassigned after two weeks should be escalated to the CISO for decision — an internet-facing host with no owner represents an unmitigated risk.
Use Shodan's historical data to identify when assets first appeared and correlate with deployment records
Shodan Enterprise provides historical scan data showing when a host first appeared in Shodan scans, which port configuration changes have occurred, and what the banner content has been over time. Use historical data to investigate newly discovered Shodan assets: if a host first appeared in Shodan scans six months ago coinciding with a cloud infrastructure migration project, the asset may be a legitimate deployment that was not added to the internal inventory during the migration rush. If a host first appeared last week with no corresponding deployment record, it may be an active configuration change or a recent breach-related deployment. For hosts with sensitive services (databases, management interfaces), review the full historical timeline to determine how long the exposure has existed and whether any banner changes (password prompt added, service upgraded) indicate the team is aware of and actively managing the exposure. Historical data is also useful for incident response: determining when a compromised host first became internet-accessible establishes the minimum possible window for exploitation.
Continuous monitoring: Shodan Monitor for new exposure alerting
Point-in-time Shodan searches provide the initial asset discovery baseline but miss exposures that emerge between searches. A firewall rule opened for a 30-minute debugging session that is never closed, a new cloud instance deployed by a team member without going through the standard process, or a Docker container that accidentally binds to 0.0.0.0 instead of 127.0.0.1 are all exposures that Shodan Monitor alerts on within hours of them appearing in Shodan's scan data.
Configure Shodan Monitor webhook integration with Slack for immediate team notification on new port exposures
Configure the Shodan Monitor webhook to post alerts to a dedicated Slack channel (#external-exposure-alerts) with a formatted message that includes the IP address, newly opened port, service banner, associated hostname (from Shodan's reverse DNS), and a direct link to the Shodan host page for investigation. Set the webhook trigger for Any new open port on monitored networks as the primary high-priority alert, and configure the Slack message to @here for new port alerts on production IP ranges and no mention for development IP ranges. The direct Shodan host link in the Slack message allows the on-call engineer to immediately see the full Shodan record for the newly exposed host — what service is running, what banner it presents, what other ports are open — without running a manual Shodan search. Add a Slack workflow button to the alert message that creates a tracking ticket in Jira automatically, so the exposure is captured in the vulnerability management system from the moment it is detected rather than only after a human manually creates the ticket.
Run a Shodan search for your organization after every major infrastructure change to verify no unintended exposures
Make a Shodan verification search a standard post-deployment checklist item for all infrastructure changes that involve firewall rules, security groups, network ACLs, or load balancer configuration. After completing any such change, run net:AFFECTED_IP_RANGE on Shodan and compare the results against the pre-change baseline to confirm that only the intended services are now visible. Cloud provider APIs report security group changes synchronously, but Shodan's scan data reflects the actual internet-visible state — a security group change that accidentally opens a broader port range than intended will appear in Shodan within 24-48 hours of Shodan's next scan of that IP. For high-priority infrastructure (production databases, payment systems, authentication services), run Shodan checks immediately after any firewall change rather than relying on Shodan Monitor's periodic scan cycle, since the monitor may take 24-72 hours to detect a new exposure depending on Shodan's scan schedule for that IP range.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
Shodan provides the external attacker's view of your infrastructure that internal network scanners and cloud console dashboards cannot replicate. Start with net: CIDR range searches across all registered IP blocks, org: searches for cloud-hosted assets, and ssl: domain searches for certificate-identified assets to build the complete external asset inventory. Cross-reference against internal CMDB to identify shadow assets for immediate remediation or decommissioning. Deploy Shodan Monitor with webhook-to-Slack integration for continuous alerting on new port exposures across production IP ranges. Integrate Shodan API into the daily security workflow for automated shadow asset detection and vulnerability correlation. Prioritize Shodan-discovered internet-facing vulnerabilities above equivalent internal findings since external exposure means any attacker can attempt exploitation without network access. Run Shodan searches after every firewall or security group change to verify no unintended exposures resulted from the change.
Frequently asked questions
How do I use Shodan to discover my organization's internet-facing assets?
Discover your organization's internet-facing assets in Shodan by searching across all known IP ranges, ASN, and domain names. Start with the CIDR range search: net:203.0.113.0/24 for each of the organization's registered IP blocks (obtain the full list from ARIN, RIPE, or APNIC by searching for your organization). Add the org: filter to catch assets in cloud provider ranges registered to your organization: org:'Your Company Name' which returns all Shodan-indexed hosts where the BGP registration shows your organization as the owner. Add SSL certificate domain searches to find cloud assets using your domain's TLS certificates: ssl:'yourdomain.com' returns all hosts where a TLS certificate containing your domain name is presented, regardless of IP range — this catches cloud instances, CDN endpoints, and third-party services hosting your domain that are not in your registered IP space. Build a union of all three searches, deduplicate by IP, and compare against your internal asset inventory to identify the unknown assets that appear in Shodan but not in your tracking system — those unknown assets are the immediate security focus.
How do I set up Shodan Monitor for continuous alerting on new exposures?
Set up Shodan Monitor at monitor.shodan.io by adding your organization's IP ranges as monitored networks and configuring alert notifications. After logging in with a Shodan account that has a Monitor subscription, click Add Network and enter each CIDR range you want to monitor. Configure alert triggers: New open port (alerts when a previously closed port becomes open on any monitored IP), New vulnerability (alerts when Shodan detects a new CVE on a monitored asset, requires Shodan Enterprise), and New service (alerts when a new service type appears). Configure alert delivery to email and optionally to a webhook endpoint that posts to Slack: the webhook receives a JSON payload with the IP, port, banner, and vulnerability data for the newly detected exposure. Set the alert frequency to Immediately for critical exposure types (new open ports on production IP ranges) and to Daily digest for informational changes (SSL certificate updates, banner changes) to manage notification volume. Review Shodan Monitor alerts daily during business hours as a first indication of accidental exposure — a new open port alert at 3am may indicate an engineer opened a firewall rule for testing and forgot to close it.
How do I use Shodan to identify shadow IT and unauthorized cloud deployments?
Identify shadow IT and unauthorized cloud deployments using Shodan's favicon hash search and SSL certificate domain searches to find instances of specific applications deployed by teams without security team knowledge. Calculate the MurmurHash of the favicon.ico file from a known instance of a corporate web application (use a Python script: import mmh3, requests; favicon = requests.get('http://app.example.com/favicon.ico').content; print(mmh3.hash(base64.encodebytes(favicon))) then search Shodan for all internet-exposed instances of that application: http.favicon.hash:-123456789. Every result is a publicly accessible instance of that application — compare against the approved deployment list to identify unauthorized deployments. For cloud asset discovery, use the ssl: filter to find cloud instances using your organization's TLS certificates that were not provisioned through the standard process: ssl:'*.yourdomain.com' may surface development environments, proof-of-concept deployments, or expired environments that were not properly decommissioned. Shadow IT found through Shodan is typically more critical than shadow IT found through internal network scanning because it represents internet-exposed exposure with no security controls applied.
How do I use the Shodan API to automate asset monitoring and vulnerability tracking?
Automate Shodan asset monitoring using the Python shodan library to query the Shodan API and correlate results against your internal asset inventory. Install with pip install shodan and initialize the API client with api = shodan.Shodan('YOUR_API_KEY'). Query your IP ranges with results = api.search('net:203.0.113.0/24') which returns paginated results with host data including open ports, services, and banner information. For each host in the results, extract the IP, ports, hostnames, and vulns (vulnerability list, requires enterprise subscription) fields and compare against your asset management system. Write a script that runs daily and sends a Slack notification for any IP that appears in Shodan results but not in the internal asset inventory, and for any host where the open port list has changed since the previous Shodan scan. Use the Shodan streaming API for real-time banner updates on your monitored IP ranges: api.stream.banners() yields a continuous stream of new scan data for all Shodan-monitored hosts. Cache Shodan API results to avoid hitting rate limits — the free tier allows 1 query per second and the data from a full CIDR scan is stable for 24-72 hours between Shodan's scan cycles.
How do I prioritize Shodan-discovered vulnerabilities for immediate remediation?
Prioritize Shodan-discovered vulnerabilities by combining the CVE severity with the internet exposure factor — a vulnerability on an internet-facing host is higher priority than the same CVE on an internal server regardless of CVSS score, because external exposure means any attacker can attempt exploitation without needing network access. For critical CVEs visible in Shodan (using the vuln: filter if you have an Enterprise subscription), treat them as P1 incidents regardless of normal vulnerability SLA: an internet-exposed host with Log4Shell (CVE-2021-44228) or ProxyShell (CVE-2021-34473) at CVSS 9.8+ should be patched or taken offline within 24 hours. For Shodan-discovered exposed services that do not have known CVEs but should not be internet-facing (database ports, management interfaces, development servers), prioritize based on service type: database services (3306/MySQL, 5432/PostgreSQL, 27017/MongoDB) exposed to the internet should be blocked within hours regardless of patching status — an open database port is exploitable even without a CVE through authentication bypass or credential stuffing. Track Shodan remediation separately from the internal vulnerability management queue since the internet-exposure factor changes the risk calculus significantly.
How do I find exposed management interfaces and default credentials using Shodan?
Find exposed management interfaces across your IP ranges using Shodan's product and port filters to identify administrative services that should not be internet-facing. Search for common management interface exposures: net:YOUR_CIDR port:22 shows all SSH instances; net:YOUR_CIDR port:3389 shows all RDP-exposed hosts; net:YOUR_CIDR product:Cisco IOS finds exposed network device management interfaces; net:YOUR_CIDR title:'router login' finds web-based router management pages. For default credential detection, Shodan's vuln: filter in Enterprise plans includes Shodan's own default credential checks — some banners also include authentication bypass indicators directly in the banner text (Shodan shows the banner as returned by the service, so a banner containing 'no authentication required' or response data that only appears after successful login indicates a credential bypass). For Kubernetes clusters specifically: net:YOUR_CIDR port:10250 finds exposed kubelet API ports, and net:YOUR_CIDR port:2379 finds exposed etcd ports — both are critical exposures that indicate a misconfigured cluster with potentially unauthenticated access to container orchestration and all cluster secrets.
How do I track SSL certificate expiry and misconfiguration using Shodan?
Use Shodan to audit SSL certificate status across your internet-facing hosts, identifying expired certificates, certificates with mismatched hostnames, and wildcard certificates that are broader than necessary. Search for your domain's TLS certificates: ssl.cert.subject.cn:'*.yourdomain.com' OR ssl:'yourdomain.com' and filter the results for ssl.cert.expired:true to find hosts presenting expired certificates that may indicate a forgotten deployment or certificate management failure. For certificate hostname mismatches: Shodan's banner data includes the SSL certificate fields, and the http.host field shows what domain the host was accessed under — mismatches between ssl.cert.subject.cn and the http.host indicate certificate misconfiguration. Review the full certificate inventory from Shodan against your certificate management system to identify wildcard certificates being used on internet-facing hosts (*.example.com certificates expose all subdomains if compromised rather than only the specific deployment host), and identify self-signed certificates on production hosts that should be using CA-signed certificates. Set up Shodan Monitor alerts for ssl.cert.expired:true matching your IP ranges to get proactive notification before certificate expiry causes service outages.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.