August 12, 2026

Subdomain takeover: the DNS attack that hijacks your brand overnight

Somewhere in your DNS zone file, there's probably a record you forgot about. Maybe a freelancer set up staging.yourbiz.com three years ago, pointed it at a Heroku app, and moved on. The app got shut down. The DNS record didn't. And right now, anyone in the world can claim that Heroku name and start serving phishing pages under your brand.

This is subdomain takeover. It's one of the quietest ways a small business gets impersonated, and most owners have no idea it's possible until Google flags their entire domain as unsafe.

What subdomain takeover actually is

Let's walk through the mechanism in plain terms.

When you (or someone on your team) sets up a service like Heroku, GitHub Pages, or an S3 bucket, you often want it to live under your own domain. So instead of using yourbiz.herokuapp.com, you create a DNS record — usually a CNAME — that points app.yourbiz.com at Heroku's infrastructure. That's a "dangling" record waiting to happen.

Here's the sequence:

You point staging.yourbiz.com → yourbiz-staging.herokuapp.com via CNAME.
Six months later, you shut down the Heroku app. The name yourbiz-staging becomes available on Heroku's platform.
Nobody removes the DNS record. It still points at yourbiz-staging.herokuapp.com, which no longer exists.
An attacker scans the internet, finds your dangling record, and creates a new Heroku app called yourbiz-staging.
Now staging.yourbiz.com resolves to the attacker's Heroku app. They control what shows up when someone visits your subdomain.

They didn't hack your website. They didn't guess a password. They didn't touch your DNS provider. They just claimed an abandoned name on a shared platform, and your DNS was already pointing customers straight to them.

The services that make this possible

Any platform where you can register a custom subdomain — and where names get released back into the pool when accounts close — is a candidate. The usual suspects:

Heroku — apps get deleted, the app name goes back to the pool.
GitHub Pages — if you delete a repo or a user account, someone else can create one with the same name and inherit any CNAMEs pointing at it.
AWS S3 buckets — bucket names are globally unique. Delete yours, someone else claims it, and if you had a CNAME pointing at bucket-name.s3.amazonaws.com, they now own that subdomain.
Vercel and Netlify — project names on the free tier can be reclaimed.
Shopify, Fastly, Zendesk, Tumblr, Squarespace, Unbounce — dozens of SaaS products let you attach a custom domain, and most of them will happily serve traffic for any custom domain that points at them without verifying you actually own it.
Azure blob storage and Azure websites — same story as S3.

The full list of vulnerable services runs into the hundreds. The security community maintains a public inventory of "fingerprints" — the response signatures each service returns when a subdomain points at an unclaimed target — and it grows every year.

The pattern is always the same: shared infrastructure + a naming system that lets any account claim any unused name + no verification that the person attaching a custom domain actually owns that domain.

Why this hurts a small business more than a big one

Enterprises have security teams that catch this stuff. You probably don't. And the damage lands harder on you for a few reasons.

Phishing under your brand. An attacker who controls login.yourbiz.com or secure.yourbiz.com can put up a page that looks exactly like your login. Your customers see a certificate that says yourbiz.com (many of these platforms auto-issue SSL for any custom domain), the URL says yourbiz.com, and they type in credentials or credit cards. Your customers don't blame the attacker. They blame you.

SEO poisoning. A takeover subdomain gets stuffed with spam content — usually gambling, pharmacy, or adult keywords in whatever language pays best. Google indexes it. Now searches for your business surface pages like blog.yourbiz.com/best-online-casino-2025. Your search ranking tanks, and it's your problem to clean up.

Google Safe Browsing flags your apex domain. This is the nightmare scenario. When Google detects malicious content on any subdomain, the flag often gets applied to the entire domain. Chrome, Firefox, and Safari all start showing the big red "Deceptive Site Ahead" warning for yourbiz.com. Overnight, your revenue drops to zero because nobody can reach your site without clicking through a scary warning page.

Email deliverability collapse. If your compromised subdomain gets used to send phishing emails, the reputation hit lands on your entire domain's sending reputation. Suddenly your legitimate invoices land in spam folders.

I worked on a WordPress incident last year — a Southern California contractor whose site had been quietly compromised by a previous developer's leftover access. The self-healing backdoor kept regenerating spam posts (115+ before we got in), and the SEO damage took weeks to reverse even after eradication. Subdomain takeover follows the same script: the initial breach is invisible, the cleanup is slow, and the reputation recovery is where most of the pain lives.

The freelancer and agency handoff problem

Almost every subdomain takeover I've seen or read about traces back to the same root cause: nobody owns the DNS inventory.

Here's how it happens in a small business:

A freelance developer sets up staging environments, marketing landing pages, and a docs site during a big project. They add DNS records as needed. Nobody writes them down.
The agency handling your rebrand spins up microsites for campaigns. They add DNS records. Nobody writes them down.
Two years pass. You've worked with three developers, two agencies, and a marketing consultant. Each of them added a handful of records. None of them left a clean handoff document.
Projects end. Services get canceled. DNS records stay.

If I ask a small-business owner "how many DNS records do you have and what do they all point at?" — 95% of the time, the answer is "I have no idea, my [freelancer/agency/nephew] handles that."

That's the actual vulnerability. The technical mechanism is real, but the underlying problem is organizational: no inventory, no ownership, no cleanup checklist.

The 20-minute DIY audit

You can do a rough version of this yourself in an afternoon. Here's the workflow.

Step 1: Pull your DNS zone

Log in to whoever runs your DNS. Usually this is your domain registrar (GoDaddy, Namecheap, Google Domains, Cloudflare) or your hosting provider. Find the DNS management section and export or screenshot every record.

