Subdomain Takeover: The Hidden Threat in Your DNS Records

What is it?

Subdomain takeover is a security vulnerability that occurs when an attacker gains control of a subdomain of a legitimate domain. This typically happens when a DNS record (most commonly a CNAME record) points to an external service that is no longer in use or has been deprovisioned, but the DNS record itself remains active.

To understand this threat, let's first clarify how CNAME records work. A Canonical Name (CNAME) record is a type of DNS record that maps an alias name to a true or canonical domain name. For example, if you have blog.example.com pointing to myblog.blogprovider.com via a CNAME record, anyone visiting blog.example.com will actually be served content from myblog.blogprovider.com.

The vulnerability arises in this scenario: imagine your company once used blog.example.com and pointed it to a third-party blogging platform. Later, you stopped using that service and deleted your account on the blogging platform, but you forgot to remove the DNS CNAME record. Now blog.example.com still points to myblog.blogprovider.com, but that account no longer exists. An attacker can register myblog.blogprovider.com on the same platform and suddenly gain control of your subdomain.

This is called a "dangling CNAME" because the DNS record hangs in space, pointing to nothing that you control.

Why does it matter?

Subdomain takeovers pose severe security risks that extend far beyond simple website defacement. When an attacker successfully takes over your subdomain, they inherit all the trust and authority associated with your parent domain.

First and foremost, subdomain takeovers enable sophisticated phishing attacks. Users trust subdomains of legitimate organizations. If an attacker controls login.example.com, they can create a convincing fake login page that appears completely legitimate in the browser's address bar. There's no suspicious URL, no typosquatting - it's your actual domain. Users will enter their credentials, believing they're on your legitimate site.

Second, attackers can leverage your subdomain to distribute malware. Email filters and security tools often whitelist subdomains of trusted organizations. An attacker controlling downloads.example.com can host malicious files that bypass many security controls because they're served from your trusted domain.

Third, subdomain takeovers can lead to cookie theft and session hijacking. Many websites set cookies with the Domain attribute set to the parent domain (like .example.com), making those cookies accessible to all subdomains. If an attacker controls any subdomain, they may be able to steal or manipulate these cookies, potentially gaining unauthorized access to user accounts.

Fourth, this vulnerability can severely damage your brand reputation. When users are phished or infected with malware from your subdomain, they blame your organization. Even after remediation, the incident erodes trust that may take years to rebuild.

Finally, subdomain takeovers can impact your SEO and search rankings. Attackers can use your subdomain to host spam content or redirect to malicious sites. Search engines may penalize your entire domain, causing legitimate pages to drop in rankings or be delisted entirely.

How attacks work

Understanding the attack workflow helps organizations prevent subdomain takeovers. The typical attack sequence follows several distinct phases.

Phase 1: Reconnaissance

Attackers begin by enumerating subdomains of target organizations. They use various techniques:

Certificate Transparency logs, which are public repositories of all SSL/TLS certificates issued
DNS enumeration tools like Amass, Subfinder, or Sublist3r
Historical DNS data from services like SecurityTrails or DNSdumpster
Web crawling and scraping search engine results
Analyzing JavaScript files, HTML comments, and public code repositories for hardcoded subdomain references

Phase 2: Identification

Once attackers have a list of subdomains, they test each one to identify dangling CNAMEs. They look for specific error messages that indicate a subdomain is vulnerable:

"There isn't a GitHub Pages site here" (GitHub Pages)
"No such app" (Heroku)
"Project not found" (GitLab Pages)
"Repository not found" (Bitbucket)
"The specified bucket does not exist" (AWS S3)
"404 - Not Found" with specific provider signatures (Azure, Shopify, etc.)

Automated tools like SubOver, subjack, or nuclei can scan hundreds of subdomains per minute to identify these patterns.

Phase 3: Exploitation

When an attacker finds a vulnerable subdomain, they claim the resource on the target platform:

GitHub Pages example: If docs.example.com has a CNAME to example-org.github.io but that repository doesn't exist, an attacker creates a GitHub account, registers the username example-org, creates a repository, enables GitHub Pages, and adds docs.example.com as a custom domain. Now they control the content served at docs.example.com.
AWS S3 example: If assets.example.com points to example-assets.s3.amazonaws.com but that bucket has been deleted, an attacker creates an S3 bucket with that exact name in any AWS region and uploads malicious content. The subdomain now serves the attacker's content.
Heroku example: If staging.example.com has a CNAME to example-staging.herokuapp.com but that app was deprovisioned, an attacker creates a new Heroku app with that name and deploys their own application.

Phase 4: Exploitation

With control of the subdomain, attackers can:

Host phishing pages that collect credentials
Distribute malware disguised as legitimate downloads
Inject cryptocurrency miners
Set up command-and-control infrastructure for botnets
Conduct watering hole attacks targeting your organization's users
Steal cookies and session tokens
Manipulate Single Sign-On (SSO) flows if the subdomain is part of authentication infrastructure

Real-world incidents

