Subdomain Takeover: The Hidden Danger of Forgotten DNS Records

What Is Subdomain Takeover Vulnerability?

Your marketing team once set up a landing page at promo.yourcompany.com using a platform like Unbounce. The campaign was a success, and after it ended, you canceled the Unbounce account. But nobody remembered to remove the DNS record that pointed promo.yourcompany.com to that service. Weeks later, a security researcher informs you that your own subdomain now hosts a phishing page asking for passwords. How is that possible? You never created that page. This is subdomain takeover — a silent threat that turns your domain’s good name into an attacker’s tool.

A subdomain takeover occurs when a DNS record (usually a CNAME) for one of your subdomains continues to point to a cloud service or platform that you no longer control. An attacker spots this orphaned pointer and claims the same service resource, making traffic to your subdomain land on their server. Because the URL still shows yourcompany.com, users trust it as yours.

In technical terms, when you set up a subdomain like myapp.yourdomain.com and configure a CNAME (Canonical Name record, which redirects one hostname to another) pointing to a service-specific hostname like , that pointer stays in place even after you delete the Heroku app. The hostname becomes “dangling.” An attacker can then create a new Heroku app with the same name and, because the DNS record still points there, hijack your subdomain.

Real-World Analogy

Think of it like leaving your name on the mailbox of a house you moved out of. The new resident starts receiving — and opening — your mail. Your domain is your name; the subdomain is the specific mailbox; and the cloud resource (like an S3 bucket) is the house. As long as the mailbox label (the DNS record) remains, anyone who claims the house can act as you.

How Subdomain Takeover Works

Plain English

Here’s the step-by-step sequence, no technical knowledge required. You register a subdomain and tell the internet “When someone types this subdomain, ask that external service what to show.” Later, you stop paying for that external service or delete your account, but you forget to tell the internet to stop pointing there. The slot you vacated on that service becomes available again. An attacker, running scripts that detect such forgotten pointers, quickly grabs that slot and sets up their own content under your subdomain. Now, anyone visiting your subdomain sees whatever the attacker wants them to see — a fake login page, malicious downloads, or even a redirect to a scam site. Because the address bar still shows your trusted domain, victims have no reason to be suspicious. The attacker hasn’t hacked your website or your servers; they’ve simply moved into the empty house your sign was still attached to.

Technical Detail

The following block dives into the mechanics. If you’re troubleshooting or want to understand what your DNS administrator is looking at, this is for you. Everyone else can skip to the next section.

Technical Details

▸Dangling CNAME records are the most common vector. A CNAME like pointing to becomes vulnerable if the S3 bucket named does not exist or is not owned by you.

▸Cloud services that use custom domains are prime targets: AWS S3/CloudFront, Azure Cloud Services (e.g., ), Heroku (), GitHub Pages (), Shopify, and many others.

▸The attack steps: the attacker monitors domain/subdomain combinations or scans DNS, identifies an unresolvable CNAME target, registers the same resource identifier (bucket name, app name, repo name) with the hosting provider, and configures it to serve content.

▸Because the CNAME is still active, traffic passes to the attacker’s resource. The attacker can set cookies scoped to , potentially stealing session tokens if a user is logged into your main domain.

▸Even or records can be vulnerable if they point to an IP address that later gets reassigned by a cloud provider—though this is rarer.

Why It Matters for Your Business

When your DNS records are clean and every subdomain points to a service you actively manage, subdomain takeover is impossible. That’s the ideal. But in reality, the average company accumulates dozens of subdomains over the years — many created by former employees or agencies, often forgotten. If one of those gets hijacked, the consequences go beyond IT.

Attackers can host convincing phishing pages that harvest credentials from your customers or employees. A subdomain like will trick even cautious users. Your email domain’s reputation can suffer if the subdomain is used in spam or phishing campaigns, which might get your entire domain blacklisted. Marketing teams may see their campaign links suddenly redirect to malware; salespeople might unknowingly share compromised links with prospects. Executives face brand damage and potential compliance failures if customer data is exposed. Subdomain takeover is not a theoretical risk — it’s a direct threat to trust, security, and your bottom line.

Common Issues and Warning Signs

Most companies don’t know they have dangling DNS records until something bad happens. TechSpy’s security scan can proactively detect these records before an attacker pounces. Here are the red flags that indicate you might be vulnerable or already compromised:

Common Issues

A subdomain you haven’t used in months suddenly displays a page you didn’t create — often a login form or an error message from a cloud service saying the resource doesn’t exist.

You receive a notice from a platform (like Heroku or AWS) about an account closure or billing issue for a service you thought you deregistered months ago.

Customers report that a link from your company leads to a suspicious site, even though the URL looks like your domain.

Security scanning tools flag a “dangling CNAME” or “potential subdomain takeover” warning for your domain.

In your DNS control panel, you see CNAME records pointing to hostnames you don’t recognize (e.g., ).

How to Fix or Prevent Subdomain Takeover

Fixing this starts with a thorough inventory. If you have direct access to your domain’s DNS settings, follow the steps below. If your IT team or web agency manages DNS, forward this guide to them — it’s a straightforward cleanup.

Once you’ve cleaned up, run a fresh TechSpy scan to verify no dangling records remain. Then, implement a simple policy: whenever you cancel a cloud service, remove its DNS record the same day. With that habit and continuous monitoring, you’ll close the door on subdomain takeover for good.

1Log into your DNS hosting provider (often where you bought your domain, or a service like Cloudflare, Route53). Export a list of all DNS records. Focus on records that point to hostnames outside your domain.

2For each external CNAME target, open that hostname in a browser. If you get an error like “bucket not found,” “app does not exist,” or a provider’s generic landing page, that record is likely dangling and vulnerable.

3Confirm whether you still actively use that service. Check your accounts for the associated platform. If you don’t — or if you’re unsure — delete the DNS record immediately. It’s safer to remove it and recreate later than leave it dangling.

4If you can’t delete it right away (e.g., you need approval), temporarily point the record to a safe, non-routable IP address (like 127.0.0.1) so it cannot be hijacked.

5Set up recurring DNS scans. TechSpy will automatically check your domain for dangling records and alert you the moment one becomes vulnerable, so you can fix it before an attacker notices.