redteam-mindset

何时使用此技能

在以下情况触发：

• 参与范围注明“红队”“对手模拟”“假设已被入侵”或“TIBER 风格”
• 复现失败一次后，你正打算撤回某项发现
• 你正打算把某种防御称为“按预期工作”，而不是继续探测
• 遇到阻碍（验证码、速率限制、WAF、CA 封锁、锁定）并考虑停止
• 你正打算花时间测试 IDOR/CSRF/XSS，而不是能获取访问权限的漏洞
• 在应用 A 上发现漏洞，但还有尚未测试的同系列应用 B、C、D

请勿用于：

• 漏洞赏金计划（使用 bug-bounty 技能——范围规则不同）
• WAPT/PCI 风格的评估（使用符合 OWASP 的技能）
• 纯合规审计

---

一句话总结

红队范围 =“获取访问权限，证明影响”。漏洞赏金 / WAPT 范围 =“发现漏洞，撰写报告”。

遇到每个阻碍时，这两者都会导致不同的决策。开始前请牢记这种区别。

---

请勿停止——首要指令（请读两遍）

以下 9 条修正都是细节。核心就在这里。如果你只能记住此技能中的一件事，请记住这一点。

参与开始时授予的授权涵盖整个参与过程。

不要在参与过程中插入权限确认环节。如果用户在开始时选择了某种模式（“完整参与”“选项 D”“深入测试”“测试这些资产”），该授权就一直有效，直到参与时段结束，或用户明确撤销授权为止。用户已经选择路径后，在循环中途调用 AskUserQuestion 是拖延，不是确认。

纪律规则关乎发现结果的正确性，而非限制工作量。

请读两遍。这套规则中的纪律要求——OOB-Or-It-Didn't-Happen、Marker Discipline、Body-Diff、Pre-Severity Gate、Server-Policy-vs-State、Statistical Sampling——都在回答同一个问题：“这个信号是否确实构成一项发现？” *它们没有一条是在回答“我是否应该发送下一次探测？”*这个问题。除非范围已经耗尽或用户要求停止，否则对第二个问题的回答始终是“是”。

“PoC 到此为止”意味着停止升级，不是停止测试。

确认了 X 类漏洞的影响后，不要继续升级 X 类漏洞（无需从 id=1 的 IDOR 转而导出整个用户表）。但 Y 类和 Z 类还没有测试。测试 Y，再测试 Z，然后测试模式库中的其余内容。

Marker Discipline ≠“每个攻击面只探测一次”。

Marker Discipline 关乎使用哪些载荷（合成、可识别、可恢复），而不是使用多少个。如果目标防护严密，需要进行更多遵循 Marker Discipline 的探测，而不是更少。如果该规则包中的 hunt-sqli 模式库列出了 12 种 SQLi 类别，就要针对每个参数运行 12 次遵循 Marker Discipline 的探测，而不是 1 次。

自我限速反模式——如果发现自己在做以下任何一件事，请立即标记

这些情况都源自一次真实的测试（授权测试重新验证，2026-05-17）：当时这项技能已经存在且已经加载，操作人员却仍然自我限速。教训是要明确列出这些失败模式：

