Back to Details

bb-methodology

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Bug Bounty Methodology: Workflow + Mindset

Bug Bounty 方法论：工作流 + 思维模式

Master orchestrator for hunting sessions. Combines the 5-phase non-linear workflow with the critical thinking framework that separates top 1% hunters from the rest.
用于狩猎会话的主控编排器。将 5 阶段非线性工作流与批判性思维框架结合起来，后者让顶尖 1% 的猎手脱颖而出。

PART 0: MODE CONFIRMATION (Before Anything Else)

第 0 部分：模式确认（开始一切之前）

Confirm the engagement type before deciding what counts as a finding. The same target produces a different report shape depending on which mode applies. Getting this wrong is the single biggest waste of time in this workflow — answer it explicitly before Phase 0.
Engagement typeWhat counts as a findingWhat gets rejected
Bug bounty (H1 / Bugcrowd / Intigriti / private VDP)Impact-demonstrated bugs ONLY. Full chain to attacker-attainable harm.Hygiene (EoL software alone, permissive CSP alone, stack traces, info disclosure without concrete impact, "best practice" violations)
Red team (external client engagement)Hygiene findings + recon + IoCs + defensive-state observations are ALL deliverablesNothing — even "no finding here" is reportable as a positive defensive observation
Pentest (signed SoW / WAPT)Depends on SoW. Read scope explicitly. Usually accepts hygiene + impact + reconOut-of-scope assets, unsigned testing
Internal auditCompliance-mapped findings (PCI / ISO / NIST / DPDPA / GDPR)Findings without a control-mapping
Hard rule: Before Phase 0 runs, write the engagement type as the first line in your hunt notes. If you can't answer it from the user's instruction, ASK once. Don't assume — the mistake costs both you and the triager.
Lesson from an authorized engagement: First-pass on this target produced 5 hygiene findings (SP2013 EoL, permissive CSP, stack traces) shipped in red-team format. The engagement was bug-bounty. Findings would have been N/A'd as "informational, no impact demonstrated." After the corrected pass with hygiene-as-context-not-finding, the same target yielded 11 impact-demonstrated bugs including 3 Critical.
在决定什么算作 finding 之前，先确认 engagement type。 同一个目标在不同模式下会对应不同的报告结构。弄错模式是整个工作流中最大的时间浪费来源——必须在 Phase 0 之前明确回答。
Engagement type什么算作 finding什么会被拒绝
Bug bounty（H1 / Bugcrowd / Intigriti / 私有 VDP）仅限已证明实际影响的 bug。必须形成从漏洞到攻击者可达危害的完整链条。Hygiene（仅有 EoL 软件、宽松 CSP、堆栈跟踪、没有具体影响的信息泄露、“最佳实践”违规）
Red team（外部客户委托）Hygiene findings、recon、IoCs 和防御状态观察都属于交付物没有——即使“此处没有 finding”也可作为积极的防御观察结果进行报告
Pentest（已签署 SoW / WAPT）取决于 SoW。必须明确阅读范围。通常接受 Hygiene、影响证明和 recon范围外资产、未经授权的测试
Internal audit映射到合规项的 findings（PCI / ISO / NIST / DPDPA / GDPR）未映射控制项的 findings
硬性规则： 在 Phase 0 开始前，先在 hunt notes 的第一行写明 engagement type。如果无法根据用户的指示得出答案，就询问一次。不要擅自假设——这个错误会让操作人员和分诊人员都付出代价。
来自一次已授权项目的经验： 首次检查该目标时发现了 5 个 Hygiene findings（SP2013 EoL、宽松 CSP、堆栈跟踪），并按 red-team 格式提交。然而该项目实际属于 bug bounty，这些 findings 会被分诊为“信息性问题，未证明实际影响”。采用“将 Hygiene 作为上下文而非 finding”的正确方法重新检查后，同一目标最终发现了 11 个已证明影响的 bug，其中包括 3 个 Critical。

PART 1: MINDSET (How to Think)

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

Core Principle

核心原则

Hunting is not "find a bug" -- it is "prove an attack scenario." Think like an attacker with a specific goal, not a scanner looking for patterns.
狩猎不是“找到一个 bug”——而是“证明一个攻击场景”。要像一个拥有明确目标的攻击者一样思考，而不是像一个扫描模式匹配的扫描器。

Daily Discipline: Define, Select, Execute

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

Before touching any tool:
  1. Define: "Today I target [feature/domain] to achieve [CIA impact]"
  2. Select: Choose 1-2 vuln classes (IDOR, Race Condition, etc.)
  3. Execute: Focus ONLY on selected techniques. No wandering.
在接触任何工具之前：
  1. 定义：“今天我以 [功能/领域] 为目标，争取实现 [CIA/ATO/RCE 影响]”
  2. 选择：选择 1～2 个漏洞类别（IDOR、Race Condition 等）
  3. 执行：只专注于选定的技术。不要四处游走。

5 Ultimate Goals (Pick One Per Session)

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

  1. Confidentiality -- steal data the attacker shouldn't see
  2. Integrity -- modify data the attacker shouldn't change
  3. Availability -- disrupt service (app-level DoS only)
  4. Account Takeover -- control another user's account
  5. RCE -- execute commands on the server
  1. Confidentiality——窃取攻击者本不应看到的数据
  2. Integrity——修改攻击者本不应更改的数据
  3. Availability——中断服务（仅限应用级 DoS）
  4. Account Takeover——控制另一个用户的账户
  5. RCE——在服务器上执行命令

4 Thinking Domains

4 个思维领域

1. Critical Thinking (deep analysis)

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

Question trust boundaries:
  • Frontend control disabled? Send request directly via proxy
  • user_role=user
    cookie? Change to 
    admin
  • price=1000
    in POST? Change to 
    1
  • <script>
    blocked? Try 
    <img onerror=...>
Reverse-engineer developer psychology:
  • Feature A has auth checks -> Similar feature B (newly added) probably doesn't
  • Complex flows (coupon + points + refund) -> Edge cases have bugs
  • /api/v2/user
    exists -> Does 
    /api/v1/user
    still work with weaker auth?
What-If experiments:
  • Skip checkout -> hit 
    /checkout/success
    directly
  • Skip 2FA -> navigate to 
    /dashboard
  • Send coupon request 10x simultaneously -> Race condition?
  • Replace 
    guid=f8a2...
    with 
    id=100
    on sibling endpoint -> IDOR?
质疑信任边界：
  • 前端控制已禁用？通过 proxy 直接发送请求
  • user_role=user
    cookie？将其改为 
    admin
  • POST 中有 
    price=1000
    ？将其改为 
    1
  • <script>
    被阻止？尝试 
    <img onerror=...>
