Table of Contents
Overview
A subdomain takeover is a well-known cybersecurity threat that poses serious risks to organizations. It often affects dynamic, fast-moving companies that frequently create and delete resources as part of their operations.
This vulnerability is especially common in cloud environments, though it can also occur in on-premises infrastructure under specific circumstances. In most cases, it happens when a dangling DNS record points to a resource that no longer exists, creating an opportunity for DNS takeover if not properly managed.
How It Works
To understand how a subdomain takeover happens, it helps to look at what’s going on behind the scenes of a domain name system (DNS). When an organization deletes a cloud resource but leaves the corresponding DNS record in place, that record is no longer linked to anything, creating what’s known as a dangling DNS record.
A subdomain takeover occurs when a DNS record points to a cloud resource (for example, an Azure web app) that has been deprovisioned. This issue most commonly appears with CNAME records, which map one domain to another.
Attackers often exploit this vulnerability to redirect legitimate users to malicious sites, such as phishing pages or fraudulent landing pages. However, this is not the only possible outcome. A takeover can also be used for spam campaigns, scams, or hosting disinformation.
There are many tools and methods that can detect this issue, most of which rely on scanning a list of domains and subdomains and testing for the presence of inactive or “dead” DNS entries.
How Hackers Can Detect and Exploit It
To find potential takeover targets, an attacker will perform DNS enumeration of the victim’s infrastructure. This can involve using a dictionary of common subdomains, DNS brute forcing, or harvesting subdomains from web search engines and other OSINT sources. Tools such as dnsrecon are commonly used for this task. Example output:
$ ./dnsrecon.py -d victim.com
[*] Performing General Enumeration of Domain: victim.com ...
[-] DNSSEC is not configured for victim.com
[*] A subdomain.victim.com 192.30.252.153
[*] CNAME subdomain1.victim.com fictitioussubdomain.victim.com
...
(Snippet from OWASP Web Application Security Testing Guide)
There are many tools for discovery and validation. Another popular open-source utility is can-i-take-over-xyz, which helps identify abandoned targets. If an attacker finds a CNAME record, they will probe the target to see whether the referenced resource is inactive. Simple commands like dig and curl are often enough to confirm a dangling DNS entry. If the resource is not available, the vulnerability has been found.
The attacker’s remaining steps are to register or create the corresponding resource and deploy their own content under the targeted subdomain. The exact method depends on the original hosting provider and the attacker’s available resources.
There are also specialized scanning templates and automation for takeover testing. For example, the vulnerability scanner Nuclei includes templates at nuclei-templates/http/takeovers to test for common takeover fingerprints. The good news is that the same enumeration and validation techniques used by attackers can be adopted by security teams to find and fix dangling DNS records before they are abused.
Consequences
Successful exploitation of this vulnerability could lead to several serious consequences:
- Loss of content control. An attacker can publish inappropriate or malicious content on your subdomain, making it look like it came from your company.
- Unauthorized access to visitor cookies. If session cookies are scoped to subdomains, an attacker who controls a subdomain can potentially access those cookies and hijack sessions.
- Phishing and scams. Compromised subdomains are often used for phishing campaigns or scams, which can severely damage your brand reputation.
- Attack escalation. A takeover can be a foothold for more complex attacks, including lateral movement or credential harvesting.
How To Remediate It
If you discover that a subdomain has been taken over, act quickly and follow these steps:
- Remove the DNS record for the affected subdomain. This immediately severs the link between your domain and the attacker-controlled resource.
- Check CDNs and caches. If you use a CDN or any caching layer, purge caches and review CDN settings to ensure the attacker cannot serve content from your domain.
- Rotate credentials and secrets. If the takeover could have exposed any keys, API tokens, or credentials, rotate them and revoke any suspicious access.
- Investigate the scope. Determine how the attacker gained control and whether other DNS records or resources are affected.
How To Prevent It
There are several ways to prevent this vulnerability in your infrastructure, both technical and procedural.
If you use Azure, you can check whether your environment is exposed to subdomain takeover with Microsoft’s PowerShell tool Get-DanglingDnsRecords. It helps identify all domains that have a CNAME pointing to active Azure resources within your subscriptions or tenants.
If your CNAME records are managed outside Azure DNS but still point to Azure resources, you can list those records in an input file for the tool. This applies, for example, if you use Cloudflare to manage external DNS entries.
Azure also provides several built-in tools to help reduce the risk:
- Microsoft Defender for App Service – generates alerts when a custom DNS entry points to a decommissioned App Service.
- Azure DNS Alias records – automatically link DNS records with resources, ensuring the record is deleted when the resource is removed.
However, the best long-term way to prevent subdomain takeover, regardless of your cloud provider (AWS, Azure, GCP, etc.), is to improve your infrastructure lifecycle processes. Establish clear, ordered steps for provisioning and deprovisioning resources:
- When provisioning, set up the virtual host first and create the DNS record afterward.
- When deprovisioning, remove the DNS record first and then delete the virtual host or other hosting resource.
This approach helps avoid situations where a deleted resource leaves behind a dangling DNS record that can be exploited. It is also recommended to regularly audit your DNS configuration to find and remove outdated or unused records.
Conclusion
A subdomain takeover is a serious security risk that occurs when dangling DNS records point to external services that are no longer in use. These unused entries act like open doors for attackers to hijack your subdomain and serve malicious or fraudulent content. The consequences can range from phishing and malware distribution to lasting reputational damage.
To stay protected, organizations should regularly audit DNS configurations, remove unused records, and maintain clear ownership of third-party services. Preventing DNS takeover is not only a technical measure but also a key part of strong asset management and operational hygiene.
2Ops can help you identify and eliminate vulnerabilities in your cloud infrastructure before they become threats. Check out our services and book a free consultation with one of our specialists to make your environment more secure.
