Subdomain Takeover 2026: The DNS Gap Nobody Scans

[Blacksec]

Hey hackers — subdomain takeover is that rare vulnerability class where the entire internet's top results read like corporate prevention checklists while the actual mechanism sits there in plain sight: a DNS record outliving the resource it points to, leaving an unclaimed service that anyone can claim. No exploitation of software needed, no injection, no creds — just lifecycle gaps between DNS and the services DNS points at. This guide covers the core mechanism properly (why DNS structurally creates this class), the full dangling-resource taxonomy by service type, how operators actually identify the gap during recon, what the impact chain looks like (and why bug bounties pay real money for it), the organizational rot that keeps the class alive, and the authorized-research line. Mechanics, not prevention pamphlets.
TL;DR: A subdomain takeover happens when sub.victim.com has a DNS record (usually CNAME) pointing at a third-party resource (SaaS page, cloud bucket, PaaS app, CDN endpoint) that has been deprovisioned but not unlinked — and the provider lets anyone claim/control orphaned resources. Attacker claims the resource → attacker serves content on the victim's own subdomain → phishing credibility, cookie-scope abuse, defacement, SEO poisoning, or full brand impersonation — all riding on the victim's domain reputation. Identification = enumerate subdomains → observe record targets → fingerprint dead-resource responses → attempt claim safely. It's a class of infrastructure hygiene failures, and it's everywhere.

What Is Subdomain Takeover?​

Precise definition: a subdomain takeover (also "dangling DNS" or "dangling subdomain") is the condition where a subdomain's DNS record resolves to a third-party service that no longer exists under the owning organization's control — combined with a provider model where resource claim/control can be acquired by whoever registers it first. The takeover is the ACT of claiming that orphaned resource; the vulnerability is the state that allows it.
Three components must coexist — understand all three and the class is fully mapped:

• A dangling record. Some DNS entry (almost always CNAME, sometimes A/ALIAS to shared infrastructure) still points at a resource identifier the organization believes is "done with" — subdomain kept, resource deleted. DNS records don't expire when cloud resources do; they persist until someone removes them.
• A claimable resource slot. The target service's business model (or legacy behavior) allows unclaimed resource names to be registered by new parties — SaaS static-page hosts, cloud storage bucket naming, PaaS app names, code-hosting pages, CDN custom-hostnames, and dozens more patterns operate on first-come naming.
• No ownership verification on claim. The provider validates that you control the RESOURCE name in their system — nothing checks that you control the DNS pointing to it. The victim proved ownership to no one when creating the record; the attacker proves nothing to the victim when claiming the slot.

The intersection is the whole bug: DNS says "this lives here," the provider says "whoever claims it controls it," and nobody connects the two directions. Not a cryptographic failure, not an auth bypass — a lifecycle desynchronization between two systems that were never designed to talk to each other.

Why DNS Structurally Creates This Class​

Stage	What happens	The gap created
1. Integration	Team points app.victim.com CNAME → something.saaSprovider.com (marketing site, staging, campaign page, docs)	Record now depends on external resource state nobody tracks
2. Resource teardown	Project ends; resource deleted at the PROVIDER (the free-tier page, bucket, or app gets removed)	DNS record remains — nobody's runbook includes "unpoint DNS on teardown"
3. TTL expiry of awareness	Months pass; the people who knew the mapping change roles/projects; DNS TTL means resolvers keep serving the record indefinitely anyway	Record is now invisible institutional knowledge
4. Name becomes claimable	Provider's resource-name registry shows the slot as unclaimed/available	Open door: first party to register that name controls what the victim's DNS serves
5. Claim	Anyone who finds the dangling record claims the resource name at the provider	Full content control on the victim's subdomain — takeover complete

The persistence math is why this class never dies: DNS records outlive employees, projects, M&A integration timelines, and often the security team's visibility into external asset inventory. Every organization with more than a handful of subdomains and third-party integrations has statistically likely dangling records — the class isn't about poor security products, it's about two lifecycle processes (DNS management vs. resource management) that have no forcing function to sync.

The Dangling Resource Taxonomy​

Which third-party resource classes actually produce takeovers — the surface map (public disclosure history from bug-bounty programs has catalogued this thoroughly):

