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

bash

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:

bash

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.

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 <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:

Search scan data for the target's TLS certificate on IPs outside the CDN's ASNs. Origins commonly serve the real cert directly.
Search a unique HTTP body string or favicon hash and filter out CDN ASNs.
Read historical DNS from before the CDN was adopted (
```
who-owns-this-domain
```
). Origins move less often than people assume.
Check services that bypass the proxy by design: MX hosts,
```
ftp
```
,
```
cpanel
```
,
```
direct
```
,
```
origin
```
, and non-HTTP ports on the same netblock.
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.

find-exposed-servers

NPX Install

Tags

SKILL.md Content