mid-engagement-ir-detection

用途

该技能用于在红队测试（red-team engagement）过程中，检测并记录目标安全状态在测试期间发生的变化。当目标存在活跃的 SOC 监控时，其安全状态并非静态，会针对测试流量实时改变。这些变化本身具有价值：既是关于 IR（事件响应）响应能力的正面运营发现，也是原始漏洞真实存在的确认证据，还可用于判断缓解措施的深度（WAF 规则部署还是代码修复）。

触发条件

在以下情况触发：

• 对具有活跃 SOC 监控的目标进行主动测试
• 已确认的漏洞在复查时不再复现
• 基线时序意外变化（慢 3 倍、突然报错、出现新响应头）
• 不同测试窗口之间响应大小发生变化
• 会话开始时不存在的 WAF cookie 或响应头出现
• 锁定/错误率在不同测试窗口之间变化（尤其是凭据攻击的 LOCKED 计数）
• 测试为“假设已失陷”或“白盒”模式，客户知晓测试正在进行

不适用于：漏洞赏金（客户不知情，无实时 IR）、纯侦察（无状态变化）、一次性漏洞扫描（无时间维度）。

核心洞察

在针对有能力的 SOC 的真实红队测试中，目标的安全状态会随测试流量而改变。这些状态变化本身是有价值的发现、确认证据和分类信号。反模式是：把复现失败当作原始信号为误报的证据。变更前捕获的原始 PoC 证据仍然是漏洞发现。

纪律：变更前捕获，变更后对比

测试前采集目标指纹（时间戳、源 IP、基线响应时间、基线响应大小、响应头集合、WAF cookie 列表、锁定计数），持久化到 engagement_log/fingerprint_pre.json。测试期间将每次测试结果以 JSONL 追加方式记录完整上下文。测试后或首次复查失败时，采集相同结构的 fingerprint_post 并计算 delta（基线时间变化、大小变化、新出现的响应头、新 WAF cookie、新增锁定数）。若任何 delta 显著，应调查而非撤回。

三类主要 IR 观察

观察一：测试中途部署 WAF 规则

症状：原始 payload 返回相同响应、响应体大小与基线一致、时序回归基线、响应中出现新 cookie 或响应头、特定关键词触发不同响应码（403、406、429）。

确认方法：使用 WAF 规避变体重试（不同 URL 编码、更换请求方法、更换 content-type、放慢节奏、混合大小写关键词）。若规避变体恢复信号，说明缓解在 WAF 层（可绕过）；若仍被阻断，缓解可能在代码层。

发现模板包含：观察描述、缓解深度评估（WAF 层可绕过 vs 代码层持久）、正面影响（SOC 具备检测可见性与部署权限）、注意事项（原始漏洞确实存在且可被利用）、建议（验证缓解在代码层、审计同类应用、记录 IR 响应能力）。

观察二：活跃的并发攻击者

症状：尽管遵守每用户一次尝试的纪律，仍出现大量 AADSTS50053（LOCKED）响应；锁定按字母顺序或其他排序键聚集；测试期间出现新锁定；LOCKED 率超过预期基线。

数学验证：自身纪律为每用户一次尝试；Smart Lockout 默认在 10 次失败尝试后锁定，锁定持续时间从 60 秒开始并随每次后续锁定增长。因此若工具日志确认每用户恰好一次尝试，则数学上不可能由自身造成 Smart Lockout。测试窗口内新增累积的锁定由他人造成；既有锁定可能源于合法用户自身失败或先前测试，仅将新增锁定归因于外部方。

确认方法：按字母排序锁定账户查看是否聚集；对比会话前后锁定计数；探测已知活跃的系统账户（noreply@、info@、oc@）。

发现模板包含：观察描述、归因说明（仅归因于测试窗口内新增的锁定）、影响（外部对手正积极尝试入侵 M365 账户）、建议（24 小时内开启 P1 事件、拉取登录日志、应用条件访问规则、启用身份保护、强制密码重置、审计 MFA 豁免）、证据路径。

观察三：检测引发的速率限制/IP 封禁

