--- name: Red Team Flow Generator slug: red-team-flow-generator category: Automation description: Red Team Flow Generator creates SITF-compliant attack flow JSON from red team or pentest reports, URLs, or pasted findings. Use it to turn offensive security engagement notes into structured attack chains. github: "https://github.com/wiz-sec-public/SITF/tree/main/.claude/skills/red-team-flow" language: HTML stars: 179 forks: 18 install: "npx degit https://github.com/wiz-sec-public/SITF/tree/main/.claude/skills/red-team-flow ~/.claude/skills/red-team-flow" installs_to: ~/.claude/skills/red-team-flow source_path: .claude/skills/red-team-flow/SKILL.md collection_size: 3 category_size: 2109 collection_url: "https://dirskills.com/collections/wiz-sec-public/SITF" added: 2026-09-07T05:20:29.893Z last_synced: 2026-09-07T05:20:29.893Z canonical_url: "https://dirskills.com/skills/red-team-flow-generator" --- # Red Team Flow Generator Red Team Flow Generator creates SITF-compliant attack flow JSON from red team or pentest reports, URLs, or pasted findings. Use it to turn offensive security engagement notes into structured attack chains. **Install:** ```bash npx degit https://github.com/wiz-sec-public/SITF/tree/main/.claude/skills/red-team-flow ~/.claude/skills/red-team-flow ``` ## README # Red Team Flow Generator Generate SITF-compliant attack flow JSON files from red team or penetration testing reports. ## Usage ``` /red-team-flow [source] ``` - `engagement-name`: Identifier for the engagement (e.g., "acme-2026q1", "client-sdlc-audit") - `source`: One of: - `--file `: Path to report file (markdown, txt, json, pdf) - `--url `: URL to report or findings page - Omit to paste report text directly in conversation Arguments: $ARGUMENTS ## Supported Input Formats The skill accepts red team and pentest reports in various formats: ### Text-Based Reports - Markdown reports with findings sections - Plain text engagement notes - Bullet-point attack chains - Executive summaries with technical appendix ### Structured Formats - JSON findings export - CSV with columns: finding, target, technique, evidence - YAML engagement summaries ### Report Sections Recognized The skill looks for these common report patterns: - "Findings", "Vulnerabilities", "Attack Path", "Kill Chain" - "Initial Access", "Lateral Movement", "Privilege Escalation" - "Recommendations", "Remediation" (used for control mapping) - Numbered steps (1., 2., 3. or Step 1, Step 2) - MITRE ATT&CK references (T1xxx) ## Instructions When this skill is invoked: ### Phase 1: Report Ingestion 1. **If `--file` specified:** - Read the file content - Detect format (markdown, txt, json, csv, yaml) - Extract structured findings 2. **If `--url` specified:** - Fetch the URL content - Parse as report or findings page 3. **If no source specified:** - Prompt user to paste report content - Or use context from current conversation 4. **Normalize the input:** - Extract attack steps/findings into a structured list - Identify: target component, action taken, evidence, outcome - Preserve attack chain order if present ### Phase 2: Technique Mapping 1. Read `techniques.json` to get the full SITF technique library. 2. For each finding/attack step, find the best matching technique: - Match by **action semantics**, not surface keywords - Map pentest terminology to SITF: - "GitHub Actions exploit" → T-C003 (PWN Request) or T-C004 (Script Injection) - "Stole AWS creds from logs" → T-C005 (Secret Exfiltration from Workflow) - "Published malicious package" → T-R004 (Publishing Malicious Package) - "Accessed prod via stolen token" → T-P001 (Abuse Production Credentials) - If MITRE ATT&CK IDs are in the report, cross-reference with SITF mappings 3. If no matching SITF technique exists: - Check if finding is **in-scope** for SITF (SDLC/supply-chain related) - If in-scope: Create placeholder with `"type": "technique-gap"` - If out-of-scope (generic infra attack): Note in output, reference MITRE ATT&CK 4. For pentest reports with isolated findings (not chained): - Group findings by target component - Create parallel technique nodes within each component - Connect entry point to each finding independently ### Phase 3: Layout Calculation Apply these layout rules (consistent with `/attack-flow`): #### Rule 1: Component Layout (Left-to-Right by Attack Flow) - Order components by their **sequence in the attack chain** - If findings aren't chained, order by: endpoint → vcs → cicd → registry → production - Component x-positions: Use increments of ~300px starting from x=50 #### Rule 2: Technique Ordering (Top-to-Bottom) - **Chained attacks**: Order by attack sequence - **Isolated findings**: Order by severity (Critical → High → Medium → Low) - Vertical gap between techniques: ~130px - First technique starts at y = component.y + 80 #### Rule 3: Technique-Component Centering - technique.x = component.x + (component.width - technique.width) / 2 - With component.width=250 and technique.width=160: offset = 45 - Example: component at x=50 → technique at x=95 #### Rule 4: Component Sizing - Width = 250px (standard) - Height = max(500, (technique_count × 130) + 160) #### Rule 5: Edge Connections - Connect source.bottom → target.top for vertical flows within component - Connect source.right → target.left for cross-component flows - Add labels from report evidence ("Stolen AWS_ACCESS_KEY_ID", "via PR #123") - Use `"type": "smoothstep"` for all edges ### Phase 4: JSON Generation Generate attack flow JSON with this structure (identical to `/attack-flow` output): ```json { "metadata": { "name": "Engagement Name", "title": "Canvas Display Title", "created": "ISO-8601 timestamp", "version": "1.0", "framework": "SITF", "source": "red-team-report", "description": "Brief engagement description" }, "nodes": [], "edges": [] } ``` **Metadata field guidelines:** - `name`: Short identifier (e.g., "acme-2026q1", "client-sdlc-audit") - `title`: Concise canvas title, max 5-7 words (e.g., "ACME CI/CD Pipeline Assessment", "Client SDLC Red Team Q1") - `description`: One sentence summary, max 150 characters - Do NOT write paragraph-length titles — save details for technique customLabels and evidence fields **Node types** (same as /attack-flow): - `entryPoint`: How the engagement started (Assumed Breach, External Attacker, Insider, etc.) - `component`: SITF component container (endpoint, vcs, cicd, registry, production) - `technique`: Attack technique from techniques.json - `technique-gap`: Placeholder for missing SITF technique - `exitPoint`: Engagement outcome (Data Exfiltration, Persistence, Supply Chain Compromise, etc.) **Special metadata for red team flows:** - Add `"source": "red-team-report"` to metadata - Add `"engagement"` field if client/engagement name is known - Add `"scope"` array listing in-scope components #### Node Structure - Technique (with evidence) ```json { "id": "technique-c003-1", "type": "technique", "position": { "x": 95, "y": 160 }, "data": { "id": "T-C003", "name": "PWN Request / Poisoned Pipeline Execution", "component": "cicd", "stage": "Initial Access", "description": "Full description from techniques.json", "risks": ["risk1", "risk2"], "controls": { "protective": [], "detective": [] }, "customLabel": "Exploited workflow in repo X", "evidence": "PR #142 triggered workflow with write permissions", "severity": "Critical" }, "zIndex": 10, "width": 160, "height": 96 } ``` ### Phase 5: Control Gap Analysis After generating the flow, analyze defensive gaps: 1. For each technique used in the attack: - List the protective controls from techniques.json - Identify which controls were missing (enabled the attack) 2. Generate a **Controls Gap Summary**: ``` | Technique | Missing Control | OWASP SPVS | |-----------|-----------------|------------| | T-C003 | Minimal workflow permissions | V3.1 | | T-C005 | Log sanitization | V2.5 | ``` 3. Prioritize recommendations by: - Number of techniques the control would prevent - Severity of findings it addresses ### Phase 6: Validation Run this checklist before outputting: ``` [ ] Valid JSON structure (parse test passes) [ ] Required fields: metadata.{name,title,created,version,framework,source}, nodes[], edges[] [ ] All node IDs are unique [ ] All edge source/target reference valid node IDs [ ] Technique nodes use data.id and data.name (NOT techniqueId/label) [ ] Technique nodes include full risks[] and controls from techniques.json [ ] All techniques centered within components (x = component.x + 45) [ ] Component heights adequate for technique count [ ] Out-of-scope findings noted but not forced into SITF [ ] Evidence preserved in customLabel or evidence fields [ ] Exit points connected to terminal techniques ``` ### Phase 7: Output 1. Write the JSON file to `flows/red-team/.json` 2. Validate JSON: `python3 -c "import json; json.load(open('file'))"` 3. Provide output summary: ```markdown ## Red Team Flow: ### Attack Chain 1. Initial Access via [entry point] 2. [Technique] → [Technique] → ... 3. Impact: [exit point] ### Techniques Used | ID | Name | Component | Evidence | |----|------|-----------|----------| | T-C003 | PWN Request | CI/CD | PR #142 | | ... | ... | ... | ... | ### Control Gaps Identified | Missing Control | Would Prevent | Priority | |-----------------|---------------|----------| | Minimal workflow permissions | T-C003, T-C005 | High | | ... | ... | ... | ### Out-of-Scope Findings - [Finding X]: Generic cloud attack, see MITRE ATT&CK T1078 ### Technique Gaps - [Finding Y]: No matching SITF technique, run `/technique-proposal` ``` 4. If technique-gaps exist, recommend `/technique-proposal` for each ## Examples ### From File ``` /red-team-flow acme-2026q1 --file ./reports/acme-final-report.md ``` ### From URL ``` /red-team-flow client-audit --url https://internal.wiki/engagements/client-findings ``` ### From Pasted Text ``` /red-team-flow demo-engagement We started with access to a developer laptop (assumed breach). Found GitHub PAT in ~/.config/gh/hosts.yml. Used the token to access private repos and discovered hardcoded AWS credentials in a workflow file. The AWS creds had admin access to production S3 buckets. We exfiltrated customer data as POC. ``` ## Pentest vs Red Team Handling **Red Team Reports** (attack chains): - Typically have sequential steps (A → B → C → D) - Generate connected flow with edges between techniques - Entry point connects to first technique, exit point to last **Pentest Reports** (isolated findings): - May have unconnected findings per component - Generate parallel techniques within components - Entry point fans out to multiple techniques - Each finding may have its own exit point or shared "Findings Reported" exit The skill auto-detects based on report structure: - Sequential numbering / "then we..." / "next..." → chained flow - Bullet lists / severity ratings / individual findings → parallel flow