ThreatCraft is an automated attack scenario generation tool that combines rule-based reasoning with large language models to produce structurally valid and realistic attack scenarios while reducing expert dependency, inconsistency, and hallucinated outputs.
Table of Contents
ThreatCraft is an automated attack scenario generation framework that combines a rule-based attack reasoning engine with LLM-based scenario generation. It is designed to address two key limitations of existing approaches: (i) rule-based systems rely on extensive manual rule engineering, and (ii) LLM-based approaches may generate hallucinated or structurally invalid attack scenarios.
The overall architecture shown in Figure above is organized as a sequential pipeline:
-
📌 Input Data (DFD / System Description)
→ DataFlow Diagram(DFD), Attack Mode, Target Asset → (Figure: left-most input block) -
📌 Rule-Based Attack Engine
→ Constructs structured attack paths using:- Integrated Attack Library (MITRE ATT&CK, CVE, CWE, domain KBs)
- Asset & attack-step dependency model
- Unified Kill Chain (UKC) phase structuring
→ (Figure: upper-middle “Rule Engine” block which is composed of 'Attack Scenario' and 'Risk Value Determination' block)
-
📌 Risk Assessment Module
→ Evaluates attack paths using:- Feasibility (attack vector: network/local/physical/etc.)
- Impact (SFOP + asset criticality)
→ (Figure: branch under rule engine → “Risk Matrix”)
The system-level outputs are not final results. They are used as grounded constraints for LLM-based refinement.
-
📌 Generator Agent
→ Expands system-level paths into function-level attack scenarios
→ Injects vulnerability context (CWE / CVE / EMB3D mapping)
→ (Figure: LLM block – “Generator”) -
📌 Reviewer Agent
→ Converts structured attack paths into natural-language reasoning
→ Validates logical consistency against attack knowledge base
→ (Figure: LLM block – “Reviewer”)
The final output is a structured threat report that includes:
- 🧩 Function-level attack scenarios
- 🧩 System-level validated attack graph
- 🧩 Risk scores (feasibility × impact)
- 🧩 Asset-level vulnerability mapping
→ (Figure: bottom/right output block)
ThreatCraft is not a pure LLM system nor a pure rule engine. Instead, it is a two-stage constrained generation framework where:
- Rule-based reasoning defines the “what is possible”
- LLM defines the “how it actually happens”
- Knowledge base grounding ensures “real-world feasibility”
ThreatCraft/
├── asset/ # Static assets (figures, logo, references)
│ ├── logo.png # Project logo used in README/UI
│ ├── WorkFlow-1.png # System architecture diagram (paper figure)
│ └── UKC_document.pdf # Unified Kill Chain reference document
│
├── code/ # Core implementation directory
│ │
│ ├── frontend/ # GUI + orchestration layer
│ ├── tool_attack_paths.py # main entry point (GUI launcher)
│ ├── automotive/ # automotive Domain frontend
│ ├── tool_attack_paths_automotive.py # Automotive entry point (GUI launcher)
│ ├── tool_threat_mapper_automotive.py # Automotive Middleware between GUI and backend
│ ├── hierarchy_data_automotive.json # Automotive CVE–CWE–EMB3D mapping dataset
│ ├── ics/ # ics Domain frontend
│ ├── tool_attack_paths_ics.py # ics entry point (GUI launcher)
│ ├── tool_threat_mapper_ics.py # ics Middleware between GUI and backend
│ ├── hierarchy_data_ics.json # ics CVE–CWE–EMB3D mapping dataset
│ ├── enterprise/ # enterprise Domain frontend
│ ├── tool_attack_paths_enterprise.py # enterprise entry point (GUI launcher)
│ ├── tool_threat_mapper_enterprise.py # enterprise Middleware between GUI and backend
│ ├── hierarchy_data_enterprise.json # enterprise CVE–CWE–EMB3D mapping dataset
│ │
│ └── backend/ # Threat reasoning & attack graph engine
│ ├── parse_attack_graph_automotive.py # automotive attack scenario generator
│ ├── parse_attack_graph_ics.py # ics attack scenario generator
│ ├── parse_attack_graph_enterprise.py # enterprise attack scenario generator
│ │
│ └── threat_library/ # Structured threat intelligence database
│ ├── impact_feasability_map.json # Risk scoring model (severity × feasibility)
│ ├── automotive/ # automotive json
│ ├── asset_to_threats_automotive.json
│ │ # Maps assets → applicable threats & tactics
│ │
│ ├── attack_vector_feasibility_automotive.json
│ │ # Threat metadata (tactic, feasibility, attack vector)
│ │
│ ├── dependency_automotive.json
│ │ # Asset/threat dependency constraints for attack chaining
│ │
│ ├── impact_map_automotive.json
│ │ # SFOP impact model (Safety / Financial / Operational / Privacy)
│ │
│ └── threat_to_tactic_automotive.json
│ # Threat → MITRE ATT&CK tactic mapping & ordering logic
│ ├── ics/ # ics json
│ ├── asset_to_threats_ics.json
│ │ # Maps assets → applicable threats & tactics
│ │
│ ├── attack_vector_feasibility_ics.json
│ │ # Threat metadata (tactic, feasibility, attack vector)
│ │
│ ├── dependency_ics.json
│ │ # Asset/threat dependency constraints for attack chaining
│ │
│ ├── impact_map_ics.json
│ │ # SFOP impact model (Safety / Financial / Operational / Privacy)
│ │
│ └── threat_to_tactic_ics.json
│ # Threat → MITRE ATT&CK tactic mapping & ordering logic
│ ├── enterprise/ # enterprise json
│ ├── asset_to_threats_enterprise.json
│ │ # Maps assets → applicable threats & tactics
│ │
│ ├── attack_vector_feasibility_enterprise.json
│ │ # Threat metadata (tactic, feasibility, attack vector)
│ │
│ ├── dependency_enterprise.json
│ │ # Asset/threat dependency constraints for attack chaining
│ │
│ ├── impact_map_enterprise.json
│ │ # SFOP impact model (Safety / Financial / Operational / Privacy)
│ │
│ └── threat_to_tactic_enterprise.json
│ # Threat → MITRE ATT&CK tactic mapping & ordering logic
│
└── example/
├── Automotive_DFD.tm7 # Example DFD
├── ICS_DFD_B.tm7 # Example DFD
├── Enterprise_DFD.tm7 # Example DFD
├── _ag_tmp_184849195185.html # Output Report in FTML format
└── _ag_tmp_184849195185.pdf # Output Report in PDF format
│
└── smoke_test.py # Smoke test script
└── smoke_output/ # Smoke test output directory
├── attack_graph.json # Generated attack graph
├── attack_report.html # Generated HTML report
└── attack_report.pdf # Generated PDF report
│
└── README_Markdown_version.md # Markdown-only version of the README
└── REQUIREMENTS.md # System and software requirements
└── STATUS.md # Artifact badges and justification
└── [Artifact Evaluation] Abstract.pdf # Artifact Evaluation abstract
Follow the steps below to set up and run ThreatCraft in your local environment.
-
Install Graphviz
Download and install Graphviz from the official site:
https://graphviz.org/download/
After installation, make sure to add Graphviz to your system PATH (required for rendering attack graphs). -
Install Python dependencies
Run the following command in your project environment:pip install graphviz pillow -
Verify backend prerequisites
Ensure Python version is 3.10+ and Graphviz is accessible from the terminal:dot -V -
Run ThreatCraft
Navigate to the frontend directory and execute:cd code/frontend python tool_attack_paths.py
However, if ThreatCraft cannot be executed properly due to software dependency or local environment configuration issues, it can also be executed using Docker.
-
Install WSL2 on Windows
If you are running ThreatCraft on Windows, install WSL2 first. Open Windows PowerShell as Administrator and run:After the WSL2 installation is complete, restart the system if required.wsl --install -
Install Docker Desktop
Download and install Docker Desktop for Windows from the official Docker website:
https://docs.docker.com/desktop/setup/install/windows-install/
After installation, launch Docker Desktop and keep it running. -
Move to the ThreatCraft artifact directory
Open Windows PowerShell and move to the root directory of the extracted ThreatCraft artifact. -
Build the Docker environment
Run the following command:docker compose build -
Run ThreatCraft in the Docker environment
Run the following command:docker compose up -d -
Access ThreatCraft through a web browser
After the container starts successfully, open the following URL in a web browser:http://localhost:6080/vnc.html?autoconnect=1&resize=scale
Once executed successfully, the system will launch the ThreatCraft and the GUI will be displayed on your screen.
A lightweight offline smoke test is provided to verify that the core rule-based analysis pipeline is working correctly before launching the full GUI workflow.
The smoke test does not require a GPT or Gemini API key. It verifies the following components:
- Python and Graphviz availability
- Required example and threat-library files
- TM7 input parsing
- Rule-based attack graph generation
- Attack-path output validation
Run the test from the root directory of the artifact:
python smoke_test.pyExpected output:
ThreatCraft Smoke Test
========================================
[PASS] Python version: 3.10
[PASS] Graphviz: dot - graphviz version ...
[PASS] Required input files found
[PASS] Rule-based backend completed
[PASS] Output JSON created
[PASS] Attack graph nodes generated: <number>
[PASS] Attack paths generated: <number>
SMOKE TEST PASSED
The generated test results are saved in the following directory:
smoke_output/
├── attack_graph.json
└── attack_report.html
After the smoke test passes, users can proceed to the full GUI workflow described below.
We assume an attacker attempting to remotely compromise a vehicle door control system.
- Target Asset:
Door - Trust Boundary:
External Vehicle Boundary - Attack Mode:
Remote
Select the target domain for the system under analysis. In this tutorial, the attack scenario targets a vehicle, so choose the Automotive Vehicle domain.
After starting the application, the GUI dashboard is displayed.
Configure the analysis environment as follows:
-
📂 DFD File Selection
Load the target system model (TM7 file) representing the vehicle architecture. -
🧠 LLM Configuration
- Select LLM backend (e.g., GPT-based model)
- Input valid API key
- Alternatively, select Ollama to run the LLM locally without an API key
-
🎯 Target Definition
- Select Target Asset:
Door
- Select Target Asset:
-
🌐 Trust Boundary Selection
- Define system boundary:
External Vehicle Boundary
- Define system boundary:
-
⚔️ Attack Mode
- Set attacker capability:
Remote
- Set attacker capability:
-
▶️ ClickRun Analysis
📌 Note: All required threat intelligence libraries (CVE/CWE/EMB3D mappings, dependency graphs, risk models) are preloaded via Library File Settings by default.
Next, we define the implementation details for each asset.
For instance, as shown in the figure below a TCU may run a Linux operating system with multiple implementation characteristics:
- loadable kernel modules (PID-23L1) and
- Linux namespace isolation (PID-23L2).
After adding the implementation details to the assets, click “OK”.
📌 Note: It is not mandatory to provide implementation details for all assets.
The result window consists of three tabs:
Each CWE threat is mapped to a specific asset. Note that CWE entries for an asset are not provided by default; they become available only after defining the asset’s implementation details, as described in Subsection 2 (“Configure Implementation Details of Assets”).
Each identified attack path is summarised. Each path represents a unique combination of assets and threats.
The AI analysis is divided into two levels:
For each attack path, the tool assesses its likelihood (confidence level) and provides mitigation recommendations. Furthermore, it performs a comprehensive evaluation across all attack paths to identify and present the highest-risk path.
The tool evaluates the most critical vulnerabilities within each asset in the aggregated attack tree from an SFOP (Safety, Financial, Operational, Privacy) perspective, and presents the results for each asset-specific vulnerability accordingly.
📌 Note: You could save its results into JSON, CSV respectively, and also, you can check this whole results displayed in TARA Report(check
example/_ag_tmp_184849195185.html)
This project is licensed under the MIT License.
- Seungjoo Kim (Corresponding Author) — Professor, Korea University, School of Cybersecurity (skim71@korea.ac.kr)
- Dohee Kang (First Author) — M.S. course, Korea University, School of Cybersecurity (kangdohee1211@korea.ac.kr)
- Jiwon Kwak (Second Author) — Ph.D. course, Korea University, School of Cybersecurity (jwkwak4031@korea.ac.kr)
- Geunwoo Baek (Third Author) — M.S, Korea University, School of Cybersecurity (sinse100@korea.ac.kr)
- Our Lab — Security Automation aNd Engineering Lab (SANE Lab)