Internet Scanning Data: Censys, GreyNoise and Shodan

Attackers already look up your exposed services in internet scanning datasets, so defenders who do not use the same data are the last to know what they expose. Internet scanning services continuously probe public IP space and index what answers, while sensor networks record who is scanning everyone. Used well, this data finds forgotten remote desktop gateways and expired certificates before attackers do, and cuts alert volume by separating background internet noise from traffic aimed at you. This guide explains what each of three widely used datasets sees, how to query them for your own assets, how to enrich SOC alerts, and how to use them lawfully. Platforms are listed alphabetically (Censys, GreyNoise, Shodan); order is never a ranking. The discipline of attack surface management is covered in the Attack Surface Management Guide; this page is about using the data sources.

This is an independent guide from NHI Mgmt Group, based on the public documentation of Censys, GreyNoise and Shodan as of November 2026. It is not sponsored or reviewed by any of these companies. Product features change, so confirm settings against each vendor's current documentation.

Key takeaways

Two kinds of data, two jobs. Service scan data (what is exposed on an IP) answers "what do we expose"; scanner sensor data (who is probing the internet) answers "is this alert aimed at us or just background noise".
Start with your own address space. Load your registered IP ranges, cloud egress addresses and domains, and set up continuous monitoring and alerts on change.
Enrich, do not auto-block. Use scanner classifications and business service context to prioritise alerts; treat them as context, not as allow lists or access controls.
Passive lookup is not scanning. Querying an index does not touch the target; requesting an on-demand scan does, and should only be pointed at assets you own or are authorised to test.
Close the loop. Every exposure found needs an owner, a ticket and a re-check, or the data only produces reports.

What the tool does

All three services gather data from the public internet, but they look at it from different directions. Censys and Shodan connect out to public IP addresses and record the services that respond. GreyNoise runs listening sensors and records the hosts that connect in to them, which means it sees scanners and opportunistic attackers rather than exposed services.

Platform	How data is collected (from vendor docs)	Main data objects	Query language
Censys	Sends small connection attempts to every IPv4 address and completes a protocol handshake (for example an HTTP request) where a service accepts the connection; states it never bypasses authentication	Hosts, web properties, certificates	Censys Query Language (CenQL)
GreyNoise	Collects and analyses internet wide scan and attack traffic arriving at its sensors; a separate dataset identifies IPs of common business services	IPs with classification, tags, first and last seen; Business Services (formerly RIOT)	GreyNoise Query Language (GNQL)
Shodan	Collects information from services on internet connected devices and stores each as a banner	Banners per IP and port (data, ip_str, port, org, location)	Shodan search filters (filtername:value)

Censys

Censys search runs on the Censys Platform across host, web property and certificate records. CenQL supports full text queries and field value queries of the form field operator value. Operators include : for case insensitive tokenised match, = for exact match, =~ for regular expressions, range comparisons and :* for any non-empty value. Wrapping conditions in host.services: ( ... ) requires them to match the same service, which avoids false matches where port and protocol come from different services. The docs also describe a twist() function for lookalike domain discovery. Censys publishes its scanner subnets and ASNs (AS398722, AS398705, AS398324) and its HTTP user agent, which lets defenders recognise its traffic in their own logs.

GreyNoise

GreyNoise assigns each scanning IP one of four classifications. Benign means the actor is a known legitimate organisation such as a search engine or research group that offers an opt out; malicious means GreyNoise has directly observed harmful behaviour and applied at least one malicious tag; suspicious covers systematic probing between the two, which GreyNoise describes as contextual intelligence rather than an immediate call to action; unknown covers scanning that meets none of the other criteria. Business Services Intelligence identifies IPs of CDNs, update servers, public DNS and NTP services, SaaS APIs and cloud security products. GreyNoise states that it is not an allow list and must not be used as an access control list. GNQL supports field filters such as classification:malicious, tags, CIDR blocks, time filters such as last_seen:1d, and a spoofable field for excluding traffic that may be spoofed.

Shodan

Shodan stores each service response as a banner. Only the banner's data property is searched by default, so searching an organisation name alone may return nothing; filters written as filtername:value with no space (for example org:"Example Ltd" or country:GB) search other properties and reduce false positives. The REST API offers host lookup (/shodan/host/{ip}), search, a count endpoint that does not consume query credits, network alerts with triggers and notifiers, and on demand scanning on paid plans. InternetDB is a free, keyless lookup for non-commercial use that returns open ports, CPEs, hostnames, tags and known vulnerability identifiers per IP, updated weekly.

Defender use cases

Use case	Question answered	Data type	Typical output
External exposure inventory	What services on our IPs and domains answer from the internet?	Service scan data	List of IP, port, service, software, certificate
Exposure change alerting	Did something new appear on our ranges this week?	Service scan data with monitoring	Alert to SOC or ticket queue
Remote access exposure	Are RDP, SSH, VPN portals or admin panels reachable?	Service scan data	Priority remediation list
Certificate and domain hygiene	Which hosts present certificates with our names, and which lookalike domains exist?	Certificate and web property data	Expiring or unknown certificates, lookalike domains
Alert enrichment	Is this source IP a mass scanner, a known business service or something targeted?	Scanner sensor data	Classification and tags added to the alert
Emerging exploitation awareness	Has mass scanning started for a newly disclosed weakness in a product we run?	Scanner sensor data with tags	Patch priority input
Third-party exposure review	What does a supplier visibly expose?	Service scan data, passive only	Evidence for a supplier conversation

