A company launches a new website.

Six months later, the project is abandoned.

The developers delete the application.

The marketing team forgets about the old subdomain.

But one thing remains:

old.example.com

The DNS record is still there.

And it still points to a third-party service.

The company thinks the old application is gone.

The DNS record says otherwise.

An attacker discovers the forgotten subdomain and realizes something interesting:

The domain still points to a resource that no longer belongs to the company.

If the external service allows the resource to be claimed by someone else, the attacker may be able to take control of the subdomain.

Suddenly:

old.example.com

belongs to the attacker.

And because the URL still uses the company’s legitimate domain, visitors may trust it.

This is known as:

Subdomain Takeover

It is one of the most interesting vulnerabilities that can be discovered during subdomain enumeration and attack-surface reconnaissance.

What Is a Subdomain Takeover?

A subdomain takeover happens when an organization’s DNS configuration points a subdomain toward an external service or resource that has been deleted, abandoned, or released—but the DNS record remains active.

A simplified example:

example.com
      │
      ├── www.example.com
      │
      ├── api.example.com
      │
      └── old.example.com
              │
              ▼
        Third-party service

The company later deletes the third-party resource.

But the DNS record remains:

old.example.com
      ↓
external-service.example.net

The external resource is now unclaimed.

If the service permits another customer to claim that resource, an attacker could potentially associate it with:

old.example.com

The result:

old.example.com
        ↓
Attacker-controlled resource

The attacker hasn’t necessarily hacked the company’s DNS provider.

They exploited an abandoned dependency.

Why This Vulnerability Is So Interesting

The attacker may not need:

• The company’s password
• Access to its DNS account
• Access to its servers
• Malware
• SQL injection
• XSS
• A stolen employee account

Instead, they may only need to discover:

DNS record
+
abandoned external resource
+
claimable resource

That’s why reconnaissance matters so much.

Sometimes the vulnerability is visible before you even interact with the main application.

The Basic Attack Chain

A typical scenario looks like this:

Company creates:
blog.example.com
        ↓
Points to external service
        ↓
Project abandoned
        ↓
External resource deleted
        ↓
DNS record remains
        ↓
Researcher discovers dangling DNS
        ↓
Resource may be claimable
        ↓
Subdomain potentially controlled

The critical word is:

Potentially

A dangling DNS record does not automatically mean takeover is possible.

You must verify that the external resource can actually be claimed and that the resulting behavior is exploitable.

DNS Is the Starting Point

Suppose an organization owns:

example.com

It may have hundreds or thousands of subdomains:

www.example.com
api.example.com
dev.example.com
staging.example.com
support.example.com
blog.example.com
old.example.com
partners.example.com

Each may have different infrastructure.

Some could point directly to company servers.

Others might point to:

CDN
Cloud platform
SaaS provider
Marketing platform
Helpdesk
E-commerce platform
Hosting provider

This creates a large attack surface.

CNAME Records Are Particularly Interesting

One DNS record type frequently encountered during takeover research is:

CNAME

A CNAME essentially says:

This hostname should resolve through another hostname.

For example:

blog.example.com
        ↓
example.hosting-provider.com

The company’s DNS still controls:

blog.example.com

But the actual application may be hosted elsewhere.

If the external resource disappears while the CNAME remains, you may have a dangling dependency.

A Simplified Example

Imagine:

docs.example.com
        ↓
example.docs-service.com

The company eventually cancels its documentation project.

The provider removes:

example.docs-service.com

But nobody removes:

docs.example.com

Now:

docs.example.com
        ↓
Nonexistent external resource

A security researcher discovers this.

The next question is:

Can the external resource be legitimately registered or claimed by another account?

If yes, there may be a takeover path.

A Dangling CNAME Is Not Enough

This is an extremely important distinction.

Finding:

CNAME → nonexistent-resource.example

doesn’t prove:

“I can take over the subdomain.”

It only proves:

“The DNS configuration may be dangling.”

The external provider may:

• Reserve the old resource
• Prevent reassignment
• Require ownership verification
• Block the resource permanently
• Return a generic error
• Use another security mechanism

Therefore:

DNS evidence is the beginning of the investigation, not the final proof.

Why Forgotten Subdomains Are Everywhere

Large organizations constantly create temporary infrastructure.

For example:

campaign.example.com
summer-sale.example.com
2024.example.com
events.example.com
dev.example.com
staging.example.com
beta.example.com
old.example.com

Projects end.

Employees leave.

Vendors change.

Cloud resources are deleted.

DNS records are forgotten.

The result is technical debt in the public attack surface.

Subdomain Takeover Is an Asset-Management Problem

At its core, this vulnerability is often caused by poor lifecycle management.

The company thinks:

Delete application
=
Delete everything

But the actual infrastructure may be:

Application deleted
      ↓
Cloud resource deleted
      ↓
DNS record remains
      ↓
Certificate remains
      ↓
Documentation remains
      ↓
Monitoring remains

The pieces have different owners.

Nobody realizes the hostname is still active.

Why Attackers Love Reconnaissance

Imagine you only visit:

https://example.com

You see:

Homepage
Login
Products
Contact

Nothing appears vulnerable.

But the organization’s real attack surface could be:

example.com
www.example.com
api.example.com
dev.example.com
staging.example.com
old.example.com
cdn.example.com
assets.example.com
support.example.com
partners.example.com

The forgotten infrastructure is often where interesting security problems live.

That’s why subdomain enumeration is an important part of authorized security testing.

Finding Subdomains

For organizations you own or are authorized to assess, researchers can build a subdomain inventory using sources such as:

• DNS records
• Certificate Transparency
• Public documentation
• Search engines
• Historical data
• Asset-discovery tools
• Organization-owned infrastructure inventories

The goal is to answer:

What hostnames belong to this organization?

Not:

“How can I attack random domains?”

Certificate Transparency Can Reveal Old Infrastructure

TLS certificates can contain hostnames.

For example, a certificate might include:

example.com
www.example.com
api.example.com
old.example.com
dev.example.com

Even if the organization doesn’t prominently advertise those hostnames anymore, certificate records can provide useful clues during authorized attack-surface mapping.

This is one reason Certificate Transparency is useful for defenders as well as security researchers.

DNS Enumeration

After collecting candidate hostnames, researchers can examine their DNS records.

For example:

A
AAAA
CNAME
MX
TXT
NS

The objective is to understand where each hostname points.

A simple inventory might look like:

This turns thousands of hostnames into something security teams can actually investigate.

What Does a Vulnerable Host Look Like?

A suspicious hostname might produce behavior such as:

404

or:

Resource not found

or a provider-specific message indicating that the resource doesn’t exist.

But again:

An error page does not prove takeover.

Different providers use different messages.

A researcher must identify:

1. Where the hostname points.
2. Whether the resource exists.
3. Whether the resource is claimable.
4. Whether claiming it would actually control the subdomain.

The Difference Between “Dangling” and “Takeover”

These terms should not be treated as synonyms.

Dangling DNS

The DNS record points to something that appears to be unavailable.

Example:

old.example.com
       ↓
deleted-resource.provider.com

Subdomain Takeover

The external resource can actually be claimed or controlled in a way that causes:

old.example.com
       ↓
attacker-controlled content

The second is significantly more serious.

Why HTTPS Makes This More Interesting

Imagine an organization previously used:

old.example.com

with HTTPS.

Users may still see:

https://old.example.com

and trust it because:

• It uses HTTPS.
• It contains the company’s real domain.
• It may have appeared in old documentation.
• Search engines may still index it.
• Employees may still recognize it.

HTTPS proves that the connection is encrypted and that the certificate matches the hostname.

It does not prove that the current content is trustworthy.

If the legitimate domain has been delegated to an attacker-controlled service through a takeover, HTTPS can make the malicious page look even more legitimate.

What Could an Attacker Do?

The impact depends heavily on the environment.

Potential consequences can include:

Phishing

A trusted subdomain could host convincing login pages.

