ofensiva
Shodan
OSINT
Censys

What Is Shodan: Internet-Connected Device Search and Defensive Use

What Shodan is, the search engine for Internet-connected devices. Advanced operators, pentesting and threat hunting use cases, plus Censys and ZoomEye.

SecraJune 8, 202614 min read

Shodan is the best known search engine for Internet-connected devices, not for web pages. While Google indexes HTML content, Shodan indexes service banners, TLS certificates, protocol headers and metadata of servers, IP cameras, industrial controllers, routers, exposed databases and anything with a public IP and an open port. John Matherly built it in 2009 and today it is the reference both for defensive teams that want to understand their external attack surface and for offensive teams kicking off an authorised reconnaissance phase.

This guide explains what Shodan is in concrete terms, how it works technically, the advanced operators worth mastering, real defensive and offensive use cases, market alternatives and how it fits into an attack surface management strategy for a serious organisation. The whole guide assumes a legal framework and authorisation: Shodan enables visibility over owned or authorised infrastructure, not a blank cheque to scan whatever you want.

What Shodan is

Shodan is a search engine specialised in services and devices reachable from the Internet. Instead of crawling hyperlinks, it runs a fleet of distributed scanners that continuously connect to common ports across the global IPv4 space and a growing subset of IPv6, capture the banner each service returns and store it in a searchable index. When you query, you do not get web pages, you get IPs, open ports, identified products and known vulnerabilities associated with them.

The practical value comes from flipping the question: instead of "what is on the Internet about this company", you ask "what services and devices of this company are exposed on the Internet". That second question is what separates a mature security programme from one that learns about its own exposures from a press headline after someone exploited them.

Shodan is a dual-use tool. The same results that help a CISO audit shadow IT help an attacker locate poorly protected admin panels. Treat it like any dual-use tool: document scope, keep a query log and restrict its use to authorised personnel.

Shodan does not discover what is not already exposed. If an organisation appears in Shodan with sensitive public services, the problem is not Shodan: the problem is that those services are exposed.

How it works technically

Shodan runs its own scanner infrastructure across several countries, both to avoid local geo-blocking and to obtain more reliable fingerprints. The simplified flow:

  1. Target generation. IP lists derived from the public IPv4 space and from IPv6 ranges announced by BGP. IPv6 coverage is partial because scanning the full IPv6 space is computationally unfeasible; active ranges identified via passive DNS, certificates and observed responses are prioritised.
  2. Connection to predefined ports. Lists that grow over time: HTTP, HTTPS, SSH, FTP, Telnet, SMB, RDP, MQTT, CoAP, Modbus, S7, BACnet, MongoDB, Elasticsearch, Redis, Memcached, VNC, IPMI and many others relevant to IT, IoT and OT.
  3. Banner grabbing. When the port responds, Shodan records exactly the header or initial response the service returns: version, SSH banner, HTTP headers, TLS certificate, page title, error message and derived metadata.
  4. Fingerprinting and enrichment. Internal rules associate the banner with a product, version, operating system and, where applicable, known CVEs. The result is also enriched with geolocation, reverse hostname, ASN and the organisation owning the IP block.
  5. Indexing. The result enters a search index with structured filters and becomes accessible via web, REST API and CLI.

Re-scan frequency varies by port and region: dense ranges are re-scanned within days, marginal regions within weeks. That is why Shodan is not real time, it is a recent snapshot, enough for strategic attack surface management but not for live incident detection.

Advanced Shodan operators

Operators are the real differentiator. Anyone can type "webcam" and get thousands of noisy results; a trained analyst combines operators to narrow down to what is actionable.

The most useful in serious work:

  • port: filters by port. Example: port:3389 to locate exposed RDP.
  • country: filters by ISO country code. Example: country:ES for Spain.
  • city: filters by city. Example: city:"Madrid".
  • org: filters by the IP block's organisation according to WHOIS. Example: org:"My Company Ltd".
  • hostname: filters by host name (PTR or certificate). Example: hostname:"mycompany.com".
  • product: filters by detected product. Example: product:"Apache httpd".
  • version: filters by version. Example: version:"2.4.49" to locate known vulnerable instances.
  • vuln: filters by CVE. Example: vuln:CVE-2021-44228. Requires a paid subscription.
  • ssl.cert.subject.CN: filters by certificate Common Name. Example: ssl.cert.subject.CN:mycompany.com.
  • http.title: filters by HTML title. Example: http.title:"Login".
  • net: filters by CIDR block. Example: net:203.0.113.0/24.
  • asn: filters by ASN. Example: asn:AS65000.
  • has_screenshot:true only results with a web screenshot.
  • tag:ics only devices classified as industrial.

Operators combine with an implicit AND and can be negated with -. For example, to audit your own organisation without noise from known honeypots:

org:"My Company Ltd" country:ES -tag:honeypot

Or to locate TLS servers with your CN exposed on non-standard ports:

ssl.cert.subject.CN:mycompany.com -port:443 -port:8443

