One of the more common questions that people ask in the FOR610 (reversing) class is about writing malware reports. Specifically what should go into a malware report?
The Guiding Principle
When I get asked this question my first response is usually "well why did you do the exam?" Besides potentially being a bit cheeky, the reason I ask this question is because it highlights the fact that malware analysis is something that's usually done to facilitate investigations, incident response, etc. So the heuristic to use when deciding what to put into a malware report falls along the lines of "include whatever supports the purpose of the exam".
Now that's all fine and dandy in many situations, but what if you don't know how your results will be used? Perhaps the examination is being done fairly early on in the investigation. Another common scenario is to be brought in and given a specific task (e.g. analyze this specimen) and that's all that you are told.
Common Things in Malware Reports
If for whatever reason you aren't sure what to put in your malware reports, here is a list of things I commonly include:
Also known as the "executive summary" this is a short summary of what you found out during the examination; using technical terms sparingly. Unlike most forensic reports, I usually try to keep this to no more than a few sentences. The thinking is that most people who will read a malware report will only read this section.
If there were any specific questions (e.g. what is the purpose of XYZ?) that were asked, I usually answer them right after the general overview. The reason is that these usually drive the examination itself, and are what most people are interested in. Titles of these sections often fall along the lines of:
- ABC.txt (or whatever file is of interest)
- Communication with IP address: (IP address of interest)
- How the malware is installed
After answering any specific questions (if they exist) it's also a good idea to document how the specimen interacts with its environment. Depending on the specimen itself, this might come from behavioral analysis, although more and more I'm seeing malware that requires a fair amount of code analysis to yield anything useful.
Things that can go here include:
- Persistence mechansisms (how the specimen survives things like reboots)
- Installation procedures (how the specimen is installed / gets on the system)
- Registry interactions
- File system interactions
- Network interactions
This section is for the more technical stuff that you uncovered during the examination. Things like custom encryption/decryption routines, proprietary file formats, etc.
Since many malware examinations are used to support incident response, information that helps containment and remediation processes is often useful. I've found that listing the forensic footprints (i.e. the artifacts that are left behind by the specimen) can help stuff like:
- Creating scripts to identify the specimen on other systems
- Creating network signatures to help identify specimen related activity on the network
- Determining how to recover from specimen-related damage
This tends to be the last section, and is where you can include further actions that you think are appropriate based on your findings. This can be anything from incident-specific activities (e.g. how to contain an incident) to things like recommending further analysis (if you are under time constraints.)
Wrapping it Up
Not every examination report will include all of these sections, and if your organization has a particular format (e.g. some places require document control numbers, etc.) make sure to follow policy.
Other than the things listed here, I'd be curious to hear what other people commonly include in their malware reports. Feel free to leave your suggestions in the comments below. :)
Interested in learning how to analyze malware?
Mike Murr and Lenny Zelster will be teaching FOR610: Reverse Engineering Malware online through vLive starting June 5th, 2012.
If you register by May 14th you can get a free Macbook Air or $850 discount on the class!