/red-team-engagement

name: red-team-engagement
description: "Plan, scope, and execute an authorized red-team engagement — distinct from a penetration test. Covers engagement methodology, assumed-breach scenarios, ATT&CK emulation plans, rules of engagement, deconfliction with the blue team, post-engagement debriefs, and the program-level work that makes red teams actually improve defenses. Use when the user mentions 'red team,' 'red team engagement,' 'red teaming,' 'adversary emulation,' 'ATT&CK emulation,' 'assumed breach,' 'purple team exercise,' 'tabletop with technical execution,' 'red team scope,' 'rules of engagement,' 'red team RoE,' 'deconfliction,' 'red team debrief,' or wants to design or run a red-team engagement against systems with authorization."
allowed-tools: Read, Write, Bash, Grep, Glob, WebSearch

Red Team Engagement — Authorized Adversary Emulation

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.

Authorization Check — required before any planning or execution

Before working with this skill at all, confirm:

1. **Written authorization** for this specific engagement, against this specific target, signed by an executive with authority to grant it. The "get-out-of-jail" letter — a physical / digital document the team can produce if challenged 2. **Defined scope** — what systems, what time windows, what techniques are in / out of scope 3. **Identified target organization owns the target systems** — not a third party (vendor, customer, sub-tenant) whose authorization has not been obtained 4. **Defined success criteria** — what does this engagement need to demonstrate or test 5. **Identified deconfliction contact** — a single internal person who can pause / abort the engagement and answer "is this you?" when the blue team finds activity 6. **Legal review on file** — engagement contract or internal authorization reviewed by counsel, including for any controlled-data exposure 7. **Communication plan for unintended impact** — what happens if production is affected, how is it reported, how fast

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.

What red-team engagements are for (and what they are not for)

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:

• If an attacker gets initial access, how long until the blue team notices?
• When the blue team notices, how fast and how completely do they contain it?
• Are the documented incident-response procedures actually used?
• Do detections that exist in theory actually fire in practice?
• Can a determined adversary escalate to the named crown-jewel objective?

Red-team engagements are **not for**:

• Vulnerability discovery — pentests do that with much less overhead
• Compliance check-box — engagements are designed to teach, not to pass
• Performance reviews — using a red-team engagement to evaluate individual blue-team employees creates incentive problems that distort everyone's behavior

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.

Engagement model — three flavors

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

Engagement lifecycle

Phase 0 — Pre-engagement (4-8 weeks before kickoff)

**Scoping with the client / sponsor:**

• **Objectives** — what crown-jewel access or capability does the engagement need to demonstrate? "Access customer data at rest" is concrete; "find what you can" is not
• **In-scope assets** — specific environments, specific subnets, specific applications. List by name, not by description
• **Out-of-scope assets** — explicitly named. Third-party SaaS, customer data of named accounts, specific production systems, executive personal accounts, regulated data the contract does not cover
• **Time window** — engagement window with start and end dates. Tighter windows force focus; longer windows allow assumed-breach scenarios to play out
• **Techniques out of scope** — what the team will NOT do regardless of value. Common: destructive techniques, modification of custome