---

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:

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:

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

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 for the scaffold and completeness-check tooling.
• MITRE ATT&CK and MISP/STIX IOC formats (linked in frontmatter).