Resource class	Dangling condition	Claim model	Representative pattern
Static page hosts	Project/site deleted at provider, CNAME remains	Name-based claim — register the site name, it serves your content	The classic form: campaign pages, GitHub-Pages-style hosts, docs sites
Cloud storage buckets	Bucket deleted (or never created after record set), CNAME to bucket endpoint persists	Create bucket with the exact name → endpoint now yours	Storage-naming uniqueness makes claim deterministic where names align
PaaS / app platforms	App unlinked from platform, custom domain binding remains in DNS	Deploy app claiming that name → platform binds it	App-name registries across major PaaS providers
CDN / edge hosts	Custom hostname removed at provider, DNS left pointing at edge	Re-register hostname at provider (or provider's legacy open-bind behavior)	Edge configuration vs DNS drift
Code-hosting pages	Repo/org/page deleted, CNAME to pages endpoint remains	Create page with matching path/name	Public-forge page hosting models
SaaS marketing/helpdesk/CRM	Subscription lapsed → account/space deleted, DNS unremoved	Often claimable via re-registration patterns (provider-dependent)	Lapsed-SaaS = extremely common in mid-market sprawl
Email/spam-gateway links	Tracking/click domains pointed at lapsed email SaaS	Provider-dependent; sometimes claimable, sometimes just dead-resolution intel	Niche but documented in disclosures
Third-party widgets/CDN scripts	Vendor offboarded, script-hosting DNS remains	Depends on vendor's orphan handling	Often missed in vendor-exit checklists

Two structural notes on the table: (1) every row is a VENDOR-LIFECYCLE problem wearing a DNS costume — the fix category is always asset-inventory hygiene, never a patch; (2) cloud providers have been tightening claim-models for the biggest platforms over time (some now verify DNS ownership before binding — the class narrows at well-defended providers while persisting everywhere else, including at the long tail of smaller SaaS where most dangling records live).

How Operators Identify the Gap (Recon Mechanics)​

The identification workflow at concept level — this is what "subdomain takeover checkers" automate, and worth understanding before anyone reaches for a tool:

Spoiler: The enum → fingerprint loop, step by step

• Subdomain enumeration. Build the list of everything that resolves: certificate-transparency logs (certs issued for *.victim.com are public), passive DNS sources, historical records, wordlist-driven resolution against the zone. The intel dimension: subdomains are MOST discoverable through CT logs precisely because TLS issuance is publicly logged — most takeover targets announce themselves to anyone reading the right feed.
• Record observation. For each discovered name, read what it points at (CNAME chain especially — the dangling signal is a CNAME whose target is a recognizable third-party pattern: provider-specific hostname formats identify themselves clearly).
• Response fingerprinting. Resolve the target and read the HTTP response. Dead-resource states have recognizable signatures: the provider's "project not found / no such site / this page doesn't exist" error served WITH the victim's subdomain in the URL bar = textbook dangling condition. The error page IS the vulnerability evidence — it proves the record resolves to a claimable-but-unclaimed slot.
• Safe claim verification. (Authorized scope only) attempting the provider-side claim in a way that doesn't deface anything — some disclosure practices register the resource and immediately prove control with a static placeholder, then report. Out of scope: this step is the line between reconnaissance and unauthorized access, and only ever crosses it with written authorization.

The pattern-sense that speeds this up: high-value targets are boring forgotten things — staging., old-, campaign-, 2019-, test- prefixed names, subdomains of acquired companies, microsites from past events. Nobody's production app sits dangling; everything forgotten does.

Spoiler: The classic takeover chain, walked end to end

The canonical pattern as it appears in public disclosure reports (concept walk — no live targets, no claims, the shape every writeup shares):
State found: promo.victim-brand.com CNAMEs to victim-brand.somestaticpageservice.com. Visiting it returns the provider's default "404 - project does not exist" page — but served under the victim's domain. The record is dangling: page was deleted at the provider, DNS never updated.
Claim step: at the provider, registering a project/site named victim-brand succeeds (name is unclaimed — the victim never owned it as a "claim", they only CNAMEd at it). The platform now serves attacker-controlled content at the same URL.
Impact demonstrated: the subdomain now hosts arbitrary content under the victim's domain — which inherits the domain's trust context: cookies scoped to .victim-brand.com can be interacted with (session-adjacent attacks depending on cookie flags), the branded URL defeats "check the domain" phishing heuristics, and any reputation the root domain holds extends to attacker content (email-link trust, search indexing, enterprise allowlists that trust the parent domain).
Disclosure outcome shape: report → vendor removes dangling record (the actual fix) → bounty (this class historically paid well because impact chains into phishing/brand abuse that security teams can't detect from inside their own apps) → sometimes provider-side hardening followed (DNS-ownership verification on claim, improving the whole class).
What makes the chain work isn't cleverness — it's that no single system did anything wrong: DNS pointed where it was told; the provider claimed what it was asked to. The failure lives entirely in the seam between them, which is why scanning for the seam (record exists × resource missing × claim open) catches this class mechanically.

Why the Class Persists (Organizational Rot)​

• Wildcard DNS. *.victim.com → some-platform.com patterns mean ANY subdomain ever created under the wildcard resolves toward third-party infrastructure — including ones nobody remembers creating. Wildcards multiply the attack surface by every historical subdomain ever issued.
• Subdomain sprawl without inventory. Marketing runs campaigns, devs spin staging, agencies build microsites — each adds DNS records; nobody adds them to an inventory with expiry dates. Research consistently finds large enterprises with hundreds-to-thousands of subdomains beyond their asset-management awareness.
• M&A residue. Acquired companies' DNS zones merge into corporate infrastructure without merging into security teams' scanning scope. Forgotten-brand microsites of acquired subsidiaries are takeover-class goldmines (documented repeatedly in bounty disclosures).
• Vendor-exit gaps. Offboarding a SaaS vendor checks accounts and contracts; DNS records pointing at the vendor live in a different system with a different owner — routinely missed in exit runbooks.
• TTL false confidence. Teams sometimes assume TTL expiry "cleans up" records — TTLs only control resolver caching, they never delete records. The record serves until explicitly removed.

Subdomain Takeover vs Neighboring Concepts​

Concept	Mechanism	Key difference
Subdomain takeover	Dangling DNS → claim third-party resource	The class this page covers — infrastructure lifecycle seam
Subdomain hijack (DNS-side)	Unauthorized DNS record modification itself (registrar/zone compromise)	Attacker changes the pointer; takeover exploits an EXISTING stale pointer
Subdomain squatting	Registering unregistered subdomains at the REGISTRAR level (dropped domains, unclaimed zones)	Domain-registration layer, not DNS-record-to-service layer
Brand impersonation	Lookalike domains mimicking the brand	Whole different domain; takeover rides the REAL domain
Supply-chain script compromise	Third-party JS is compromised while DNS correctly points at legitimate live resource	Resource is legitimately owned — the compromise is in the vendor's code, not an ownership gap

The distinctions matter because the response to each differs completely — misclassifying takeover as "we got hacked" sends IR down wrong paths when the actual finding is a stale DNS record with an asset-inventory fix.

The Research Line & The Standing Rules​

Consistent with every guide in this series (the OTP bypass chain model, the SQLi dorks recon framing): the vulnerability class above is documented openly — HackerOne's disclosed-report library is full of takeover writeups, OWASP maintains cheat sheets, MDN has an entry (a thin one — this is the deep version). Enumeration and fingerprinting are observation; attempting claims on infrastructure outside written scope is not. The bounty ecosystem that pays for this class exists precisely because authorized reporting channels exist — they're the lane where this skill has a career instead of a court date.
Standing rule one — never purchase CC or financial instruments from anyone. Same structure as everything else this site warns about: the takeover class shows how much of "security" is lifecycle seams nobody owns — the stolen-data market shows what happens when someone monetizes a seam you were sitting on. Both reward verification discipline over assumption.

Takeover findings look like magic and are actually bookkeeping: two systems, one stale record, zero ownership checks. Learn to read lifecycle seams — DNS-vs-resource here, config-vs-environment anywhere else — and you find a class of bugs that scanners call "infrastructure" and bounty programs call "payable."

FAQ​

What is a subdomain takeover?​

The condition where a subdomain's DNS record still points at a third-party resource that has been deleted or unclaimed at the provider, combined with a provider model letting anyone claim orphaned resource names. Claiming the resource gives content control on the victim's real subdomain — no software exploitation involved, just the DNS-record-vs-resource-lifecycle seam between two systems that never sync.

How dangerous is subdomain takeover?​

Impact chains from content control on a trusted domain: brand-perfect phishing pages under the victim's real domain, cookie-scope abuse depending on session configurations, SEO poisoning of the domain's search presence, and reputation inheritance for whatever gets served. Severity depends on the subdomain's scope (a forgotten campaign page vs. a SSO-adjacent host), which is why bounty payouts for the class historically range from moderate to significant — the class routinely chains into things defenders can't detect from inside their own applications.

How do you find subdomain takeover vulnerabilities?​

At concept level: enumerate subdomains (certificate-transparency logs are public and authoritative for what's been issued), read each record's CNAME/ALIAS targets for third-party patterns, and fingerprint responses for the provider's dead-resource error pages served under the target domain — that error page under the victim's URL is the signature. The tooling ecosystem automates exactly these three steps; understanding them first is what separates using a checker from interpreting one (and what keeps the claim-attempt step inside authorized scope).

Is subdomain takeover illegal to test?​

Enumeration and passive record observation live in normal internet-observation territory. CLAIMING the resource — controlling the orphaned slot — is where authorization matters: on programs with written scope (bug bounties routinely include this class), it's sanctioned research; outside scope it's unauthorized access to third-party infrastructure regardless of the dangling-state being the victim's misconfiguration. The disclosure ecosystem's norms (register + minimal proof + report + immediate remediation coordination) exist exactly because the class sits on that line — follow program rules, keep proofs minimal, never serve malicious content during testing.

What's the difference between subdomain takeover and subdomain hijacking?​

Takeover exploits an existing stale DNS record pointing at a claimable dead resource — nobody hacks anything; the record just outlived its target. Hijacking (DNS-side) means modifying the DNS record itself through registrar/zone compromise — an active compromise of DNS control. Different layers, different response playbooks: takeover fixes with record cleanup and asset inventory; hijack triggers full credential-compromise incident response.

Do big cloud providers still allow subdomain takeovers?​

The major platforms have been hardening claim models for years — several now verify DNS ownership before binding custom hostnames, closing their piece of the class. But the class has a long tail: smaller SaaS vendors, legacy integration points, and older provider behaviors persist, and the VULNERABILITY was never really the provider's claim model alone — it's the dangling-DNS-plus-no-inventory combination that organizations control. Provider hardening shrinks the taxonomy's well-known rows; the hygiene gap keeps generating findings on the rest.

How do you fix subdomain takeover risk?​

Three-layer answer (from the mechanism, not a vendor checklist): inventory every subdomain and what it CNAMEs to (you can't fix records you don't know exist — CT logs are the external truth source); tie DNS changes to resource lifecycle (teardown runbooks must include record removal — the stage-2 gap from the lifecycle table); and periodic dangling-scan automation (the same enum-fingerprint loop from the recon section, run on your own estate with authorization by definition). The class dies with bookkeeping, not products.

Where To Go From Here​

You've got the three-component definition, the DNS lifecycle gap with its five stages, the full dangling-resource taxonomy, the recon mechanics behind every checker tool, the end-to-end disclosure-shaped walk, the organizational-rot causes, and the concept-disambiguation table. That's the class mapped end to end — deeper than the prevention-checklist SERP this query usually returns.
BlackSec official channel: t.me/Blacksec_official — drops, tradecraft, community. Only official channel we run; anyone selling "takeover checkers" or "dork packs" under our name is running the buyer-predation economy dissected in the method-seller and nulled guides.
Related boards + series:

• General Hacking — home of the web-attack series: this guide, OTP bypass, and the recon-dorks pair — flow analysis across the whole attack surface
• Hacking Tools — where the enum-fingerprint loop graduates into tooling (authorized scopes)
• Courses — DNS internals, infrastructure architecture: understand why lifecycle seams exist and the finding class writes itself
• Carding Forums 2026 — evaluation discipline applied to a different surface

Rules unchanged: never purchase CC or financial instruments from anyone — and in this class specifically: scope in writing before claims, minimal proof after, records-not-runs as the fix philosophy. Lifecycle seams reward the patient; everything else is someone else's incident report.
— BlackSec crew. Taxonomy current for 2026 claim-models. Providers keep hardening the famous rows (bigger platforms verify DNS ownership now) — the long tail of smaller vendors and forgotten records is where this class keeps paying: when your live enumeration contradicts this page, trust the enumeration, document the seam, report it properly.