Subdomain Takeover: a beginner's guide

A subdomain takeover is an attack where someone claims control of a subdomain of your brand by registering a SaaS account that matches a dangling CNAME in your DNS. The setup is almost always the same: years ago, somebody pointed `blog.brand.com` at `brand-team.herokuapp.com` for a marketing experiment. The experiment ended, the Heroku app got deleted, but nobody remembered to delete the CNAME. The CNAME now points at a Heroku name that's available for anyone to register. An attacker registers a new Heroku app under that exact name, serves arbitrary content, and suddenly has a live HTTPS site at `blog.brand.com` — complete with a valid certificate, indistinguishable from the real brand to anyone clicking a link. The can-i-take-over-xyz project maintains a running list of services vulnerable to this pattern; the count is in the dozens and growing.

You should care because subdomain takeover is a low-sophistication, high-impact attack that usually lives undetected for months or years. The pattern has produced public findings against Microsoft, Tesla, Uber, Starbucks, and hundreds of smaller brands. Every time a company deprovisions a SaaS account without cleaning up the DNS that pointed at it, a new takeover becomes available. Bug-bounty hunters actively farm this pattern and collect meaningful payouts for each confirmed finding on HackerOne and Bugcrowd — because the consequences range from hosting phishing content under the real brand to stealing authentication cookies scoped to the parent domain.

The five things every subdomain-takeover check looks at:

• CNAME targets for every subdomain. Enumerate every `blog.brand.com → something.saas-provider.com` relationship. The CNAME target, not just the presence of a CNAME, is what matters.

• Matching against known-vulnerable services. GitHub Pages, Heroku, AWS S3, Azure Blob Storage, Netlify, Fastly, Shopify, WordPress.com, Readme.io, Ghost, Cargo, Tumblr, and others. Each has a distinctive fingerprint in the CNAME target and a specific response-body signature when the target has been deleted.

• HTTPS response body fingerprinting. A dangling CNAME often returns a provider-specific "this site doesn't exist" page ("There isn't a GitHub Pages site here", "No such app" from Heroku, "NoSuchBucket" from S3). Matching the body against the service's known indicator confirms the takeover.

• Orphan subdomain discovery. The CNAME might be on a subdomain nobody at the company remembers setting up. Enumerating `www`, `api`, `blog`, `dev`, `staging`, `cdn`, `support`, `docs`, and `assets` as candidates catches most of them.

• Certificate transparency log cross-reference. CT logs show every cert ever issued for the domain; cross-referencing with the current DNS reveals subdomains that had valid HTTPS at some point but no longer resolve.

Three questions a subdomain-takeover check answers:

• Do I have any dangling CNAMEs pointing at deprovisioned SaaS accounts?

• Is the `brand-name` on the far end of the CNAME currently available to register with the underlying service?

• If an attacker registered that name right now, would they control a subdomain of my brand?

The cost of leaving subdomain takeovers unaddressed is the silent presence of attacker-controllable subdomains under your brand — and the phishing campaigns that will eventually use them. The fix is continuous scanning for dangling CNAMEs and a disciplined offboarding process that cancels the CNAME the same day the SaaS account is deprovisioned. The HackerOne Hacktivity stream shows the steady drumbeat of public disclosures, and Detectify's Labs write-ups cover the attack patterns in detail.

In one sentence: Detect dangling CNAMEs vulnerable to subdomain takeover

Probes candidate subdomains for dangling CNAMEs pointing to known takeover-prone services (GitHub Pages, Heroku, S3, Azure Blob, Fastly, Netlify, Shopify, WordPress.com, Readme.io, etc.). When a CNAME (Canonical Name record) target matches a known SaaS fingerprint, probes the HTTPS (secure HyperText Transfer Protocol) endpoint and matches the response body against the per-service takeover indicator (e.g., "There isn't a GitHub Pages site here"). Reports each finding with the vulnerable service, evidence, and remediation steps.

Don't worry if some of the words above are still unfamiliar — there's a plain-language glossary at the bottom of this page, and most of the terms link to their own beginner guides if you want to learn more.

Here's what's actually happening behind the scenes when you call this endpoint:

Accepts either an explicit list of subdomains to probe or seeds from common names (www, mail, blog, API, dev, staging, docs, support, CDN, assets, status, etc.). For each candidate: (1) DoH (DNS over HTTPS) CNAME (Canonical Name record) lookup; (2) if CNAME target matches a takeover fingerprint, HTTPS (secure HyperText Transfer Protocol) GET the candidate; (3) body match against the service's takeover indicator text. Fingerprints currently cover 15+ services including GitHub Pages, Heroku, AWS S3, Azure Blob Storage, Fastly, Netlify, Shopify, WordPress.com, Tumblr, Readme, UserVoice, Ghost, Cargo Collective, and Unbounce. Returns per-candidate status plus an aggregated list of confirmed takeover-vulnerable subdomains.

If you're using an AI assistant through MCP, you don't need to understand any of the technical details — the assistant calls the tool and translates the result for you.

Let's skip the marketing fluff and answer the only question that actually matters: why should you, a real human with a real to-do list, care about the Subdomain Takeover tool? Here's the plain-English version, written the way you'd hear it from a friend who happens to do this for a living.

Subdomain takeover is a low-sophistication, high-impact attack that persists for months or years after infrastructure deprovisioning. Teams forget that a blog.example.com CNAME (Canonical Name record) still points to a cancelled Heroku app — until an attacker registers that app name and suddenly hosts malware under the legitimate brand. Automated detection catches these dangling CNAMEs during DNS (Domain Name System) audits rather than during an incident.