症状：特定 IP 在正常响应窗口后开始返回 403/429/451；响应显著变慢；TLS 握手失败或连接中断；DNS 突然返回 NXDOMAIN；部分主机从某 IP 可用而从另一 IP 不可用。

确认方法：切换到不同 IP 重试；对比 DNS 响应 TTL；检查 CDN 相关响应头。

发现模板（通常为低/信息级运营备注）包含：观察描述、影响（正面：反自动化控制有效；注意事项：轮换 IP 可轻易绕过）。

状态差异——关键技术

维护三份状态：

1. engagement_log/baseline.json——会话开始时采集（时间戳、源 IP、各目标的基线响应时间/大小/响应头/cookie、M365 锁定计数等）
2. engagement_log/journal.jsonl——追加式测试日志（每次测试记录时间戳、IP、工具、目标、payload、响应码、响应大小、响应时间、判定、备注）
3. engagement_log/state_changes.jsonl——观察到的差异（检测到状态变化时追加，包含观察时间、变化类型、目标、变更前后数值、解释、采取的行动）

第三份文件是发现证据，每条记录都是候选发现。

工具：自动化状态变化检测

提供 Bash watcher 脚本，在测试期间每 5 分钟运行，重新测量关键目标的基线时序，并与会话前基线对比，若偏移超过 50% 则告警。另提供 M365 锁定计数跟踪脚本，每 30 分钟统计 AADSTS50053 出现次数并记录历史，对比首尾以呈现差异。

“单一信号撤回”规则

若已确认的漏洞不再复现：不要删除原始 PoC（原始时间戳、payload、响应捕获永久保留）；详细捕获新状态；在宣布“不确定”前至少尝试 3 种替代向量；若均无法恢复信号，记录为“漏洞在 T0 确认，在 T0+ 观察到缓解，缓解深度：[WAF | 代码]”。两种状态都写入报告。

为何这是一项发现

向客户说明“我在 14:24 确认 SQLi，你在 14:55 部署了缓解，这是原始 PoC，以及为何仍应验证修复在代码层”，可确认漏洞存在、确认缓解已部署、识别深度问题、展示红队价值。这比单独“我确认了 SQLi”更有价值。

应避免的反模式

• “复查失败 → 误报。”不对，复查失败是因为目标改变了，应调查变化。
• “不再有漏洞，放弃该发现。”不对，它曾经有漏洞，发现保留，添加“当前状态：已缓解”注释。
• “他们打了补丁，任务完成。”不对，WAF 规则不等于代码修复，需验证深度。
• “不要告诉客户我们观察到他们的补丁。”应该告诉，这是关于其 IR 的正面发现。
• “不要包含锁定账户列表——他们会以为是我们造成的。”不对，数学与日志纪律证明不是，应连同数学一起包含列表。

与相邻技能的衔接

• redteam-mindset——更广泛的纪律框架，本技能是其具体应用
• m365-entra-attack——M365 / Smart Lockout 差异的具体案例
• evidence-hygiene——如何正确捕获和脱敏 PoC 证据
• report-writing——IR 观察的发现模板
• bb-methodology——注意本技能不适用于漏洞赏金（无实时 IR）

一句话总结

你的测试会留下足迹，足迹会改变目标。捕获两种状态，两者都是发现。

相关技能与链

• redteam-mindset：测试开始时加载，建立基线捕获习惯；响应模式中途变化时激活本技能，将 SOC 补丁状态作为新发现捕获。
• evidence-hygiene：本技能产生两种状态（补丁前与补丁后），均需纪律性证据捕获。
• m365-entra-attack：现代测试中最丰富的 IR 信号来源；M365 喷洒触发锁定，若锁定窗口中途变化则捕获为发现。
• enterprise-vpn-attack + vmware-vcenter-attack：关键基础设施 CVE 利用噪声最高，预期 SOC 数小时内打补丁；利用前采集基线，若设备中途更新则捕获为防御动作发现。
• redteam-report-template：IR 观察发现拥有独立 Subject，与技术漏洞发现的框架不同。