Shodan and Censys for Defenders: Find and Fix Your Exposed Assets Before Attackers Do

TL;DR: Attackers Are Already Searching for You — Search First

Use Shodan, Censys, and ZoomEye as attack-surface recon tools against your own IP ranges, then automate continuous monitoring so you learn about new exposures before an attacker’s script does. Attack-surface recon is not a one-time project—it’s a query you run every day.

Traditional asset inventory assumes you know what’s on your network. But every organization with a cloud account, a forgotten test server, or a vendor appliance has assets that answered the internet’s call without anyone in IT knowing. The entire discipline of external attack surface management (EASM) exists because of one uncomfortable truth: attackers run internet-wide scans continuously, and most breaches start with an asset nobody remembered owning. CISA’s Known Exploited Vulnerabilities catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) is dominated by internet-facing services—VPN gateways, file-transfer servers, management consoles—precisely because that’s what scanners find first. This guide flips the recon: you’ll query the same search engines attackers use, fingerprint what’s dangerous, and build a pipeline that alerts you the moment something new goes live.

How Shodan, Censys, and ZoomEye Actually Work

Three engines, one core mechanic: internet-wide scanning with banner grabbing and certificate analysis, indexed into searchable datasets.

• Shodan sweeps the IPv4 space on common ports, connects to services, captures the protocol banners they emit, and indexes them alongside geolocation, ASN, and certificate data. The famous IoT angle—default cameras, open databases—comes straight from those banners.
• Censys (https://search.censys.io) began as a University of Michigan research project scanning with ZMap and ZGrab. It builds a per-host view that synthesizes services, autonomous system data, and TLS certificates, refreshed on its own scan cadence.
• ZoomEye (https://www.zoomeye.hk) applies the same model with distinct Xmap/Wmap fingerprinting and component-tagging, which is why it frequently surfaces results the other two miss.

The key operational consequence: these are indexes, not live views. A host’s record reflects the last successful scan, which may be hours or weeks old. Everything downstream—verification of fixes, alerting logic—must account for that lag.

Setting Up Your Accounts, API Keys, and CLI Tooling

Install the CLIs from an isolated admin workstation or container:

pip install shodan censys zoomeye

• Shodan: Grab your API key from your account page, then shodan init YOUR_API_KEY. Free accounts get limited search filters; the org: filter and higher API quotas require a paid tier (Small Business or above, roughly $59+/month).
• Censys: Create an account at search.censys.io and generate an API ID and secret under Account → API. Free tier allows a limited number of query results per month—enough for learning and small ranges, not for enterprise sweeps.
• ZoomEye: Register at zoomeye.hk, then zoomeye init -apikey YOUR_TOKEN. Free tier gives daily query credits.

Store keys in environment variables or a secrets manager, never in the scripts you’ll commit to your monitoring repo.

Finding Your Own Exposed Assets in Shodan

Start with organizational and network filters:

shodan search "org:'Your Company Name'"
shodan search "net:203.0.113.0/24"
shodan search "ssl.cert.subject.CN:yourcompany.com"

The certificate pivot is the one defenders underuse. Attackers buy your expired certificates, typo-squatted domains, and old SANs from certificate transparency logs and pivot into infrastructure you forgot. Search for every CN and SAN your org has ever issued, then check which IPs currently present them.

For detail on a specific host:

shodan host 203.0.113.50

Example output pattern:

203.0.113.50
Hostnames: mail.yourcompany.com
Organization: Your Company ASN
Ports: 25, 443, 3389, 5900
3389: Microsoft Terminal Services — RDP protocol 10.6
5900: VNC — "RFB 003.008" banner, no authentication required

That last line is the entire reason you run this exercise.

Hunting Exposures in Censys

Censys Search uses a structured query language against parsed service data. Useful queries for your ranges:

autonomous_system.description:"Your Company"
services.service_name:"RDP" and autonomous_system.asn:64512
services.tls.certificates.leaf_data.subject.common_name:"yourcompany.com"
net:203.0.113.0/24 and services.port:5432

Export via the Python SDK for programmatic processing:

from censys.search import CensysHosts
h = CensysHosts()
results = h.search('net:203.0.113.0/24 and services.port:3389', per_page=100)
for page in results:
  for host in page:
    print(host['ip'], [s['port'] for s in host.get('services', [])])

Censys’s certificate-centric view catches hosts Shodan indexes differently, and its virtual host detection (covering TLS SNI–routed services) surfaces assets behind shared frontends—another coverage gap the other engines close only partially.

Cross-Checking with ZoomEye and Correlating Results

Run the same ranges through ZoomEye:

zoomeye search "ip:"203.0.113.0/24""
zoomeye search "ssl:"yourcompany.com""

Then merge: normalize every result to a tuple of (IP, port, protocol, banner-version), dedupe across engines, and diff against your CMDB or cloud inventory. Anything in the engines but absent from your inventory is, by definition, an unknown asset—and unknown assets are where incidents live. Expect 5–15% coverage variance between engines on any given range; that variance is exactly why the “which is better” question has only one correct answer: use all three.

Fingerprinting Exposed Services: What’s Dangerous vs. Normal

Not every exposure is a fire. Triage by fingerprint:

• Critical: Exposed databases (PostgreSQL 5432, MySQL 3306, MongoDB 27017, Redis 6379 without auth), RDP/VNC/SMB to the internet, ICS/SCADA protocols (Modbus 502, EtherNet/IP 44818, DNP3 20000), and anything answering with a default credential banner. CISA has repeatedly warned about exposed ICS — its advisories at https://www.cisa.gov/news-events/cybersecurity-advisories cover exactly these fingerprints.
• High: Outdated service versions with known exploited CVEs — e.g., an Ivanti or Fortinet VPN banner predating patched builds, or an Apache Struts version in the vulnerable range. Match the banner against CISA’s KEV list.
• Context-dependent: HTTPS web apps, mail servers, CDNs. Normal to be exposed; abnormal to leak version banners, directory listings, or admin paths like /jenkins or /phpmyadmin.
• Immediate red flags: Banners containing default credentials in vendor strings, unauthenticated VNC/RFB responses, S3-compatible buckets with readable listings, exposed Kubernetes API servers returning version data unauthenticated.

Default-banner services deserve zero tolerance. A device answering RFB 003.008 on 5900 with no auth prompt is a live feed of your network’s console to anyone with a query.

Fixing What You Find: Remediation Playbook

1. Triage by severity. Critical fingerprints (open databases, ICS, unauth VNC) get same-day action. Known-exploited versions get scheduled within your SLA window. Informational banner leaks go into the backlog.
2. Decide: takedown vs. hardening. Forgotten assets get decommissioned—period. Assets that must stay online get firewalled to known IPs, VPN-fronted, or moved behind your WAF/Zero Trust access broker.
3. Verify removal by rescan. Request a fresh Shodan scan of the specific IP (shodan scan submit IP), then re-query after 24–48 hours and confirm the port no longer returns. Censys offers on-demand scans on paid plans. Do not trust a firewall change ticket alone—trust the index.
4. Hijacked or stale space: If you find your certificates or org name on IPs outside your ranges, you may be dealing with delegated space you never reclaimed. Contact the ASN’s abuse contact with evidence and reclaim or formally relinquish the space.

Building a Continuous Exposure-Monitoring Pipeline

Point-in-time searches go stale within days. The durable answer is a scheduled pipeline:

1. Maintain a known-good inventory — CIDR list plus expected service/port pairs, versioned in Git.
2. Schedule API queries — a cron job or CI pipeline (GitHub Actions nightly works fine) runs the same Shodan/Censys/ZoomEye queries from this guide.
3. Diff against inventory. New IP, new port, or changed banner on a known host = finding.
4. Alert to Slack, PagerDuty, or your SIEM via webhook so the finding lands where humans actually look.

This is the same monitoring mindset behind modern exposure management programs—CISA’s free Attack Surface Attack Surface Reduction guidance (https://www.cisa.gov/resources-tools/resources) and OWASP’s guidance on asset management both converge on the same principle: you cannot defend an asset you cannot see, and seeing once is not seeing.

Sample Pipeline: Python + Shodan Stream + Alerts

Minimal working script — new banners on your CIDRs trigger a Slack alert:

import os, json, shodan, requests

json.dump(list(known), open("known_assets.json", "w"))

Run it nightly via cron or GitHub Actions. The shodan stream API (paid) pushes banners in real time as Shodan collects them — swap the polling loop for api.stream(CIDRS) for sub-minute alerting. Extend the same pattern with Censys SDK calls to close the coverage gap. For deeper alert correlation, pipe findings into your SIEM alongside the detection content from our monitoring guides.

Defender Pitfalls and OpSec When Searching for Yourself

• Attribution leaks. Your queries on Shodan/Censys are tied to accounts. A dedicated research account (not your corporate SSO email) for exposure hunting keeps your monitoring program from revealing your org’s security posture and infrastructure interests to anyone watching—attackers use these platforms too, and some monitor interesting queries.
• Legal note. Querying indexed data is simply reading a public database — no legal exposure. Active verification scans (nmap, banner grabs) against your own ranges are legal with internal authorization; get written sign-off from whoever owns the address space before you touch anything, including cloud IPs and delegated ranges.
• Index lag cuts both ways. Shodan and Censys rescans depend on port popularity and history — expect hours to weeks. A fix isn’t confirmed until a fresh scan returns clean; actively request rescans rather than waiting.
• False confidence from deduplication. Overlapping CIDRs, shared frontends, and virtual hosts mean your merged view can silently drop hosts. Keep per-engine raw exports in your audit trail.

Frequently Asked Questions

Is it legal to scan Shodan and Censys for my own IP ranges?

Yes. Querying indexed data is reading a public search engine. Actively scanning your own assets is legal with proper internal authorization — get written sign-off from whoever owns the address space first.

Which is better for defenders, Shodan or Censys?

Neither — they have different scan infrastructures, indexing models, and parsing. Each reliably surfaces hosts the others miss. Use both, plus ZoomEye, for complete coverage of your ranges.

How often do Shodan and Censys rescan hosts?

It depends on port popularity and host history — popular services on common ports may refresh within hours; obscure ports can lag weeks. Verify fixes by requesting an on-demand rescan, not by waiting for the index to update.

Do I need a paid plan to do this?

Free tiers suffice for learning and small ranges. Enterprise-grade filters like org:, high API query volumes, on-demand scans, and the Shodan Stream API all require paid plans.

Can attackers use Shodan to find my infrastructure?

Yes — that’s the entire point. Attackers run these queries continuously against your organization and certificates. That’s precisely why defenders should search first and fix exposures proactively.