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] 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:

…