Malware Analysis

If you do malware analysis as part of your DFIR activities, check out this post from the System Forensics blog; what I really like about the post is not just that the testing environment is described in a pretty thorough manner, it's also that this is someone doing malware analysis who runs PEView against the file to be tested, rather than simply running strings!  In fact, not only is PEView used in the static analysis of the malware, so is PEiD and Dependency Walker, both very useful tools that are used to great effect in this post to illustrate some important artifacts of the EXE being analyzed.  The post also lists an impressive set of tools used for dynamic analysis of the malware (including CaptureBAT).

The post continues with dynamic analysis of the malware...if you're new to this sort of thing, this is an excellent post to read in order to get yourself up to speed on how to go about performing dynamic analysis.  It also illustrates some of the important artifacts and IOCs that can be derived, not just from analysis of the malware, but in communicating the analysis and results to another part of the IR team.

Some thoughts on what might prove to be very useful...

MFT analysis, particularly with respect to the batch files mentioned in the post.  For example, if the MFT is extracted and parsed, and the record for the tmpe275a93c.bat file still exists (even if it's marked as not in use), it might be a good idea to see if the file is resident or not.  If it is (batch files don't need to contain a great deal of text to be useful), then the contents of the file could be extracted directly from the MFT record.

While it may seem to be providing redundant information from a purely malware analysis standpoint, enabling a greater level of auditing on the system (enabling Process Tracking, for example), as well as increasing the size of the Event Logs, would prove to be useful, particularly for those without the funding or budgets, or the time, for more expansive tools.  When it comes to response, having relevant data is critical...yet, even when shortcomings are identified (i.e., "I really could have used information about processes that had been launched..."), many times we're not able to get the tools we need in order to answer the critical questions next time.  So, if you have come to realize the value of tracking which processes had been launched, but can't get something like Carbon Black, then perhaps enabling Process Tracking on systems and increasing the size of the Event Log files is something of a happy medium.  After all, it doesn't cost anything, and may provide you with some valuable information.

With the transient nature of the processes listed in the post (particularly WinMail), I would think that something like Carbon Black would be an excellent tool to have installed in a malware testing environment, particular the next version (due out next month) that includes monitoring of Registry modifications and network initiations.

There might be great benefit in more extensive Prefetch analysis, particularly with respect to some of the other processes that were created (i.e., WinMail, etc.).  Corey recently took a second look at Prefetch file analysis, and turned up some pretty interesting artifacts, and illustrated how there's more to Prefetch file analysis than just getting the last execution time and the runcount.

Something else to keep in mind when testing malware like this...you need to separate the malware IOCs from the "self-inflicted" artifacts; if you have a sample and not other information regarding the propagation mechanism of the malware, then there will likely be some artifacts that are created as a result of the testing environment, as well as the method used to initiate the malware itself.

Finally, there can often be far more value to malware analysis, particularly from an intel/counter-intel perspective, something that was recently discussed on the MalAnalysis blog.

Resources
MS Free Safety Scanner