bb-methodology

漏洞赏金方法论：工作流 + 思维方式

漏洞挖掘会话的主控流程。结合非线性的 5 阶段工作流与批判性思维框架，帮助你跻身顶尖 1% 的漏洞挖掘者。

---

第 0 部分：模式确认（先于一切）

在判断什么算作漏洞发现之前，先确认参与类型。 同一个目标会因适用模式不同而产生不同形式的报告。在这个工作流中，弄错这一点是最浪费时间的事——请在第 0 阶段之前明确回答。

参与类型	什么算作漏洞发现	什么会被拒绝
漏洞赏金（H1 / Bugcrowd / Intigriti / 私有 VDP）	仅限已证明影响的漏洞。完整攻击链必须造成攻击者可实现的危害。	安全卫生问题（仅有 EoL 软件、仅有宽松的 CSP、堆栈跟踪、没有具体影响的信息泄露、“最佳实践”违规）
红队（外部客户参与）	安全卫生问题 + 侦察 + IoC + 防御状态观察结果都属于交付内容	无——即使是“此处没有发现”也可以作为正面的防御观察结果报告
渗透测试（已签署的 SoW / WAPT）	取决于 SoW。明确阅读范围。通常接受安全卫生问题 + 影响 + 侦察	范围外资产、未经签署的测试
内部审计	与合规要求对应的发现（PCI / ISO / NIST / DPDPA / GDPR）	未映射到控制项的发现

硬性规则： 在第 0 阶段开始之前，把参与类型写在狩猎笔记的第一行。如果无法从用户的指示中判断出来，就询问一次。不要自行假设——弄错会让你和分诊人员都付出代价。

一次授权参与中的教训： 对此目标的首轮测试发现了 5 个安全卫生问题（SP2013 EoL、宽松的 CSP、堆栈跟踪），并以红队报告格式提交。但这次参与属于漏洞赏金。这些发现会因“仅供参考，未证明影响”而被判定为 N/A。修正后再次测试，将安全卫生问题作为背景信息而非漏洞发现，同一目标最终产生了 11 个已证明影响的漏洞，其中包括 3 个严重级别漏洞。

---

第 1 部分：思维方式（如何思考）

核心原则

漏洞挖掘不是“找漏洞”，而是“证明攻击场景”。要像有明确目标的攻击者那样思考，而不是像只会查找模式的扫描器。

日常纪律：定义、选择、执行

使用任何工具之前：

1. 定义：“今天我针对 [功能/领域]，以实现 [CIA 影响]”
2. 选择：选择 1–2 类漏洞（IDOR、竞态条件等）
3. 执行：只专注于所选技术。不要漫无目的地探索。

5 个终极目标（每次会话选择一个）

1. 机密性——窃取攻击者不应看到的数据
2. 完整性——修改攻击者不应更改的数据
3. 可用性——中断服务（仅限应用层 DoS）
4. 账户接管——控制其他用户的账户
5. RCE——在服务器上执行命令

4 个思考领域

1. 批判性思维（深入分析）

质疑信任边界：

• 前端控件被禁用？通过代理直接发送请求
• 有 user_role=user cookie？改成 admin
• POST 中有 price=1000？改成 1
• <script> 被拦截？试试 <img onerror=...>

逆向推断开发者的思维方式：

• 功能 A 有身份验证检查 -> 类似的功能 B（新添加的）可能没有
• 复杂流程（优惠券 + 积分 + 退款）-> 边缘情况可能存在漏洞
• 存在 /api/v2/user -> /api/v1/user 是否仍以较弱的身份验证方式运行？

“如果这样做会怎样”实验：

• 跳过结账 -> 直接访问 /checkout/success
• 跳过 2FA -> 跳转到 /dashboard
• 同时发送 10 次优惠券请求 -> 是否存在竞态条件？
• 在同级端点上将 guid=f8a2... 替换为 id=100 -> 是否存在 IDOR？

2. 多角度思考（多个视角）

视角	检查内容
横向（相同角色）	用户 A 的令牌 + 用户 B 的 ID → IDOR
纵向（不同角色）	普通用户 → /admin/deleteUser
数据流（代理视角）	JSON 中的隐藏参数：debug=false、discount_rate
时间/状态	竞态条件、删除后复用会话
客户端环境	移动端 UA → 使用身份验证较弱的旧版 API
业务影响	“如果这里出问题，损失会是多少？”

