A malware reverse engineering pass is finished when it hands the SOC eight things it can act on, not when the analyst runs out of functions to read. That standard matters more now that commercial protectors are routine in malware. MITRE ATT&CK tracks them as sub-technique T1027.002, Software Packing, and protected samples are exactly where reports go vague.
This checklist is for analysts writing up a sample and for SOC and IR leads deciding whether a report is done. It covers what to deliver, how to mark findings you couldn't prove, and what changes when the sample is VM-protected.
What should a malware reverse engineering pass produce?
A malware reverse engineering pass should produce eight things for a SOC: a short summary for decision-makers, the observed behavior across files, processes and network, the persistence mechanisms and triggers, indicators of compromise ready for detection rules, the recovered functions in a format analysts can keep working in, the configuration and C2 details found, the analysis limits, and a statement of how sure each finding is.
Sandbox output covers part of this. Reverse engineering exists for the rest: the branches that didn't fire in the lab, the configuration that was encrypted at rest, and the honest answer to "could it have done more than we saw?"
The checklist
Copy this into your report template:
- [ ] Summary that a non-analyst can act on in two minutes
- [ ] Behavior: files, registry, processes, network, each marked observed or inferred from code
- [ ] Persistence and triggers: how it survives a reboot, and what makes it act or stay dormant
- [ ] Indicators of compromise: hashes, domains, IPs, mutexes, file paths, ready for detection rules
- [ ] Configuration and C2: decrypted config, keys and campaign identifiers, with how they were recovered
- [ ] Recovered functions in a format the next analyst can open
- [ ] Analysis limits: what was out of scope, and what couldn't be reached
- [ ] Confidence per finding: proven, depends on runtime, unresolved, or bounded
Summary for decision-makers
Two or three sentences. Name the malware family if you're confident, what the sample can do, whether it ran in your environment, and what to do now. Leave the opcodes for the appendix.
Behavior: files, processes, network
List behavior in two columns, observed (it happened in the lab) and from code (the code can do it, but it didn't fire). Incident leads scope containment from the second column.
Persistence and triggers
Persistence answers "will it come back?" Triggers answer "why didn't it do anything in the sandbox?" Common triggers are dates, a reachable C2, locale or keyboard checks, and anti-VM checks. List each one with the condition it waits for.
Indicators of compromise
Ship IOCs in a form your detection pipeline ingests directly. Prefer behavioral and code-based indicators over the sample hash, which changes with every rebuild.
Recovered functions you can keep working in
Give the next analyst your work, not just your conclusions: an IDA or Ghidra database with your names, types and comments, or annotated pseudocode for the key functions. A PDF of screenshots can't be searched, diffed or extended.
How sure each finding is
This is the item most reports skip, covered in the next sections.
What changes when the sample is VM-protected?
A VM-protected malware sample is one where some functions were translated into bytecode for an interpreter embedded in the file. A decompiler shows the interpreter's dispatcher loop and handlers instead of the logic, so static findings for those functions are missing until someone traces or devirtualizes them.
Two things follow for the deliverable:
- Say which functions were virtualized. A report that silently skips them reads as complete when it isn't.
- Check before assuming. A June 2024 ANY.RUN study of Themida- and VMProtect-protected samples from five families found that none of them used the protectors' code virtualization; the protectors were used much like basic packers.
How to mark what was not proven
A reverse engineering report should label each finding by how it was established, rather than presenting every function as equally certain. One way to do this is Devirt's four proof states: proven, runtime-dependent, unresolved and permanently bounded. Each in-scope function stays in the count in exactly one of the four states, so an unproven function can't silently drop out of an incident note.
| State | What it means in a malware report | Example |
|---|---|---|
| Proven | The recovered logic is shown to match the sample | String decryption routine, verified against decrypted output |
| Runtime-dependent | The result depends on something not available | A command handler that needs the C2's real response |
| Unresolved | Not recovered with the evidence available | A virtualized function nobody traced |
| Permanently bounded | Can't be recovered, and the reason is known | Code that relies on a key held only on the victim machine |
The runtime-dependent row does the most work in malware reports. It keeps "we didn't see it do X" from turning into "it can't do X". The proof-state article explains each state.
Handling live samples safely
Live malware samples should only be analyzed in an isolated environment with no route to production networks, and kept out of shared storage once the analysis ends. A service handling samples for a SOC should state where samples run, whether they're shared or used for training, and when the input is deleted.
Ask any third party those three questions in writing. Devirt's answer, for example, is published: uploads run in an isolated environment, aren't shared between customers or used for training, and input deletion begins once processing finishes and the output is available.
Where outside recovery fits
When the functions you need are virtualized and the deadline is short, an automated devirtualization service can return them in the deliverable formats above. Devirt returns an authorized sample's recovered functions as an IDA database (.i64), annotated pseudocode, a full RE report and API JSON for your own pipeline, each with the coverage ledger. An unfamiliar build can start with a free assessment. Its page for malware analysts explains the scoping. Malware analysis and defensive threat intelligence are accepted uses; deploying or improving malware is not.
Further reading
- Reverse engineering malware: what it is and where it stops: the static and dynamic basics
- What a malware reverse engineer actually does: the job, case by case
- Protected binary analysis workflow: the stages from triage to recovered code
Written by Devirt, an automated devirtualization service for authorized analysis of protected software.
Top comments (0)