Attackers do not need to scan your network to find your exposed services, because Shodan, Censys, FOFA and similar engines have already done it and will sell or show them the results. These internet exposure search engines continuously connect to public IP addresses, record what answers, and index banners, certificates and web content so anyone can query them. Defenders can use the same data to see their organisation from the outside, catch new exposures within hours and confirm fixes. This guide explains how the engines collect data, the query patterns for finding your own assets, alerting, false positives, removal and the legal and ethical limits. Engines are listed alphabetically; the order is not a ranking. For the wider programme and tooling market, see the Attack Surface Management Guide.
Key takeaways
- Your exposure is already indexed. MITRE ATT&CK lists searching scan databases as reconnaissance technique T1596.005, because these services publish IPs, hostnames, open ports, certificates and banners that adversaries use for targeting.
- Query by what you own, not by what you fear. Netblocks, organisation names, certificate names and domains find your assets; product and vulnerability terms then narrow them.
- Alerts beat ad hoc searches. Monitoring features such as Shodan Monitor's new_service, open_database and ssl_expired triggers turn a one-off audit into a control.
- Every result needs validation. Index data can be days old, attribute shared or cloud IPs to you wrongly, or miss services behind SNI and CDNs.
- Removal is not remediation. Blocking scanners stops future indexing but not historical data, and attackers run their own scans: close the service instead.
What the tool does
An internet exposure search engine has three parts: scanners that probe address space, parsers that extract structured data from each response, and a search index with a query language and API.
- Collection: Censys documents that it makes small connection attempts to every IPv4 address and, when a server accepts, completes a protocol handshake such as an HTTP request to learn about the service. Shodan stores a "banner" for each service it finds, with properties such as
data(the service's response),ip_str,port,organdlocation.country_code; an HTTP banner shows server software and version, while an industrial protocol banner can show firmware and serial numbers. - Enrichment: engines add geolocation, ASN and organisation, TLS certificate details, product fingerprints, screenshots and vulnerability labels, then expose them as searchable fields.
- Access: web search, APIs, bulk downloads and alerting. Shodan's official Python library supports search, bulk IP lookups, a streaming firehose and network alerts; FOFA offers an API with selectable result fields.
| Engine | Data model | Query style (from vendor docs) | Defender features |
|---|---|---|---|
| Censys | Hosts with nested services, web properties and certificates | CenQL: field: value (tokenised), = exact, =~ regex, ranges, and/or/not, nested host.services: (port = "22" and protocol = "SSH") | Certificate search, scan-time filters ("now-1d"), look-alike function twist(), published scanner ranges and opt-out process |
| FOFA | Network assets with web titles, bodies, headers, certificates and favicons | field="value" joined with && and ||, e.g. title=, body=, header=, cert.is_valid=true, icon_hash | Icon (favicon) search, batch search, API with field selection, built-in product rules |
| Shodan | One banner per service per IP, with history | filter:value with no space after the colon, quotes for values with spaces, filters combined, e.g. org:"Example Ltd" city:London | Shodan Monitor network alerts with triggers, on-demand scans of your own IPs, host history |
FOFA is a commercial service whose Python SDK is published under the copyright of Fofa, Inc. Before sending queries that name your organisation to any engine, consider that the query itself is information you are sharing with the provider, and check where the provider and its data are hosted against your data handling policy.
Defender use cases
1. Build an outside-in inventory
Start from what you can prove you own: registered netblocks, cloud elastic IPs, domains and certificate names. Typical scoping patterns are a netblock filter (Shodan net:203.0.113.0/24, Censys host.ip matched against a CIDR value), your organisation name (org:"Example Ltd"), certificate names (Shodan ssl.cert.subject.cn:example.com, Censys cert.names: example.com) and domains (FOFA domain="example.com"). Compare results with the CMDB: anything in the index but not in the inventory is shadow IT or a mis-attribution, and both need an owner. The Certificate Transparency Monitoring Guide for Web Teams covers the complementary certificate log view.
2. Hunt for the exposures attackers look for first
| Exposure | Why it matters | How to scope the search to your assets | Fix |
|---|---|---|---|
| RDP (3389), SMB (445), VNC (5900) | Direct remote access and ransomware entry | Your netblock plus port:3389 (Shodan) or nested host.services: (port = "3389") (Censys) | Remove from the internet; broker through VPN or a gateway. See the Remote Desktop (RDP) Security Guide |
| SSH (22) with password login | Credential stuffing and brute force | Netblock plus SSH protocol filter | Keys or certificates only, allow-listing. See the SSH Key Management Guide |
| Databases and caches (e.g. 9200, 27017, 6379) | Unauthenticated data access | Netblock plus product or port; Shodan's open_database trigger | Bind to private interfaces, require authentication |
| VPN and edge appliance login pages | Zero-day targets with stored secrets | Certificate name or HTTP title of your portal | Patch within KEV deadlines, restrict management interfaces. See the Edge Device Security Guide |
| Admin panels, dev and staging sites | Default credentials, debug data, secrets | Your certificate names plus http.title (Shodan) or title= (FOFA) | Put behind SSO or remove |
| Industrial and IoT protocols | Physical process impact | Netblock plus tag:ics (Shodan) or industrial_control_system trigger | Isolate; see the ICS Advisory Triage and OT Vulnerability Management Guide |
| Expired or mismatched certificates | Outages and a sign of unmanaged hosts | Certificate names plus validity fields; Shodan's ssl_expired trigger | Bring under certificate lifecycle management |
3. Respond fast when a zero-day drops
When a critical edge vulnerability is announced, the first question is how many of your devices are exposed. A saved query by product fingerprint within your netblocks answers it in minutes. Organisations that already know which appliances face the internet can patch, isolate and rotate the secrets those appliances hold first. Cross-check findings with the CISA KEV Catalogue Guide to set deadlines.
4. Monitor continuously
Shodan Monitor lets you register netblocks and enable triggers; its official command line tool enables malware, industrial_control_system, internet_scanner, iot, open_database, new_service, ssl_expired and vulnerable by default for a monitored domain, sends notifications to configured notifiers and supports ignoring specific IP and port pairs once triaged. In Censys, a saved query with host.services.scan_time > "now-1d" shows what was newly observed in the last day. Route alerts to the same queue as vulnerability findings, not a mailbox nobody reads.
5. Spot impersonation
Censys's twist() function finds look-alike hostnames, and FOFA's favicon (icon_hash) search finds hosts serving your logo, which can reveal phishing kits cloning your login page. Hand confirmed cases to the Brand Impersonation and Lookalike Domain Takedown Playbook.
Deployment and safe use
- Write down scope and authority first. Searching an index is passive, but follow-up actions are not. Only actively probe or scan IPs your organisation owns or has written permission to test, and record the netblocks, domains and cloud accounts in scope. Reading another organisation's exposure is not permission to touch it; route third-party findings through coordinated disclosure (see the Bug Bounty and Vulnerability Disclosure Guide).
- Protect API keys. Engine API keys carry paid query credits and reveal what you look for. Store them in a secrets manager, give each integration its own key, and rotate when staff leave.
- Treat results as sensitive. A list of your exposed services is an attacker's target list. Restrict exports and keep them out of public tickets.
- Validate before acting. Confirm ownership (WHOIS, cloud console, DNS), then confirm the service is live from an authorised host. Check the observation timestamp: Censys states that host services are usually removed 24 to 48 hours after the last observation, so stale entries can linger briefly.
- Handle false positives deliberately. Shared hosting, CDNs and cloud IPs reassigned to other tenants produce results that are not yours; honeypots and tarpits produce results that look alarming but are not real services. Record dispositions so the same item is not triaged twice.
- Removal requests are a last step. Censys publishes its scanner ASNs (AS398722, AS398705, AS398324), IP ranges and the
CensysInspect/1.1user agent; blocking them stops future indexing but does not remove history, and Censys does not block IPs dedicated to cloud hosting. Exclusion requests must come from a verifiable WHOIS contact or with ownership documentation. Use this only for systems that must stay reachable and are already hardened.
Detection and hardening value
The engines are a detective control: they tell you that a preventive control failed (a firewall rule, a cloud security group, a change process). Their value shows in the metrics.
- Unknown exposures: internet-facing services found by the engine but missing from the inventory, trending down.
- Time to remediate high-risk exposures: from first observation to closure for remote access, databases and admin panels; aim for days, not months.
- Alert coverage: share of owned netblocks and cloud ranges under continuous monitoring, target 100 per cent.
- Exposure recurrence: services that reappear after closure, which point to a broken change or provisioning process.
- Zero-day response time: hours from advisory to a confirmed list of affected internet-facing devices.
US public sector and critical infrastructure organisations can add CISA's free Cyber Hygiene vulnerability scanning, which continuously scans internet-accessible assets on public static IPv4 addresses, sends weekly reports and raises ad hoc alerts for risky exposed services and known exploited vulnerabilities.
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | RA-5 Vulnerability Monitoring and Scanning; CM-8 System Component Inventory | External view of vulnerabilities and unknown components |
| NIST SP 800-53 Rev. 5 | SC-7 Boundary Protection; CM-7 Least Functionality | Evidence that only intended services are reachable |
| NIST CSF 2.0 | ID.RA-01 (vulnerabilities identified and recorded); DE.CM-01 (networks and network services monitored) | Continuous outside-in monitoring |
| MITRE ATT&CK | T1596.005 Scan Databases; T1595 Active Scanning; T1190 Exploit Public-Facing Application; T1133 External Remote Services | The adversary reconnaissance and initial access these searches pre-empt |
Alternatives
| Approach | Choose it when | Trade-off |
|---|---|---|
| Exposure search engines (this page) | You want a fast attacker's-eye view and alerting with little setup | Data can be stale or mis-attributed; coverage of SNI-only and IPv6 services varies |
| Your own external scanning (e.g. Nmap from an authorised host) | You need current, authoritative results for owned ranges | Point in time; needs scheduling, scope control and permission for cloud providers' rules |
| Commercial ASM or exposure management platforms | Large, changing estates with many subsidiaries and cloud accounts | Cost; attribution logic must be checked. See the Attack Surface Management Buyer's Guide |
| Government scanning services (e.g. CISA Cyber Hygiene) | You are eligible and want a free independent view | Limited to eligible organisations and static IPv4 assets |
Small organisations: a free or low-cost account with alerts on your few public IPs and domains covers most of the value. Large organisations: feed engine data through the API into the ASM or exposure management workflow described in the Exposure Management and CTEM Guide, with ownership attribution and SLAs.
Common failure patterns
- Searching once a year: a pre-audit search misses the database exposed for a weekend by a test deployment.
- Monitoring only known netblocks: cloud accounts, acquired companies and suppliers hosting on your behalf sit outside the monitored ranges.
- Treating removal as a fix: asking an engine to drop a listing while the service stays open leaves it visible to every attacker running their own scans.
- Acting on unvalidated results: taking down or reporting a host that was reassigned to another cloud tenant wastes time and can breach someone else's terms.
- Ignoring stored secrets on exposed appliances: patching an exposed edge device without rotating the service account and API credentials it holds, the lesson of the Ivanti case above.
Practitioner checklist
- Record owned netblocks, cloud ranges, domains and certificate names as the authorised search scope.
- Run initial searches in at least two engines and reconcile results with the asset inventory.
- Enable continuous alerts on every owned range, including new service, open database and expired certificate conditions.
- Save product-fingerprint queries for your edge devices so zero-day exposure can be counted in minutes.
- Validate ownership and liveness before remediation, and log false positive dispositions.
- Close or restrict remote access, database and admin services rather than requesting delisting.
- Store engine API keys in a secrets manager, one per integration.
- Report exposure metrics monthly: unknown exposures, time to remediate, alert coverage, recurrence.
Standards and references
- MITRE ATT&CK: Search Open Technical Databases: Scan Databases (T1596.005)
- Censys: Censys Query Language
- Censys: Opt out of data collection
- Shodan: Search Query Fundamentals
- Shodan: Official Python library and CLI
- FOFA: Python SDK
- CISA: Cyber Hygiene Services
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Attack Surface Management Guide · Exposure Management and CTEM Guide · Edge Device Security Guide · CISA KEV Catalogue Guide