116 lines
4.1 KiB
Markdown
116 lines
4.1 KiB
Markdown
---
|
|
name: writing-a-malware-analysis-report
|
|
description: 'Structures a clear, actionable malware analysis report covering summary,
|
|
sample identity, capabilities, IOCs, ATT&CK mapping, and detection guidance for both
|
|
technical and decision-making audiences. Activates for requests to write, structure, or
|
|
review a malware analysis or reverse-engineering report.'
|
|
domain: cybersecurity
|
|
subdomain: lab-foundations
|
|
tags:
|
|
- malware
|
|
- reporting
|
|
- ioc
|
|
- mitre-attack
|
|
- documentation
|
|
- detection
|
|
version: 1.0.0
|
|
author: analyst-ai-pack
|
|
license: Apache-2.0
|
|
mitre_attack:
|
|
- T1587
|
|
d3fend:
|
|
- D3-FA
|
|
references:
|
|
- 'MITRE ATT&CK — https://attack.mitre.org/'
|
|
- 'MISP core format / STIX 2.1 for IOC representation — https://www.misp-project.org/'
|
|
---
|
|
|
|
# Writing a Malware Analysis Report
|
|
|
|
## When to Use
|
|
|
|
- You have completed static, dynamic, or reverse-engineering analysis and need to communicate
|
|
findings to responders, detection engineers, and leadership.
|
|
- You need a consistent report structure so findings are actionable and comparable across
|
|
samples.
|
|
- You are reviewing a draft report for completeness before distribution.
|
|
|
|
**Do not use** this as a substitute for analysis; a report only documents work already done.
|
|
Do not pad a report with tool output that has no analytic conclusion.
|
|
|
|
## Prerequisites
|
|
|
|
- Completed analysis artifacts: sample hashes, behavioral notes, extracted IOCs, screenshots,
|
|
and any reversed routines.
|
|
- An ATT&CK reference for mapping observed behaviors to techniques.
|
|
|
|
## Workflow
|
|
|
|
### Step 1: Lead with an executive summary
|
|
|
|
Three to five sentences a non-analyst can act on: what the sample is, what it does, the risk,
|
|
and the recommended action. State your confidence and the basis for it.
|
|
|
|
### Step 2: Record sample identity
|
|
|
|
A table the reader can match against their telemetry:
|
|
|
|
```text
|
|
Filename (as received) : invoice.exe
|
|
SHA-256 : 9f86d0818...
|
|
SHA-1 / MD5 : ...
|
|
File type / size : PE32 executable / 412 KB
|
|
First seen / source : 2026-06-20 / MalwareBazaar
|
|
Signing : unsigned / invalid certificate
|
|
```
|
|
|
|
### Step 3: Describe capabilities, not just events
|
|
|
|
Group findings by capability (persistence, C2, defense evasion, collection), each with the
|
|
evidence and the ATT&CK technique:
|
|
|
|
```text
|
|
Persistence : Run key HKCU\...\Run "Updater" -> %APPDATA%\svc.exe [T1547.001]
|
|
C2 : HTTPS beacon to evil[.]com/api every 60s +/- jitter [T1071.001]
|
|
Defense evasion: UPX-packed; checks for VM artifacts before running [T1027, T1497]
|
|
```
|
|
|
|
### Step 4: Provide IOCs in a usable form
|
|
|
|
Defanged for reading, plus a machine-ingestible block (CSV/STIX/MISP) for detection teams.
|
|
Separate **host** IOCs (paths, registry keys, mutexes) from **network** IOCs (domains, IPs,
|
|
URLs, JA3).
|
|
|
|
### Step 5: Give detection and response guidance
|
|
|
|
Concrete next steps: YARA/Sigma rules, what to hunt for, containment, and remediation.
|
|
|
|
### Step 6: Generate the skeleton and validate completeness
|
|
|
|
```bash
|
|
python scripts/analyst.py scaffold --sha256 <sha256> --name "Sample" > report.md
|
|
python scripts/analyst.py check report.md
|
|
```
|
|
|
|
## Validation
|
|
|
|
- An incident responder can act on the report without reading the raw tool logs.
|
|
- Every capability claim cites specific evidence (offset, registry key, packet, decompiled
|
|
routine).
|
|
- IOCs appear both defanged (for humans) and in a structured block (for tools).
|
|
- ATT&CK techniques are valid current IDs and tied to observed behavior, not guessed.
|
|
|
|
## Pitfalls
|
|
|
|
- Dumping raw tool output without interpretation — the reader needs conclusions.
|
|
- Overclaiming attribution ("this is APT-X") from weak signals; state confidence and
|
|
evidence instead.
|
|
- Mixing host and network IOCs, or leaving IOCs clickable in the human-readable section.
|
|
- Mapping to ATT&CK techniques that the evidence does not actually support.
|
|
|
|
## References
|
|
|
|
- See [`references/api-reference.md`](references/api-reference.md) for the scaffold and
|
|
completeness-check tooling.
|
|
- MITRE ATT&CK and MISP/STIX IOC formats (linked in frontmatter).
|