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: