Why are forgotten subdomains a security risk?

Any business that has been online for a few years has left subdomains along the way: staging for testing the website before launch, shop for a seasonal campaign, blog on a platform that was abandoned, survey pointing at a service nobody pays for any more. They did their job, the project ended, and nobody deleted the DNS record.

As long as nobody looks at them, they seem harmless. The trouble is that people do look at them, systematically, and finding them is a good deal easier than it sounds.

How does anyone know which subdomains you have?

The short answer: because you published them yourself, without realising, every time you gave them an HTTPS certificate.

TLS certificates issued by trusted authorities are recorded in Certificate Transparency (CT): public logs that can only be appended to, never edited, where every certificate is noted down along with the names it covers. They were created to catch certificates issued by mistake or fraudulently, and they do that job: if an authority issues a certificate for your domain that you never asked for, it shows up. Since 2018 Chrome has rejected public certificates missing from those logs, so in practice everything with a padlock is in there.

The side effect is that those logs are also a public list of subdomains. Services such as crt.sh index them and let you search by domain: every name that ever had a certificate appears, with the dates of its first and last issuance. Including staging-2019.yourdomain.com, which nobody on your team remembers.

There are two exceptions. Wildcard certificates (*.yourdomain.com) cover any subdomain without naming it, so the specific names they protect do not appear. Nor do subdomains that never had HTTPS.

What is a subdomain takeover?

A subdomain takeover is the most concrete of the risks, and it works like this:

1. You set up a campaign page on an external service: a landing page platform, cloud storage or a static site host.
2. You create a CNAME record so that campaign.yourdomain.com points at that service.
3. The campaign ends and you close the account or delete the resource on the service. But the CNAME stays where it was.
4. Someone notices that your subdomain points at a resource that no longer exists, creates one with the same name on that service and, from then on, controls what appears at campaign.yourdomain.com.

They have not attacked your server or your DNS: they have moved into a gap that was left open. And what they gain is worth having:

• An address on your domain to host a phishing page that the browser will show with a padlock and your name in the address bar.
• Cookies: if your main site sets cookies for the whole domain, the hijacked subdomain may be able to read them.
• Inherited trust: security policies, allowed-origin lists or integrations that trust any *.yourdomain.com.
• Your reputation: if it is used to spread malware, the brand that ends up on dangerous-site lists is yours. What to do in that case is covered in what to do if Google flags your site as dangerous.

Not every service is vulnerable: many now require you to verify domain ownership before accepting it. But the list of those that do not, or did not when the record was created, is long enough for some people to work through it automatically.

Other risks forgotten subdomains leave behind

Takeover is the most striking risk, but not the most common one. The usual problems are more mundane:

• Open test environments. A copy of the website or application with real data, with no password or with a test password half the team knows.
• Unpatched software. An old content management system on old-blog that nobody updates is a way into the server it lives on, which is sometimes the same one as the main site.
• Admin panels exposed to the internet that should sit behind a VPN.
• Duplicate or out-of-date content that search engines keep indexing under your brand.

None of these problems is on your main website, which is the one you check. That is why they go unnoticed.

Building an inventory

A subdomain inventory does not need an expensive tool. It needs a list and someone to keep it up to date:

1. Gather names from two sources: your provider’s full DNS zone (what is configured) and certificate transparency (what was ever published). The two lists rarely match completely, and the differences are exactly what is interesting.
2. For each name, record what it points at (an IP or a CNAME to which service), what it is for, who is responsible and whether it is still in use.
3. Check which ones respond. A name that still resolves but whose service returns a message along the lines of “this site does not exist” or “resource not found” is the prime candidate for a takeover.
4. Flag the ones nobody claims. If nobody knows what it is for, it is probably surplus.

What to clean up first

In order of urgency:

1. CNAME records pointing at external services you have cancelled. Delete them as soon as possible: they are the direct takeover risk.
2. A records pointing at IP addresses that are no longer yours, such as a cloud server that was shut down. The provider can hand that IP to another customer.
3. Test environments reachable from the internet. Put a password or an IP restriction on them, or remove them.
4. Old applications nobody maintains. Migrate what is worth keeping and switch off the rest.

And one rule for the future that prevents almost all of the above: when retiring a service, delete the DNS record first and the resource second. Done the other way round, for however long passes between the two steps, the subdomain points at something that no longer exists. Done in the right order, the worst that can happen is that the subdomain stops responding slightly earlier than planned.

The subdomains you do still use deserve a look at their security headers too: they are often less carefully configured than the main site’s, because they were set up on a different server at a different time.

Finding yours

The subdomain finder searches certificate transparency through crt.sh and returns every name that has had a public certificate, with the first and last issuance dates, whether any certificate is still valid, who issued it and which ones are wildcards. You can filter the list, select up to thirty names to check whether they still resolve in DNS, and download it as a CSV to start your inventory.

Pay particular attention to names whose last certificate expired long ago but which still answer in DNS: they are subdomains someone stopped maintaining without ever deleting.

---

A forgotten subdomain is not dangerous on the day it is created. It becomes dangerous years later, when nobody remembers it exists. Reviewing the inventory once a year is enough to close most of those gaps.