3. 战术思维（模式检测）

• 命名异常：到处都是 userId，却突然出现 user_id → 开发人员不同，安全性较弱
• 错误差异：相同的 403，但 JSON 结构不同 → 后端系统不同
• 环境差异：生产环境与开发/预发布环境 → 调试标头、禁用 CSP
• 版本差异：更新前后的 JS 文件 → 新端点、删除的参数
• 供应链：检查框架/库版本是否存在已知 CVE
• 第三方集成：Stripe/Auth0/Intercom → 是否缺少 webhook 签名？

4. 战略思维（全局视角）

• 不对称性：防御方必须修补所有漏洞。你只需要找到一个。
• 直觉训练：记录某件事“感觉不对”的原因。之后再验证。更新思维数据库。
• 未知情况管理：有些内容不明白？加入“稍后调查”列表。按需学习。

业余者与专业人士：7 阶段对比

阶段	业余者	专业人士
侦察	仅主域名	影子 IT、开发环境、所有资产
发现	寻找错误	寻找设计矛盾、业务逻辑缺陷
利用	遇到阻碍就放弃	构造过滤器绕过载荷
提权	只报告现象	将漏洞串联为实际危害（会话窃取、ATO）
可行性	包含不现实的条件	尽量减少攻击前提
报告	只陈述事实	量化业务风险
复测	检查旧 PoC 是否失效	分析修复方式，寻找不完整的补丁

两种行动路线

• 路线 A（基于功能）：“这个功能很复杂” → 深入检查其输入处理 → 发现漏洞
• 路线 B（基于漏洞）：“我想找 IDOR” → 查找 ID 连续的端点 → 测试访问控制

反模式（停止这样做）

• 不断切换项目：至少坚持测试一个目标 2 周 / 30 小时
• 只依赖工具搜寻：自动化工具会找到重复问题。手动测试才能发现独特漏洞。
• 钻牛角尖：每个参数最多花 45 分钟。设置计时器。如果卡住了，睡一觉再继续。
• 没有目标：“随便看看”= 浪费时间。务必先定义目标。

---

第 2 部分：工作流（要做什么）

5 阶段非线性流程

+-------------------------------------------------+
|                                                 |
|  +----------+    +----------+    +----------+   |
|  | 1. RECON |---+| 2. MAP   |---+| 3. FIND  |  |
|  +----------+    +-----+----+    +-----+-----+  |
|       ^                |               |         |
|       |                v               v         |
|       |          +----------+    +----------+    |
|       +----------| 4. PROVE |---+| 5. REPORT|   |
|                  +----------+    +----------+    |
|                                                  |
|  Non-linear: stuck at any phase -> go back       |
|  New API found at phase 3 -> return to phase 2   |
|  WAF blocks at phase 4 -> origin IP from phase 1 |
+-------------------------------------------------+

这不是线性流程。 可以在各阶段之间自由切换。遇到阻碍时，返回之前的阶段。

阶段 0：会话开始（每次都要执行）

使用任何工具之前，请回答以下问题：

1. 定义目标：“今天我针对 [功能/域名]，以实现 [C/I/A/ATO/RCE]”
2. 选择方向：选择 1–2 类漏洞（IDOR、XSS、SSRF 等）
3. 执行：只专注于选定的技术

路线选择 —— 广泛还是深入？

信号	广泛（侦察扫描）	深入（集中测试）
新项目，第一天	X
通配符范围 *.target.com	X
主 Web 应用，已测试超过 3 天		X
范围更新（新增域名）	X
发现有意思的子域名		X

阶段 1：侦察

目标：最大限度扩大攻击面。发现其他人遗漏的内容。

广泛方式（初步扫描）：

Subdomain enum -> DNS resolution -> HTTP probing -> Port scan -> Tech detect

深入方式（针对性测试）：

Google Dorks -> JS file download -> Hidden param discovery -> API mapping

发现内容	下一步操作
使用中的子域名及其技术栈	阶段 2（映射）
已知软件（WordPress、Jira）	立即检查 CVE 和默认配置
云资源（S3、Firebase）	测试权限（读取/写入/列出）
在某台主机上花 5 分钟后仍一无所获	跳过并尝试下一台主机（5 分钟规则）

命令：/recon target.com

阶段 2：映射与分析

目标：像开发者一样了解应用。

检查清单：

