TL;DR: What Shodan and Censys Do for Attack Surface Recon

They index the internet-exposed attack surface so you can find your organisation’s exposed hosts, services, and certificates before attackers do. Both platforms run continuous internet-wide scans, fingerprint every reachable service, and let you query the results with search-engine syntax. Treat them as passive mirrors of what the internet already sees when it looks at you.

Ethics and Legal Guardrails Before You Scan Anything

Passive OSINT and active scanning are different activities with different legal exposure. Querying Shodan, Censys, or crt.sh means searching data their own scanners already collected—it is functionally equivalent to reading a search engine. Launching your own port scan, vulnerability probe, or login attempt against a system you don’t own is a different matter entirely.

In plain English:

• CFAA (US): The Computer Fraud and Abuse Act criminalises unauthorised access to “protected computers.” Port scanning sits in a grey zone that has fared inconsistently in court; attempting authentication or exploiting a vulnerability almost certainly crosses the line.
• GDPR (EU): Grabbing screenshots or banners that contain personal data—usernames in banners, certificates naming individuals—can constitute processing personal data without a lawful basis. Minimise what you collect.
• Authorisation: For anything active, get written permission. Bug bounty scope documents, penetration testing statements of work, or a signed Rules of Engagement are your licence. Scope means scope: a wildcard bug bounty that excludes third-party hosts does not license you to touch your target’s CDN neighbours.
• Responsible disclosure: If you find someone else’s exposure, report it—don’t log in, don’t download, don’t screenshot sensitive data beyond what’s needed to demonstrate the issue.

CISA’s Cyber Essentials toolkit starts with exactly this: know your own external footprint. Attack surface reconnaissance is the blue-team version of that first step.

Lab Setup: Accounts, API Keys, and Your Target Choice

You’ll need three free accounts and one legitimate target.

1. Create accounts at shodan.io and search.censys.io. Free tiers include API access with rate limits; academic researchers can apply for upgraded Censys access.
2. Install the CLIs:

pip install shodan
pip install censys

shodan init YOUR_SHODAN_API_KEY
censys config  # paste API ID and secret

3. Pick a target you own or an authorised scope. Good lab targets: your own public-facing VPS, a domain your organisation owns, or a HackerOne/Bugcrowd programme with an explicit wildcard scope. example.com and scanme.nmap.org are useful for testing queries against assets you don’t control, without control of the results.

Never point active follow-up scans at anything outside documented scope.

Mapping Your Target with crt.sh Certificate Transparency

Certificate Transparency logs (mandated by browser policy since 2018) record every TLS certificate issued for public domains. crt.sh indexes them—meaning every certificate your CA ever issued for a subdomain you forgot about is publicly searchable. Attackers use this for exactly that reason.

Pull all certificates for a domain and extract unique subdomain names with jq:

curl -s "https://crt.sh/?q=%25.example.com&output=json" 
  | jq -r '.[].name_value' 
  | sed 's/*.//g' 
  | sort -u > crtsh_subs.txt

You’ll typically get dozens to thousands of names, including dev-internal.example.com and old-vpn.example.com that nobody’s inventory lists. crt.sh is frequently slow or rate-limited; the crt.sh community mirrors and tools like subfinder pull from the same logs. This is purely passive—you’re reading public log data, not touching the target.

Shodan Queries: Finding Exposed Hosts, Ports, and Services

Shodan indexes banners: what a service says about itself when a scanner connects. The web UI supports the same syntax as the CLI. Useful filters:

• org:"Your Company Name" — hosts registered to your ASN/org string
• net:203.0.113.0/24 — a specific CIDR range
• ssl.cert.subject.CN:example.com — certs naming your domain
• http.title:"Dashboard" org:”Your Company” — titled web apps
• hostname:.example.com — reverse-DNS matches

# Everything Shodan knows about your CIDR
shodan download results.json net:203.0.113.0/24
shodan parse --fields ip_str,port,product,version results.json > inventory.csv

# Quick summary of open services on a single host
shodan host 203.0.113.50

Sample parsed output looks like:

203.0.113.50,443,nginx,1.18.0
203.0.113.50,3389,Microsoft Terminal Services,
203.0.113.61,22,OpenSSH,7.4
203.0.113.72,8080,Tomcat,8.5.5

Even on a well-run network, expect surprises: an RDP port exposed to the internet, an OpenSSH 7.4 build (pre-dates multiple CVEs including CVE-2023-38408 territory), a Tomcat 8.5 instance past end-of-life. Shodan’s query fundamentals are documented at shodan.io/search/filters.

Censys Search: Host and Certificate Intelligence

Censys Search 2.0 takes a structured, record-based approach: every host is a document with typed fields queried in a syntax close to Elasticsearch/Kibana.

# Web UI / API query examples
host.services.port:3389 and host.ip:203.0.113.0/24
web.hostname:*.example.com
cert.subject.organization:"Your Company Name"

