mid-engagement-ir-detection – Security skill for AI agents

> ⚠️ AUTHORIZED USE ONLY

> This skill is for educational purposes or authorized security assessments only.

> You must have explicit, written permission from the system owner before using this tool.

> Misuse of this tool is illegal and strictly prohibited.

Mandatory confirmation gate

Before any probe, evasion, source-IP change or credential-related request, collect the exact target URL, IP, account, or resource, written authorization and permitted scope; show the exact command and expected effect. Wait for explicit confirmation in the current conversation. Otherwise review existing evidence only. Unexpected blocks/lockouts trigger the engagement stop/contact procedure, not automatic evasion. Bound requests, account attempts, timing and cost; never test unrelated accounts or change tenant policies.

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:

• Any program whose authorization excludes the proposed observation/probe; bug-bounty programs can also have active SOC monitoring
• 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. Contextual evidence (a response change alone proves neither a patch nor the original vulnerability)

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. Preserve original artifacts, then independently assess whether they actually established the vulnerability; label uncertain signals honestly.

---

The discipline — capture before, diff after

Before any active test:

# Pseudocode only; placeholders are not runnable Python.
# 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:

# Pseudocode only.
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 a delta is significant, investigate alternative explanations and update confidence; neither retain nor retract a finding automatically.

---

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).

A failed variant does not identify a code fix. WAF/origin/cache/session/backend changes require owner logs, configuration or code evidence to distinguish.

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:
[observed bypass under stated conditions] vs [layer/depth unknown pending owner evidence].

Impact (positive): Only claim SOC detection/mitigation timing when owner telemetry confirms the detection and change events; response timing alone is not that evidence.

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.

Observation 2 — Possible concurrent activity or authentication policy change

AADSTS50053 can reflect account lockout or a malicious-source-IP block, irrespective of password validity. Defaults vary across cloud environments and tenant settings. Prior failures, familiar/unfamiliar-location counters, legitimate users, federated/pass-through behavior and the engagement itself can contribute. One logged attempt per user does not mathematically exclude tester contribution or prove an external actor.

Stop credential probes at the agreed threshold and coordinate with the authorized SOC contact. Review existing owner-provided sign-in logs, actual failure reasons, source identities/IPs, correlation IDs, timestamps and tenant policies. Compare against the tester's complete request journal and approved baseline. Alphabetic clustering or a rising response-code count is a hypothesis, not attribution. Do not probe service mailboxes to “confirm” a live attacker or assume they are MFA-exempt.

Report observed counts separately from unique principals and actual lockout events. Preserve unknown causes and benign alternatives. Password resets, geo-blocking, risk-policy changes or tenant-wide containment belong to the authorized incident commander after impact review, not an automatic24-hour checklist.

Example report:

Observation: N responses contained50053 during [UTC window] from approved sourceX.
Known: owner logs identify [documented failure reason]; tester journal covers [scope].
Unknown: attribution and whether the response change resulted from a mitigation.
Next: authorized SOC correlates existing identity/network telemetry and decides response.

Observation 3 — Detection-induced rate limiting / IP blocks

Symptoms:

• Specific IP starts returning 403 / 429 / 451 after a window of normal responses
• Specific IP starts seeing dramatically slower responses (3x+ baseline)
• TLS handshake fails or RST mid-connection
• DNS suddenly returns NXDOMAIN for hosts that resolved before
• Some hosts work from one IP but not another

Confirmation:

• Compare already authorized source observations; do not rotate around a block unless the engagement owner explicitly approves that exact action
• Compare DNS answers/TTL with resolver/cache/routing controls; a TTL change alone does not prove mitigation
• Check Server:, Via:, CF-Cache-Status: headers for CDN-introduced limits

Finding template (operational note, usually low/info severity):

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): A permitted alternate-source observation may show a scope limitation; it does not establish universal bypass, attacker cost or complete control fa

… (full content is in the download package)