• 映射所有端点（Burp/Caido 站点地图 + JS 分析）
• 确认身份验证模型（cookie、JWT、OAuth、SAML？）
• 找出业务关键流程（付款、注册、密码重置、数据导出）
• 下载并分析 JS 文件，查找隐藏路由、机密信息和逻辑
• 确认角色和权限（用户、管理员、API 密钥）
• 记录“奇怪”的行为（命名、错误、时序异常）

发现内容	后续操作
含有有趣代码的 JS 文件	污点分析（Sink -> Source）
OAuth/SAML 身份验证	OAuth/SAML 检查清单
带 ID 参数的 API	阶段 3，针对 IDOR 进行测试
复杂的业务逻辑（付款、优惠券）	阶段 3，针对 BizLogic 进行测试
postMessage 监听器	DOM 分析、postMessage-tracker

阶段 3：漏洞发现

目标：找到漏洞。先使用基于错误的方法，再使用盲测方法。

根据测试目标选择的决策流程：

What input are you testing?
+-- ID parameter (user_id, order_id)
|   -> IDOR checklist
+-- Search/filter/sort field
|   -> SQLi, NoSQLi probing
+-- URL input / webhook / PDF gen
|   -> SSRF checklist
+-- Text field reflected in page
|   -> XSS (DOM or reflected)
+-- File upload
|   -> SVG XSS, web shell, path traversal
+-- Price/quantity/coupon
|   -> Business logic, race conditions
+-- Login / 2FA / password reset
|   -> Auth bypass
+-- Profile update API
|   -> Mass Assignment
+-- Template / wiki editor
|   -> SSTI
+-- Nothing obvious
    -> Fuzz with ffuf, try Error-based probing

基于错误与盲测的选择：

1. 先尝试基于错误的方法（发送 '、"、{{7*7}}、${7*7}）——留意 500 错误和堆栈跟踪
2. 没有错误？尝试基于时间的方法（SLEEP(10)、; sleep 10;）——观察响应时间
3. 时间没有差异？尝试 OOB（curl attacker.com、interactsh）——留意 DNS 回连
4. 还是没有结果？尝试布尔方法（AND 1=1 与 AND 1=0）——观察内容长度差异

发现内容	后续操作
低影响行为（重定向、自我型 XSS、cookie 注入）	将其串联利用——寻找连接器 gadget
已确认漏洞（XSS、IDOR、SQLi）	阶段 4（验证影响并提升等级）
被 WAF/CSP/403 拦截	使用绕过技术，然后重试
已知软件漏洞（CVE）	1-day 快速工作流
在此端点测试 20 分钟后仍一无所获	切换目标（20 分钟规则）

阶段 4：验证并提升等级

目标：证明最大的业务影响。将低危漏洞提升为严重漏洞。

提升等级的决策：

What did you find?
+-- XSS
|   +-- Can steal cookie/token? -> Session hijack -> ATO
|   +-- Cookie is HttpOnly? -> Force email change via XHR -> ATO
|   +-- Self-XSS only? -> Find CSRF to trigger it
+-- IDOR
|   +-- Can read PII? -> Automate scraping, show scale
|   +-- Can change password/email? -> Direct ATO
|   +-- UUID only? -> Find UUID leak source, then retry
+-- SSRF
|   +-- DNS only? -> DON'T REPORT. Try cloud metadata
|   +-- Can reach 169.254.169.254? -> Extract keys -> RCE
|   +-- Internal port scan? -> Find Redis/K8s -> RCE
+-- SQLi
|   +-- Error-based? -> Extract data (passwords, tokens)
|   +-- Can INTO OUTFILE? -> Web shell -> RCE
|   +-- Blind? -> Boolean/Time extraction
+-- Open Redirect
|   +-- OAuth flow? -> Token theft -> ATO
|   +-- javascript: scheme? -> XSS
+-- Blocked by defense
|   -> Bypass (WAF/CSP/proxy/sanitizer/2FA)
+-- Low-impact, can't escalate alone
    -> Find connector gadget for chain

证明影响后，检查：

• 攻击能否通过 0-1 次点击成功？（尽量减少前置条件）
• 影响对象是所有用户，还是特定角色？
• 业务损失金额是多少？

阶段 5：验证并报告

目标：获得报酬。让分诊人员的工作更轻松。

报告前检查：

