pentest-threat-model

name	pentest-threat-model
description	Threat modeling — STRIDE, DREAD, attack tree, data flow diagram, MITRE ATT&CK Navigator integration. Triggers on threat model, STRIDE, DREAD, attack tree, DFD, data flow diagram, MITRE ATT&CK, threat matrix, risk scoring.
license	MIT
compatibility	Works with Claude Code
allowed-tools	Read Write Edit Grep
metadata	{"author":"badi","homepage":"https://github.com/fatihkan/badi-skills/tree/main/skills/pentest-threat-model","badi-version":">=1.24.0","category":"pentest","scope":"advisory","inspired-by":"0xSteph/pentest-ai-agents threat-modeler"}

pentest-threat-model

System threat modeling — STRIDE, DREAD, attack tree, DFD. Used at engagement start or in a design review.

Triggers

• "create a threat model"
• "STRIDE analysis"
• "DREAD scoring"
• "draw an attack tree"
• "data flow diagram"
• "MITRE ATT&CK matrix"

STRIDE (Microsoft)

Letter	Threat	Counter Property
S	Spoofing identity	Authentication
T	Tampering with data	Integrity
R	Repudiation	Non-repudiation
I	Information disclosure	Confidentiality
D	Denial of service	Availability
E	Elevation of privilege	Authorization

Apply STRIDE to every DFD element (Process, Data Store, Data Flow, Trust Boundary).

DREAD Scoring

Dimension	1 (Low)	5 (High)	10 (Critical)
Damage	Minimal	Major	Catastrophic
Reproducibility	Hard	Sometimes	Trivial
Exploitability	Hard	Moderate	Trivial (script)
Affected users	Few	Many	Most
Discoverability	Hidden	Apparent	Public docs

Total: 50 max. High = high risk.

DFD Structure

[External Entity] --> ((Process)) --> [Data Store]
                          |
                      Trust Boundary
                          |
                   ((Internal Service))

Components:

• External Entity (square): user, 3rd party API
• Process (circle): web server, microservice
• Data Store (cylinder): database, cache
• Data Flow (arrow): request/response
• Trust Boundary (dashed line): VPC boundary, network zone

Attack Tree Template

Goal: Steal credit card data
├── 1. Compromise web server
│   ├── 1.1 RCE via SQL injection
│   │   └── 1.1.1 Find SQLi in /api
│   ├── 1.2 Steal session cookie via XSS
│   └── 1.3 Brute force admin panel
├── 2. Compromise database directly
│   ├── 2.1 Internal port reachable
│   └── 2.2 Default credential
└── 3. Social engineer admin
    ├── 3.1 Phishing
    └── 3.2 Vishing IT helpdesk

For each leaf:

• DREAD score
• Likelihood (1-5)
• Cost to exploit (hours/days)
• Detection (likely/possible/unlikely)

MITRE ATT&CK Matrix Mapping

threat_model:
  asset: Production database
  threats:
    - id: T-DB-001
      stride: I (Information disclosure)
      attack:
        tactic: TA0009 Collection
        technique: T1213 Data from Information Repositories
      dread: { damage: 9, repro: 7, exploit: 6, affected: 8, discover: 5 }
      score: 35
      mitigation:
        - DB encryption at rest
        - Access logging + SIEM rule
        - Network segmentation

Output Template

## Threat Model — <system>

### 1. System Description
- Frontend: React SPA on CDN
- Backend: Node.js API on Kubernetes
- Data: PostgreSQL (managed) + Redis (managed)
- 3rd party: Stripe, SendGrid, Auth0

### 2. Data Flow Diagram (Mermaid)
(mermaid flowchart of external entities, processes, data stores, and trust
boundaries — see the render example in the "Mermaid DFD Render" section below)

### 3. Entry Points & Trust Boundaries
Entry points: /api/* (JWT), /webhooks/stripe (signature), admin panel (SSO)
1. CDN <-> API (TLS, JWT auth)
2. API <-> DB (VPC private subnet, IAM auth)
3. API <-> 3rd party (TLS + API key)

### 4. Threats (STRIDE + DREAD table)

| # | Threat | STRIDE | DREAD | Tactic |
|---|--------|--------|-------|--------|
| 1 | Stripe webhook spoofing (no sig verify) | T | 38 | Initial Access |
| 2 | JWT alg=none bypass | S+E | 36 | Initial Access |
| 3 | DB credential leak via 0/1-day | I | 33 | Credential Access |
| 4 | Redis SSRF via SSRF in URL param | I | 30 | Discovery |
| 5 | DoS via excessive GraphQL nesting | D | 28 | Impact |

### 5. Mitigations
- Stripe: webhook signature verify (Stripe-Signature header)
- JWT: enforce alg whitelist (RS256 only)
- DB: rotate credentials quarterly, IAM auth (no static creds)
- SSRF: URL allowlist (no internal IP)
- GraphQL: max-depth 7, max-aliases 30

File Output Convention (v1.34+)

When the user asks to persist the threat model (or when it feeds the security-check pipeline), write it to THREAT_MODEL.md at the scan target's root (the project root for a whole-repo scan) using the Output Template above, organized into numbered sections:

1. System Description
2. Data Flow Diagram (Mermaid)
3. Entry Points & Trust Boundaries
4. Threats (STRIDE + DREAD table)
5. Mitigations

Sections 3 and 4 are the machine-consumed scoping contract: the security-check pipeline (Phase 1 recon and Phase 2 hunting) reads them to focus scanning on the modeled entry points and threats. THREAT_MODEL.md is the head of the harness-compatible artifact chain THREAT_MODEL.md → VULN-FINDINGS.json/.md → TRIAGE.json/.md — filenames follow anthropics/defending-code-reference-harness (Apache-2.0) for interop. Unlike the generated scan artifacts, THREAT_MODEL.md is a durable design document — commit it.

Mermaid DFD Render

flowchart LR
    User[User Browser] -->|HTTPS| CDN[CDN]
    CDN -->|HTTPS+JWT| API[API Gateway]
    API -->|VPC| DB[(PostgreSQL)]
    API -->|VPC| Cache[(Redis)]
    API -->|HTTPS+API Key| Stripe[Stripe API]
    API -->|HTTPS+API Key| SendGrid[SendGrid]

    classDef boundary stroke-dasharray:5
    style CDN stroke-dasharray:5
    style API stroke-dasharray:5

Out-of-Scope

• Live attack execution (modeling only)
• Automatically updating an existing model (manual review as needed)