Domain or subdomain takeover is possible when a domain used by your organization loads resources from a location that is available for others to register.
Detection Methodology
The possibility of domain takeover can be tested by analysing a domain's DNS records for resource locations like other domains, SaaS subdomains, or IP addresses, that are not in use and can be acquired by attackers. For example, if the A record for one of your domains points to an IP address that is not in use, a third party could theoretically acquire that IP address and thereby control what content is served on your domain.
This same type of problem can occur for other DNS record types: CNAME, MX, and NS records.
To test whether a domain is at risk of takeover, use the dig command to get the DNS records and then look at the domains and IPs listed in the answers. If the resource named in the IN response for the subdomain is available for others to acquire, the subdomain may be at risk of takeover.
Example: Amazon S3
An example of a service where dangling DNS records are at risk of takeover is Amazon Web Service's S3. Imagine you have a site "my-site.example.com" that has a CNAME pointing to the S3 bucket "my-site.s3.amazonaws.com." If you decommission the bucket "my-site," that bucket name becomes available for registration again. An attacker can then register the bucket "my-site" and add whatever files they want. Your site located at "my-site.example.com" still has a CNAME pointing to "my-site.s3.amazonaws.com." Visiting my-site.example.com will thus cause the user's browser to load files that are hosted in a bucket under the attacker's control, causing impacts ranging from reputational damage to malware distribution to credential skimming.
Here is a truncated example of the dig request and the relevant portion of the response:
dig my-site.example.com
[...]
;; ANSWER SECTION:
my-site.example.com. 3600 IN CNAME my-site.s3.amazonaws.com.
We see in the dig lookup that the CNAME for "my-site.example.com" is "my-site.s3.amazonaws.com."
Severities of Takeover Risks
The severity of this issue depends on the re-use mechanisms put in place by the provider managing that resource. For example, a common type of dangling DNS issue is when a CNAME points to an abandoned SaaS account that is no longer registered. Whether that SaaS provider allows users to register previously used account names varies by provider and is subject to change.
UpGuard therefore identifies three severities of subdomain takeover:
Vulnerable to takeover. These are dangling DNS records where abandoned resources are known to be available for registration, like AWS S3.
Potentially vulnerable to takeover. These are dangling DNS records where there are additional factors that may or may not make the subdomain vulnerable, similar to the "unverified" status for vulnerabilities.
Dangling DNS. These are DNS records pointing to a third party that is not vulnerable to takeover, but which indicate poor hygiene of the asset's DNS records.
Remediation
Each of these cases can be observed in the UpGuard platform in the same places as other risks– in the context of a given domain in the Domains view or in the Risk Profile. This information is available in BreachSight and Vendor Risk.
Removing the DNS record that points to the unused resource will prevent an attacker who has acquired that resource from being able to take over your domain, and is likely the fastest way to address the issue. If the subdomain is no longer in use, you may also consider decommissioning the subdomain to reduce your attack surface.