Run /validate (7-Question Gate)
+-- All 7 pass? -> Write report
+-- Any fail? -> KILL the finding. Don't waste time.
+-- Borderline? -> Run /triage for quick go/no-go

多工具复现要求（仅限严重/高危）：

在将发现标记为严重或高危之前，必须使用至少 两种独立工具（不同技术栈、不同 HTTP 库）复现。跨工具结果一致，才能排除由工具造成的伪发现（例如，仅在 curl 中出现、在 Python requests 中消失的时序差异是工具造成的现象，而非漏洞）。

独立复现的示例：

• curl + Burp send_http1_request（TLS 技术栈不同，标头规范化方式不同）
• Python requests + 通过 ssl.wrap_socket 使用原始套接字（一种库会规范化，另一种不会）
• Burp Repeater + Python urllib（预期两者产生相同的线上结果）

报告中的复现命令必须可直接粘贴到 Shell 中运行——分诊人员会原样复制这些命令。如果 curl 版本需要特殊标志，或在某些系统上无法运行，请提供 Python 替代方案。

**授权测试经验教训：**三个严重漏洞（Authentication.asmx 暴力破解、TE.CL 请求走私、NTLM Type-2 信息泄露）均分别通过 curl、Python 原始套接字和 Burp 工具独立复现。正是跨工具的一致性让分诊报告确认这些发现并非工具造成的伪象。

报告：

Run /report
+-- Platform-specific format (H1/Bugcrowd/Intigriti/Immunefi)
+-- Title: [Bug Class] in [Endpoint] allows [role] to [impact]
+-- Impact-first summary (sentence 1 = what attacker CAN do)
+-- Exact HTTP requests in Steps to Reproduce
+-- Under 600 words
+-- CVSS 3.1 score that MATCHES actual impact

提交后：

• 等待分诊期间：尝试进一步提升漏洞等级（A->B 信号法）
• 如果已部署修复：重新测试是否可绕过（不完整的补丁 = 新漏洞）
• 使用 /remember 记录发现，供后续搜寻时参考

---

第 3 部分：导航与时机

非线性导航速查

我卡在这里，因为……	前往……
找不到任何子域名	阶段 1：尝试不同的侦察来源、Google Dorks
找到了子域名，但不知道该测试什么	阶段 2：梳理应用、下载 JS、了解身份验证
正在测试，但毫无进展	阶段 3：切换漏洞类别（20 分钟轮换规则）
找到了漏洞，但影响较低	阶段 4：尝试提升影响的路径或利用链
WAF/CSP/403 阻止了我的载荷	尝试绕过技术，然后回到当前阶段
在一个参数上卡了 45 分钟	停下。这是死胡同。转到下一个端点。
测试期间发现了新的 API 端点	返回阶段 2：先梳理，再发起攻击
找到了一个漏洞	A->B 信号：同一位开发者还犯了其他错误。花 20 分钟寻找同类问题。

20 分钟轮换计时

每隔 20 分钟问问自己：“我有进展吗？”

• 有 -> 继续
• 没有 -> 切换到下一个：端点 -> 子域名 -> 漏洞类别 -> 目标
• 在同一个目标上花了 2 周以上却毫无发现？ -> 考虑切换项目

反驳处理流程（用户说“再多找一些”时）

当用户不同意你的停止时机时，例如：“我找到了 10 多个漏洞，你也应该找到一样多”“再仔细找找”或“你漏掉了一些东西”：

默认假设：用户是对的。你停得太早了。

在反驳并说“我认为已经查完了，因为 X”之前，请执行以下操作：

1. 再阅读 3 个 hunt-* 技能，查看你尚未加载的内容。选择与已观察到的攻击面相匹配的技能（例如，自定义登录 → hunt-auth-bypass；SOAP 端点 → 查找特定于该协议的技能；URL 参数 → hunt-ssrf）。
2. 使用新技能的检查清单重新攻击同一攻击面。逐步完成新技能中的所有步骤，即使感觉重复也要照做。
3. 边检查边记录否定结果——确认“这里没有漏洞”本身也是值得让用户看到的发现（这能证明覆盖范围）。
4. 只有在完成 3 个新技能的检查清单后，才能提出反驳，而且只能列出具体测试过的内容。

**一次经授权的安全测试经验：**首次检查只发现了 5 个影响较低的问题，用户说：“我找到了 10 多个，再找找。”加载 hunt-auth-bypass 后（该技能之前虽已加载，却没有端到端地逐步执行），立即发现了 /_vti_bin/Authentication.asmx 这一旧版 SOAP 登录端点——这是此次安全测试中影响最大的漏洞。用户是对的；反驳只会是错的。

按阶段路由工具

阶段	工具	此顺序的原因
侦察：子域名	subfinder -> amass -> puredns -> httpx	先被动侦察（不触发检测）-> 解析 DNS -> 探测 HTTP 和技术栈
侦察：URL	gau + waymore -> katana -> uro	先查存档（找出被遗忘的端点）-> 主动爬取（渲染 JS）-> 去重
侦察：JS	jsluice + mantra + trufflehog --only-verified	提取 URL/密钥 -> 查找 API 密钥 -> 验证密钥是否实际可用
侦察：端口	naabu（广泛扫描）-> rustscan（深度扫描）	快速扫描前 1000 个端口 -> 对有价值的目标扫描全部 65535 个端口
侦察：扫描	nuclei -tags cve -> nuclei -tags takeover	先查已知 CVE -> 再查接管问题（立即处理）
映射：参数	arjun + paramspider + ParamMiner	暴力枚举隐藏参数 + 挖掘存档 + 检查缓存标头
映射：JS 代码	下载 -> jsluice -> 在 VS Code/Cursor 中 grep	提取 -> 静态分析 -> AI 辅助污点分析
映射：搜索语法	手动使用 Google Dorks	针对每个目标定制查询，找出自动化工具遗漏的内容
发现：模糊测试	ffuf -ac + cewl 自定义词表	自动校准过滤规则 + 针对目标定制的词语优于通用列表
发现：XSS	kxss -> dalfox	先过滤（哪些参数会反射？）-> 再扫描（仅扫描会反射的参数）
发现：SQLi	ghauri	针对类似 ID 的参数进行现代盲注 SQLi 测试
发现：SSRF	interactsh-client	用于盲 SSRF/XXE/RCE 的可自托管带外监听器
发现：WAF	wafw00f -> whatwaf	识别 WAF 供应商 -> 测试绕过技术
利用：403	byp4xx 或 nomore403	自动化执行 20 多种绕过技术
利用：接管	subzy	检查 CNAME 是否指向 70 多种易受攻击的服务
利用：云	s3scanner + aws CLI	扫描存储桶权限 -> 提取元数据凭证
利用：密钥	trufflehog --only-verified	仅保留经验证可用的密钥（无误报）

会话结束检查清单

• 保存所有 Burp/Caido 项目文件
• 记录任何“奇怪但尚不可利用”的行为（未来可用的攻击入口）
• 更新笔记，记录失败的尝试（不要用相同技术重复测试）
• 使用 /remember 记录发现

---

第 4 部分：方法纪律（防止误报）

大多数撤回的发现都源于四种反复出现的流程错误。每种错误都有一条硬性规则。

重要说明： 这些纪律规则关乎发现的正确性，而不是限制投入。它们告诉你哪些信号是真正的发现，哪些不是。它们并不是让你减少探测次数。如果你发现自己用这些规则作为提前停止的理由，那就是理解错了——加载 redteam-mindset（DO NOT STOP 首要指令）并继续。覆盖范围纪律与发现正确性纪律是相互独立的两个方面；两者都必须全面落实。

标记规范

测试反射、缓存投毒、参数污染或 OOB SSRF 时，注入的标记字符串必须唯一且醒目。

规则：

• 标记应为随机字母数字字符串，至少 8 个字符，不包含英文单词或协议关键词。
• 切勿使用 test、marker、evil、attacker、payload、javascript、script、AAAA、BBBB、你的域名，或任何可能自然出现在目标 HTML/JS/错误消息中的字符串。
• 好的标记： cpmark987abc、x4hd2k9pq、类似 dlsrcurl.<collab>.oastify.com 的 Collaborator 子域名前缀，或 __ZZ_MARKER_<random>_ZZ__。
• 声称发现反射前：在基线（不含标记）响应中搜索标记字符串。如果它自然出现，请更换标记。这项单一检查可发现 80% 的反射误报。
• 进行 OOB 测试时，为每个 Collaborator 负载添加不同的子标签（例如 dlsrcurl.<collab>、authsrc.<collab>），以便回调能识别触发的具体接收点。