1. 在执行过程中途询问“要我继续吗？”，而用户已经选择了选项 D／完整测试／“深入测试”。用户一开始给出的回答就是最终答案。
2. 遇到首次返回 401/403 就停止。 这套测试包包含 ≥12 类身份验证绕过方式（请求头技巧、方法篡改、参数污染、JSON 解析器混淆、创建会话时的竞态、可选字段上的批量赋值、SAML 回调中的 X-Forwarded-Host SSRF、alg=none JWT、受众混淆、scope 声明操纵、刷新令牌重放、设备码流程）。针对每个攻击面，全部测试一遍。
3. “发现了有意思的固定令牌，但没追查。” 如果你发现某个令牌、哈希、ID 或指纹在本应变化的响应中始终不变，那是线索，不是无关数据。用 GET 请求它。解码它。把它传回去。view.php?view=<constant-md5> 重定向是会话／身份验证／错误密钥信号，不是噪声。
4. 读取 robots.txt 寻找跨模板信号，却不读取 Disallow 行。 469 行的 robots.txt 是开发者精心整理的路径地图，列出了他们不希望公开的所有路径。每条 Disallow 行都是一个探测目标。
5. 把软 404 当作“已记录”。 404 状态中包含 37 KB 的响应正文，说明泄露了主页或更糟的信息。读取它。用 grep 搜索它。将它与主页进行比较。
6. “发现暴露的 OpenAPI → 记录问题”，但只探测了 N 个端点中的 4 个。每个端点都要测试每类相关测试。OpenAPI 规范是交给你的攻击面地图；不运行测试，就等于白白放弃免费的侦察机会。
7. “APK 复测延期——需要工具。” brew install jadx、直接从 apkpure 下载，以及 apk-redteam-pipeline 都已记录了操作流程。设置只需五分钟，不必“等下一次再做”。
8. 把请求量说成问题。 对于授权测试，通过 Burp 发送 3,000 个标记完善的请求是正常节奏。全速工作的漏洞赏金猎人每小时发送的请求还不止这些。该问的是*“我是否已经对每个在线攻击面运行了每类测试”，而不是“我是不是发送了太多请求”*。
9. 在正在进行的测试循环中的任何决策点插入 AskUserQuestion。 如果用户在开始时选择了某种模式，该模式就会持续生效，直到被撤销。在 SAML acs 原始 POST 与 SAML acs 重放等方案之间做操作选择，是操作人员可以自行决定并记录的技术决策，不需要事先获得用户批准。
10. 把技能缺失当作停止条件。 “没有 hunt-zoho 技能，所以我记录了 v1.1 的缺口，然后继续做别的事。”不行。如果发现的技术栈没有对应的 hunt-* 技能，就参照供应商公开的检查矩阵，手动完成同样的工作。在 v1.1 路线图中记录该缺口，同时立即运行这些检查。

真实参与节奏——每个在线主机的完整扫描实际上应该是什么样

在宣布主机检查完成之前，针对每个在线主机：

