CloakQuest3r

spyboy-productions’ Python tool for uncovering the real origin IP of a site behind Cloudflare or a similar reverse proxy/CDN (MIT, ~2,222★/301 forks; created 2023-11-02, last pushed 2026-01-06). Routed here 2026-08-05. The README scopes it as “a Proof of Concept, for Educational Purposes Only,” requiring written permission before use against any target.

What it does

Enumerates subdomains, then checks which of them resolve outside the CDN’s IP ranges — the common misconfiguration where www is proxied but a forgotten dev, mail or direct subdomain points straight at the origin. Around that it runs SSL-certificate analysis (matching a cert seen on an exposed host to the protected one), IP-history lookups (addresses the domain used before it moved behind Cloudflare), and optional SecurityTrails API enrichment, threaded for speed.

None of it is exotic and none of it is AI. It is the standard infrastructure-recon toolkit pointed at one specific job: defeating origin-hiding.

Why it is interesting here — the first tool aimed at beating a named defense

Every infrastructure tool the spoke held resolves an address into facts (ip-reconnaissance, myip). CloakQuest3r assumes the address is deliberately hidden and works to recover it anyway. That makes it the first source whose target is a control, not a subject — the counterpart to the CDN’s promise that the origin cannot be reached directly.

It also inverts myip cleanly. MyIP is the toolkit run inward — know what the cheap recon already sees about you. CloakQuest3r is the same infrastructure primitives run outward against a protected target, and the two together state the defensive lesson exactly: the honest defence is running this against your own domain before someone else does, because what leaks the origin is your own DNS history and your own forgotten subdomain, not anything Cloudflare controls.

The evidence discipline is better than a profiler’s

The recon here is self-verifying in a way people-profiling is not. A recovered origin IP is either reachable and serves the same site or it is not — a testable claim, where a profile is a set of assertions nobody checks (autonomous-pentesting made the same point about exploits). So its false-positive mode is narrow and visible: a candidate IP that turns out to be a shared host or a stale record fails the reachability check rather than sitting in a dossier as a plausible-looking guess.

Dual-use, and the boundary is the usual one

The capability is neutral — a defender maps their own exposure, an attacker maps someone else’s — and the tool ships the standard README warning with no technical scope enforcement, nothing distinguishing a domain you own from one you don’t. That is strix‘s boundary problem in a smaller, non-AI form: consent is a convention, not a control. The spoke’s standing position holds — catalog and analyse the technique and its defence, no operational use against real targets — and the useful thing to record is that origin-IP exposure is a configuration failure, so the defence is auditing your own DNS and cert history, not buying more proxy.

Tier

T3 — the author’s own repository, self-describing. The subdomain/cert/DNS-history techniques are well understood and the code is readable, but nothing here measures a hit rate against real Cloudflare deployments, and success depends entirely on the target having leaked somewhere.

ip-reconnaissance · myip · osint · strix · autonomous-pentesting · synthesis