The challenge is judgement: a well thought query returns five actionable findings; a sloppy one returns 50,000 results nobody reviews.

Defensive use cases

The canonical case is attack surface management. A mid-size organisation discovers with a day of Shodan work more exposed surface than its CMDB declares: forgotten test servers in a marketing cloud account, admin panels with basic authentication, open NoSQL database instances, managed switches with public web UI, IP cameras in remote offices, corporate printers with open IPP services.

Other recurrent defensive cases:

  • Shadow IT discovery. Departments that procure SaaS or IaaS bypassing IT leave traces in Shodan via TLS certificates with the corporate domain in CN or SAN.
  • M&A due diligence. Before closing an acquisition, mapping the external exposure of the target gives a much more realistic picture than any security questionnaire filled in by the target itself.
  • Third-party monitoring. Watching the exposure of critical suppliers helps anticipate supply chain incidents: an ERP-as-a-service appearing with unpatched vulnerabilities is a direct risk to its customers.
  • Post-incident validation. After a patch or change, verify in Shodan that the service is indeed no longer reachable or that the banner no longer exposes the vulnerable version.
  • Compliance and audit support. Shodan captures accompany audit reports as objective evidence of the external surface at a given point in time.

Offensive use cases

In the pentesting and Red Team phase, Shodan speeds up pre-engagement reconnaissance when there is explicit authorisation from the client:

  • Target identification. Locate every public asset within the agreed scope, including those the client did not declare out of ignorance.
  • Technology and versions. Know what software and which versions each asset exposes before touching anything, reducing the noise of later active scanning.
  • Honeypot detection. Shodan tags many known honeypot installations with tag:honeypot, avoiding hours wasted on systems that are not the real target.
  • Cross-referencing with known vulnerabilities. Combined with a good CVE catalogue it helps prioritise which asset deserves deep analysis first.
  • Support to wider OSINT. Fits with Maltego, theHarvester, Amass and the rest of reconnaissance tooling.

Offensive use without contractual authorisation is illegal and unprofessional. Any serious pentest starts with a statement of work where Shodan appears explicitly within the methodology.

Commercial and open alternatives

Shodan is not the only option. The choice depends on geographic coverage, banner grabbing depth, licensing model and specialisation:

  • Censys. Born at the University of Michigan. Historical strength in TLS certificates and better IPv6 coverage than Shodan in some ranges. Limited academic free tier, commercial platform for enterprise.
  • ZoomEye. Chinese vendor. Good coverage in Asia and on Chinese products that Shodan fingerprints less well. Less polished platform for a European user and jurisdictional considerations when uploading sensitive queries.
  • BinaryEdge. Enterprise focus and raw datasets available for download. Useful when you want to ingest data into your own pipelines.
  • Fofa. Chinese search engine similar to Shodan, with its own syntax and broad Asian coverage.
  • Onyphe. French vendor, strong in passive DNS, geolocation and threat intelligence enrichment.
  • Spyse (discontinued but still referenced in much literature). Relevant datasets where part of the functionality has moved to other platforms.
  • Hunter (do not confuse with Hunter.io for emails). Specific service exposure coverage.
  • GreyNoise. Not a direct competitor: classifies Internet background noise versus targeted traffic. Complements Shodan in the analysis phase to prioritise IoCs.

A realistic stack for corporate attack surface management combines Shodan plus Censys plus Onyphe or GreyNoise: each one covers nuances the others miss in fingerprinting.

Shodan Monitor and alerting

Beyond the search engine, Shodan offers Monitor, a module where you define IPs, CIDR ranges, ASNs or domains under watch. When a new exposed service appears or the banner of an existing one changes, it sends notification via email, webhook or API.

Typical setup for a mid-size organisation:

  1. Load into Monitor every public range assigned by the ISP.
  2. Add cloud blocks assigned by AWS, Azure or GCP to corporate accounts.
  3. Add the own ASN if the organisation has BGP autonomy.
  4. Add hostname and certificate CN patterns covering corporate subdomains.
  5. Configure a webhook that pushes events to a SIEM queue or to a security team Slack channel.
  6. Define playbook: every alert is triaged within 24 hours, categorised (expected, shadow IT, exposure to fix) and closed.

Well implemented, Monitor covers 80% of the external attack surface management use case without needing to buy a dedicated six-figure annual ASM platform.

ICS and OT specifics

Shodan maintains a special industrial control devices category, accessible via tag:ics and specific product operators. It indexes banners of OT protocols such as Modbus TCP, Siemens S7, DNP3, BACnet, EtherNet/IP, Niagara Fox and many others. The consequence is that Siemens PLCs, Schneider Modicon, Allen-Bradley RS Logix, various HMIs and SCADA systems directly exposed to the Internet become globally visible.

For industrial cybersecurity leaders this data changes priority: any OT asset appearing in Shodan is a network segmentation failure, not an acceptable risk. The golden rule remains that OT must not be directly accessible from the Internet, and Shodan becomes the external audit that validates that rule.

