Subdomain Takeover: How Trusted Domains Get Weaponized – and What Actually Stops It

In the advertising ecosystem, a domain’s reputation is currency. Years of legitimate traffic, institutional backlinks, and clean delivery history translate directly into deliverability, lower verification friction, and access to placements that newer domains simply cannot reach. That currency is exactly what subdomain takeover lets an attacker spend without ever earning it.

The mechanism is procedural rather than exotic: a CNAME record on a respectable domain still points to a cloud bucket, SaaS tenant, or PaaS app that was decommissioned months ago. An attacker re-registers the abandoned resource, and traffic to that subdomain now resolves to their page – sitting under a domain whose trust signals were built by someone else. No breach, no phished admin, no exploit in anyone’s code. Just a deprovisioning step that never happened.

We have been tracking this pattern from inside the verification stack for three years. In November 2022, our team flagged an iGaming landing page running under a subdomain of FC Barcelona’s official site during routine campaign monitoring on PropellerAds. Weeks later, the same pattern surfaced on expresstestdrives-qa.carmax.com, where the subdomain was managed through Azure while the root sat on Akamai.

In 2025, the abuse moved up the trust ladder: Indonesian .ac.id and .go.id zones – universities and municipal authorities – serving Mahjong Ways and Candy Bonanza variants into a market where online gambling is criminalised under Articles 303 and 303 bi of the Penal Code, with a handful of US universities and an Italian grocery domain rounding out the cluster.

This article walks through what subdomain takeover actually is, why it is structurally attractive to ad fraudsters specifically, what the three cases above show on different surfaces, and – the part most write-ups skip – what detection looks like in production when the textbook fingerprint signal is no longer visible because the attacker has already filled the empty resource.

---

TL;DR

• What it is
  A subdomain takeover (also called subdomain hijacking, dangling DNS attack, or CNAME takeover attack) happens when a DNS record on a domain you own still points to a third-party resource you no longer control. An attacker re-registers that resource and silently inherits your domain’s reputation.
• Why it matters in advertising
  Reputation systems trust the parent domain while content scanners look at the page, and a hijacked subdomain breaks that pairing: the domain looks safe, the page is malicious, and most pre-bid stacks do not reconcile the two by default.
• What actually stops it
  On the owner side: a live DNS inventory, a deprovisioning checklist that includes DNS, and continuous orphan-fingerprint monitoring of your own zone. On the ad-platform side: stacked signals (NS/IP consistency, content-vertical alignment, geo-vertical anomaly review) plus human review on edge cases. No single layer closes the gap.

---

What a Subdomain Takeover Actually Is

A subdomain takeover is a DNS hygiene failure rather than a software vulnerability. A record on a domain you own, usually a CNAME, sometimes an A or NS record, still resolves to a third-party service that you no longer control. 

The classic shape is promo.brand.com pointing to a cloud bucket, a SaaS tenant, or a PaaS app that has since been deleted, decommissioned, or returned to the provider, leaving the DNS entry resolving to a backend that no longer exists.

When an attacker spots the dangling reference, they re-register the abandoned resource on whichever provider the record points at, claiming the now-free S3 bucket name if the CNAME pointed to S3, registering the released app slug if it pointed to Heroku, creating a GitHub Pages site under the deleted username, or spinning up a tenant on the SaaS service the previous owner walked away from. 

Only one of those actions is needed in any given case, and from that moment forward, traffic to your subdomain resolves to the attacker’s content without any network breach, phished admin, or exploit in your code – they have simply moved into the empty room your DNS was still pointing at.

This is why OWASP files the issue under A05:2021 Security Misconfiguration rather than as a discrete vulnerability class. There is no software bug to patch, because the exposure is procedural: a deprovisioning step that did not happen.

The major cloud providers publish their own guidance on this failure mode, which is worth reading even if you do not run on their stack. 

Microsoft’s documentation on preventing dangling DNS entries and avoiding subdomain takeover is one of the more concrete operational references; AWS and Google Cloud have analogous notes. EdOverflow’s community list Can I take over XYZ? tracks which providers are currently vulnerable to which fingerprint patterns.

---

Subdomain takeover vs. related terms

The term overlaps with several others, and treating them as synonyms causes real confusion in incident reports.

