Subdomain Takeover Attacks 2026: How Forgotten DNS Records Become Phishing Domains (And How to Audit Yours)

Disclaimer: This article is for educational and defensive security purposes only. The detection techniques described are intended to help domain owners audit and protect their own infrastructure. Performing reconnaissance against domains you do not own or have written permission to test is illegal in most jurisdictions, including under the U.S. Computer Fraud and Abuse Act (CFAA) and Indonesia's UU ITE.

A subdomain you forgot about can become a phishing site for your customers in less than a day — and you would not get an email, an alert, or a single hint until someone searches for your brand and lands on a stranger's page.

Across the seven aggregator sites I run at Warung Digital Teknologi, I have accumulated roughly 40 active subdomains over 11 years — staging environments, old marketing landing pages, a few one-off project demos for clients, and infrastructure subdomains for analytics and email. Two of them, I now realize, were dangling for several months in 2024 after I migrated a static site off Netlify without removing the CNAME. That's the precise condition a subdomain takeover attack exploits.

What is a subdomain takeover, exactly?

A subdomain takeover happens when a DNS record on your domain points to an external service (Heroku, AWS S3, GitHub Pages, Azure, Shopify, Fastly, Vercel, Netlify) and that external resource has been deleted or released — but the DNS record was never removed. An attacker who claims the now-orphan service name then controls content served on your subdomain.

Here is the simplified flow:

1. You point blog-old.yourcompany.com via CNAME to yourcompany.netlify.app.
2. You decide to migrate the blog to a different platform and delete the Netlify site.
3. You forget to delete the CNAME record at your DNS provider.
4. An attacker creates a new Netlify site and claims yourcompany.netlify.app as the custom name.
5. Visitors to blog-old.yourcompany.com now see whatever the attacker uploads — with your brand in the address bar and, in many cases, a valid HTTPS certificate.

What makes this dangerous in 2026 is that browsers display your subdomain in the URL bar, your favicon (if cached), and often your name in search results. Phishing emails sent from related infrastructure look legitimate to enterprise email gateways because the link does point to your real domain.

Why this attack is trending in 2026

According to CISA advisories and disclosed bug bounty reports throughout 2025–2026, three forces are driving an uptick in subdomain takeover incidents:

1. SaaS consolidation churn. Companies migrated from one platform to another aggressively in 2024–2025 (especially off Heroku after the free-tier shutdown), leaving thousands of orphan CNAMEs.
2. Automated discovery tools. Open-source projects like Subjack, Subzy, and OWASP Amass now scan public certificate transparency logs and resolve subdomains across the entire internet within hours of a new record appearing.
3. Cheaper service onboarding. Most affected SaaS platforms allow free-tier signups, so claiming an orphan subdomain costs an attacker nothing.

HackerOne disclosed in its 2025 annual report that subdomain takeover findings remained in the top 10 vulnerability categories by paid bounty value, with average payouts between $500 and $5,000 per finding.

Three real incidents worth studying

Public, disclosed cases are the best way to internalize what this looks like in practice:

• Microsoft (2020–2022). Researcher Michel Gaschet documented over 670 Microsoft-owned subdomains vulnerable to takeover via dangling Azure CloudApp records. Several were used in phishing campaigns before remediation. Documented in CVE-2021-46414.
• Chegg. An educational platform had a marketing subdomain taken over via an orphaned Amazon S3 bucket; the attacker hosted gambling content for several weeks before discovery.
• Starbucks. A 2020 HackerOne report (publicly disclosed) showed a subdomain takeover that could have been used to set cookies for the parent domain — turning a "static-content subdomain" into a session hijacking primitive.

The common thread: none of these companies were running shoddy operations. They had thousands of subdomains, and a handful slipped through the decommissioning process. That is the realistic threat model.

How attackers find vulnerable subdomains

Understanding the attacker's discovery process is what lets you cut them off. The standard reconnaissance pipeline is:

1. Enumerate subdomains using certificate transparency logs (crt.sh, censys.io), DNS brute-forcing (subfinder, amass), and search engine scraping.
2. Resolve each subdomain and capture the response — IP address, CNAME target, HTTP status code.
3. Match the CNAME target's fingerprint against a database of known-takeoverable services. Each platform returns a distinctive 404 or error page when an unclaimed name is requested. The can-i-take-over-xyz project maintains the canonical list of vulnerable fingerprints across 50+ services.
4. Claim the orphan service. Sign up for the platform, register the matching name, upload content.

The entire pipeline runs in a few hours against an organization with thousands of subdomains. This is not a manual, targeted attack — it is mass-scanning at internet scale.

Defense Part 1 — Inventory every DNS record you own

You cannot defend an asset you do not know exists. When I audited my own DNS earlier this year, I found three records pointing to platforms I no longer used. The first step is enumeration.

For each apex domain you own, dump the zone file from your DNS provider's UI or API. Then verify against external sources:

# Subdomain enumeration from passive sources (uses CT logs + DNS DB)
subfinder -d yourcompany.com -all -recursive -o subs.txt

# Resolve each subdomain and capture the CNAME target
dnsx -l subs.txt -cname -resp -o resolved.txt

# Compare against your DNS provider's authoritative zone file
diff <(sort resolved.txt) <(sort zonefile-export.txt)

The diff catches subdomains that exist in public CT logs but are missing from your provider's UI — usually wildcard records or third-party-created entries (Mailchimp, SendGrid, ConvertKit, status pages).

Defense Part 2 — Audit every CNAME pointing to a third-party service

This is the action that pays for itself within minutes. List every CNAME record where the target is not a subdomain of your own apex domain. For each external CNAME, verify the resource still exists and is still under your control:

