Detecting and Preventing Subdomain Takeover Vulnerabilities

1. What a Subdomain Takeover Vulnerability Actually Is

A subdomain takeover vulnerability arises when a DNS record, usually a CNAME, points to an external cloud service that no longer exists or is no longer owned by the original operator. As long as the DNS zone keeps that record in place, the subdomain stays technically reachable and simply waits for someone to reclaim the target service. Because many cloud platforms hand out resource names on a first come, first served basis, an attacker can register that exact free name and effectively take control of the subdomain.

What makes this class of vulnerability so insidious is how invisible it stays during normal operation: the main domain remains untouched, its TLS certificate keeps working, and nobody notices anything as long as no user happens to visit the affected subdomain. That very silence is what makes subdomain takeover an attractive target for automated scanners that continuously sweep large volumes of DNS zones for dangling records.

2. The Classic Flow: A Dangling CNAME Pointing to a Decommissioned Service

A typical scenario starts with a marketing campaign: a team sets up a landing page under promo.mironsoft.de using a page builder service and creates a CNAME record pointing at an address the service assigned, for example mironsoft.pagebuilder-app.com. Once the campaign ends, the landing page gets deleted inside the page builder service, but the DNS record in the company's own zone gets forgotten. The target host no longer exists, the CNAME points nowhere, and requests land on the page builder provider's generic error page.

An attacker systematically scanning DNS zones for CNAME records pointing at known cloud services recognizes that generic error page as the fingerprint of an available takeover. They simply register a new project named mironsoft with the same provider, the service then automatically connects the pre-existing DNS record to the attacker's new project, and from that moment on promo.mironsoft.de serves content fully under the attacker's control, under an address that looks entirely trustworthy.

# Identify a suspicious CNAME
dig promo.mironsoft.de CNAME +short
# mironsoft.pagebuilder-app.com.

# Check whether the target host resolves
dig mironsoft.pagebuilder-app.com A +short
# (no answer, or a generic error page on request)

curl -sI https://promo.mironsoft.de | head -n 5
# HTTP/1.1 404 Not Found
# Server: PageBuilderApp
# X-App-Status: no-such-project

3. Which Cloud Services Are Commonly Affected

Static hosting on GitHub Pages, app platforms such as Heroku, object storage like Amazon S3 with static website hosting enabled, Azure App Services, Fastly configurations, and helpdesk or landing page builders all rank among the classic candidates, because they assign project names on a first come, first served basis while also allowing simple CNAME connections to custom domains. Projects such as can-i-take-over-xyz publicly document which error messages, on which provider, signal a resource ripe for takeover.

Not every service is equally vulnerable: some providers now actively check whether a newly registered resource name already has a DNS record pointing at them, blocking the registration in that case or requiring an extra verification step. These safeguards differ considerably between providers and change over time, which means a setup once classified as safe should not be assumed safe indefinitely.

4. The Impact: From Phishing to Cookie Theft

Once an attacker has taken over a subdomain, they can serve arbitrary content there, typically fake login forms for phishing campaigns that feel far more credible thanks to the seemingly legitimate domain than a lookalike address ever could. Users following links from old marketing emails or search engine caches land, without any warning, on a page that visually and address-wise appears to belong to the real brand.

It gets worse when cookies are set without a restrictive domain attribute: a session cookie scoped to the entire mironsoft.de domain remains visible on the taken-over subdomain too and can be read or manipulated from there. If the taken-over subdomain is additionally listed as a trusted source in the main site's Content-Security-Policy, it can even be abused to inject scripts into the actual main site.

5. Systematic Auditing: Checking Every DNS Record Against Active Services

Every audit starts with a complete export of the DNS zone, ideally pulled directly from the DNS provider's management interface or a zone file, rather than relying on an incomplete list maintained from memory. Every single CNAME and ALIAS record then gets resolved and checked for whether the target system genuinely exists and returns a plausible response matching the brand, instead of a generic error page from the cloud provider.

Cross-referencing against a current inventory of all actively used cloud resources matters most. Only when both lists, DNS records and actually existing cloud projects, line up can you reliably rule out a dangling record. This audit should not stay a one-off project but repeat at regular intervals, since new dangling records get created by every marketing campaign, every test server, and every team reorganization.

6. Certificate Transparency Logs as an Additional Discovery Source

Besides a direct DNS export, public Certificate Transparency logs such as crt.sh offer a valuable, independent source for subdomain inventory. Every publicly trusted TLS certificate gets logged there, which surfaces subdomains that internal documentation may have long forgotten but that received a certificate at some point, for a short-lived test server, for example.

Regularly cross-checking subdomains discovered through Certificate Transparency logs against the maintained inventory exposes exactly the gaps a pure DNS export misses, where records exist but are documented nowhere. Some security teams set up automated notifications that fire an alert the moment a new certificate gets issued for an unrecognized subdomain of their own domain.

7. Automated Detection Tools at a Glance

For large DNS zones with hundreds of records, dedicated open source tools relying on a curated fingerprint database of known cloud services are worth the investment for automated dangling record detection. These tools resolve every CNAME, request the target host over HTTP, and compare the response against known error message patterns of each cloud platform, instead of checking every record by hand.

Automated scans do not fully replace a manual audit, since fingerprint databases naturally lag behind new or less common cloud services. A combination works best: automated scans as recurring baseline coverage for known patterns, complemented by periodic manual spot checks on unusual or rarely used records that no fingerprint tool reliably recognizes.

8. The Clean Cleanup Process When Decommissioning a Cloud Service

The most effective protection is organizational, not technical: deleting a DNS record has to be a mandatory step in every deprovisioning process, before or immediately after a cloud resource gets decommissioned, never weeks or months later. The most reliable order reverses the setup sequence: remove the DNS record first, only then delete the cloud resource, so a dead CNAME never points at an already-free resource name at any point in time.

During a planned migration or decommission, temporarily lowering the TTL helps changes take effect quickly and shrinks the window of possible abuse. Teams using infrastructure as code should manage DNS records in the same Terraform or Pulumi module as the associated cloud resource, so deleting the resource automatically removes the DNS record too, instead of maintaining two independent processes that can drift apart.

9. Organizational Measures: Subdomain Inventory and Ownership

Technical measures alone fall short if nobody on the team knows which subdomain exists for what purpose and who owns it. A central, maintained subdomain inventory listing purpose, owning team and underlying cloud service prevents that knowledge from living exclusively in individual employees' heads and disappearing when they leave.

Especially for growing teams and frequent marketing or product campaigns, a mandatory process that automatically registers every new DNS record in this inventory, and explicitly asks about the associated DNS record during every deprovisioning step, pays off. A quarterly review that cross-checks the entire subdomain inventory against the actual DNS zone catches gaps created by informal, undocumented changes.

10. Summary

11. FAQ: Subdomain Takeover: The Essentials at a Glance