MSPs
What is a subdomain takeover and could it happen to me?
Rodney Hall, COO— AI-assisted and reviewed prior to publication.
A subdomain takeover happens when a CNAME record in your DNS points to a cloud service you canceled, but the record still exists. An attacker registers the same resource name on that provider, inherits your subdomain, and serves content under your domain.
How dangling DNS records create the vulnerability
A subdomain takeover occurs when a DNS record points to a deprovisioned Azure resource, creating what's known as a "dangling DNS" entry (learn.microsoft.com). The most common case is a CNAME record that points to a third-party service after the service contract expires (bluevoyant.com).
Subdomain takeover is most common on platforms that allow users to claim named resources, including AWS S3, GitHub Pages, Heroku, Fastly, Azure, Shopify, and Zendesk (censys.com). When you spin up an Azure App Service at yourapp.azurewebsites.net and point marketing.client.com to it via CNAME, the record remains live even after you delete the App Service. Google Cloud Storage bucket names are globally unique and can be reclaimed after deletion, creating the same risk for GCS-backed subdomains.
The vulnerability window opens the moment the cloud resource is deleted. AWS CIRT has observed threat actors actively scanning for public DNS CNAME records that point to resources that no longer exist (aws.amazon.com).
How do attackers claim your subdomain?
A subdomain takeover attack typically begins with reconnaissance, with persistent attackers setting up automated monitoring and waiting for DNS configurations to change or signs of abandonment (crowdstrike.com). Once a dangling CNAME is identified, the attacker registers the resource your DNS points to.
For an S3 bucket, that means creating a new bucket with the exact name your CNAME targets. For Azure App Service, it means claiming the now-available azurewebsites.net hostname. Attackers can then register the same service or a similar one to take control of the subdomain (valimail.com). The DNS resolves correctly, traffic flows to the attacker's resource, and phishers can leverage the reputation of the legitimate domain name to elicit sensitive information from victims.
In 2020, security researchers identified over 670 Microsoft subdomains vulnerable to takeover due to misconfigured DNS entries pointing to unclaimed Azure services. In 2016, Uber experienced a subdomain takeover exposing sensitive information about drivers and passengers, caused by an unclaimed AWS S3 bucket.
What makes this especially dangerous for MSPs?
You manage DNS for dozens or hundreds of clients. You cannot protect subdomains you have forgotten exist, and the inventory is exactly what organizations are worst at maintaining. A client migrates from one email provider to another, marketing spins up a campaign microsite on Netlify for three weeks, a developer tests a staging environment on Heroku. Each creates a CNAME. Not all of them get deleted when the project ends.
When websites configure cookies with a domain attribute of .example.com or .example.com, these cookies automatically become available to all subdomains, including a taken-over one. When developers configure authentication flows to allow redirects to any subdomain of the primary domain, attackers can exploit subdomain takeovers to grab session tokens, since OAuth/SSO flows typically return tokens as URL parameters or fragments.
A single forgotten staging.client.com pointing to a deleted Azure resource can become a phishing page that collects credentials, serves malware, or intercepts session cookies. The domain is real, the TLS certificate (via Let's Encrypt) is valid, and your client's brand is attached.
The inventory that prevents it
Remove DNS records when decommissioning services, maintain an inventory of subdomain-to-service mappings, and enforce a change management process that ties service cancellation to DNS cleanup, with an accurate inventory of all CNAME targets as the foundation.
Start with a complete subdomain list. Pull from your authoritative DNS plus Certificate Transparency logs, resolve each record, and run a fingerprint scanner like subjack or nuclei's takeover templates. Many cloud DNS providers such as Google Cloud DNS, Cloudflare, AWS Route 53, and Azure DNS allow zone file exports or API-based inventory.
For each external CNAME, document who owns it, which cloud resource it points to, and when it was created. Store business purpose, owner, environment, target resource, provider, creation date and planned retirement, managing DNS and cloud resources in the same infrastructure-as-code workflow where possible. Infrastructure-as-Code tools like Terraform, Pulumi, or AWS CDK can serve as a living inventory when DNS records and cloud resources are managed in the same codebase.
DNS should be audited continuously, since new dangling entries can appear any time a cloud resource is decommissioned, with a full audit at minimum quarterly and a DNS review in any cloud resource offboarding checklist. The free AI-visibility check (/check) includes DNS health signals for SPF, DMARC, and DKIM, but subdomain takeover requires dedicated CNAME validation against your cloud asset inventory.
What to do right now
The common mistake is deleting the cloud resource first, which creates an immediate window for takeover that persists until someone notices the dangling record. Start provisioning by claiming the virtual host and creating DNS records last, then start deprovisioning by removing DNS records first.
Build a runbook. When a client cancels an Azure App Service, AWS S3 bucket, or Heroku app, the first step is to delete or update the CNAME. Deprovisioning runbooks must include DNS cleanup as a required step, with service templates that enforce one-click teardown removing both app resources and DNS records. Automate routine DNS audits, since dangling records can appear every time an engineering team decommissions a cloud workload.
Monitor certificate transparency logs because unexpected certificates for your subdomains can signal a recent takeover. If you spot a certificate you didn't request, investigate immediately. Tools exist (OWASP's prevention guide lists several), but the real fix is operational.
Subdomain takeover is a DNS lifecycle failure. The vulnerability is simple, the exploitation is trivial, and the fix is procedural. ActiScore's pricing (/pricing) includes DNS security scoring across SPF, DMARC, DKIM, and TLS on every plan, but protecting against takeover specifically requires you to maintain one authoritative list of what you have exposed and delete the DNS record before you delete the service. If you manage DNS for clients and cannot name every CNAME pointing to an external provider right now, you have exposure. The guide (/guide) covers DNS fundamentals, but the urgent action here is to export your zone files, enumerate every external CNAME, and cross-check them against active cloud resources today.
Common questions
What is a subdomain takeover?
A subdomain takeover occurs when a CNAME record in your DNS points to a cloud service you canceled, but the DNS record still exists. An attacker registers the same resource name on that provider, inherits your subdomain, and serves content under your domain. The DNS resolves correctly, traffic flows to the attacker's resource, and they can leverage your domain's reputation for phishing or malware distribution.
Which cloud services are most vulnerable to subdomain takeover?
Subdomain takeover is most common on platforms that allow users to claim named resources, including AWS S3, GitHub Pages, Heroku, Fastly, Azure, Shopify, and Zendesk. Google Cloud Storage bucket names are globally unique and can be reclaimed after deletion, creating the same risk. Azure App Services and any platform with user-claimable hostnames present this vulnerability when DNS records outlive the actual cloud resource.
How do attackers find and exploit dangling DNS records?
Attackers typically begin with reconnaissance, scanning for public DNS CNAME records that point to resources that no longer exist. AWS CIRT has observed threat actors actively monitoring for these conditions. Once a dangling CNAME is identified, the attacker simply registers the resource your DNS points to—creating a new S3 bucket with the exact name, or claiming the now-available azurewebsites.net hostname your CNAME targets.
Why are subdomain takeovers especially dangerous for MSPs?
MSPs manage DNS for dozens or hundreds of clients, creating many opportunities for forgotten CNAME records when clients migrate services, run temporary campaigns, or test staging environments. Each creates a CNAME that may not get deleted when the project ends. A single forgotten subdomain pointing to a deleted cloud resource can become a phishing page with a valid TLS certificate, exploiting your client's brand reputation and potentially intercepting session cookies or OAuth tokens configured at the parent domain level.
What is the correct order for preventing subdomain takeover?
When provisioning, claim the cloud resource first and create DNS records last. When deprovisioning, reverse the order: delete or update the CNAME first, then delete the cloud service. Deleting the cloud resource before removing DNS creates an immediate takeover window. Deprovisioning runbooks must include DNS cleanup as a required first step, ideally automated through infrastructure-as-code tools that manage DNS records and cloud resources together in the same workflow.