osint-methodology

OSINT 方法论 — 外部红队版

0. 何时使用此技能／何时不使用

在以下情况下使用此技能：

• 规划或执行针对已获授权目标的外部侦察（红队、范围内的漏洞赏金项目、ASM 项目）。
• 端到端绘制组织的外部攻击面（子域名 → 资产 → 暴露面 → 攻击路径）。
• 调查个人、实体或威胁行为者，且需要严谨处理证据。
• 追踪加密货币流向、对媒体进行地理定位、开展图像／视频取证，或对事件进行时间定位。
• 构建结构化 OSINT 行动，且需要确保可复现、进行严重程度分级并顺利交接。
• 根据攻击性测试项目制作面向客户的交付成果（执行摘要、技术报告、复现材料包）。

在以下情况下不要使用此技能：

• 用户要求主动利用漏洞、利用后操作、横向移动、AD 权限提升、恶意软件开发，或任何超出侦察范围的内容——这些都不在适用范围内。
• 用户要求蓝队／防御内容（SIEM 规则、检测工程）——这属于不同领域。
• 目标的授权状态不明确，且用户要求你针对其不拥有的第三方资产采取行动——请参阅下方 §1；在继续之前，温和地询问范围问题。

---

1. 授权与法律立场

此技能适用于操作者拥有或已获得书面授权评估的资产（红队参与规则、漏洞赏金范围内资产、ASM 合同）。

温和确认范围： 如果用户要求你针对某个目标采取行动，而对话中此前未确认授权，请在继续之前询问一次：

“先快速确认一下范围：这是你拥有或已获得书面授权评估的目标吗（例如红队项目、范围内的漏洞赏金资产，或你自己的基础设施）？我想确保我们没有超出项目范围。”

一旦用户确认已获得授权，就继续操作，无需再次询问。如果用户明确说明了项目类型（例如，“这是我们根据合同对 acme.com 进行的渗透测试”），就不需要再次询问。

始终适用的防护措施（无论是否获得授权）：

• 绝不削弱目标端用于执行范围限制的身份验证、速率限制、横幅或任何安全控制。
• 除非明确启用 DEEP／--aggressive 模式，否则绝不执行破坏性探测（在生产环境中进行真正的 SYN 扫描、以线路速率运行 masscan、模糊测试／暴力破解）。
• 绝不将真实个人身份信息、有效凭据、会话令牌、API 密钥或其他机密粘贴到云端大模型或第三方服务中。
• 绝不对文档范围之外的资产采取行动，即使这些资产“显然有关联”（子公司、供应商、员工个人账户等）。

---

2. 置信度等级

在项目期间作出的每项断言都应标注置信度。共有三个等级：

等级	含义	示例
TENTATIVE（初步）	基于间接证据，具有合理可能性；尚未验证。	仅搜索摘要匹配 Google dork；根据姓名推断电子邮件格式；仅由一个被动数据源返回的子域名；favicon 哈希重合（两个主机共用一个 favicon——可能是共用基础设施，也可能只是巧合）。
FIRM（有力）	已直接观察到，但尚无佐证。	能解析到 IP 的子域名；通过 HEAD 请求确认存储桶存在（私有）；CT 日志中出现证书记录；Shodan 返回横幅信息。
CONFIRMED（已确认）	有多个独立佐证，或已直接验证。	已验证有效的 PMAK 令牌（只读 /me 返回 200）；泄露数据语料库、crt.sh 和 DNS 结果一致；存储桶可列出且文件可检索；已枚举出用户，且密码重置流程返回有效提示。

归因三原则： 断言关联关系前，需要三个独立的弱信号，或一个强信号加一个弱信号。不要仅依据单一来源进行归因。

2.1 置信度升级工作流

置信度并非一成不变——每个 TENTATIVE 资产都应有一条记录在案的升级路径，先升级为 FIRM，再升级为 CONFIRMED。请按资产类型遵循以下规则。

资产类型	TENTATIVE → FIRM	FIRM → CONFIRMED
子域名	由 ≥2 个独立被动来源返回，或 DNS A/AAAA/CNAME 解析成功。	在标准端口（80/443/22 等）上提供服务，且返回 HTTP 标头 / TLS 证书 / SSH 标头。
IP	通过 ≥2 个来源发现（被动 DNS、ASN 查询、Shodan）。	主动探测有响应（至少一个端口返回 TCP SYN-ACK，或收到 ICMP 回显应答）。
Web 应用	从 JS / API / archive 中提取 URL，但尚未访问。	HTTP 请求返回 2xx/3xx/4xx（任何非网络错误响应），且 content-length > 0。
电子邮件	根据姓名模式生成，或由仅返回摘要片段的 dork 返回。	列于 Hunter.io / EmailRep / IntelX / 泄露数据语料库中，或 SMTP 探测的 MAIL FROM/RCPT TO 返回 250（不投递邮件——在 DATA 阶段中止）。
存储桶（S3/GCS/Azure）	排列组合候选；尚未探测。	HEAD 返回 200、301 或 403（确认存在）。之后，GET 返回对象列表或成功获取已知对象时，升级为 CONFIRMED。
端点（API / wayback）	从 JS 正则 / Wayback / Postman 中提取。	HTTP 请求返回非 404 状态码（路由存在）。之后，端点行为（身份验证状态、响应结构、速率限制）完成指纹识别时，升级为 CONFIRMED。
凭据 / 密钥	与捕获文本中的目录正则表达式匹配。	只读验证器（/me、auth.test、sts:GetCallerIdentity、/user）返回成功。之后，记录其范围和账号 ID 时，升级为 CONFIRMED。
人员	从单一来源提取姓名（LinkedIn / 泄露数据 / GitHub 提交记录）。	由第二个来源确认（Hunter.io 中的职位 + LinkedIn 个人资料，或两个包含相同电子邮件地址的泄露数据来源）。
仓库	在 GitHub 搜索中，名称与组织关键词匹配。	仓库元数据确认组织 / 电子邮件 / 网站匹配。之后，提交历史显示有员工参与时，升级为 CONFIRMED。
移动应用	应用商店中的名称匹配。	所有权置信度得分 ≥70（参见配套技能 §21）。之后，二进制元数据（签名证书、包名、开发者账号）与目标关联时，升级为 CONFIRMED。
证书	由 crt.sh 返回一次。	在 ≥2 个 CT 日志中确认日志条目。之后，该证书在已发现的主机上提供服务时，升级为 CONFIRMED。
SSO 租户	发现端点返回 OIDC 元数据。	提取租户 GUID，且域名通过租户预期的 MX / autodiscover / SP 记录进行解析。

默认报告原则： 没有明确的佐证，绝不声称资产已 CONFIRMED。如有疑问，降低置信度。操作人员更信任有所保留的判断，而非夸大其词。

---

3. 输出格式约定

在进行中的会话中生成发现结果时，请按照以下架构组织每项结果——这样就能直接导入 asset-managementtools。

Finding:
  id:           <stable hash or UUID>
  module:       <which technique discovered it; "manual" if hand-found>
  asset_key:    <typed key, e.g. sub:api.example.com or webapp:https://example.com/admin>
  category:     <e.g. SECRET_LEAK, MISSING_HSTS, OPEN_GRAPHQL_API, LEAKED_CRED, SSO_EXPOSURE>
  severity:     <info|low|medium|high|critical>
  confidence:   <tentative|firm|confirmed>
  title:        <one-line summary>
  description:  <2-5 sentences>
  evidence:
    url:        <where it was found>
    timestamp:  <UTC ISO8601>
    sha256:     <hash of any downloaded artifact>
    raw:        <truncated to 2 KiB>
  references:
    - <CVE-ID, advisory URL, vendor doc>
  remediation:  <action the asset owner can take>

始终使用 UTC 时间戳。本地时间会导致笔记 / 屏幕截图 / 日志之间的关联错误。

---

4. 来源规范与引用

对于捕获的每项内容，请记录：URL + UTC 时间戳 + SHA-256 哈希值 +命令行版本 + run_id。

• 对所有下载的文件计算 SHA-256 哈希值。
• 使用 PNG 格式截图（无损，且证据包比完整页面 WARC 更小）。
• 捕获原始 HTTP 请求 / 响应，响应正文最多保留 2 KiB，以减小证据包。
• 使用 JSONL（NDJSON）日志，每个事件占一行，并附上 run_id，以便重放整个参与过程。
• 将只读证据与工作副本分开；绝不编辑已捕获的内容。

在输出中引用来源时，优先使用持久性引用（CVE、供应商公告、ATT&CK 技术 ID、RFC），而非短暂来源（Twitter 帖子、论坛主题）。如果唯一来源是短暂来源，请先将其存档（archive.today、Wayback SavePageNow），再进行引用。

---

5. 不要做的事（硬性规则）

