Subdomain takeover is a serious risk for organizations with a large online presence (which is a lot of businesses in 2025!). A domain name is the starting point of your company’s online identity, encompassing the main and subsidiary websites—serving as the organization’s business card, storefront, and a central hub for commercial activities. For SaaS providers and tech solution vendors, domains also form a critical component of their product offerings. 

So the last thing you want is for a bad actor to fraudulently operate under one of your subdomains without your knowledge. This article explores subdomain takeover risk and outlines practical solutions for reducing the risk of subdomain takeover, including external attack surface management (EASM) as a useful tool for mitigation.

How does subdomain takeover work?

A subdomain takeover attack occurs when an attacker takes control of a subdomain that should be under the control of the original domain owner. Here’s how it typically works:

1. Identify unused subdomains: The attacker starts by scanning the target domain for subdomains that are no longer in use or are misconfigured. Tools like sublist3r, amass, or subfinder can help in this process.
2. Check DNS records: The attacker then checks the DNS records of these subdomains to see if they are pointing to a valid service or if they are misconfigured. Misconfigurations can include CNAME records pointing to a service that no longer exists or has been deleted.
3. Exploit misconfigurations: If a subdomain is found to be pointing to a service that no longer exists, the attacker can take advantage of this. For example, if a subdomain is set to point to a cloud service (like an AWS S3 bucket) that has been deleted, the DNS record will still point to the cloud service’s domain.
4. Claim the subdomain: The attacker can then create a new resource on the cloud service (e.g., a new S3 bucket) with the same name as the original resource. Since the DNS record still points to the cloud service, the subdomain will now point to the attacker’s resource.
5. Control the subdomain: Once the attacker has control of the subdomain, they can use it for various malicious purposes, such as hosting phishing pages, serving malware, or redirecting traffic to malicious sites.
6. Maintain control: The attacker can maintain control of the subdomain until the domain owner corrects the DNS records or takes other remedial actions.

Consider the following scenario: a bank unintentionally leaves a subdomain associated with a past promotional event vulnerable. An attacker exploits this oversight to create a fraudulent page resembling the bank’s login portal. Unsuspecting customers, trusting the authentic-looking URL, enter their credentials, inadvertently granting the attacker access to thousands of bank accounts and sensitive data. This not only exposes the bank to significant legal liability but also risks severe and lasting reputational harm.

Motives and intent

Once an attacker gains control of a vulnerable subdomain, they can host malicious content, effectively transforming the subdomain into a platform for phishing campaigns and other malicious activities. Hackers use subdomain takeover as a mechanism to intercept user authentication credentials, distribute malware, and harvest sensitive information, such as session cookies, which can facilitate further attacks.

Walkthrough of a takeover scenario

Imagine you work for a global business which uses example.com as their primary domain. Because it’s the 21st century, one of your activities is to create and maintain an online e-commerce platform, in addition to the brick and mortar stores your company has been operating for many years.

There are some very popular cloud e-commerce providers (e.g. Shopify, BigCommerce, Magento, Yokart, Big Kartel), so you setup a new store in one of these available offerings. After you have done the setup and configuration, the cloud e-commerce provider assigns exampleshop.someecommerceplatform.com as a domain for your store. This doesn’t look very compelling to share and communicate to your customers, so you want it to be present on your brand, under shop.example.com.

In order to achieve this, you have two configuration options:

1. A 301/302 redirect HTTP will take care of redirecting visitors of shop.example.com to the domain of the e-commerce provider. This approach is less appealing because it will completely replace the domain in the URL bar of the user’s browser.
2. Configuration of a CNAME DNS record that will delegate the DNS resolution directly to e-commerce provider. Using this approach, the domain in the URL bar keeps unchanged. (Note: not all cloud providers support DNS delegation using CNAME)

Since the CNAME approach is more robust, you proceed with option 2.

Risks down the line

Fast forward one year later, the e-commerce activities of your company turn out to be a total disaster. For several reasons, the revenue targets were not reached. The operational management instructs you to take the e-commerce shop offline until the strategy is redefined.

To save money, you cancel your company’s subscription of the the 3rd party e-commerce platform supplier. So now comes the moment that the risk of a potential subdomain takeover is introduced: you can easily forget to update or simply remove the CNAME record in your DNS zone file.
Bottom line, when you don’t remove the CNAME record from your DNS zone file, anybody can register a new store in the same e-commerce platform suppliers environment and therefore aim to takeover shop.example.com.

Recent subdomain attack incidents

Unfortunately, subdomain attacks are common occurrences with far-reaching repercussions. For instance you may have seen the news about the defacement of the Trump administration website as an example. Recently, a massive ad fraud campaign named “SubdoMailing” used over 8,000 legitimate internet domains and 13,000 hijacked subdomains of major brands to send up to five million emails per day for generating revenue via scams and malvertising.

Large enterprises are no less vulnerable to subdomain takeover attacks. In 2020, Microsoft security researchers found multiple Microsoft subdomains vulnerable to takeover. Cyber attackers even managed to takeover Tesla’s subdomain to host a cryptocurrency scam.

As extra reading material on subdomain takeover, we refer to some additional bug bounty reports:

• Subdomain takeover report for vince.co
• Subdomain takeover report for greenhouse.io
• Subdomain takeover report for uber.com

What makes a subdomain vulnerable?

Each domain name is linked to a set of DNS records, including canonical name (CNAME) records, which route subdomains to specific target domains or services. Vulnerabilities arise when an external service, often hosted by cloud providers, becomes inactive or misconfigured while the DNS record continues to point to it.

