Help us improve
Share bugs, ideas, or general feedback.
From cybersecurity-skills
Plans, scopes, and executes authorized red-team engagements with ATT&CK emulation, rules of engagement, and blue-team deconfliction.
npx claudepluginhub briiirussell/cybersecurity-skills --plugin cybersecurity-skillsHow this skill is triggered — by the user, by Claude, or both
Slash command
/cybersecurity-skills:red-team-engagementThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill is for **planning and executing an authorized red-team engagement against systems and an organization that has explicitly contracted for it**. It is distinct from a penetration test (technique-focused; see `web-pentest`) and from threat hunting (defensive; see `threat-hunting`). A red-team engagement is multi-week, objective-based, often assumed-breach, and explicitly tries to test t...
Defines scope, objectives, rules of engagement, threat model selection, and operational timelines for authorized red team operations before offensive testing begins.
Defines scope, objectives, rules of engagement, threat model selection, and operational timelines for authorized red team operations before offensive testing begins.
Plans red team engagements by defining scope, objectives, rules of engagement, threat models, and timelines before offensive security testing.
Share bugs, ideas, or general feedback.
This skill is for planning and executing an authorized red-team engagement against systems and an organization that has explicitly contracted for it. It is distinct from a penetration test (technique-focused; see web-pentest) and from threat hunting (defensive; see threat-hunting). A red-team engagement is multi-week, objective-based, often assumed-breach, and explicitly tries to test the blue team's detect-and-respond capability — not just to find vulnerabilities.
This is the most dual-use skill in this catalog. The skill refuses to help conduct unauthorized adversary simulation, regardless of how the request is framed. The authorization check below is enforced strictly.
Before working with this skill at all, confirm:
If any of the above is missing or unclear, stop. Ask the user to confirm. Do not proceed with planning, technique selection, or any execution work.
If the user describes a target that does not appear to belong to them or to a contracted client, refuse — this is not a misunderstanding to be cleared up by adding "for educational purposes" or "in a CTF." The skill refuses to help simulate an attack on systems whose authorization is not present.
Red-team engagements exist to test the security program's response capability — not just to find vulnerabilities. A good red-team engagement answers questions like:
Red-team engagements are not for:
If the goal is "find vulnerabilities," use web-pentest or the relevant audit skill. If the goal is "test whether our detection and response actually works," this is the right skill.
| Model | Description | When to use |
|---|---|---|
| External red team | Engagement starts from outside the perimeter; no initial foothold | Mature programs testing the full attack chain end-to-end |
| Assumed breach | Engagement starts from a granted initial foothold (workstation, credentials, low-privilege account) | When the perimeter is well-tested already and the question is post-compromise containment |
| Purple team | Red and blue work side-by-side; red executes technique, blue verifies detection live | Early in detection-engineering maturity; high learning rate |
Assumed-breach is the most common modern engagement model — the value-per-week is highest because almost every real breach starts with the perimeter already past. Pure external red teams are valuable but expensive in calendar time.
Scoping with the client / sponsor:
Documentation deliverables before kickoff:
For external engagements, leverage recon and osint-recon. For assumed-breach engagements, this phase is internal recon from the granted starting position.
The output is a target map — the systems, accounts, and pivots the team will work through to reach the objective.
Following an ATT&CK emulation plan tailored to the engagement.
Emulation plans are published playbooks of how specific threat actors operate. Use them as starting points, not scripts:
attack.mitre.org/resources/adversary-emulation-plans/The engagement progresses through the kill chain — initial access (for external) or post-foothold execution (for assumed breach), persistence, privilege escalation, defense evasion, credential access, discovery, lateral movement, collection, exfiltration (simulated — see boundaries) — toward the named objective.
Operational notes:
The most under-invested phase, and the one that determines whether the engagement actually improves defenses.
Same-day debrief (within 24 hours of engagement end):
Full written report (within 2-4 weeks):
# Red Team Engagement Report
## Engagement: [name]
## Sponsor: [executive sponsor]
## Engagement window: [start - end]
## Engagement type: External / Assumed Breach / Purple
## Authors: [red team leads]
### Executive summary
[3-5 paragraphs — were objectives achieved, what the blue team's detection-and-response posture looks like, top 3-5 systemic recommendations]
### Engagement timeline
[Red-team actions with timestamps and ATT&CK technique IDs]
### Blue-team observations
[For each red-team action, what the blue team saw, when, and how they responded — or did not]
### Detection coverage analysis
[Map of techniques used vs detections that did / should have fired]
### Findings
| ID | Severity | Category | Description |
|----|----------|----------|-------------|
(Categories: Detection gap, Response gap, Privileged-access exposure, Lateral-movement enabler, Crown-jewel access path, Compensating control reliance)
### Per-finding detail
[Technique used, what was achieved, what the blue team did / didn't see, recommended remediation]
### Recommendations
[Prioritized — usually 5-10 items mapping to specific systemic improvements, not point fixes]
### What the engagement did NOT cover
[Honesty about what was out of scope and where coverage gaps remain]
Recommendations from the report become work items. The red team's value compounds when:
siem-detection, response runbooks updated per soc-operations, control improvements per the audit skills)breach-patterns and incident-triage runbooksA red team that finds the same problem twice is a budget that was wasted the second time.
The RoE is the contract. It must be specific.
| Section | What it specifies |
|---|---|
| Authorization | Who authorized this engagement, when, with what authority |
| Scope — in | Specific systems, accounts, environments, applications by name |
| Scope — out | Explicitly excluded — third parties, regulated data, named accounts, specific production systems |
| Techniques in scope | Categories of technique permitted (e.g., "credential capture in named test environments") |
| Techniques out of scope | Categories of technique not permitted (e.g., "no destructive techniques," "no social engineering of named executives," "no exploitation of vendor systems") |
| Time window | Start date, end date, blackout periods (e.g., "no engagement activity during quarterly close") |
| Data handling | What happens to data discovered during the engagement — destruction timelines, encryption requirements, exfiltration markers |
| Reporting cadence | Daily / weekly / end-of-engagement |
| Deconfliction contact | Single named individual + backup + 24/7 contact path |
| Stop conditions | When the engagement pauses or aborts — production outage caused, regulatory event triggered, unintended scope crossed |
| Get-out-of-jail letter | Format, distribution, contact for verification |
This is the most consequential boundaries section in this catalog. Read it.
attack.mitre.orgattack.mitre.org/resources/adversary-emulation-plans/github.com/redcanaryco/atomic-red-teamctid.mitre.org — open-source emulation content