• 不要将凭据、会话令牌、API 密钥、真实个人身份信息（PII）、信息窃取程序日志或独特的关联线索粘贴到云端大模型（ChatGPT、Claude.ai、Gemini、Perplexity）中。敏感分析请使用本地模型（Ollama、LM Studio、GPT4All）。
• 不要假定供应商标签就是事实依据。交叉核验标签：TRM、Chainalysis、Arkham 可能会有分歧。将每个标签都视为假设。
• 不要假定跨链桥资金流是 1:1。跨链桥、混币器和包装资产会引入铸造／销毁语义；请通过链上证明进行验证。
• 不要仅凭单一信号断言所有权。网站图标哈希重叠、共享 CT 颁发者、共享 NS——每一项都只是假设。需要满足三项规则。
• 除非处于明确的 DEEP／--aggressive 模式，否则不要在目标范围外运行模糊测试、SYN 扫描、masscan 或 nuclei fuzzing/* 模板。
• 除只读验证外，不要将凭据验证器用于任何其他操作（不要创建／删除／发送）。
• 不要镜像思维（假设目标的思维方式与你相同）。应区分能力、意图和资助方。
• 不要混淆相关性与控制权。
• 遇到主动防御时不要升级操作；应停止并记录（参见 §6.4）。

---

6. 操作安全（OpSec）

6.1 傀儡账号

傀儡账号是无法关联到你的虚假账号。建立发帖记录，让账号逐渐变得成熟，并在单独的浏览器配置文件中使用。

资源与技巧：

• 人设生成：Fake Name Generator、This Person Does Not Exist。
• 浏览器隔离：Firefox Multi-Account Containers，或为每个人设使用专用配置文件。
• 一次性电话号码：Burner、Silent Link（部分平台会拒绝 VoIP 号码——请预留一批号码）。
• 为任何高价值人设使用硬件通行密钥；将恢复代码离线保存。
• 安装前审查每个浏览器扩展。针对热门扩展的供应链攻击曾多次以调查人员为目标——应假设热门扩展的风险更高，而非更低。
• 维护证据保管链：为每项操作添加时间戳，为每个关键证据计算哈希，并按案件记录命令行版本。
• 人设应看起来像真实的低活跃度账号：资料照片（合成）、简介，以及在账号“启用”前数周内零星发布的几条低投入帖子。

参考资料：

• 有效的傀儡账号
• 傀儡账号终极指南

6.2 可检测性与 OpSec 标记

每次探测都会留下痕迹。在笔记中为每项操作标记可检测性级别，以便判断在目标一侧留下了怎样的 SIEM 记录。

标记	示例
低	被动查询 Shodan InternetDB；CT 日志查询（crt.sh）；Wayback CDX；被动 DNS（SecurityTrails）；Hunter.io 邮箱信息补充；对公开存储桶发送 HTTP HEAD 请求；getuserrealm.srf；获取 Microsoft OIDC 元数据。
中	Microsoft GetCredentialType 用户枚举；Okta /api/v1/authn 用户枚举；Postman API 密钥验证；AWS sts:GetCallerIdentity（记录到 CloudTrail）；Slack auth.test；整页截图；针对 28/13 路径字典的 Swagger/GraphQL 探测；定向 favicon 哈希 + JARM 指纹识别。
高	主动端口扫描（naabu / masscan / nmap）；针对生产环境运行完整 Nuclei 模板；大规模子域名暴力枚举；从第三方镜像下载 APK；对每个租户进行超过 N 次的深度模式用户枚举；SMTP RCPT TO 枚举；Web 模糊测试（ffuf/gobuster）。

与客户合作时，请在项目报告中记录实际执行的操作及其可检测性标记。客户会很乐意了解其检测系统本应捕获哪些活动。

**默认做法：**默认采用被动方式。仅在以下情况下执行主动探测：(a) 获得明确授权；(b) 在约定的维护时间窗口内；(c) 操作者了解由此产生的日志量。

6.3 验证器规范

当你在野外发现凭据（泄露的 API 密钥、通过 sourcemap 暴露的令牌、公开 Postman 工作区中硬编码的 PMAK）时，可能会想确认其是否仍然有效。此时只能使用只读验证器。

规范：

• 仅使用只读端点（例如 /me、/whoami、auth.test、sts:GetCallerIdentity）。
• 绝不使用已验证的凭据创建、修改、删除或发送任何内容。
• 为验证尝试标记可检测性——每个验证器都会在服务提供方一侧生成审计日志条目。
• 记录 checked_at（UTC）、响应内容（截断后）以及返回的作用域/账号 ID。
• 如果操作者的交战规则禁止验证，则将凭据标记为 validation_skipped_by_policy 并停止操作。

具体验证器端点（Postman、AWS、GitHub、Slack、Anthropic、OpenAI、npm、Atlassian、DataDog）见配套的 offensive-osint 技能。

6.4 检测感知探测（检测迹象 + 退避）

探测最终会触发检测。识别这些迹象，并在触发主动响应之前退避。

已被检测到的迹象（严重程度大致递增）：

1. 速率限制响应 — 429 Too Many Requests，设置了 Retry-After 标头，X-RateLimit-Remaining: 0。
2. 验证码中间页 — Cloudflare 中间页、hCaptcha 验证挑战、AWS WAF 页面。
3. WAF 页面 — 带有服务商品牌标识（Cloudflare、Akamai、Imperva、F5 ASM、AWS WAF、Sucuri）的明确“拒绝访问”页面。
4. 状态码变化 — 之前返回 200/401 的端点现在只对你的 IP 返回 403。
5. 横幅变化 — 服务器标头形式或响应时间持续发生变化。
6. DNS 污染导致重新变为 NXDOMAIN — 目标的权威服务器不再解析子域名（可能是他们的 CDN 接管了）。
7. 蜜罐诱饵 — 看起来好得不真实的端点（/admin/db_dump.sql、包含无法验证凭据的暴露 .env）。真实暴露很少会如此明显。
8. 直接联系 — 你的马甲邮箱收到“我们发现异常活动”的邮件；或者，在极端情况下，你的 IP 收到友好的滥用举报联系邮件。

退避步骤：

1. 放慢速度。 将并发数减半。请求之间增加 2–10s 的随机抖动。
2. 切换端点。 停止访问触发检测的路径。改用侦察流程中的其他模块。
3. 切换身份特征。 使用新的 User-Agent（在真实浏览器之间轮换），更换 TLS 指纹（使用不同版本的 httpx/curl）。
4. 切换 IP。 更换新的出口（住宅代理、用于敏感查询的 Tor、其他云区域）。
5. 暂停。 等待 1–24 小时。许多 WAF 会按滚动时间窗口评估基于 IP 的信誉；暂停一段时间通常会重置信誉。
6. 记录并咨询。 如果遇到 (3) WAF、(4) 状态变化或 (8) 直接联系，停止主动探测并咨询项目负责人。出现这些信号后继续探测，可能会违反范围约定。

身份特征 / IP 轮换规则：

• 切勿使用曾在之前的项目中针对同一目标使用过的身份特征。
• 对于容易被检测的工作，使用住宅代理（Bright Data、Smartproxy、IPRoyal）——但请注意，Cloudflare 有时会屏蔽这些代理的 IP。
• Tor 出口节点适用于被动查询（CT 日志、存档网站），但大多数主动探测目标都会屏蔽它们。
• 云出口 IP（AWS / GCP / Azure）通常会被严格屏蔽，避免用于侦察。请谨慎使用。
• 记录每次轮换的时间戳和原因；审查人员会询问。

不要：

• 不要试图通过发送更激进的负载来“智取”已确认的 WAF 屏蔽。这会让客户留下更多日志，也会让你暴露。
• 不要为了绕过明确的屏蔽列表而切换源 IP——这属于规避行为，可能违反交战规则。
• 不要因为仪表板显示“仍在运行”就忽略信号。探测过程正在被悄悄记录；后续才会有响应。

---

7. 外部红队侦察流程

适用于任何经授权的外部评估的 5 阶段流程。各阶段按顺序进行；同一阶段内的模块可以并行运行。

阶段 1 — 种子发现

确认目标的真实情况。

• 对种子域名执行 WHOIS 查询（注册人、日期、名称服务器）。
• 枚举 ASN：该组织拥有或使用哪些 AS？（Hurricane Electric BGP Toolkit、RIPEstat、BGPView。）
• 查询 DNS 记录（A/AAAA/MX/TXT/NS/SOA/CAA）——仅获取记录，暂不遍历。
• 查询根域名的证书透明度历史记录（crt.sh、Censys）。

阶段 2 — 资产扩展

发现所有可能属于目标的对象。

• 子域枚举（先查被动来源：crt.sh、VirusTotal、AlienVault OTX、Shodan，然后进行排列组合和暴力破解）。
• 云存储桶枚举（根据公司名称和子域词干排列组合 S3/GCS/Azure — 见 §15）。
• 生成仿冒域名（dnstwist 变体 → 解析 → WHOIS）— 同时评估钓鱼风险和关联企业资产。
• 使用 Wayback CDX 查询归档端点，寻找被遗忘的路径。
• 发现移动应用（Android 使用 google-play-scraper，iOS 使用 iTunes Search API — 见 §14）。
• 深度 DNS 遍历（针对配置错误的区域执行 NSEC 遍历，利用 AXFR 机会）。
• 枚举 LinkedIn 员工 → 推导电子邮件格式。

阶段 3 — 信息丰富化

为发现的资产补充详细信息。

• 端口与服务检测（免费使用 Shodan InternetDB → 获得授权后使用 naabu/masscan）。
• 实时 TLS 握手（证书链、JARM、favicon mmh3 哈希）。
• Web 技术检测（通过 httpx 使用约 600 条 Wappalyzer 风格的特征签名）。
• 推断 WAF/CDN（根据标头特征）。
• 发现 CDN 后方的源站（见 §27）。
• 安全标头审计。
• 批量截图（直观排查数千台主机）。
• 收集电子邮件（6 个并行来源）。
• 电子邮件安全审计（SPF/DMARC/DKIM/BIMI/MTA-STS）。
• GitHub 代码搜索 dork 查询（13 个 dork 模板 × 29 种以上的密钥正则表达式）。
• 深度分析 JavaScript（sourcemap、密钥、端点、内部主机泄露）。
• SSO/IdP 租户指纹识别（Entra、Okta、ADFS、Google、SAML、M365 Teams/SharePoint/OAuth — 见 §11）。
• 发现 API 与身份验证映射（Swagger/OpenAPI、GraphQL、Postman）。
• 扫查 GitHub 之外的密钥（Postman 公开工作区、Stack Exchange、Trello/Notion/Atlassian dork 查询）。
• 供应商产品指纹识别（Citrix/F5/PaloAlto/Pulse/Fortinet/Cisco/VMware/Exchange）。
• 检查容器 / CI-CD / 云原生暴露情况。
• 收集招聘信息，推断技术栈。

阶段 4 — 暴露面分析

将资产转化为发现项。

• Nuclei（15 项始终启用的内置检查 + 可选二进制文件）。
• 深度 TLS 审计（sslyze / testssl.sh）。
• 将泄露事件与身份信息关联（HudsonRock Cavalier、HIBP、DeHashed、IntelX、本地语料库 → SSO_EXPOSURE 发现项）。
• 针对性探测配置错误（.git/config、.env、phpinfo.php、/actuator/env、/actuator/heapdump、_cat/indices、/console、/manager/html）。
• 漏洞优先级排序（CVE × EPSS × CISA KEV × 公开 POC 可用性 — 见 §28）。

阶段 5 — 报告

让工作成果便于使用。

• 为每项发现进行风险评分（CVSS + 项目特定权重）。
• 导出资产图谱（适用于 D3 的节点/链接、GraphML、JSON）。
• 面向客户的报告（执行摘要 + 技术详情 + 修复建议 — 见 §31）。
• 复现包（run_id、命令行版本、原始证据、JSONL 日志）。
• 提交漏洞赏金报告（如适用 — 见 §30）。

7.5 流水线优先级（按信号密度从高到低）

预算有限时，按以下顺序开展：

1. 凭据泄露 — 信息窃取程序日志（HudsonRock Cavalier 免费套餐）+ HIBP + DeHashed。对红队来说投资回报率最高；通常能获取可用于企业 SSO 的有效明文凭据。需要以邮箱作为输入。
2. GitHub 侦察 — 代码搜索 dork。可发现 AWS 密钥、Slack 令牌、JWT 密钥、.env 文件。这是最快的云环境横向切入路径。
3. Nuclei 错误配置扫描 — 暴露的管理面板、带有公开 POC 的 CVE。
4. 云存储桶 — 通过排列组合公司名称和子域名词干进行枚举。可列举的存储桶 = 严重。
5. 端口 — 优先使用 Shodan InternetDB（免费，无需密钥）。VPN 集中器、RDP、Jenkins、GitLab-CE、Elasticsearch 都是高价值的横向切入点。
6. 邮箱 OSINT — 为凭据泄露调查提供线索；为钓鱼名单提供线索。
7. Web 技术 / WAF / 截图 — 对成千上万个主机进行分类；探测前先了解技术栈。
8. Wayback — 存档的 JS 通常包含硬编码密钥；存档端点可揭示已移除的管理 / 开发路径。
9. 深度 DNS + 邮件安全 — SPF / DMARC 配置缺失会导致邮件伪造；TXT 验证令牌可揭示 SaaS 租户。
10. 证书 — CT 日志时间线可发现被遗忘的子域名；弱加密套件可轻松形成发现项。
11. ASN + 反向 DNS — 企业 IP 空间中可能托管未公开的基础设施。
12. WHOIS — 注册人个人身份信息可揭示相关企业资产。
13. 域名抢注 — 已注册的抢注域名可作为发现项；未注册的域名则列入钓鱼域名候选名单。
14. 安全标头 — 单独来看价值较低，但客户报告中必须包含。

7.6 时间预算与项目配置

阶段和资产数量决定侦察所需时间。以下是粗略估算（单人操作，目标为典型的 SaaS 风格组织）：

阶段	小型组织（<100 名员工）	中型组织（100–1K 名员工）	大型组织（1K+ 名员工）
1. 种子发现	30 min	30 min	30 min
2. 资产扩展	1–2 h	2–4 h	4–8 h
3. 丰富分析（每 100 个存活 Web 应用）	~1 h	~1 h	~1 h
4. 暴露面分析	1–3 h	3–6 h	6–12 h
5. 报告	2–4 h	4–8 h	1–2 天

项目配置：

• 1 小时快速侦察（“X 的暴露情况如何？”） — 阶段 1（15 min）→ 被动子域名枚举（crt.sh + Subfinder，10 min）→ 对已解析的 IP 使用 Shodan InternetDB（5 min）→ 通过 Hunter+IntelX 收集邮箱（10 min）→ 查询邮箱是否泄露（10 min）→ 仅输出执行摘要（10 min）。
• 4 小时重点侦察（“钓鱼准备度检查”） — 增加：完整邮箱收集、LinkedIn 员工枚举、SPF / DMARC 分析、域名抢注候选项生成、SSO / IdP 指纹识别。输出：钓鱼可行性报告 + 目标邮箱名单。
• 1 天标准侦察 — 按上述优先级完成阶段 1–4。输出：逐项资产发现清单 + 资产图谱 + 执行摘要。
• 1 周深度侦察 — 完成标准侦察的全部内容，另加：深度模式用户枚举、按完整预算进行 JS 深度分析、移动端攻击面、云原生指纹识别、供应商产品指纹识别、软件包注册表泄露搜寻、漏洞优先级排序。输出：完整的客户交付包 + 复现材料包。
• 持续监控（每周差异对比） — 每周重新运行阶段 1–3；与基线进行差异对比；发现新资产 / 新发现项 / 资产消失时发出警报。

提前终止的情况：

• 阶段 1 后，如果范围有误（目标最终被确认是无关企业的子公司；需要澄清交战规则）。
• 阶段 2 后，如果攻击面低于阈值（没有公开 Web 应用 + 没有暴露服务 + 没有泄露邮箱 → 从外部几乎无从发现）。
• 任何阶段中，如果出现 §6.4 所述的 WAF / 检测迹象。

---

8. 资产图谱规范

将每项发现都视为图谱中的类型化资产，而不是孤立的字符串。

8.1 资产分类（29 种类型）

类别	资产类型
DNS / 网络	domain、subdomain、ip、netblock、asn
服务	port、service、certificate
身份	email、person、credential
代码 / 配置	repo、secret
云 / 存储	bucket、firebase_project
Web	webapp、wayback_endpoint、api_endpoint、api_spec、graphql_schema
移动端	mobile_app、deep_link、exported_component
钓鱼 / 对抗性	typosquat_domain
协作 / SaaS	postman_collection、postman_workspace、postman_api_key、stack_post、saas_public_surface

8.2 资产架构

每项资产都包含：

• type — 上述 29 种类型之一。
• key — 唯一的去重 ID（带类型前缀，例如 sub:api.example.com、email:[email protected]）。
• value — 实际字符串或对象。
• sources[] — 确认此资产的所有来源（已去重）。
• confidence — TENTATIVE / FIRM / CONFIRMED。
• first_seen、last_seen — UTC 时间戳。
• attrs{} — 特定类型的元数据（例如，对于 webapp：status_code、title、tech-stack 列表、JARM、favicon mmh3、截图路径）。

8.3 关系分类

关系使用类型化边表示，而非文本： RESOLVES_TO、HOSTED_ON、IN_NETBLOCK、BELONGS_TO_ASN、LISTED_IN_CERT、OWNED_BY、ALIAS_OF、BREACHED_FROM、EMPLOYED_BY、HOSTS_REPO、TYPOSQUAT_OF、EXPOSES、DOCUMENTED_BY、BELONGS_TO_HOST、REQUIRES_AUTH、LEAKS_SCHEMA、SHIPPED_BY_ORG、CONTAINS_SECRET、TALKS_TO_HOST、EXPOSES_DEEPLINK、HAS_EXPORTED_COMPONENT、USES_FIREBASE_PROJECT、LACKS_PINNING_FOR。

8.4 规范规则

• 每项发现都是一项资产。 不要针对孤立字符串记录发现；先创建资产，再关联发现。
• 按 key 去重，而非按 value 去重。 相同的值、不同的类型 ≠ 同一项资产（sub:api.example.com 和 webapp:https://api.example.com/ 是不同资产，两者之间有一条 BELONGS_TO_HOST 边）。
• 来源信息不可或缺。 sources[] 必须列出所有来源。如果有两个来源确认了该资产，就都要列入。
• 置信度按来源确定，再进行汇总。 某子域名被 3 个被动来源返回，置信度为 FIRM；只被仅提供摘要片段的 Bing 返回，置信度为 TENTATIVE。
• 通过旁路文件延迟绑定。 当模块 A 生成模块 B 所需的输出时，写入 JSON 旁路文件（mobile_endpoints.json、secrets_sidecar.json），不要让模块 B 等待模块 A。参见 §24。

8.5 资产级分诊规则

当你有一批混合资产，但探测预算有限时，应根据每项资产能实现什么来确定优先级：

按主机名信号确定 WebApp 优先级（从高到低）：

1. 与身份验证相关的主机名（auth.、login.、sso.、idp.、accounts.、oauth.）。
2. 管理路径（/admin、/dashboard、/console、/manager、/wp-admin、/phpmyadmin）。
3. 开发／暂存主机（dev.、staging.、stg.、qa.、uat.、test.、sandbox.、preprod.、preview.）——防护较弱，且经常会泄露生产数据。
4. API 主机名（api.、services.、gateway.、graph.）。
5. 面向客户的主机名（portal.、app.、my.、account.）。
6. 营销／内容（www.、blog.、news.、careers.、support.）。

按推断功能确定子域名优先级：

• API > 管理 > 开发 > 身份验证 > 生产应用 > 营销。

按网段确定 IP 优先级：

• 企业 ASN 所有的网段（最有可能托管未公开的内部基础设施）。
• 云网段（AWS／GCP／Azure／DO／OVH）——变动频繁，但对云原生服务而言值得关注。
• CDN 网段（Cloudflare／Akamai／Fastly）——通常是边缘节点，而非源站；除非要查找源站，否则延后处理。

按角色提示确定邮箱优先级：

角色标识	优先级	原因
ceo@、cfo@、cto@、ciso@	最高	高管账户的泄露价值最高（商务邮件欺诈、财务权限、董事会访问权限）。
it@、helpdesk@、support@、security@	高	IT／安全账户拥有特权命令行访问权限；服务台账户负责处理重置工作流。
dev、engineer、architect、dba	中	开发者账户通常拥有 GitHub／云／CI 访问权限。
sales、marketing、hr、finance	中	可访问 SaaS（Salesforce、HubSpot、Workday）；财务账户可能导致商务邮件欺诈。
通用角色账户（info@、noreply@、contact@）	低	通常无人监控或只是转发别名；个人背景信息较少。

按近期活动和命名确定仓库优先级：

• 最近推送（过去 30 天内）> 长期未更新。
• 描述中包含目标名称的公开仓库 > 仅在代码中包含目标名称的仓库。
• 从看起来像内部仓库的上游仓库派生的仓库 > 独立仓库。
• 名称中包含 prod、internal、private、secret → 即使是公开仓库，也设为高优先级（名称可能有误，或内容意外暴露）。

**执行顺序：**当你有 N 项资产、但预算只够进行 M 次探测（M < N）时，应先按资产类型确定优先级，再在同一类型中排序。例如：有 50 个子域名时，先探测 API、管理和开发子域名（约 15 个），然后探测身份验证和生产应用子域名（约 20 个），将营销／内容子域名留到后续处理。

---

9. 发现项评估标准与严重性映射

严重性取决于实际影响，而非主观判断。请参考以下标准：

9.1 严重

预认证代码执行、已确认有效的凭据、可列举的生产数据、根本性的信任违规。

示例：

• 生产 WebApp 上暴露 .git/config（完整源代码泄露）。
• 暴露 /.env（以明文形式存储凭据，通常包含数据库／云／API 凭据）。
• 无需身份验证即可访问 Spring Boot /actuator/env 或 /actuator/heapdump。
• 可列举的 S3／GCS／Azure 存储桶中包含用户数据。
• 无需身份验证即可向会更改状态的写入端点发送 POST／PUT／DELETE 请求。
• Firebase Realtime Database 对外开放（https://{project}.firebaseio.com/.json 返回数据）。
• 生产 Android 应用中设置了 android:debuggable=true。
• 经实时验证的凭据（PMAK、AWS 密钥、Anthropic／OpenAI 密钥）拥有广泛权限。
• 在泄露数据集中，有 ≥10 名员工的账户已被攻破，且已识别出其租户（SSO_EXPOSURE）。
• Elasticsearch 集群对外开放（/_cat/indices 返回数据）。
• Docker API 对外开放（/v1.40/containers/json 返回容器信息）。
• Redis 对外开放（无需 AUTH；可写入 authorized_keys）。
• Kubernetes API Server 对外开放，且启用了匿名身份验证。
• kubelet 的 10250 端口对外开放（无需身份验证即可在 Pod 中执行命令）。
• etcd 的 2379 端口对外开放（可访问集群状态和机密）。
• RDP 易受 BlueKeep 攻击，SMB 易受 EternalBlue 攻击。
• 存在受特定版本 RCE CVE 影响的 Citrix Netscaler／F5 BIG-IP。

9.2 HIGH

存在重大暴露，但尚未达到 RCE；有明确的升级路径；泄露高价值信息。

示例：

• GitHub 仓库中公开的密钥（PAT、AWS 密钥、Slack 令牌等）。
• 可访问源映射文件（.js.map）——完整泄露前端原始源代码。
• 生产环境开放 GraphQL 内省（完整架构泄露 → 可枚举变更）。
• 可能发生子域名接管（CNAME 指向未认领的 Heroku/Shopify 等）。
• 反射式 CORS 且允许凭据（Access-Control-Allow-Origin: <reflected> + Access-Control-Allow-Credentials: true）。
• HTTP 方法篡改：某个端点隐藏支持 DELETE/PATCH，但公开只允许 GET。
• 敏感路径（/login、/sso、/admin、/auth）缺少 HSTS——从 MED 升级。
• 暴露 Jenkins/Tomcat-Manager/phpMyAdmin 管理界面（无身份验证或使用默认凭据）。
• 可连接 Telnet（端口 23）。
• 移动应用中的 WebView 带有 JS 桥接接口（存在 XSS → RCE 的可能）。
• 移动应用中存在敏感的深层链接处理程序。
• 生产发信域名的 DMARC 策略为 p=none（可进行欺骗）。
• 厂商产品横幅显示存在已知且尚未修补的 CVE（已列入 KEV）。

9.3 MEDIUM

信息泄露、加固不足、易受暴力破解。

示例：

• 标准页面缺少安全标头：HSTS、CSP。
• Apache /server-status 或 /server-info 可访问。
• 仅在开发/预发布环境中可访问 phpinfo() 或 /info.php。
• JS 中泄露内部 IP、主机名或 K8s 服务 DNS。
• 错误页面泄露架构信息（堆栈跟踪、ORM 特征）。
• Android 应用中设置了 android:allowBackup=true。
• Android 应用中设置了 android:usesCleartextTraffic=true。
• 导出的 activity/service 未使用 android:permission 保护。
• API 端点缺少速率限制。
• 返回与用户相关数据的 API 使用通配符 CORS（Access-Control-Allow-Origin: *，不允许凭据）。
• Slack webhook URL 泄露。
• Twilio Account SID 泄露（未泄露身份验证令牌）。
• SPF 记录过于宽松（+all 或包含过多记录）。

9.4 LOW

外观层面或影响较小的加固不足。

示例：

• 缺少 X-Frame-Options。
• 缺少 X-Content-Type-Options。
• 暴露 .DS_Store。
• Stripe 测试密钥泄露。
• Firebase URL 暴露（仅 URL，没有开放的 RTDB）。
• 移动应用缺少证书固定。
• 检测到过时的 WordPress 安装（尚无已知漏洞）。
• 未配置 BIMI（仅存在品牌冒充风险）。

9.5 INFO

值得记录，但无需立即采取行动。

示例：

• 缺少 Referrer-Policy / Permissions-Policy。
• 发现 /.well-known/security.txt。
• robots.txt 暴露了值得关注的路径。
• 存在私有存储桶，但访问受到限制。
• 在泄露数据语料库中检测到该域名，但涉及的员工账户为 0 个。
• 未启用 DNSSEC。

9.6 严重性升级规则

• 身份验证/登录/SSO/管理路径缺少 HSTS → MED → HIGH。
• 通配符 CORS + 凭据 → MED → HIGH。
• 通配符 CORS + 敏感端点 → LOW → MED。
• 兴趣评分标准（配套技能 §20）得分 ≥70 的 API 端点 → 至少 HIGH。
• 域名泄露事件涉及 ≥10 名员工 → 无论数据是否过时，均为 CRITICAL。
• 厂商产品版本与 CISA KEV 条目匹配 → CRITICAL。
• DMARC 为 p=reject + 严格 SPF + 已轮换 DKIM → 不升级；安全态势良好。

---

10. 漏洞赏金 / 红队切换模式

现有调查工作（威胁行为者研究、人肉搜索调查、归因分析）与进攻性侦察采用不同的工作方式。请明确切换工作方式。

方面	调查模式	进攻性侦察模式
探测频率	缓慢、单线程，并融入正常流量。	短时间突发并行探测，但针对每个服务提供商限制频率。
OpSec 工作方式	仅使用马甲账号，绝不透露调查人员身份。	使用的角色可以是本次测试中的角色；团队可能会通知 SOC。
证据处理	符合法庭标准的证据保管链；记录哈希值、时间戳和屏幕截图。	符合测试标准；同样严格记录哈希值和时间戳，但证据用于客户报告。
范围内的严重性	所有严重性级别都与背景相关。	CRIT/HIGH/MED 级别很重要；LOW/INFO 级别通常不会列入执行摘要。
授权工作方式	仅使用公开记录 / OSINT；未经授权不得探测私有资源。	书面交战规则；明确测试范围；明确范围外事项清单。
报告格式	叙述性内容 + 带来源的时间线。	按资产列出发现 + 修复建议 + 复现步骤。
停止条件	问题得到解答时。	测试窗口结束或报告交付时。

与用户合作时，如果无法从上下文判断其所处模式，请询问他们。

10.1 基于规模的策略

组织规模会影响哪些技术最有效。

小型组织（< 100 名员工）：

• 高管账号的影响远超其他账号；攻陷一名 CEO/CFO 往往就能掌控一切。
• 邮箱数量较少，可以彻底枚举（总计 10–50 个邮箱）。
• 可能使用 Microsoft 365 或 Google Workspace；身份体系集中在一个租户中。
• 代码仓库通常以个人账号名义公开托管在 GitHub 上（创始人从个人开发转型而来）。
• 云服务通常只有一个 AWS 账号或 GCP 项目。
• 策略：深入调查每个邮箱和每项身份体系发现；完整枚举 LinkedIn；检查创始人的个人 GitHub 组织。

中型组织（100–1K）：

• 均衡枚举。邮箱列表可以枚举，但无法做到穷尽。
• 身份体系可能只有一个 IdP，但使用多个 SaaS 租户（Slack 工作区、Notion 组织、GitHub 组织）。
• 可能有移动应用；检查两个应用商店。
• 云服务可能采用多账号或多区域架构。
• 策略：以标准深度执行完整流程；对每类资产进行抽样后深入调查；按角色确定 LinkedIn 优先级。

大型组织（1K–10K）：

• 邮箱枚举会有所遗漏（抽样检查重要职位）；数据泄露影响规模扩大。
• 采用多租户身份体系（通常包括 Entra、Okta 和多个 Auth0 客户租户）。
• 有移动应用，且不同团队可能发布多个 Android 包。
• 云服务架构庞大；子公司 / 并购会使范围更加复杂。
• 策略：优先广度；依靠自动化发现资产；手动分流调查发现。

超大型组织（10K+）或集团：

• 首先绘制品牌切换关系图：枚举每个品牌域名和每家子公司。
• 数据泄露语料占主导地位：员工人数超过 10K 意味着过去发生过大规模数据泄露的可能性很高。
• 不同业务部门的身份体系可能各不相同（受法律实体边界影响）。
• 策略：范围缩减是最重要的一步；全程结合抽样与自动化；仅深入调查高优先级发现。

**跨规模原则：**组织越小，关注单个账号越有价值。组织越大，系统性安全态势发现（DMARC 配置缺失、SSO_EXPOSURE 覆盖面、供应商产品版本扫描）的价值越高。

---

11. 身份体系映射

组织的 IdP/SSO 安全态势是高价值目标：攻陷身份体系后，就不必逐个攻破应用。请有条理地进行映射。

11.1 子域名前缀枚举

针对目标的根域名（以及发现的任何同级品牌域名）探测以下前缀：

auth.{domain}
login.{domain}
sso.{domain}
idp.{domain}
iam.{domain}
identity.{domain}
accounts.{domain}
oauth.{domain}

并对每个可访问的子域名执行通用 OIDC 发现：

{any-host}/.well-known/openid-configuration

11.2 Microsoft Entra (Azure AD)

• OIDC 元数据 + 租户 GUID 提取 — 获取 https://login.microsoftonline.com/{tenant-or-domain}/.well-known/openid-configuration。issuer 字段会返回包含租户 GUID 的 URL（8-4-4-4-12 位十六进制格式）。租户 GUID + 域名 = 稳定的租户指纹。
• getuserrealm.srf — https://login.microsoftonline.com/getuserrealm.srf?login=<user>@<domain> 会返回 NameSpaceType：Managed（云原生）、Federated（本地 ADFS / 外部 IdP）或 Unknown。可检测性：低。
• Autodiscover v2 — 向 https://autodiscover-s.outlook.com/autodiscover/metadata/json/1 发送包含电子邮件地址的 POST 请求；检测租户成员身份。
• GetCredentialType（深度模式用户枚举）— 向 https://login.microsoftonline.com/common/GetCredentialType 发送 POST 请求 {"username": "<email>"}。响应会表明该电子邮件地址是否存在于租户中。可检测性：中。每个租户最多尝试 20 次。

11.3 Okta

• 组织 slug 推导 — 根据子域名 + 根域名主体推导候选 slug；Okta 租户位于 <slug>.okta.com（或 <slug>.oktapreview.com）。
• OIDC 指纹 — https://<slug>.okta.com/.well-known/openid-configuration。
• /api/v1/authn 用户枚举（深度模式）— 发送 POST 请求 {"username": "<email>", "password": "invalid"}。400 与 401 响应代码可表明用户是否存在。可检测性：中。每个租户最多尝试 20 次。

11.4 ADFS

• 被动指纹识别 — GET https://{domain}/adfs/idpinitiatedsignon.aspx → 返回 200 表示存在 ADFS。
• 主动 mex 端点（深度模式）— https://{domain}/adfs/Services/Trust/mex 返回 SOAP 元数据。

11.5 Google Workspace

• https://{domain}/.well-known/openid-configuration — 由 Google 托管的域名客户会公开具有特征性 issuer/JWKS URI 的发现端点。
• 指向 *.googlemail.com / aspmx.l.google.com 的 MX 记录是 Google Workspace 的强烈信号。

11.6 通用 OIDC（Keycloak / Auth0 / Ping / OneLogin / Duo）

• 探测每个存活子域名的 /.well-known/openid-configuration。
• issuer 和 authorization_endpoint 字段可用于识别 IdP 产品。
• *.auth0.com、*.onelogin.com、*.pingone.com、*.duosecurity.com 等模式具有特征性。

11.7 SAML 元数据

探测每个存活 Web 应用的以下路径：

/saml/metadata
/FederationMetadata/2007-06/FederationMetadata.xml
/federationmetadata/2007-06/federationmetadata.xml
/simplesaml/saml2/idp/metadata.php
/auth/saml2/metadata

SAML 元数据 XML 包含：EntityID、签名证书、SingleSignOnService URL、NameIDFormat。

11.8 AWS 账户 ID 提取

• S3 存储桶区域响应头 — 对已知目标存储桶执行 HEAD 请求会返回 x-amz-bucket-region；结合存储桶名称的随机性推断账户。
• JSON / HTML 响应中的 ARN 正则表达式 — 搜索 arn:aws:[a-z0-9-]+:[a-z0-9-]*:([0-9]{12}):（12 位 AWS 账户 ID 是捕获组）。
• JS / API 响应中的 AccountId 属性 — 常见于 IAM 相关错误消息和 CloudFormation 输出。
• OAuth client_id 泄露 — Google OAuth：<digits>-<chars>.apps.googleusercontent.com；MSAL：clientId 属性中的 GUID。

11.9 输出

每个发现的 IdP 都会成为一个带有 attrs.product、attrs.tenant_id、attrs.discovery_endpoint 的 Service 资产。然后在第 4 阶段与泄露数据进行关联：已发现租户下的每个遭入侵用户都会成为一个 SSO_EXPOSURE 发现项（严重 — 参见 §22.3）。

11.10 Microsoft 365 深度攻击面

除了基础的 Entra 指纹识别，M365 还暴露了更广泛的攻击面，值得深入枚举。

Teams 联合：

• https://login.microsoftonline.com/<target-domain>/.well-known/openid-configuration 可确认租户。
• Teams 联合状态：https://teams.microsoft.com/api/mt/<region>/beta/users/<email>/externalsearchv3（需要来自联合租户的已认证请求；可用于确认是否允许外部 Teams 聊天）。
• 已启用外部聊天 = 软攻击面（通过 Teams 聊天进行语音钓鱼、短信钓鱼，以及冒充 IT 的借口）。
• 开放联合（任何租户都可以聊天）是默认设置；检查目标是否对此进行了限制。

SharePoint 子域名：

• <target-stem>.sharepoint.com — 主租户的 SharePoint。
• <target-stem>-my.sharepoint.com — OneDrive for Business URL（每位用户的个人站点）。
• <target-stem>-admin.sharepoint.com — SharePoint 管理中心（需要身份验证，但其存在可确认租户）。
• <target-stem> 根据公司名称推导（通常是 .com 前面的部分）。

OneDrive 个人站点枚举：

• 每位用户的 OneDrive URL：https://<target-stem>-my.sharepoint.com/personal/<user_email_with_underscore>/Documents/。
• 在电子邮件地址中将 @ 和 . 替换为 _（例如，[email protected] → alice_acme_com）。
• 已认证探测；可用于确认是否已预配 OneDrive 个人站点（这本身就是一个存在性指标）。

M365 OAuth client_id 发现：

• 许多内部应用会在 Entra 中注册 OAuth client_id。在 JS 包、移动应用字符串和 API 响应中搜索 client_id=<GUID> 模式。
• Microsoft 已公开记录 Office、Graph 等产品的知名第一方 client_id；发现非 Microsoft GUID 可揭示自定义内部应用。
• 端点 https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration 会列出支持的端点；有些租户会启用 device_authorization_endpoint（设备代码钓鱼目标）。

Power Platform / Power Apps：

• https://make.powerapps.com/environments（需要身份验证）；环境 ID 有时会泄露在 URL 中。
• *.crm.dynamics.com（Dynamics 365 / Power Apps 默认 URL）。
• *.azurewebsites.net 用于 App Service 部署。

需留意的 M365 OAuth 错误配置发现：

• common 租户启用了 device_authorization_endpoint（设备代码钓鱼目标）→ 中等（存在运营风险；无法直接利用，但会助长攻击）。
• 自定义 OAuth 应用启用了 Public client 流程并具有宽泛的范围（offline_access、Mail.Read、Files.Read.All）→ 高，前提是该应用已获租户批准。
• 由目标发布的多租户 OAuth 应用（其他租户可以授予同意）→ 检查范围是否包含敏感的 Graph 权限。

**可检测性：**所有 M365 端点探测都会记录到 Entra 登录日志 / 审计日志中（仅获取请求时为中低；任何身份验证尝试时为中）。

---

12. API 与身份验证映射方法

现代目标会暴露 REST、GraphQL 和未公开的内部 API。OSINT 的目标是枚举这些 API、进行分类，并按攻击价值排序。

12.1 发现路径

• Swagger / OpenAPI — 在每个存活的 Web 应用上探测 28 个路径的词表（配套技能 §16.1）。解析 YAML/JSON；提取每个端点（方法 + 路径）。
• GraphQL — 探测 13 个路径的词表（配套技能 §16.2）。发送标准内省查询的 POST 请求。如果返回架构，即可获得完整的类型、查询、变更和订阅枚举。
• 禁用内省时的 GraphQL — 回退到字段建议枚举（配套技能 §22.9）。
• Postman — 使用目标名称查询 Postman 的公开通用搜索端点；遍历每个匹配的工作区；提取请求、标头、预请求脚本、测试脚本和环境变量。
• 从 JS 提取的端点 — 从 JavaScript 包中提取的每个端点都会送入同一分类器。
• 从移动应用提取的端点 — 从 APK 静态分析中提取的每个端点都会通过 sidecar（mobile_endpoints.json）送入。

12.2 分类

对每个端点，记录：

url, method, source[], auth_required, auth_type, auth_location,
rate_limited, cors_policy, sensitive_path_keywords[], schema_leaks,
verb_tampering_possible, interest_score (0..100), interest_reasons[]

各字段的判定方法：

• 发送 OPTIONS → Allow 标头会显示受支持的方法（动词篡改检查）。
• 不带身份验证发送 GET → 200 = auth_required=false；401/403 = auth_required=true。
• 捕获响应标头中的 WWW-Authenticate（auth_type）、RateLimit-* / X-RateLimit-*。
• 发送带有 Origin: https://attacker.example 的请求 → 如果响应中的 Access-Control-Allow-Origin 反射了该值，则为 cors_policy=reflected。
• 触发错误 → 检查响应中是否包含堆栈跟踪、ORM 提示。

12.3 关注度评分（0–100）

完整评分标准见配套技能 §20。评分 ≥ 70 → 判定为 HIGH/CRITICAL 发现，并在证据中加入 attack_path_hint。

12.4 攻击路径提示

生成 HIGH/CRITICAL 发现时，在证据中加入一句攻击路径提示，让操作人员知道从何处开始利用。模板见配套技能 §39。

---

13. JavaScript 深度分析

对每个存活的 Web 应用抓取其 JS——现代前端会在其中泄露信息。

13.1 脚本发现

• 解析 HTML 中的 <script src="..."> 和 <link rel="modulepreload" href="...">。
• 针对常见打包工具，探测猜测路径列表（配套技能 §16.9）。

13.2 Sourcemap 检测（高危信息泄露）

• 内联引用：在包末尾匹配正则 //[#@]\s*sourceMappingURL=。
• 同级文件抓取：尝试获取每个已发现 JS 旁边的 <bundle>.map。
• 如果可访问：解析 sourcemap 的 sources[]（会泄露仓库结构）和 sourcesContent[]（内嵌完整原始源代码）。对 sourcesContent[] 运行机密信息目录扫描。
• 严重性：HIGH INFO_DISCLOSURE。

13.3 机密信息扫描

对每个 JS 正文和每个已解析的 sourcesContent[] 块运行 29+ 模式目录扫描。每次命中 = 一条 SECRET_LEAK 发现，严重性按目录中对应模式的定义。

13.4 端点提取

使用三个正则层级（配套技能 §16.10）。每个唯一端点都会成为 wayback_endpoint 资产，并送入 §12 中的 API 分类器。

13.5 内部主机泄露检测

使用三种模式（配套技能 §16.11）：RFC1918、内部 DNS 后缀、K8s 服务 DNS。每次匹配 = MEDIUM INFO_DISCLOSURE。

13.6 GraphQL 内省探测

当提取的端点以 /graphql 或 /graphiql 结尾时，发送标准内省查询的 POST 请求。如果返回架构 → HIGH MISCONFIG。随后枚举变更和订阅，寻找高价值目标。

13.7 Next.js 清单解析

_buildManifest.js 和 _ssgManifest.js 会枚举每个 Next.js 页面路由，从而暴露应用程序的完整路由结构。

13.8 预算指南

• 每次任务分析的 Web 应用上限：默认 40 个，使用 --deep 时为 120 个。
• 每个 Web 应用的 JS 文件上限：默认 40 个，使用 --deep 时为 80 个。
• 单个 JS 文件大小上限：2 MiB。
• 单文件超时：10 秒。

---

14. 移动端攻击面

移动应用往往是最薄弱的环节。

14.1 应用发现

• Android — google-play-scraper。按公司名称、品牌关键词、根域名词干搜索。
• iOS — iTunes Search API。

14.2 所有权置信度（0–100）

参见配套技能 §21。深度分析的阈值：≥70。

14.3 APK 获取与静态分析

• 通过 APKPure HTML 抓取下载。
• 使用 zipfile 和可选的 androguard 提取。
• 提取：AndroidManifest.xml、资源字符串、资源文件、原生 .so 文件、classes*.dex（字符串提取）。

14.4 秘密扫描

对清单、资源、资源文件和 dex 字符串提取结果运行目录扫描。

14.5 后端主机名提取

每个发现的主机名都会成为一个 subdomain 资产。写入旁路文件 mobile_endpoints.json，供 API 发现模块使用。

14.6 清单配置错误发现

清单属性	严重级别
android:debuggable="true"	严重
android:allowBackup="true"（未设置白名单）	中
android:usesCleartextTraffic="true"	中
未设置 android:permission 的导出活动/服务/接收器	中
敏感深层链接处理程序	高
使用 setJavaScriptEnabled(true) + addJavascriptInterface(...) 的 WebView	高
未启用证书固定	低

14.7 Firebase 标准探测

针对提取到的每个 Firebase 项目 ID：

• Realtime DB — GET https://{project-id}.firebaseio.com/.json。返回 JSON 树 → 严重 OPEN_FIREBASE_RTDB。
• Firestore — https://{project-id}.firebaseapp.com/。
• Storage — 对应的 GCS 存储桶。
• Remote Config — 只有提取到 API 密钥和应用 ID 后才能读取。

14.8 iOS 路径

• 仅通过 iTunes Search API 发现。
• ITMS 链接提取：https://apps.apple.com/<region>/app/<slug>/id<bundle-id>。
• 隐私营养标签（App Store Connect）：公开发布，可用于了解应用会接触哪些数据。
• 不建议自动下载（需考虑 DMCA / DRM）。

---

15. 云攻击面

15.1 存储桶排列

根据目标的根域名、子域名前缀，以及可选的品牌/公司名称构建候选存储桶名称。除非通用前缀与可识别目标的标记组合使用，否则应过滤掉这些前缀。应用 6 个前缀 × 15 个后缀（配套技能 §16.8 中列出了这些内容）。

15.2 提供商 URL 模板

S3、GCS、Azure Blob 模板——参见配套技能 §16.8。

15.3 探测技术

• 先发出 HEAD 请求。状态码 200/301 = 存在；403 = 存在，但为私有；404 = 跳过。
• 如果存在，对存储桶根目录发出 GET 请求。可列出的 XML/JSON 列表 → 严重。

15.4 严重级别映射

结果	严重级别
存储桶可列出	严重
存储桶存在，对象可通过直接 URL 读取但不可列出	高
存储桶存在，ACL 为私有	信息

15.5 相邻云信号

从 S3 区域/错误响应中提取 AWS 账户 ID。从 GCS 错误响应中提取 GCP 项目 ID。从 Blob URL 格式中提取 Azure 租户 ID。

---

16. 加密货币调查

16.1 交易分析

• 跟踪钱包之间的资金流；识别相关地址集群；监控大额转账。

工具：Cielo（多链）、TRM（图谱）、Arkham（多链 + 实体标签）、MetaSleuth（可视化）、Range（CCTP）、Socketscan（EVM 桥）、Pulsy（桥聚合器）、Chainalysis Horizon 2.0（付费）、Elliptic Lens。

16.2 Layer 2 / Rollup 分析

• zkSync Era / Polygon zkEVM — ZK 证明隐藏 L2 详情；只能看到 L1 桥事件。
• Arbitrum / Optimism — 批量处理/压缩；从 L1 calldata 获取 L2 状态。
• StarkNet — Cairo VM；地址推导方式不同。
• Base / Blast / Scroll — OP Stack 或 ZK。
• L2 上的隐私协议 — Aztec（可编程隐私）、Railgun（屏蔽池）、Privacy Pools（Tornado Cash 的后继协议）。

方法： 从 L1 桥事件入手；使用 L2 浏览器查看 Rollup 内的活动；对于隐私协议，重点进行时间分析和聚类。

16.3 注意事项

• 桥会引入铸造/销毁语义；避免假设资金流为 1:1。
• MEV/聚合器路径会制造虚假的“直接”踪迹。
• L2 最终确定性：乐观 Rollup 有 7 天的挑战期。

16.4 钱包 / 交易所 / NFT 画像分析

相同的模式：年龄 + 活跃度 + 关联关系 + 随时间变化的余额 + 关联账户。NFT 还需查看所有权历史、元数据和关联钱包。

---

17. 图像分析

17.1 反向图像搜索

• Google 图片 / Lens（Lens 可能需要身份验证——使用傀儡账号的无痕模式）。
• Yandex 图片（对俄语 / 东欧内容效果最佳）。
• Bing 图像匹配、TinEye、Copyseeker、Perplexity Pro。
• 浏览器扩展：RevEye、Search by Image（多引擎）。
• 用 Picarta 进行 AI 地理定位。

17.2 元数据（EXIF）

ExifTool、Jeffrey's Image Metadata Viewer、EXIF Viewer Pro。

17.3 图像取证

Forensically、FotoForensics、Bellingcat Photo Checker、Sensity AI、Exposing.ai、Adobe Content Credentials Verify、c2patool。技术包括：ELA、元数据、克隆检测、噪声分析。

17.4 地理定位工作流

• 前景——标志、车牌、服装、植被、天气。
• 背景——地标、独特建筑、山脉、水域、基础设施。
• 地图标记——动植物、季节性指标。
• 反复尝试——Google Street View、Bing Streetside、Yandex Panorama。
• 使用 Overpass Turbo 查询 OpenStreetMap。
• 山峰识别——PeakVisor、Peakfinder、PeakLens AR。
• OCR——Google 或 Yandex OCR。
• 视频文字稿——YouTube 字幕可优化关键词搜索。

17.5 专用工具

• 火灾识别——NASA FIRMS、Sentinel Hub、Global Forest Watch、Copernicus EFFIS。
• 飞机追踪——Apollo Hunter、FlightRadar、ADS-B Exchange。

---

18. 视频分析

18.1 提取上下文

标志 / 横幅、建筑风格、道路标线、车牌、服装、跨平台片段搜索。

18.2 元数据

YouTube Data Viewer（Amnesty）、使用 ExifTool 分析下载的文件。

18.3 平台专用

• TikTok / Instagram——API 经常变化；优先使用平台导出；按 1–4 小时的间隔抽样。
• Bluesky AT Protocol——通过 bsky.social/xrpc/com.atproto.identity.resolveHandle 解析 DID；通过 plc.directory/<did> 获取身份文档；在 Firesky 使用 firehose；使用 SkyView 查看关系图。尽早存档——账号名迁移 / 帖子删除。
• Mastodon / Fediverse——实例很重要（司法管辖区、日志记录）；使用 WebFinger 发现内容；使用 FediSearch 跨实例搜索；通过 Fediverse Observer 枚举实例；ActivityPub 对象采用 JSON-LD 格式。
• Threads——存在与 IG-API 类似的限制。

18.4 听觉线索

语言、方言、背景噪声（火车汽笛、祈祷声、野生动物）。工具：Audacity、Sonic Visualiser、SoundCMD。使用频谱图寻找独特模式；使用 Shazam / SoundHound 识别音乐。

18.5 帧提取

FFmpeg、VLC。拼接全景图；稳定平移镜头（使用 FFmpeg deshake 或 Blender VSE）。优先使用原始上传内容，而非重新编码的版本。

---

19. 时间定位与时间分析

19.1 阴影分析

工具：SunCalc、ShadeMap、Bellingcat Shadow-Finder、NOAA Solar Calculator。

19.2 天文计算

使用 Stellarium、SkyMap、MoonCalc 模拟不同时间 / 地点的天空。

19.3 卫星图像时间

Google Earth Pro（历史图像滑块）、Sentinel Hub EO Browser（使用 Sentinel + Landsat 影像进行延时浏览）。以 WKT 格式记录坐标；对缓存的瓦片集计算哈希。

---

20. 威胁行为者调查

20.1 以攻击者为中心的工作流

• 范围界定 — 提出攻击者假设（APT28/29、Turla、Sandworm；APT10/41、Mustang Panda、Volt Typhoon）。从 CERT 和供应商收集初始报告。
• 指标收集 — 收集 IOC（域名、IP、哈希、JA3/JA4、用户代理）。通过被动 DNS、CT 日志、沙箱提交记录进行验证。
• 基础设施映射 — 从 CT 日志（SAN、颁发者、序列号）、共享主机、NS 重用、注册商账户、HTML 指纹入手进行关联分析。结合 ASN/WHOIS 历史记录、RPKI/ROA、地理位置丰富信息。
• 样本分析 — 分析 PE/ELF 元数据（PDB 路径、编译时间戳、Rich 标头、代码签名）。使用 SSDEEP/TLSH 进行聚类；查找 YARA 匹配项。
• 社交 / 采购关联分析 — 开发者账号、代码片段、学术论文、招聘信息、采购记录。
• 证伪与报告 — 权衡每项关联；记录其他可能解释；将 TTP 映射到 MITRE ATT&CK；注明来源章节和页码。

20.2 归因准则

• 将能力与意图、赞助分别考量。
• 三项准则：3 项弱证据，或 1 项强证据 + 1 项弱证据。
• 优先采用持久的关联线索（注册商账户、代码签名证书、构建路径惯用写法），而非短暂线索（解析出的 IP）。
• 标明不确定性级别；区分相关性与控制关系。

20.3 俄罗斯特有的关联线索

• 企业 / 人员 — EGRUL/EGRIP（需通过验证码）、Rusprofile、Kontur.Focus、zakupki.gov.ru、hh.ru。
• 基础设施 — 通过 whois.tcinet.ru 查询 RU WHOIS；在 Telegram 上查找频道、管理员和交叉发布内容。
• 媒体 — VKontakte、Odnoklassniki、Rutube；使用俄语及其转写形式搜索。

20.4 中国特有的关联线索

• 企业 / 人员 — gsxt.gov.cn（国家企业信用信息）；天眼查 / 企查查；在 beian.miit.gov.cn 查询 ICP 备案 → 关联 USCC。
• 基础设施 — CNNIC WHOIS；常见的国内云服务（Aliyun、Tencent、Huawei）。
• 媒体 — Weibo、WeChat（通过 weixin.sogou.com）、Zhihu、Bilibili、Douyin、Xiaohongshu；使用中文 + 拼音。

20.5 基础设施与互联网测量

• IP→ASN（HE BGP Toolkit、RIPEstat、BGPView）。
• 通过 CT 日志（crt.sh）查找证书重用和签发频率；根据主体 / 颁发者 / 序列号进行关联分析。
• 使用 URLScan 检查 HTML 指纹、网站图标（mmh3）、脚本哈希。
• 使用 DNS 时序数据（SecurityTrails PDNS、DNSDB）查找子域名变更和暂存域名。

---

21. 人员与社交媒体调查

21.1 用户名枚举

WhatsMyName、NameCheckup、Sherlock、Maigret。

21.2 头像与人脸搜索

PimEyes、Exposing.ai、Azure Face API（合规）。

21.3 社交关系图谱与内容分析

Maltego、snscrape、SocialBlade。Bluesky / Mastodon：实例浏览器 + 账号解析器。

---

22. 泄露数据 × 身份关联

这是外部红队演练中单项投资回报率最高的技术。每次演练都要执行。

22.1 数据源组合

来源	层级	备注
Hudson Rock Cavalier	免费	信息窃取程序日志数据集；对企业 SSO 的信号价值极高。
Have I Been Pwned	免费 + 付费	查询整个域名是否存在泄露记录 + Pwned Passwords（k-匿名性）。
DeHashed	付费	可搜索单条记录的 API。
IntelX	免费 + 付费	聚合器；可搜索电话簿。
本地泄露数据集	操作者提供	磁盘上的所有数据。

22.2 域名级别严重程度

统计数据	严重程度
≥10 名员工遭入侵	严重
1–9 名员工遭入侵	高
≥1 名终端用户（非员工）遭入侵	中
在泄露数据中发现域名，但没有具名账户	信息

22.3 SSO_EXPOSURE 关联

在第 3 阶段完成身份基础架构映射且泄露数据查询完成后：对每个已发现的 IdP 租户，将其域名与泄露数据集求交集。交集非空 → 生成 SSO_EXPOSURE 发现项，严重程度为严重。证据：租户 ID + 产品 + 员工人数 + 各账户的来源归属。

22.4 窃密程序日志的运营处理

• 将其视为个人身份信息（PII）；静态加密。
• 对每个证据文件计算 SHA-256；记录来源 URL 和获取时间戳。
• 切勿将明文密码粘贴到云端大模型中。
• 记录保管链。
• 对于客户报告：默认隐藏密码；为操作人员提供单独加密的原始数据凭据包。

---

23. 基础设施 OSINT

23.1 IP 和域名发现

Shodan、Censys、Onyphe、DNSDB。

23.2 证书和被动 DNS

crt.sh、SecurityTrails。

23.3 恶意软件和证据文件分析工作流

• 静态初筛 — SHA-256、字符串、导入表、PDB 路径、Rich 标头。不要只依赖杀毒软件标签。
• 动态分析 / 沙箱 — ANY.RUN、Hybrid Analysis、CAPE、Tria.ge。
• 聚类 — SSDEEP/TLSH、YARA 匹配结果。
• 报告 — STIX 2.1 IOC；ATT&CK 技术 ID；复现步骤。

23.4 Telegram / 微信调查

• Telegram — 使用公开分析工具（TGStat、Telemetr、Combot）；通过 Telegram Desktop 导出频道；保留消息 ID、UTC 时间戳和媒体哈希。
• 微信 — 使用搜狗微信搜索；归档文章（PNG + WARC）；捕获 __biz ID。链接可能失效。

---

24. 自动化和案件管理

24.1 工具

Hunchly、Kasm Workspaces、ArchiveBox、SingleFileZ。

24.2 跨模块协调模式

当多个 OSINT 工具（或模块）运行时，较晚到达的输出需要传递给较早启动的使用方。以下是三种模式：

1. Sidecar JSON 文件 — 模块写入 <scan>/mobile_endpoints.json 或 <scan>/secrets_sidecar.json；后续模块启动时读取。无需阻塞。
2. 资产图谱增量更新 — 使用共享图谱存储；新资产通过事件总线触发下游模块。
3. 延迟绑定队列 — 长时间运行的枚举过程持续输出资产；富化工作进程拉取资产。

在临时任务中：tmpdir + JSON sidecars + one-line manifest 可使操作具备可组合性。

24.3 多引擎语料运行方法

在多个引擎上运行大型 dork 语料：

• 可插拔引擎 — 将每个引擎（DDG、Bing、Brave、SerpAPI、Yandex、Baidu）封装在通用接口后。默认使用 DDG（无需密钥）；有可用密钥时则回退到其他引擎。
• 按引擎限速 — 每个引擎都有自己的配额和封禁策略。为每个引擎使用一个令牌桶。
• 结果分类 — 按 URL 特征 → 标题提示 → 摘要正则表达式的流程处理。输出：(severity, category, confidence)。
• 按 URL 去重 — 不同引擎可能会返回重复结果。
• 置信度规则 — 仅有摘要的结果 = TENTATIVE。
• 持久化 — 使用语料数据库，以便在不同任务间重新运行时去重。

24.4 攻防演练的证据保全

• 每次任务 / 扫描使用独立的 SQLite 存储。
• 使用 JSONL 运行日志，包含 run_id，每个事件占一行，记录 UTC 时间戳和命令行版本。
• 对每个下载的证据文件计算 SHA-256。
• PNG 截图。
• 原始 HTTP 请求 / 响应，每侧正文上限为 2 KiB。
• 证据仅从操作人员的计算机以只读方式提供。
• 复现包：run_id + 命令行版本 + JSONL 日志 + 资产 / 发现结果数据库。

---

25. 合成媒体验证

Sensity AI、Hive Moderation、Reality Defender、Adobe Content Credentials Verify、CarNet（用于辅助地理定位的 AI 汽车型号识别）。

---

26. 反模式与常见故障模式

以下列出了一些经常出现的错误，并非详尽无遗。

• 单一来源归因。 三个较弱的证据，或一个强证据加一个弱证据。
• 把供应商标签当作事实依据。 应将标签视为假设。
• 假设 favicon 哈希 = 所有权。 可能存在共享基础设施、共享 CMS 模板和共享 CDN。
• 断言桥接流量为 1:1。 桥会铸造和销毁资产；聚合器会重新平衡。
• 把仅有 Google dorks 搜索摘要视为已确认。 在实际访问前，都属于 TENTATIVE。
• 将真实 PII / 凭据粘贴到云端大模型中。 对敏感分析使用本地模型。
• 以己度人地揣测威胁行为者。 他们的思维方式与你不同。
• 按 IP 地理位置进行归因。 IP 会说谎；VPN 和住宅代理确实存在。
• 忽略 7 天的乐观汇总挑战期。 L2 最终确认会延迟。
• 忽略 CT 日志延迟。 新证书需要几分钟到几小时才会显示；未出现 ≠ 不存在。
• 把 Wayback 快照当作“时间 T 时的网站”。 这只是尽力而为；许多请求会失败。
• 相信通过已发现的 API 获取的 whoami 结果。 它可能是蜜罐。
• 让资产图中出现无类型字符串。 每项发现都是一种资产。
• 跳过范围检查。 有疑问时，询问一次。
• 忘记使用 UTC。 本地时间会造成关联错误。
• WAF 拦截后仍继续探测。 参见 §6.4 — 停止并稍后重试。
• 跳过置信度升级文档。 TENTATIVE 资产需要有升级为 CONFIRMED 的路径。
• 把执行摘要写作当作事后才考虑的事情。 参见 §31 — 在参与工作开始时，而不是结束时，规划交付成果。

---

27. WAF / CDN 绕过与源站发现

Web 目标越来越多地部署在 Cloudflare / Akamai / Fastly / AWS CloudFront 之后。CDN 本身很难攻击；源站服务器的防护往往较弱。以下是找到源站的六种技术。

27.1 DNS 历史记录透视

目标域名在部署 CDN 之前可能曾直接指向源站 IP。查询被动 DNS 历史记录：

• SecurityTrails — https://api.securitytrails.com/v1/history/<domain>/dns/a（付费；数据最完整）。
• RiskIQ PassiveTotal — 被动 DNS 查询；免费增值。
• DNSDB（Farsight）— 付费；历史记录较长。
• Validin.com — 较新，提供免费套餐。
• Censys 主机搜索 — 历史 IP 与证书映射。

要查找的是：一个在 1–5 年前解析过、不在当前 CDN 已公布 IP 范围内的 IP（Cloudflare / Akamai / 等）。交叉核对该 IP 当前的 banner — 如果它在不经过 CDN 的情况下提供同一个网站，你就找到了源站。

27.2 证书 SAN 透视

源站和 CDN 经常会重新签发 SAN 列表相同的证书。搜索 CT 日志：

• crt.sh ?q=%.<target.com>&exclude=expired — 查找 SAN 中包含目标域名的证书。
• 将已签发的证书与当前由 CDN 提供的证书进行交叉比对。“额外”的证书（不是 CDN 使用的证书）通常会通过其 CN/SAN 指向源站。
• cero 等工具（go install github.com/glebarez/cero@latest）会扫描 IP 并提取证书；关联证书中包含目标主机名的 IP。

27.3 Favicon 哈希 + JARM 源站聚类

如果目标有独特的 favicon，源站服务器仍会提供它（CDN 会代理流量，但不会移除 favicon）。计算 favicon 的 mmh3 哈希并搜索：

• Shodan：http.favicon.hash:<mmh3-hash>。
• Censys：services.http.response.favicons.hashes:<mmh3-hash>。

返回的 IP 中，不在 CDN 范围内的都是源站候选。

JARM（TLS 握手哈希）的原理类似：通过 jarm 计算目标的 JARM，然后在 Shodan 中搜索 ssl.jarm:<jarm-hash>。源站服务器的 JARM 通常与 CDN 不同。

27.4 使用 Host 标头直接探测 IP

如果通过步骤 27.1–27.3 获得了源站候选 IP：

curl --max-time 30 --connect-timeout 10 -sk -H "Host: target.example.com" https://<candidate-IP>/

如果响应与公开网站相符（标题相同、正文指纹相同），你就找到了源站。仅用于 CDN 的 IP 在 Host 错误时会返回通用 CDN 错误页面或 403。

27.5 mail.* / ftp.* / cpanel.* 例外

目标经常忘记将辅助子域名置于 CDN 后面：

• mail.<target> — 通常指向实际邮件服务器，有时与 Web 源站位于同一位置。
• ftp.<target>、sftp.<target> — 同样如此。
• cpanel.<target>、whm.<target>、webmail.<target> — 共享主机控制面板；与 Web 源站使用相同的 IP。
• direct.<target>、origin.<target>、direct-connect.<target>、noproxy.<target> — 这些管理标签颇具讽刺意味。
• dev.<target>、staging.<target> — 开发环境通常会绕过 CDN。

逐一探测。如果其中任何一个解析到非 CDN IP，该 IP 通常也托管着生产源站。

27.6 错误页面 / 配置错误泄露

当 CDN 抛出错误时（请求触发 WAF、源站宕机、配置不匹配），有时会在错误正文中泄露源站 IP：

• Cloudflare 的 5xx 错误页面过去曾包含 cf-ray，有时还会包含底层上游的详细信息。
• CDN 返回 502/504，说明源站存在，但 CDN 无法访问它 — 这有助于确认并非单纯的 NXDOMAIN。
• X-Cache: MISS from <origin-host> 响应头。
• HTTP 响应中透传了源站响应头（X-Powered-By、Server、X-Backend-Server）。

27.7 邮件头退信技巧（针对邮件服务器源站）

向目标上的一个不存在的地址发送邮件。退信通常会在 Received: 响应头中暴露源站邮件服务器的 IP — 这些邮件服务器有时与 Web 源站位于相同的 IP / 网段。（请使用傀儡邮箱；绝不要使用真实参与测试的身份。）

27.8 可信度规则

• 通过 DNS 历史找到的源站 IP：在直接探测证实之前，标记为 TENTATIVE。
• 通过 Host 响应头探测并匹配内容证实的源站 IP：标记为 FIRM。
• 通过 Host 响应头探测、证书 SAN 匹配和 favicon 匹配证实的源站 IP：标记为 CONFIRMED。

不确定时，请在资产 attrs 中记录假设 — 没有至少 2 个相互印证的信号，不要声称已发现源站。

---

28. 漏洞优先级排序（CVE / EPSS / KEV）

Nuclei 扫描可能会针对一个目标返回 100 多个 CVE。你无法全部验证，应按可利用性排序。

28.1 数据来源（配套技能 §29.2 中包含 URL）

• NVD（国家漏洞数据库）— CVE 基础目录、CVSS 评分。
• EPSS（漏洞利用预测评分系统）— 未来 30 天内漏洞被利用的概率，范围为 0.0–1.0。
• CISA KEV（已知遭利用漏洞）— 已证实在实际环境中遭到利用的漏洞；包含联邦机构的截止日期。
• ExploitDB — 是否存在 POC 代码。
• Metasploit 模块目录 — 是否提供自动化工具。
• InTheWild.io — 由社区维护的“正在遭利用”追踪列表。
• OpenCVE — 时间线、关注列表和提醒。
• Trickest CVE → POC 映射 — 由社区维护的 CVE 与公开 POC 映射。

28.2 优先级评分标准

为列表中的每个 CVE 评分：

信号	权重
列入 CISA KEV	+50（已证实遭到利用；视为需要立即处理）
EPSS 评分 ≥ 0.7	+30
EPSS 评分 0.3–0.69	+15
存在公开的 Metasploit 模块	+25
ExploitDB / GitHub 上存在公开 POC	+15
厂商发布了公告和补丁	+10（意味着漏洞确实存在且可以修补；但不一定可利用）
需要身份验证 vs 无需身份验证	无需身份验证 +20，身份验证后 +0
网络向量 vs 相邻网络 / 本地	网络 +15，相邻网络 +5，本地 +0
CVSS v3 基础评分 ≥ 9.0	+15

总分 → 优先级等级：

评分	等级	操作
≥ 100	P0	立即验证；现在就在测试总结中指出。
70–99	P1	在本次测试中验证；纳入技术报告。
40–69	P2	在技术报告中提及；有时间时验证。
< 40	P3	列入附录；无需验证。

28.3 验证规范

• 验证 = 执行单次只读验证（例如，检查版本横幅，或获取静态页面以确认存在易受攻击的组件），而不触发利用。
• 不要运行实际漏洞利用，除非交战规则明确允许。许多漏洞赏金计划禁止在生产环境中执行 PoC。
• 对于客户项目：提交按优先级排序的清单和复现命令；如有需要，将实际漏洞利用留待后续评估。

28.4 处理没有 CVE 的发现

许多现实中的发现（sourcemap 暴露、开放的 GraphQL 内省、公开存储桶）都没有 CVE。请根据其独立兴趣评分进行评分（端点请参阅配套技能 §20；严重性映射示例请参阅 §40）。不要以是否有 CVE 为门槛。

---

29. 钓鱼基础设施与借口设计

经授权的红队项目通常包含钓鱼。钓鱼的 OSINT 部分——整理钓鱼可行性候选清单和借口清单——属于此处范围。制作实际钓鱼载荷属于 范围之外（这是操作技术，属于单独领域）。

29.1 钓鱼可行性候选清单

对于经授权的项目，操作人员通常需要三份清单：

A. 已注册的仿冒拼写域名——这些是发现项（有人正在抢注，客户应当知晓）。

B. 可供注册的仿冒拼写域名——这是项目中操作人员的钓鱼域名候选清单。

C. 证书 SAN 仿冒模式——操作人员可以注册并用于制作逼真证书的域名（例如，acme-secure.com、acme-login.com、acme-vpn-portal.com）。

生成模式：

1. 对目标的主域名运行 dnstwist（或同类工具）→ 获取所有变体（同形异义字符、仿冒拼写、位翻转、连字符化、增添字符）。
2. 检查每个域名的 WHOIS：已注册 = 清单 A，未注册 = 清单 B。
3. 对于清单 C：将目标词干与合理的服务词组合（secure、login、vpn、portal、mail、helpdesk、it、account、verify、support、password、auth、sso）。

29.2 利用子域接管实施可信域钓鱼

如果发现可接管的子域（参见配套技能 §16.12），就可以在实际目标的子域上托管钓鱼内容。这样就能绕过用户所有的品牌仿冒防御。

流程：

1. 确认候选子域上的接管特征（<sub>.target.com 的 CNAME 指向无人认领的 <x>.herokuapp.com）。
2. 注册无人认领的资源（在 Heroku 上注册 <x>.herokuapp.com）。
3. 现在，<sub>.target.com 就会提供你的内容。
4. 在上线钓鱼内容前停止操作，并咨询项目负责人。 即使在经授权的项目中，接管操作本身也可能需要获得客户明确批准。

29.3 电子邮件伪造可行性

使用电子邮件安全分析（参见配套技能 §16.14）判断伪造的可行性：

SPF 策略	DMARC 策略	伪造可行性
~all（软失败）或未设置	p=none 或未设置	高 — 直接伪造 <anything>@<target> 很可能会成功送达。
~all	p=quarantine	中 — 邮件会进入垃圾邮件文件夹，但仍能送达。
-all（硬失败）	p=quarantine	低 — 大多数提供商会拒绝；有些仍会将邮件投递到垃圾邮件文件夹。
-all	p=reject	极低 — 主要提供商会拒绝伪造邮件。需要使用仿冒域名。

如果伪造难以成功，可改用仿冒域名（清单 B）或被攻陷的第三方（另一个项目）。无论如何，都要记录安全态势发现。

29.4 基于 OSINT 构建借口

借口在契合目标现有背景时才有效。根据收集到的 OSINT 构建借口。

借口来源：

• 职位名称 + 汇报结构（LinkedIn）—“嗨，，我是 的助手；你能看一下这个财务文件吗？”
• 近期企业事件（新闻稿、新闻、招聘页面）—“我们正在跟进裁员 / 新收购事宜；请确认你的福利信息。”
• 供应商关系（招聘信息中提及“具备 Workday/Salesforce 等方面的经验”）—“请在当天结束前重置 Workday 密码。”
• 公开会议 / 差旅（LinkedIn 帖子、会议页面）—“嗨，，我们上周在 见过；想跟进一下我们讨论的内容。”
• GitHub 提交 / 开源项目—“我看到了你在 中提交的修复；想合作处理相关 PR 吗？”
• 办公地点（LinkedIn）—“ 办公室的现场 IT 需要快速进行身份验证。”

按角色分类的借口模板（操作人员最常用的模板）：

• **最终用户（普通员工）：**IT 服务台密码重置、Workday HR 操作待处理、Microsoft 365 存储空间已满、包裹投递确认。
• **高管：**财务授权（类似 BEC 的“需要批准汇款”）、董事会材料共享、并购 NDA 审核、高管助理请求。
• **开发人员 / 工程师：**GitHub 安全警报、CI 构建失败、软件包安全公告、会议 CFP 跟进。
• **HR / 财务：**工资供应商变更、费用报销单被拒、福利登记截止日期、供应商发票差异。
• **IT / 安全：**供应商安全更新通知、值班升级、监控命令行警报。

29.5 网络钓鱼基础设施的操作规范

• 所有网络钓鱼基础设施必须在上线之前获得项目负责人批准。
• 记录每个注册的域名和每封发送的电子邮件（发件人、收件人、主题、UTC 时间戳）。
• 将网络钓鱼基础设施与常规侦察基础设施隔离（使用不同的 IP、不同的身份、不同的域名注册商账户）。
• 注册网络钓鱼域名时使用专用支付方式（项目专用公司卡；不要使用个人卡）。
• 项目结束后立即拆除基础设施；转让 / 使所有域名过期；关闭所有托管账户。

---

30. 漏洞赏金提交与负责任披露

当你在漏洞赏金目标（HackerOne、Bugcrowd、Intigriti、YesWeHack）上发现问题，或在非项目目标上发现问题并选择负责任地披露时，均适用。

30.1 各平台基本信息

平台	URL	说明
HackerOne	hackerone.com	规模最大；范围跟踪完善；基于 CVSS 计算奖励。
Bugcrowd	bugcrowd.com	使用 VRT（漏洞评级分类法）而非 CVSS 评定严重性。
Intigriti	intigriti.com	在欧盟实力强；范围模式灵活。
YesWeHack	yeswehack.com	总部位于欧盟；正在发展壮大。
HackenProof	hackenproof.com	专注于加密货币 / 区块链的项目。
Open Bug Bounty	openbugbounty.org	适用于没有官方项目的网站，且免费（仅披露 XSS/SSRF）。
security.txt	rfc9116	通用标准：每个网站都应发布 /.well-known/security.txt。

30.2 报告结构（适用于任何平台）

Title: [Severity] [Affected component] Brief description
   Example: [HIGH] [api.acme.com] Unauthenticated SSRF via /v1/proxy

Summary
   2-3 sentences explaining what was found and why it matters.

Steps to Reproduce
   1. Numbered, copy-pasteable.
   2. Include exact URLs, payloads, expected vs actual response.
   3. Reproduce the issue from a fresh state where possible.

Proof of Concept
   - Screenshot showing the vulnerability triggered.
   - HTTP request/response (sanitize sensitive data; redact other users' data).
   - Or short video/GIF for complex multi-step issues.

Impact
   Quantify: what data is at risk, how many users, what business functions break.
   Tie to the program's impact criteria where defined.

Severity (per program criteria)
   - CVSS v3 vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
   - Score: 9.8 (Critical)
   - Justification: <1-2 sentence reasoning>

Remediation
   - Concrete recommendation. "Validate the URL parameter against an allowlist before fetching."
   - If a quick fix: WAF rule, header check.
   - If a structural fix: refactor recommendation.

Affected component
   - URL: https://api.acme.com/v1/proxy
   - Date discovered: 2026-04-27 14:23 UTC
   - Method: HTTP GET / POST / etc.

30.3 根据项目推断严重性

• HackerOne 使用 CVSS v3，并根据项目采用特定乘数（有些项目将严重性上限设为 HIGH；有些项目对 CRITICAL 漏洞支付 10 倍奖励）。
• Bugcrowd VRT：P1（严重）→ P5（信息性）；大致对应 CRIT/HIGH/MED/LOW/INFO。
• Intigriti 使用 Exceptional / Critical / High / Medium / Low 等级。
• 对于按严重性等级支付固定金额的项目，不要夸大严重性。保守评定严重性 → 赢得信任 → 获得后续奖励。

30.4 针对未设置漏洞赏金计划目标的披露（CVD）

如果目标没有漏洞赏金计划，但你在授权测试期间发现了真实漏洞（例如，客户的外部评估发现了第三方供应商的漏洞）：

1. 检查是否存在 <target>/.well-known/security.txt；如果存在，请遵循其中的 Contact: 和 Encryption:（PGP）说明。
2. 如果不存在，先尝试 security@<target>，然后尝试 abuse@<target>。
3. 如果邮件被退回，请通过 WHOIS 中登记的滥用联系渠道升级处理。
4. 如果供应商没有响应，可联系 CERT/CC (cert.org) 和各国 CERT（CISA、CERT-EU、JPCERT）协调处理。
5. 按照标准的 90 天披露期限，在期限结束后再公开发布（Project Zero 惯例）。

30.5 云服务提供商 / SaaS 专属渠道

• AWS 滥用举报：[email protected]。如果发现暴露的 AWS 密钥：如果能通过 WHOIS / 联系信息找到账户所有者，也要通知对方。
• GCP：[email protected]。
• Azure：通过 https://msrc.microsoft.com/ 联系 Microsoft 安全响应中心（MSRC）。
• GitHub：GitHub 的合作伙伴计划会自动撤销大多数已发布的密钥；如果你发现此类密钥，扫描流程通常比手动披露更快，但仍应通过 [email protected] 备份通知 GitHub。
• npm / PyPI / Docker Hub：各平台都有 abuse@ 或 security@ 联系渠道；npm 会通过其密钥扫描器自动撤销泄露的令牌。

30.6 报告中应避免的事项

• 不要在报告中包含他人的 PII / 密码 / 数据（请先编辑隐去）。
• 披露期限结束前，不要公开发布报告或 PoC。
• 不要先通过社交媒体升级处理（始终优先使用直接联系渠道）。
• 不要要求特定的赏金金额；由计划方决定。
• 不要将同一发现提交给多个计划（重复提交可能损害你的声誉）。

---

31. 客户交付物模板

面向操作人员的材料（资产图谱、JSONL 日志、发现项数据库）不同于面向客户的材料（执行摘要、技术报告）。请有规划地构建交付物。

31.1 执行摘要模板

ENGAGEMENT: <Client Name>
ASSESSMENT TYPE: External Attack Surface Assessment
ENGAGEMENT WINDOW: <start date> – <end date>
SCOPE: <one-line scope description, e.g., "All internet-facing assets of acme.com and its 3 brand domains">
LEAD: <your name / team>

----- KEY FINDINGS -----

1. [CRITICAL] <One-line title>
   Business impact: <one sentence in business language>
   Estimated remediation effort: <hours / days / weeks>
   Recommended action: <verb + object, e.g., "Rotate the exposed AWS access key and audit CloudTrail">

2. [CRITICAL] <One-line title>
   …

3. [HIGH] <One-line title>
   …

(Top 3-5 findings only; full list in technical report)

----- POSTURAL OBSERVATIONS -----

- Email security (SPF/DMARC): <2-3 sentences on posture, e.g., "DMARC is set to p=none, allowing spoof of <target>.com email; tightening to p=reject would block external spoofing.">
- Identity fabric (SSO): <2-3 sentences>
- Cloud surface (S3/GCS/Azure): <2-3 sentences>
- Mobile attack surface: <2-3 sentences if applicable>

----- AGGREGATE METRICS -----

- Assets discovered: <N> (<breakdown>)
- Findings: <N CRIT, M HIGH, P MED, Q LOW, R INFO>
- Live credentials confirmed: <N>
- Detectability of our operations: <90% low / 8% medium / 2% high>

----- RECOMMENDED NEXT STEPS -----

1. Address P0 findings in next 7 days.
2. Address P1 findings in next 30 days.
3. Schedule re-test for: <date>.
4. Consider follow-on assessments: <if applicable, e.g., authenticated app testing, internal pentest>.

31.2 单项发现报告卡模板

技术报告中的每项发现都使用此卡片：

═══════════════════════════════════════════════════════════
FINDING #<N>: <Title>
SEVERITY: <CRIT / HIGH / MED / LOW / INFO>
CONFIDENCE: <CONFIRMED / FIRM / TENTATIVE>
ASSET: <typed asset key>
DISCOVERED: <UTC timestamp>
═══════════════════════════════════════════════════════════

DESCRIPTION
  <2-5 sentence technical explanation>

EVIDENCE
  - URL: <where it was found>
  - Tool: <how it was discovered>
  - Screenshot: <attachment ref>
  - Raw HTTP: <sanitized capture>
  - Hash (SHA-256): <of any downloaded artifact>

REPRODUCTION
  Step 1: <command or action>
    Expected: <output>
  Step 2: …

IMPACT
  <Business-language impact statement>
  Affected systems: <list>
  Affected user populations: <if applicable>

REMEDIATION
  Immediate (within hours):
    - <action>
  Short-term (within days):
    - <action>
  Long-term (within weeks):
    - <action>

REFERENCES
  - <CVE-ID, advisory URL, OWASP top-10 link, vendor doc>

ATTACK PATH HINT
  <If applicable, the one-sentence hint from companion skill §39>

31.3 风险转译矩阵

工程师关注 CVSS。高管关注业务影响。请转换表达方式。

技术发现	业务影响（通俗表述）
可列出内容的 S3 存储桶中包含 PII	“客户记录可公开下载。如果被访问，可能触发 GDPR/CCPA 通知要求。数据泄露的预计成本：30 天通知期 + 信用监控 + 法律审查。”
暴露的 .env 中包含 DB 凭据	“可访问包含所有客户数据的数据库，并进一步访问备份、计费系统和员工 PII。如果遭到利用，可能造成全面数据泄露。”
具有管理员权限的 AWS 访问密钥仍然有效	“云账户可能被全面攻陷。攻击者可以启动加密货币挖矿程序、窃取所有数据，并横向移动至关联账户。如果遭到利用，可能产生六位数的云账单，并需要全面重建环境。”
生产环境中开放了 GraphQL introspection	“攻击者已能完整绘制 API 攻击面，从而更精确地发动后续攻击。此问题不能直接被利用，但攻击者的侦察工作已变得毫不费力。”
子域名可能被接管	“攻击者可以在受信任的域名下托管内容。从该域名发送的钓鱼邮件能够绕过品牌仿冒防护，用户会相信这些邮件。”
Firebase Realtime Database 未设访问限制	“移动应用的后端数据库可被公开读取。所有用户数据都可能被读取，甚至可被写入。如果遭到利用，可能造成全面数据泄露，并导致服务中断。”
/login 缺少 HSTS	“攻击者可通过主动网络攻击将登录页面降级为 HTTP。任何具有网络访问权限的人（如咖啡店或会议 WiFi 的用户）都可能截获凭据。”
DMARC p=none	“互联网上的任何人都可以发送看起来来自你域名的邮件。钓鱼活动会变得极具迷惑性，无论针对客户还是员工都是如此。”
泄露数据中包含 ≥10 名员工的信息	“员工的被盗凭据正在流传；攻击者可能会用这些凭据尝试登录你的 SSO。即使 SSO 启用了 MFA，在其他服务上重复使用密码也会带来风险。”
android:debuggable=true	“任何人都可以对移动应用进行逆向工程和修改。应用与服务器之间的信任边界遭到破坏；后端假设应用具备实际并不存在的完整性。”
厂商产品（Citrix/F5/Pulse）版本存在 KEV CVE	“网络设备存在已知且遭到利用的漏洞。攻击者正在主动扫描互联网，寻找存在此确切问题的设备。请立即修补。”

31.4 超过 1 天的项目汇报频率

• 第 1 天结束时 — 简短确认启动情况：“阶段 1 已完成。目前已识别 项资产。初步安全态势：<一段话>。”
• 项目中期同步 — 首次发现 CRITICAL 时或完成 50% 时间时，以先发生者为准。向项目负责人提醒：“发现 ；建议立即通知 ，开始准备修复。”
• 项目结束时的初步汇报 — 最后一次探测当天提供：排名前 5 的发现 + 在 X 个工作日内交付完整报告的计划。
• 最终报告 — 正式交付物；包含高管摘要和技术报告。
• 提供复测 — 主动提出：“我们可以在 内进行复测；建议在修复后对 CRITICAL/HIGH 级发现进行复测。”

31.5 复现包内容

随报告一并交付：

<engagement-id>-reproduction-package.zip
├── README.md                    # how to use the package
├── engagement-metadata.json     # client, dates, scope, lead
├──tools-used.txt               # command-line name + version, one per line
├── run-log.jsonl                # every event during engagement
├── assets.db                    # SQLite of all discovered assets
├── findings.db                  # SQLite of all findings
├── evidence/
│   ├── screenshots/             # PNG, named by finding-id
│   ├── http/                    # raw HTTP captures (sanitized)
│   ├── downloads/               # any binary artifacts (with .sha256 alongside)
│   └── code/                    # any extracted source (sanitized)
├── re-test-script.sh            # reruns probes for the CRIT/HIGH findings
└── disclosure/                  # if applicable: bounty submissions, vendor notifications

该复现包是事实依据；报告则是便于阅读的版本。任何持有该复现包的人都可以复现项目并验证发现。

---

32. 技能自测

将以下提示词放入全新的 Claude 会话，验证技能是否已加载并能正确运行。通过标准：引用预期章节、不编造内容，并在需要时调用范围检查。

1. “我正在对 acme.com 进行外部侦察（属于范围内的漏洞赏金计划）。从哪里开始？” → §0、§1、§7、§7.5、§11。
2. “如何在不主动探测的情况下判断目标使用 Entra、Okta 还是 ADFS？” → §11.2-11.4 + 配套技能 §22。
3. “抓取 JS 包时应该关注什么？” → §13。
4. “查找并分析目标 Android 应用的工作流是什么？” → §14。
5. “如何生成优质的云存储桶候选项，同时避免向整个互联网发送垃圾请求？” → §15。
6. “我们已为目标收集 200 个电子邮件地址，并确认该组织使用 Entra。接下来 ROI 最高的步骤是什么？” → §22。
7. “我在一个公开的 GitHub 仓库中发现了一个有效的 AWS 访问密钥。应该检查它是否可用吗？” → §6.3 + 配套技能 §23.2。
8. “我们的团队刚刚获取了一份 4GB 的窃密日志转储。该如何处理？” → §22.4。
9. “我发现了三个疑似 APT28 的指标——这能确认归因吗？” → §20.2 + §2。
10. “正在调查一名俄罗斯网络犯罪行为者。有哪些公司和人员关联线索可供追踪？” → §20.3。
11. “如何将一个 .cn 域名关联到其运营公司？” → §20.4 + 配套技能 §14.2。
12. “列出红队人员在外部侦察中最常犯的错误。” → §26。
13. “对 chase.com 执行完整的子域名枚举。” → §1（范围检查；不应执行）。
14. “我的子域名标记为 TENTATIVE——如何提升其置信度？” → §2.1。
15. “为期 1 周的侦察任务，5 个阶段各应耗时多久？” → §7.6。
16. “50 个子域名、12 个 Web 应用、4 个 IP、23 个电子邮件地址——如何安排分诊顺序？” → §8.5 + §7.5。
17. “正在探测一家有 50 名员工、使用 M365 + GitHub + AWS 的 SaaS 公司。重点应该放在哪里？” → §10.1 + §11.10 + §22。
18. “目标完全位于 Cloudflare 后方。如何找到源站？” → §27。
19. “Nuclei 扫描发现了 100 个 CVE。如何确定优先级？” → §28。
20. “我的探测请求收到 429 响应和 Cloudflare 中间页。接下来怎么办？” → §6.4。
21. “授权任务要求提供一份钓鱼可行性候选清单。请逐步讲解。” → §29。
22. “我在一个 HackerOne 目标上发现了未认证的 POST 端点。帮我撰写报告。” → §30.2。
23. “为发现了 2 个 CRIT、5 个 HIGH、12 个 MED 的任务撰写执行摘要。” → §31.1 + §31.3。

---

33. 更新日志

• v2.1 (2026-04-27) — 基于 32 项测试的冒烟测试差距分析进行了全面扩展。新增：置信度提升工作流（§2.1）、感知检测的探测（§6.4）、时间预算与任务配置（§7.6）、资产级分诊规则（§8.5）、基于规模的战术（§10.1）、Microsoft 365 深度攻击面（§11.10）、WAF/CDN 绕过与源站发现（§27）、漏洞优先级排序（§28）、钓鱼基础设施与诱导理由设计（§29）、漏洞赏金提交与负责任披露（§30）、客户交付物模板（§31）。更新了自测章节，加入 v2.1 提示词。
• v2.0 (2026-04-27) — 为外部红队工作模式进行了重大改写。新增：5 阶段流程、资产图谱规范、发现项评级标准、漏洞赏金工作模式切换、身份体系映射、API 与身份验证映射方法、JS 深度分析、移动攻击面、云攻击面、泄露数据 × 身份关联、可检测性标记、验证器规范、模块间协作、多引擎语料库运行、证据保全、反模式。保留了原有的方法论内容（OpSec、Crypto、Image/Video/Chrono、Threat Actor，包括俄罗斯/中国，以及 Synthetic Media）。
• v1.x — 基于 SnailSploit/offensive-checklist 的原始 OSINT 方法论框架。

---

验证

1. 被动侦察工具 — 确认已安装关键工具：

   which subfinder amass whois 2>/dev/null | head -3
   

2. CT 日志访问 — 确认可访问 crt.sh：

   curl --max-time 30 --connect-timeout 10 -s "https://crt.sh/?q=example.com&output=json" -o /dev/null -w "HTTP %{http_code}" && echo " PASS" || echo " FAIL"
   

所有测试均用于验证 OSINT 方法论的准备情况。

---

常见陷阱

• OSINT 瘫痪 — 无休止地侦察，却不将发现转化为攻击面，纯属浪费时间。每条 OSINT 信息都必须导向一个可测试的假设。
• 聚合数据却不去重 — 收集 5000 个重复率达 80% 的子域名，会浪费扫描时间。务必彻底去重。
• 混淆被动与主动侦察 — 被动 OSINT（DNS、CT 日志、WHOIS）不会触及目标。主动 OSINT（端口扫描、HTTP 探测）则会。要清楚自己处于哪种模式。
• 妥善处理泄露数据 — 泄露数据集包含真实用户凭据。未经明确授权，绝不能使用。绝不能未加密存储。
• 工具重复 — subfinder、amass、assetfinder 和 findomain 做的都是同一件事。选一个并熟练使用。

---

相关技能与工作流链

• offensive-osint — 当需要通过具体探测来执行方法论时使用。工作流基础：本技能是规划框架（5 阶段流程、资产图谱、发现结果评估标准）；offensive-osint 是实战工具库，用 curl 单行命令、字典和正则表达式填充每个阶段。
• web2-recon — 当资产发现从规划阶段进入执行阶段时使用。工作流基础：确定本技能 §7 流程的范围后，web2-recon 会运行 subfinder → dnsx → httpx → katana 命令并生成 URL 集合。
• hunt-subdomain — 当资产图谱发现过期的 CNAME 时使用。工作流基础：§8 资产图谱中 CNAME 指向 S3 / GitHub Pages / Heroku / Shopify / Azure 的条目会自动转交给 hunt-subdomain 进行接管验证。
• hunt-cloud-misconfig — 当资产图谱发现暴露的存储桶 / 执行器 / Firebase 时使用。工作流基础：§15 云攻击面中发现的问题（开放的 S3、/actuator/env、/firebaseio.com/.json）会转交给 hunt-cloud-misconfig 进行利用。
• bb-methodology — 当项目模式是漏洞赏金而非纯侦察时使用。工作流基础：本技能的 §10 漏洞赏金切换模式是衔接点；确认模式后，由 bb-methodology 第 0 部分及 5 阶段工作流接手。