Subdomain takeover vulnerabilities have affected numerous high-profile organizations, demonstrating that no one is immune to this threat.

Microsoft (2020)

Security researchers discovered multiple subdomain takeover vulnerabilities across Microsoft's vast infrastructure. One notable case involved subdomains pointing to deprovisioned Azure services. An attacker could have registered these resources and served malicious content from domains like *.microsoft.com, *.azure.com, and *.office.com. Microsoft's bug bounty program paid out significant rewards for these findings and promptly remediated the issues. This incident highlighted how even technology giants with mature security programs can overlook dangling DNS records.

Uber (2017)

Researchers found that several Uber subdomains were vulnerable to takeover. One subdomain pointed to a deprovisioned Heroku app, which could have been claimed by an attacker. Given Uber's position as a critical transportation infrastructure provider handling millions of user accounts and payment information, such a takeover could have led to massive phishing campaigns targeting both drivers and riders.

Starbucks (2019)

Multiple Starbucks subdomains were found vulnerable to takeover, some pointing to unused AWS S3 buckets and others to deprovisioned cloud resources. For a brand with Starbucks' global recognition and customer base, these vulnerabilities posed significant phishing and brand reputation risks.

The UK Government (2018)

Security researchers discovered subdomain takeover vulnerabilities in several UK government domains. These included subdomains of *.gov.uk domains that pointed to decommissioned cloud services. Government domains are particularly attractive targets because they carry inherent trust and authority, making them ideal for sophisticated social engineering attacks.

Shopify (2016)

A security researcher discovered that thousands of Shopify-hosted stores had dangling CNAME records. When store owners closed their Shopify accounts but didn't update their DNS, their domains became vulnerable. An attacker could register a new Shopify store and claim these domains, potentially conducting fraudulent transactions or collecting customer payment information.

These incidents share common themes: organizational complexity, cloud service migrations, decommissioned projects, and inadequate DNS hygiene. They prove that subdomain takeovers are not theoretical vulnerabilities but actively exploited attack vectors.

What Nyambush detects

Nyambush provides comprehensive subdomain takeover detection as a core component of your attack surface monitoring. Here's specifically what our scanner checks for:

DNS Record Analysis

Nyambush examines all DNS records associated with your domain, with particular focus on:

CNAME records pointing to external services
A/AAAA records resolving to cloud provider IP ranges
NS records delegating subdomains to external nameservers

Dangling CNAME Detection

For each CNAME record found, Nyambush performs sophisticated validation:

Resolution Testing: We resolve the CNAME chain to its final destination and verify whether the target resource exists.
Service Fingerprinting: We identify which cloud or SaaS provider the CNAME points to (GitHub Pages, Heroku, AWS S3, Azure, Shopify, Zendesk, AWS CloudFront, Fastly, etc.).
Error Pattern Matching: We fetch the content served at each subdomain and analyze HTTP status codes, response headers, and page content for provider-specific error messages that indicate vulnerability.
Vulnerability Confirmation: When we detect patterns indicating a subdomain may be vulnerable, we perform additional validation checks to minimize false positives.

Subdomain Enumeration

Beyond analyzing known DNS records, Nyambush actively discovers subdomains you may not be aware of through:

Certificate Transparency log monitoring
Common subdomain pattern testing
Historical DNS data analysis

This is crucial because the most dangerous subdomain takeovers often involve forgotten or undocumented subdomains that security teams don't know exist.

Continuous Monitoring

For Nyambush Pro and Business subscribers, we continuously monitor your domain for new subdomain takeover risks:

Alert you immediately when new dangling CNAMEs are detected
Track DNS changes over time
Monitor for subdomains that transition from valid to vulnerable states
Revalidate previously detected issues after remediation

Detailed Reporting

When we detect potential subdomain takeover vulnerabilities, our reports include:

The specific subdomain at risk
The CNAME target and provider identified
The error pattern or response indicating vulnerability
Risk severity assessment
Step-by-step remediation guidance
AI-powered analysis explaining the specific risk in context of your infrastructure

How to fix it

Remediation of subdomain takeover vulnerabilities requires both immediate response and long-term preventive measures.

Immediate Remediation Steps

When you discover a dangling CNAME, take these steps immediately:

Verify the vulnerability: Confirm that the subdomain truly points to a resource you no longer control. Test by visiting the subdomain and checking DNS records:

# Check CNAME record
dig subdomain.example.com CNAME

# Check what the CNAME resolves to
dig subdomain.example.com

Assess the risk: Determine whether the subdomain is still referenced anywhere:
- Search your codebase for hardcoded references
- Check documentation and internal wikis
- Review SSL certificates that might include the subdomain
- Examine authentication and SSO configurations
Choose remediation approach:

Option A: Remove the DNS record (recommended if subdomain is no longer needed)

Update your DNS zone file or DNS provider settings to completely remove the CNAME record. This is the safest option because it eliminates the attack surface entirely.

For popular DNS providers:

Cloudflare:

Navigate to DNS settings
Find the CNAME record
Click delete
Changes propagate within minutes

Route53 (AWS):

# Using AWS CLI
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890ABC \
  --change-batch '{
    "Changes": [{
      "Action": "DELETE",
      "ResourceRecordSet": {
        "Name": "blog.example.com",
        "Type": "CNAME",
        "TTL": 300,
        "ResourceRecords": [{"Value": "old-blog.platform.com"}]
      }
    }]
  }'

Option B: Reclaim the resource (if you need to keep the subdomain active)

If the subdomain must remain functional, reclaim the resource on the target platform:

GitHub Pages:

Create a repository with the required name
Enable GitHub Pages in repository settings
Add your subdomain as a custom domain
Verify ownership via DNS TXT record

AWS S3:

Create an S3 bucket with the exact name
Enable static website hosting
Upload appropriate content
Configure bucket policy for public access

Heroku:

Create a new Heroku app with the required name
Deploy your application
Add custom domain in Heroku dashboard
Verify DNS configuration

Option C: Point to a safe placeholder

As an intermediate measure, update the CNAME to point to a resource you control:

# Update CNAME to point to your main site or a placeholder
blog.example.com. 300 IN CNAME www.example.com.

Long-term Prevention Strategies

Preventing future subdomain takeover vulnerabilities requires process and technical controls:

DNS Inventory Management

Maintain a comprehensive inventory of all DNS records:

{
  "subdomain": "blog.example.com",
  "type": "CNAME",
  "target": "example.platform.com",
  "purpose": "Company blog",
  "owner": "Marketing Team",
  "created": "2024-01-15",
  "last_verified": "2024-02-11"
}

Decommissioning Checklist

Create a formal process for decommissioning services:

[ ] Identify all DNS records associated with the service
[ ] Document dependencies and integrations
[ ] Update or remove DNS records
[ ] Verify subdomain no longer resolves after DNS propagation
[ ] Remove from SSL certificates
[ ] Update documentation and code repositories
[ ] Schedule follow-up verification in 30 days

Implement DNS Monitoring

Use tools like Nyambush to continuously monitor your DNS:

Automated daily scans of all DNS records
Alerts for newly detected dangling CNAMEs
Regular subdomain enumeration to discover forgotten subdomains
Integration with your security operations workflow

Adopt Infrastructure-as-Code

Manage DNS records through code with version control:

# Example Terraform configuration
resource "cloudflare_record" "blog" {
  zone_id = var.cloudflare_zone_id
  name    = "blog"
  type    = "CNAME"
  value   = "example-blog.ghost.io"
  ttl     = 300

  # Add metadata for tracking
  comment = "Company blog - owned by [email protected]"
}

This approach provides audit trails, prevents unauthorized changes, and makes DNS inventory management straightforward.

Claim Defensive Registrations

For critical services, defensively register resources even before DNS is configured:

Register GitHub organization/username matching your domain
Claim potential bucket names on cloud platforms
Pre-register application names on PaaS providers

Use CAA Records

Certificate Authority Authorization (CAA) DNS records specify which certificate authorities can issue certificates for your domain:

example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild "letsencrypt.org"

While CAA records don't prevent subdomain takeover, they make it harder for attackers to obtain valid SSL certificates for your subdomains, reducing the effectiveness of phishing attacks.

Summary

Subdomain takeover represents a critical yet often overlooked attack vector that affects organizations of all sizes. When DNS records point to deprovisioned external resources, attackers can claim those resources and gain control of your subdomains, leading to phishing attacks, malware distribution, brand damage, and potential data breaches.

The vulnerability stems from a simple oversight: deleting a cloud service or external resource while forgetting to remove or update the corresponding DNS records. However, the consequences can be severe. Attackers leverage the inherent trust in your domain to conduct highly convincing social engineering attacks, bypass security controls, and steal sensitive information.

Real-world incidents affecting organizations like Microsoft, Uber, and government agencies prove that subdomain takeover is not a theoretical risk but an actively exploited vulnerability. The attack workflow is well understood, tools for identifying vulnerable subdomains are readily available, and attackers continuously scan for opportunities.

Prevention requires a combination of immediate remediation and long-term process improvements. When vulnerable subdomains are discovered, they must be addressed immediately by removing DNS records, reclaiming resources, or pointing to safe destinations. Long-term prevention involves maintaining comprehensive DNS inventories, implementing formal decommissioning processes, continuous monitoring, infrastructure-as-code practices, and defensive resource registration.

Nyambush automates the critical but labor-intensive work of subdomain enumeration, dangling CNAME detection, and continuous monitoring. By identifying vulnerabilities before attackers do, Nyambush gives you the opportunity to remediate risks and protect your organization's attack surface. Regular scanning and monitoring transform subdomain takeover from a hidden threat into a manageable, preventable security issue.

Don't let forgotten DNS records become your next security incident. Stay vigilant, maintain clean DNS hygiene, and leverage automated monitoring to protect your domain's integrity and your users' trust.