• Dangling DNS attack. The same phenomenon, named from the DNS record’s perspective rather than the attacker’s.
• CNAME takeover attack. A subset in which the dangling record is specifically a CNAME pointing to a deprovisioned third-party host.
• Subdomain hijacking. Often used interchangeably with takeover, but in some incident reports, it refers to a credential or registrar compromise of a subdomain rather than a dangling-record reclamation. Read carefully.
• CMS / credential compromise. Different mechanism (legitimate hosting, attacker-controlled login), identical-looking outcome (attacker content under your domain).

---

Why This Attack Is Structurally Attractive to Ad Fraudsters

The interesting question is not whether subdomain takeover can be done – Detectify Labs and others demonstrated the mechanism years ago – but why it keeps paying off specifically in advertising.

---

Reputational arbitrage

A newly registered domain has no history, so reputation systems treat it cautiously, ad platforms throttle delivery, and verification vendors flag it for review. 

A subdomain on *.ac.id, *.go.id, or a .gov second-level domain inherits years of accumulated trust signals: backlinks, age, institutional context, and sometimes even allowlist entries in enterprise filtering tools.

For an actor pushing iGaming or other regulated-vertical funnels into geographies where direct advertising is restricted, the lift in deliverability is what carries the campaign economics rather than a marginal optimization on top of them.

---

Detection asymmetry

Reputation-based filters score the domain while content scanners score the page, and subdomain takeover decouples the two: the domain is genuinely high-trust, the page is genuinely malicious, and most pre-bid stacks do not reconcile that contradiction at scale. 

The defenses that do catch it – DNS-level resolution checks, NS-record consistency checks across the domain tree, behavioral traffic-pattern analysis – are not standard issue across the verification market.

What buying teams often miss is that the attacker never has to compromise the legitimate site at all. The legitimate site keeps functioning, the owner sees no abnormal logs, and any traffic anomaly lands on infrastructure the owner does not even monitor.

---

The attack chain, end-to-end

The dotted annotations are the defender artifact that should have caught the chain at each stage. The structural problem is that the artifacts live in different organizations: stages 1–3 are visible only to the domain owner; stages 4–5 are visible only to the ad platform and its verification vendors. Neither side has end-to-end visibility, which is why the attack pattern persists.

---

Three Cases That Show the Same Mechanism on Different Surfaces

The Adex anti-fraud team has documented the pattern across very different domain categories. Each case illustrates a different angle of the same exposure.

---

November 2022: FC Barcelona

During routine campaign verification on the PropellerAds network, an analyst flagged a link pointing to FC Barcelona’s official domain. 

The root domain resolved to AWS; the subdomain in question resolved through Google Cloud DNS, with mismatched IP infrastructure, hosting an iGaming page that had been live since late October. 

The full breakdown, including the NS-record mismatch that triggered the manual review, is in our original write-up of the FC Barcelona subdomain incident:

---

Late 2022: Carmax

A few weeks later, a near-identical pattern appeared on carmax.com, a high-traffic U.S. retailer. The root was on Akamai DNS; the suspicious subdomain – expresstestdrives-qa.carmax.com – was managed via Microsoft Azure and hosted iGaming content. 

The naming convention is worth pausing on: expresstestdrives-qa is plausible enough to look like a QA environment, a marketing or product team might genuinely have stood up, and that plausibility is what makes these takeovers hard to spot from inventory lists alone, a point we expanded on in the Carmax case analysis:

---

2025–2026: Indonesian institutional cluster

The most recent cluster, surfaced in early 2025 and reviewed through 2026, moved up the trust ladder. 

Affected landing pages were sitting under Indonesian .ac.id and .go.id zones: universities and municipal authorities, pushing iGaming creatives (Mahjong Ways, Candy Bonanza variants) into narrowly geo-targeted campaigns aimed at Indonesian users, a market in which all forms of gambling are criminalised under Articles 303 and 303 bi of the Penal Code and reinforced by Law No. 7 of 1974 and the 2024 update to the ITE Law, and where direct advertising of those creatives would be flagged on sight.

That prohibition is exactly the condition under which attackers most need institutional-domain cover. A handful of cases also involved U.S. universities and an Italian B2B grocery domain. Some were classic dangling-CNAME takeovers; others were traceable to outdated CMS installations or compromised admin credentials. The full inventory and the editorial position are in our coverage of the abuse of trusted domains in iGaming:

Three different surfaces produced the same underlying failure: a DNS record that outlived the resource it pointed to, or an admin surface that outlived its hardening.

---

What Detection Actually Looks Like in Production

In theory, subdomain takeover is trivially detectable, but in production, it is not, and the gap between the two is where most of the operational difficulty sits.

---

The textbook signal

The textbook signal is a fingerprint response from the orphaned cloud service: AWS S3 returns NoSuchBucket on a direct request, Azure returns a specific 404 template, GitHub Pages returns the “There isn’t a GitHub Pages site here” string, and Heroku returns “No such app”.

Some of these fingerprints have shifted recently – AWS changed CloudFront-to-deleted-bucket behavior at the end of 2023, so distributions now return a generic NotFound without the bucket name, which breaks scanners that match on the old string, but the underlying pattern of a fingerprintable orphan response still holds across the major providers.

Open-source tools: subjack, nuclei with the takeovers template set, and commercial attack-surface platforms automate this lookup at scale, and if you only had to defend your own perimeter, this would mostly work.

---

Why does it fail in advertising

In ad ops, you are not defending your perimeter; you are defending against the use of someone else’s dangling subdomain as a click destination. 

The signal you have access to is the URL submitted with a campaign, and that URL by design, after reclamation, resolves to a real page with a real certificate on a real trusted domain. The takeover fingerprint is no longer visible from outside because the attacker has already filled the empty resource.

What works in that environment is a different signal stack:

Detection layer	What it looks for	Where it works	Where it fails
Reputation scoring	Domain-level trust score	New, low-reputation domains	High-trust domain hosting malicious subdomain — passes
NS / IP consistency	Mismatch between root and subdomain authoritative servers	Root and subdomain on different infrastructure with no business reason	Large enterprises legitimately split DNS by function — false positives
Content classification	Page content vs. expected vertical of the domain	iGaming page on a .edu or vehicle retailer	Cloaked pages serving different content to crawlers vs. real users
Behavioural traffic analysis	Click patterns, geo concentration, conversion shape	Narrow geo / vertical anomalies on otherwise stable domains	Requires post-bid data; partial visibility before spend
Asset inventory hygiene	Owner-side audit of every DNS record and its resolution target	The original takeover before exploitation	Out of reach for advertisers and ad platforms — only the domain owner can run it

No single row in that table closes the problem. 

The Indonesian cluster, for example, first surfaced not through content classification but through a geo-vertical anomaly: online gambling is illegal in Indonesia, so concentrating iGaming-creative delivery into narrowly geo-targeted campaigns running almost exclusively on .ac.id and .go.id domains was the kind of country-vertical pairing nothing in those domains’ profile could plausibly justify. 

Content classification confirmed the finding and NS inconsistency explained the mechanism, but none of the three signals alone would have justified an automated block.

This is where the practical center of gravity lies for ad-platform security: stack layers with different blind spots, and accept that human review remains part of the loop for edge cases. 

---

How to Tell a Takeover Apart from Adjacent Threats

Subdomain takeover gets conflated with three nearby threats because the externally visible outcome is similar: attacker content reaching users from a domain that should be trustworthy.

Misclassifying the threat means the wrong people are paged, and the wrong fix gets applied.

	Subdomain takeover	CMS / credential compromise	Typosquatting / lookalike domain	Open redirect abuse
Domain ownership	Legitimate	Legitimate	Attacker-owned	Legitimate
Attack surface	Orphan DNS record	CMS or admin login	DNS registration	Web app logic (redirect parameter)
Visible to root-domain owner	Rarely — separate infrastructure	Sometimes — admin and access logs	No — different domain entirely	Yes — appears in app logs
First-line defense	DNS hygiene + orphan monitoring	Patching + MFA + admin hardening	Brand monitoring, registrar takedown	App-layer redirect allowlist
Typical detection signal	NS/IP mismatch + content anomaly	Login anomalies, file-system changes	Brand-similarity registration alert	Suspicious referrer chain

---

What Domain Owners Actually Need to Do

For the brand whose subdomain is being weaponized, the defensive picture is concrete. Most published advice on this collapses into four operational requirements that are easy to list and surprisingly hard to actually maintain.

---

1. Maintain a live DNS inventory