# Pull all CNAMEs from your zone file
grep -i CNAME zonefile-export.txt > cnames.txt

# Resolve each and inspect the HTTP response
while read line; do
    target=$(echo "$line" | awk '{print $5}')
    status=$(curl -s -o /dev/null -w "%{http_code}" "https://$target")
    echo "$line -> HTTP $status"
done < cnames.txt

A 404 from the target, or a service-specific "no such site" page, is the signal. Cross-reference against the can-i-take-over-xyz fingerprint list. Anything matching a known signature is an active vulnerability — remove the DNS record immediately.

From my own 2026 audit: I had a CNAME for old-status.<site>.com pointing to a statuspage.io page I had cancelled in 2023. The page returned a 404 with the distinctive Statuspage error body. Atlassian (the parent company) requires re-verification for new claims, so the risk window was narrower than for some platforms — but a CNAME pointing to a dead service is always a finding worth remediating, even if the specific platform has hardened claim flow.

Defense Part 3 — Change your decommissioning process

Every subdomain takeover I have read about traces back to a missing step in a decommissioning workflow. The fix is procedural, not technical:

• Always delete the DNS record before deleting the external resource. If the order is reversed, even by 30 minutes, a continuous scanner can claim the orphan.
• Document every external service tied to a subdomain in one place. A simple spreadsheet works — columns for subdomain, target service, account owner, last-renewed date.
• Add subdomain decommissioning to the offboarding checklist for any departing employee. A surprising fraction of orphan records belong to ex-employees who set them up for a one-off project and never recorded the dependency.
• Avoid wildcard CNAMEs to third parties. A wildcard like *.staging.yourcompany.com CNAME yourapp.herokuapp.com creates an entire takeoverable subtree, not just one record.

Defense Part 4 — Set up continuous monitoring

Manual audits drift. The realistic threshold for me, given seven sites, is to scan continuously and review weekly. Options ranked by cost:

Tool / Service	Cost	What it covers
Subjack (open source)	Free	CLI scanner for known vulnerable fingerprints. Run as a daily cron job against your subdomain list.
OWASP Amass	Free	Broader subdomain discovery + takeover detection. Requires more setup but produces an inventory.
Detectify Surface Monitoring	From $89/month (2026 pricing)	Managed external attack surface scanning, includes takeover detection.
Certificate Transparency feeds (crt.sh + RSS)	Free	Email alerts whenever a new certificate is issued for any subdomain of your apex. Catches unauthorized takeover claims that use Let's Encrypt.

For my own ops, the free tier of crt.sh RSS plus a weekly Subjack cron is enough — the surface is small. For an enterprise with thousands of subdomains, a managed product pays for itself.

What to do if a subdomain has already been taken over

If you discover an active takeover — phishing content, gambling redirects, or just a stranger's site under your subdomain — work in this order:

1. Remove the DNS record immediately. This kills the attacker's access to your branding within the TTL window (usually 5 minutes to 1 hour).
2. Capture evidence. Screenshot the abusive content, save the HTTP response headers, log the resolved IP. You will need this for the platform abuse report and any law enforcement filing.
3. Report to the hosting platform. Every major SaaS platform has an abuse contact. Heroku, AWS, Netlify, GitHub, and Vercel all have documented takedown procedures.
4. Audit cookies and authentication scope. If the affected subdomain was inside the same parent domain as authenticated services, attackers may have been able to set cookies readable by your main site. Force a session reset for all users and review your Domain cookie attribute usage.
5. Notify customers if data exposure was possible. Many jurisdictions (GDPR, California CCPA, Indonesia's UU PDP) require breach notification when authentication scope was implicated, even if you cannot confirm misuse.
6. Consider filing with the FBI's IC3 or your national CERT if the takeover was used for phishing — they track campaign patterns and can sometimes link the attacker across multiple victims.

FAQ

Does HTTPS protect against subdomain takeover?

No. The attacker who claims the orphan service typically obtains a valid Let's Encrypt or platform-managed certificate, so the padlock icon appears as normal. HTTPS prevents someone in the network path from tampering with traffic, but it does not validate that you control the destination.

Does HSTS or DNSSEC help?

Marginally. HSTS prevents downgrade attacks on the subdomain but does nothing about who actually serves content there. DNSSEC prevents DNS spoofing in transit but cannot detect that your own DNS record now points to an attacker-controlled resource. The fix is DNS hygiene, not transport-layer cryptography.

What about second-level subdomains like blog.api.company.com?

Same risk model. Some attackers specifically target deep subdomains because they are forgotten more easily and rarely monitored. Include them in your inventory and audit.

If I use Cloudflare, am I protected?

Cloudflare introduced dangling DNS detection in its enterprise tier in 2023, and rolled out alerts to lower tiers in 2025. It detects CNAME targets that fail to resolve and flags them in the dashboard, but you must act on the alerts. Cloudflare does not automatically delete records — you remain the responsible party.

How often should I audit?

Quarterly manual audits, weekly automated scans, and immediate scans after any platform migration. Migration windows are when 80% of orphan records get created.

Sources and further reading

• OWASP Web Security Testing Guide — Test for Subdomain Takeover
• CISA Cybersecurity Advisories
• can-i-take-over-xyz — Service fingerprint database
• NIST Cybersecurity Framework
• HackerOne — Public disclosed reports

If you found this guide useful and you run any production websites, schedule a 60-minute DNS audit this week. It is the single highest-value security task you can do on a small ops team — the time-to-find ratio for orphan CNAMEs is unmatched by almost any other defensive activity.