The analyst report is the deliverable that turns a technical investigation into actionable intelligence for defenders. The eight-section structure, the executive summary that non-technical stakeholders can act on, and the reporting failures that undermine otherwise good analysis.
Sign in to mark this article as read and track your progress.
Malware analysis without a report is a private activity. The knowledge lives only with the analyst who did the work. A well-written report converts that knowledge into a shared, permanent, actionable artifact that defenders can implement, managers can understand, and future analysts can build on. The report is not the appendix to the real work — it is the deliverable.
This distinction matters because many analysts treat reporting as documentation: a record of what they did. The better frame is communication: what does the reader need to know, and in what order, to act correctly? These are different writing tasks.
Industry-standard malware analysis reports follow a consistent structure. Variations exist, but reports that deviate significantly from this structure create friction for readers who are used to the standard format.
1. Executive Summary (one page maximum) Written for a non-technical decision-maker. Answers four questions: What is this threat? How serious is it? What systems or data are at risk? What should be done immediately? No technical jargon, no tool names, no register values. If a manager cannot read this section and decide whether to escalate, the executive summary has failed.
2. Sample Metadata A structured table:
| Field | Value |
|---|---|
| Filename | invoice_march.exe |
| SHA-256 | [hash] |
| File type | PE32 executable (GUI) |
| File size | 487,424 bytes |
| Compile timestamp | 2024-03-14 09:22:11 UTC |
| Packer / Obfuscation | UPX 3.96 |
| First submission (VT) | 2024-03-15 |
3. Static Analysis Findings What was found by examining the file without executing it: strings, imports, exports, sections, embedded resources, entropy analysis, code signatures. Report what was found and what it implies.
4. Dynamic Analysis Findings What was observed during execution: process behaviour, network activity, file system modifications, registry changes, memory artefacts. Organise by category, not by chronological sandbox log dump.
5. Code Analysis (if performed) Key functions reverse engineered, algorithms identified, anti-analysis techniques encountered. Reference specific virtual addresses or function names so another analyst can navigate to the same code.
6. IOC Table A machine-readable table of all extracted Indicators of Compromise with confidence levels. Format that can be imported into a SIEM or threat intelligence platform. Include hash, network, host, and behavioural IOCs in separate subsections.
7. ATT&CK Mapping The ATT&CK Navigator layer image embedded in the report, plus a table listing each technique with the specific evidence that supports the mapping.
8. Recommendations Actionable items for defenders: what to block, what to hunt for, what controls would have prevented or detected this threat, what patching is relevant. Prioritised by implementation effort and impact.
The executive summary is the section most analysts write worst, because it requires translating technical findings into business language without losing accuracy.
A useful template:
"[Threat name] is [malware category] that [primary capability in plain language]. It was [delivery method] and targets [affected systems or user types]. If executed, it [primary impact: what does it steal, encrypt, install, or enable]. [X] systems in the environment may be at risk based on [indicator]. Recommended immediate actions: [2-3 specific items]."
Example:
"The submitted file is a loader that downloads and executes additional malware after establishing a foothold on the victim machine. It is delivered via phishing emails with ZIP attachments and targets Windows 10 and 11 systems. If executed, it silently installs a remote access tool that allows the attacker to control the system, steal credentials, and deploy ransomware. Based on network indicators identified, communication with the attacker's server may already have occurred from machines in the 192.168.10.0/24 subnet. Recommended immediate actions: block the identified C2 domain at the perimeter, isolate any machine that executed the attachment, and audit authentication logs for the affected subnet."
Notice: no register names, no API names, no tool output. A CFO can read this and make a decision.
Speculation as fact. "This malware is from [nation-state]" requires substantial evidence. "This malware shares code and infrastructure with samples previously attributed to [group] by [vendor]" is accurate and defensible. Attribution claims in a single-sample analysis report are almost always speculation.
Missing IOC provenance. "MD5: abc123def456" with no indication of whether this was the submitted sample, a dropped file, or a network indicator is useless. Every IOC needs a source.
Chronological sandbox dump masquerading as analysis. Pasting the sandbox JSON output into a document is not analysis. The analyst's job is to interpret what the sandbox observed, explain what it means, and connect it to the broader picture.
No ATT&CK mapping. A report without ATT&CK mapping cannot be directly consumed by a detection engineer. The mapping section is not optional for a complete analysis.
Over-mapping ATT&CK. A report that maps 40 techniques for a commodity loader is also a failure. It maps inferences and assumptions alongside confirmed observations with no confidence distinction, making every technique in the list equally suspect.
No recommendations. "The malware does X" is incomplete. "The malware does X; defenders should implement Y to detect or prevent this" is a complete report.
Several organisations publish report templates and completed example reports:
