subdomain-takeover

技能：子域名接管——检测与利用手册

AI 加载说明：涵盖 CNAME/NS/MX 接管、按提供商匹配指纹、认领流程和防御性监控。基础模型常会混淆“存在 CNAME”和“可能被接管”——关键在于 CNAME 指向的资源是否无人认领且可被认领。

0. 相关路由

• 当利用子域名接管绕过信任 *.target.com 的 SSRF 允许列表时，参见 ssrf-server-side-request-forgery
• 当 CORS 信任 *.target.com 时，参见 cors-cross-origin-misconfiguration——接管后可实现完整的跨域读取
• xss-cross-site-scripting 接管后可在目标源下执行脚本（窃取 Cookie、滥用 OAuth 重定向）
• 当 Host 路由导致子域范围的缓存或身份验证问题时，参见 http-host-header-attacks
• 当被接管的子域与主域共享缓存时，参见 web-cache-deception

---

1. 核心概念

发生子域名接管的条件：

1. sub.target.com 有一条 DNS 记录（CNAME、NS、A）指向外部服务
2. 外部资源已不再配置（已删除的 S3 存储桶、已移除的 Heroku 应用等）
3. 攻击者可以在提供商处注册／认领该确切资源名称
4. 攻击者现在可以控制通过 sub.target.com 提供的内容

影响：窃取 Cookie（父域 Cookie）、拦截 OAuth 令牌、在受信任域下进行网络钓鱼、绕过 CORS、通过列入白名单的子域绕过 CSP。

---

2. 检测方法

2.1 CNAME 枚举

1. Collect subdomains (amass, subfinder, assetfinder, crt.sh, SecurityTrails)
2. Resolve DNS for each:
   dig CNAME sub.target.com +short
3. For each CNAME → check if the CNAME target returns NXDOMAIN or a provider error
4. Match error response against fingerprint table (Section 3)

2.2 关键信号

信号	含义
CNAME → xxx.s3.amazonaws.com + HTTP 404 "NoSuchBucket"	S3 存储桶已删除，可被认领
CNAME → xxx.herokuapp.com + "No such app"	Heroku 应用已删除
CNAME → xxx.github.io + 404 "There isn't a GitHub Pages site here"	GitHub Pages 未被认领
CNAME 目标域名本身返回 NXDOMAIN	目标域名已过期或从未存在
CNAME → 提供商，但 HTTP 200 返回默认停放页面	可能可认领，也可能不可认领——需验证

2.3 自动化工具

工具	用途
subjack	自动检查 CNAME 接管
nuclei -t takeovers/	Nuclei 接管检测模板
can-i-take-over-xyz (GitHub)	查询哪些服务存在漏洞
dnsreaper	多提供商接管扫描器
subzy	快速验证子域名接管

3. 服务提供商指纹表

服务提供商	CNAME 模式	指纹（HTTP 响应）	可认领？
AWS S3	*.s3.amazonaws.com / *.s3-website-*.amazonaws.com	NoSuchBucket（404）	是 — 创建名称匹配的存储桶
GitHub Pages	*.github.io	There isn't a GitHub Pages site here（404）	是 — 创建仓库并启用 Pages
Heroku	*.herokuapp.com / *.herokudns.com	No such app	是 — 创建名称匹配的应用
Azure	*.azurewebsites.net / *.cloudapp.azure.com / *.trafficmanager.net	各种默认页面、NXDOMAIN	是 — 注册匹配的资源
Shopify	*.myshopify.com	Sorry, this shop is currently unavailable	是 — 创建店铺并添加自定义域名
Fastly	CNAME 指向 Fastly 边缘节点	Fastly error: unknown domain	是 — 将域名添加到 Fastly 服务
Pantheon	*.pantheonsite.io	带有 Pantheon 品牌标识的 404 Site Not Found	是
Tumblr	*.tumblr.com（自定义域名 CNAME）	There's nothing here / Whatever you were looking for doesn't exist	是
WordPress.com	CNAME 指向 *.wordpress.com	Do you want to register	是 — 在 WP.com 认领域名
Zendesk	*.zendesk.com	Help Center Closed / 错误页面上的 Zendesk 品牌标识	是 — 创建名称匹配的子域名
Unbounce	*.unbouncepages.com	The requested URL was not found	是
Ghost	*.ghost.io	404 Not Found Ghost 错误	是
Surge.sh	*.surge.sh	project not found	是
Fly.io	CNAME 指向 *.fly.dev	Fly.io 默认 404	是

---

4. 接管流程 — 常见服务提供商

4.1 AWS S3

1. Confirm: curl -s http://sub.target.com → "NoSuchBucket"
2. Extract bucket name from CNAME (e.g., sub.target.com.s3.amazonaws.com → bucket = "sub.target.com")
3. aws s3 mb s3://sub.target.com --region <region>
4. Upload index.html proving control
5. Enable static website hosting

4.2 GitHub Pages

1. Confirm: curl -s https://sub.target.com → "There isn't a GitHub Pages site here"
2. Create GitHub repo (any name)
3. Add CNAME file containing "sub.target.com"
4. Enable GitHub Pages in repo settings
5. Wait for DNS propagation (GitHub verifies CNAME match)