You need a live inventory, updated automatically, that lists every CNAME and external alias, the cloud account or SaaS tenant each record points to, and the business owner responsible for it. 

Takeovers almost always trace back to an inventory that doesn’t exist or has drifted out of date. AWS Route 53 Resolver query logs, Azure DNS analytics, or third-party DNS posture managers can populate the data automatically; the discipline is keeping the ownership column accurate.

---

2. Make DNS part of every deprovisioning checklist

When a marketing campaign ends, a SaaS contract is canceled, or a cloud resource is deleted, the corresponding DNS record must be removed in the same change window – a process problem more than a technical one. 

A useful gate is to require that no cloud resource can be deleted without a linked DNS-record disposition (delete, re-point, or document why kept), enforced in your change-management system.

---

3. Continuously monitor your own DNS surface

Several attack-surface vendors and open-source tools will continuously scan your zones for fingerprintable orphan responses, making this the cheapest mitigation and the one most consistently skipped. 

At minimum, schedule a weekly subjack or nuclei run against your full subdomain list, with results piped into your existing alerting.

---

4. Harden admin and CMS surfaces

Not every case in the 2025 cluster was a dangling CNAME; some were straightforward credential compromises on outdated CMS instances. 

Subdomain takeover and CMS takeover get conflated because the externally visible outcome is identical: an attacker hosting their content on your domain. The defenses are different (patching, MFA, admin IP allowlisting, removal of unused tenants), but the inventory discipline that catches one will surface the other.

---

A Self-Check Runbook

If you own a domain and want to know right now whether you have an exposed subdomain, the following gives you a defensible first pass. None of it is a substitute for a continuous program; it is what we recommend for a one-hour first audit.

---

Step 1. Enumerate your subdomains

Pull from every source you can:

• Your authoritative DNS provider’s zone export.
• Certificate Transparency logs (crt.sh, e.g., https://crt.sh/?q=%25.brand.com&output=json).
• Passive DNS providers (SecurityTrails, VirusTotal, Shodan).
• Internal CMDB and cloud-account exports.

Merge and dedupe the result; that combined list is what you will run scans against.

---

Step 2. Resolve every record and capture the response

For each subdomain, capture:

You are looking for two things: CNAMEs that point to third-party hosts, and HTTP responses that match a known orphan-fingerprint pattern.

---

Step 3. Run a fingerprint scan

Treat anything flagged as “vulnerable” as a candidate rather than a conclusion, because false positives are common, and every hit should be confirmed by hand before you alert an owner.

---

Step 4. Triage hits

For each candidate:

1. Confirm the third-party host actually returns the orphan signature (re-run the curl manually).

2. Identify the cloud account or SaaS tenant that the record points at.

3. Either reclaim the resource (preferred) or remove the DNS record. Reclaiming is safer because it prevents an attacker from racing you to the name.

---

Step 5. Wire it into change management

The audit only matters if it does not have to be redone manually next quarter. Land the subdomain list and the fingerprint scan into your CI/CD or scheduled-task runner, alert on diffs, and require a DNS-disposition entry on every cloud-resource deletion ticket.

---

Provider-Specific Notes

Reclamation behavior is not uniform across providers. The following are the patterns we have observed most often in 2024–2026 incidents; check current provider documentation before treating any of them as authoritative.

• AWS S3. Bucket names are global and reusable after deletion, and CloudFront distributions tied to a CNAME are the more common takeover vector once the distribution is removed. AWS now requires CNAME validation for some distribution types, but older configurations are not retroactively protected. As of late 2023, CloudFront no longer leaks the underlying bucket name in the error response when the bucket is missing, which complicates detection, but does not close the underlying takeover path – the dangling CNAME is still the failure, and the attacker who can identify the bucket name (often from old archives, JS bundles, or CT logs) can still reclaim it.
• Microsoft Azure. Azure introduced subscription-scoped DNS validation for App Service, Storage, and CDN endpoints in stages from 2019 onward, but tenants that predate the change or opted out of the validation flow remain exposed. The Microsoft Learn guidance linked above is the current operational reference.
• GitHub Pages. The “There isn’t a GitHub Pages site here” response is the canonical fingerprint. GitHub has tightened the takeover path with custom-domain verification – a custom domain on a verified organization cannot be silently reclaimed by re-registering the username – but unverified custom domains and *.github.io slots tied to deleted usernames remain exploitable, and the fingerprint is still the right signal to scan for.
• Heroku. App names are reusable after deletion, with the “No such app” response acting as the fingerprint.
• Netlify, Vercel, Fastly, Fly.io. All have variants of the same pattern. EdOverflow’s Can I take over XYZ? tracks the current status per provider and is the most reliable single reference.

---

Who’s Exposed, and What’s at Stake

The most common misreading of this category is that subdomain takeover is a problem of large brands with sloppy infrastructure, when in practice, smaller organizations are often more exposed: they spin up cloud resources for a campaign or a microsite, hand the work to an external agency, and lose track of the DNS record after the engagement ends.

The 2025 Indonesian cluster spans institutional domains without dedicated security operations, which is exactly the profile attackers prefer.

The second misreading is treating this primarily as a brand-safety problem, when it is also a compliance problem. A .gov or .edu subdomain hosting an unlicensed gambling page is not just reputationally awkward; it can expose the legitimate owner to regulatory risks they did not consent to and cannot easily document their way out of.

---

Where This Leaves the Defender

There is no single control that closes subdomain takeover end to end: domain owners shrink the exposure window through inventory discipline, ad platforms, and verification layers stack signals to catch the abuse downstream while accepting the false-positive cost, and neither approach is sufficient on its own.

The change of mindset worth taking from this is to stop treating a trusted domain in a campaign URL as a sufficient signal of legitimacy, which it has not been for several years. The work is to build the second-layer checks (NS consistency, content-vertical alignment, behavioral anomaly review) into the verification stack, and to treat any campaign that fails them as worth the friction of a manual review rather than the cost of a quiet impression on someone else’s hijacked subdomain.

That is a less satisfying conclusion than “deploy this tool and the problem goes away,” but it is closer to what the operational reality looks like.

---

Frequently Asked Questions

How do I check if my subdomain is vulnerable to takeover right now?

Pull a complete subdomain list from your authoritative DNS plus Certificate Transparency logs, resolve each record, and run a fingerprint scanner (subjack or nuclei’s takeovers templates). Anything returning a known orphan fingerprint – NoSuchBucket, “There isn’t a GitHub Pages site here”, “No such app”, and so on – is a candidate that should be confirmed by hand before remediation. The runbook above walks the steps end-to-end.

---

What tools detect subdomain takeover?

On the open-source side, subjack, nuclei (with the takeover templates), subzy, and dnsReaper are the staples for direct takeover detection, with BadDNS (released early 2025) now in the same category and worth tracking because it auto-syncs signatures from Nuclei and dnsReaper. aquatone remains useful for the preceding step – enumerating and visually triaging large subdomain lists, but it is not itself a fingerprint scanner. Most commercial attack-surface management vendors include takeover detection in their offering. EdOverflow’s “Can I take over XYZ?” repository is the canonical reference list of currently fingerprintable services.

---

How is subdomain takeover different from typosquatting?

Typosquatting uses an attacker-owned lookalike domain (brnd.com instead of brand.com), whereas subdomain takeover uses your real domain by hijacking a subdomain through a dangling DNS record. The defenses differ accordingly: typosquatting needs brand-monitoring and registrar takedowns, while takeover requires DNS hygiene and orphan monitoring.

---

Is the cloud provider or the domain owner responsible?

Operationally, the domain owner is responsible: the cloud provider’s contract typically allows resource names to be reused after deletion, and the dangling DNS record is the owner’s artifact. 

Some providers (notably Azure for several services) have added validation flows that block reclamation even when DNS is misconfigured, but ownership of the underlying procedural failure sits with the domain owner.

---

Can ad networks block subdomain takeover automatically?

Not from a single signal: reputation scoring alone passes hijacked subdomains because the parent domain is genuinely trusted, and while stacking NS/IP consistency, content-vertical classification, and behavioral anomaly review catches a meaningful fraction, false-positive rates on any single layer keep human review in the loop on edge cases.

---

What should I do if I find a takeover on someone else’s domain?

Disclose responsibly: identify the domain owner’s security contact through security.txt, the company’s vulnerability disclosure program, or a direct email to a security alias, and provide reproduction steps, the fingerprint response, and a short remediation recommendation. Do not host content on the reclaimed resource beyond what is necessary to demonstrate the issue.