逆向理解开发者心理：
  • 功能 A 有认证检查 -> 类似功能 B（较新添加的）很可能没有
  • 复杂流程（优惠券 + 积分 + 退款）-> 边缘情况往往存在 bug
  • 存在 
    /api/v2/user
    -> 
    /api/v1/user
    是否仍可使用，而认证更弱？
What-If 实验：
  • 跳过结账 -> 直接访问 
    /checkout/success
  • 跳过 2FA -> 导航至 
    /dashboard
  • 同时发送 10 次优惠券请求 -> 存在 Race Condition？
  • 将兄弟端点中的 
    guid=f8a2...
    替换为 
    id=100
    -> 存在 IDOR？

2. Multi-Perspective (multiple angles)

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

PerspectiveWhat to check
Horizontal (same role)User A's token + User B's ID -> IDOR
Vertical (different role)Regular user -> 
/admin/deleteUser
Data flow (proxy view)Hidden params in JSON: 
debug=false
, 
discount_rate
Time/StateRace conditions, post-delete session reuse
Client environmentMobile UA -> legacy API with weaker auth
Business impact"What's the $ damage if this breaks?"
视角检查内容
水平视角（相同角色）用户 A 的 token + 用户 B 的 ID -> IDOR
垂直视角（不同角色）普通用户 -> 
/admin/deleteUser
数据流（proxy 视角）JSON 中的隐藏参数：
debug=false
、
discount_rate
时间/状态Race Condition、删除后重用 session
客户端环境移动端 UA -> 使用认证更弱的旧版 API
业务影响“如果这里被攻破，会造成多少美元损失？”

3. Tactical Thinking (pattern detection)

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

  • Naming anomaly: 
    userId
    everywhere but suddenly 
    user_id
    -> different dev, weaker security
  • Error diff: Same 403 but different JSON structure -> different backend systems
  • Environment diff: Prod vs Dev/Staging -> debug headers, CSP disabled
  • Version diff: JS file before/after update -> new endpoints, removed params
  • Supply chain: Check framework/library versions for known CVEs
  • Third-party integration: Stripe/Auth0/Intercom -> webhook signature missing?
  • 命名异常： everywhere 都使用 
    userId
    ，却突然出现 
    user_id
    -> 可能由不同开发者实现，安全性更弱
  • 错误差异：相同 403，但 JSON 结构不同 -> 来自不同的后端系统
  • 环境差异：生产环境与 Dev/Staging -> 调试 header、CSP 被禁用
  • 版本差异：更新前后的 JS 文件 -> 新端点、被移除的参数
  • 供应链：检查 framework/library 版本是否存在已知 CVE
  • 第三方集成：Stripe/Auth0/Intercom -> 是否缺少 webhook 签名验证？

4. Strategic Thinking (big picture)

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

  • Asymmetry: Defender must patch ALL holes. You only need ONE.
  • Intuition engineering: Log why something "feels wrong." Verify later. Update mental DB.
  • Unknown management: Can't understand something? Add to "investigate later" list. Just-in-Time Learning.
  • 不对称性：防守方必须修补所有漏洞，而攻击者只需找到一个。
  • 直觉工程：记录某个点“感觉不对”的原因。稍后进行验证，并更新心理知识库。
  • 未知项管理：无法理解某个内容？将其加入“稍后调查”列表。采用 Just-in-Time Learning。

Amateur vs Pro: 7-Phase Comparison

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

PhaseAmateurPro
ReconMain domain onlyShadow IT, dev environments, all assets
DiscoveryLook for errorsLook for design contradictions, business logic flaws
ExploitGive up when blockedBuild filter-bypass payloads
EscalationReport the phenomenon onlyChain to real harm (session steal, ATO)
FeasibilityInclude unrealistic conditionsMinimize attack prerequisites
ReportingState facts onlyQuantify business risk
RetestCheck if old PoC failsAnalyze fix method, find incomplete patches
阶段业余人员专业人士
Recon只关注主域名Shadow IT、开发环境、全部资产
Discovery寻找错误寻找设计矛盾、业务逻辑缺陷
Exploit遇到阻碍就放弃构建过滤器绕过 payload
Escalation只报告表面现象串联至真实危害（窃取 session、ATO）
Feasibility纳入不现实的前提条件尽量减少攻击前提条件
Reporting只陈述事实量化业务风险
Retest旧 PoC 失效便停止分析修复方式，寻找不完整补丁

Two Approach Routes

两条路线

  • Route A (Feature-based): "This feature is complex" -> deep-dive its input handling -> find vuln
  • Route B (Vuln-based): "I want IDOR" -> find endpoints with sequential IDs -> test access control
  • 路线 A（基于功能）：“这个功能很复杂”-> 深入检查其输入处理 -> 找到漏洞
  • 路线 B（基于漏洞）：“我要找 IDOR”-> 寻找带顺序 ID 的端点 -> 测试访问控制

Anti-Patterns (Stop Doing These)

反模式（停止做这些事）

  • Program hopping: Stick with one target minimum 2 weeks / 30 hours
  • Tool-only hunting: Automation finds duplicates. Manual testing finds unique bugs.
  • Rabbit hole: Max 45 min per parameter. Set a timer. If stuck, sleep on it.
  • No goal: "Just looking around" = wasted time. Always Define first.
  • 频繁更换项目：至少坚持一个目标 2 周或 30 小时
  • 只依赖工具狩猎：自动化会发现重复问题，手工测试才能发现独特 bug
  • 陷入兔子洞：每个参数最多投入 45 分钟。设置计时器；卡住就先睡一觉。
  • 没有目标：“只是随便看看”= 浪费时间。永远先执行 Define。

PART 2: WORKFLOW (What to Do)

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

The 5-Phase Non-Linear Flow

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 |
+-------------------------------------------------+
THIS IS NOT LINEAR. Move freely between phases. When stuck, return to a previous phase.
+-------------------------------------------------+
|                                                 |
|  +----------+    +----------+    +----------+   |
|  | 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 |
+-------------------------------------------------+
这不是线性流程。 可以在各阶段之间自由移动。遇到阻碍时，返回之前的阶段。

Phase 0: SESSION START (Every Time)

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

Before touching any tool, answer these:
  1. Define: "Today I target [feature/domain] to achieve [C/I/A/ATO/RCE]"
  2. Select: Choose 1-2 vuln classes (IDOR, XSS, SSRF, etc.)
  3. Execute: Focus ONLY on selected techniques
