Subdomain Takeover Explained

Subdomain takeover is when someone else takes control of a subdomain that should belong to you. A subdomain looks like blog.example.com or dev.example.com. When a subdomain points to a service or resource that no longer exists, an attacker can claim that resource and make the subdomain load their content. This lets them serve pages, steal cookies, or run scripts under your domain name.

How this happens

A common way is this. A DNS record points a subdomain to an external service. The service is removed or never set up. The DNS still points there. An attacker finds that unused target. Then the attacker signs up at the service and claims the leftover name. The subdomain starts to show the attacker content.

Sometimes a team creates a temporary site for a campaign and forgets to remove the DNS when the campaign ends. Other times a developer deletes a cloud bucket or an app but forgets the DNS entry. If you do not own the resource anymore and the DNS still points to it, someone else can take it.

Real life example

A marketing team sets up blog.company.com on a hosting service. The campaign ends and the hosting site is deleted. The DNS entry for blog.company.com stays in the company DNS. An attacker sees blog.company.com pointing to the hosting service that no longer has an owner. The attacker signs up on the hosting service and claims blog.company.com. Now the attacker can put a fake login form on blog.company.com and collect user passwords. This is simple but dangerous.

Why this is risky

When an attacker controls a subdomain they can do many bad things. They can serve phishing pages that look real. They can run scripts that steal cookies or tokens. They can put malware behind a trusted name so users click more easily. They can also trick other systems that trust the subdomain into exposing secrets. All of this happens because a link between DNS and a resource was left broken.

Signs a subdomain is vulnerable

Look for these signs when you check domains.
If a DNS record points to an external service that returns a 404 or says the resource is not found, that is a sign.
If many old subdomains point to cloud services that do not respond, those could be taken.
If automated scans show CNAME targets that belong to services like hosting, CDN, or cloud storage but the service says the name is unclaimed, that is a red flag.

What an attacker does step by step

First they scan DNS records and find subdomains that point to third party services. Then they try to access the target and see if the resource is missing. Next they register or claim that resource on the third party platform. After that they host content under your subdomain. Finally they use the subdomain to scam users or to try to access tokens or cookies.

How to find weak subdomains

Run regular scans of your DNS. Check CNAME and ALIAS records. Try to visit each target and see what the service replies. Use simple scripts that check if the target returns an error that suggests it is unclaimed. Ask teams which subdomains are in use before you remove any resources. Keep a list of active owners for each subdomain.

A small human idea here is to treat each subdomain like an asset tag. Give it an owner and an expiry date tied to a project. When the project ends the owner must confirm removal or renewal. This step alone stops many mistakes.

How to stop takeovers

Keep DNS clean. Remove records that you do not use anymore. When you delete cloud resources also remove the DNS entry that pointed to them. Add checks in your release and deprovision process so no DNS record is left behind.

Make a simple rule for all teams. If you create a subdomain, add an owner tag and a date when it must be reviewed. If the owner does not renew, remove the DNS entry. Use automation to list subdomains and to check if targets appear unclaimed. If the scan finds a risky target, send an email to the owner and to the security team.

For public services, require TLS certificates and verify the certificate owner. If a subdomain suddenly serves a new certificate from a different owner, that is a signal to investigate. Use monitoring to watch for new content or new certificates on subdomains.

Limit what subdomains can do. For example, do not allow subdomains to host forms that accept credentials unless they are managed by a central team. This reduces the damage if someone claims a subdomain by mistake.

Quick steps for defenders

List every subdomain and who owns it.

Scan DNS for CNAME and ALIAS entries that point to external platforms.

Check those targets for unclaimed or deleted resources.

Remove DNS entries that are not needed.

Add an ownership tag and review date for each subdomain.

Automate scans and alerts for new or changed DNS targets.

Restrict high risk uses like hosting login pages to trusted systems only.

Use certificate monitoring to spot unexpected certificate issuances.

Small human practices that help

Ask teams to say out loud when a project ends and to confirm DNS cleanup. Do a monthly short meeting where people name subdomains they no longer need. Keep a tiny playbook that any new hire can follow to add or remove a subdomain. These small steps lower the chance of mistakes. Automation catches many issues, but a quick human check prevents edge cases.

Legal and ethical note

Taking over a subdomain that does not belong to you is illegal and wrong. Security researchers should get permission before testing. If you find an unclaimed subdomain that points to your organization report it to your security team. If you are a defender report suspected takeovers to your hosting provider and remove the DNS mapping.