Cloudflare has become one of the main guardians of the modern web. Millions of sites rely on the company for protection against DDoS attacks, performance improvements via CDN and, above all, for hiding the real IP addresses of their servers. On top of that protection layer, a business worth tens of billions of dollars has been built.
However, in cybersecurity there is no such thing as a perfect shield. Many organisations protect their main domain with Cloudflare, but forget something as basic as applying the same security layer to all their subdomains: development environments, admin panels, staging servers, legacy APIs… And that is exactly where CloudRip comes in.
This tool, whose legitimate use lies in authorised security audits and penetration tests, specialises in locating those “blind spots” and revealing origin IPs that remain exposed, despite the apparent protection offered by Cloudflare on the main domain.
What CloudRip actually does
CloudRip is built with a very specific goal: finding IP addresses of servers that sit behind Cloudflare… but that, due to misconfigurations or oversight, have not been fully protected.
Its operation is based on three very simple ideas:
- Subdomain enumeration
It starts from a target domain (for example,example.com) and generates or loads a list of potential subdomains:dev.example.com,staging.example.com,admin.example.com, and so on. - DNS resolution
For each subdomain, it resolves its IP address and checks which range it belongs to. - Cloudflare IP filtering
If the IP is part of Cloudflare’s ranges, it gets discarded. If it is not in the known Cloudflare ranges, it is flagged as a possible real origin IP.
This way, the analyst doesn’t have to manually review hundreds or thousands of subdomains: the tool directly delivers a filtered list of targets that are worth investigating in more detail.
Installation and requirements, without pain
CloudRip is written in Python and deploying it in an audit environment (such as a Kali Linux-based distro) is straightforward. In essence, you only need to:
- Pull the code from its public repository.
- Install two lightweight libraries to improve terminal output (colour and banner).
- Run the tool specifying the domain to analyse and, optionally, a custom subdomain list and an output file.
From there, the user can begin cross-referencing subdomains and IPs, always within a legal framework and with the explicit consent of the domain owner.
Advanced options for professionals
Although CloudRip is easy to use, it includes several options aimed at security teams and pentesters:
- Custom wordlist: allows the use of custom subdomain lists obtained with other tools (such as DNS enumeration tools or subdomain scanners), significantly increasing the depth of the analysis.
- Thread count: you can increase scan speed by running multiple queries in parallel, adjusting the number of threads according to available resources and how much noise you are willing to generate.
- Output to file: the list of IPs not associated with Cloudflare can be written to a text file, making subsequent analysis, correlation, or integration into other workflows much easier (for example, port scanners or attack-surface review tools).
A practical example: from audit to exposed IP
To better understand CloudRip’s role in a real environment, it helps to imagine a typical situation in a mid-sized company.
Scenario: security audit in a company with global presence
A tech company with customers across several countries commissions an external security audit of its web infrastructure. Its main domain (global-company.com) appears to be perfectly protected with Cloudflare: DNS records point to Cloudflare IPs, the WAF is configured and there are specific rules in place to mitigate attacks.
At first glance, everything seems in order.
- Initial review of the main domain
The audit team confirms using standard tools (whois, DNS queries) that the domain sits behind Cloudflare and that the real IP is not visible in the main A record. This is the expected behaviour. - Subdomain enumeration
Next, the team uses subdomain discovery tools (passive collection, certificate transparency, search engines, public DNS…). The result is a list with dozens of entries:app.global-company.comportal.global-company.comdev.global-company.comstaging.global-company.comlegacy-api.global-company.com- etc.
- Running CloudRip with a custom wordlist
Instead of using only the generic list bundled with the tool, the auditors feed CloudRip with the wordlist generated in the previous step.
This way, the tool is not “guessing” subdomains, but working with what actually exists in the organisation:- For each subdomain, it resolves the IP address.
- It checks whether that IP belongs to Cloudflare’s ranges.
- If not, it flags it as a potentially exposed origin address.
- Key finding: a forgotten staging environment Among the scan results, one item stands out:
staging.global-company.com → 203.0.113.45(IP not belonging to Cloudflare).
- A staging environment accessible from the open Internet.
- A login panel with credentials reused from production.
- Old versions of the web framework and API, with known, catalogued vulnerabilities.
- Reporting and remediation The finding is documented in the audit report, highlighting:
- Risk of unauthorised access to test data (which sometimes contains real information).
- Potential to use the staging environment as an entry point into internal systems.
- Inconsistency in the subdomain protection policy.
- Moves the staging environment behind Cloudflare or restricts it to VPN/allowed IPs.
- Reviews its subdomain inventory to locate other forgotten services.
- Strengthens deployment procedures to prevent similar “oversights” in future.
These kinds of scenarios are common: admin panels, old CMS installs, legacy API versions… CloudRip helps bring them to light in minutes, but always under one core principle: it is a defensive tool, not an offensive one. Its use should be tied to authorised audits, internal Red Team exercises or security consulting work supported by a formal contract.
Strengths and limitations of the tool
CloudRip’s minimalist approach brings clear advantages:
- It focuses on a very concrete problem (finding unprotected origin IPs).
- It is lightweight, fast, and easy to integrate into existing workflows.
- Its multi-threaded architecture lets you tune performance without unnecessary complexity.
But it also has limitations that professionals should keep in mind:
- It fully depends on the quality of the subdomain list. If the organisation uses very unconventional or secret naming schemes, it may be impossible to detect them.
- Companies that have properly protected all their subdomains behind Cloudflare will expose few or no “interesting” IPs.
- It doesn’t analyse historical DNS data, certificates or other advanced sources; it focuses on current name resolution.
In short, it is another component in the toolbox of any cybersecurity professional, especially useful during reconnaissance and attack-surface assessment phases.
Frequently asked questions about CloudRip and finding IPs behind Cloudflare
Is it legal to use a tool like CloudRip to discover real IPs behind Cloudflare?
It is only legal when used with explicit permission from the domain owner, within the framework of an audit, bug bounty, or penetration test covered by a contract. Using it against third-party systems without consent can qualify as a computer crime in many jurisdictions.
What exactly does CloudRip do to find servers hidden behind Cloudflare?
CloudRip generates or receives a list of subdomains, resolves their IP addresses and compares them against Cloudflare’s IP ranges. Any IP that doesn’t belong to those ranges is flagged as a potentially exposed origin server, which the analyst can then examine in more detail.
Can CloudRip completely bypass Cloudflare protection on a well-configured site?
No. If an organisation has correctly protected all its subdomains, shut down unnecessary services and maintains good DNS hygiene, the tool will not find useful IPs. CloudRip does not “break” Cloudflare; it simply detects misconfigurations and forgotten subdomains.
What best practices should companies follow so tools like CloudRip don’t uncover weak spots?
Maintain an up-to-date inventory of domains and subdomains, put Cloudflare (or an equivalent WAF) in front of all exposed services, restrict access to staging and test environments using VPNs or allow-listed IPs, and regularly review their exposure with internal or external security audits.
Sources:
- Public CloudRip repository on GitHub.
- Cloudflare documentation and educational material on origin protection and infrastructure.
