Detecting Fake Hotel Sites Behind Cloudflare: Technical Methods

When we analyzed hundreds of fake hotel sites, the picture that emerged was extremely clear: more than eighty percent of these sites were hosted behind the Cloudflare CDN (Content Delivery Network). This choice is no coincidence; Cloudflare hides the real server IP address, significantly complicating the takedown (removal) processes.

To initiate action against a fake site, it's necessary to reach the hosting company. To reach the hosting company, knowing the IP address is essential. When Cloudflare hides this IP, the process seems to stall. However, the visible and the real are not always the same.

In this article, we discuss how Cloudflare works, why the protection is not absolute, and the technical methods used to bypass this protection and reach the real infrastructure of fake sites.

Legitimate sites use Cloudflare for DDoS protection, speed optimization, and security. Fraudsters, on the other hand, prefer it for a different reason: to remain anonymous.

When a site goes behind Cloudflare's proxy, every external DNS query shows only Cloudflare's IP addresses. The real server IP is not visible. This both complicates removal requests and makes it harder to identify the hosting company.

Industry experts state that fraudsters using Cloudflare in this way actually constitutes platform abuse. Cloudflare's own policies prohibit this use; however, the system does not intervene automatically without a complaint.

Cloudflare protection works at a specific layer: it masks HTTP and HTTPS traffic. However, a web server doesn't work only with web traffic. Email servers, old DNS records, subdomain configurations, and server behaviors can remain outside this mask.

In our research, we've seen that in seventy-three percent of fake sites using Cloudflare, it was possible to reach the real IP address with at least one alternative method.

This is the most common and most productive vulnerability. Even if the main domain is behind Cloudflare, subdomains can point directly to the server IP with a different configuration.

The technical reason for this is as follows: SMTP (email) traffic cannot be routed through the Cloudflare proxy. Subdomains like "mail.fakehotel.com" or "smtp.fakehotel.com" must connect directly to the mail server. When a DNS query is made for this subdomain, the real IP address is directly visible.

In a case we detected in our research, while the main domain was fully under Cloudflare protection, the "info." subdomain pointed directly to a server in Eastern Europe. Seventeen different fake booking sites were hosted on the same server.

Tools used for subdomain scanning include Sublist3r, Amass, and Subfinder. These tools try common subdomain names for a domain and determine which ones point to a real IP.

• mail., smtp., imap., pop., mx., webmail. (email infrastructure)
• ftp., sftp. (file transfer)
• cpanel., whm., plesk., direct-admin. (hosting panels)
• api., backend., admin., portal. (application layers)
• dev., staging., test., beta. (development environments)

The vast majority of fake sites do not use Cloudflare initially. After the site is established, they switch to being behind a CDN against the risk of detection. DNS records from this pre-transition period remain stored in various archive services.

Passive DNS databases like SecurityTrails and ViewDNS.info store the IP addresses and nameserver records that a domain has used in the past. When looking at these archives, the real server IP used before switching to Cloudflare can be seen.

In one client's experience, it had been only three days since they notified us that the fake site had switched to Cloudflare. A query we made on SecurityTrails revealed two different IP addresses used in the pre-transition period. One of these IPs was still actively serving multiple fake sites.

In CT logs, not only the domain name but occasionally IP-based searches can also be performed. Some servers obtain SSL certificates for their own direct IP addresses as well.

After an IP address is detected, certificate records for that IP can be searched on crt.sh. This search can reveal other fake sites on the same infrastructure.

In a real case: after finding the IP address of a fake hotel site using the subdomain method, we detected 27 more different fake domains for the same IP in our search in CT logs. All were within the scope of the same operation.

To get more comprehensive information about Certificate Transparency logs, we recommend examining our Certificate Transparency Log Monitoring article.

Shodan is a search engine that continuously scans devices and servers connected to the internet. When an IP address is searched on Shodan, the software versions running on that server, open ports, service headers (HTTP response headers), and banner information can be seen.

This information can be used for several different purposes:

• Determining which hosting company the server belongs to (ASN information).
• Detecting other sites hosted on the same server.
• Noting known security vulnerabilities in the server software (supporting evidence in takedown applications).

In a portion of the fake sites we analyzed, information obtained from Shodan scans enabled the identification of the server's registered hosting company and gave the opportunity to apply directly to that company.

Some web servers, due to misconfiguration, broadcast detailed server information at endpoints like "/server-status" or "/server-info". On servers where this is open, all virtual host names using that server can be listed.

When this type of vulnerability is detected, Cloudflare protection becomes non-functional. Because with the server's own report, all domains and IP relationships come to light. We encountered exactly this vulnerability in one of the fake sites we analyzed; the server hosted 31 different fake domains and gave the information of all of them itself.

Detecting these types of vulnerabilities doesn't require checking every URL manually. Automated tools can scan these endpoints quickly.

Reaching the real IP address concretizes the takedown process:

Direct complaint to the hosting company: Which hosting company the IP belongs to can be determined by an ASN query (with tools like bgp.he.net or ipinfo.io). A DMCA notice or abuse complaint can be sent to the hosting company's abuse email address.

Strong application to Cloudflare: Presenting real server information in complaints made to Cloudflare speeds up the application evaluation process. Cloudflare can terminate the service of sites that violate its abuse policy.

