mid-engagement-ir-detection

何时使用此技能

适用于：

• 对启用了 SOC 监控的目标进行主动测试
• 复查时，已确认存在漏洞的发现不再复现
• 基线耗时意外变化（慢 3 倍、突然出现错误、新增标头）
• 不同测试时段的响应大小发生变化
• 会话开始时没有的新 WAF Cookie 或标头出现
• 不同测试时段的锁定／错误率发生变化（尤其是凭据攻击中的 LOCKED 数量）
• 测试属于“假设已遭入侵”或“白盒”场景——客户知道你在进行测试

不适用于：

• 漏洞赏金（客户不知道你在测试，也没有实时事件响应）
• 纯侦察（不会发生状态变化）
• 一次性漏洞扫描（没有时间维度）

---

核心认识

在针对成熟 SOC 开展的真实红队测试中，目标的安全状态并非静态。目标会因你的流量而在测试期间发生变化。这些状态变化：

1. 本身就是有价值的发现（有关事件响应能力的正面运营观察）
2. 是确认依据（测试期间打上的补丁，表明原始漏洞确实存在）
3. 是分类信号（部署 WAF 规则还是修复代码，代表不同的修复深度）

反模式：把无法复现视为原始信号属于误报的证据。变更前捕获的原始 PoC 产物仍然是漏洞发现的依据。

---

测试规范——先采集，后对比

任何主动测试开始前：

# Capture pre-test fingerprint of the target
fingerprint = {
    "ts_pre": time.time(),
    "ip_seen": "<operator-src-ip>",
    "baseline_response_time_ms": <measure>,
    "baseline_response_size_bytes": <measure>,
    "response_headers": <capture set>,
    "waf_cookies": <list>,
    "lockout_count_in_state": <count from o365_attempts.json>,
}

保存到 engagement_log/fingerprint_pre.json。

测试期间：

将每项测试结果及完整上下文（时间戳、IP、载荷、响应代码、响应大小、响应时间，以及相关标头）以 JSONL 追加写入，不覆盖已有内容。

测试会话结束后或首次复查失败时：

fingerprint_post = same structure
delta = {
    "baseline_time_change_ms": post.time - pre.time,
    "baseline_size_change_bytes": post.size - pre.size,
    "new_headers_appeared": post.headers - pre.headers,
    "new_waf_cookies": post.cookies - pre.cookies,
    "new_lockouts": post.locked_count - pre.locked_count,
}

如果存在任何显著差异，应调查，而非撤回发现。

---

三项主要事件响应观察

观察 1——测试期间部署 WAF 规则

症状：

• 原始载荷返回完全相同的响应 → 复查时完全没有信号
• 正文大小与基线一致（登录页面反射）
• 无论载荷如何，耗时都恢复到基线
• 响应中出现新的 Cookie 或标头（例如，cf-bm、__cf_bm、awselb）
• URL／正文中的特定关键词现在会触发不同的响应代码（403、406、429）

**确认方法：**使用 WAF 绕过变体重试：

• 以不同方式对 URL 中的载荷进行编码（%27 与 %5cu0027）
• 更改请求方法（POST → PUT、GET → POST）
• 更改内容类型（form-urlencoded → multipart）
• 放慢请求频率（请求间隔从 5s 增至 60s）
• 混合大小写关键词（SLEEP → SlEeP）

如果 WAF 绕过变体能恢复信号，说明缓解措施位于 WAF 层（可绕过）。

如果 WAF 绕过变体仍被拦截，缓解措施很可能位于代码中。

发现模板：

Subject: Mid-engagement mitigation deployed for <vulnerability X>
Observation: At engagement timestamp T0, vulnerability <X> on <endpoint> was
confirmed via <PoC>. At T0+<minutes>, recheck via the original payload no longer
reproduces the timing/error/size differential. <WAF-evasion variant> [does/does
not] restore the signal.

Description: This pattern is consistent with the client SOC observing engagement
traffic and deploying a mitigation in real time. Mitigation depth assessment:
[at-WAF, bypassable] vs [in-code, durable].

Impact (positive): Client SOC has both detection-grade visibility into application
traffic AND the authority to deploy mitigations within ~<minutes> of detection.

