Finding the Origin Server Behind Cloudflare: How HailBytes ASM Bypasses CDN Shielding

Putting a site behind Cloudflare is supposed to shrink your attack surface: scanners see Cloudflare’s edge IPs, the WAF filters hostile traffic, and the origin server stays out of view. The problem is that “out of view” is not the same as “unreachable.” If an attacker can find the origin’s real IP address, they can connect to it directly — bypassing the WAF, the rate limits, and the bot protection entirely — and whatever is listening on that IP becomes attack surface again. HailBytes ASM’s origin_bypass phase looks for exactly this exposure, so it surfaces in your scan results instead of in someone else’s recon notes.

Why Cloudflare-Fronted Assets Still Carry Risk

The shielding only holds if every path to the origin goes through Cloudflare. In practice it frequently doesn’t. Origin servers commonly leave SSH, database ports, monitoring endpoints, and old admin panels listening on the public interface, protected by nothing more than the assumption that nobody knows the IP. DNS history from before Cloudflare was enabled, a forgotten subdomain that points straight at the origin, an email server sharing the same host, or a TLS certificate the origin presents directly — any of these can leak the address. Once it leaks, the WAF is just a setting on a hostname the attacker no longer needs to use.

This is a category of exposure that traditional scanning misses by design: point a scanner at the hostname and it dutifully reports on Cloudflare’s edge, exactly as Cloudflare intends. The risk lives one layer down.

The Two-Phase Discovery Pipeline

HailBytes ASM approaches origin discovery the way an attacker would, in two stages.

Classification. First the phase classifies a target’s A records against Cloudflare’s published CIDR ranges. If a host already resolves to a non-Cloudflare IP, there is nothing to bypass. If it sits behind the Cloudflare edge, it becomes a candidate for origin discovery.

Candidate generation with CloudFlair. The phase queries Censys for hosts on the public internet presenting the same TLS certificate as the target. An origin server very often serves the site’s real certificate directly — so a non-Cloudflare IP answering with that exact certificate is a strong origin candidate. This is the CloudFlair technique: use internet-wide certificate data to find the machine hiding behind the proxy.

Confirmation with hakoriginfinder. Candidate IPs are not taken on faith. Each one is probed and its response body is hashed and compared against the response served through Cloudflare; when the bodies match, the candidate is confirmed as the real origin rather than an unrelated host that merely reused a certificate. Confirmed origins are persisted as exposed-origin-ip Vulnerability rows.

What the Finding Tells You

An exposed-origin-ip finding means the WAF is bypassable for that asset, and it points you at the IP to lock down. The remediation is concrete: restrict the origin’s firewall to accept inbound traffic only from Cloudflare’s IP ranges (or use Cloudflare Tunnel / Authenticated Origin Pulls), and close the SSH, database, and admin ports that were never meant to face the internet in the first place. Because the finding is an ordinary Vulnerability row, it flows into the same exposure graph, SIEM forwarding, ticketing, and compliance reports as the rest of your attack surface.

Enabling the Phase

Origin bypass is off by default and opt-in via the origin_bypass block in the scan engine YAML. It uses Censys through the existing threat-intel provider configuration, so it needs a Censys API key; when no key is present, the phase skips silently rather than failing the scan. Like the rest of HailBytes ASM, it runs in your own AWS or Azure account, so the certificate lookups and origin probes happen under your control.