子域名接管

要解决的具体问题

当一个子域名如 sub.target.com 的 DNS 记录指向外部云服务（如 xxx.s3.amazonaws.com、xxx.herokuapp.com、xxx.github.io），而该外部资源已被删除或从未被认领时，若 DNS 记录未同步清理，攻击者只需在对应服务商处注册同名资源，即可让浏览器把目标子域名的内容指向攻击者控制的页面。这就是子域名接管（Subdomain Takeover）。常见影响包括：窃取父域 Cookie、拦截 OAuth 回调、在受信域名下钓鱼、绕过 CORS 与 CSP 白名单。若 NS 记录指向已失效的委派域，则可能导致整个 zone 的控制权丢失；若 MX 记录指向已注销的邮件租户，攻击者可接收密码重置邮件。

核心能力与关键步骤

该技能围绕 CNAME/NS/MX 三类记录展开检测与利用：

• CNAME 枚举：从子域名清单中提取指向第三方服务的 CNAME，并逐一发起 HTTP 探测。
• 指纹匹配：根据响应特征判断资源是否已被删除且可被认领。例如 S3 返回 NoSuchBucket（404）、Heroku 返回 No such app、GitHub Pages 返回 There isn't a GitHub Pages site here。若返回 403（bucket 存在但私有），则不可利用。
• 认领流程：按服务商要求创建同名资源并配置自定义域，常见目标包括 AWS S3、GitHub Pages、Heroku、Azure、Shopify、Fastly、WordPress.com 等。
• NS 接管：当 NS 委派指向失效域时，攻击者可控制整个 zone 的 DNS 解析、签发 DNS-01 TLS 证书、修改 SPF/DKIM/DMARC，危害远高于普通 CNAME 接管。
• MX 接管：当 MX 指向已过期的 Google Workspace / Microsoft 365 租户时，攻击者可创建新租户并接收目标域邮件。
• 泛解析风险：若 *.target.com 通配 CNAME 指向可认领服务，则任意未定义子域名都可能被接管，攻击面被显著放大。

适用边界与注意点

• CNAME 存在不等于可接管：必须确认后端资源已删除且可被第三方注册。403、默认停放页、品牌错误页需要逐项验证。
• 区域与验证：S3 bucket 名称全局唯一，但 website endpoint 分区域，需匹配 CNAME 中的区域。GitHub Pages 已加入域名所有权验证，组织验证过的域名无法被他人认领。
• 链路完整性：二阶接管要求沿 sub.target.com → other.target.com → dead-service.com 整条链追踪，中间任何一跳已失效都会改变结论。
• SPF 子域名接管：若 SPF 包含 include:sub.target.com 且该子域名被接管，攻击者可改写其 TXT 记录，授权自己的邮件服务器，伪造目标域邮件。
• 防御基线：删除云资源时同步移除 DNS 记录；监控 CNAME 目标的 NXDOMAIN 响应；审计 NS 委派域的所有权与续期；避免对第三方服务使用通配 CNAME。