mid-engagement-ir-detection

Detects SOC patches, attacker activity, and security-state changes during red-team engagements.

7|4|Updated Jun 22, 2026
One-click install
npx skills add https://github.com/dbx0/skills --skill mid-engagement-ir-detection-dbx0
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: mid-engagement-ir-detection
Source: https://github.com/dbx0/skills/tree/main/skills/methodology/workflows/mid-engagement-ir-detection
Command: npx skills add https://github.com/dbx0/skills --skill mid-engagement-ir-detection-dbx0

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? During an authorized red-team engagement, the target's security state changes in response to your testing — a confirmed vulnerability stops reproducing, lockout counts spike, or new WAF headers appear. Without a disciplined method, testers misread these shifts as false positives and lose both the original finding and the valuable observation about the client's incident response capability. ## Core Features & Use Cases - Baseline fingerprinting and state diffing: Capture pre-test fingerprints (timing, response size, headers, cookies, lockout counts) and diff them against post-test state to surface meaningful changes. - Three IR observation patterns: Detect mid-engagement WAF rule deployment, active concurrent external attackers (e.g., AADSTS50053 Smart Lockout accumulation during M365 testing), and detection-induced rate limiting or IP blocks. - Finding templates and evidence discipline: Convert each observed state change into a reportable finding with pre/post PoC evidence, mitigation-depth assessment (WAF vs code fix), and client-facing recommendations. - Use Case: You confirm a SQL injection at 14:24, and by 14:55 the payload no longer reproduces. Instead of retracting the finding, you capture the new state, test WAF-evasion variants, and report both the original vulnerability and the client's ~30-minute mitigation response as a positive IR capability metric. ## Quick Start Ask the agent to capture a pre-test baseline fingerprint of the target and set up state-change monitoring for the engagement.

Frequently Asked Questions about mid-engagement-ir-detection

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
What should I do when a confirmed vulnerability stops reproducing during a pentest?▼

Do not retract the finding. Capture the new response state in detail, try at least three alternative vectors such as WAF-evasion payload variants, and document the result as vulnerability confirmed at T0 with mitigation observed at T0 plus delta. Both states belong in the report.

How do I detect an active password spray attack during M365 testing?▼

Track AADSTS50053 Smart Lockout responses during ROPC validation. With a one-attempt-per-user discipline you cannot mathematically cause lockouts, so new locks accumulating during your session indicate an external attacker. Alphabetical clustering of locked accounts confirms a username-list-driven spray.

How can I tell if a fix was deployed at the WAF layer or in code?▼

Retry the original payload with WAF-evasion variants: alternate URL encoding, different HTTP methods, changed content types, slower pacing, and mixed-case keywords. If variants restore the signal, the mitigation is at the WAF layer and bypassable; if none work, the fix is likely in code.

Is this methodology appropriate for bug bounty hunting?▼

No. The skill explicitly excludes bug bounty because the client does not know you are testing and there is no real-time incident response to observe. It also does not apply to pure recon or one-off vulnerability scanning where no temporal state change occurs.

What baseline data should I capture before active testing?▼

Capture source IP, baseline response time and size per target, full response header sets, WAF cookie names, and current lockout counts for identity systems. Persist this as a fingerprint JSON file and log every subsequent test to an append-only JSONL journal for later diffing.