find-exposed-servers

Find exposed servers

Internet-wide scanners already scanned your target. Querying their results is passive — you never send a packet to the target, so nothing appears in their logs and nothing is attributable to you. The cost is that every result is a claim about a moment in the past, and the beginner's mistake is reading a banner as the current state of a live host.

Which platform first

Shodan has the broadest device and protocol coverage and the friendliest query language. Censys has more structured host records, better certificate joins, and a stricter query syntax. FOFA, ZoomEye, Netlas, Onyphe, BinaryEdge and LeakIX see different slices of the internet and are worth a pass when the first two come up empty — non-Western scanners in particular index hosts the big two miss.

Shodan

shodan init <api-key>
shodan host 203.0.113.10                                 # everything known about one IP
shodan search

Free and unauthenticated, for a single IP:

Filters worth knowing: net:, port:, hostname:, asn:, org:, isp:, country:, city:, product:, version:, os:, http.title:, http.html:, http.status:, http.favicon.hash:, ssl.cert.subject.CN:, ssl.cert.issuer.CN:, ssl.cert.expired:, ssl.jarm:, ssl:, tag:, vuln:, has_screenshot:, and before:/after: for scan dates. vuln: and some others require a paid tier.

Censys uses a structured field path syntax over a host document — services.port, services.service_name, services.http.response.html_title, services.tls.certificates.leaf_data.subject_dn, dns.names, autonomous_system.asn, location.country — combined with and/or/not. Its API v2 exposes https://search.censys.io/api/v2/hosts/search?q=… and https://search.censys.io/api/v2/hosts/{ip} with API-ID/secret basic auth.

Side-by-side query equivalents across platforms are in reference/query-cookbook.md.

Reading what comes back

A result is a banner plus metadata, not a verdict. Interpretation of specific service banners — what a version string implies, which fields are self-reported and which are observed — is in reference/banner-interpretation.md. The general discipline:

• Check the scan timestamp on every record. Shodan records carry a timestamp; Censys carries a last-observed time. Rescan cadence varies by port and address space, so a record can be days or many months old. Report findings as "observed on ", never as "is".
• Separate observed from claimed. The open port and the TLS certificate are observed facts. The product name and version are parsed from a banner the host chose to send, and hosts lie — deliberately, or because a distribution backported patches without changing the version string.
• CVE tags are inference. They come from matching a version string against a vulnerability database. They are leads for a report, never confirmation of exploitability, and backported fixes make them wrong routinely in both directions.
• Hostnames in a record come from reverse DNS and certificates, which means they can belong to a previous tenant of the IP.

The pivots that matter

This is what makes scan platforms more than a port list.

Favicon hash. Shodan indexes a hash of the site's favicon (a MurmurHash3 of the base64-encoded icon bytes; FOFA's icon_hash uses the same construction). Because a favicon is usually shipped with an application rather than configured per host, searching the hash finds every host running the same appliance, framework, or the target's own branded portals — across unrelated IPs, ASNs and domains. It is the single best way to find an organization's scattered instances of one product.

TLS certificate. Search on the certificate's subject CN, its subject organization, or its serial number, and you find every host serving that certificate. A certificate serial is unique per issuer, so a serial match is a near-exact identity. Shodan also exposes a certificate fingerprint filter; check its documentation for which hash it expects rather than guessing. Combine with find-hidden-subdomains — CT gives you the cert, scan data gives you every host presenting it.

JARM and TLS stack fingerprints. JARM hashes how a server responds to a set of TLS handshakes, so it fingerprints the TLS stack rather than the certificate. It clusters appliances, load balancers and command-and-control frameworks. It is not unique to an organization, so treat it as a filter that narrows a search, not as an identifier.

Response-body fingerprints. A unique string from the target's pages — a tracking ID, an unusual copyright line, a custom header, a build hash — searched via http.html: finds other hosts serving the same application, including staging copies and the origin behind a CDN.

Finding an origin behind a CDN

When a hostname resolves to Cloudflare or another proxy, the origin still exists and is often reachable by IP. Passive routes to it, in order of reliability:

