用途
本技能用于在红队交战（red-team engagement）过程中，检测目标客户端SOC（安全运营中心）的补丁部署、攻击者活动以及安全状态变化，并将这些变化转化为可交付的安全发现。它解决的核心问题是：在带有活跃SOC监控的真实交战中，目标的安全状态会因你的测试流量而动态改变，而这些改变本身就是有价值的发现，而非需要撤回原结论的信号。
核心洞察
在针对具备能力的SOC开展的真实红队交战中，目标的安全状态不是静态的，而是会响应你的流量在测试过程中发生变化。这些状态变化本身是：
- 有价值的发现（关于IR响应能力的正面运营观察）
- 确认证据（交战中途的补丁 = 原始漏洞确实存在）
- 分类信号（WAF规则部署 vs 代码修复 —— 修复深度不同）
反模式：将复现失败视为原始信号是误报的证据。在状态变化之前捕获的原始PoC工件仍然是漏洞发现。
使用时机
触发条件包括：
- 针对带有活跃SOC监控的目标运行主动测试
- 已确认的漏洞发现在复查时不再复现
- 基线时序意外偏移（变慢3倍、突然报错、出现新响应头）
- 测试窗口之间响应大小发生变化
- 会话开始时不存在的新WAF Cookie或响应头出现
- 锁定/错误率在测试窗口之间变化（尤其是凭证攻击的LOCKED计数）
- 交战属于“假设已失陷”或“白盒”模式——客户端知道你在测试
不要用于：
- 漏洞赏金（客户端不知道你在，没有实时IR）
- 纯侦察（没有状态变化发生）
- 一次性漏洞扫描（没有时间维度）
纪律 —— 前捕获、后对比
在任何主动测试之前，捕获目标的前测试指纹，包括时间戳、操作源IP、基线响应时间、基线响应大小、响应头集合、WAF Cookie列表、锁定计数等，持久化到 engagement_log/fingerprint_pre.json。
测试期间，将每个测试结果连同完整上下文（时间戳、IP、载荷、响应码、响应大小、响应时间、相关响应头）追加写入JSONL。
测试会话结束后或首次复查失败时，生成同结构的后测试指纹并计算差异（基线时间变化、基线大小变化、新增响应头、新增WAF Cookie、新增锁定数）。若任何差异显著，应调查而非撤回。
三类主要IR观察
观察1 —— 交战中WAF规则部署
症状：原始载荷返回完全相同的响应（复查时完全无信号）；响应体大小与基线一致；无论载荷如何时序都回归基线；响应中出现新的Cookie或响应头；URL/响应体中的特定关键词现在触发不同的响应码（403、406、429）。
确认方法：使用WAF规避变体重试，包括不同的URL编码、更改请求方法、不同content-type、放慢节奏、混合大小写关键词。若WAF规避变体恢复信号，则缓解在WAF层（可绕过）；若规避变体仍被阻止，缓解可能在代码层。
发现模板包含：主题、观察、描述（缓解深度评估）、正面影响（客户端SOC具备检测级可见性和部署权限）、注意事项（原始漏洞确实存在，若仅为WAF层缓解则代码级缺陷仍可通过替代载荷利用）、建议（验证是代码级修复、审计同类应用、记录IR响应能力）。
观察2 —— 活跃的并发攻击者
症状：尽管你遵循每用户仅1次尝试的纪律，仍出现大量AADSTS50053（LOCKED）响应；锁定按字母或其他排序键聚集；你的交战中新增锁定出现（前后差异）；LOCKED率超出预期基线。
数学校验：你的纪律是每用户终身1次尝试；Smart Lockout默认在10次失败尝试后锁定，锁定时长从60秒开始并随每次后续锁定增长。因此若命令行日志确认每用户恰好1次尝试，你数学上不可能造成Smart Lockout。因此窗口中新增累积的每个AADSTS50053都是他人造成的；只将新累积的锁定归因于外部方。
确认方法：按字母排序被锁定账户，若聚集则攻击者使用排序用户名列表；比较会话前后锁定计数；探测已知活跃的“系统”账户（noreply@、info@、oc@），若被锁定则攻击者也在攻击服务邮箱（通常免MFA，对攻击者高价值）。
发现模板包含：主题、观察、描述、影响、建议（关键——24小时内：向SOC开P1事件、拉取登录日志、应用条件访问规则、启用身份保护用户风险策略、强制全体密码重置、审计服务账户MFA豁免）、证据。
观察3 —— 检测引发的限流/IP封禁
症状：特定IP在正常响应窗口后开始返回403/429/451；特定IP响应显著变慢；TLS握手失败或连接中途RST；DNS突然对之前可解析的主机返回NXDOMAIN；某些主机从一个IP可访问但从另一个不行。
确认方法：切换到不同IP重试；比较DNS响应的TTL；检查Server、Via、CF-Cache-Status响应头中的CDN引入限制。
发现模板（运营备注，通常低/信息级严重性）包含：主题、观察、描述、正面影响、注意事项（轮换即轻松绕过，耐心的攻击者或住宅代理喷射攻击者不受影响）。
状态差异——关键技术
维护三份状态：
- engagement_log/baseline.json —— 会话开始时捕获
- engagement_log/journal.jsonl —— 仅追加测试日志
- engagement_log/state_changes.jsonl —— 观察到的差异
第三个文件是发现证据，每条记录都是候选发现。
工具 —— 自动化状态变化检测
技能提供了Bash watcher脚本，每5分钟运行一次，重新测量关键目标的基线时序并与会话前基线对比，若偏移超过50%则告警。另提供M365锁定计数跟踪方法，每30分钟记录一次锁定计数并对比首尾差异。
“单一信号撤回”规则
若已确认漏洞的发现停止复现：不要删除原始PoC（原始时间戳、载荷、响应捕获永久保留）；详细捕获新状态；在宣布“不确定”前至少尝试3种替代途径；若都无法恢复信号，记录为“T0确认漏洞，T0+观察到缓解，缓解深度：[WAF|代码]”。两个状态都进入报告。
为什么这是发现（向客户说明价值）
当告诉客户“我在14:24确认了SQLi，你们在14:55部署了缓解，这是原始PoC，这是为什么你们仍应验证修复在代码层”时：确认了漏洞存在（审计级证据）；确认了缓解已部署（SOC的正面运营发现）；识别了深度问题（WAF vs 代码——修复成本不同）；展示了红队价值。
应避免的反模式
- “复查失败 → 误报。” 不对。复查失败是因为目标改变了。调查变化。
- “不再有漏洞，放弃发现。” 不对。它曾经有漏洞。发现保留。添加“当前状态：已缓解”注释。
- “他们打了补丁，任务完成。” 不对。WAF规则 ≠ 代码修复。验证深度。
- “不要告诉客户我们观察到他们的补丁。” 不，要告诉。这是关于他们IR的正面发现。
- “不要包含被锁定账户列表——他们会认为是我们造成的。” 不。数学+日志纪律证明不是你造成的。带上数学一起包含列表。
与相邻技能的桥接
redteam-mindset（更广泛的纪律框架，本技能是其具体应用）、m365-entra-attack（M365/Smart Lockout差异的具体案例）、evidence-hygiene（如何正确捕获和编辑PoC证据）、report-writing（IR观察的发现模板）、bb-methodology（注意本技能不适用于漏洞赏金，那里没有实时IR）。
一句话总结
你的交战会留下足迹。足迹改变了目标。捕获两个状态。两者都是发现。
验证
检测信号——确认常见IDS/IPS签名被识别；时间线模板——确认时间线文档被覆盖。所有测试验证IR检测就绪状态。
陷阱
IR检测但无响应计划（检测蓝队反应是情报，但无适应计划就只是观察）；正常运营的误报（业务时间增加日志是正常的，区分IR特定信号）；通过重扫描惊动SOC（激进的扫描会触发IR，发现应是你从其响应中学到的，而非你触发了它）；假设被检测=被抓（检测是IR杀伤链的一步，遏制、根除、恢复随后）；未记录时间线（检测发生的确切时间、变化内容、你如何适应是交付物）。