Impact (caveat): The original vulnerability did exist and was exploitable for at
least the engagement window before mitigation. If the mitigation is at the WAF
layer only, the underlying code-level flaw remains exploitable via alternative
payloads.

Recommendation:
1. Verify the mitigation is in code (parameterized queries, input sanitization),
   not just at the WAF layer.
2. Audit the codebase for the same root cause across sister applications.
3. (Positive) Document the IR responsiveness as a capability metric.

观察 2 — 活跃的并发攻击者

症状：

• 尽管你严格遵守每个用户仅尝试 1 次的原则，仍出现大量 AADSTS50053（LOCKED）响应
• 账户锁定按字母顺序或其他排序键聚集
• 在你的测试期间出现新的锁定（对比前后状态）
• LOCKED 比率超过预期基线（在我们的测试中，占所有尝试的 11% → 红色警报）

数学核验：

• 你的纪律：每个用户终身仅尝试 1 次
• Smart Lockout 默认在失败尝试 10 次后锁定；锁定时长从 60 秒开始，并随之后每次锁定逐渐增加（并非固定的 10 分钟时长）
• 因此：如果工具日志确认每个用户恰好尝试 1 次（没有突发重试、没有并行 goroutine 重复发送、没有工具配置错误），那么从数学上说，你不可能触发 Smart Lockout——在断言这一点之前，请确认 journal.jsonl 显示每个用户仅尝试 1 次
• 因此：在测试时间窗口内新增的每个 AADSTS50053（通过前后状态对比确认）都由其他人造成；既有锁定可能源于合法用户自身的失败尝试或之前的测试运行，因此只能将新增锁定归因于外部人员

确认方法：

• 按字母顺序排列被锁定的账户；如果出现聚集，说明攻击者正在使用排序后的用户名列表
• 比较测试会话开始前和结束后的锁定数量——会话期间新增的锁定说明攻击者此刻仍在活动
• 探测一个已知活跃的“系统”账户（noreply@、info@、oc@）——如果它也被锁定，说明攻击者也在攻击服务邮箱（这些邮箱通常免于 MFA，对攻击者而言价值很高）

发现模板：

Subject: Active external password-spray campaign detected during engagement

Observation: During M365 ROPC validation against the <tenant> Entra tenant, <N>
unique principals returned AADSTS50053 (Smart Lockout) when probed with a single
password attempt at safe pace. Our tool journal (journal.jsonl) confirms exactly
1 attempt per user with no duplicate sends, so under the Smart Lockout default
(lockout after 10 failed attempts) we cannot have caused these lockouts. The
attribution below applies to the <K> NEW locks that accumulated during our
engagement window between <timestamp_start> and <timestamp_end> (per before/after
diff); pre-existing locks are not attributed to this campaign.

Description: The pattern (alphabetical clustering, real-time accumulation,
including system mailboxes) is consistent with an external attacker performing
a username-list-driven password spray attack against the tenant.

Impact: An external adversary is actively attempting to compromise corporate
M365 accounts. The attacker has knowledge of the user-email schema and a
password-guess wordlist. <List of locked accounts is now in attacker's hands>
(Smart Lockout differentiates valid from invalid usernames).

Recommendation (CRITICAL — within 24h):
1. Open a P1 incident with the SOC. Pull Entra sign-in logs for the <N> locked
   accounts over the last 30-60 days. Identify source IPs and time windows.
2. Apply Conditional Access rule blocking sign-ins from outside <expected geo>
   for non-admin accounts.
3. Enable Identity Protection's User Risk policy with auto-reset on high risk.
4. Force tenant-wide password reset for all <N> previously-locked accounts.
5. Audit service accounts for MFA exemptions; ensure all human-interactive
   accounts have phishing-resistant MFA.

Evidence: engagement_log/poc/m365/locked_accounts.txt (<N> entries with timestamps)

观察 3 — 检测触发的速率限制 / IP 封禁

症状：

• 某个 IP 在一段时间内正常响应后，开始返回 403 / 429 / 451
• 某个 IP 的响应速度明显变慢（达到基线的 3 倍以上）
• TLS 握手失败，或连接中途收到 RST
• 之前能解析的主机名，其 DNS 突然返回 NXDOMAIN
• 某些主机从一个 IP 可以访问，从另一个 IP 则不行