Picture this in real life. Imagine a security engineer. Here's the situation they're walking into: Weekly scan of enumerated subdomains to catch new dangling CNAMEs created when teams tear down SaaS infrastructure. Without the right tool, that person would be stuck copy-pasting between five browser tabs, reading documentation written for engineers, and crossing their fingers that the answer they cobble together is correct. With the Subdomain Takeover tool, the same person gets a clear answer in seconds — no spreadsheets, no guessing, no waiting for someone on the infrastructure team to free up.

Three questions this tool answers in plain English. If any of these have ever crossed your mind, the Subdomain Takeover tool is built for you:

• Is my website encrypted properly, or are visitors going to see a scary browser warning?

• Am I missing any of the security headers that modern browsers expect?

• Could a known weakness on my site quietly be costing me trust, traffic, or compliance?

You can either click the tool and get the answer yourself, or ask your AI assistant — connected through MCP (Model Context Protocol) — to ask the question for you and translate the answer into something you can paste into Slack.

Who gets the most out of this. Founders and freelancers running their own sites, agencies handing off projects to clients, security and compliance teams chasing audit findings, and developers hardening login pages. If you see yourself in that list, this is one of the EdgeDNS tools you should bookmark today.

What happens if you skip this entirely. Skip it and visitors get browser warnings, search engines lose trust in your site, and a single missed setting can become a public security incident. That's why running this check — even once a month — is one of the cheapest forms of insurance you can give your domain.

If you're still on the fence about whether the Subdomain Takeover tool belongs in your toolbox, this section is for you. Below you'll meet three real people — a security engineer, a red team lead, and an IT integration lead — facing three real situations where this tool turns a stressful afternoon into a five-minute task. Read whichever story sounds closest to your week.

Story 1: Continuous Subdomain Hygiene

Imagine you're a security engineer. Weekly scan of enumerated subdomains to catch new dangling CNAMEs created when teams tear down SaaS infrastructure.

Why it matters: Detect and remove orphaned CNAMEs before attackers find them.

Story 2: Pen-Test Preparation

Imagine you're a red team lead. Enumerate vulnerable subdomains before a red-team engagement so findings can be exploited in-scope.

Why it matters: Confirm attack surface before engagement kickoff.

Story 3: M&A DNS Cleanup

Imagine you're an IT integration lead. Sweep acquired-brand DNS (Domain Name System) for dangling SaaS CNAMEs as part of integration hygiene.

Why it matters: Remove inherited takeover risk during integration.

Common situations across teams. Beyond the three stories above, here are the everyday workplace moments when people across the company reach for the Subdomain Takeover tool — or one of the tools right next to it in this category. If any of these are on your calendar this month, that's your sign:

• After every site redesign or platform migration.

• Before a penetration test, security review, or vendor questionnaire.

• When your SSL certificate is about to expire and you want to confirm the renewal worked.

• On a recurring monthly schedule, so you catch new issues before attackers do.

If you can see yourself in even one of those bullets, the Subdomain Takeover tool will pay for itself the first time you use it.

Still not sure? Here's the easiest test in the world. Open Claude, ChatGPT, Gemini, or any other AI assistant connected to the EdgeDNS MCP server and ask, in your own words: "Is the Subdomain Takeover tool useful for my job?" The assistant will look at the tool, ask you a couple of follow-up questions about what you're trying to accomplish, and give you a straight answer in plain English. No commitment, no signup forms, no jargon.

If you've connected the EdgeDNS MCP server to Claude, ChatGPT, Gemini, Cursor, or any other AI assistant, you don't need to write any code. Just ask in plain English:

"Use the Subdomain Takeover tool to check example.com and explain anything that looks wrong in plain language."

The AI will figure out which tool to call, fill in the right parameters, run it, and then explain the result back to you. No copy-pasting between tabs. No reading raw JSON. No memorizing endpoint names.

If you're a developer and want to call the endpoint from a script or your own application, here's the simplest possible example. Replace the placeholder API key with the real one from your dashboard.

You need to provide 2 pieces of information when you call this tool. The table below lays them out side by side, with a real example for each one so you can see exactly what to send.

When you call this tool, you'll get back a JSON object with the fields below. If you're talking to it through an AI assistant, the assistant reads these for you and explains them in plain language — you don't need to memorize them.

These tools pair naturally with Subdomain Takeover. If you're already running this check, the related ones often answer the next question that comes up:

• DNS Lookup — Query any of 22 DNS record types or ALL at once with DNSSEC validation

• Wildcard DNS — Detect wildcard DNS configuration

• CT Logs — Search Certificate Transparency logs

If you're using an AI assistant through MCP (Model Context Protocol), you can ask it to run several of these in one go: "Check Subdomain Takeover and the related tools for example.com and tell me what looks off."

If any words on this page felt like jargon, here's a plain-language version. Click any linked term to read a full beginner-friendly guide.

DNS (Domain Name System) — The internet's address book. When you type a website name, DNS turns it into the actual numeric address computers use to find each other.

CDN (Content Delivery Network) — A worldwide network of servers that store copies of your website close to your visitors so pages load fast.

API (Application Programming Interface) — A way for one program to ask another program for something — like a waiter taking your order to the kitchen.

HTTPS (secure HyperText Transfer Protocol) — HTTP with encryption — the little padlock in your browser. It means nobody between you and the website can read what you're sending.

CNAME (Canonical Name record) — A DNS entry that says "this name is just an alias for that other name."

DoH (DNS over HTTPS) — A modern way of sending DNS queries that hides them inside encrypted HTTPS traffic, so people on the same network can't see which websites you're looking up.