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: ```py...