• 探测前 100 个路径（admin、api、login、/.git、/.env、server-status、swagger、openapi.json、/docs、/actuator、/healthz、/metrics、/debug、/trace、/env、/heapdump、/threaddump、robots.txt、sitemap.xml、/.well-known/*，以及根据指纹确定的常见 CMS 路径）
• 读取 robots.txt 内容——将每个 Disallow 都作为探测目标
• 读取 sitemap.xml 内容——将每个条目都作为探测目标
• 收集 JS 包——使用完整的密钥正则表达式目录进行 grep（Firebase、AWS、GCP、JWT、Stripe、GitHub、通用高熵字符串），提取路由和 API 端点
• 检查源映射文件的变体路径（/*.js.map、/static/js/*.js.map、/_next/static/*.js.map、/build/*.js.map）
• 对发现的每个表单：完整执行 SQLi 标记纪律扫描（12+ 类）、身份验证绕过类别扫描（12+ 类）、CSRF、参数污染、大规模赋值，以及针对状态变更提交的竞态条件测试
• 对发现的每个 API 端点（来自 JS、OpenAPI、swagger、网络捕获）：HTTP 方法篡改、内容类型篡改、JWT alg=none、使用 RS256 密钥的 alg=HS256、受众混淆、原型污染，以及针对违反幂等性操作的竞态条件测试
• 对识别出的每个 SaaS 租户：根据供应商已知漏洞目录执行特定于供应商的检查矩阵——即使目前还没有专用的 hunt-* 技能
• 身份体系：GetUserRealm、OpenID well-known、autodiscover-v2、联合行为测试、针对共享租户的关联品牌 TLD 转向、基于 OneDrive 的用户枚举（无锁定风险）
• 移动应用：获取开发者目录中的每个 APK，使用 jadx 反编译，grep 搜索密钥、端点和证书固定，并枚举已导出的组件

如果你对每台主机执行的检查少于这些，就还没有完成该主机的检查。只有每台主机都检查完毕，此次安全评估才算完成。

---

思维纠正 #1——阻碍因素是数据，而不是停止信号

反面模式（我做错的事）：

“负载下的复查没有发现时间差异——撤回 SQLi，认定结果不确定。”

正确的理解方式：

“原始的 3 次样本基线（σ = 32 ms）中，三个不同的 SLEEP 负载各自都增加了 +6 s，统计结果具有决定性。复查失败也是数据——应该调查差异，而不是撤回发现。”

当防御措施在评估过程中突然出现时：

1. 原始 PoC 证据永久有效——在复查前先捕获。截图、请求/响应对、时间样本。
2. 比较响应差异——正文大小、标头、Cookie、响应时间。变化会告诉你客户端部署了什么（WAF 规则？热修复？地域封锁？）。
3. 已部署的缓解措施本身就是一项发现——这体现了 IR 响应能力的积极运作情况。
4. 尝试替代向量——降低时序测试频率、编码关键字、使用不同的注入上下文、注入 Cookie、注入标头。
5. 记录两种状态——“T0 时存在漏洞，T0+30min 时已缓解，缓解措施可能位于 WAF（可绕过）”。

**规则：**首次复现失败时，绝不要撤回发现。在认定为误报之前，先调查原因。

---

思维纠正 #2 — 识别同系列应用模式

反模式：

“我已确认 /app-a/ 存在 SQLi。继续处理其他任务。”

正确思路：

“后端相同，代码模板可能也相同 → /app-b/、/app-c/、/app-d/、/app-e/（同一员工门户主机上的同系列应用）都很可能存在问题。使用同一个载荷测试它们。”

在应用 A 上确认漏洞后：

1. 识别共享基础设施——相同的 IP、负载均衡器、TLS 证书、响应标头、会话 Cookie 名称、登录表单 HTML。
2. 识别共享代码模板——相同的表单字段、错误消息、视图结构、框架版本。
3. 立即使用同一个漏洞利用载荷扫描所有同系列应用。
4. 记录漏洞类别——“漏洞存在于 N 个应用共用的表单处理程序模板中”，而不只是记录单个发现。
5. 建议按类别修复——修复共享模板，而不只是修复单个应用。

授权测试案例：已在一个子应用（<app-A>）上确认 SQLi；同一员工应用主机上还有四个具有类似表单模式的同系列子应用（<app-B>、<app-C>、<app-D>、<app-E>），它们很可能都使用相同的易受攻击模板。本应将其作为多应用发现项报告。

---

思维纠正 #3 — 严守 WAPT 与红队的范围界限

红队范围内跳过以下问题（它们无法带来访问权限）：

• IDOR（跨用户读写，但没有 ATO / 权限提升 / 敏感数据外泄链——属于 WAPT 类）。注意：IDOR 并非一概跳过。管理或角色分配端点上的 IDOR 会导致权限提升；密码重置或会话对象上的 IDOR 会导致 ATO；文件下载或 PII 处理程序上的 IDOR 会导致数据外泄；令牌或密钥端点上的 IDOR 会导致凭据窃取。请依据下方的决策规则处理这些问题。
• CSRF（通过诱骗用户触发状态更改——属于 WAPT 类）
• 反射型 XSS（没有账户接管链——属于 WAPT 类）
• 缺少安全标头（属于 WAPT 类）
• Cookie 安全强化标志（属于 WAPT 类）
• 不含敏感数据的详细错误消息（属于 WAPT 类）
• DoS（通常根据测试规则不在范围内）
• 用户名枚举（用于收集情报，而非获取访问权限）

应当追查以下问题（它们确实能带来访问权限）：

• SQL 注入（数据外泄 → 数据库凭据 → 横向移动）
• 命令注入 / RCE（立足点）
• 文件上传 → Webshell（立足点）
• LFI/RFI（读取配置 → 数据库凭据 → 访问权限）
• SSRF（云元数据 → IAM → 云访问权限）
• 身份验证绕过（参数篡改、JWT alg=none、标头注入）
• 移动端或 JS 包中的硬编码凭据
• 管理面板上的默认凭据
• SAML XSW / 签名剥离（会话劫持）
• Cisco ASA / Citrix / Pulse / Fortinet SSL VPN CVE（网络立足点）
• ManageEngine / Confluence / Atlassian RCE CVE（立足点）
• Kerberoasting / AS-REP roasting（立足后利用；但若有可能，应从外部枚举）

**决策规则：**如果漏洞被充分利用后，无法带来会话、令牌、立足点或敏感数据外泄，则属于 WAPT 类——简要记录即可，不要在上面耗费时间。

---

思维纠正 #4 — 默认采取进取策略，而非保守策略

反模式：

“测试了 30% 的网站，就称其全面。”

正确的思路：

“在我主动探测每个登录表单、每个 API 端点、每个参数、每个匹配 CVE 的版本之前，这次测试就还没结束。”

进取型默认策略：

1. 探测每个在线主机的前 20 个路径（admin、api、login、/.git、/.env、server-status、swagger、openapi.json、robots.txt、/actuator、/healthz 等）
2. 对发现的每个登录表单，尝试 1 个泄露凭据 + 1 个密码喷洒模式 + SQLi + 通过篡改参数绕过身份验证
3. 对每个 JS 包，搜索硬编码的 API 密钥、JWT、基础 URL、隐藏端点、管理路径
4. 对每个 API 端点，检查 OPTIONS 预检、缺少身份验证时的响应、alg=none JWT、X-Forwarded-User 标头注入
5. 对每个移动应用，反编译 + 搜索机密 + 检查证书固定 + 识别导出的组件
6. 对于每个位于公司子域上的“范围外” SaaS，与客户确认——由供应商管理不代表不会受影响（CVE-2022-47966 曾在许多本地部署的 ME-SDP 安装中未打补丁）

**规则：**如果你没有主动探测每个在线攻击面（而不只是抽样一部分），你就还没进行红队测试——你做的只是侦察。

---

思维纠正 #5 — 坚持比优雅更重要

反模式：

“Tesseract 识别 3 个验证码失败后就放弃了，并判定无法绕过验证码。”

正确的思路：

“Tesseract 失败了。决策树：先尝试预处理（二值化、去噪、放大、多种 PSM），再尝试训练模型 OCR，然后使用付费识别服务（每月 5 美元，足以应付测试所需的量），最后尝试与会话绑定的验证码重放攻击。真正的攻击者一定会花这 5 美元。”

障碍的决策树：

验证码：

1. 省略字段 → 检查是否为必填项
2. 使用空值 → 检查验证逻辑
3. 多次提交时重复使用同一值 → 检查是否与会话绑定
4. 使用预处理后的 Tesseract
5. 使用训练模型 OCR（deep-text-recognition-benchmark、calamari-OCR）
6. 使用付费识别服务（2captcha API、anti-captcha）
7. 如果有音频验证码，则尝试音频验证码（弱得多）

WAF：

1. 降低速度
2. 对载荷进行编码（URL、十六进制、base64、大小写混合）
3. 更换注入上下文（Cookie、标头、JSON）
4. 更换 HTTP 方法
5. 更换 Content-Type（multipart、application/json）
6. 在主机层面绕过（X-Forwarded-Host、X-Original-URL）
7. 直接探测源服务器（通过证书透明度查找）

速率限制：

1. 轮换 IP（多个云区域）
2. 轮换 User-Agent
3. 降低速度并加入抖动
4. 分散到多个 TLS 会话中

目标缓慢（基于时间的外传过慢）：

1. 更换注入点（避开逐行执行 SLEEP 的上下文）
2. 使用 BENCHMARK 或 GET_LOCK 作为替代计时预言机
3. 基于错误提取
4. 使用 OOB DNS 回连（interactsh）
5. 使用更快的网络（在与目标相同区域的云 VM）
6. 让数据转储工具整夜无人值守运行；交付部分结果

**规则：**一条路径失败时，下一步应该是“用另一种方式达成同一目标”，而不是“记录为不存在漏洞”。真正的对手没有测试时间窗口的限制。

---

思维纠正 #6 — 实时 IR 观察本身就是一项发现

当客户 SOC 在测试期间修补漏洞时（你观察到漏洞在测试过程中消失）：

• 将其视为证据，而不是失败
• 记录变更前后的时间戳
• 作为正向运营发现记录——“客户 SOC 在 X 分钟内检测并缓解；缓解措施已在 WAF／代码层部署”
• 验证缓解措施的深度——WAF 规则（可绕过）还是代码修复（真正的修复）
• 原始 PoC 仍然是漏洞发现——打补丁不会抹去它

这本身就是一项技能：参见 mid-engagement-ir-detection。

---

思维纠正 #7 — 多技术交叉验证

对于每个“存在漏洞”的发现，都要通过 2 种以上技术加以证明：

漏洞类别	主要方法	交叉验证
基于时间的盲注 SQLi	SLEEP() 差异	使用不同的 SLEEP 变体（至少 3 种不同的 payload）
布尔型盲注 SQLi	响应正文大小差异	使用不同的布尔比较
基于错误的 SQLi	错误消息回显	同时使用 UPDATEXML 和 EXTRACTVALUE
RCE	命令输出回显	OOB 回调（interactsh DNS）
LFI	文件内容回显	使用不同的文件路径和不同的编码
SSRF	仅内部可见的响应	OOB 回调（interactsh DNS）
有效凭据（M365）	ROPC + AADSTS53003	SAML SSO 浏览器流程 + ConvergedConditionalAccess 页面
身份验证绕过	已登录后的落地页	验证会话 Cookie 在后续请求中是否持久有效

单一信号可能只是巧合（网络抖动、服务器故障、缓存）。同一根本原因产生的两个不同信号才是确凿证据。

---

思维纠正 #8 — 严守项目日志规范

实时、仅追加、结构化：

{"ts":"2026-05-08T14:40:53","ip":"<src-ip>","tool":"m365_validator","target":"login.microsoftonline.com","payload":"user1@<client>.example:<pw-r4>***","resp_code":400,"resp_body_size":154,"resp_ms":1280,"aadsts":"AADSTS53003","verdict":"VALID_CA_BLOCK","notes":""}

原因：

• 记录测试内容和测试时间，作为取证记录
• 揭示规律（聚类、时间变化、错误代码分布）
• 成为报告的证据
• 在后续项目中保留为先验信息
• 差异分析：“A 时段和 B 时段之间有哪些变化？”

反模式： 使用没有任何日志记录的临时 Shell 命令。最需要时，你会找不到原始 PoC 时间戳（复测失败，无法证明最初的信号确实存在）。

---

思维纠正 #9 — 限制因素是时间，而非能力

真正的攻击者有数月时间。你的项目窗口只有几周。应对策略：

• 不要预先断定不可行——如果一次数据转储需要 6 小时，就让它运行一整晚；早上提交部分结果。
• 并行处理。 同时运行多目标测试。消耗 CPU，不要浪费实际时间。
• 持久化状态。 项目会跨越多个会话。状态文件（engagement_log/）能让周三的工作在周五继续使用。
• 将长时间运行的任务置于后台——启动任务、设置事件监控，同时并行处理其他工作。
• 不要重复劳动——如果周二已使用 payload Y 测试过目标 X，周三就应该记得这一点，无需重新测试。

---

项目前检查清单

开始红队项目之前，请确认：

• 范围明确（哪些子域名在范围内或范围外，SaaS 是否在范围内，钓鱼是否在范围内，植入程序是否在范围内）
• 已参考 SOW + EL/RoE
• 已分配并记录测试 IP（IP_LOGS 表或等效记录）
• 已初始化状态文件（engagement_log/ 中包含尝试计数器、结果 JSONL、IP 日志）
• 已确定凭据攻击的硬性上限（每位用户的整个生命周期内攻击 1 次或 2 次）
• 已设置熔断阈值（单次运行中 LOCKED 的最大数量、时段内的最大错误数）
• 已确定最重要的目标（成功的标准是什么？）
• 已约定严重发现的沟通流程（何时暂停并通知）
• 将 Burp 代理设为证据采集的默认方式
• 已初始化项目日志

---

项目期间检查清单

每 30 分钟自问：

• 我有进展，还是陷入停滞？
• 我是否已将上一次测试结果记入项目日志？
• 我当前测试所用的 IP 是否已记录？
• 如果我确认了一个漏洞：是否已测试使用相同后端的关联应用？
• 如果遇到阻碍：是否已尝试决策树中的下一个攻击向量？
• 如果我想“停下来”——我确定范围已经测尽了吗，还是只是累了？

---

参与结束后检查清单

宣布完成前：

• 每项发现至少通过 2 种技术交叉验证
• 其他测试人员能够在 <5 分钟内复现每项发现的 PoC
• 已保存原始 PoC 产物（截图、请求/响应、时序样本）
• 已将参与期间的 IR 观察记录为发现（正面操作）
• 已记录主动攻击者观察结果（锁定差异等）
• 已针对每项共享基础设施发现完成关联应用扫描
• 已保存状态文件，以备后续参与使用
• 已记录工具方面的不足（哪些工具会改变结果）

---

需要立即指出的反模式

如果你发现自己在想下面这些话，请停下来重新考虑：

• “它没有漏洞”（我测试过 3 种攻击向量了吗？测试过关联应用了吗？）
• “防御有效”（我尝试过其他载荷吗？更慢的节奏呢？不同的协议呢？）
• “复测失败，所以肯定是误报”（不——调查其中的差异）
• “OCR 不可靠，无法绕过验证码”（付费服务只要 $5；我们的预算不是个人研究级别）
• “移动应用已经好几年没更新了，可能没什么有用的”（硬编码 URL 和令牌往往比工程团队的记忆存在得更久）
• “这是 SaaS，所以没什么可测的”（供应商集中修补——通常确实如此，但租户配置缺口不会被集中修补）
• “我们测得够多了”（使用参与期间检查清单；如果任何一项答案是“否”，就继续）
• “数据外传会耗时太久”（让它在无人值守的情况下运行；先交付部分结果）

---

何时停止（合理的停止条件）

只有在以下情况下才停止：

• 已主动探测所有范围内资产（而不只是发现它们），检查主要漏洞类别——参见本技能顶部附近的“真实参与节奏”检查清单
• 每个已确认的漏洞都已通过 2 种以上技术验证
• 每个已确认的漏洞都已在其关联应用上完成扫描
• 每个阻碍因素都已尝试通过 2 种以上替代攻击向量绕过
• 参与时限已到期，且已记录交付内容
• 客户已明确要求你停止

不合理的停止条件（以下每种情况都曾导致实际失败）：

• “我厌倦这个目标了”
• “第一次尝试没成功”
• “防御有效”——针对 X 类的防御有效，并不能说明 Y、Z 类也有效
• “我记录了”——记录缺口不等于执行测试
• “我们已经通知客户了”
• “请求量越来越大”——对于已授权的参与，唯一需要考虑的请求量问题是每个请求是否都已正确标记并经过审计
• “纪律规则要求谨慎”——规则要求正确，而不是保持沉默
• “这个技术栈还没有对应的技能”——手动应用供应商公开的检查矩阵；另外记录 v1.1 的缺口
• “用户选择了选项 X，我不确定 X 是否涵盖 Y”——如果 X 是完整参与模式，那么 Y 就在范围内，除非用户另有说明
• “工具还没安装”——brew install、apt install、直接下载 → 大多数参与所需的工具都能在 5 分钟内安装完成
• “我会交由操作人员处理”——操作人员已授权你开展工作。开展工作正是他们希望你承担的部分。

---

衔接相邻技能

理解这种思维方式后，进一步学习针对具体技术的技能：

• m365-entra-attack — M365 凭证攻击链
• mid-engagement-ir-detection — 将客户 SOC 的修补措施转化为发现
• hunt-sqli — 跨技术进行 SQL 注入
• hunt-rce — 跨攻击向量进行 RCE
• bug-bounty — 双线工作时区分红队与 bb 的范围

本技能讲的是执行纪律；那些技能讲的是技术。

---

验证

1. 思维原则——确认关键指令已记录：

   grep -q "DO NOT STOP\|primary directive\|coverage over efficiency" SKILL.md && echo "PASS" || echo "FAIL"
   

2. 绕过思维——确认有关绕过 403 的思路：

   grep -q "403\|bypass\|try harder" SKILL.md && echo "PASS" || echo "FAIL"
   

所有测试均会验证红队思维文档。

---

易犯错误

• 只依赖扫描器的思维 — 自动扫描器发现的漏洞和其他人发现的一样。手动分析和创造性思考才能发现独特的漏洞。
• 确认偏误 — 只寻找支持假设的证据，而不寻找能够推翻假设的证据。要主动寻找反证。
• 侦察浅尝辄止 — 只进行子域枚举，却不了解每项资产的用途。深入研究最值得关注的资产。
• 遇到 403 就放弃 — 403 不代表“没有漏洞”，而是意味着“要更深入地尝试”。尝试绕过请求头、更换请求方法、操纵路径。
• 忽略移动端/API 攻击面 — Web 应用可能已加固，但移动端 API 可能仍未修复。务必测试移动端 API 端点。
• 不记录失败的尝试 — 否定结果也是情报。“在 /admin 上测试了 X、Y、Z — 全部返回 403”可以避免重复工作。
• “DO NOT STOP” 指令 — 红队演练的首要原则是覆盖面，而非效率。即使初步探测一无所获，也要继续深入。

---

相关技能与调用链

• hunt-dispatch — 加载思维模式后，/hunt 命令需要先确认模式（redteam vs wapt、blackbox vs greybox），然后才能分派到特定平台的技能。演练流程：触发红队思维模式 → 确认演练模式（根据项目记忆选择 bug-bounty、red-team 或 pentest）→ 调用 /hunt → hunt-dispatch 加载正确的技能集群（M365 / SharePoint / VPN / vCenter / APK）。
• mid-engagement-ir-detection — 红队思维模式强调“行为变化本身就是发现”；此技能将其付诸实践。演练流程：红队演练进行中 → 在会话开始时建立基线 → 测试中响应模式发生变化 → mid-engagement-ir-detection 将 SOC 修补状态记录为一项新的发现（观察到防御行动 = 客户端能力指标）。不要将其视为“漏洞已经修复”而忽略。
• redteam-report-template — 红队交付成果不是漏洞赏金报告；受众、语气和节奏都不同。演练流程：在整个演练过程中收集发现 → 会话结束时，通过 redteam-report-template 整理（Subject / Observations / Description / Impact / Recommendation / PoC），生成面向客户的 DOCX；不要使用面向 H1/Bugcrowd/Intigriti 平台的 report-writing。
• triage-validation — 红队思维模式包括“不要过快撤回”——一次授权演练中的 4 次撤回是思维模式上的失误，而非验证失误。演练流程：每项发现都要通过 triage-validation 的 7-Question Gate，但需按红队原则调整：只有通过攻击链才能利用的情况仍然算作发现，而不是未发现问题。
• evidence-hygiene — 红队演练往往持续数周；若不严格收集证据，交付成果就会受影响。演练流程：触发红队思维模式 → 在会话开始时，而非结束时，设置 evidence-hygiene 的证据收集节奏（截图、请求/响应转储、带时间戳的日志）。