I recently saw a tweet that got me thinking, then it got me reading, then it kept me busy for about an hour. In that short space of time I managed to take control of a lot of domains that were up for grabs. Of course, as the title suggests, once you control a domain you're allowed to get certs for it. Here's how scarily easy that can be.

What got me started

It was a normal Wednesday and I was browsing through the Twitters when I came across this tweet.

If you don't follow Matt he's definitely worth a follow and in this particular tweet he triggered an idea. He'd deleted once of his old cloud instances which obviously releases the IP address back into the available pool for all users. Someone had then obviously spun up a new server, been assigned that IP and had started a WordPress installation. The problem is that Matt's domain was still resolving to that old IP so it looked like he now had a WordPress site where his site used to be! Even worse, he'd caught it during the setup process and I'm sure could have done hostile things. This got me thinking about the same problem in reverse, what if I spin up a new server and get an IP address that someone else still resolves to?

Gone fishin'

This was easy enough to try out, what with servers being insanely cheap and the ability to grab IP addresses quickly and easily. I use DigitalOcean (referral link) for my servers on my blog, Security Headers, Report URI and everything else I do because they're super cheap and super easy to use. Here are the prices for the Standard Droplets (VPS), which are all we need:

The cheapest server they do is $0.007 per hour, and we don't even need it for that long, we just need to spin it up and see what IP gets assigned. On top of that Digital Ocean also have Floating IPs which allow you to assign additional IP addresses to a server and best of all, you can do that for free.

This means we can quickly and easily spin up a server to get an IP and then add an additional IP to it for no extra cost.

Creating servers

There are a few regions to choose from when creating droplets in DO so I started out with SFO2, assuming it would have the largest churn rate on resources, with the view to expand to other regions later.

You simply choose the cheapest droplet, choose the region and I passed in some User Data which is a script that will run when the droplet is first booted.

apt-get -y  install nginx
wget https://raw.githubusercontent.com/Neilpang/acme.sh/master/acme.sh
chmod +x acme.sh

This would install Nginx, which will need for serving the ACME challenge, and prepare acme.sh for use if we need to get a certificate.

Finding domains that point to our new IP

The next step is to see if there is anything resolving to our new IP address and that requires a quick bit of searching. You could check to see if there is a PTR record set but honestly I wouldn't expect that to be the case. Instead we're going to need a few tools to help us out: SecurityTrails, viewDNS and Shodan.

All of these tools will allow you to search for domains that resolve to the IP address you now have so simply get your IPv4 address, paste it into the tool and see if anything comes back. If it doesn't then you have 2 choices, assign some Floating IPs or destroy the server and create a new one to get a new address.

Obtaining a certificate

If you do have a domain that points to your IP address then obtaining a certificate is as simple as calling acme.sh to issue one.

./acme.sh --issue -d cert-test.scotthelme.co.uk -d example.com -w /var/www/html

You could have the certificate issued for just the domain in question but I figured that wasn't much of a PoC because anyone could have had that issued. I also pointed one of my subdomains to the same IP so that acme.sh could have a certificate issued that contained both domains, proving that they were on the same host. After calling that command, the certificate was issued and you can see them in CT logs.

You can see the certificates listed here by searching for the domain cert-test.scotthelme.co.uk in CT.

Notifying those affected

The scale of this problem is obviously huge, considerably larger than I thought it would be. Whilst I made reasonable efforts to contact all of the hosts I came across during this research, there are most likely many tens of thousands more out there who are in the same position. Do you have any domains or subdomains pointing to IP addresses that you no longer control? Perhaps it's time to go check your DNS configs!

The other problem here is then around what the host could do about this if instead of being a responsible researcher, I were someone hostile and the domain was a high value domain. First of all, they'd need to know something like this had happened, and that's probably the biggest problem. Whilst yes we can use Certificate Transparency to find out about these, just like the search I showed above, the truth is that the vast majority of sites won't be monitoring CT for new certificates. You can monitor CT, check if you're compliant and even find lookalike phishing sites really easily, but you have to go out there and do it.

Let's assume they do that though and they do find out that a certificate has been issued for their site that they don't want, what's the next step? The next step is to have the certificate revoked to prevent it being used. The problem is, well, Revocation is broken. Yes you can get the certificate revoked by demonstrating control of at least 1 domain in the certificate but the actual revocation isn't likely to be that useful given the reasons outlined in that post.

The final piece to worry about there is that an attacker could get a certificate for the maximum allowed validity period if they were looking to use it for bad things. Right now that's a little over 2 years! I got Let's Encrypt certifiactes for the PoC here so they have a very short 90 day validity and I've talked about why we need to reduce certificate lifetime before.


This whole piece of reseach took less than an hour and cost less than $1, writing the blog post took more time and probably cost me more! All of the private keys, certificates and associated servers were destroyed immediately at the conclusion of this research. Given how easy this was I'd say it's worth checking your own zone files to see if you have any domains resolving to IP addresses you no longer control. The certificates issued were issued by Let's Encrypt but they would have been issued by any other CA had I asked as I could demonstrate control of the domains.

I'd also like to point out that this research is by no means original. As is often the case with things like this when you think "woah that's a cool idea" someone else has probably already done it and often, a long time ago. This is no exception and with some quick Google Fu I found a blog from 2015 on Fishing the AWS IP Pool for Dangling Domains which is exactly the same research but on AWS instead.