Route selection -- Wide or Deep?
SignalWide (recon sweep)Deep (focused testing)
New program, first dayX
Wildcard scope 
*.target.com
X
Main webapp, been here >3 daysX
Scope update (new domain added)X
Found interesting subdomainX
在接触任何工具之前，回答以下问题：
  1. 定义：“今天我以 [功能/领域] 为目标，争取实现 [C/I/A/ATO/RCE]”
  2. 选择：选择 1～2 个漏洞类别（IDOR、XSS、SSRF 等）
  3. 执行：只专注于选定的技术
路线选择——广度还是深度？
信号广度（recon sweep）深度（聚焦测试）
新项目，第一天X
通配范围 
*.target.com
X
主 Web 应用，已测试超过 3 天X
范围更新（新增域名）X
发现有趣的子域名X

Phase 1: RECON

Phase 1：RECON

Goal: Maximize attack surface. Find what others missed.
Wide approach (initial sweep):
Subdomain enum -> DNS resolution -> HTTP probing -> Port scan -> Tech detect
Deep approach (targeted):
Google Dorks -> JS file download -> Hidden param discovery -> API mapping
What you findNext action
Live subdomains with tech stackPhase 2 (Mapping)
Known software (WordPress, Jira)Check CVEs + defaults immediately
Cloud resources (S3, Firebase)Test permissions (read/write/list)
Nothing after 5 min on a hostSkip, try next host (5-minute rule)
Command: 
/recon target.com
目标：最大化攻击面。发现别人遗漏的内容。
广度方法（初始扫描）：
Subdomain enum -> DNS resolution -> HTTP probing -> Port scan -> Tech detect
深度方法（定向测试）：
Google Dorks -> JS file download -> Hidden param discovery -> API mapping
发现内容下一步行动
存活子域名及技术栈Phase 2（Mapping）
已知软件（WordPress、Jira）立即检查 CVE 和默认配置
云资源（S3、Firebase）测试权限（read/write/list）
某主机 5 分钟后仍无任何发现跳过并尝试下一个主机（5 分钟规则）
命令：
/recon target.com

Phase 2: MAPPING & ANALYSIS

Phase 2：MAPPING 与 ANALYSIS

Goal: Understand the app like its developer does.
Checklist:
  • Map all endpoints (Burp/Caido sitemap + JS analysis)
  • Identify auth model (cookie, JWT, OAuth, SAML?)
  • Find business-critical flows (payment, registration, password reset, data export)
  • Download and analyze JS files for hidden routes, secrets, logic
  • Identify roles and permissions (user, admin, API keys)
  • Note "weird" behaviors (anomalies in naming, errors, timing)
What you findNext action
JS files with interesting codeTaint analysis (Sink -> Source)
OAuth/SAML authenticationOAuth/SAML checklist
API with ID parametersPhase 3, target IDOR
Complex business logic (payment, coupon)Phase 3, target BizLogic
postMessage listenersDOM analysis, postMessage-tracker
目标：像开发者一样理解应用。
检查清单：
  • 映射所有端点（Burp/Caido sitemap + JS 分析）
  • 识别认证模型（cookie、JWT、OAuth、SAML？）
  • 找出关键业务流程（支付、注册、密码重置、数据导出）
  • 下载并分析 JS 文件，寻找隐藏路由、secret 和逻辑
  • 识别角色和权限（user、admin、API key）
  • 记录“异常”行为（命名、错误和耗时中的异常）
发现内容下一步行动
包含有趣代码的 JS 文件污点分析（Sink -> Source）
OAuth/SAML 认证OAuth/SAML 检查清单
带 ID 参数的 API进入 Phase 3，针对 IDOR
复杂业务逻辑（支付、优惠券）进入 Phase 3，针对 BizLogic
postMessage listenerDOM 分析、postMessage-tracker

Phase 3: VULNERABILITY DISCOVERY

Phase 3：漏洞发现

Goal: Find the bug. Use Error-based first, then Blind-based.
Decision flow based on what you're testing:
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
Error vs Blind decision:
  1. Try Error-based first (send 
    '
    , 
    "
    , 
    {{7*7}}
    , 
    ${7*7}
    ) -- watch for 500 errors, stack traces
  2. No error? Time-based (
    SLEEP(10)
    , 
    ; sleep 10;
    ) -- watch response time
  3. No time diff? OOB (
    curl attacker.com
    , interactsh) -- watch for DNS callback
  4. Still nothing? Boolean (
    AND 1=1
    vs 
    AND 1=0
    ) -- watch content-length diff
What you findNext action
Low-impact behavior (redirect, self-XSS, cookie injection)Chain it -- find a connector gadget
Confirmed vuln (XSS, IDOR, SQLi)Phase 4 (Prove and Escalate)
Blocked by WAF/CSP/403Bypass techniques, then retry
Known software vuln (CVE)1-day speed workflow
Nothing after 20 min on this endpointRotate (20-minute rule)
目标：找到 bug。先使用 Error-based，再使用 Blind-based。
根据测试对象选择路径：
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
Error 与 Blind 的决策顺序：
  1. 先尝试 Error-based（发送 
    '
    、
    "
    、
    {{7*7}}
    、
    ${7*7}
    ）——观察 500 错误和堆栈跟踪
  2. 没有错误？尝试基于时间的检测（
    SLEEP(10)
    、
    ; sleep 10;
    ）——观察响应时间
  3. 没有时间差？尝试 OOB（
    curl attacker.com
    、interactsh）——观察 DNS 回调
  4. 仍无结果？尝试 Boolean（
    AND 1=1
    与 
    AND 1=0
    ）——观察 content-length 差异
发现内容下一步行动
低影响行为（重定向、self-XSS、cookie 注入）进行串联——寻找 connector gadget
已确认漏洞（XSS、IDOR、SQLi）Phase 4（证明并扩大影响）
被 WAF/CSP/403 阻止使用绕过技术后重试
已知软件漏洞（CVE）执行 1 天快速工作流
测试该端点 20 分钟后仍无发现轮换目标（20 分钟规则）

Phase 4: PROVE & ESCALATE

Phase 4：证明与扩大影响

Goal: Prove maximum business impact. Turn Low into Critical.
Escalation decision:
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
After proving impact, check:
  • Can attack work with 0-1 clicks? (minimize prerequisites)
  • Does it affect all users or specific role?
  • What's the business $ impact?
目标：证明最大业务影响。将 Low 提升为 Critical。
扩大影响的决策路径：
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 次点击内完成？（尽量减少前提条件）
  • 是否会影响所有用户，还是仅影响特定角色？
  • 对业务的美元影响是多少？

