THREATBYTES / Malware-Analysis-Report-Template

# ThreatBytes Malware Analysis Report Template
> **Part of ThreatBytes**: practical, open resources for threat intelligence and malware analysis.
A consistent, machine-readable report format for malware analysis, mapped to MITRE ATT&CK. It ships as a JSON Schema, a fill-in Markdown template, a fictional worked example and a validator.
## Why use it?
- **Consistency**: every report covers the same ground, from hashes to recommendations, so nothing is missed.
- **Comparability**: structured fields make it easy to compare samples, track families and spot overlaps.
- **Automation-friendly**: JSON reports can be validated in CI, ingested by a SIEM/TIP or turned into IOC feeds.
- **ATT&CK-native**: every behaviour is tied to a technique ID *and* the evidence behind it.
## Repository layout
 [code] 
## Quick start
 [code] 
Prefer prose? Copy `templates/report-template.md` and fill it in; the headings mirror the schema so you can convert to JSON later.
## Field overview
| Section | Key fields | Required |
|---|---|---|
| `schema_version` | `"0.1.0"` | ✔ |
| `metadata` | `id` (`TB-MAR-YYYY-NNN`), `title`, `analyst`, `date`, `tlp` (TLP 2.0), `summary`, `fictional` | ✔ |
| `sample` | `hashes` (`md5`, `sha1`, `sha256`*, `ssdeep`, `tlsh`), `file_type`, `size_bytes`, `names`, `first_seen` | ✔ |
| `classification` | `family`, `type`, `confidence` | ✔ |
| `static_analysis` | `pe_info`, `imports`, `sections` (with entropy), `strings`, `packers`, `yara_hits` | |
| `dynamic_analysis` | `sandbox`, `processes`, `file_activity`, `registry_activity`, `network_activity`, `persistence` | |
| `iocs` | `type` (ip, domain, url, hash, mutex, file_path, registry_key), `value`, `confidence` | ✔ |
| `attack_mappings` | `tactic`, `technique_id`, `technique_name`, `evidence`, `confidence` | ✔ |
| `detection` | `yara[]`, `sigma[]` (name + rule content) | |
| `recommendations` | list of actions | |
| `references` | `title`, `url` | |
\* SHA-256 is the only mandatory hash. Confidence is always `low`, `medium` or `high`.
## Validating a report
 [code] 
The script exits non-zero on failure and lists each error with its JSON path, so it slots straight into CI. Formats (dates, URIs) are checked too.
## ATT&CK mapping guidance
- **Use the most specific technique** available: `T1547.001` rather than `T1547`. IDs must match `Txxxx` or `Txxxx.xxx`.
- **One row per technique per tactic.** If a technique serves two tactics (e.g. persistence and privilege escalation), add two rows.
- **Always cite evidence**: a registry write, an API call, a network beacon. No evidence, no mapping.
- **Grade confidence honestly**:
 - `high`: directly observed in dynamic analysis or unambiguous in code.
 - `medium`: strongly implied by static indicators (imports, strings).
 - `low`: inferred or based on third-party reporting.
- Use the tactic names exactly as ATT&CK Enterprise lists them (e.g. `Command and Control`).
- Check IDs against the current ATT&CK matrix; techniques are sometimes deprecated or renumbere