Brand impersonation

The attacker could display company-branded content.

Reputation damage

Visitors may associate malicious content with the organization.

OAuth-related problems

In certain architectures, trusted subdomains can interact with authentication flows.

Cookie-related risks

Poorly scoped cookies can make subdomain compromise more serious.

Trust relationships

Other systems may treat subdomains as trusted origins.

Stored content or JavaScript

If the service allows arbitrary content, the attacker may control what users receive from the hostname.

But don’t automatically claim:

“Subdomain takeover = account takeover.”

The actual impact depends on the organization’s architecture.

Cookie Scope Can Make Things Worse

Consider a poorly designed cookie:

Set-Cookie: session=...; Domain=.example.com

That cookie is potentially available across subdomains.

Now imagine:

secure.example.com
        +
old.example.com

If old.example.com becomes attacker-controlled and sensitive cookies are broadly scoped, the security consequences could become much more serious.

This is why organizations should avoid unnecessarily broad cookie domains.

Modern cookie protections such as:

Secure
HttpOnly
SameSite

also matter.

Trusted Subdomains Are Security Boundaries

Developers sometimes assume:

“It’s still our domain.”

But a domain isn’t automatically trustworthy merely because it ends with:

.example.com

Each subdomain can potentially have different:

• Infrastructure
• Owners
• Applications
• Vendors
• Security controls

Treat external subdomains as separate security boundaries unless they are explicitly controlled.

Third-Party Services Create Risk

Companies frequently integrate:

• SaaS platforms
• Marketing systems
• Support platforms
• Cloud hosting
• CDNs
• Documentation platforms
• Recruitment systems
• E-commerce platforms

A hostname might therefore point to:

example.thirdparty.com

The external service becomes part of the company’s public attack surface.

When the relationship ends, the DNS record must be removed.

The Employee Lifecycle Problem

Imagine:

Employee A
   ↓
Creates project
   ↓
Creates subdomain
   ↓
Connects SaaS service
   ↓
Leaves company

Months later:

Project abandoned
SaaS account deleted
DNS record remains

The security team may not even know the subdomain existed.

This is why asset inventory needs to include DNS dependencies.

How Bug Bounty Researchers Approach Subdomain Takeover

If a bug bounty program explicitly allows subdomain and infrastructure testing, a safe workflow is:

Step 1 — Enumerate assets

Collect known subdomains.

Step 2 — Resolve DNS

Determine where each hostname points.

Step 3 — Identify external services

Look for third-party infrastructure.

Step 4 — Find dangling resources

Determine whether the destination appears deleted.

Step 5 — Verify claimability safely

Follow the provider’s legitimate ownership/claim process.

Step 6 — Stop once control is demonstrated

Don’t upload malware.

Don’t collect credentials.

Don’t target users.

A harmless proof-of-control page is generally sufficient where the program permits it.

What Makes a Good Proof of Concept?

Suppose you discover:

old.example.com

pointing to an abandoned third-party resource.

The strongest report isn’t:

“This looks vulnerable.”

Instead, demonstrate:

DNS
 ↓
External resource
 ↓
Resource no longer owned by company
 ↓
Resource can be legitimately claimed
 ↓
Controlled content appears at old.example.com

Use harmless content such as:

Subdomain Takeover PoC
Security testing by researcher

Do not collect visitor information unless the program specifically requires and permits it.

Avoid Over-Testing

Once you demonstrate control, stop.

You don’t need to:

• Phish employees
• Harvest cookies
• Steal credentials
• Inject malicious JavaScript
• Redirect users
• Collect visitors
• Attack internal systems

A responsible researcher proves the vulnerability with the smallest possible impact.

Common False Positives

Subdomain takeover scanners can produce false positives.

For example:

CNAME exists
+
provider error

doesn’t necessarily mean:

resource is claimable

Possible explanations include:

• Resource intentionally disabled
• Provider reserves the name
• Resource requires ownership validation
• DNS configuration is intentional
• Provider blocks reassignment
• The error page is generic

Always manually verify important findings.

Why Automated Takeover Scanners Can Be Dangerous

Some tools attempt to automate detection.

That’s useful for authorized security work.

But automation can become dangerous if it:

• Automatically creates accounts
• Claims resources
• Modifies third-party infrastructure
• Uploads content
• Performs destructive actions

A good security workflow separates:

Detection

from:

Exploitation

Automate discovery.

Be extremely careful with verification.

Subdomain Takeover and Cloud Security

Cloud infrastructure makes this problem increasingly relevant.

Organizations can create and delete resources rapidly:

Cloud resource
      ↓
DNS record
      ↓
Application

Later:

Cloud resource deleted
      ↓
DNS record forgotten

The cloud resource disappears.

The DNS record doesn’t.

That creates a dangling dependency.

The Defender’s View

Security teams should maintain a live inventory containing:

Hostname
DNS record
Owner
Application
Provider
Environment
Business purpose
Expiration/review date

For example:

The biggest red flag is:

Unknown owner.

If nobody knows why a hostname exists, it deserves investigation.

Build a DNS Lifecycle

When creating a subdomain:

Create
 ↓
Assign owner
 ↓
Document provider
 ↓
Monitor
 ↓
Review
 ↓
Retire
 ↓
Remove DNS

Don’t stop at:

Delete application

The DNS record is part of the asset.

Monitor Dangling DNS Continuously

Organizations can periodically check:

CNAME records
A records
AAAA records
External dependencies
Cloud resources
SaaS integrations

Look for:

External target no longer exists

or:

External resource no longer belongs to organization

This is especially important after:

• acquisitions
• rebranding
• migrations
• cloud migrations
• vendor changes
• product shutdowns
• employee departures

Subdomain Takeover Checklist

For security teams:

Asset Discovery

• Enumerate all subdomains
• Identify owners
• Identify external providers
• Review Certificate Transparency
• Review DNS records

DNS Security

• Audit CNAME records
• Audit A/AAAA records
• Identify abandoned destinations
• Remove unused DNS entries
• Review wildcard DNS

Third-Party Services

• Track SaaS ownership
• Document cloud resources
• Remove integrations when projects end
• Verify resources are deleted
• Confirm DNS cleanup

Authentication

• Avoid broad cookie domains
• Review trusted origins
• Review OAuth redirect URIs
• Review CORS configuration
• Review cross-subdomain trust

What Bug Bounty Hunters Should Remember

Subdomain takeover isn’t just:

“Find a broken CNAME.”

A proper finding requires a chain:

Subdomain
    ↓
DNS record
    ↓
External dependency
    ↓
Dependency abandoned
    ↓
Resource claimable
    ↓
Subdomain controllable
    ↓
Security impact

Each step matters.

The Bigger Lesson

Subdomain takeover demonstrates something important about modern cybersecurity:

Your attack surface isn’t just your servers.

It’s everything your domain points to.

A company might secure:

example.com

perfectly.

But if it has:

old.example.com
campaign.example.com
dev.example.com
support.example.com

pointing to forgotten third-party resources, those forgotten assets can become security liabilities.

The weakest link may not be the main website.

It might be the hostname nobody remembers exists.

Final Takeaway

Every company has a digital graveyard.

Old applications.

Old servers.

Old cloud resources.

Old domains.

Old APIs.

Old subdomains.

Some disappear properly.

Others leave behind DNS records that quietly remain online.

And that’s what makes subdomain takeover so interesting.

An attacker doesn’t necessarily need to break into the company’s infrastructure.

Sometimes they just need to find something the company forgot to remove.

The security lesson is simple:

If you create a DNS record, you also need a plan for deleting it.

For defenders:

Know every subdomain. Know where every subdomain points. Know who owns it.

For bug bounty hunters:

Don’t just enumerate subdomains—understand the infrastructure behind them.

And for organizations:

An abandoned hostname isn’t harmless just because nobody uses it anymore.

Sometimes, the forgotten subdomain is the one an attacker is looking for.

Think Like an Attacker. Secure Like a Pro.