The Ghost in the Cloud: The Severe Security Risks of Poor DNS Hygiene
- Andy Gravett
- Jul 4
- 4 min read
When we talk about enterprise cloud security, we tend to focus on the flashy perimeter defenses: locking down identity providers, deploying next-gen firewalls, or fine-tuning AI-driven endpoint detection. Yet, one of the most critical vulnerabilities in modern infrastructure is often the most neglected: the Domain Name System (DNS).
DNS is the foundational map of the internet, but in fast-moving cloud environments, that map is frequently left covered in eraser marks. Engineering teams spin up temporary cloud buckets, third-party marketing tools, and staging servers at a blistering pace. But when those campaigns end or infrastructure is torn down, a crucial step is routinely missed: deleting the public DNS records pointing to them.
This oversight—poor DNS hygiene—gives rise to a silent, highly exploitable vulnerability known as dangling DNS.
The anatomy of a subdomain takeover.
To an attacker, a dangling DNS record is an open invitation. By identifying these abandoned connection points, malicious actors can execute a subdomain takeover, inheriting the explicit trust of your corporate domain without ever having to breach your actual network perimeter.
Here is exactly how these takeovers happen, why traditional security tools miss them, and how you can lock down your infrastructure's digital footprint.
## How a Subdomain Takeover Happens
When an organization fails to maintain proper DNS hygiene, they leave an open vector for attackers to orchestrate a subdomain takeover.
(The rest of your original post flows naturally from here...)
How a Subdomain Takeover Happens
When an organization fails to maintain proper DNS hygiene, they leave an open vector for attackers to orchestrate a subdomain takeover.
The Infrastructure Setup: A company sets up a temporary marketing site, a cloud-hosted tool, or an API gateway at promo.company.com. They create a CNAME record pointing it to an external provider, such as an AWS S3 bucket, an Azure App Service, or a GitHub Pages instance (e.g., company-promo.s3.amazonaws.com).
The Decommissioning Oversight: The marketing campaign ends, and the security or engineering team deletes the AWS S3 bucket. However, they forget to delete the CNAME record in their authoritative DNS zone. The record is now dangling.
The Hijack: An attacker scans the company’s public DNS footprint, finds the unresolved CNAME, and realizes the underlying cloud bucket name is available. The attacker registers a new AWS bucket using that exact name (company-promo).
The Exploitation: Because the company’s official DNS still points to that bucket destination, any user visiting promo.company.com is now silently routed to the attacker’s infrastructure.
High-Risk Record Vectors
While CNAME records are the most common culprits, dangling DNS issues span multiple record types, each bringing its own specific attack vectors:
CNAME Records: Points a subdomain to a third-party SaaS or cloud service endpoint that an attacker can easily spin up and claim.
MX (Mail Exchange) Records: Points mail routing to an expired domain or decommissioned mail server. Attackers can register the expired domain, spin up an MX server, and intercept inbound corporate communications.
NS (Name Server) Records: Points a sub-zone delegation to an expired or third-party DNS provider. If an attacker claims that target server, they gain total authority over that entire sub-zone and can mint any record they choose.
TXT (SPF/DKIM) Records: Stale include: mechanisms in SPF records pointing to abandoned domains allow attackers to register those domains and send perfectly authenticated phishing emails (often referred to as SubdoMailing).
Why It Matters: The Blast Radius
An attacker who successfully takes over a dangling subdomain inherits the explicit trust of your primary domain. This opens the door to severe exploits:
Bypassing the Same-Origin Policy (SOP): Because the attacker controls a legitimate subdomain, they can harvest session cookies scoped to *.company.com, giving them a backdoor into user sessions on the main corporate application.
Flawless Phishing and Impersonation: Phishing campaigns originating from trusted-subdomain.company.com easily bypass Secure Email Gateways (SEGs) and fool users, as the domain passes SPF, DKIM, and DMARC checks.
AI Agent Exploitation: Modern autonomous AI agents and agentic browsers rely heavily on DNS and HTTP relationships. If an AI agent scrapes or interacts with a trusted corporate subdomain, it will blindly execute malicious data or code hosted there by an attacker, weaponizing the dangling record into an automated data-exfiltration pipeline.
Prevention and Remediation Strategy
Resolving dangling DNS requires moving away from reactive point-in-time cleanups and embedding lifecycle management directly into infrastructure deployment.
Coupled Lifecycles (Alias Records): Where possible, use cloud-native alias records (such as Azure DNS Alias records or AWS Route 53 Alias records) rather than standard CNAMEs. These track the lifecycle of the target resource and stop routing traffic if the resource is deleted.
Automated DNS Auditing: Implement continuous external attack surface management (EASM) tools or open-source utilities (like Get-DanglingDnsRecords or custom scripts querying passive DNS data) to flags records returning NXDOMAIN or pointing to unallocated cloud spaces.
Decommissioning Guardrails: Ensure your CI/CD pipelines and Terraform/CloudFormation destroy workflows explicitly include steps to tear down the corresponding DNS entries simultaneously with the cloud compute or storage layers.
Tighten Cookie Scoping: Avoid setting overly broad wildcards for sensitive session cookies (.company.com) to limit the blast radius if a subdomain is compromised.
Comments