SITF red-team-flow

Generate SITF-compliant attack flow JSON from red team or pentest reports. Accepts report files, URLs, or pasted findings. Use when documenting offensive security engagements.

install
source · Clone the upstream repo
git clone https://github.com/wiz-sec-public/SITF
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/wiz-sec-public/SITF "$T" && mkdir -p ~/.claude/skills && cp -r "$T/.claude/skills/red-team-flow" ~/.claude/skills/wiz-sec-public-sitf-red-team-flow && rm -rf "$T"
manifest: .claude/skills/red-team-flow/SKILL.md
source content

Red Team Flow Generator

Generate SITF-compliant attack flow JSON files from red team or penetration testing reports.

Usage

/red-team-flow <engagement-name> [source]
  • engagement-name
    : Identifier for the engagement (e.g., "acme-2026q1", "client-sdlc-audit")
  • source
    : One of:
    • --file <path>
      : Path to report file (markdown, txt, json, pdf)
    • --url <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):

{
  "metadata": {
    "title": "Human-readable title for canvas display",
    "name": "Engagement Name",
    "created": "ISO-8601 timestamp",
    "version": "1.0",
    "framework": "SITF",
    "source": "red-team-report",
    "description": "Red team engagement against ACME Corp SDLC infrastructure"
  },
  "nodes": [],
  "edges": []
}

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)

{
  "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.{title,name,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/<engagement-name>.json
  2. Validate JSON:
    python3 -c "import json; json.load(open('file'))"
  3. Provide output summary:
## Red Team Flow: <engagement-name>

### 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`
  1. 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