Last Updated: 2012-09-19 18:03:29 UTC
by Kevin Liston (Version: 1)
Volatility 2.2 RC1 is available and supports Linux images
The good folks in the Volatilty/Memory Analysis community have been pretty busy lately. Release candidate for version 2.2 has been recently published (http://code.google.com/p/volatility/downloads/list) which adds support for Linux and adds plugins addressing the Windows GUI. There is also a plugin that will pull the event logs from memory for XP and 2003. Take a moment to read through the release notes for 2.2 RC1: http://code.google.com/p/volatility/wiki/Release22
Month of Volatility Plugins
Last week, the Volatility Labs Blog started a Month of Volatility plugin series, to introduce the new features becoming available in 2.2 (http://volatility-labs.blogspot.com/2012/09/month-of-volatility-plugins-movp.html) Final release for 2.2 should be available in October.
Using Volatilty in the Workplace
I've employed volatility in a couple different ways in the workplace. Gathering a memory snapshot was added to our malware response process, so adding a few default volatility jobs to the analysis procedure made sense.
In other instances, it was used in an ad hoc fashion, depending on the particulars of the case. When used in this manner, I would install volatlity in with the case file itself, and scripts were used to create any volatility output that was later used in the write-up. While this was a waste of disk-space, it allowed for others to reproduce my work, and this was in the early days of Volatility where updates might break plugins that I'd used in a case. Now we're moving towards using a VM for each case so that the entire too-lset used in the investigation is
Dealing with Upgrades
In both methods, I'm still faced with how to deal with updates to the tool. In the former I run the risk of breaking the process. In the latter, it's not as big of a deal, since I would install the latest whenever a case was started. It may be a good idea to keep a couple of versions of volatility installed due to plugin dependencies.
When a particular finding is crucial in a case, it makes sense to verify that finding using different tools. Compare your volatilty results with those from say, Mandiant's redline or memoryze, or whatever commercial memory analysis tool you enjoy.
You should also follow a similar process with new versions of plugins. Test the new version on an old case's memory image (or compare using some of the example memory captures here: http://code.google.com/p/volatility/wiki/PublicMemoryImages)