Honest limitations

Shodan is not magic and it pays to accept its limitations:

  • Not real time. There is lag between an infrastructure change and its appearance in the index. For ongoing incident detection you have to combine with your own flow logs and EDR.
  • Does not see behind a well configured WAF or CDN. If the real origin is hidden behind Cloudflare, Akamai or similar, Shodan sees the frontend, not the backend. That said, origin leak errors and subdomains not protected by the CDN often reveal the backend.
  • No authenticated visibility. Shodan does not authenticate to services, it only reads what is returned without credentials. Vulnerabilities that require post-auth do not map.
  • Uneven IPv6 coverage. Improves every year, but there are still announced IPv6 ranges that are not deeply swept.
  • Honeypots and dirty data. Many results are academic honeypots or decoy systems that add noise if not filtered with -tag:honeypot.
  • Imperfect fingerprinting. Version inference can fail when the banner is modified or when the service returns non-standard responses.
  • Privacy and ethics. Even though the information is public, there are ethical grey areas (insecure home cameras, personal medical devices). A reasonable internal policy avoids exploiting visually what works for headlines but does not improve client security.

Implementing attack surface management with Shodan

Step by step to bring Shodan into a serious operation:

  1. Define a formal scope. Inventory owned IP ranges, ASNs, domains and subdomains. Include cloud accounts (AWS, Azure, GCP), critical SaaS and any relevant outsourcing. Without this written scope, queries become anecdotal.
  2. Adequate subscription. The free account is for testing; professional use requires Small Business or higher to access vuln:, Monitor with alerts and extended API.
  3. Query catalogue. Build and version an internal repository of useful queries by sector and finding type: exposed admin panels, open databases, obsolete services, expiring certificates.
  4. SIEM/SOAR integration. Monitor events arrive at the SIEM queue like any other feed, with an associated playbook. Webhook integration is native.
  5. Frequency and cadence. Weekly review of Monitor findings; monthly full audit with catalogue queries; quarterly audit with the Red Team to validate trends.
  6. Internal metrics. Number of exposures detected per quarter, mean time to closure, percentage of services found that were not in the CMDB. These are the metrics that go to the security committee.
  7. Closure discipline. Each finding is closed by removing exposure, restricting IP, moving behind WAF or formally accepting the risk. Without closure discipline, ASM turns into a graveyard of tickets.

It fits naturally into external infrastructure pentesting programmes: continuous ASM identifies assets, periodic pentest validates and goes deeper.

Frequently asked questions

Yes. Querying Shodan about your own infrastructure or about infrastructure for which contractual authorisation exists is legal. What does infringe the law is using Shodan as a step prior to unauthorised access to third-party systems: the issue is not the tool, it is the subsequent use. For investigations touching personal data, the general framework of GDPR also applies.

Does the free tier cover my company's exposure?

For an SMB with few ranges and domains, the free tier allows enough basic queries for a one-off audit. For a mid-size or large company with cloud assets, several domains and a need for continuous alerting, a paid plan is necessary to access Monitor with alerts, vuln: searches and the API volume required.

Is CVE search real time?

No. When a new CVE appears, Shodan takes hours to days to reflect the association between version and CVE in the index. For inventory of your own vulnerable assets it is reliable; for identifying global exposure to a freshly published zero-day there is always lag.

Shodan or Censys, which is better?

It is not either or. They are complementary. Shodan tends to have broader coverage of non-HTTP protocol banners and IoT/OT; Censys excels in TLS certificates and in some IPv6 ranges. A serious programme subscribes to both and compares findings.

How do I send Shodan alerts to my SIEM?

Via Monitor: define the assets under watch, configure a webhook pointing to the SIEM ingestion endpoint or to middleware (Logstash, Fluentd, Cribl). The payload arrives as JSON with standard fields (IP, port, module, product, vulns), directly parseable.

Is Shodan enough as the only ASM tool?

For an SMB, yes, it covers the essential case. For a large organisation, no: you need to combine Shodan with Censys, your own authorised active scanning, continuous subdomain discovery, certificate monitoring (CT logs) and, if the context demands, a dedicated commercial ASM platform. The key is not to confuse coverage with false reassurance.

Attack surface management with Secra

At Secra we integrate Shodan, Censys and active discovery into every external pentest project and into continuous attack surface management programmes. We define formal scope with the client (IP ranges, ASNs, domains, cloud accounts), configure Monitor with alerts towards SIEM, maintain our own query catalogue by sector and deliver reports with actionable, prioritised findings, not lists of IPs without context. If you need to audit the real external exposure of your organisation or want to set up an ASM programme with judgement and closure discipline, write to us via contact or check our pentesting service.

About the author

Secra Solutions team

Ethical hackers with OSCP, OSEP, OSWE, CRTO, CRTL and CARTE certifications, 7+ years of experience in offensive cybersecurity, and authors of CVE-2025-40652 and CVE-2023-3512.

Share article