VERA Vendor Risk Signals Library

Subdomain Takeover Risk

Subdomain takeover risk can arise when an organization’s DNS continues to point to a cloud service, hosting platform, or other external resource that has been removed or deprovisioned. If that abandoned resource can be claimed by someone else, an attacker may be able to serve content from a subdomain that still appears to belong to the vendor.

What is subdomain takeover risk?

A subdomain takeover can occur when a DNS record points to an external resource that no longer exists or is no longer controlled by the organization.

OWASP describes this type of condition as a dangling DNS record. For example, a CNAME record may continue to point to a third-party hosting service after the underlying site or application has been deleted. If the service allows another party to register the abandoned resource, that party may be able to take control of the organization’s subdomain.

A simplified example might look like:

portal.vendor.com → vendor-app.hosting-provider.com

If vendor-app.hosting-provider.com has been deprovisioned but the DNS record for portal.vendor.com remains, the record is dangling.

Whether that condition is actually exploitable depends on the provider and the way the resource is assigned. Some platforms include protections that prevent abandoned resources from being reclaimed, while others may allow a takeover condition to exist.

Why does subdomain takeover risk matter in vendor risk?

A subdomain inherits trust from the organization’s primary domain.

Employees, customers, partners, and security tools may reasonably assume that content hosted at a hostname such as:

support.vendor.com

login.vendor.com

is controlled by the vendor.

If an attacker gains control of that hostname, they may be able to use that trust for malicious purposes.

Microsoft notes that subdomain takeover can redirect traffic intended for an organization’s domain to infrastructure controlled by an attacker.

Depending on the affected subdomain and surrounding configuration, this could support activities such as:

phishing or credential collection;
distribution of malicious content;
impersonation of the vendor;
abuse of trusted links or bookmarks; or
exploitation of trust relationships involving the affected subdomain.

From a third-party risk perspective, the value of this signal is that it can expose the operational residue left behind when applications and cloud resources are retired.

A vendor may have strong written security policies while still maintaining forgotten DNS records tied to infrastructure that no longer exists.

That does not prove poor security governance across the organization. It does provide concrete evidence of a condition worth examining.

What can VERA observe?

Because DNS and many associated internet-facing services are externally observable, VERA can evaluate evidence that may indicate subdomain takeover risk.

Depending on the available evidence, VERA can observe:

vendor-associated subdomains;
DNS records pointing to third-party or cloud-hosted resources;
CNAME or other records that appear to reference deprovisioned or unavailable services;
provider-specific responses associated with unclaimed resources;
externally observable evidence that the destination resource no longer exists;
persistent DNS records associated with retired infrastructure; and
related attack-surface conditions involving the affected hostname.

OWASP’s testing guidance similarly describes subdomain takeover assessment as involving subdomain enumeration, detection of potentially vulnerable records, and validation of the underlying condition.

The important distinction is between:

a dangling DNS record

and

a confirmed exploitable takeover condition.

Those are not the same thing.

The more useful question is:

“Does the observable DNS configuration indicate that a vendor-controlled hostname points to an external resource that may no longer be under the vendor’s control?”

What does this signal not prove?

A dangling DNS record does not automatically prove that a subdomain can be taken over.

It also does not prove that:

an attacker has already claimed the resource;
malicious content has been served from the subdomain;
users have been redirected to attacker-controlled infrastructure;
credentials or data have been compromised;
the vendor intentionally exposed the condition; or
the organization has weak security controls overall.

Exploitability depends heavily on the external service involved.

Some cloud and hosting providers prevent abandoned resources from being re-registered or use additional ownership-validation controls specifically to reduce takeover risk. Microsoft, for example, documents platform features designed to prevent dangling DNS entries from becoming exploitable takeover conditions.

For that reason, identifying a DNS record that references an unavailable resource should be described carefully.

A finding may represent:

a stale DNS record, a potential takeover condition, or a validated takeover opportunity.

The evidence should determine which conclusion is justified.

How VERA uses this signal

VERA evaluates subdomain takeover risk as part of its broader external attack-surface and DNS analysis.

Where a potentially dangling record is identified, the finding can be evaluated using the observable DNS configuration, the external provider involved, the state of the referenced resource, and other available evidence.

The goal is not to label every stale DNS record as a critical vulnerability.

It is to identify conditions where an organization’s trusted namespace may point to infrastructure it no longer controls and determine how strongly the available evidence supports that conclusion.

This reflects VERA’s broader approach to vendor risk:

identify externally observable conditions, preserve the supporting evidence, and avoid claiming more than the evidence can establish.

Related Vendor Risk Signals

No single external signal tells the whole story. These related signals can provide additional context when evaluating this finding as part of a broader third-party risk assessment.