[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6F90FZVHBE4HAY35KDFWJFF":3,"skill-same:01M6F90FZVHBE4HAY35KDFWJFF":73},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":41,"linkOnly":42,"markdownContent":43,"markdownBody":44,"frontMatter":45,"refName":29,"commitSha":53,"skillDirectory":54,"forksCount":55,"repositoryHtmlUrl":56,"repositoryHomepageUrl":6,"ownerHtmlUrl":57,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":58,"install":59,"resources":72},"01M6F90FZVHBE4HAY35KDFWJFF","mid-engagement-ir-detection",null,"Methodology for detecting client SOC patches, attacker activity, and security-state changes that occur DURING a red-team engagement","boisenoise\u002Fskills-collections","boisenoise","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F193180?v=4","01M6CDBDQK6BDN55ZMA6B6PKBM","01M6CDBDVSJ3JPTBYN26FZ7TZK",13,"MIT","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-mid-engagement-ir-detection\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40],"mid engagement ir detection","detection","engagement","2026","github","changes","for","detecting","activity","offensive","upstream","main","community","tooling","only","process","team","soc","red-team","https","license","state","security","2026-11-10 10:12:30",false,"---\nname: mid-engagement-ir-detection\ndescription: Methodology for detecting client SOC patches, attacker activity, and\n  security-state changes that occur DURING a red-team engagement\ncategory: security\nrisk: offensive\nsource: https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter\nsource_repo: elementalsouls\u002FClaude-BugHunter\nsource_type: community\ndate_added: '2026-09-20'\nlicense: MIT\nlicense_source: https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter\u002Fblob\u002Fmain\u002FLICENSE\ncompatibility: Process guidance; no tooling required. Docs-only; upstream templates\n  not bundled.\nsources: authorized-engagement\nreport_count: 1\n---\n\n> **⚠️ AUTHORIZED USE ONLY**\n> This skill is for educational purposes or authorized security assessments only.\n> You must have explicit, written permission from the system owner before using this tool.\n> Misuse of this tool is illegal and strictly prohibited.\n\n## Mandatory confirmation gate\n\nBefore 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\u002Flockouts trigger the engagement stop\u002Fcontact procedure, not automatic evasion. Bound requests, account attempts, timing and cost; never test unrelated accounts or change tenant policies.\n\n## When to use this skill\n\nTrigger when:\n- Running active testing against a target with active SOC monitoring\n- A confirmed-vulnerable finding stops reproducing on recheck\n- Baseline timing shifts unexpectedly (3× slower, sudden errors, new headers)\n- Response sizes change between test windows\n- New WAF cookies or headers appear that weren't there at session start\n- Lockout \u002F error rates change between test windows (especially LOCKED count for credential attacks)\n- Engagement is \"assume breach\" or \"white box\" — client knows you're testing\n\nDO NOT use for:\n- Any program whose authorization excludes the proposed observation\u002Fprobe; bug-bounty programs can also have active SOC monitoring\n- Pure recon (no state-change happening)\n- One-off vulnerability scanning (no temporal dimension)\n\n---\n\n## The core insight\n\nIn 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:\n\n1. **Themselves valuable findings** (positive operational observations about IR responsiveness)\n2. **Contextual evidence** (a response change alone proves neither a patch nor the original vulnerability)\n3. **Classification signals** (WAF rule deployment vs code fix — different remediation depth)\n\nAnti-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.\n\n---\n\n## The discipline — capture before, diff after\n\n### Before any active test:\n\n```text\n# Pseudocode only; placeholders are not runnable Python.\n# Capture pre-test fingerprint of the target\nfingerprint = {\n    \"ts_pre\": time.time(),\n    \"ip_seen\": \"\u003Coperator-src-ip>\",\n    \"baseline_response_time_ms\": \u003Cmeasure>,\n    \"baseline_response_size_bytes\": \u003Cmeasure>,\n    \"response_headers\": \u003Ccapture set>,\n    \"waf_cookies\": \u003Clist>,\n    \"lockout_count_in_state\": \u003Ccount from o365_attempts.json>,\n}\n```\n\nPersist to `engagement_log\u002Ffingerprint_pre.json`.\n\n### During the test:\n\nLog every test result with full context (timestamp, IP, payload, response code, response size, response time, headers if relevant) to JSONL append-only.\n\n### After the test session OR on first failed-recheck:\n\n```text\n# Pseudocode only.\nfingerprint_post = same structure\ndelta = {\n    \"baseline_time_change_ms\": post.time - pre.time,\n    \"baseline_size_change_bytes\": post.size - pre.size,\n    \"new_headers_appeared\": post.headers - pre.headers,\n    \"new_waf_cookies\": post.cookies - pre.cookies,\n    \"new_lockouts\": post.locked_count - pre.locked_count,\n}\n```\n\nIf a delta is significant, investigate alternative explanations and update confidence; neither retain nor retract a finding automatically.\n\n---\n\n## The three primary IR observations\n\n### Observation 1 — Mid-engagement WAF rule deployment\n\n**Symptoms:**\n- Original payloads return identical response → no signal at all on recheck\n- Body size identical to baseline (login page reflection)\n- Timing reverts to baseline regardless of payload\n- New cookie or header in responses (e.g., `cf-bm`, `__cf_bm`, `awselb`)\n- Specific keyword in URL\u002Fbody now triggers different response code (403, 406, 429)\n\n**Confirmation:** retry with WAF-evasion variants:\n- URL-encode the payload differently (`%27` vs `%5cu0027`)\n- Change request method (POST → PUT, GET → POST)\n- Different content-type (form-urlencoded → multipart)\n- Slower pace (5s → 60s between requests)\n- Mixed-case keywords (`SLEEP` → `SlEeP`)\n\nIf WAF-evasion variants restore the signal, the mitigation is at the WAF layer (bypassable).\n\nA failed variant does not identify a code fix. WAF\u002Forigin\u002Fcache\u002Fsession\u002Fbackend changes require owner logs, configuration or code evidence to distinguish.\n\n**Finding template:**\n```\nSubject: Mid-engagement mitigation deployed for \u003Cvulnerability X>\nObservation: At engagement timestamp T0, vulnerability \u003CX> on \u003Cendpoint> was\nconfirmed via \u003CPoC>. At T0+\u003Cminutes>, recheck via the original payload no longer\nreproduces the timing\u002Ferror\u002Fsize differential. \u003CWAF-evasion variant> [does\u002Fdoes\nnot] restore the signal.\n\nDescription: This pattern is consistent with the client SOC observing engagement\ntraffic and deploying a mitigation in real time. Mitigation depth assessment:\n[observed bypass under stated conditions] vs [layer\u002Fdepth unknown pending owner evidence].\n\nImpact (positive): Only claim SOC detection\u002Fmitigation timing when owner telemetry confirms the detection and change events; response timing alone is not that evidence.\n\nImpact (caveat): The original vulnerability did exist and was exploitable for at\nleast the engagement window before mitigation. If the mitigation is at the WAF\nlayer only, the underlying code-level flaw remains exploitable via alternative\npayloads.\n\nRecommendation:\n1. Verify the mitigation is in code (parameterized queries, input sanitization),\n   not just at the WAF layer.\n2. Audit the codebase for the same root cause across sister applications.\n3. (Positive) Document the IR responsiveness as a capability metric.\n```\n\n### Observation 2 — Possible concurrent activity or authentication policy change\n\n`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\u002Funfamiliar-location counters, legitimate users, federated\u002Fpass-through behavior and the engagement itself can contribute. One logged attempt per user does **not** mathematically exclude tester contribution or prove an external actor.\n\nStop 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\u002FIPs, 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.\n\nReport 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.\n\nExample report:\n```text\nObservation: N responses contained50053 during [UTC window] from approved sourceX.\nKnown: owner logs identify [documented failure reason]; tester journal covers [scope].\nUnknown: attribution and whether the response change resulted from a mitigation.\nNext: authorized SOC correlates existing identity\u002Fnetwork telemetry and decides response.\n```\n\n### Observation 3 — Detection-induced rate limiting \u002F IP blocks\n\n**Symptoms:**\n- Specific IP starts returning 403 \u002F 429 \u002F 451 after a window of normal responses\n- Specific IP starts seeing dramatically slower responses (3x+ baseline)\n- TLS handshake fails or RST mid-connection\n- DNS suddenly returns NXDOMAIN for hosts that resolved before\n- Some hosts work from one IP but not another\n\n**Confirmation:**\n- Compare already authorized source observations; do not rotate around a block unless the engagement owner explicitly approves that exact action\n- Compare DNS answers\u002FTTL with resolver\u002Fcache\u002Frouting controls; a TTL change alone does not prove mitigation\n- Check `Server:`, `Via:`, `CF-Cache-Status:` headers for CDN-introduced limits\n\n**Finding template (operational note, usually low\u002Finfo severity):**\n```\nSubject: Engagement traffic detected — IP \u003CX> rate-limited at \u003Ctimestamp>\n\nObservation: After ~\u003CN> requests in \u003Cwindow> from IP \u003CX>, target \u003Chostname>\nbegan returning \u003Ccode> for all subsequent requests. Rotation to IP \u003CY>\nrestored normal responses.\n\nDescription: Active anti-automation control at the perimeter (CDN\u002FWAF\u002Forigin).\n\nImpact (positive): Volumetric anti-automation is functional.\n\nImpact (caveat): A permitted alternate-source observation may show a scope limitation; it does not establish universal bypass, attacker cost or complete control failure.\n```\n\n---\n\n## State diff — the key technique\n\nMaintain three pieces of state:\n\n### 1. `engagement_log\u002Fbaseline.json` — captured at session start\n\n```json\n{\n  \"ts\": \"2026-05-08T13:00:00\",\n  \"source_ip\": \"\u003Coperator-src-ip>\",\n  \"targets\": {\n    \"https:\u002F\u002Ftarget.example.com\u002Flogin\": {\n      \"baseline_response_time_ms\": 584,\n      \"baseline_response_size_bytes\": 11966,\n      \"headers_seen\": [\"Server: Apache\", \"X-Powered-By: PHP\u002F8.0.26\"],\n      \"set_cookie_names\": [\"PHPSESSID\"]\n    }\n  },\n  \"m365\": {\n    \"lockout_count\": 247,\n    \"valid_creds_count\": 0\n  }\n}\n```\n\n### 2. `engagement_log\u002Fjournal.jsonl` — append-only test log\n\nEvery test logs:\n```jsonl\n{\"ts\":\"...\",\"ip\":\"...\",\"tool\":\"...\",\"target\":\"...\",\"payload\":\"...\",\"resp_code\":...,\"resp_size\":...,\"resp_ms\":...,\"verdict\":\"...\",\"notes\":\"...\"}\n```\n\n### 3. `engagement_log\u002Fstate_changes.jsonl` — observed deltas\n\nWhen a state change is detected, append:\n```jsonl\n{\"ts_observed\":\"2026-05-08T14:30:00\",\"change_type\":\"baseline_time_shift\",\"target\":\"https:\u002F\u002F\u003Cemployee-app-host>\u002F\u003Capp>\u002Flogin.php\",\"baseline_pre_ms\":24412,\"baseline_post_ms\":90403,\"interpretation\":\"likely WAF rule deployed\",\"actions_taken\":[\"tested WAF-evasion variants — no signal restoration\",\"documented as IR-mitigation finding\"]}\n```\n\nThis third file is your finding evidence. Every entry is a candidate finding.\n\n---\n\n## Tooling — automated state-change detection\n\n```bash\n# Bash watcher — runs every 5 min during engagement, alerts on shifts\n\ncd \"$ENGAGEMENT_DIR\"\n\n# Re-measure baseline timing on key targets\nfor target in \"$@\"; do\n  ms=$(curl -sS -o \u002Fdev\u002Fnull -w \"%{time_total}\" \"$target\" --max-time 30)\n  ms_int=$(echo \"$ms * 1000\" | bc | cut -d. -f1)\n  echo \"$(date -u +%FT%TZ) $target $ms_int\" >> baseline_history.log\ndone\n\n# Diff against pre-session baseline\npython3 - \u003C\u003C 'PY'\nimport json, time\nbaseline = json.load(open(\"engagement_log\u002Fbaseline.json\"))\nfor line in open(\"baseline_history.log\"):\n    parts = line.strip().split()\n    ts, target, ms = parts[0], parts[1], int(parts[2])\n    if target in baseline[\"targets\"]:\n        pre = baseline[\"targets\"][target][\"baseline_response_time_ms\"]\n        if abs(ms - pre) > pre * 0.5:  # >50% shift\n            print(f\"ALERT {ts} {target} time {pre} -> {ms}\")\nPY\n```\n\nFor lockout-count tracking on M365:\n```bash\n# Run every 30 min during M365 spray\nLOCK_COUNT=$(grep -c '\"AADSTS50053\"' engagement_log\u002Fo365_results.jsonl)\necho \"$(date -u +%FT%TZ) lockout_count $LOCK_COUNT\" >> lockout_history.log\n# Diff first vs last to surface delta\n```\n\n---\n\n## The \"single signal recanted\" rule\n\nIf a confirmed-vulnerable finding stops reproducing:\n\n1. **DO NOT delete the original PoC.** Preserve restricted\u002Fredacted evidence according to agreed retention; do not retain sensitive payloads indefinitely.\n2. **Capture the new state in detail.** What's the recheck response? What's different?\n3. Reassess original evidence and authorized scope. Stop or request owner correlation; do not require additional attack vectors when limits or uncertainty call for stopping.\n4. If no reproduction is available, report exactly what was confirmed atT0 and what changed; keep mitigation cause\u002Fdepth unknown until independently established.\n5. **Both states go in the report.** The original finding + the IR observation.\n\nThis is the discipline that distinguishes professional red team from \"hobbyist scanning\". Your client wants the timeline of vulnerability + mitigation, not just the static state.\n\n---\n\n## Owner Correlation Before Causal Claims\n\nThe following narrative applies only when original impact and owner detection\u002Fchange events have been independently confirmed. A before\u002Fafter response difference alone cannot establish any of these claims.\n\n## Why confirmed evidence can be useful\n\nWhen you tell a client \"I confirmed SQLi at 14:24, you deployed a mitigation by 14:55, here's the original PoC and here's why you should still verify the fix is in code\":\n\n- **Confirmed the vulnerability existed** (auditor-grade evidence)\n- **Confirmed the mitigation was deployed** (positive ops finding for the SOC)\n- **Identified the depth question** (WAF vs code — different remediation cost)\n- **Demonstrated red-team value** (you proved both the bug AND the IR responsiveness)\n\nThis is a more valuable deliverable than \"I confirmed SQLi\" alone, because it captures the engagement's full operational picture.\n\n---\n\n## Anti-patterns to avoid\n\n- **\"Recheck failed → false positive.\"** A failed recheck has multiple causes. Investigate and reassess the original evidence.\n- **\"It's no longer vulnerable, drop the finding.\"** No. It WAS vulnerable. The finding stays. Add a \"current state: mitigated\" annotation.\n- **\"They patched it, mission accomplished.\"** No. WAF rule != code fix. Verify the depth.\n- **\"Don't tell the client we observed their patch.\"** Yes, do. It's a positive finding about their IR.\n- **\"Don't include the locked accounts list — they'll think we caused it.\"** No actor attribution follows from a response code. Share minimized account evidence only with the authorized SOC and state uncertainty.\n\n---\n\n## Bridge to neighboring skills\n\n- `redteam-mindset` — broader discipline framework; this skill is a specific application\n- `m365-entra-attack` — specific case for M365 \u002F Smart Lockout differential\n- `evidence-hygiene` — how to capture and redact PoC evidence properly\n- `report-writing` — finding template for IR observations\n- `bb-methodology` — note that this skill is INAPPROPRIATE for bug bounty (no real-time IR there)\n\n---\n\n## One-line summary\n\n**Capture both states, distinguish observation from causation, and retain only evidence-supported findings.**\n\n---\n\n## Related Skills & Chains\n\n- **`redteam-mindset`** — This skill is a specific application of the broader red-team discipline. Engagement flow: `redteam-mindset` loaded at engagement start → baseline-capture habit built in → when response patterns shift mid-test, `mid-engagement-ir-detection` activates to capture the SOC-patch state as a NEW finding (defensive-action observed = client capability metric, not \"the bug got fixed so we lose the finding\").\n- **`evidence-hygiene`** — Mid-engagement IR detection produces TWO states (pre-patch and post-patch); both need disciplined evidence capture or the second finding can't be defended. Engagement flow: baseline screenshots + timestamped request\u002Fresponse dumps at session start → response shift detected → second capture set with explicit timestamp delta → both packaged together.\n- **`m365-entra-attack`** — The single richest source of mid-engagement IR signal in modern engagements. Engagement flow: M365 spray triggers AADSTS50053 lockout → baseline lockout policy captured → if lockout window changes mid-test (e.g., from 60min to 24hr) → `mid-engagement-ir-detection` captures the policy change as a finding (\"CA policy hardened mid-engagement; defensive response measured\").\n- **`enterprise-vpn-attack`** + **`vmware-vcenter-attack`** — Critical-infrastructure CVE exploitation is the highest-noise activity; expect SOC to patch within hours. Engagement flow: confirmed VPN\u002FvCenter CVE → baseline capture BEFORE exploitation attempt → if appliance updates mid-test, capture as defensive-action finding → report both the original CVE AND the IR-response.\n- **`redteam-report-template`** — IR-observation findings get their own Subject in the deliverable, framed differently from technical-vuln findings. Engagement flow: `mid-engagement-ir-detection` captures behavior-change event → `triage-validation` 7-Question Gate (specifically: \"is the behavior-change attributable to my activity?\") → `redteam-report-template` packages as a \"client capability observation\" with explicit timeline and detection-latency metric.\n\n## Limitations\n\n- Process guidance only; it does not authorize probing or exploitation — those steps need their own authorized skill and confirmation gate.\n- Docs-only import: upstream templates, commands, and research assets are not bundled.\n\n### Example\n\n```markdown\nApply this skill's checklist to the current engagement notes and report gaps.\n```\n\n> Adapted from [elementalsouls\u002FClaude-BugHunter](https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter) (MIT); frontmatter, When to Use\u002FLimitations, and safety boundaries added for upstream compliance. Docs-only import: executable helpers, commands, engine, and research assets not bundled.\n","> **⚠️ AUTHORIZED USE ONLY**\n> This skill is for educational purposes or authorized security assessments only.\n> You must have explicit, written permission from the system owner before using this tool.\n> Misuse of this tool is illegal and strictly prohibited.\n\n## Mandatory confirmation gate\n\nBefore 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\u002Flockouts trigger the engagement stop\u002Fcontact procedure, not automatic evasion. Bound requests, account attempts, timing and cost; never test unrelated accounts or change tenant policies.\n\n## When to use this skill\n\nTrigger when:\n- Running active testing against a target with active SOC monitoring\n- A confirmed-vulnerable finding stops reproducing on recheck\n- Baseline timing shifts unexpectedly (3× slower, sudden errors, new headers)\n- Response sizes change between test windows\n- New WAF cookies or headers appear that weren't there at session start\n- Lockout \u002F error rates change between test windows (especially LOCKED count for credential attacks)\n- Engagement is \"assume breach\" or \"white box\" — client knows you're testing\n\nDO NOT use for:\n- Any program whose authorization excludes the proposed observation\u002Fprobe; bug-bounty programs can also have active SOC monitoring\n- Pure recon (no state-change happening)\n- One-off vulnerability scanning (no temporal dimension)\n\n---\n\n## The core insight\n\nIn 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:\n\n1. **Themselves valuable findings** (positive operational observations about IR responsiveness)\n2. **Contextual evidence** (a response change alone proves neither a patch nor the original vulnerability)\n3. **Classification signals** (WAF rule deployment vs code fix — different remediation depth)\n\nAnti-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.\n\n---\n\n## The discipline — capture before, diff after\n\n### Before any active test:\n\n```text\n# Pseudocode only; placeholders are not runnable Python.\n# Capture pre-test fingerprint of the target\nfingerprint = {\n    \"ts_pre\": time.time(),\n    \"ip_seen\": \"\u003Coperator-src-ip>\",\n    \"baseline_response_time_ms\": \u003Cmeasure>,\n    \"baseline_response_size_bytes\": \u003Cmeasure>,\n    \"response_headers\": \u003Ccapture set>,\n    \"waf_cookies\": \u003Clist>,\n    \"lockout_count_in_state\": \u003Ccount from o365_attempts.json>,\n}\n```\n\nPersist to `engagement_log\u002Ffingerprint_pre.json`.\n\n### During the test:\n\nLog every test result with full context (timestamp, IP, payload, response code, response size, response time, headers if relevant) to JSONL append-only.\n\n### After the test session OR on first failed-recheck:\n\n```text\n# Pseudocode only.\nfingerprint_post = same structure\ndelta = {\n    \"baseline_time_change_ms\": post.time - pre.time,\n    \"baseline_size_change_bytes\": post.size - pre.size,\n    \"new_headers_appeared\": post.headers - pre.headers,\n    \"new_waf_cookies\": post.cookies - pre.cookies,\n    \"new_lockouts\": post.locked_count - pre.locked_count,\n}\n```\n\nIf a delta is significant, investigate alternative explanations and update confidence; neither retain nor retract a finding automatically.\n\n---\n\n## The three primary IR observations\n\n### Observation 1 — Mid-engagement WAF rule deployment\n\n**Symptoms:**\n- Original payloads return identical response → no signal at all on recheck\n- Body size identical to baseline (login page reflection)\n- Timing reverts to baseline regardless of payload\n- New cookie or header in responses (e.g., `cf-bm`, `__cf_bm`, `awselb`)\n- Specific keyword in URL\u002Fbody now triggers different response code (403, 406, 429)\n\n**Confirmation:** retry with WAF-evasion variants:\n- URL-encode the payload differently (`%27` vs `%5cu0027`)\n- Change request method (POST → PUT, GET → POST)\n- Different content-type (form-urlencoded → multipart)\n- Slower pace (5s → 60s between requests)\n- Mixed-case keywords (`SLEEP` → `SlEeP`)\n\nIf WAF-evasion variants restore the signal, the mitigation is at the WAF layer (bypassable).\n\nA failed variant does not identify a code fix. WAF\u002Forigin\u002Fcache\u002Fsession\u002Fbackend changes require owner logs, configuration or code evidence to distinguish.\n\n**Finding template:**\n```\nSubject: Mid-engagement mitigation deployed for \u003Cvulnerability X>\nObservation: At engagement timestamp T0, vulnerability \u003CX> on \u003Cendpoint> was\nconfirmed via \u003CPoC>. At T0+\u003Cminutes>, recheck via the original payload no longer\nreproduces the timing\u002Ferror\u002Fsize differential. \u003CWAF-evasion variant> [does\u002Fdoes\nnot] restore the signal.\n\nDescription: This pattern is consistent with the client SOC observing engagement\ntraffic and deploying a mitigation in real time. Mitigation depth assessment:\n[observed bypass under stated conditions] vs [layer\u002Fdepth unknown pending owner evidence].\n\nImpact (positive): Only claim SOC detection\u002Fmitigation timing when owner telemetry confirms the detection and change events; response timing alone is not that evidence.\n\nImpact (caveat): The original vulnerability did exist and was exploitable for at\nleast the engagement window before mitigation. If the mitigation is at the WAF\nlayer only, the underlying code-level flaw remains exploitable via alternative\npayloads.\n\nRecommendation:\n1. Verify the mitigation is in code (parameterized queries, input sanitization),\n   not just at the WAF layer.\n2. Audit the codebase for the same root cause across sister applications.\n3. (Positive) Document the IR responsiveness as a capability metric.\n```\n\n### Observation 2 — Possible concurrent activity or authentication policy change\n\n`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\u002Funfamiliar-location counters, legitimate users, federated\u002Fpass-through behavior and the engagement itself can contribute. One logged attempt per user does **not** mathematically exclude tester contribution or prove an external actor.\n\nStop 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\u002FIPs, 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.\n\nReport 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.\n\nExample report:\n```text\nObservation: N responses contained50053 during [UTC window] from approved sourceX.\nKnown: owner logs identify [documented failure reason]; tester journal covers [scope].\nUnknown: attribution and whether the response change resulted from a mitigation.\nNext: authorized SOC correlates existing identity\u002Fnetwork telemetry and decides response.\n```\n\n### Observation 3 — Detection-induced rate limiting \u002F IP blocks\n\n**Symptoms:**\n- Specific IP starts returning 403 \u002F 429 \u002F 451 after a window of normal responses\n- Specific IP starts seeing dramatically slower responses (3x+ baseline)\n- TLS handshake fails or RST mid-connection\n- DNS suddenly returns NXDOMAIN for hosts that resolved before\n- Some hosts work from one IP but not another\n\n**Confirmation:**\n- Compare already authorized source observations; do not rotate around a block unless the engagement owner explicitly approves that exact action\n- Compare DNS answers\u002FTTL with resolver\u002Fcache\u002Frouting controls; a TTL change alone does not prove mitigation\n- Check `Server:`, `Via:`, `CF-Cache-Status:` headers for CDN-introduced limits\n\n**Finding template (operational note, usually low\u002Finfo severity):**\n```\nSubject: Engagement traffic detected — IP \u003CX> rate-limited at \u003Ctimestamp>\n\nObservation: After ~\u003CN> requests in \u003Cwindow> from IP \u003CX>, target \u003Chostname>\nbegan returning \u003Ccode> for all subsequent requests. Rotation to IP \u003CY>\nrestored normal responses.\n\nDescription: Active anti-automation control at the perimeter (CDN\u002FWAF\u002Forigin).\n\nImpact (positive): Volumetric anti-automation is functional.\n\nImpact (caveat): A permitted alternate-source observation may show a scope limitation; it does not establish universal bypass, attacker cost or complete control failure.\n```\n\n---\n\n## State diff — the key technique\n\nMaintain three pieces of state:\n\n### 1. `engagement_log\u002Fbaseline.json` — captured at session start\n\n```json\n{\n  \"ts\": \"2026-05-08T13:00:00\",\n  \"source_ip\": \"\u003Coperator-src-ip>\",\n  \"targets\": {\n    \"https:\u002F\u002Ftarget.example.com\u002Flogin\": {\n      \"baseline_response_time_ms\": 584,\n      \"baseline_response_size_bytes\": 11966,\n      \"headers_seen\": [\"Server: Apache\", \"X-Powered-By: PHP\u002F8.0.26\"],\n      \"set_cookie_names\": [\"PHPSESSID\"]\n    }\n  },\n  \"m365\": {\n    \"lockout_count\": 247,\n    \"valid_creds_count\": 0\n  }\n}\n```\n\n### 2. `engagement_log\u002Fjournal.jsonl` — append-only test log\n\nEvery test logs:\n```jsonl\n{\"ts\":\"...\",\"ip\":\"...\",\"tool\":\"...\",\"target\":\"...\",\"payload\":\"...\",\"resp_code\":...,\"resp_size\":...,\"resp_ms\":...,\"verdict\":\"...\",\"notes\":\"...\"}\n```\n\n### 3. `engagement_log\u002Fstate_changes.jsonl` — observed deltas\n\nWhen a state change is detected, append:\n```jsonl\n{\"ts_observed\":\"2026-05-08T14:30:00\",\"change_type\":\"baseline_time_shift\",\"target\":\"https:\u002F\u002F\u003Cemployee-app-host>\u002F\u003Capp>\u002Flogin.php\",\"baseline_pre_ms\":24412,\"baseline_post_ms\":90403,\"interpretation\":\"likely WAF rule deployed\",\"actions_taken\":[\"tested WAF-evasion variants — no signal restoration\",\"documented as IR-mitigation finding\"]}\n```\n\nThis third file is your finding evidence. Every entry is a candidate finding.\n\n---\n\n## Tooling — automated state-change detection\n\n```bash\n# Bash watcher — runs every 5 min during engagement, alerts on shifts\n\ncd \"$ENGAGEMENT_DIR\"\n\n# Re-measure baseline timing on key targets\nfor target in \"$@\"; do\n  ms=$(curl -sS -o \u002Fdev\u002Fnull -w \"%{time_total}\" \"$target\" --max-time 30)\n  ms_int=$(echo \"$ms * 1000\" | bc | cut -d. -f1)\n  echo \"$(date -u +%FT%TZ) $target $ms_int\" >> baseline_history.log\ndone\n\n# Diff against pre-session baseline\npython3 - \u003C\u003C 'PY'\nimport json, time\nbaseline = json.load(open(\"engagement_log\u002Fbaseline.json\"))\nfor line in open(\"baseline_history.log\"):\n    parts = line.strip().split()\n    ts, target, ms = parts[0], parts[1], int(parts[2])\n    if target in baseline[\"targets\"]:\n        pre = baseline[\"targets\"][target][\"baseline_response_time_ms\"]\n        if abs(ms - pre) > pre * 0.5:  # >50% shift\n            print(f\"ALERT {ts} {target} time {pre} -> {ms}\")\nPY\n```\n\nFor lockout-count tracking on M365:\n```bash\n# Run every 30 min during M365 spray\nLOCK_COUNT=$(grep -c '\"AADSTS50053\"' engagement_log\u002Fo365_results.jsonl)\necho \"$(date -u +%FT%TZ) lockout_count $LOCK_COUNT\" >> lockout_history.log\n# Diff first vs last to surface delta\n```\n\n---\n\n## The \"single signal recanted\" rule\n\nIf a confirmed-vulnerable finding stops reproducing:\n\n1. **DO NOT delete the original PoC.** Preserve restricted\u002Fredacted evidence according to agreed retention; do not retain sensitive payloads indefinitely.\n2. **Capture the new state in detail.** What's the recheck response? What's different?\n3. Reassess original evidence and authorized scope. Stop or request owner correlation; do not require additional attack vectors when limits or uncertainty call for stopping.\n4. If no reproduction is available, report exactly what was confirmed atT0 and what changed; keep mitigation cause\u002Fdepth unknown until independently established.\n5. **Both states go in the report.** The original finding + the IR observation.\n\nThis is the discipline that distinguishes professional red team from \"hobbyist scanning\". Your client wants the timeline of vulnerability + mitigation, not just the static state.\n\n---\n\n## Owner Correlation Before Causal Claims\n\nThe following narrative applies only when original impact and owner detection\u002Fchange events have been independently confirmed. A before\u002Fafter response difference alone cannot establish any of these claims.\n\n## Why confirmed evidence can be useful\n\nWhen you tell a client \"I confirmed SQLi at 14:24, you deployed a mitigation by 14:55, here's the original PoC and here's why you should still verify the fix is in code\":\n\n- **Confirmed the vulnerability existed** (auditor-grade evidence)\n- **Confirmed the mitigation was deployed** (positive ops finding for the SOC)\n- **Identified the depth question** (WAF vs code — different remediation cost)\n- **Demonstrated red-team value** (you proved both the bug AND the IR responsiveness)\n\nThis is a more valuable deliverable than \"I confirmed SQLi\" alone, because it captures the engagement's full operational picture.\n\n---\n\n## Anti-patterns to avoid\n\n- **\"Recheck failed → false positive.\"** A failed recheck has multiple causes. Investigate and reassess the original evidence.\n- **\"It's no longer vulnerable, drop the finding.\"** No. It WAS vulnerable. The finding stays. Add a \"current state: mitigated\" annotation.\n- **\"They patched it, mission accomplished.\"** No. WAF rule != code fix. Verify the depth.\n- **\"Don't tell the client we observed their patch.\"** Yes, do. It's a positive finding about their IR.\n- **\"Don't include the locked accounts list — they'll think we caused it.\"** No actor attribution follows from a response code. Share minimized account evidence only with the authorized SOC and state uncertainty.\n\n---\n\n## Bridge to neighboring skills\n\n- `redteam-mindset` — broader discipline framework; this skill is a specific application\n- `m365-entra-attack` — specific case for M365 \u002F Smart Lockout differential\n- `evidence-hygiene` — how to capture and redact PoC evidence properly\n- `report-writing` — finding template for IR observations\n- `bb-methodology` — note that this skill is INAPPROPRIATE for bug bounty (no real-time IR there)\n\n---\n\n## One-line summary\n\n**Capture both states, distinguish observation from causation, and retain only evidence-supported findings.**\n\n---\n\n## Related Skills & Chains\n\n- **`redteam-mindset`** — This skill is a specific application of the broader red-team discipline. Engagement flow: `redteam-mindset` loaded at engagement start → baseline-capture habit built in → when response patterns shift mid-test, `mid-engagement-ir-detection` activates to capture the SOC-patch state as a NEW finding (defensive-action observed = client capability metric, not \"the bug got fixed so we lose the finding\").\n- **`evidence-hygiene`** — Mid-engagement IR detection produces TWO states (pre-patch and post-patch); both need disciplined evidence capture or the second finding can't be defended. Engagement flow: baseline screenshots + timestamped request\u002Fresponse dumps at session start → response shift detected → second capture set with explicit timestamp delta → both packaged together.\n- **`m365-entra-attack`** — The single richest source of mid-engagement IR signal in modern engagements. Engagement flow: M365 spray triggers AADSTS50053 lockout → baseline lockout policy captured → if lockout window changes mid-test (e.g., from 60min to 24hr) → `mid-engagement-ir-detection` captures the policy change as a finding (\"CA policy hardened mid-engagement; defensive response measured\").\n- **`enterprise-vpn-attack`** + **`vmware-vcenter-attack`** — Critical-infrastructure CVE exploitation is the highest-noise activity; expect SOC to patch within hours. Engagement flow: confirmed VPN\u002FvCenter CVE → baseline capture BEFORE exploitation attempt → if appliance updates mid-test, capture as defensive-action finding → report both the original CVE AND the IR-response.\n- **`redteam-report-template`** — IR-observation findings get their own Subject in the deliverable, framed differently from technical-vuln findings. Engagement flow: `mid-engagement-ir-detection` captures behavior-change event → `triage-validation` 7-Question Gate (specifically: \"is the behavior-change attributable to my activity?\") → `redteam-report-template` packages as a \"client capability observation\" with explicit timeline and detection-latency metric.\n\n## Limitations\n\n- Process guidance only; it does not authorize probing or exploitation — those steps need their own authorized skill and confirmation gate.\n- Docs-only import: upstream templates, commands, and research assets are not bundled.\n\n### Example\n\n```markdown\nApply this skill's checklist to the current engagement notes and report gaps.\n```\n\n> Adapted from [elementalsouls\u002FClaude-BugHunter](https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter) (MIT); frontmatter, When to Use\u002FLimitations, and safety boundaries added for upstream compliance. Docs-only import: executable helpers, commands, engine, and research assets not bundled.\n",{"name":5,"risk":27,"source":46,"license":14,"sources":47,"category":40,"date_added":48,"description":7,"source_repo":49,"source_type":30,"report_count":50,"compatibility":51,"license_source":52},"https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter","authorized-engagement","2026-09-20","elementalsouls\u002FClaude-BugHunter",1,"Process guidance; no tooling required. Docs-only; upstream templates not bundled.","https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter\u002Fblob\u002Fmain\u002FLICENSE","7bf2279c8a65758319526a721d5c4b75683aec9c","skills\u002Fantigravity-mid-engagement-ir-detection",3,"https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections","https:\u002F\u002Fgithub.com\u002Fboisenoise","2026-11-14 14:18:11",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add boisenoise\u002Fskills-collections --skill mid-engagement-ir-detection",{"tool":65,"command":66},"bunx","bunx skills add boisenoise\u002Fskills-collections --skill mid-engagement-ir-detection",{"tool":68,"command":69},"pnpm","pnpm dlx skills add boisenoise\u002Fskills-collections --skill mid-engagement-ir-detection","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-mid-engagement-ir-detection\u002FSKILL.md",true,[],[74,102,127,151,170,193],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":78,"licenseFileUrl":79,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":41},"01M6WNH92BHVFXHGPDZCPJ0AG0","web-access","Use Treg for public web or platform data only when existing search, browser and connected tools cannot cover the task, with explicit cost and data boundaries.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-web-access\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-web-access\u002FSKILL.md",[],[83,84,85,86,87,88,89,90,91,92,93,32,94,95,96,97,98,99,100,101,21],"web","access","web access","official","development","browser","search","data","Tools","read","fetch","youtube","free tools","platform","critical","free","cover","normal","when",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":78,"licenseFileUrl":106,"sourceHtmlUrl":107,"categories":108,"keywords":114,"publishedAt":41},"01M6WNF9XAYAB2CZDDJBAKNM93","treg","Use the Treg CLI or MCP catalog to discover, price and call authorized external tools with team-scoped credentials and a user-approved budget.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-treg\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-treg\u002FSKILL.md",[109],{"categoryNo":110,"categoryName":111,"taxonomyType":112,"taxonomyTypeDesc":113},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[104,115,116,22,86,87,38,91,117,118,34,119,120,121,122,97,123,124,125,126,21],"MCP","cli","Budget","credentials","catalog","use","call","discover","external tools","with","scoped","blob",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":78,"licenseFileUrl":131,"sourceHtmlUrl":132,"categories":133,"keywords":139,"publishedAt":41},"01M6WN93MEAZ4E41DYAHJRPHQT","recruit","Turn a job description into an evidence-linked candidate shortlist through Treg, with job-related ranking and optional authorized business contact enrichment.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-recruit\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-recruit\u002FSKILL.md",[134],{"categoryNo":135,"categoryName":136,"taxonomyType":137,"taxonomyTypeDesc":138},"01JBSEEDCAT000000000000038","人力资源","PROFESSION","适用职业",[129,22,86,38,37,140,141,142,143,144,97,145,146,147,124,24,148,149,150,126,104,21],"email","enrichment","business","evidence","phone","ranking","post","job description","person","candidate","reason",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":78,"licenseFileUrl":155,"sourceHtmlUrl":156,"categories":157,"keywords":158,"publishedAt":41},"01M6WN8R5RXSMHM9B4D9FAFX42","rea-growth","Analyze a company’s public growth and content through Treg, distinguish observations from hypotheses, and produce an evidence-linked playbook within an approved budget.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-rea-growth\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-rea-growth\u002FSKILL.md",[],[159,160,161,22,86,38,162,163,37,164,117,165,166,167,143,97,168,169,126,104,21],"growth","rea","rea growth","produce","content","playbook","marketing","analyze","public","observations","company",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":78,"licenseFileUrl":174,"sourceHtmlUrl":175,"categories":176,"keywords":177,"publishedAt":41},"01M6WN2EVE3RQRGWAKBT4S7YT2","make-ugc","Create original AI UGC-style product videos through Treg: research hooks, approve a licensed presenter and voice, generate clips, add captions and report costs.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-make-ugc\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-make-ugc\u002FSKILL.md",[],[178,179,22,180,86,181,38,182,183,184,185,186,97,187,188,189,190,191,192,126],"make","make ugc","research","create","Video","Captions","ads","short","hooks","head","style","niche","trending","talking-head","approve",{"skillNo":194,"name":195,"nameZh":6,"description":196,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":78,"licenseFileUrl":197,"sourceHtmlUrl":198,"categories":199,"keywords":200,"publishedAt":41},"01M6WN10ARAA63Y8K1YNGXJ2RM","lead-signals","Find and qualify public buying signals through Treg, rank fitting business accounts and optionally enrich authorized business contact information.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-lead-signals\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-lead-signals\u002FSKILL.md",[],[201,202,203,22,86,38,204,205,142,206,207,97,208,209,210,211,212,23,213,126],"signals","lead","lead signals","how","find","ready","as","how to","qualify","people","information","enrich","funding"]