Recommended Free Tools
A subdomain takeover happens when an organization leaves a DNS record pointing to a cloud or third-party service after that resource is no longer under its control—and someone else can claim the abandoned resource. The organization’s hostname can then serve content controlled by an attacker. A stale DNS record is a warning sign, not proof of an exploitable takeover: the backend must also be claimable or otherwise controllable.
What is a subdomain takeover?
A subdomain is a hostname beneath a domain, such as service.example.com. Organizations often point one to a hosted application or other third-party service. If the resource is deleted or released but its DNS record remains, the hostname may still direct visitors toward a backend the organization no longer controls. If an attacker can claim that backend, the organization’s hostname may begin serving attacker-controlled content. Microsoft describes this failure pattern in its Azure-focused guidance; OWASP covers additional DNS record types and conditions in its prevention guidance.
As an Amazon Associate I earn from qualifying purchases.
- An organization provisions a hosted resource and points a subdomain to it.
- The resource is deleted or released, but the DNS pointer remains.
- An attacker finds the stale association and claims the provider-side resource, if that service permits it.
- Traffic to the organization’s hostname can reach content controlled by the attacker.
A dangling CNAME is a familiar example, but the same broad concern can involve other record types. Whether any particular record is exploitable depends on the destination, provider behavior, and configuration.
How can an abandoned subdomain become dangerous?
It can lend a familiar hostname to malicious content
An attacker who controls the destination may use the organization’s subdomain to host phishing pages or other malicious content. Visitors may trust the familiar hostname, and links to it may appear to belong to the organization.
#1 Best Overall
It can affect systems that trust the subdomain
Depending on application design, cookie scope, and security policies, a compromised subdomain may create risks for other parts of the organization’s web presence that trust or share data with subdomains. The impact is configuration-dependent; a takeover does not automatically grant access to every application or account associated with the parent domain.
HTTPS does not establish who controls the site
Microsoft notes that a hijacked subdomain may be able to obtain a valid TLS certificate. HTTPS protects a connection to the hostname, but a certificate does not prove that the organization still controls the hostname’s destination or the content being served.
Which DNS records can be involved?
OWASP describes several possible dangling-record scenarios. They are not equally common or automatically exploitable: the key questions are what destination the record references, whether that destination can be claimed, and what traffic or authority it receives.
| Record type | Potential failure | What determines the risk |
|---|---|---|
| CNAME | A hostname points to a hosted service that has been deprovisioned. | Whether another party can claim the provider-side name or resource. |
| A | A hostname points to an address that has been released. | Whether the address can be reassigned and what service answers there. |
| NS | A delegated DNS zone or account is abandoned. | Whether an attacker can control the delegated DNS authority. |
| MX | Mail routing points to a deprovisioned service. | Whether the mail destination can be claimed and how the organization uses it. |
These cases and their configuration-dependent nature are discussed in the OWASP Subdomain Takeover Prevention Cheat Sheet. A suspicious record should be investigated, not treated as conclusive evidence that an attacker has control.
How can organizations prevent subdomain takeovers?
Make DNS cleanup part of resource decommissioning
When retiring a hosted service, remove its DNS association or repoint the hostname to a resource the organization controls. Microsoft also recommends updating application references and establishing a deprovisioning process that includes DNS cleanup. This lifecycle control applies across providers, even though the specific record and service behavior vary.
Keep DNS and active resources in one reviewable inventory
Maintain an inventory of DNS records and the active resources responsible for answering them. Check that associations still have an owner and a live destination, especially during changes to cloud accounts, applications, and service providers. Inventory and monitoring can help find drift; they do not replace removing records when resources are retired.
Rank #4
Use provider safeguards where they apply
For supported Azure App Service resources, Microsoft documents secure unique default hostnames and domain-verification TXT records such as asuid.{subdomain}. The verification token helps prevent another Azure subscription from validating the custom domain without that token. Microsoft also documents name reservation behavior after deletion, but it should not be treated as a permanent guarantee or assumed to apply to other providers. These protections are service-specific; consult the current Azure App Service prevention guidance for applicable services and configuration.
Free tools Windows power users keep installed
One-click scans. No signup required.
Microsoft also documents dangling-DNS detection through Defender for App Service and an organization-focused PowerShell tool for identifying some Azure-related records. Such tools can support an inventory and cleanup process, but cannot ensure that every unmanaged record is covered.
Best Value
What should you do if you find a dangling or taken-over record?
- Remove or repoint the DNS record. Point it to a resource the organization controls, or remove it if the hostname is no longer needed.
- Investigate possible impact. Determine whether attacker-controlled content was served and whether users, application data, or other systems could have been affected. Microsoft and OWASP both include investigation as part of remediation.
- Fix the decommissioning gap. Identify how the record survived resource retirement and update ownership, inventory, and change procedures so future deprovisioning includes DNS review.
OWASP’s Web Security Testing Guide v4.2 discusses testing for subdomain takeover. Testing should establish whether the provider-side resource is actually claimable; finding a dangling-looking record alone does not demonstrate control of the hostname.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
