Every domain that has been around for more than a couple of years is carrying dead weight – old campaign pages, decommissioned staging environments, one-off partner integrations – and subdomain squatting is what happens when an attacker notices that dead weight before you do. It is a quiet, patient attack: no phishing email, no malware, just an abandoned DNS record and a few minutes of registration on a cloud provider.
What Subdomain Squatting Actually Means
Subdomain squatting is the practice of an attacker registering or claiming a resource that an old, abandoned subdomain still points to. It is closely related to subdomain takeover, but the framing matters: squatting emphasizes that the attacker isn’t breaking anything technically – they’re just picking up something you left lying around.
This is different from typo-squatting, where an attacker registers a lookalike domain such as yourcompany-support.com. With subdomain squatting, the attacker takes over a real subdomain of your real domain – blog.yourcompany.com, promo2022.yourcompany.com, api-staging.yourcompany.com – because the DNS record is still live and pointing at a service nobody owns anymore.
Why Leftover DNS Records Exist in the First Place
Nobody sets out to leave dangling records behind. They accumulate as a side effect of normal business activity:
A marketing team spins up a campaign page on a hosted platform, points a subdomain at it, and lets it expire on the platform’s side six months after the campaign ends – but never removes the DNS record. A developer creates a quick demo on a cloud storage bucket or a PaaS app, shares the link internally, and then deletes the underlying resource without telling whoever manages DNS. A partnership ends, but the CNAME record set up for the integration stays in the zone file indefinitely because removing it isn’t anyone’s explicit responsibility.
None of these are unusual mistakes. They’re the default outcome of DNS management being decentralized across teams while cleanup is nobody’s job.
How the Actual Takeover Happens
The mechanics are almost boringly simple, which is part of why this attack is so effective. A CNAME record for old.yourcompany.com still points to something like old-yourcompany.herokuapp.com or old-yourcompany.s3.amazonaws.com. The underlying app, bucket, or repository has been deleted or the account has expired, but the DNS record was never cleaned up.
An attacker scanning for these opportunities – often using cheap, automated tools that check thousands of subdomains against known vulnerable service patterns – finds the dangling pointer. They register the same resource name on the same platform. Since DNS still resolves your subdomain to that platform, the attacker’s newly claimed resource now serves content under your domain name. For a deeper technical breakdown of exactly how this resolution chain gets hijacked, see the walkthrough on dangling CNAME records.
From there, the subdomain can host phishing pages that inherit your domain’s trust and TLS certificate, serve malware, or be used to bypass Content Security Policy rules and cookie scoping that assume anything under yourcompany.com is legitimate.
A Myth Worth Retiring
A common assumption is that deleting the cloud resource – shutting down the S3 bucket, deleting the Heroku app, canceling the Azure service – automatically closes the risk. It does not. The DNS record is a separate, independent piece of infrastructure. It has no awareness that the thing it points to no longer exists, and it will happily keep resolving traffic toward that name indefinitely until someone manually removes it.
This is the single most misunderstood part of the whole issue. Decommissioning the service and decommissioning the DNS record are two separate tasks, and skipping the second one is what actually creates the vulnerability.
A Realistic Scenario
A mid-sized company runs a product launch and sets up launch.example.com pointing to a landing page hosted on a third-party site builder. The campaign runs for eight weeks, gets folded into the main site, and the site builder subscription lapses three months later for non-payment.
Nobody remembers that launch.example.com still has a CNAME pointing at that provider. Fourteen months later, someone registers the matching account name on the same platform, and launch.example.com is now serving whatever content they choose – often a convincing phishing page that reuses the company’s branding, since old campaign assets are frequently still cached or scraped from before. Because the domain matches, spam filters and users alike treat it as trustworthy.
Reducing the Risk in Practice
The fix isn’t complicated, but it requires discipline rather than a one-time cleanup. A few practical steps:
Treat DNS record removal as a mandatory step in every service decommissioning checklist, not an afterthought. Whoever shuts down the underlying resource should also be responsible for removing or updating the pointing record, or at minimum filing a ticket to do so.
Maintain a current inventory of every subdomain and what it’s supposed to point to, so anything unexpected stands out immediately. Building and maintaining that kind of list is harder than it sounds once an organization has multiple teams provisioning infrastructure independently – there’s a detailed approach to building a subdomain inventory that actually stays current worth following if this hasn’t been formalized yet.
Periodically audit CNAME and A records against active services, flagging anything pointing to a provider where the account status is unclear. Automated, continuous checking catches this far more reliably than an annual manual review, since the window between decommissioning and exploitation can be as short as a few weeks on popular cloud platforms.
For teams that want the full picture of how these takeovers unfold end to end, including the reconnaissance techniques attackers use to find candidates, the article on how subdomain takeover attacks work covers the attacker’s side of the process in detail.
Frequently Asked Questions
Is subdomain squatting the same as subdomain takeover?
They describe the same underlying vulnerability from slightly different angles. Subdomain takeover usually refers to the technical act of claiming the unclaimed resource; subdomain squatting emphasizes that the attacker is exploiting neglect rather than a software flaw.
Can subdomain squatting happen even if the main domain is well secured?
Yes. The main domain’s security posture – strong passwords, MFA, a locked-down registrar account – has no bearing on individual DNS records for subdomains pointing to third-party services. Each dangling record is its own independent exposure.
How quickly can an abandoned subdomain be claimed?
It varies by platform, but on many cloud services an unclaimed resource name can be re-registered within minutes of becoming available. Some platforms release names for reuse almost immediately after deletion, which is why the gap between decommissioning and cleanup is the actual danger window.
Subdomain squatting isn’t a sophisticated exploit – it’s a maintenance gap turned into an attack surface. The organizations that avoid it aren’t the ones with the most advanced security tooling; they’re the ones that treat DNS record removal as a required step whenever a service goes away, not an optional cleanup task for later.