Phase 5: VALIDATE & REPORT

Phase 5：验证与报告

Goal: Get paid. Make triager's job easy.
Pre-report gate:
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
Multi-Tool Reproduction Bar (Critical / High only):
Before labeling a finding Critical or High, reproduce it via at least two independent tools (different stacks, different HTTP libraries). Cross-tool consistency rules out tool-artefact findings (e.g., a curl-only timing differential that disappears under Python 
requests
was an artefact, not a bug).
Examples of independent reproductions:
  • curl
    + Burp 
    send_http1_request
    (different TLS stacks, different header normalisation)
  • Python 
    requests
    + raw socket via 
    ssl.wrap_socket
    (one library normalises, one doesn't)
  • Burp Repeater + Python 
    urllib
    (same wire result expected from both)
The reproduction commands MUST be paste-into-shell ready in the report — a triager copies them verbatim. If the curl version requires special flags or breaks on certain systems, include a Python alternative.
Lesson from an authorized engagement: All three Critical findings (Authentication.asmx brute-force, TE.CL smuggling, NTLM Type-2 disclosure) were each independently reproduced via curl + Python raw sockets + Burp tooling. The cross-tool consistency was what convinced the triage write-up that the findings were not artefacts.
Report:
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
After submission:
  • While waiting for triage: try to escalate further (A->B signal method)
  • If fix deployed: re-test for bypass (incomplete patch = new bug)
  • Record finding with 
    /remember
    for hunt memory
目标：获得报酬。让分诊人员更容易处理。
报告前关卡：
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
多工具复现门槛（仅限 Critical / High）：
在将 finding 标记为 Critical 或 High 之前，至少使用两种独立工具复现（不同技术栈、不同 HTTP library）。跨工具的一致性可以排除工具伪影，例如仅在 curl 中出现、换用 Python 
requests
后便消失的计时差异。
独立复现示例：
  • curl
    + Burp 
    send_http1_request
    （不同 TLS 栈、不同 header 规范化方式）
  • Python 
    requests
    + 通过 
    ssl.wrap_socket
    使用原始 socket（一个 library 会做规范化，另一个不会）
  • Burp Repeater + Python 
    urllib
    （预期两者产生相同的 wire result）
报告中的复现命令必须能够直接粘贴到 shell 中运行——分诊人员会逐字复制。如果 curl 版本需要特殊参数或无法在某些系统上运行，应同时提供 Python 替代方案。
来自一次已授权项目的经验： 3 个 Critical findings（Authentication.asmx brute-force、TE.CL smuggling、NTLM Type-2 disclosure）均通过 curl + Python 原始 socket + Burp 工具独立复现。正是这种跨工具一致性让分诊报告相信这些 findings 并非工具伪影。
报告：
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 signal 方法）
  • 如果修复已部署：重新测试绕过方式（不完整补丁 = 新 bug）
  • 使用 
    /remember
    记录 finding，以供后续狩猎检索

PART 3: NAVIGATION & TIMING

第 3 部分：导航与时间控制

Non-Linear Navigation Quick Reference

非线性导航快速参考

I'm stuck because...Go to...
Can't find any subdomainsPhase 1: Try different recon sources, Google Dorks
Found subdomain but don't know what to testPhase 2: Map the app, download JS, understand auth
Testing but nothing worksPhase 3: Switch vuln class (20-min rotation rule)
Found a bug but impact is lowPhase 4: Escalation paths or gadget chaining
WAF/CSP/403 blocking my payloadBypass techniques, then return to current phase
Been stuck for 45 min on one paramSTOP. Rabbit hole. Move to next endpoint.
New API endpoint discovered during testingReturn to Phase 2: map it before attacking
Found one bugA->B signal: same dev made more mistakes. Hunt 20 min for siblings.
遇到阻碍的原因应前往
找不到任何子域名Phase 1：尝试不同 recon 来源、Google Dorks
找到子域名但不知道测试什么Phase 2：映射应用、下载 JS、理解认证
正在测试但没有效果Phase 3：切换漏洞类别（20 分钟轮换规则）
发现 bug 但影响较低Phase 4：扩大影响路径或串联 gadget
WAF/CSP/403 阻止 payload使用绕过技术，然后返回当前阶段
在同一个参数上卡住 45 分钟停止。不要陷入兔子洞。前往下一个端点。
测试期间发现新 API 端点返回 Phase 2：先映射，再攻击
发现一个 bugA->B signal：同一位开发者还犯了更多错误。再狩猎 20 分钟以寻找同类问题。

20-Minute Rotation Clock

20 分钟轮换时钟

Every 20 minutes ask yourself: "Am I making progress?"
  • Yes -> Continue
  • No -> Rotate to next: endpoint -> subdomain -> vuln class -> target
  • Been on same target 2+ weeks with no findings? -> Consider switching program
每 20 分钟问自己：“我正在取得进展吗？”
  • 是 -> 继续
  • 否 -> 轮换下一个方向：端点 -> 子域名 -> 漏洞类别 -> 目标
  • 已持续测试同一目标 2 周以上却没有 findings？-> 考虑更换项目。

Pushback Protocol (When the User Says "Find More")

抗阻协议（当用户要求“Find More”时）

When the user disagrees with your stopping point — e.g., "I've found 10+ bugs, you should find the same," or "look harder," or "you're missing things":
Default assumption: they are correct. You stopped early.
Before pushing back with "I think we're done because X," do this:
  1. Re-read 3 more 
    hunt-*
    skills     beyond what you have loaded. Pick ones that match observed surface (e.g., custom login → 
    hunt-auth-bypass
    ; SOAP endpoints → look for protocol-specific skills; URL parameters → 
    hunt-ssrf
    ).
  2. Re-attack the same surface with the new skill checklists. Walk every step in the new skills, even if it feels redundant.
  3. Document negatives as you go — a confirmed "no bug here" is itself a finding for the user to see (it proves coverage).
  4. Only after exhausting 3 new skills' checklists do you push back, and only with a concrete list of what was tested.
Lesson from an authorized engagement: After a first-pass of 5 weak findings the user said "I have 10+, find them." Loading 
hunt-auth-bypass
(which had been loaded but not walked through end-to-end) immediately surfaced the 
/_vti_bin/Authentication.asmx
legacy SOAP login — the highest-impact bug in the engagement. The user was right; pushback would have been wrong.
当用户不同意你的停止点时，例如“已经找到 10 多个 bug，你也得找到这么多”“再深入查一下”或“你漏掉了一些”：
默认假设：用户是对的，是你过早停止了。
在说“我认为可以结束了，因为……”之前，执行以下操作：
  1. 重新阅读当前已加载内容之外的 3 个 
    hunt-*
    skill。选择与已观察攻击面匹配的 skill，例如自定义登录 -> 
    hunt-auth-bypass
    ；SOAP 端点 -> 查找协议专用 skill；URL 参数 -> 
    hunt-ssrf
    。
  2. 使用新 skill 的检查清单重新攻击同一攻击面。即使感觉重复，也要逐步执行新 skill 中的每个步骤。
  3. 持续记录阴性结果——“已确认此处没有 bug”本身就是一项可供用户查看的结果，能够证明测试覆盖度。
  4. 只有在完整执行 3 个新 skill 的检查清单后，才可以提出异议，并且必须附上已测试项目的具体清单。
来自一次已授权项目的经验： 首次检查发现 5 个弱 findings 后，用户表示“我有 10 多个，继续找”。加载 
hunt-auth-bypass
（该 skill 之前已经加载，但没有从头到尾执行）后，立即发现了 
/_vti_bin/Authentication.asmx
旧版 SOAP 登录——这是整个项目中影响最大的 bug。用户是对的；此时提出异议反而会出错。

Tool Routing by Phase

按阶段路由工具

PhaseToolsWhy this order
Recon: Subdomains
subfinder
-> 
amass
-> 
puredns
-> 
httpx
Passive first (no detection) -> resolve DNS -> probe HTTP + tech stack
Recon: URLs
gau
+ 
waymore
-> 
katana
-> 
uro
Archive (forgotten endpoints) -> active crawl (JS-rendered) -> deduplicate
Recon: JS
jsluice
+ 
mantra
+ 
trufflehog --only-verified
Extract URLs/secrets -> find API keys -> verify keys actually work
Recon: Ports
naabu
(wide) -> 
rustscan
(deep)		Fast top-1000 sweep -> full 65535 on interesting targets
Recon: Scan
nuclei -tags cve
-> 
nuclei -tags takeover
Known CVEs first -> then takeover (act immediately)
Mapping: Params
arjun
+ 
paramspider
+ ParamMiner		Brute-force hidden params + mine archives + cache headers
Mapping: JS codeDownload -> 
jsluice
-> VS Code/Cursor grep		Extract -> static analysis -> AI-assisted taint analysis
Mapping: DorksManual Google DorksCustom per-target queries find what automation misses
Discovery: Fuzz
ffuf -ac
+ 
cewl
custom wordlist		Auto-calibrate filtering + target-specific words beat generic lists
Discovery: XSS
kxss
-> 
dalfox
Filter (which params reflect?) -> scan (only reflective params)
Discovery: SQLi
ghauri
Modern blind SQLi on ID-like parameters
Discovery: SSRF
interactsh-client
Self-hosted OOB listener for blind SSRF/XXE/RCE
Discovery: WAF
wafw00f
-> 
whatwaf
Identify WAF vendor -> test bypass techniques
Exploit: 403
byp4xx
or 
nomore403
20+ bypass techniques automated
Exploit: Takeover
subzy
Checks CNAME against 70+ vulnerable services
Exploit: Cloud
s3scanner
+ 
aws
CLI		Scan bucket permissions -> extract metadata credentials
Exploit: Secrets
trufflehog --only-verified
Only verified working keys (no false positives)
阶段工具为什么采用这个顺序
Recon：子域名
subfinder
-> 
amass
-> 
puredns
-> 
httpx
先被动（不会触发检测）-> 解析 DNS -> 探测 HTTP 和技术栈
Recon：URL
gau
+ 
waymore
-> 
katana
-> 
uro
归档（被遗忘的端点）-> 主动爬取（JS 渲染）-> 去重
Recon：JS
jsluice
+ 
mantra
+ 
trufflehog --only-verified
提取 URL/secret -> 查找 API key -> 验证 key 确实可用
Recon：端口
naabu
（广度）-> 
rustscan
（深度）		快速扫描 top 1000 -> 对有趣目标扫描完整 65535 端口
Recon：扫描
nuclei -tags cve
-> 
nuclei -tags takeover
先检查已知 CVE -> 再检查接管问题（立即行动）
Mapping：参数
arjun
+ 
paramspider
+ ParamMiner		暴力发现隐藏参数 + 挖掘归档和 cache header
Mapping：JS 代码下载 -> 
jsluice
-> VS Code/Cursor grep		提取 -> 静态分析 -> AI 辅助污点分析
Mapping：Dorks手工 Google Dorks针对每个目标定制查询，寻找自动化遗漏的内容
Discovery：Fuzz
ffuf -ac
+ 
cewl
自定义 wordlist		自动校准过滤 + 目标专属词汇优于通用列表
Discovery：XSS
kxss
-> 
dalfox
过滤（哪些参数会反射？）-> 扫描（仅扫描反射型参数）
Discovery：SQLi
ghauri
对类似 ID 的参数执行现代 blind SQLi 测试
Discovery：SSRF
interactsh-client
自托管 OOB listener，用于 blind SSRF/XXE/RCE
Discovery：WAF
wafw00f
-> 
whatwaf
识别 WAF 厂商 -> 测试绕过技术
Exploit：403
byp4xx
或 
nomore403
自动化执行 20 多种绕过技术
Exploit：接管
subzy
对照 70 多种易受攻击服务检查 CNAME
Exploit：云
s3scanner
+ 
aws
CLI		扫描 bucket 权限 -> 提取 metadata credential
Exploit：Secret
trufflehog --only-verified
仅保留已验证可用的 key（避免误报）

Session End Checklist

会话结束检查清单

  • Save all Burp/Caido project files
  • Record any "weird but not yet exploitable" behaviors (future gadgets)
  • Update notes with failed attempts (don't re-test with same techniques)
  • Log findings with 
    /remember
  • 保存所有 Burp/Caido 项目文件
  • 记录任何“异常但尚不可利用”的行为（作为未来的 gadget）
  • 使用失败尝试更新笔记（不要用相同技术重复测试）
  • 使用 
    /remember
    记录 findings

PART 4: METHODOLOGY DISCIPLINE (False-Positive Prevention)

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

Most retracted findings come from four recurring process bugs. Each has a hard rule.
Important framing: These discipline rules are about correctness of findings — not throttling of effort. They tell you which signals are real findings and which aren't. They do not tell you to send fewer probes. If you find yourself using these rules to justify stopping early, you're misreading them — load 
redteam-mindset
(DO NOT STOP primary directive) and continue. Coverage discipline and finding-correctness discipline are orthogonal axes; you need both on full.
大多数被撤回的 findings 都源于四类反复出现的流程 bug。每一类都有硬性规则。
重要说明： 这些纪律规则关注的是 finding 的正确性，而不是限制投入。规则用于判断哪些信号是真正的 finding、哪些不是。它们不是让你减少探测。如果发现自己在用这些规则为提前停止辩护，说明你误解了规则——加载 
redteam-mindset
（DO NOT STOP 主指令）并继续执行。覆盖度纪律和 finding 正确性纪律是两个正交的维度，两者都需要做到满分。

Marker Discipline

Marker 纪律

When testing for reflection, cache poisoning, parameter pollution, or OOB SSRF, the marker string you inject MUST be unique and unmistakable.
Rules:
  • Markers are random alphanumeric strings, 8+ characters, no English words, no protocol keywords.
  • NEVER use 
    test
    , 
    marker
    , 
    evil
    , 
    attacker
    , 
    payload
    , 
    javascript
    , 
    script
    , 
    AAAA
    , 
    BBBB
    , your domain name, or any string that could plausibly appear naturally in the target's HTML/JS/error messages.
  • Good markers: 
    cpmark987abc
    , 
    x4hd2k9pq
    , a Collaborator subdomain prefix like 
    dlsrcurl.<collab>.oastify.com
    , or 
    __ZZ_MARKER_<random>_ZZ__
    .
  • Before claiming reflection: search the baseline (no-marker) response for the marker string. If it appears naturally, change your marker. This single check catches 80% of false-positive reflection reports.
  • For OOB testing, sub-tag each Collaborator payload (e.g., 
    dlsrcurl.<collab>
    , 
    authsrc.<collab>
    ) so callbacks identify the specific sink that fired.
Lesson from an authorized engagement: Initial scan flagged 
X-Forwarded-Proto: javascript
as reflecting into multiple SharePoint pages. The "reflection" was the literal word 
javascript
appearing naturally in SP help-link hrefs (
href="javascript:HelpWindowKey(...)"
). False positive caused by a non-unique marker.
测试反射、cache poisoning、参数污染或 OOB SSRF 时，注入的 marker 字符串必须唯一且清晰可辨。
规则：
  • Marker 应为随机字母数字字符串，长度 8+，不得包含英文单词或协议关键字。
  • 绝不使用 
    test
    、
    marker
    、
    evil
    、
    attacker
    、
    payload
    、
    javascript
    、
    script
    、
    AAAA
    、
    BBBB
    、自己的域名，或任何可能自然出现在目标 HTML/JS/错误消息中的字符串。
  • 合格 marker：
    cpmark987abc
    、
    x4hd2k9pq
    、类似 
    dlsrcurl.<collab>.oastify.com
    的 Collaborator 子域名前缀，或 
    __ZZ_MARKER_<random>_ZZ__
    。
  • 在声称存在反射前，先在基线响应（不带 marker）中搜索该 marker 字符串。如果它会自然出现，则更换 marker。仅此一项检查就能拦截 80% 的误报反射报告。
  • 进行 OOB 测试时，为每个 Collaborator payload 添加子标签，例如 
    dlsrcurl.<collab>
    、
    authsrc.<collab>
    ，使回调能够识别具体触发的 sink。
来自一次已授权项目的经验： 初始扫描将 
X-Forwarded-Proto: javascript
标记为反射到多个 SharePoint 页面。实际上，“反射”只是 
javascript
一词自然出现在 SP 帮助链接的 href 中（
href="javascript:HelpWindowKey(...)"
）。由于 marker 不唯一，产生了误报。

Body-Diff Rule

Body-Diff 规则

A bypass claim requires response body differential, not just status code.
Rules:
  • 200 OK with byte-identical body to the baseline is NOT a bypass.
  • 200 OK with a 5-byte difference might be — verify what changed (correlation ID? timestamp? real content?).
  • Always diff the body side-by-side before claiming bypass: 
    diff <(curl ... baseline) <(curl ... bypass)
    .
  • Status-code-only claims (e.g. "Host header X gave 200 instead of 403") are the most common rejected-as-N/A category on bug bounty platforms.
Lesson from an authorized engagement: 
Host: target.example:80@evil.example.com
returned HTTP 200 instead of the baseline 403. Looked like a Host-header bypass. But the body was byte-identical (8341 bytes both) — the AWS ELB normalised the Host to 
target.example:80
, dropping the 
@evil
portion. Not a bypass.
声称绕过时，响应正文必须存在差异，而不能只有状态码不同。
规则：
  • 返回 200 OK 且正文与基线逐字节相同，不算绕过。
  • 返回 200 OK 且仅有 5 字节差异，可能算——先验证具体变化是什么（correlation ID？时间戳？真实内容？）。
  • 声称绕过前，始终并排比较正文：
    diff <(curl ... baseline) <(curl ... bypass)
    。
  • 仅依据状态码提出结论，例如“Host header X 返回 200 而不是 403”，是 bug bounty 平台上最常见的 N/A 类别。
来自一次已授权项目的经验： 
Host: target.example:80@evil.example.com
返回 HTTP 200，而基线为 403，看起来像是 Host header 绕过。但两者正文逐字节相同（均为 8341 字节）——AWS ELB 将 Host 规范化为 
target.example:80
，丢弃了 
@evil
部分。因此并非绕过。

Statistical-Sample Rule (for timing-based claims)

统计样本规则（用于基于时间的结论）

Single outliers are NOT signal. Network jitter routinely produces 2× outliers.
Rules for any user-enum / blind-SQLi / blind-NoSQLi / timing-side-channel claim:
  • Minimum sample size: n ≥ 10 INTERLEAVED trials per group (control + test, randomised order, not back-to-back).
  • Compute mean, median, σ for each group.
  • A signal requires the suspect group's mean to be ≥ 2σ above the control group's mean.
  • A single 2× outlier in n=1 testing is jitter, not signal.
Lesson from an authorized engagement: Single-shot probe showed 
Administrator
taking 1527 ms vs ~700 ms control on Authentication.asmx Login — looked like clear user-enum signal. Reproduction with n=80 interleaved trials across 8 groups collapsed every group to mean=685-716 ms, σ=25-74 ms. The 1527 ms was network jitter. Finding retracted.
单个离群值不是信号。网络抖动经常会产生 2 倍的离群值。
任何 user-enum / blind-SQLi / blind-NoSQLi / timing-side-channel 结论均遵循以下规则：
  • 最小样本量：每组 n ≥ 10 次交错试验（控制组 + 测试组，随机顺序，不得背靠背执行）
  • 计算每组的均值、中位数和 σ
  • 只有当可疑组的均值比控制组均值高出至少 2σ时，才构成信号
  • 在 n=1 时出现单个 2 倍离群值属于抖动，不是信号
来自一次已授权项目的经验： 单次探测显示 
Administrator
登录耗时 1527 ms，而控制组约为 700 ms，看起来是明显的 user-enum 信号。但在 8 个组中交错执行 n=80 次复测后，各组均值均收敛至 685～716 ms，σ 为 25～74 ms。1527 ms 只是网络抖动，finding 已被撤回。

Shell-Loop Ban (>5 iterations)

禁止使用 Shell Loop（超过 5 次迭代）

For any iteration that runs more than 5 times, use Python (with try/except per iteration), not shell for-loops.
Why: zsh array expansion fails silently on edge cases. A loop like 
for x in "${arr[@]}"
can produce zero iterations with no error if the array wasn't populated by the previous command. The user sees output that looks complete but actually skipped the test entirely.
Rules:
  • Loops of ≤5 hardcoded items in shell: OK.
  • Anything that iterates a list, file, or computed range: Python.
  • Always count results. If you expected 100 probes and got <50 lines of output, your loop ate something.
Lesson from an authorized engagement: A zsh array-iteration verb-tampering test silently produced no curl invocations across 20+ iterations (zsh ate the array). Output looked like "HIT [GET] /_api/web → " repeated for every probe but the actual response was missing. ~50 probes worth of testing lost. Switching the test to Python with explicit per-iteration logging surfaced the real results.
任何执行次数超过 5 次的迭代，都必须使用 Python（每次迭代使用 try/except），不能使用 shell for-loop。
原因： zsh 数组展开在边缘情况下可能静默失败。类似 
for x in "${arr[@]}"
的循环，如果前一条命令未正确填充数组，可能执行零次却不报错。用户看到的输出看似完整，实际上可能完全跳过了测试。
规则：
  • 不超过 5 个硬编码项目的 shell loop：允许。
  • 任何迭代列表、文件或计算范围的操作：使用 Python。
  • 始终统计结果。如果预期执行 100 次探测，却只得到少于 50 行输出，说明 loop 吞掉了部分测试。
来自一次已授权项目的经验： 一次 zsh 数组迭代的 verb 篡改测试在 20 多次迭代中未产生任何 curl 调用（zsh 吞掉了数组）。输出看似反复显示“HIT [GET] /_api/web →”，但实际响应已经缺失，约 50 次探测白做了。改用带有逐次显式日志的 Python 后，真实结果才显现出来。

Related Skills & Chains

相关 Skills 与 Chains

  • hunt-dispatch
     — When PART 0 mode is confirmed (redteam / wapt + blackbox|greybox). Workflow primitive: after the engagement-type answer is locked, hand off to 
    hunt-dispatch
    to fingerprint the target and load the matching platform + hunt-* skill set; this skill stops being the active context once dispatch prints its taxonomy.
  • bug-bounty
     — When the user asks a generic "what should I do" or starts a new target. Workflow primitive: 
    bug-bounty
    is the orchestrator that names which 
    hunt-*
    skills to load by topic; this skill (
    bb-methodology
    ) provides the 5-phase workflow that orchestrator runs against.
  • triage-validation
     — When a finding completes Phase 4 and is about to be written up. Workflow primitive: Phase 5 explicitly calls 
    /validate
    (the 7-Question Gate); only findings that pass all 7 questions get handed off to 
    report-writing
    .
  • offensive-osint
     + 
    web2-recon
     — When Phase 1 (Recon) is active. Workflow primitive: Phase 1's "Wide approach" delegates to 
    offensive-osint
    for asset arsenal and 
    web2-recon
    for the live-host + URL pipeline.
  • hunt-dispatch
    ——当第 0 部分的模式已确认时（redteam / wapt + blackbox|greybox）使用。工作流原语： engagement type 锁定后，将任务移交给 
    hunt-dispatch
    ，由其识别目标并加载匹配的 platform + hunt-* skill 集合；当 dispatch 打印其分类体系后，本 skill 不再作为当前上下文。
  • bug-bounty
    ——当用户泛泛询问“下一步该做什么”或开始新目标时使用。工作流原语：
    bug-bounty
    是按主题决定加载哪些 
    hunt-*
    skill 的编排器；本 skill（
    bb-methodology
    ）提供该编排器运行所依赖的 5 阶段工作流。
  • triage-validation
    ——当 finding 完成 Phase 4、即将撰写报告时使用。工作流原语：Phase 5 明确调用 
    /validate
    （7-Question Gate）；只有通过全部 7 个问题的 finding 才会移交给 
    report-writing
    。
  • offensive-osint
     + 
    web2-recon
    ——当 Phase 1（Recon）处于活动状态时使用。工作流原语：Phase 1 的“广度方法”会将资产武器库任务委派给 
    offensive-osint
    ，将存活主机和 URL 管线任务委派给 
    web2-recon
    。

Operator Notes (Claude-BugHunter)

操作人员说明（Claude-BugHunter）

Engagement-derived additions to the vendored foundation. Wisdom from real authorized engagements + Phase 2 verification across this repo's 31+ skill-area live tests. The upstream methodology covers the WHAT; this layer covers the WHEN-IT-ACTUALLY-WORKS and the FAILURE-MODES.
基于真实已授权项目经验，以及本仓库 31+ 个 skill 领域的 Phase 2 验证，补充到内置基础方法论中的内容。上游方法论讲解了 WHAT；这一层讲解的是 WHEN-IT-ACTUALLY-WORKS 以及 FAILURE-MODES。

What the methodology doesn't tell you

方法论没有告诉你的内容

The vendored 5-phase workflow is a checklist; real engagements are improvisation. Sometimes you skip phases entirely — a client hands you a single URL and a JWT, recon was already done by their internal team, and Phase 1 collapses to a 10-minute fingerprint. Sometimes you spend 80% of the engagement in Phase 1 because the scope is a 200-asset financial-services parent org and asset discovery IS the work. The methodology is a map of terrain that exists in every engagement, not a sequence you traverse uniformly.
内置的 5 阶段工作流是一份检查清单；真实项目需要临场应变。有时你会完全跳过某些阶段——客户只给你一个 URL 和一个 JWT，内部团队已完成 recon，此时 Phase 1 会缩减为 10 分钟的目标指纹识别。有时你会在 Phase 1 花费整个项目的 80%，因为范围是一家拥有 200 项资产的金融服务母公司，而资产发现本身就是工作。该方法论是一张各地形都存在的地图，而不是一条需要统一走过的顺序路径。

Mode-confirmation, in practice

实践中的模式确认

PART 0 (the bug-bounty vs WAPT vs red-team gate at the top of this file) is a hard rule, but the answer isn't always handed to you. Read the scope language:
  • "in-scope assets" + "out-of-scope assets" + "safe harbor" → bug-bounty discipline. Validation-heavy, OOB-required, no exfil.
  • "kill chain" + "objectives" + "flag capture" + "adversary emulation" → red-team. Stealth, persistence, lateral movement valid.
  • "compliance" + "PCI" + "HIPAA" + "executive report" + "remediation timeline" → WAPT. Coverage-driven, deliverable-focused, all findings count regardless of exploitability.
When the language is mixed (common — clients often write WAPT-shaped SOWs and call them red-team engagements), default to bug-bounty discipline until proven otherwise. It's the most validation-strict mode; you can always relax later if the client confirms red-team. The reverse — assuming red-team latitude on what turns out to be a WAPT — gets findings retracted at delivery.
第 0 部分（文件顶部的 bug-bounty vs WAPT vs red-team 关卡）是硬性规则，但答案并不总会直接提供。请阅读范围措辞：
  • “in-scope assets” + “out-of-scope assets” + “safe harbor” -> bug-bounty 纪律。重视验证、要求 OOB、不得进行数据外泄。
  • “kill chain” + “objectives” + “flag capture” + “adversary emulation” -> red-team。隐蔽性、持久化和横向移动均有效。
  • “compliance” + “PCI” + “HIPAA” + “executive report” + “remediation timeline” -> WAPT。以覆盖度和交付物为导向，无论是否可利用，所有 findings 都计入结果。
当措辞混合时很常见——客户经常使用类似 WAPT 的 SOW，却将其称为 red-team 项目。在得到相反证明之前，默认采用 bug-bounty 纪律；它的验证要求最严格，客户确认是 red-team 后再放宽限制。反过来，假设 WAPT 是 red-team 并采用其宽松范围，会导致 findings 在交付时被撤回。

Phase priority shifts by target type

不同目标类型的阶段优先级变化

The 5 phases are not equal-weight. Engagement type dictates the time allocation:
EngagementReconHuntValidate+Report
SaaS bug-bounty (defined scope)10%70%20%
External red-team (wide scope)40%30%30%
WAPT (asset list provided)0%60%40%
Enterprise on-prem (single product)5%50%45%
If you find yourself spending 50% of a SaaS bug-bounty engagement in recon, you're procrastinating on the hunt. If you're spending 10% of an external red-team engagement on recon, you've already lost — the attack surface map IS the deliverable on those.
5 个阶段的权重并不相同。Engagement type 决定时间分配：
EngagementReconHuntValidate+Report
SaaS bug-bounty（范围明确）10%70%20%
External red-team（范围广）40%30%30%
WAPT（已提供资产列表）0%60%40%
Enterprise on-prem（单一产品）5%50%45%
如果你在 SaaS bug-bounty 项目中把 50% 时间花在 recon 上，就是在用侦察逃避狩猎。如果你在 external red-team 项目中只花 10% 时间进行 recon，就已经失败了——在这些项目中，攻击面地图本身就是交付物。

When to break the methodology

何时应打破方法论

If you find a Critical in the first 30 minutes of recon, stop reconning, validate the Critical fully, report it, then return to recon. The methodology says "complete the phase before moving on" — the value-per-hour curve disagrees. A confirmed Critical paying out within 24h of engagement start is worth more than a comprehensive asset list you'll never get to chain.
The same applies in reverse: if you've been hunting a candidate for 4+ hours and it won't reproduce on a second account, the candidate is dead. Don't sink another 4 hours into making a dead candidate reproduce. Drop it, document the retraction in your notes, move on.
如果你在 recon 的前 30 分钟发现了一个 Critical，停止继续侦察，完整验证该 Critical，提交报告，然后返回 recon。 方法论要求“完成当前阶段后再进入下一阶段”，但每小时价值曲线并不支持这种做法。一个在项目开始后 24 小时内即可确认并获得报酬的 Critical，远比一份永远无法用于串联的完整资产列表更有价值。
反过来也成立：如果你已经花 4 个多小时测试某个候选项，但它始终无法在第二个账户上复现，那么该候选项已经死亡。不要再投入 4 个小时强行让一个无效候选项复现。放弃它，在笔记中记录撤回原因，然后继续。

The discipline rules are non-negotiable

纪律规则不可协商

The discipline rules in this file — OOB Gate, Marker Discipline, Body-Diff Rule, Statistical-Sample Rule, Server-Policy-vs-State, Pre-Severity Gate, Shell-Loop Ban — are not methodology. They are quality gates. Methodology is the order of operations; these are the validation guarantees at each step.
Verified across Phase 2D's hardened-lab campaign: 8/8 discipline rules fired correctly against fake-bug-shaped behavior (URL echo dressed as XSS, word collision dressed as reflection, status-code-only "bypasses" with byte-identical bodies, 200-OK leak-claims with no actual leak data). Validation rates fall sharply when these rules get skipped. The friction is the feature — if a rule feels obstructive, that's it doing its job. The findings it kills are the half that would have come back N/A anyway.
  • evidence-hygiene
     — When Phase 5 is collecting PoC screenshots / HARs. Workflow primitive: before any cookie / PII appears in a screenshot, hand off to 
    evidence-hygiene
    for the redaction protocol.
本文件中的纪律规则——OOB Gate、Marker Discipline、Body-Diff Rule、Statistical-Sample Rule、Server-Policy-vs-State、Pre-Severity Gate、Shell-Loop Ban——不是方法论，而是质量关卡。方法论决定操作顺序；这些规则为每个步骤提供验证保证。
在 Phase 2D 的强化实验室活动中，这些规则已针对 8/8 种伪装成真实 bug 的行为成功触发，包括把 URL 回显伪装成 XSS、把词语碰撞伪装成反射、仅凭状态码差异声称“绕过”但正文逐字节相同，以及声称 200 OK 存在泄漏但实际没有任何泄漏数据。跳过这些规则后，验证通过率会急剧下降。这种阻力正是功能本身；如果某条规则让你觉得妨碍工作，说明它正在发挥作用。它淘汰的 findings 有一半本来就会得到 N/A。
  • evidence-hygiene
    ——当 Phase 5 正在收集 PoC 截图或 HAR 时使用。工作流原语：任何 cookie 或 PII 出现在截图中之前，先移交给 
    evidence-hygiene
    执行脱敏协议。