Via the Python client:

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

Censys tends to fingerprint services more aggressively (protocol detection rather than banner-only) and its certificate search is stronger for mapping issuance across CAs. Coverage differs from Shodan’s—hosts one engine misses, the other frequently has. Run both; treat disagreement as signal.

Correlating Findings: Building an External Asset Inventory

Merge your three datasets into one deduplicated host list:

cat crtsh_subs.txt shodan_hostnames.txt censys_hostnames.txt 
  | sort -u > all_assets.txt

dig +short $(cat all_assets.txt) | sort -u > resolved_ips.txt

Then look for the classics:

• Stale DNS: crt.sh subdomains that no longer resolve, or resolve to IPs you decommissioned years ago—dangling records an attacker can hijack (subdomain takeover).
• Orphaned certificates: certs in CT logs for hosts no one remembers. Certificates are inventory that outlives the asset.
• Forgotten services: Shodan/Censys hits on ports you thought were closed, on networks you thought were gone.

The OWASP Amass project (owasp.org/www-project-amass) automates much of this correlation if you want a framework instead of shell scripts.

Spotting Common Exposure Patterns

Across real-world recon exercises, the same findings repeat:

• Exposed RDP/SSH on non-standard ports as a “security” measure—cisa.gov’s advisories consistently flag internet-facing RDP as ransomware’s initial access vector of choice.
• Default credential banners: Tomcat manager pages, Jenkins with “Authentication: OFF”, printers showing their admin panel to the world.
• Outdated TLS: SSLv3, TLS 1.0/1.1, or expired certs served on production hosts—visible in the ssl fields of both engines.
• Misconfigured buckets: public S3/GCS buckets referenced from indexed pages or HTML comments in banner grabs.
• Dev and staging environments: your worst code, minimal logging, and no WAF—live on a subdomain from 2019.

Risk Triage and Reporting: From Finding to Fix

Triage by exploitability, not by scanner noise. A internet-exposed Jenkins with no authentication is a critical, not a “medium—informational.” Map findings to CVSS v3.1/v4.0 for severity vocabulary, but adjust for exposure context: a CVSS 9.8 vulnerability on an internal-only host matters differently than a CVSS 7.5 on your edge.

A good finding report contains: asset, evidence (banner/screenshot), why it matters, remediation step, and owner. “Close the port” beats “consider reviewing exposure.”

For continuous monitoring, Shodan Monitor (monitor.shodan.io) alerts on new services in your IP ranges, and Censys ASM does equivalent continuous attack-surface tracking with change detection. Both turn your one-off recon into an ongoing control—exactly what “know your attack surface” requires in practice.

Shodan vs Censys: When to Use Which Tool

The practical answer: use both, plus crt.sh. They see different slices of the internet, and your blind spots live in the difference.

Responsible Disclosure: What to Do When You Find Someone Else’s Exposure

You will find exposures that belong to other organisations—neighbouring CIDR space, third-party vendors on shared infrastructure. The playbook:

1. Do not interact further. No logins, no exploitation, no downloading data, no screenshots of customer records. Your evidence is the indexed metadata itself.
2. Find a reporting channel: a security.txt file (RFC 9116), a VDP on HackerOne/Bugcrowd/Intigriti, or a contact listed in WHOIS/abuse records.
3. Report minimally: the exposed asset, the query that found it, the risk, and nothing extracted.
4. Never publicise before remediation. Dropping an unauthenticated database on Twitter is not disclosure—it’s doxxing the victims to ransomware crews.

For your own organisation, the findings loop back into patch and decommission processes—recon only matters if the inventory it produces drives fixes.

Frequently Asked Questions

Is using Shodan and Censys legal?

Yes, for passive searches of their indexed public data. Querying banners and certificates their scanners collected is like using a search engine. Actively scanning or exploiting hosts without authorisation is a separate—and legally dangerous—activity.

Do Shodan and Censys scan my network themselves?

They run internet-wide scanners and index service banners, in line with their published scan policies. You can request exclusion via their support processes, but indexing is not hacking—assume anything internet-facing is already in one of these indexes.

What’s the difference between Shodan and Censys?

Different scan coverage, fingerprinting engines, query syntax, and pricing. Shodan leans banner-based with a long archive; Censys uses structured protocol fingerprinting and strong certificate records. Using both gives materially broader asset visibility.

Can I use these tools for bug bounty reconnaissance?

Yes, for in-scope assets only. Stay within the programme’s rules of engagement, respect exclusions (many programmes exclude third-party and CDN-hosted assets), and disclose findings responsibly through the programme channel.

How do I remove my organisation’s assets from Shodan results?

Secure or take down the exposed service—the listing disappears once the service is gone. For removal requests, contact Shodan support; for ongoing visibility into what’s indexed, use Shodan Monitor or Censys ASM.