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 record type) 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.

Types of dangling DNS risks and how they are detected

Your ASM workspace's names are checked one at a time against the Internet Map's stored DNS resolution data (record types, response codes, and extended DNS errors).

Two independent signals decide the risk type:

• Whether a name is dangling, which is determined from DNS response codes and extended DNS errors (EDEs).
• Whether the dangling target is takeover-eligible, which is decided by matching the target hostname against known-hijackable provider patterns.

These signals determine which of the four types of dangling DNS risks an asset has.

Additional detail on the signals is provided below.

Dangling CNAME signal

The name has a CNAME record, but the alias target authoritatively does not exist.

• The A/AAAA lookup returns response code NXDOMAIN and its answer still carries a CNAME record. In ASM, the CNAME target from that answer is recorded as the problem domain.
• Every other record type queried for the name is also NXDOMAIN.
  • The one allowed exception is SERVFAIL on the SOA record, which is commonly observed alongside a genuine NXDOMAIN.

Only NXDOMAIN counts as "does not exist." SERVFAIL and other errors may be transient, so they are deliberately not treated as dangling to avoid false positives.

Dangling NS signal

The name is delegated to a nameserver that is reachable but refuses to answer authoritatively for the zone.

• The A-record lookup carries an extended DNS error of type network-error with response code REFUSED. EDEs are inspected regardless of the top-level response code, since the EDE can be present even on NOERROR. A network error sounds like it would be transient, but it’s what is returned when a nameserver refuses to answer, not when it transiently fails.
• In ASM, the first nameserver hostname for the name is recorded as the problem domain.

The takeover signal

Takeover is an additive qualifier on top of a dangling verdict. Once a name is dangling, the offending target hostname (the CNAME target or the nameserver host) is matched against curated lists of known-hijackable provider patterns.

• One set covers cloud/SaaS providers where an unclaimed CNAME target can be re-registered by an attacker.
• A second set covers managed-DNS providers where a nameserver delegation can be reclaimed.

A match upgrades the risk finding to the corresponding "with takeover" variant (HIGH severity) and the matched pattern is kept as evidence. No match leaves it a plain dangling risk (MEDIUM severity). In short, "dangling" indicates a broken pointer (misconfiguration) and takeover indicates that broken pointer resolves to a provider where an attacker could claim the resource and control the name.

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.