Technical evidence in prosecutor applications: IP address and hosting information have the status of technical evidence in Turkish criminal proceedings and help the investigation gain speed.

Every web server sends various header information in HTTP responses. These headers may contain clues about the server software, runtime environment, or hosting infrastructure.

Headers to pay particular attention to:

• Server: Can explain server software like Apache, Nginx, LiteSpeed; sometimes also contains version information.
• X-Powered-By: Runtime information like PHP version, ASP.NET version.
• CF-Cache-Status: Cloudflare cache status—verifies whether the site is actually behind Cloudflare.
• Set-Cookie: Some hosting platforms leave their own traces in the cookie header (cPanel, Plesk, etc.).

To check these headers, the browser's developer tools (F12 → Network tab) can be used. At the same time, it's possible to see the headers in raw format using the curl command.

In one client's experience, "X-Powered-By: PHP/7.4" and a special session cookie format made the identification of the hosting provider possible. This combination carried the fingerprint of a specific hosting company, and an abuse report could be made directly to that company.

Fake hotel sites occasionally use functional email addresses to create a perception of reality. Contact pages containing email addresses like "[email protected]" add a legitimate look to the fake site.

Querying the MX (Mail Exchange) record for this email address can reveal the IP address of the mail server. An MX query made with MXToolbox or the dig command shows where the mail traffic is directed. The mail server is often not behind the Cloudflare proxy and reveals the real IP address.

In a case we detected in our research, the MX record pointed to a completely different IP address from the web traffic. It overlapped with a fake hosting infrastructure we had detected earlier; this allowed us to document that two different fake hotel sites belonged to the same operator.

In practice, applying these methods in a flow rather than independently gives the most efficient result. Recommended research order:

1. DNS historical query (SecurityTrails): Is there a pre-Cloudflare IP?
2. Subdomain scan: Do subdomains like mail., smtp., ftp., admin. point directly to an IP?
3. MX record query: Where does the mail server IP connect?
4. CT log research: Are there other certificate records for the found IP? Can other sites of the same operator be detected?
5. Shodan scan: Software and infrastructure information running on the IP.
6. HTTP header analysis: Hosting platform clues.

When we apply this flow to a single fake site, we spend an average of 45-90 minutes; however, the results mostly give comprehensive information about the entire fake operation, not just that site.

A frequently asked question: why does Cloudflare continue to serve these fake sites?

Cloudflare is a company that provides infrastructure service, not content, and makes decisions according to its own policies. It terminates the service of sites proven to contain phishing, brand infringement, and fraud; however, it makes this decision with a process based on complaints.

While evaluating abuse reports, Cloudflare looks for:

• Concrete phishing evidence (payment form, fake booking screen, etc.).
• Brand infringement document (trademark registration or clear proof of brand ownership).
• Victim statements (user complaints documenting they have been victimized).

Industry experts state that in reports with high document quality, Cloudflare's service termination decision comes within 3-7 days. In reports with weak or ambiguous documentation, the process can take longer or end without results.

Therefore, adding technical evidence collected with the above research methods to the notification before a Cloudflare notification is critically important.

Applying these methods one by one both requires technical knowledge and takes time. In some cases in our research, it took hours to reach the real IP of a fake site.

Considering the number and complexity of fake hotel sites, manual research is not sustainable in the long run. Industry experts state that automating such analyses has become an operational necessity.

In our research, it was seen that hotels reaching a real IP had fake sites removed in an average of 4 days. In cases where a real IP couldn't be detected, this period went up to 3-6 weeks; during this time, the fake site continued to collect money from guests. IP detection is not a matter of comfort; it creates a difference in efficiency that can be measured directly with economic loss.

In addition to researching DNS history at the real IP detection stage, CT log monitoring is also a strong complementary technique. You can learn how to monitor all SSL certificates obtained in your hotel's name through Certificate Transparency logs in this guide. Additionally, the SecurityTrails and Shodan platforms are free resources frequently consulted in IP detection.

Is it legal to detect a site behind Cloudflare? Yes. Passive DNS querying, CT log research, and archive scanning are completely legal technical methods. These methods benefit from publicly available data. Actions with the nature of unauthorized access or attack directly on a system are not legal; however, the methods described in this guide do not fall into this category.

What is the fastest method to bypass Cloudflare? DNS history research (SecurityTrails, PassiveDNS) and CT log querying (crt.sh) give results within a few minutes in most cases. Site-specific subdomains or old email headers can also provide fast IP detection. Although there isn't a definite ranking, the success rate increases significantly when these two methods are used together.

What information does Shodan provide? Shodan lists services and banner information running on a specific IP address by scanning open ports. It shows what country an IP is in, what hosting provider it uses, and open web services. This information serves as concrete technical evidence while preparing an Abuse notification to the hosting provider.

Can a takedown be initiated without a real IP? Yes. Even if a real IP is not known, an ICANN complaint to the domain registrar and a phishing notification to Cloudflare can be made. However, knowing the real IP provides a significant advantage for being able to apply directly to the hosting provider and get faster results. Domain-level takedown and server shutdown following real IP are two strategies that complement each other.

Use RuuSafe's automated scanning tool to detect the real infrastructure behind Cloudflare for fake sites belonging to your hotel. The first scan is free and gives results within a few minutes.