Exposure inventory: Query by your network ranges and by your certificate names rather than by organisation name, which depends on registry data and misses cloud addresses. In Censys, certificate full text search covers names, issuer and subject; in Shodan, filters on network and organisation narrow results; for both, the vendor docs list the full filter sets.
Remote access first: Prioritise remote access services because they map to T1133 External Remote Services and are a frequent initial access route. See the Secure Remote Access Beyond VPN Guide.
Alert enrichment: GreyNoise documents SIEM, SOAR and threat intelligence platform integrations; Shodan documents integrations including Microsoft Sentinel and Graylog; Censys documents CenQL host, web property and certificate queries in the Censys Platform that can be rerun as part of triage. Add the context to firewall, VPN and web application alerts before triage. See the Alert Triage Guide.
Know what attackers see: Adversaries search the same kind of index before targeting, which ATT&CK records as T1596.005 Search Open Technical Databases: Scan Databases. Running the same searches on your own estate removes that advantage.

Deployment and safe use

Define scope: Build the list of IP ranges, cloud egress and load balancer addresses, domains and certificate names you own. Get sign off from the network and cloud teams; an incomplete scope is the most common reason exposures are missed.
Start passive: Run read only searches against your scope in each platform's web interface. Record the queries so results are repeatable.
Automate: Use each platform's API with a dedicated service account and API key held in a secrets manager, not in scripts or notebooks. Rotate keys when staff leave and limit who can read them. See the Secrets Management Guide.
Monitor: Set up change alerts on your ranges (for example Shodan network alerts with triggers and notifiers, or the same CenQL and GNQL queries rerun on a schedule in Censys and GreyNoise) and route them to a queue with owners.
Enrich: Add scanner classification and business service lookups to SIEM or SOAR playbooks, with caching to stay within API quotas.
Review: Check monthly that scope still matches reality and that every alert produced a decision.

Legal and authorised use: Searching an index is passive: the target is not contacted by you. On demand scanning (Shodan documents it as a paid feature using scan credits) causes new connections to the target, so point it only at addresses you own or have written authorisation to test, and follow your organisation's testing policy. Do not use results about third parties for anything beyond defensive conversations with them. Check each platform's terms of service and licence, which distinguish commercial and non-commercial use; Shodan, for example, states InternetDB is free for non-commercial use only.
Data handling: Exposure exports describe your weaknesses. Store them with the same protection as vulnerability scan reports and limit sharing.
Your own visibility to scanners: Censys publishes scanner ranges and an opt out process; blocking those ranges stops future indexing but does not remove historical data, and Censys states services usually drop from search 24 to 48 hours after last observation. Hiding from one index does not hide you from attackers who scan themselves, so fix the exposure rather than relying on opt out.

Detection and hardening value

The data matters only when it changes what the SOC and infrastructure teams do. Use it in three places.

Triage noise reduction: Inbound connection attempts from IPs GreyNoise classifies as benign or tags as common scanners are usually lower priority at the perimeter, while successful authentication or data transfer involving any of them still needs full investigation. GreyNoise advises applying its observed scanner data first and treating business service data as supplementary context.
Targeted activity signal: A source that hits your systems but is not seen scanning the wider internet is more interesting, because it suggests interest in you specifically. Raise its priority.
Hardening feedback: Each newly exposed service found by Censys or Shodan monitoring should create a change review: was it approved, is it patched, does it need to be public?

Metric	What it shows	Target
Share of owned IP ranges and domains under continuous monitoring	Scope completeness	100%
Median time from new exposure alert to owner decision	Response speed	Under 2 business days
Internet facing remote access services without phishing-resistant MFA	Highest risk exposure	Zero
Perimeter alerts auto-enriched with scanner context	SOC efficiency	Above 90%
Unknown hosts presenting certificates with your names	Shadow IT and impersonation	Falling month on month

Activity	NIST CSF 2.0	NIST SP 800-53 Rev. 5
External exposure inventory	ID.AM-01, ID.AM-03	CM-8
Exposure and vulnerability identification	ID.RA-01	RA-5
Alert enrichment and correlation	DE.AE-02, DE.AE-03	SI-4
Threat awareness from scanning trends	ID.RA-01	PM-16

CISA's primary mitigations for operational technology start with removing internet exposure and identifying public facing assets, which is exactly what this data supports. See the Exposure Management and CTEM Guide.

Alternatives

Commercial scan indexes are one input among several. Mature teams combine them with sources they control.

Your own authorised external scans: Scheduled scans of your own ranges from outside the network give results on your timetable and cover ports an index may not. See the Vulnerability Scanning Guide.
Certificate transparency monitoring: Watching CT logs for certificates issued for your domains finds new hostnames as soon as they get a certificate. See the Certificate Transparency Monitoring Guide for Web Teams.
Cloud provider inventory: Public IP and load balancer listings from your cloud accounts are the authoritative scope list to feed every other tool.
Your own sensors: Honeypots on unused addresses show who probes your space specifically. See the Honeypot deployment guide.
Attack surface management platforms: These combine discovery, attribution and workflow. See the Attack Surface Management Buyer's Guide.

Practitioner checklist

Build and maintain an owned scope list of IP ranges, cloud addresses, domains and certificate names, reviewed monthly.
Run saved searches in Censys, GreyNoise and Shodan against that scope and record the queries.
Enable change alerting on owned ranges and route alerts to a ticket queue with named owners.
Prioritise exposed remote access and administration interfaces for removal or MFA protected access.
Add scanner classification and business service context to SIEM or SOAR perimeter alerts, as context only.
Store API keys in a secrets manager with named owners and rotation.
Use on demand scanning only against assets you own or are authorised to test, and check licence terms for commercial use.
Track time from exposure alert to decision and report it with the other vulnerability metrics.

Internet Scanning Data for Defenders: Use Censys, GreyNoise and Shodan Safely