Somewhere in your DNS, there's probably a record pointing to something that no longer exists. A CNAME for a staging environment you decommissioned six months ago. An A record for a cloud instance that was deleted after a project ended. An MX record for an email service you stopped using when you switched providers.
These forgotten records are called dangling DNS, and they're one of the most exploited attack surfaces in modern infrastructure. When a DNS record points to a resource that no longer exists, an attacker can claim that resource and serve whatever content they want under your domain name. The result is a subdomain takeover: your brand, your reputation, and your users' trust, all hijacked through a record nobody remembered to delete.
This isn't a theoretical risk. In a research investigation from October 2024 to January 2025, SentinelOne researchers acquired approximately 150 deleted AWS S3 buckets that were still referenced by DNS records belonging to government agencies, Fortune 500 companies, and major open-source projects. Within four months, over 8 million HTTP requests were directed to these compromised subdomains, including requests for container images, software updates, and deployment artifacts. In February 2025, Infoblox identified a threat actor called Hazy Hawk actively hijacking dangling DNS records at organizations including the CDC, Deloitte, PwC, and Ernst & Young.
The attack is simple, the impact is severe, and the fix starts with knowing what's in your DNS.
What Is Dangling DNS?
A dangling DNS record is any DNS record that points to a resource that no longer exists or is no longer under your control. The most common scenario involves CNAME records, but A records, MX records, and NS records can all dangle.
Here's how it typically happens:
- Your team spins up a cloud service: an S3 bucket, an Azure App Service, a Heroku app, a GitHub Pages site, or a CloudFront distribution
- A DNS record is created to point a subdomain to that service:
staging.yourcompany.com CNAME staging-app.herokuapp.com - The project ends, the service is decommissioned, the cloud resource is deleted
- Nobody remembers to delete the DNS record
- The CNAME still points to
staging-app.herokuapp.com, but that Heroku app no longer exists - An attacker creates a new Heroku app with the name
staging-app, claiming the endpoint - Traffic to
staging.yourcompany.comnow serves content from the attacker's Heroku app
From the perspective of anyone visiting staging.yourcompany.com, the content appears to come from your organization. The URL shows your domain. The browser doesn't flag anything. If the attacker provisions a TLS certificate (which many cloud platforms do automatically), the connection even shows the padlock icon.
It's Not Just CNAME Records
While CNAME-based takeovers are the most common, other record types can dangle too:
- A records pointing to released cloud IP addresses. When you delete a cloud instance, the IP is returned to the provider's pool. If someone else gets assigned that IP and you still have an A record pointing to it, your subdomain now resolves to their infrastructure.
- MX records pointing to decommissioned mail services. An attacker who claims the endpoint can receive all email sent to that subdomain, including password reset links and internal communications.
- NS records delegating a subdomain to nameservers you no longer control. This is the most dangerous form: the attacker controls DNS resolution for the entire subdomain zone, meaning they can create any record type and serve any content.
What Attackers Do With Taken-Over Subdomains
A subdomain takeover gives the attacker a platform that inherits your domain's reputation. They can:
Host Phishing Pages
A login page on accounts.yourcompany.com looks completely legitimate. Employees, customers, and partners who receive a link to that subdomain have no reason to suspect it's compromised. The attacker harvests credentials under the cover of your trusted brand.
Bypass Email Security
If the taken-over subdomain has SPF authorization (or is covered by a wildcard SPF policy), the attacker can send phishing emails that pass SPF checks. Email from billing.yourcompany.com looks legitimate to both automated security tools and human recipients.
Distribute Malware
A compromised subdomain can host malicious downloads. If the subdomain previously served legitimate software (update servers, asset distribution, installer downloads), existing clients may automatically fetch payloads from the compromised endpoint.
Compromise Supply Chains
The SentinelOne research demonstrated this vividly. Taken-over S3 buckets received requests for container images, precompiled binaries, and software update manifests. If attackers had served malicious versions of these artifacts, they could have compromised build pipelines and production deployments at scale.
Steal Cookies and Session Tokens
If the taken-over subdomain is on the same parent domain as your application, cookies scoped to .yourcompany.com are sent to the attacker's server. This can include session tokens, authentication cookies, and CSRF tokens.
Why This Keeps Happening
Dangling DNS is fundamentally a process problem, not a technology problem. It persists because:
No Single Owner
In most organizations, DNS records are created by multiple teams: engineering, marketing, IT, DevOps, security. The person who created a record for a staging environment may have left the company years ago. Nobody else knows the record exists or what it was for.
Cloud Resources Are Ephemeral
Modern infrastructure is built to be created and destroyed quickly. Teams spin up cloud resources for testing, demos, and temporary projects, then delete them when they're done. The DNS record, which lives in a completely separate system, is easily forgotten.
No Automated Cleanup
Most DNS providers have no mechanism to detect that a record's target no longer exists. The record will point to a dead endpoint forever unless someone manually removes it. Unlike cloud resources that incur costs when running (creating natural pressure to clean up), DNS records are essentially free to maintain and invisible when unused.
Audit Complexity at Scale
An organization with 50 domains and 20 subdomains each has 1,000 potential dangling records to audit. Multiply that across acquisitions, regional subsidiaries, and legacy infrastructure, and manual auditing becomes impractical. SentinelOne flagged over 1,250 subdomain takeover risks for its clients in 2024 alone.
Real-World Incidents
Subdomain takeovers aren't hypothetical. They've hit some of the largest and most security-conscious organizations in the world:
Microsoft (2020): Security researchers identified over 670 Microsoft subdomains vulnerable to takeover due to CNAME records pointing to unclaimed Azure services. Affected subdomains included identityhelp.microsoft.com and data.teams.microsoft.com.
Government and Fortune 500 (2024-2025): The SentinelOne investigation found 150 abandoned S3 buckets still referenced by DNS records from government agencies and Fortune 500 companies, receiving over 8 million requests for sensitive artifacts including software updates and deployment configurations.
Hazy Hawk Campaign (2025): Infoblox tracked a threat actor called Hazy Hawk systematically hijacking dangling DNS records at the CDC, Deloitte, PwC, and Ernst & Young, exploiting abandoned cloud resources tied to government and enterprise targets.
If it can happen to Microsoft, the CDC, and the Big Four accounting firms, it can happen to any organization.
How DNS Assistant Detects Dangling Records
DNS Assistant includes automated dangling DNS detection as a core feature of the platform. Here's how it works:
Cloud Provider Fingerprint Scanning
DNS Assistant checks CNAME and A records against known fingerprints for 22+ cloud providers including AWS (S3, CloudFront, Elastic Beanstalk), Azure (App Service, Blob Storage, Traffic Manager, CDN), Google Cloud, Heroku, GitHub Pages, Netlify, Pantheon, Fastly, Shopify, Zendesk, and more. When a record points to a cloud service that returns a "resource not found" or "no such bucket" response, DNS Assistant flags it as a dangling record at risk of takeover.
Continuous Monitoring
Dangling DNS isn't a one-time audit. New records are created regularly, and existing services are decommissioned without warning. DNS Assistant runs dangling checks on every monitoring cycle, catching newly orphaned records as they appear, not weeks or months later during a manual review.
Alert Integration
When a dangling record is detected, DNS Assistant sends alerts through your configured channels: email, Slack, Microsoft Teams, webhooks, or SMS. The alert includes the specific record, the cloud provider, and the fingerprint that triggered the detection, giving your team the information they need to remediate immediately.
Full Record Inventory
You can't fix what you can't see. DNS Assistant maintains a complete inventory of all DNS records across your monitored domains: A, AAAA, CNAME, MX, NS, TXT, SOA, CAA, and SRV. This inventory is the foundation for identifying records that point to infrastructure you no longer control.
How to Prevent Subdomain Takeovers
1. Audit Your DNS Records
Start with a complete inventory. Use the DNS lookup tool at dnsassistant.com/tools to query your known subdomains and check what their CNAME or A records point to. If a record points to a service you no longer use, delete it. For a broader view of your DNS and email authentication configuration, run a Free Domain Risk Report.
2. Delete DNS Records When You Decommission Services
Build DNS cleanup into your decommissioning process. Whenever a cloud resource, SaaS integration, or hosting service is removed, the corresponding DNS record must be deleted at the same time. This should be a checklist item, not an afterthought.
3. Use Dedicated Subdomains Instead of Wildcards
Wildcard DNS records (*.yourcompany.com) make dangling DNS harder to detect and increase the blast radius of a takeover. Use explicit subdomain records instead, so you know exactly what each record is for and can track them individually.
4. Monitor Continuously
Manual audits find problems that exist today. Continuous monitoring finds problems as they appear. DNS Assistant checks for dangling records on every monitoring cycle, catching orphaned CNAME records within hours of the target service being decommissioned.
5. Restrict Who Can Create DNS Records
Limit DNS record creation to a small team or require approval workflows. The more people who can create records, the more likely records are created without documentation and forgotten when the associated service is removed. DNS Assistant's multi-tenant RBAC (role-based access control) helps organizations manage who has visibility and control over DNS configurations.
6. Use CAA Records
CAA records restrict which Certificate Authorities can issue certificates for your domain. Even if an attacker takes over a subdomain, CAA records can prevent them from obtaining a trusted TLS certificate, reducing the effectiveness of the takeover.
The Bigger Picture
Dangling DNS is the result of a fundamental disconnect in modern infrastructure management: cloud resources are managed in one system, DNS records are managed in another, and there's no automatic link between them. When one side changes, the other doesn't know.
This disconnect gets worse over time. Every new project, every SaaS trial, every temporary environment adds DNS records. Some get cleaned up. Many don't. The number of potential dangling records grows monotonically, and without automated detection, the risk compounds silently.
The organizations that avoid subdomain takeovers aren't the ones with perfect processes. They're the ones with visibility: they know what's in their DNS, they know when it changes, and they know when a record starts pointing to something that no longer exists.
DNS Assistant provides that visibility across your entire domain portfolio.
Start with a free scan: Use the DNS lookup tool to check your subdomains, or run a Free Domain Risk Report for a comprehensive view of your DNS health. For continuous dangling DNS detection with real-time alerting, sign up at dnsassistant.com.
Start Monitoring Your DNS Today
Get real-time alerts, track record changes, and keep your domains secure with DNS Assistant.
Sign Up Free