1. Search scan data for the target's TLS certificate on IPs outside the CDN's ASNs. Origins commonly serve the real cert directly.
2. Search a unique HTTP body string or favicon hash and filter out CDN ASNs.
3. Read historical DNS from before the CDN was adopted (who-owns-this-domain). Origins move less often than people assume.
4. Check services that bypass the proxy by design: MX hosts, ftp, cpanel, direct, origin, and non-HTTP ports on the same netblock.
5. Read SPF ip4: mechanisms — organizations authorize their own sending host, which is sometimes the web origin.

A candidate origin is a hypothesis. Confirming it by sending a request with the target's Host header is an active step against the target: it needs authorization. Note also that a properly configured origin rejects non-CDN traffic, so failure to confirm does not disprove the candidate.

Where this goes wrong

• Staleness cuts both ways. A closed port may have been open when scanned; an open port may have been closed since. Absence of a result is not absence of a service — scanners do not cover every port on every address.
• Honeypots pollute everything. Deliberately exposed decoys inflate results for interesting services. Tells: implausible service combinations on one host, a very large number of open ports, default banners for many unrelated products, and hosting in research-oriented netblocks. Shodan exposes a honeyscore estimate at https://api.shodan.io/labs/honeyscore/{ip}?key= — treat it as a hint, not a ruling.
• Targets can game the scanners. Scanner source addresses are publishable, so a defender can serve fabricated banners to them specifically. High-value targets sometimes do.
• org: and isp: are network registration, not ownership. On cloud netblocks they name the cloud provider, and on resold space they name a reseller. Attribution by org: alone is how people end up reporting a neighbour's exposed database as the target's.
• Shared hosting and shared IPs. One IP can serve hundreds of unrelated sites. Ports and vulnerabilities found there belong to the host, not necessarily to your target.
• Screenshots and banners contain personal data. Exposed dashboards and cameras index real people. That is a data-protection problem the moment you save it.
• Platforms disagree, and each free tier truncates. A single-platform search that finds nothing means one sensor network saw nothing.

Confidence grading

• Confirmed exposure — the same service on the same IP and port appears in two independent scan platforms, or in one platform across multiple scan dates, and the IP is tied to the target by a certificate the target demonstrably controls or by a netblock reassigned to the target by name.
• Probable — a single recent observation on an IP linked to the target by favicon hash, body-string match or reverse DNS. Or a cross-platform match on an IP whose ownership you have not independently established.
• Unconfirmed — attribution resting only on org:/isp:, a shared-hosting IP, a single stale record, a CVE tag with no other evidence, or a host with honeypot characteristics.

Never upgrade a grade by connecting to the service. Record the platform, the query, the scan timestamp and the record identifier for every finding.

Worked example

Target: example-fintech.test, authorized external attack-surface review, passive collection only.

The apex resolves into Cloudflare, so port scanning the resolved IP would only have described Cloudflare. Instead, take the cert subject CN from find-hidden-subdomains and search scan data for hosts serving it. Three hits: two Cloudflare addresses, and one in a European hosting provider's ASN with 443 and 22 open. That third host is the likely origin.

Its favicon hash, searched back, returns six more hosts. Four are the target's regional portals. Two are unrelated companies — the favicon is a stock icon shipped with the framework, not the target's own. That is the dead end, and the lesson: check whether a favicon is actually distinctive before treating a hash match as attribution.

net: on the origin's /29 shows a second host with 3306 open and a MySQL banner, scanned four months ago. Old, so it may be gone, but it is reportable as observed. The netblock's RIR record shows a reassignment to the target's legal name, which is what turns "an IP with the right cert" into attribution.

Stop there. Do not connect to 3306, do not send a Host header to the origin. Report both, with dates and queries, and hand the reassigned netblock back to who-owns-this-domain.

Pivots

Legal and ToS notes

Querying a scan platform is lawful passive research. Acting on the result is where the line is: connecting to an exposed database, opening an admin panel, viewing an exposed camera feed, or fetching a file from an open share can constitute unauthorized access under computer-misuse law in most jurisdictions, and the absence of a password is not a defence. A finding authorizes you to report — to the abuse contact from the netblock's RIR record, or the relevant CERT — and nothing else. Scan-platform terms also restrict redistribution of their data, so quote findings in a report rather than republishing the dataset. Screenshots and banners containing personal data fall under the minimization rules in ../../ETHICS.md.