**一次经授权的测试经历：**初始扫描报告称 X-Forwarded-Proto: javascript 会反射到多个 SharePoint 页面中。所谓的“反射”其实是 SP 帮助链接的 href 中自然出现了字面字符串 javascript（href="javascript:HelpWindowKey(...)"）。这是由标记不唯一导致的误报。

响应正文差异规则

要声称绕过，必须有响应正文差异，而不只是状态码差异。

规则：

• 如果 200 OK 的正文与基线逐字节相同，就不算绕过。
• 如果 200 OK 的正文有 5 个字节的差异，也许算——请确认具体变化是什么（关联 ID？时间戳？实际内容？）。
• 声称绕过前，务必并排比较正文差异：diff <(curl ... baseline) <(curl ... bypass)。
• 仅依据状态码的说法（例如“Host 头 X 返回 200，而不是 403”）是 Bug Bounty 平台上最常被驳回为 N/A 的类别。

一次经授权的测试经历：Host: target.example:[email protected] 返回了 HTTP 200，而基线返回 403。看起来像是 Host 头绕过。但正文逐字节相同（两者均为 8341 字节）——AWS ELB 将 Host 规范化为 target.example:80，丢弃了 @evil 部分。这并非绕过。

统计样本规则（适用于基于时间的说法）

单个离群值不是信号。网络抖动经常会产生 2 倍的离群值。

针对任何用户枚举 / 盲 SQLi / 盲 NoSQLi / 计时侧信道的说法，规则如下：

• 最小样本量：每组至少 n ≥ 10 次交错试验（对照组 + 测试组，随机排序，不能连续测试）。
• 计算每组的均值、中位数和 σ。
• 只有当可疑组的均值至少比对照组均值高 2σ 时，才算存在信号。
• n=1 测试中单个 2 倍离群值是网络抖动，不是信号。

**一次经授权的测试经历：**单次探测显示，Authentication.asmx Login 上 Administrator 的响应耗时为 1527 ms，而对照组约为 700 ms——看起来明显存在用户枚举信号。随后在 8 组中进行了 n=80 次交错试验，结果各组的均值都降至 685-716 ms，σ 为 25-74 ms。1527 ms 是网络抖动造成的。该发现已撤回。

Shell 循环禁令（>5 次迭代）

对于任何运行超过 5 次的迭代，请使用 Python（每次迭代都使用 try/except），不要使用 shell for 循环。

原因： zsh 数组展开在边缘情况下会静默失败。像 for x in "${arr[@]}" 这样的循环，如果数组未由前一个命令填充，就可能在不报错的情况下执行 0 次。用户看到的输出看似完整，实际却完全跳过了测试。

规则：

• 在 shell 中循环处理 ≤5 个硬编码项：可以。
• 任何遍历列表、文件或计算范围的操作：使用 Python。
• 始终统计结果。如果预期有 100 次探测，却只得到不到 50 行输出，说明循环吞掉了部分内容。

来自一次经授权的测试的教训： 一次 zsh 数组迭代动词篡改测试静默地没有发出任何 curl 请求，尽管循环超过 20 次（zsh 吞掉了数组）。输出看起来像是每次探测都重复显示“HIT [GET] /_api/web →”，但实际上缺少响应。约有 50 次探测的测试白做了。改用 Python 并在每次迭代时明确记录日志后，才显现出真实结果。

---

相关技能与调用链

• hunt-dispatch — 当 PART 0 模式已确认（redteam / wapt + blackbox|greybox）时使用。工作流基元：锁定测试类型答案后，将任务交给 hunt-dispatch，对目标进行指纹识别并加载匹配的平台和 hunt-* 技能集；当该技能输出其分类体系后，本技能不再是当前活动上下文。
• bug-bounty — 当用户提出笼统的“我该做什么”问题或开始测试新目标时使用。工作流基元：bug-bounty 是编排器，负责按主题指出要加载哪些 hunt-* 技能；本技能（bb-methodology）提供编排器执行时使用的 5 阶段工作流。
• triage-validation — 当发现完成 Phase 4、即将整理成报告时使用。工作流基元：Phase 5 明确调用 /validate（7-Question Gate）；只有通过全部 7 个问题的发现才会移交给 report-writing。
• offensive-osint + web2-recon — 当 Phase 1（侦察）处于活动状态时使用。工作流基元：Phase 1 的“广泛方法”会将资产工具库相关工作交给 offensive-osint，并将实时主机 + URL 流程交给 web2-recon。