You're looking for:

CNAME records — highest risk, these are the classic takeover target.
A records pointing at cloud provider IPs — S3, Azure, and others use IPs that get recycled.
NS records for delegated subdomains — a lower-frequency but higher-impact variant.

Ignore MX, TXT, and SOA records for this exercise. Focus on anything routing web traffic.

Step 2: List what each record points at

Make a spreadsheet. Three columns: subdomain, target, "do I still use this?"

staging.yourbiz.com    yourbiz-staging.herokuapp.com    ???
docs.yourbiz.com       yourbiz.github.io                 ???
shop.yourbiz.com       yourbiz.myshopify.com             yes
files.yourbiz.com      yourbiz-files.s3.amazonaws.com    ???

For every "???", you have a question to answer: is this service still active, and do you still control the account?

Step 3: Check each target with dig and curl

Open a terminal. For each subdomain, run:

dig +short staging.yourbiz.com
curl -sI https://staging.yourbiz.com

What you're looking for in the curl output:

"NoSuchBucket" — S3 subdomain takeover risk.
"There's nothing here" or "No such app" — Heroku takeover risk.
"There isn't a GitHub Pages site here" — GitHub Pages takeover risk.
HTTP 404 with a fingerprint page from the service — potential takeover risk on whatever platform's page you're seeing.
Connection refused or DNS resolution failure with no service response — usually safe, but investigate.

A legitimate, actively-used subdomain returns your actual site or app. A dangling one returns an error page from the underlying platform, and that error page is the fingerprint.

Step 4: Use subjack for automated scanning

If you have 30 subdomains, doing this manually gets tedious. There's an open-source tool called subjack (written in Go) that scans a list of subdomains against a fingerprint database and tells you which ones are vulnerable.

subjack -w subdomains.txt -t 100 -timeout 30 -ssl -c fingerprints.json -v

It's not perfect. It has false positives, and its fingerprints go stale. But for a first-pass sweep, it's the fastest way to identify obvious problems.

Detectify runs a commercial subdomain scanner that's more thorough and stays updated, if you'd rather pay for a service than run tooling yourself.

Step 5: Find subdomains you forgot existed

Your DNS zone shows what you know about. Attackers use passive DNS databases and certificate transparency logs to find subdomains you don't know about. You should too.

curl -s "https://crt.sh/?q=%25.yourbiz.com&output=json" | jq -r '.[].name_value' | sort -u

That pulls every subdomain that's ever had an SSL certificate issued for your domain. You'll almost certainly find some you forgot about.

What to do if you find a vulnerable record

If your audit turns up a dangling record, act in this order:

1. Verify it's actually abandoned. Check whether anyone on your team is still using that subdomain before you rip the record out. A "abandoned-looking" subdomain might be a legitimate service someone forgot to document.

2. Remove the DNS record. Once you've confirmed nobody needs it, delete the record from your DNS provider. This immediately closes the takeover window.

3. Check whether it's already been taken over. Before you delete, actually visit the subdomain in a browser (from a sandboxed environment, not your daily machine). If you see content you didn't put there, you've found an active takeover. Screenshot everything.

4. Search for existing abuse. Google site:staging.yourbiz.com and see what's indexed. If Google has already crawled spam or phishing content under your subdomain, you'll need to file a URL removal request in Google Search Console after you clean it up.

5. Check Google Safe Browsing status. Visit https://transparencyreport.google.com/safe-browsing/search?url=yourbiz.com. If your apex domain is flagged, that's an urgent incident-response situation.

6. Rotate anything the attacker could have collected. If the takeover was live for any length of time and your customers might have entered credentials thinking it was your legitimate site, you have a disclosure decision to make. Talk to a lawyer.

Prevention: build a DNS inventory before you need one

Fixing existing dangling records is the reactive half. The proactive half is making sure this never happens again.

Keep a living DNS inventory. A shared document that lists every subdomain, what service it points to, who owns that service, and what it's used for. Update it whenever anyone adds or removes a record. This is boring administrative work, and it's the single highest-leverage security practice for a small business's web presence.

Establish a cleanup order. When you cancel a service, remove the DNS record FIRST, then cancel. If you cancel Heroku before removing the CNAME, you've opened a takeover window that could last months.

Audit quarterly. Put a recurring calendar reminder — 30 minutes every three months — to run through your DNS records and confirm each one is still live and still yours.

Write a handoff checklist. Any freelancer or agency ending a project should hand over a written list of every DNS record they created, every third-party service they set up, and every account credential associated with your domain. If they can't or won't produce that list, that's a signal about how they operate.

Prefer platforms with domain verification. When choosing SaaS tools, prefer ones that require you to prove domain ownership (usually via a TXT record) before they'll serve traffic for a custom domain. This kills the entire takeover class.

Where this fits in the bigger picture

Subdomain takeover is one of those problems that stays invisible until it isn't. There's no error message, no failed login attempt, no ransom note. Everything looks fine right up until Google emails you that your site has been flagged, or a customer forwards you a phishing email that came from your own domain.

The technical mechanism is straightforward. The organizational mechanism — no inventory, no ownership, no handoff — is what makes it a small-business problem specifically. Enterprises have people whose job is to track this. You don't. So it has to become part of a checklist somewhere, or it doesn't get done.

If you'd like this handled properly, DNS audit and inventory is a Week 1 deliverable of the Site Hardening service at Thewizrdz — I'll pull your zone, run the takeover checks, produce a written inventory you can hand to any future developer, and give you a quarterly review cadence so it stays clean. Details are at thewizrdz.io/#security, or reach out through the contact form at thewizrdz.io if you'd rather just talk it through first.