mid-engagement-ir-detection

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

1|Updated Aug 21, 2026
One-click install
npx skills add https://github.com/marcboggs/BMAD-AppSec-Orchestrator --skill mid-engagement-ir-detection-marcboggs
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: mid-engagement-ir-detection
Source: https://github.com/marcboggs/BMAD-AppSec-Orchestrator/tree/main/.claude/skills/mid-engagement-ir-detection
Command: npx skills add https://github.com/marcboggs/BMAD-AppSec-Orchestrator --skill mid-engagement-ir-detection-marcboggs

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 — SOC teams deploy WAF rules, patch confirmed vulnerabilities, and rate-limit your IPs. Without a disciplined methodology, testers misinterpret these changes as false positives, lose valid findings, and miss the opportunity to report the client's incident-response capability as a deliverable. ## Core Features & Use Cases - Baseline Fingerprinting: Capture pre-test response timing, sizes, headers, cookies, and lockout counts, then diff against post-test state to surface significant deltas. - Three IR Observation Patterns: Detect mid-engagement WAF rule deployment, concurrent external password-spray attackers (via AADSTS50053 Smart Lockout math), and detection-induced rate limiting or IP blocks. - Finding Templates: Convert each observed state change into a structured report finding covering the original vulnerability, the mitigation timeline, and mitigation depth (WAF-layer vs in-code fix). - Use Case: You confirm a SQL injection at 14:24, but at 14:55 the payload stops reproducing. Instead of retracting the finding, you test WAF-evasion variants, document the mitigation deployment, and report both the original vulnerability and the client's 31-minute detection-to-mitigation response. ## Quick Start Ask the agent to capture a pre-test baseline fingerprint of the target endpoints and monitor for response timing, header, or lockout-count shifts during the engagement, converting any detected changes into findings.

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 — the original PoC with timestamps remains valid evidence. Capture the new response state in detail, try at least three WAF-evasion variants (encoding, method, content-type changes), and document the result as a vulnerability confirmed at T0 with mitigation observed at T0 plus delta.

How do I tell if a WAF rule was deployed versus a code fix during testing?▼

Retry the 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, mitigation is at the WAF layer and bypassable; if none work, the fix is likely in code.

How can I detect an active password spray attack during an M365 engagement?▼

Track AADSTS50053 Smart Lockout responses. With a strict one-attempt-per-user discipline you cannot mathematically cause lockouts, so every lockout observed was caused by someone else. Diff lockout counts before and after your session and check for alphabetical clustering of locked accounts.

When should this mid-engagement IR detection methodology not be used?▼

Do not use it for bug bounty work, since the client does not know you are testing and there is no real-time IR to observe. It also does not apply to pure reconnaissance or one-off vulnerability scans where no temporal state-change dimension exists.

What baseline data should be captured before starting active testing?▼

Capture source IP, baseline response time in milliseconds, response size in bytes, full response headers, WAF cookie names, and current lockout counts for identity targets. Persist this as a fingerprint JSON file and log every subsequent test to an append-only JSONL journal for later diffing.