How to write a malware analysis report someone actually reads

Analysts are graded on findings. Organisations act on reports. When those two diverge, the work was wasted — and the usual cause is a report written in the order the analysis happened rather than the order a reader needs.

Lead with the verdict

Your first paragraph answers three questions: what is it, what does it do, what should we do now. Someone deciding whether to isolate a subnet at 2 a.m. should not have to reach the appendix.

invoice_2026.dll is a loader that installs a credential stealer. It establishes persistence via a Run key, beacons to hxxp://45.9.148[.]x/gate.php every five minutes, and harvests browser credentials. Recommended: block the C2 range, hunt for the Run key across the estate, force password resets for affected users.

Everything after that paragraph exists to justify it. Readers who trust you stop there; readers who need to verify keep going. Both are served.

Separate what you saw from what you concluded

This is the discipline that separates a useful report from a confident-sounding one. Observation and inference belong in different sentences.

• Observation: the binary writes HKCU\...\Run\Updater.
• Inference: it intends to survive reboot.
• Observation: it imports CryptEncrypt and enumerates directories.
• Inference: possibly ransomware — but the same pair appears in backup software, and we saw no ransom note or extension rewriting.

Hedge language belongs on inferences and nowhere else. "The sample appears to write a registry key" is a failure of nerve: either it does or you did not check. Save "appears", "likely" and "consistent with" for the conclusions they belong to, and they start carrying information.

Make the IOCs usable, and defang them

Indicators exist to be actioned, which means they need to be copy-pasteable and typed. Group them — file, host, network — and say what each one is, because a hash that might be the dropper or the payload is a hash nobody can use.

Always defang anything live: hxxp:// instead of http://, 45.9.148[.]x instead of a bare address. Reports get pasted into chat clients and ticketing systems that helpfully turn URLs into links, and someone will eventually click one. Defanging costs two characters.

Say what you did not do

The most valuable line in many reports is the one describing its own limits.

Analysis was static only; the packed payload was not unpacked. Network behaviour is inferred from strings and imports, not observed. The second-stage payload was not retrieved — the C2 was unreachable at the time of analysis.

This is not a confession of incompleteness, it is scope. Without it, a reader reasonably assumes you looked at everything, and builds decisions on coverage you never had. With it, they know exactly which questions remain open — and reviewers stop flagging gaps you were already aware of.

Map to ATT&CK, but only where it fits

Technique IDs make findings comparable across incidents and let a detection team check coverage. They earn their place when they are specific: T1547.001 for the Run key, T1055 for process injection you actually observed.

Resist the urge to decorate. A report tagged with fourteen techniques, four of which are guesses, is less useful than one tagged with four you can each point at a piece of evidence. Every ID should trace to an observation in the body.

Structure that holds up

1. Verdict and recommended actions — a short paragraph, decisions first.
2. Sample identification — names, hashes, sizes, file type, first seen.
3. Capabilities — what it does, grouped by behaviour, observations before inferences.
4. Indicators — grouped, typed, defanged.
5. ATT&CK mapping — techniques with evidence.
6. Scope and limitations — what you did not do.
7. Appendix — the raw output that supports the above.

The order matters more than the headings. Decisions at the top, evidence at the bottom, and a clear line throughout between what you observed and what you think it means.