Dangling DNS Risks

Subdomain takeover is a common attack tactic that occurs when an attacker gains control over a subdomain of a target website. This usually happens due to a misconfiguration in DNS settings, particularly when there are "dangling DNS" entries.

Censys Attack Surface Management (ASM) protects your organization against subdomain takeover by identifying dangling DNS risks in your attack surface inventory that you can triage and remediate. This document explains how dangling DNS entries are commonly exploited and how to use ASM dangling DNS risks to resolve security issues.

Dangling DNS and subdomain takeover

A dangling DNS entry refers to a DNS record that points to a domain or a resource (like an IP address, CNAME, or other types of records) that no longer exists or is no longer in use. However, the DNS record itself remains active and still points to the now-nonexistent resource.

The following outline explains how an attacker might use dangling DNS records to take over target subdomains.

1. DNS record points to a non-existent resource
   • A company might have created a DNS entry for a subdomain (like sub.example.com) that points to a domain or an external service (like AWS S3, GitHub Pages, Heroku, or another third-party service).
   • If the domain is expired, the service is decommissioned, or the account associated with the service is deleted but the DNS entry is not removed, the DNS record still points to the now-defunct resource.
2. Attacker identifies dangling DNS entries
   • Attackers can scan and identify subdomains associated with a website. They then check whether these subdomains point to any resources that no longer exist (a dangling DNS entry).
3. Attacker claims the resource
   • Once a dangling DNS entry is identified, the attacker can create an account with the same external service (like AWS S3 or GitHub Pages) and register a resource with the exact same name that the subdomain was originally pointing to. For example, if sub.example.com was originally pointing to examplebucket.s3.amazonaws.com on AWS S3, and the bucket examplebucket was deleted, an attacker can create a new bucket with the same name.
4. Subdomain now controlled by attacker
   • After registering the resource, the subdomain (sub.example.com) now resolves to the attacker’s resource. This means the attacker can host content, run scripts, or set up phishing pages under the subdomain.
   • Since the subdomain is under the legitimate domain (example.com), users might trust it more, making it easier for the attacker to perform malicious activities, such as phishing, spreading malware, or stealing sensitive information.

Dangling DNS risks in Censys ASM

In Censys ASM, dangling DNS risks can be identified on domain and web entity assets. Dangling DNS-related risks are categorized as misconfigurations. Censys automatically checks all of the names in your attack surface for dangling DNS risks every day.

Dangling DNS risks that point to resources that can be taken over by attackers have a HIGH severity by default.

Dangling DNS risks that do not have a potential takeover associated with them have a MEDIUM severity by default. Assets with these risks have CNAME or NS records that do not resolve successfully. However, the assets that they point to are not subject to potential takeover.

Note that domain pages do not have a Risks tab. Dangling DNS risks on domains are shown in the Recent Domain Activity feed and on the Risk Instances page.

Resource-specific domain and subdomain takeover risks

Some domain and subdomain takeover risks indicate the type of third-party or cloud resource (like S3 bucket, Heroku domain, GitHub domain, and so on) that a DNS record is pointing to that no longer exists. You can use this information to update your DNS records and ensure that old resources are fully decommissioned or otherwise updated.

Dangling NS and dangling CNAME risks

These risks identify when a domain's NS record delegates to an unclaimed or invalid nameserver target or CNAME record points to an unclaimed third-party resource. The domain or subdomain with the problematic record is highlighted in the risk name.

Click Risk Evidence on these risk instances to see more information. The problem_domain explains where the resolution failed. Use this information to update your DNS records as needed.