Reporting A Sample

Prerequisites

• Target system, dependencies and environment configured.

Usage

Purpose

Malware analysis that isn't communicated is wasted effort. The report is the deliverable — it turns hours of triage, detonation, and reversing into something IR can act on, detection engineers can build from, and leadership can understand. A good malware report answers each audience's question without making them read the whole analysis. This skill covers writing that report, the closing step that connects the whole domain to defence.

When to use it

After analysing a sample, before considering the work done. Even a quick triage deserves a short write-up if the sample matters. It's the bridge from the malware domain to incident-response, detection-engineering, and threat-intelligence — those teams consume this report.

Procedure

1. Lead with the answers people need, not the analysis journey. Open with a short summary: what the sample is (family/type), what it does (capability), how bad it is (impact), and the key indicators. Analysts, IR, and leadership should get the essentials from the first paragraph without reading the reversing details.
2. Serve each audience's question:
   • IR / responders — what does it do, how does it persist, what's the scope of impact, and what are the IoCs to hunt and block right now. Actionable and immediate.
   • Detection engineers — the behavioural indicators, YARA rules, and network signatures to build durable detection from.
   • Leadership / decision-makers — the risk in plain terms: what could this do to us, is it targeted, what's the recommended response. Non-technical.
3. Include the technical analysis as supporting depth, structured so readers can go as deep as they need: capabilities observed, persistence mechanism, C2 details, and notable techniques (mapped to MITRE ATT&CK so it's comparable and searchable). This is the evidence behind the summary, not the lead.
4. Present IoCs clearly and by type (file, network, host/behavioural), with the durability weighting from the extracting-iocs skill, in a format defenders can ingest. This is often the most-used part of the report.
5. Map to ATT&CK — expressing the sample's behaviour as ATT&CK techniques makes it comparable to other threats, feeds detection coverage analysis, and communicates capability in a shared language.
6. State confidence and gaps honestly — what you're sure of, what's inferred, and what you couldn't determine (packed sections you didn't fully unpack, behaviour that didn't trigger). An honest report is trustworthy; overstating certainty misleads response decisions.
7. Recommend actions — concrete next steps for IR (hunt these IoCs, block these destinations, check for this persistence) and detection (deploy these rules). A report that ends without recommendations leaves the reader to figure out what to do.

Cheatsheet

lead with ANSWERS, not the journey
  summary first: what it is (family) + what it does (capability) + how bad (impact)
  + key IoCs — readable without the deep analysis

per audience
  IR/responders     what/persist/scope + IoCs to hunt+block NOW (actionable)
  detection eng     behavioural indicators + YARA + network signatures (durable)
  leadership        plain-language risk: impact, targeted?, recommended response

supporting depth (structured, go-as-deep-as-needed)
  capabilities, persistence, C2, techniques -> mapped to MITRE ATT&CK

IoCs: clear, BY TYPE (file/network/host), durability-weighted, ingestible format
confidence + GAPS: state what's sure vs inferred vs undetermined (be honest)
RECOMMEND actions: hunt X, block Y, check persistence Z, deploy rules

goal: analysis -> ACTION for IR, detection, and decision-makers.

Reading your report

• A summary that answers what/does/impact/IoCs up front = each audience gets what they need fast; the mark of a usable report. If readers must wade through reversing details to learn what the sample does, restructure.
• IoCs clearly typed and durability-weighted = the most-used section; done well it's directly ingestible by detection and IR. A buried or unstructured IoC list undercuts the whole report.
• Behaviour mapped to ATT&CK = comparable, searchable, and feeds coverage analysis; a report without it is an island.
• Honest confidence and gaps = trustworthy and safe to act on; a report overstating certainty (claiming full understanding of a partially-unpacked sample) misleads response.
• Concrete recommendations = the report drives action; one that ends at "here's what it does" leaves value on the table.
• A layered report — summary, audience answers, supporting depth, IoCs, recommendations = analysis turned into defence, which is the entire point of the domain.

Pitfalls

• Writing the report as a narrative of your analysis. Readers need answers, not your journey through the disassembler. Lead with what/does/impact/IoCs; put the process as supporting depth.
• One report, one audience. IR, detection, and leadership need different things; serve each — at minimum a plain summary plus actionable IoCs plus technical depth.
• Burying or under-structuring the IoCs. They're the most operational part; type them, weight them by durability, and make them ingestible.
• Overstating certainty. Claiming full understanding when sections were packed/unanalysed misleads response decisions. State confidence and gaps.
• No recommendations. Analysis without "so do this" makes the reader do the translation; end with concrete actions for IR and detection.
• Skipping ATT&CK mapping. It's the shared language that makes the analysis comparable and feeds coverage — cheap to add, valuable to have.

References

• MITRE ATT&CK (technique mapping and the shared vocabulary)
• SANS FOR610 reporting guidance; malware report templates
• The extracting-iocs, yara-rule-writing, incident-response, detection-engineering, and threat-intelligence skills

Inputs

• Relevant source code, logs, network traces, or system specifications.

Outputs

• Analysis findings, security audit report, or generated code artifacts.