确认方法：

• 切换到不同的 IP 并重试——如果能够正常工作，说明你遭到了速率限制 / 封禁
• 比较 DNS 响应的 TTL——TTL 突然缩短，说明已部署主动缓解措施
• 检查 Server:、Via:、CF-Cache-Status: 标头，查看是否存在 CDN 引入的限制

发现模板（操作说明，通常为低 / 信息级别）：

Subject: Engagement traffic detected — IP <X> rate-limited at <timestamp>

Observation: After ~<N> requests in <window> from IP <X>, target <hostname>
began returning <code> for all subsequent requests. Rotation to IP <Y>
restored normal responses.

Description: Active anti-automation control at the perimeter (CDN/WAF/origin).

Impact (positive): Volumetric anti-automation is functional.

Impact (caveat): Rotation defeats this control trivially (cloud VMs cost <$5).
A patient adversary or spray-from-residential-proxies attacker is not affected.

---

状态差异 — 关键技术

维护三项状态：

1. engagement_log/baseline.json — 在会话开始时捕获

{
  "ts": "2026-05-08T13:00:00",
  "source_ip": "<operator-src-ip>",
  "targets": {
    "https://target.example.com/login": {
      "baseline_response_time_ms": 584,
      "baseline_response_size_bytes": 11966,
      "headers_seen": ["Server: Apache", "X-Powered-By: PHP/8.0.26"],
      "set_cookie_names": ["PHPSESSID"]
    }
  },
  "m365": {
    "lockout_count": 247,
    "valid_creds_count": 0
  }
}

2. engagement_log/journal.jsonl — 仅追加的测试日志

每项测试都记录：

{"ts":"...","ip":"...","tool":"...","target":"...","payload":"...","resp_code":...,"resp_size":...,"resp_ms":...,"verdict":"...","notes":"..."}

3. engagement_log/state_changes.jsonl — 观察到的变化

检测到状态变化时，追加记录：

{"ts_observed":"2026-05-08T14:30:00","change_type":"baseline_time_shift","target":"https://<employee-app-host>/<app>/login.php","baseline_pre_ms":24412,"baseline_post_ms":90403,"interpretation":"likely WAF rule deployed","actions_taken":["tested WAF-evasion variants — no signal restoration","documented as IR-mitigation finding"]}

第三个文件就是你的发现证据。每条记录都可能成为一项发现。

---

工具 — 自动检测状态变化

# Bash watcher — runs every 5 min during engagement, alerts on shifts

cd "$ENGAGEMENT_DIR"

# Re-measure baseline timing on key targets
for target in "$@"; do
  ms=$(curl -sk -o /dev/null -w "%{time_total}" "$target" --max-time 30)
  ms_int=$(echo "$ms * 1000" | bc | cut -d. -f1)
  echo "$(date -u +%FT%TZ) $target $ms_int" >> baseline_history.log
done

# Diff against pre-session baseline
python3 - << 'PY'
import json, time
baseline = json.load(open("engagement_log/baseline.json"))
for line in open("baseline_history.log"):
    parts = line.strip().split()
    ts, target, ms = parts[0], parts[1], int(parts[2])
    if target in baseline["targets"]:
        pre = baseline["targets"][target]["baseline_response_time_ms"]
        if abs(ms - pre) > pre * 0.5:  # >50% shift
            print(f"ALERT {ts} {target} time {pre} -> {ms}")
PY

对于 M365 的账户锁定数量跟踪：

# Run every 30 min during M365 spray
LOCK_COUNT=$(grep -c '"AADSTS50053"' engagement_log/o365_results.jsonl)
echo "$(date -u +%FT%TZ) lockout_count $LOCK_COUNT" >> lockout_history.log
# Diff first vs last to surface delta

---

“单一信号消失后复核”规则

如果已确认存在漏洞的发现不再复现：

1. 不要删除原始 PoC。 原始时间戳、载荷和响应捕获记录必须永久保留。
2. 详细记录新状态。 复查响应是什么？发生了哪些变化？
3. 在判定为“无法确定”之前，至少尝试 3 种替代向量。
4. **如果都无法恢复该信号，**请记录为“漏洞于 T0 确认，观察到缓解措施的时间为 T0+，缓解措施深度：[WAF | 代码]”。
5. 报告中应包含两种状态。 原始发现和 IR 观察结果。

