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

You hold	Reach for	Why
An IP	Shodan host lookup, or the free InternetDB endpoint	One request gives ports, hostnames, and CPEs
A netblock or ASN	Shodan net:/asn: with port faceting	Shows the shape of the estate before you look at individual hosts
A hostname behind a CDN	Censys certificate-to-host joins	Censys links certs to observed hosts, which is how you find origins
A cert or a distinctive page	Favicon hash and cert subject/serial searches	Finds sibling infrastructure the DNS never links
An org name	org: on Shodan, autonomous_system on Censys	Both are attribution by network registration, so both inherit its errors
Coverage doubt	A second platform with different sensors	The platforms disagree constantly; disagreement is signal

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 --fields ip_str,port,org,hostnames 'ssl.cert.subject.CN:example.com'
shodan count 'net:203.0.113.0/24'                        # cheap: no result credits
shodan stats --facets port,org 'net:203.0.113.0/24'      # the shape of a netblock
shodan download results.json.gz 'asn:AS64500 port:3389'
shodan parse --fields ip_str,port,product results.json.gz

Free and unauthenticated, for a single IP:

curl -s https://internetdb.shodan.io/203.0.113.10 | jq .   # ports, hostnames, cpes, vulns

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](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](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 <date>", 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.

1. Search a unique HTTP body string or favicon hash and filter out CDN ASNs.
2. Read historical DNS from before the CDN was adopted (who-owns-this-domain).

Origins move less often than people assume.

1. Check services that bypass the proxy by design: MX hosts, ftp, cpanel,

direct, origin, and non-HTTP ports on the same netblock.

1. 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

New selector	Goes to
Certificate subjects and SANs on discovered hosts	find-hidden-subdomains
Netblocks, ASNs, reverse-DNS hostnames	who-owns-this-domain
Organization names from cert subjects and RIR records	x-ray-a-company, who-really-owns-it
Exposed repo, CI or registry services	secrets-in-git-history
Historical content on a discovered host	read-deleted-pages
Indexed paths on a discovered service	google-like-a-spy
A host/cert/ASN cluster to lay out	graph-the-network

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](../../ETHICS.md).