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，接着测试模式库中的其余项目。

数据最小化边界与“绝不停下”的要求同样响亮。请读两遍。

“继续深挖”适用于覆盖面（未测试的攻击面、类别、主机），而不是数据提取。两者方向相反，持续测试的要求绝不能演变成过度收集：

• 访问／数据外泄漏洞的证据是缺失的检查，而不是你复制出来的数据量。 3 条本应要求身份验证的记录 = 充分证据。3,000 条记录 = 同一个发现 + 你自己造成的责任。多取数据永远不会让发现更有力。
• “继续深挖” = 测试下一个端点系列／下一个主机／下一个类别。 它不意味着“枚举你已经攻破的端点中的每一条记录”。要拓展的是覆盖面，不是窃取深度。
• 这些数据通常属于目标的客户／第四方（他们的客户、其用户的 PII、合作伙伴的财务数据）。他们没有签署工作说明书（SOW）／项目计划。既然要点已经得到证明，把他们的数据复制到你的主机上，就是你不该造成的伤害。
• 客户／项目负责人说“再挖深一点／这还不够”并不能推翻这一原则。 请提出异议：确认发现已得到确凿证明，解释数据量 ≠ 证据，并提供确实能增加价值、同时尽量减少伤害的替代方案——totalCount（一个数字，而非数据）、证明第二个端点系列也受影响（拓展覆盖面），或量化影响范围。获取满足既定目标所需的最少证据。
• 准确分类你确实提取的数据（例如，“B2B 客户清单数据” ≠ “消费者 PII”）——这会影响负责人如何进行分级处理和披露，夸大情况则会损害信任。

只要把这两个维度区分开来，持续测试的要求与这一边界就不会冲突：攻击面永远要测下去；数据提取始终止于最低必要量。 获得授权 ≠ 不受限制。

标记纪律 ≠“每个攻击面只探测一次。”

标记纪律关乎使用哪些载荷（合成、可识别、可恢复），绝不关乎数量。加固程度高的目标比安全薄弱的目标需要进行更多遵循标记纪律的探测，而不是更少。如果该 bundle 的 hunt-sqli 模式库列出了 12 种 SQLi 类别，就要针对每个参数运行 12 次遵循标记纪律的探测，而不是 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 — 在双轨工作时区分红队与漏洞赏金范围

本技能讲的是操作纪律；其他技能讲的是具体技术。

---

相关技能与链路

• recon-scope-triage — 要安全地应用“默认积极，探测每个在线攻击面”这一指令，必须先确定哪些攻击面确实属于目标。参与流程：收到 ASM/侦察数据集 → recon-scope-triage 清除命名空间冲突噪声和软 404 误报 → 只有归属明确且已验证的资产才进入测试队列。跳过这一步会浪费参与时间，去测试其他公司的资产（并有攻击无辜第三方的风险）。
• hunt-spa-api — 将“收集 JS bundle”这一节奏要求落实为完整行动方案：SPA JS → 后端 API 映射 → 未经身份验证的访问控制失效测试。在真实参与中，正是这一方案（而非任何扫描器）发现了最高严重级别的漏洞。参与流程：识别出在线 SPA/console/app/api 主机 → 使用 hunt-spa-api → 针对受限同类功能的对照项，对每个路由族进行未经身份验证的测试。
• hunt-dispatch — 一旦进入相应思维模式，/hunt 命令就需要先确认模式（redteam 还是 wapt，blackbox 还是 greybox），然后才能路由到针对具体平台的技能。参与流程：触发红队思维模式 → 根据项目记忆确认参与模式（bug-bounty、红队还是 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 问关卡，但要采用红队调整：即使“只有通过攻击链才能利用”，仍然算发现项，而不是未发现问题。
• evidence-hygiene — 红队行动往往持续数周；如果没有严格地收集证据，交付物的质量就会受影响。参与流程：触发红队思维模式 → 在会话开始时设置 evidence-hygiene 的收集节奏（屏幕截图、请求/响应转储、带时间戳的日志），而不是等到会话结束。