这正是专业红队与“业余扫描”的区别所在。你的客户需要了解漏洞和缓解措施的时间线，而不仅仅是静态状态。

---

为什么这是一个发现（向客户说明其价值）

当你告诉客户：“我在 14:24 确认了 SQLi，你们在 14:55 部署了缓解措施。这是原始 PoC，以下是为什么你们仍应确认代码中已修复该问题”时：

• 确认漏洞确实存在（审计级证据）
• 确认缓解措施已部署（对 SOC 的正面运维发现）
• 明确了深度问题（WAF 还是代码修复——修复成本各不相同）
• 展现了红队价值（你既证明了漏洞存在，也证明了 IR 响应速度）

这比单独说“我确认了 SQLi”更有价值，因为它呈现了此次参与的完整运维情况。

---

应避免的反模式

• “复查失败 → 误报。” 不对。复查失败是因为目标发生了变化。调查这项变化。
• “现在已经没有漏洞了，删除这项发现。” 不对。它曾经存在漏洞。保留这项发现，并添加“当前状态：已缓解”的注释。
• “他们打了补丁，任务完成。” 不对。WAF 规则 != 代码修复。确认修复深度。
• “不要告诉客户我们观察到了他们的修补操作。” 不对，要告诉他们。这是关于其 IR 的一项正面发现。
• “不要附上被锁定账户的列表——他们会以为是我们导致的。” 不对。通过数学计算和记录规范，可以证明并非如此。附上列表和计算过程。

---

与相邻技能的关联

• redteam-mindset — 更广泛的纪律框架；本技能是其中一项具体应用
• m365-entra-attack — 针对 M365 / Smart Lockout 差异的具体案例
• evidence-hygiene — 如何妥善采集和编辑 PoC 证据
• report-writing — IR 观察结果的发现模板
• bb-methodology — 请注意，本技能不适用于漏洞赏金（那里没有实时 IR）

---

一句话总结

你的参与会留下痕迹。痕迹会改变目标。记录变化前后的状态。两者都是发现。

---

相关技能与链路

• redteam-mindset — 本技能是更广泛红队纪律的具体应用。参与流程：在参与开始时加载 redteam-mindset → 养成捕获基线的习惯 → 测试中响应模式发生变化时，启用 mid-engagement-ir-detection，将 SOC 打补丁后的状态记录为一项新发现（观察到防御行动 = 客户能力指标，而不是“漏洞已修复，所以这项发现就不算了”）。
• evidence-hygiene — 参与期间的 IR 检测会产生两种状态（修补前和修补后）；两者都需要规范地采集证据，否则就无法为第二项发现提供依据。参与流程：在会话开始时采集基线截图和带时间戳的请求／响应转储 → 检测到响应变化 → 采集第二组证据，并明确记录时间差 → 将两组证据一并打包。
• m365-entra-attack — 在现代安全测试中，这是参与期间 IR 信号最丰富的来源。参与流程：M365 喷洒攻击触发 AADSTS50053 锁定 → 捕获基线锁定策略 → 如果测试期间锁定时长发生变化（例如从 60min 变为 24hr）→ mid-engagement-ir-detection 将策略变更记录为一项发现（“参与期间 CA 策略得到强化；已测量防御响应”）。
• enterprise-vpn-attack + vmware-vcenter-attack — 对关键基础设施 CVE 的利用是噪声最高的活动；预计 SOC 会在数小时内修补。参与流程：确认 VPN/vCenter CVE → 在尝试利用前捕获基线 → 如果设备在测试期间更新，将其记录为防御行动发现 → 同时报告原始 CVE 和 IR 响应。
• redteam-report-template — IR 观察类发现会在交付成果中拥有独立的主题，与技术漏洞发现采用不同的表述方式。参与流程：mid-engagement-ir-detection 捕获行为变化事件 → triage-validation 的 7-Question Gate（具体问题：“行为变化是否由我的活动导致？”）→ redteam-report-template 将其包装为“客户能力观察”，并明确列出时间线和检测延迟指标。