4.3 Heroku

1. Confirm: curl -s http://sub.target.com → "No such app"
2. heroku create <app-name-from-cname>
3. heroku domains:add sub.target.com
4. Deploy proof-of-concept page

---

5. NS 接管 — 高危

NS 接管远比 CNAME 接管危险：你可以控制该区域的所有 DNS 解析。

如何发生

target.com NS → ns1.expireddomain.com
                 ↓
attacker registers expireddomain.com
                 ↓
attacker now controls ALL DNS for target.com
(A records, MX records, TXT records — everything)

检测

1. Enumerate NS records: dig NS target.com +short
2. Check each NS domain: whois ns1.example.com → is the domain expired or available?
3. Also check: dig A ns1.example.com → NXDOMAIN/SERVFAIL?
4. Subdelegated zones: check NS for sub.target.com specifically

影响

• 完全接管域名（提供任意内容、拦截电子邮件、通过 DNS-01 签发 TLS 证书）
• 使用 DNS 验证从任意 CA 签发 DV 证书
• 修改 SPF/DKIM/DMARC → 以目标身份发送经过身份验证的电子邮件

---

6. MX 接管 — 拦截电子邮件

当 MX 记录指向已停用的邮件服务时：

target.com MX → mail.deadservice.com (service discontinued)

如果攻击者可以认领 mail.deadservice.com 或该邮件租户：

• 接收密码重置邮件
• 拦截敏感通信
• 可能重置使用基于电子邮件的身份验证的账户

常见场景

Google Workspace / Microsoft 365 租户过期 → MX 仍指向 Google/Microsoft → 攻击者创建新租户并认领该域名。

---

7. 通配符 DNS 风险

如果 *.target.com 有一个指向可认领服务的通配符 CNAME：

• 每个未定义的子域名都容易受到攻击
• anything.target.com 可以被接管
• 攻击面大幅增加

检测：dig A random1234567.target.com — 如果解析成功，则存在通配符。

---

8. 检测与利用决策树

Subdomain discovered (sub.target.com)?
├── Resolve DNS records
│   ├── Has CNAME → external service?
│   │   ├── HTTP response matches known fingerprint? (Section 3)
│   │   │   ├── YES → Attempt claim on provider (Section 4)
│   │   │   │   ├── Claim successful → TAKEOVER CONFIRMED
│   │   │   │   └── Claim blocked (name reserved, region locked) → document, try variations
│   │   │   └── NO → Service active, no takeover
│   │   └── CNAME target NXDOMAIN?
│   │       ├── Target is a registrable domain? → Register it → full control
│   │       └── Target is a subdomain of active provider → check provider claim process
│   │
│   ├── Has NS records → external nameserver?
│   │   ├── NS domain expired/available? → Register → FULL ZONE TAKEOVER
│   │   └── NS domain active → no takeover
│   │
│   ├── Has MX → external mail service?
│   │   ├── Mail service deprovisioned/claimable? → Claim tenant → EMAIL INTERCEPTION
│   │   └── Active mail service → no takeover
│   │
│   └── Has A record → IP address?
│       ├── IP belongs to elastic cloud (AWS EIP, Azure, GCP)?
│       │   ├── IP unassigned? → Claim IP → serve content
│       │   └── IP assigned to another customer → no takeover
│       └── IP belongs to dedicated server → no takeover
│
└── Post-takeover impact assessment
    ├── Shared cookies with parent domain? → Session hijacking
    ├── CORS trusts *.target.com? → Cross-origin data theft
    ├── CSP whitelists *.target.com? → XSS via taken-over subdomain
    ├── OAuth redirect_uri allows sub.target.com? → Token theft
    └── Can issue TLS cert for sub.target.com? → Full MITM

---

9. 防御与修复

操作	优先级
停用云资源时移除 DNS 记录	严重
监控 CNAME 目标的 NXDOMAIN 响应	高
使用 DNS 监控工具（SecurityTrails、DNSHistory）	高
删除 DNS 记录前认领/预留资源名称	高
审计 NS 委派 — 确保 NS 域名归属明确且已续费	严重
避免使用指向第三方服务的通配符 CNAME	中
实施证书透明度监控	中

---

10. TRICK 说明——AI 模型容易忽略的内容

1. CNAME ≠ 接管：指向 S3 且返回 403 的 CNAME（存储桶存在且为私有）并不代表存在漏洞。只有返回 NoSuchBucket（404）才算。
2. S3 的区域很重要：存储桶名称是全局唯一的，但网站端点按区域划分。尝试匹配 CNAME 中的区域。
3. GitHub Pages 验证：GitHub 增加了域名验证——组织已验证的域名无法被他人认领。检查目标是否使用了此功能。
4. 边缘情况：一些服务提供商（例如 Cloudfront）需要特定的分发配置，而不仅仅是认领域名。
5. 二阶接管：sub.target.com CNAME → other.target.com CNAME → dead-service.com——必须完整追踪整条链。
6. SPF 子域名接管：如果 SPF 包含 include:sub.target.com，而你接管了 sub.target.com，就可以修改其 SPF TXT 记录，将你的邮件服务器列入授权范围 → 以 target.com 的名义发送伪造邮件。