CF-Hero: Finding the Origin IP Behind Cloudflare

The problem CF-Hero attacks: a proxy hides the origin

When a web application sits behind Cloudflare, the A record you resolve points at Cloudflare's edge, not at the server running the application. For an engineer doing an authorized assessment, that means port scans, TLS inspection and direct HTTP probing all land on infrastructure that is not the target. The real host is still reachable on the internet in most deployments; it is simply no longer advertised in DNS.

CF-Hero exists to close that gap. The README describes it as "a comprehensive reconnaissance tool developed to discover the real IP addresses of web applications protected by Cloudflare." The audience is narrower than that sentence suggests: penetration testers, bug bounty hunters and internal red teams working with permission. It is not a monitoring tool and not a WAF configuration checker. If you own the application and want to know whether your origin is exposed, CF-Hero answers that question from the outside, which is the same vantage point an attacker would use.

How CF-Hero decides a domain is behind Cloudflare, and what it queries next

The flowchart in the README lays out the sequence. The tool takes a domain, checks its A records, and branches on whether the domain is behind Cloudflare. Only the Cloudflare branch proceeds to gathering. That check is what keeps the tool from spraying queries at unrelated targets.

From there, four families of sources run in parallel. Historical DNS records are pulled from SecurityTrails and Completedns. Current DNS records are read for TXT and A entries. OSINT lookups go to ZoomEye, Shodan and Censys. Separately, the tool looks for subdomains and for other domains used by the same company, on the theory that a sibling host may still resolve directly to the origin.

Everything collected converges on one step: the tool opens direct HTTP connections to each discovered IP address. That validation stage is the part that matters most in practice, because the raw source data is noisy. Historical DNS entries go stale, shared hosting IPs serve many domains, and search engines index whatever they crawled. The README states the tool "validates findings through response analysis to minimize false positives," which is the mechanism that separates a candidate list from a usable one.

The dependencies in go.mod hint at how the HTTP side is built. CycleTLS and fhttp are present, alongside retryablehttp and retryabledns, workerpool for concurrency, miekg/dns, and projectdiscovery's goflags and retryabledns. The TLS fingerprinting libraries are the interesting detail: an origin server behind Cloudflare often only responds correctly to a client whose TLS handshake resembles a browser. Reading the module list, the design clearly assumes that plain net/http is not enough.

Building CF-Hero and running a first scan

The repository is a Go module named github.com/musana/cf-hero and declares go 1.20. The README has an installation section, and the pkg.go.dev badge points at the same module path, so the standard Go toolchain route applies. The repository layout shows cmd/, internal/ and pkg/ directories at the top level:

git clone https://github.com/musana/cf-hero.git
cd cf-hero
go build ./...

After the build you should have a cf-hero binary. The README does not spell out the exact output path produced by go build, so confirm the file exists before continuing.

The tool reads configuration from YAML, since gopkg.in/yaml.v2 is a direct dependency in go.mod and the repository has a pkg/ directory. That is where API keys for the intelligence sources belong. The README's usage section is the authoritative place for the exact config keys; go.mod alone does not reveal them, and inventing key names here would be guesswork.

Once keys are in place, a run takes a domain and produces candidate IPs after the validation step. The README's "Running cf-hero" section covers the flag surface. Expect output only for domains that the A record check classifies as behind Cloudflare; a domain that resolves directly will not enter the gathering branch at all, per the flowchart.

Where CF-Hero is the wrong tool

The biggest constraint is the dependency on third-party intelligence services. ZoomEye, Shodan, Censys and SecurityTrails all require accounts, and the quality of the result tracks the quality of those accounts. A free-tier Censys key returns a fraction of what a paid one does. The README does not document a mode that works without these keys, so if you cannot obtain them, the OSINT half of the pipeline is unavailable to you.