This creates an opportunity for attackers to hijack the subdomain by providing their own virtual host and hosting malicious content. Such control allows attackers to intercept cookies from the main domain, execute cross-site scripting (XSS) attacks, bypass content security policies, and potentially capture sensitive information, including user credentials, or deliver malicious content to unsuspecting users.

IT considerations for defending against subdomain takeover

For organizations with a minimal online presence, subdomain takeover may not be a primary concern for their IT teams. However, for larger firms where domains play a critical role in their operations and often encompass numerous subdomains, the risk becomes significantly more pronounced. This makes subdomain takeover a substantial threat to business continuity and security.

Here are some common ways to defend your organization’s digital assets against subdomain takeover.

Monitoring and detection

Organizations often leave subdomains unmanaged or improperly configured over time, creating vulnerabilities. One of the most effective ways to prevent subdomain takeovers is by implementing an external attack surface management (EASM) tool. EASM tools continuously monitor domains, identifying exploitable changes, including misconfigured or abandoned subdomains.

As a crucial part of a comprehensive security strategy, EASM maps and analyzes an organization’s digital footprint from an external perspective, uncovering vulnerabilities before they can be exploited. By proactively addressing these weak points, EASM tools help organizations secure their online assets and strengthen overall security.

Regularly audit and clean DNS records

Regularly review your DNS records, with particular attention to CNAME and TXT records, to maintain the security and accuracy of your domain configurations. Ensure that outdated or irrelevant subdomain entries pointing to unused third-party services are promptly removed or updated. This prevents attackers from exploiting vulnerable subdomains and helps safeguard your domain while ensuring its configurations remain secure and up-to-date.

Monitor third-party services

When using third-party services like cloud platforms, hosting providers, or content delivery networks (CDNs) for your subdomains, be sure to verify that these services remain active and correctly configured at all times. Keep track of expiration dates and trial period deadlines, as lapses can leave subdomains pointing to unclaimed addresses, exposing them to potential security breaches.

Domain registrar locking and MFA

Utilize domain-locking features offered by most domain registrars to prevent unauthorized changes to your DNS settings, reducing the risk of exploitation by hackers. Additionally, enable multi-factor authentication (MFA) for your domain registrar account to add an extra layer of protection, further deterring unauthorized access. Implementing these security measures significantly reduces the risk of subdomain takeover and helps protect your online assets.

Cloud providers and subdomain takeover

Of course it is clear that this vulnerability is not limited to e-commerce platforms, but to a large industry of cloud providers. Many CNAME records out there are pointing to large cloud providers like Amazon AWS or Microsoft Azure. In those examples, and when certain conditions are achieved, a subdomain takeover can be achieved quite easily.

Let’s take Amazon Cloudfront as an example. This is a CDN service, which works with the concept of distributions. A distribution can be seen as a set of static files hosted on the Amazon Cloudfront Edge servers.

After creating a new distribution (see screenshot above), AWS generates a random domain name such as d2erlblaho6777.cloudfront.net. You can access the files in your distribution using this domain. Random generation of the subdomain might seem as a good prevention against subdomain takeover, however, it is not the case for CloudFront.

The problem is, that it doesn’t use 1:1 mapping – there is no dedicated IPv4 address for every distribution. CloudFront uses m:n mapping, which means that domains are mapped (think A records) to a smaller set of Cloudfront Edge servers. Since this is some kind of virtual hosting, CloudFront internally uses the mapping table to translate distribution domain to the actual content of the distribution.

What can you do?

If you’re familiar with virtual hosting, you can tell that using CNAME records is not that straightforward. Web servers use the HTTP Host header field to determine, which domain they need to serve. If you would like to use static.example.com for your static files, it will have a CNAME record to your distribution domain as the syntax shows below:

static.example.com.		600	IN	CNAME	d2erlblaho6777.cloudfront.net.

However, if you use static.example.com directly, CloudFront servers will see it in an HTTP Host header. Therefore, CloudFront cannot map this domain to any distribution, because this domain is not in a mapping table! That’s why CloudFront allows you to provide which CNAME records you will use with your distribution.

If a domain has a CNAME record to CloudFront, but the distribution with its associating CNAME was deleted, a cyber attacker can easily claim that domain to setup his attacker infrastructure. You generate a distribution, set the CNAME, and CloudFront’s mapping mechanism will take care of the rest.

Immediate steps to take

The consequences of a subdomain takeover can be pretty bad. This is a perfect way for cyber attackers to launch a phishing campaign leveraging your established (soon to be impacted) brand reputation. The victim has no way of telling, whether the content is served by the domain owner or the cyber attacker.

Despite this, organizations usually don’t audit their DNS configuration on a regular basis. Many times, there is no standardized process for adding, changing or removing entries from their DNS zone file. Even logging changes to your DNS records, are not that common.

Preventing subdomain takeover starts with proper monitoring and analysis of the DNS records of your attack surface. An important step is to conduct subdomain enumeration as explained in the “The Art of Subdomain Enumeration”. Building and maintaining visibility on your dynamic attack surface including the changes to your DNS configuration is key to address this problem before it’s too late.

Map your attack surface for free

If you have little or no visibility on your attack surface and want confirmation if you are prone (or not) to subdomain takeover, Outpost24 can help. Interested to get a comprehensive view of your attack surface risks, including all domains and subdomains? Book a free analysis here.