---

操作员备注（Claude-BugHunter）

根据测试经验对引入的基础内容所做的补充。来自真实授权测试的经验，以及本仓库 31+ 个技能领域实时测试中的 Phase 2 验证。上游方法论涵盖了“做什么”；这一层涵盖了“何时真正有效”以及“失效模式”。

方法论没有告诉你的内容

引入的 5 阶段工作流是一份清单；真实测试则需要灵活应变。有时你会完全跳过某些阶段——客户端给你一个 URL 和一个 JWT，侦察工作已由其内部团队完成，Phase 1 便缩短为 10 分钟的指纹识别。有时你会把 80% 的测试时间花在 Phase 1，因为范围涉及一家拥有 200 项资产的金融服务母公司，而资产发现本身就是全部工作。方法论描绘的是每次测试中都存在的地形，而不是一条需要始终按同样方式走完的路线。

实际中的模式确认

第 0 部分（本文件开头的漏洞赏金与 WAPT、红队模式判定）是硬性规则，但答案并不总是摆在眼前。请仔细阅读范围说明：

• “范围内资产” + “范围外资产” + “安全港” → 漏洞赏金规范。以验证为重，必须进行 OOB 验证，不得窃取数据。
• “攻击链” + “目标” + “夺旗” + “对手模拟” → 红队。隐蔽性、持久化、横向移动均属有效手段。
• “合规” + “PCI” + “HIPAA” + “高管报告” + “修复时间线” → WAPT。以覆盖率为导向，以交付物为核心，无论能否利用，所有发现都计入。

当措辞混杂时（这种情况很常见——客户经常编写 WAPT 风格的工作说明书，却称之为红队行动），在确认之前，默认采用漏洞赏金规范。这是验证要求最严格的模式；客户确认属于红队后，随时可以放宽。反过来——误以为可以按红队方式自由操作，结果实际是 WAPT——会导致交付时撤回发现。

不同目标类型的阶段优先级调整

5 个阶段的权重并不相同。行动类型决定时间分配：

行动类型	侦察	搜寻	验证与报告
SaaS 漏洞赏金（范围明确）	10%	70%	20%
外部红队（范围广）	40%	30%	30%
WAPT（已提供资产清单）	0%	60%	40%
企业本地部署（单一产品）	5%	50%	45%

如果你把 SaaS 漏洞赏金行动 50% 的时间都花在侦察上，那就是在拖延搜寻。如果你只把外部红队行动 10% 的时间花在侦察上，那就已经输了——在这类行动中，攻击面图谱本身就是交付物。

何时打破方法论

如果在侦察的前 30 分钟内发现一个严重级别为 Critical 的问题，**立即停止侦察，彻底验证该问题，报告后再继续侦察。**方法论要求“完成当前阶段后再进入下一阶段”，但按小时计算的价值曲线并不认同。行动开始后 24 小时内确认并报告的 Critical，价值高于一份你最终根本无暇利用的完整资产清单。

反过来也一样：如果你已经搜寻某个候选问题 4 小时以上，而它在第二个账户上无法复现，那这个候选问题就不成立。不要再花 4 小时试图让一个无法成立的候选问题复现。放弃它，在笔记中记录撤回原因，然后继续。

纪律规则不可妥协

本文件中的纪律规则——OOB Gate、Marker Discipline、Body-Diff Rule、Statistical-Sample Rule、Server-Policy-vs-State、Pre-Severity Gate、Shell-Loop Ban——不是方法论，而是质量门槛。方法论规定操作顺序；这些规则则保障每一步的验证质量。

在 Phase 2D 的强化实验室行动中，这些规则均已验证：面对伪装成漏洞的行为，8/8 条纪律规则都能正确触发（伪装成 XSS 的 URL 回显、伪装成反射的词语碰撞、响应体字节完全相同却仅凭状态码声称“绕过”，以及没有实际泄露数据却声称 200-OK 数据泄露）。跳过这些规则时，验证通过率会急剧下降。摩擦感正是这些规则的作用——如果某条规则让人觉得碍事，那正说明它在发挥作用。它淘汰的那些发现，有一半最终无论如何都会被判定为 N/A。

• evidence-hygiene — Phase 5 收集 PoC 截图 / HAR 时使用。工作流的基本步骤：在截图中出现任何 Cookie / PII 之前，将任务交给 evidence-hygiene 执行脱敏流程。