Subdomain takeover is one of the most consistently underestimated exposures in enterprise attack surface management, partly because it sounds technical and obscure and partly because it produces no immediate visible symptom. The mechanism is straightforward: an organisation creates a DNS CNAME record pointing a subdomain to a third-party service, the account on that service is closed or the resource is deleted, and the DNS record is not removed. The subdomain now points to an unclaimed resource at the third-party service. Anyone who creates a new account at that service and claims the matching resource now controls what is served at the organisation's subdomain.
The implication is significant. An attacker who identifies a vulnerable subdomain like blog.targetcompany.com that points to an unclaimed GitHub Pages site can create a GitHub account, claim the project name, and serve any content they choose at that URL. From a victim's perspective, they are visiting a page at blog.targetcompany.com, which is the real organisation's domain, with a valid TLS certificate issued by Let's Encrypt for that domain. There is nothing technically suspicious about the URL. The content, which the attacker controls, can be a phishing page, a credential harvesting form, or malware download disguised as a software update from the trusted domain.
The services most frequently exploited in subdomain takeover attacks are those that allow users to publish content to a URL based on their account or project name, and that serve a distinct response when a project is unclaimed rather than returning a generic 404. GitHub Pages is the most documented example: when a GitHub Pages site is configured but the corresponding repository has been deleted, GitHub serves a custom 404 page at the URL rather than refusing the connection. An attacker can create a repository with the right name and push content that GitHub then serves at the organisation's subdomain.
Other services with similar properties include Heroku, Fastly, Azure Cloud Services, AWS Elastic Beanstalk, Netlify, and various other platform-as-a-service providers. Each has its own response pattern for unclaimed subdomains, and security researchers have documented the specific response signatures that indicate a vulnerable subdomain for each major platform. Automated scanning tools like subjack, subzy, and nuclei with subdomain takeover templates can scan large domain portfolios and identify vulnerable subdomains within minutes. These are the same tools that attackers use, and they are freely available.
The attack does not require exploiting any vulnerability in the target organisation's systems. The vulnerability is entirely in the DNS configuration and the lifecycle management of cloud resources. An organisation that properly decommissions cloud resources by removing the corresponding DNS records before closing accounts eliminates the risk. The challenge is that DNS record cleanup is not part of most organisations' standard decommissioning checklists, and the people who remove cloud resources are often different from the people who manage DNS, with no automated process linking the two.
When an attacker successfully takes over a subdomain, one of their first actions is to obtain a TLS certificate for it so that the phishing page they serve does not trigger browser security warnings. Certificate authorities issue certificates to anyone who can demonstrate control over a domain or subdomain, and the most common demonstration method for automated issuance (Let's Encrypt and others using the ACME protocol) is serving a specific challenge token at a well-known URL on the domain. An attacker who controls the content served at a vulnerable subdomain can complete this challenge and obtain a valid certificate.
This certificate issuance step is visible in Certificate Transparency logs, which are maintained as append-only public records of all certificates issued by participating certificate authorities. A certificate issued for blog.targetcompany.com that was not requested by the target organisation appears in the CT log within seconds of issuance. Monitoring CT logs for certificates issued for your organisation's domain space, and flagging any certificate not matching expected issuers or not matching an expected certificate provisioning event, provides an early detection signal for subdomain takeover that appears before any victim traffic has reached the attacker's page.
The effectiveness of subdomain takeover as a phishing vector comes from the trust that users and security systems place in domain names. Users who have learned to check that a URL contains the company's real domain name before entering credentials are specifically targeted by this technique: the domain is real, and the phishing page is served at a real subdomain of the organisation's domain. The certificate is valid and issued for the exact domain shown in the browser's address bar. Email security gateways that evaluate URLs against reputation lists may not flag a link to a subdomain of a known trusted domain. Web proxies that allow access to known corporate domains may not inspect the content served at that domain's subdomains.
Documented subdomain takeover cases include examples where attackers served credential phishing pages at subdomain URLs that were sent to customers as official communication, where malware was distributed from what appeared to be a trusted software update URL on a vendor's domain, and where fraudulent content remained at a vulnerable subdomain for extended periods because no one in the organisation was monitoring for unexpected content at their own subdomains. The monitoring gap is structural: organisations monitor external attacks against their infrastructure but often do not monitor what is being served at their own domain names.
Closing subdomain takeover risk requires three concurrent activities: inventory, monitoring, and process change. Inventory means enumerating all DNS records across all domain names and subdomains the organisation owns, and checking each CNAME record to verify that the resource it points to is still claimed by the organisation. This is a one-time exercise for the known domain space, but it needs to be repeated regularly because new subdomains are added and old ones are forgotten continuously. Tools that query the DNS for all records and then probe each CNAME destination to check for the known unclaimed-resource signatures of major cloud providers can automate this check.
Monitoring means continuous surveillance of CT logs for unexpected certificate issuance and of DNS for new records pointing to third-party services. New CNAME records added to the organisation's domains should trigger a review to verify that the corresponding resource has been claimed and is under organisational control. CT log monitoring catches takeover attempts that are already underway, the moment the attacker obtains a certificate, which is typically within minutes of claiming the resource.
Process change means making DNS cleanup a mandatory step in the resource decommissioning checklist for any cloud service or third-party platform that uses the organisation's domains. This is an operational change rather than a technical one, but it is the permanent solution that prevents the accumulation of vulnerable CNAME records over time. Automated linking between cloud resource termination events and DNS management systems, where the act of deleting a cloud resource that is mapped to a DNS record generates an alert or automatic cleanup, is the mature implementation of this control. External attack surface monitoring that continuously verifies the claim status of DNS records is the detection layer that catches what process controls miss.
Subdomain takeover vulnerabilities have become one of the most commonly reported findings in bug bounty programmes, which has had mixed effects on how organisations perceive and respond to the risk. On the positive side, the bug bounty ecosystem has produced a large volume of public research documenting which cloud providers are susceptible to takeover and what their specific response signatures look like, creating detailed guidance that security teams can use to scan their own infrastructure. On the less positive side, the financial incentive of bug bounties has attracted a community of researchers who scan large numbers of organisations' DNS records using automated tools, which means that any new subdomain takeover vulnerability is likely to be discovered by a bug bounty researcher (or by an attacker using the same tools) within days of the vulnerable DNS record being created.
This discovery timeline dynamic underscores the urgency of the monitoring approach: organisations cannot afford to scan their DNS records quarterly and expect to catch takeover vulnerabilities before researchers or attackers do. The monitoring needs to be continuous and triggered by DNS changes, with alerts generated when new CNAME records are added that point to third-party services, and verification checks run immediately to confirm that the pointed-to resource is claimed by the organisation. Any window of unverified CNAME records, measured in days, is a window during which the vulnerability can be discovered and exploited.
The fundamental challenge with subdomain takeover is that it is an attack against the gap between an organisation's actual asset inventory and its intended asset inventory. An organisation that knows about every subdomain it has ever created, and monitors the DNS records for each one, can detect the conditions that enable subdomain takeover before an attacker exploits them. An organisation that provisions subdomains through a rapid development process without consistent decommissioning procedures will accumulate orphaned DNS records over time, and those records become available for takeover without the organisation being aware of the risk.
Automated subdomain discovery is the starting point for building a subdomain inventory. Tools like Amass, Subfinder, and similar passive DNS reconnaissance tools use certificate transparency logs, DNS brute-forcing, and search engine queries to enumerate subdomains associated with a given domain. Running these tools against your own domain space gives you a picture of what subdomains exist that you may not be tracking in your internal asset inventory. The discrepancy between what these tools find and what your internal inventory tracks represents the potential takeover surface.
DNS record monitoring for NXDOMAIN responses and CNAME chains that resolve to third-party services where the target resource no longer exists is the ongoing monitoring that catches new takeover conditions as they emerge. When a CNAME record points to an Heroku application that has been deleted, or to an S3 bucket that no longer exists, that record starts returning responses from the third-party service's error handling, which may indicate that the subdomain is eligible for takeover through the third-party platform. Monitoring for these conditions needs to run continuously against your full subdomain inventory, not just against a manually maintained list of known assets.
Responsible disclosure programmes and bug bounty programmes frequently surface subdomain takeover vulnerabilities, because security researchers use the same automated tools to discover takeover conditions in public domain space. Organisations with active bug bounty programmes receive reports of their own subdomain takeover vulnerabilities before they are exploited. Organisations without these programmes are dependent on their own monitoring and on the goodwill of researchers who discover the vulnerabilities. Attack surface monitoring that runs continuously against your complete domain and subdomain inventory provides the equivalent of a continuous subdomain takeover vulnerability scan without requiring a public bug bounty programme.
Not all subdomain takeover vulnerabilities carry the same level of risk. The risk depends primarily on what the attacker can do with the subdomain once they have claimed it through the third-party platform. Subdomain takeovers that enable the attacker to serve content under the victim organisation's domain are high risk because users who see that content in their browser will see the organisation's domain in the address bar, which provides a significant trust signal. Subdomain takeovers that enable the attacker to receive email sent to that subdomain are even higher risk because they may allow the attacker to receive authentication emails, password reset links, and other security-critical communications sent to that subdomain.
Takeovers of subdomains that are used for authentication cookies or that are in scope for the organisation's authentication domain are the highest-risk category. If an attacker controls a subdomain in the same TLD as a domain used for session cookie issuance, they may be able to receive authentication cookies sent to that subdomain, depending on the cookie scope configuration. This scenario is rare but represents a significant authentication bypass if it occurs. Security teams conducting subdomain takeover assessments should specifically check whether any subdomain takeover opportunities they identify have authentication domain implications.
Subdomains previously used for development or staging environments represent a common high-risk scenario. A staging subdomain that was used to test a new application may have had authentication flows configured, may have had OAuth redirect URIs registered for it, and may be trusted by the organisation's authentication infrastructure in ways that a pure content-hosting subdomain would not be. When that staging subdomain's hosting is decommissioned but the DNS record persists, an attacker who claims the subdomain through the same hosting provider inherits whatever trust that subdomain had in the organisation's infrastructure.
Thorough subdomain discovery requires multiple techniques used in combination. Certificate transparency logs, available through services like crt.sh, record all TLS certificates issued for a domain and its subdomains. Passive DNS databases aggregate historical resolution records. DNS brute-forcing attempts resolution of dictionary-based subdomain names. Web scraping and search engine queries surface subdomains referenced in the organisation's own content. No single technique covers all subdomains, which is why professional attack surface management tools combine multiple approaches to build the most complete inventory possible.
Subdomain takeover vulnerabilities should be treated as critical-severity findings requiring rapid remediation, typically within 24-48 hours. The reason for urgency is the short window between a CNAME record becoming eligible for takeover and automated scanners finding it. Remediation consists of either removing the orphaned DNS record entirely or recreating the resource on the third-party platform to prevent takeover. Simply updating the CNAME to point elsewhere is not sufficient if the original destination resource still does not exist.
Yes. Beyond hosting phishing pages under a trusted domain, subdomain takeover enables cookie theft through cross-subdomain cookie scope, same-origin bypasses in web applications that treat subdomains of the same TLD as trusted, and mail interception if the subdomain has MX records. In cases where the taken-over subdomain is in scope for an OAuth application's allowed redirect URIs, it can enable OAuth token theft. The specific impact depends on what trust relationships the organisation has established for the affected subdomain.
Bug bounty programmes that include subdomain takeover as an in-scope vulnerability class produce a consistent stream of disclosures that reveal patterns in where these vulnerabilities occur. Public bug bounty reports on platforms like HackerOne and Bugcrowd, where researchers disclose validated subdomain takeover findings with the permission of the programme owner, show that the most commonly discovered subdomain takeover vulnerabilities involve GitHub Pages, Heroku, and Azure-hosted endpoints. These three services are popular for development and staging deployments, and their domain verification processes create consistent vulnerability patterns when hosted content is removed without updating DNS.
GitHub Pages subdomain takeovers follow a specific pattern: an organisation creates a GitHub Pages site at username.github.io or at a custom domain with a CNAME pointing to username.github.io, then the GitHub repository is deleted or the Pages feature is disabled, but the DNS CNAME record pointing to the deleted repository persists. An attacker who creates a GitHub repository with the same username and enables Pages can now serve content under the original domain. This pattern has been reproduced in bug bounty reports against numerous organisations across many sectors.
The lesson from bug bounty subdomain takeover disclosures is that these vulnerabilities are not primarily a result of unusual or sophisticated attack techniques; they result from ordinary decommissioning failures that accumulate over time in any organisation where infrastructure is provisioned faster than decommissioning is tracked. The organisations with the most subdomain takeover vulnerabilities in public bug bounty disclosures are typically not those with poor security cultures, but those with active development programmes that create and decommission infrastructure frequently without consistent DNS cleanup processes.
Subdomain takeover vulnerabilities are also increasingly discovered through certificate transparency log monitoring. When an attacker claims a subdomain through a third-party service, they often provision a TLS certificate for it. Certificate transparency logs, which are public records of all certificates issued by trusted certificate authorities, record this certificate issuance in near-real time. Monitoring certificate transparency logs for certificates issued to your subdomains by unexpected certificate authorities or for unexpected subdomain names you do not recognise in your inventory is an additional detection mechanism that catches takeover events from a different angle than DNS monitoring. Services like Facebook's certificate transparency monitoring tool (crt.sh) make this monitoring accessible without requiring dedicated infrastructure.
Subdomain takeover exposures sit invisibly in your DNS until an attacker finds them. Fake apps impersonating your brand accumulate reviews and installs before your team is alerted. Typosquatting domains go live in minutes and may operate for weeks before discovery. Social media impersonation accounts build follower bases while redirecting customers to fraud. All of these threats are detectable through continuous external monitoring, but only if you are looking in the right places at the right cadence.
Defendis monitors your external footprint continuously: DNS records, new domain registrations, certificate transparency logs, app store listings, and social media profiles that use your brand identity. When something fraudulent appears, you get an alert before your customers are the ones who find it.
Book a demo to see how Defendis monitors brand exposure and external attack surface for your organisation.
