Writing A Malware Analysis Report

---
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).