Searches every CSV for the target domain in the Common Name and SAN DNS fields. Matching IPs are candidate origins — the origin server's cert has the real domain, the CDN's cert doesn't.
Filter CDN ranges
CDN ranges (Cloudflare, Fastly, AWS CloudFront) are fetched live and used to drop CDN-owned IPs. What remains are non-CDN candidate origins.
Outputs:
inventory.jsonl — every matching IP with cert fields + CDN classification
candidates.txt — non-CDN IPs to probe
Input: Target Domain
Enter the domain fronted by a CDN/WAF (no protocol), e.g. shop.acme.com.
Default example.com — Cloudflare-fronted, a safe live test. One domain per run.
> Only test targets you are authorised to assess.
Confirm Origin (WAF Bypass)
confirm-origins connects directly to each candidate IP but sends Host = target domain, so the origin serves the target's virtual host instead of its default page.
The response is compared against the CDN-fronted baseline:
| Signal | Score |
|---|---|
| TLS cert valid for domain | +40 |
| Page <title> match | +20 |
| Favicon mmh3 match | +20 |
| Body sha256 match | +15 |
| Server header match | +5 |
Score ≥ 40 = CONFIRMED origin. A non-CDN IP that answers but blocks (403/401) is flagged as a likely-but-locked origin.
> Technique from the blog.
Fetch Cloud SSL Dataset
fetch-cloud-data shallow-clones the trickest/cloud repo — a daily scan of every AWS EC2 and GCP IP range for SSL certificates.
CSV columns per host:
| Field | Example |
|---|---|
| IP Address | 3.90.103.70 |
| Common Name | cloudflare.malwareworld.com |
| Organization | Amazon |
| SAN DNS | cloudflare.malwareworld.com |
| Self-signed | false |
> The origin's cert carries the real domain name. The CDN's cert does not.
Results
A Trickest-styled PDF + structured JSON (report.json):
Confirmed origins ranked first (CRITICAL — direct WAF bypass)
Likely origins needing manual review
Full IP inventory with CDN classification and cert fields
Methodology — dataset → search → filter → confirm
report.json contains the same findings in machine-readable form for export / SIEM pipelines.
Overview
A WAF only protects the traffic that goes through it. If the origin server also
answers on its own public IP, every control you bought sits to one side of the
request: the rate limiting, the rules, the bot scoring, all bypassed by connecting
directly. Teams usually believe the origin is unreachable, because the main
hostname resolves to the CDN and nothing about that looks wrong.
This tells you whether that belief holds. Candidates come from sources that never
touch the target: subdomain enumeration, certificate transparency, passive DNS
holding addresses from before the CDN was in front, and the MX and SPF records
that mail infrastructure publishes and a CDN rarely fronts. Everything resolving
into a published CDN range is dropped, and what is left is requested directly
with your domain in the Host header. So you finish with a verdict per address
rather than a list to work through, which is the difference between a lead and a
finding.
It is a standing check for offensive security
work, because an origin leaks the day someone adds a DNS record, not the day you
look. Run on a schedule, the value is the diff: an address that answers outside
the CDN this week and did not last week is the alert.
Pipeline
Read the target domain.
subfinder enumerates subdomains, including the mail, dev
and legacy hosts that usually sit outside the CDN.
The resolved addresses are checked against the published ranges of the major
CDN providers, leaving the ones that belong to you.
Each remaining IP is requested directly with the original Host header, and the
response is compared against the site served through the CDN.
Confirmed origins are ranked by confidence and written to a PDF.
Inputs
Target domain. The hostname that sits behind the CDN or WAF, with no
protocol, one per run. The default is example.com, which is CDN fronted and
safe to run against while you read the graph.
Credentials. None. Subdomain enumeration, certificate transparency,
passive DNS and the DNS record lookups are all token free, so nothing has to be
provisioned before the first run.
CDN ranges. Not a field you fill in. The published ranges for Cloudflare,
Fastly and AWS CloudFront are fetched at run time rather than baked into the
workflow, so a range the provider added last week still filters correctly.
Outputs
Ranked candidate report (PDF). Every candidate address with its verdict.
Confirmed origins rank critical, addresses outside all CDN ranges that did not
confirm rank medium.
Per-IP evidence. The direct-to-IP response behind each verdict: status,
server header, page title, certificate match and body hash, next to the CDN
fronted baseline it was scored against.
Resolved IP inventory. Every hostname the run found and the addresses it
resolved to, including the ones inside CDN ranges. When nothing leaks, the
inventory is what the run is worth.
Sample output
From a completed run against example.com.
The confirmation step is where a candidate becomes a finding. Each address is
requested directly and the response is fingerprinted, so the comparison is
against evidence rather than a guess:
scheme
port
status
server
title
body_sha256
cert_valid_for_domain
reachable
kind
ip
https
443
200
cloudflare
Example Domain
ff67a9d7...
true
true
baseline
null
https
443
200
nginx
Example Domain
ff67a9d7...
true
true
candidate
192.0.2.10
https
443
200
nginx
Example Domain
ff67a9d7...
true
true
candidate
192.0.2.23
http
80
301
cloudflare
—
—
false
true
reject
104.20.23.154
dnsx keeps the full record detail, including the SOA that names
the DNS provider:
kind: baseline is the site as served through the CDN. A candidate is only
reported as an origin when its body hash and certificate match that baseline
while its address sits outside every published CDN range.
FAQ
What makes a candidate a confirmed origin rather than a lead?
Two things have to hold. The address has to sit outside every published CDN
range, and a direct request to it carrying your domain in the Host header has to
answer like your site. Certificate, page title, favicon hash, body hash and
server header are scored together, and only a candidate that clears the threshold
is reported as confirmed. The rest stay candidates with their evidence attached.
Why does the body hash comparison matter?
Any host will answer on 443. Comparing a hash of the response body against the
CDN fronted baseline is what separates the server that actually serves your site
from a shared host, a default virtual host, or a parking page that happens to be
reachable. Without that comparison you have an open port and a guess.
Does the target see this run?
The enumeration half does not, because subdomains, certificate transparency,
passive DNS and DNS records all come from third-party sources. The confirmation
step does, because it has to connect to each candidate address. Expect those
requests in the origin's own logs even though the CDN never sees them.
What do you do once an origin is confirmed?
Change the address, then restrict the new one so it only accepts connections from
the CDN's published ranges. Changing it matters because the old address stays in
passive DNS history and certificate logs for years. Re-run afterwards: if the
address no longer confirms, the fix held.
Do you need an API key for any of the sources?
No. Every source the enumeration reads is public and unauthenticated, and the CDN
ranges are published by the providers themselves, so a run needs nothing beyond
the domain.
Related workflows
Subdomain Enumeration. Reach for this
one first when you do not have the complete hostname list yet, because origin
finding is only as good as the names you feed it.
ASN-Wide Vulnerability Scan. Reach for this
one once the origin is confirmed and the question moves to what is wrong with
that host and everything sitting beside it in the netblock.
Passive Port & CVE Scan (Shodan). Reach for
this one when you want the origin's service banners without any probe of your
own reaching it.