Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: Volatility: 2.2 is Coming Soon SANS ISC InfoSec Forums

Participate: Learn more about our honeypot network
https://isc.sans.edu/honeypot.html

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Volatility: 2.2 is Coming Soon

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
maintained.

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)

 

Kevin Liston

292 Posts
ISC Handler

Sign Up for Free or Log In to start participating in the conversation!