mid-engagement-ir-detection

When to use this skill

Trigger when:

- Running active testing against a target with active SOC monitoring

- A confirmed-vulnerable finding stops reproducing on recheck

- Baseline timing shifts unexpectedly (3× slower, sudden errors, new headers)

- Response sizes change between test windows

- New WAF cookies or headers appear that weren't there at session start

- Lockout / error rates change between test windows (especially LOCKED count for credential attacks)

- Engagement is "assume breach" or "white box" — client knows you're testing

DO NOT use for:

- Bug bounty (client doesn't know you're there; no real-time IR)

- Pure recon (no state-change happening)

- One-off vulnerability scanning (no temporal dimension)

---

The core insight

In a real red-team engagement against a competent SOC, the security state of the target is **not static**. It changes during your test in response to your traffic. These state changes are:

1. **Themselves valuable findings** (positive operational observations about IR responsiveness)

2. **Confirmation evidence** (mid-engagement patch = the original vulnerability was real)

3. **Classification signals** (WAF rule deployment vs code fix — different remediation depth)

Anti-pattern: treating reproduction failure as evidence the original signal was a false positive. **Original PoC artifacts captured before the change are still the vulnerability finding.**

---

The discipline — capture before, diff after

Before any active test:

# 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>,
}

Persist to `engagement_log/fingerprint_pre.json`.

During the test:

Log every test result with full context (timestamp, IP, payload, response code, response size, response time, headers if relevant) to JSONL append-only.

After the test session OR on first failed-recheck:

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,
}

If any delta is significant — **investigate, don't retract**.

---

The three primary IR observations

Observation 1 — Mid-engagement WAF rule deployment

**Symptoms:**

- Original payloads return identical response → no signal at all on recheck

- Body size identical to baseline (login page reflection)

- Timing reverts to baseline regardless of payload

- New cookie or header in responses (e.g., `cf-bm`, `__cf_bm`, `awselb`)

- Specific keyword in URL/body now triggers different response code (403, 406, 429)

**Confirmation:** retry with WAF-evasion variants:

- URL-encode the payload differently (`%27` vs `%5cu0027`)

- Change request method (POST → PUT, GET → POST)

- Different content-type (form-urlencoded → multipart)

- Slower pace (5s → 60s between requests)

- Mixed-case keywords (`SLEEP` → `SlEeP`)

If WAF-evasion variants restore the signal, the mitigation is at the WAF layer (bypassable).

If even WAF-evasion variants stay blocked, the mitigation is likely in code.

**Finding template:**

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]