Subdomain takeover happens when a subdomain points to a service you no longer control, letting an attacker claim it and serve content under your domain. It enables phishing, credential theft and brand abuse that looks legitimate because it uses your real name. Continuous attack surface discovery finds these dangling records before an attacker does.
Some security weaknesses announce themselves.
A critical vulnerability generates an alert. A compromised endpoint starts behaving differently. An exposed database appears in a security assessment.
Subdomain takeover is quieter.
The domain continues resolving.
The DNS record remains in place.
Nothing appears obviously broken.
But the service behind the record may no longer exist.
That creates an opportunity for an attacker to claim the abandoned resource and take control of a legitimate subdomain.
From the outside, the result can look completely legitimate because the attacker is operating under your real domain.
This makes subdomain takeover a particularly useful technique for phishing, credential theft, malicious content hosting and brand abuse.
What subdomain takeover is
A subdomain takeover occurs when a subdomain’s Domain Name System (DNS) record points to an external service or resource that is no longer controlled by the organisation, but the DNS record remains active.
A common example involves a CNAME record.
An organisation might create:
portal.example.com
which points to a cloud-hosted application.
Later, the application is decommissioned.
The DNS record remains.
The underlying cloud resource is released.
If the service provider allows another customer to claim that resource, an attacker may be able to associate it with the organisation’s existing subdomain.
The attacker has not compromised the organisation’s DNS infrastructure.
They have exploited the gap between the DNS record and the resource it references.
The OWASP Web Security Testing Guide: Test for Subdomain Takeover describes this as a situation where an external DNS record points to a non-existent or inactive resource that an attacker may subsequently claim.
How subdomain takeover happens
Subdomain takeovers are usually created by ordinary infrastructure changes.
The security problem appears when decommissioning does not clean up DNS.
Decommissioned services
A marketing team launches a campaign microsite.
The campaign ends.
The hosting service is removed.
The DNS record stays.
The organisation considers the project finished.
The DNS record does not.
Expired cloud resources
Cloud platforms make it easy to create and remove resources.
A development team may deploy an application, connect a subdomain to it, and later delete the resource.
If the DNS record remains and the underlying resource can be claimed by another party, the subdomain becomes a candidate for takeover.
Forgotten DNS records
Large organisations accumulate years of infrastructure history.
Acquisitions introduce new domains.
Projects create temporary environments.
Vendors manage services.
Teams change.
People who created the original records may no longer work for the organisation.
The result is DNS that continues pointing towards services nobody actively manages.
What an attacker can do with a taken-over subdomain
The impact depends on the subdomain, its relationship to other systems, and the controls protecting users.
The most obvious use is phishing.
An attacker can host a convincing login page at:
secure.example.com
The domain itself looks legitimate.
An employee may recognise the organisation’s real domain and assume the page is trustworthy.
The attacker can then attempt to collect credentials or direct victims towards another malicious service.
Subdomain takeover can also support:
- Credential theft
- Malware distribution
- Brand abuse
- Malicious content hosting
- Phishing campaigns
- Social engineering
- Cookie theft in certain application configurations
OWASP specifically notes that successful subdomain takeover can enable malicious content, phishing, credential theft and session cookie theft.
The important point is that the attacker gains credibility from the legitimate domain.
That is what makes the weakness valuable.
Why it is easy to miss
Subdomain takeover can sit quietly in DNS for months.
The organisation may not even know the record points to an abandoned resource.
Security teams often focus their attention on:
- Active applications
- Production infrastructure
- Vulnerability findings
- Cloud workloads
- Known domains
DNS records can fall between these systems.
An asset inventory may show the subdomain.
A cloud inventory may show no corresponding resource.
A vulnerability scanner may not flag anything because there is no conventional software vulnerability.
The weakness exists in the relationship between two systems.
That relationship needs to be validated.
Finding dangling records through continuous discovery
The first step is discovering the external DNS footprint.
Organisations need visibility into the subdomains that actually exist, not only those recorded in internal documentation.
Continuous external discovery can identify:
- New subdomains
- Forgotten subdomains
- DNS changes
- External service dependencies
- Cloud-hosted endpoints
- Unexpected DNS records
Once discovered, suspicious records can be validated.
The validation process should establish:
- What does the DNS record point to?
- Does the referenced resource still exist?
- Is the resource still controlled by the organisation?
- Does the external provider recognise the resource as unclaimed?
- Could another party legitimately claim it?
A DNS record pointing to a missing resource is not automatically proof of an exploitable takeover.
Validation is required.
OWASP’s current testing guidance explicitly recommends manual validation because automated checks can produce false positives.
That distinction fits the Attack Insights approach.
Discover first.
Validate second.
Prove the exposure before prioritising it.
Preventing subdomain takeover
Prevention starts with DNS hygiene.
Every organisation should know which external services its DNS records point towards and who owns those services.
When infrastructure is decommissioned, the DNS record should be removed or updated as part of the same process.
That sounds simple.
Large environments make it difficult.
A mature decommissioning process should include:
- Identifying associated DNS records
- Confirming resource ownership
- Removing obsolete records
- Reviewing third-party dependencies
- Documenting exceptions
- Validating the external result after changes
The final step matters.
Deleting a cloud resource does not necessarily mean the DNS record has disappeared.
Security teams should validate the external state after decommissioning.
DNS hygiene needs continuous visibility
Subdomain takeover is fundamentally an external attack surface problem.
The weakness may begin with a cloud resource, but the exploitable condition exists because an internet-facing DNS record continues pointing towards it.
That means security teams need visibility across both sides.
They need to know:
What DNS records exist?
And:
What do those records actually point to?
This is where attack surface management becomes relevant.
Continuous external discovery can help identify changes that internal asset inventories may miss, while validation can confirm whether a dangling record creates an exploitable takeover condition.
Digital Risk Protection adds another layer by monitoring how attackers may abuse legitimate domains once exposure exists. Learn more about digital risk protection and its role in monitoring external brand and identity risks.
The quiet risks deserve attention
Subdomain takeover is not usually a dramatic security event.
There may be no malware.
No stolen credentials at first.
No obvious intrusion.
Instead, there is a DNS record pointing somewhere it should not.
That is enough.
Attackers continuously look for these relationships because they can turn legitimate domains into infrastructure they control.
Security teams should therefore treat DNS as part of the external attack surface rather than as a static networking function.
Discover the records.
Validate the dependencies.
Remove the abandoned resources.
Confirm the DNS state.
Repeat the process continuously.
Request a Demo
A forgotten DNS record can give an attacker a legitimate-looking place to operate.
Request a demo of Attack Insights to see how our attack surface management capabilities continuously discover external assets, validate dangling DNS records, and help your team close quiet attack surface risks before attackers exploit them.
FAQ
What is subdomain takeover?
Subdomain takeover occurs when an attacker claims an external service or resource referenced by a subdomain that the organisation no longer controls. The DNS record remains active, allowing the attacker to serve content through a legitimate-looking subdomain.
Why is subdomain takeover dangerous?
A successful takeover can allow attackers to serve phishing pages, malicious content, or fraudulent resources under a legitimate organisation domain. Depending on the application and configuration, it can also support credential theft, brand abuse, and session-related attacks.
How does subdomain takeover happen?
It commonly occurs when a DNS record continues pointing to a decommissioned, expired, or unclaimed external service. Cloud resources, development environments, campaign sites, and third-party platforms can all create these dangling dependencies when they are removed without updating DNS.
How do you prevent subdomain takeover?
Prevent takeover by removing obsolete DNS records, maintaining clear ownership of external services, including DNS cleanup in decommissioning processes, and continuously monitoring the external attack surface for dangling records that may become exploitable.
