Usually when DDoS protection providers are in the news, it's for one of two reasons. Either they mitigated another large scale traffic flood targeted at one of their customers or they are shielding websites with harmful content from being taken down with such an attack.

While being a popular excuse for providers of DDoS attack services, real Distributed Denial of Service attacks are hardly something that security teams do for testing the resiliency of their companies' networks. Yet, there is some value behind being able to find the real IP behind a DDoS protected website, especially in the bug bounty space, such as access to running services other than HTTP or to bypass web application firewalls, that prevent attacks such as SQL injections.

In this blog post we will have a closer look at a collection of methods that can be used for that purpose.

Server-Side Request Forgery

One of the ways to find the real IP address is a Server Side Request Forgery vulnerability. If there is such a flaw in the web service it's easy to find the origin IP if requests aren't routed through a proxy first.

Just use your own server as receiving host and issue the request. You can then find the requesting IP in the log files. If this IP does not belong to the DDoS protection provider, it's highly probable that the IP belongs to the server that runs the application which issued the request.

WordPress Pingbacks

WordPress has a feature called pingbacks. They allow you to indicate relationships across Websites. When an author writes a post linking to a WordPress website he may send a pingback request using WordPress’ API.

In order to verify whether the linking website was indeed responsible for sending the pingback request the website that receives it will issue another request back to the source server.

So in other words, we can force a WordPress website to send an HTTP request to our Webserver - given pingbacks aren't disabled.

To find the url for the pingback you can use the x-pingback header value or search for the pingback meta tag within the HTML source of a blog post. Usually it's /xmlrpc.php

In order to exploit that behavior you need to send the following request with an application/xml content-type header and replace the two values.

<?xml version="1.0" encoding="iso-8859-1"?>
<methodCall>
  <methodName>pingback.ping</methodName>
  <params>
    <param>
      <value>
        <string><https://your-website/logging></string>
      </value>
    </param>
    <param>
      <value>
        <string><https://target-website/link/to/blog/post/></string>
      </value>
    </param>
  </params>
</methodCall>

Finding Server IP by searching for TLS certificates

Most DDoS protection providers act as an intermediate proxy between a sites users (or attackers) and the actual server, with the application hosted somewhere else.

To protect data being sent from the cloudflare intermediate to the origin server, there is often an additional TLS certificate.

However, when connecting to a TLS protected port, the server may respond with a certificate that contains the server’s domain name.

What this means is that you can easily use a service such as censys, that continuously scans the web and stores these certificates in a searchable format - including information such as the IP address of the service.

It allows you to search for a specific domain, go through the associated IP addresses, resolve them and check whether the IP is not from the DDoS protection service. If it is not, it is likely that you found the origin server.

E-Mail

Depending on the setup you might be able to get the real IP address from the email headers when a site sends you a newslette, marketing email or

This may not always reveal the server address itself, but maybe the IP of a dedicated mail server instead, yet it doesn't hurt to try.

DNS records

While you certainly want all traffic to go through the reverse proxy that hides your server’s IP address, you don't want to expose any services like SSH through it. Besides, not all DDoS Protection Services allow to proxy any TCP connection, but instead just forward HTTP requests.

Therefore many website owners use a separate DNS entry that points to the real IP address instead of the cloudflare one for example. This may include hostnames such as ssh.example.com, direct.example.com etc. So if you apply the usual methods for subdomain enumeration you might find one that actually points to the real web server.

Shodan, Google, etc.

TLS certificates are not the only identifier that you can use to find an origin web server via various specialized search engines.

Instead there are other methods, such as checking the response for certain indicators such as unique header constellations, keywords, tracking ids and even the favicon.

You can either use Google for simple queries or use the powerful filters provided by shodan. Either way you are searching for information on the target website that will also be served identically over an unprotected direct connection.

Historical DNS Records

Often DDoS protection is an afterthought and not implemented from the start. This means that your target may have pointed its dns records to the actual origin server before it thought about pointing it to a DDoS protection provider. There are some services that collect historical DNS information and make them searchable for a fee.

That means you can search for your target in their databases and may find the real IP as one of its previous entries.

Conclusion

DDoS protection is not an easy plug & play solution that you just switch on and allows you to be safe when a dedicated attacker tries to find out a direct path to your backend web server.

Instead you must be mindful of the different ways attackers are able to get your IP address and prevent them from working, ideally by switching operation to a different machine, blocking any communication not coming from or going to the DDoS protection service and routing necessary outgoing requests through a dedicated server, not connected to the actual origin server.