Second, the tool is a snapshot, not a watch. Nothing in the README describes scheduling, change detection or alerting. If your goal is to know when a new origin IP appears, you would be running CF-Hero repeatedly and diffing the output yourself.

Third, response analysis is a heuristic. An origin that serves a login page, a maintenance page or a generic 200 to any Host header can pass validation without being the real target. The README claims the validation minimizes false positives; it does not claim elimination, and no response-based check can. Treat the output as a ranked set of candidates to verify manually.

Finally, the maintenance picture is mixed. The repository is not archived, but the last push was on 2026-06-26, and the most recent release, v1.0.4, dates to 2025-06-01. The gap between the last release and the last commit means the main branch may carry changes that are not in any tagged build. There is no committed LICENSE file visible among the top-level entries (README.md, cmd/, go.mod, go.sum, img/, internal/, pkg/), even though the README carries an MIT badge. If licence terms matter to your organization, that discrepancy is worth resolving before you vendor the code.

CF-Hero against CloakQuest3r and Cloudmare

The two names that come up alongside CF-Hero in search data are CloakQuest3r and Cloudmare. Both target the same problem, and the difference is in where they look.

CloakQuest3r is built around SSL certificate transparency and subdomain enumeration. It leans on certificate data to find hosts that share a certificate with the protected domain, then probes those hosts. The approach is cheap and needs no commercial API, but it only finds origins that reuse a certificate, which is exactly the misconfiguration a careful operator avoids.

Cloudmare takes a different angle again: it looks for DNS history and misconfigured records, and it is commonly used against a broader set of CDNs rather than Cloudflare alone. Its strength is the historical record; its weakness is that history ages badly and the tool has less machinery for confirming what it finds.

CF-Hero's distinguishing choice is breadth plus verification. It queries four source families in parallel and then establishes direct HTTP connections to every candidate, using TLS-fingerprinting clients from CycleTLS and fhttp so that the handshake looks like a browser. That combination is heavier to set up (you need the API keys) but it produces a validated candidate list rather than a raw one. If you have no keys and only need certificate-based hints, CloakQuest3r is the lighter option. If you want the multi-source sweep and the validation stage in one binary, CF-Hero is the one to build.

Upgrade cost and licence status

CF-Hero ships as a Go module with a small direct dependency set: CycleTLS, workerpool, retryablehttp, miekg/dns, projectdiscovery's goflags and retryabledns, progressbar, golang.org/x/net and yaml.v2. The indirect list is longer and includes forked TLS and HTTP stacks (fhttp, utls) pinned to 2022 pseudo-versions. Those pins are the main upgrade cost. Bumping CycleTLS or utls to chase a new browser fingerprint means rebuilding and retesting the validation stage, because the fingerprint is what makes origin servers answer.

The release cadence visible in the release list is uneven: v1.0.2 in January 2025, v1.0.3 and v1.0.4 within two days of each other in May and June 2025. If you track the project, pull tagged releases rather than main, since main has moved past v1.0.4.

On licensing, the README displays an MIT badge linking to opensource.org/licenses/MIT, but no LICENSE file appears in the top-level repository listing. That is a documentation gap, not a legal conclusion, and I am not giving legal advice. If your organization requires a committed licence file before internal use, raise it with the maintainer or check the repository directly at the commit you intend to vendor.

Editorial conclusion

Adopt CF-Hero if you run authorized assessments against Cloudflare-fronted applications and want multi-source gathering plus response validation in one binary. Do not adopt it if you have no API keys for the intelligence sources, since the README does not document a keyless mode, or if you need a supported product rather than a research tool. Before relying on output, verify three things: whether the MIT badge in the README matches a committed licence file, which the top-level repository listing does not show; whether you are pulling the tagged release v1.0.4 rather than main; and whether the candidate origin returns the expected application response to a direct HTTP connection rather than a default page.

Frequently asked questions

Official sources

1. Issues
2. musana/CF-Hero on GitHub
3. README
4. Releases