Memory Collection and Analysis Tools
Recently, there was a post on the SANS Forensics blog about memory collection and analysis tools, but for some reason, it seems that folks are STILL having trouble with this process; I'm seeing posts in forums (forii??) saying that "...this tool doesn't work..." or "...that tool crashed when I tried to use it...". My suspicion is that the tools aren't being used correctly as folks may not understand their limitations.
Collection
I tend to separate collection and analysis...I've found that it's better to do each one right separately than it is to try to do both at the same time and split your resources.
XP/2003
There are a number of tools that allow for collection of physical memory on Windows XP and 2003 systems. The first and perhaps best known was a version of dd.exe modified by George M. Garner, Jr. This tool is no longer available, but it was used as the exemplar tool for collecting physical memory for the DFRWS 2005 Memory Challenge. Another tool is dcfldd.exe, written by Nick Harbour (currently with Mandiant). However, this blog post is one of several locations where it seems that someone's discovered that attempting to dump the \\.\PhysicalMemory object doesn't work, but dumping /dev/mem (yes, on Windows) appears to have an affect. Nigilant32 is a GUI-based tool that you can use to dump the contents of RAM, as well.
These tools are also available on the Helix CD. In addition, HBGary released their fastdump tool for dumping physical memory.
The delineation mark for the tools came with Windows 2003 SP1, as that's when MS removed user-mode access to the PhysicalMemory object. This, in turn, required a change in tools to collect physical memory.
2003 SP1 and Above
The tools used to collect the contents of physical memory for Windows 2003 SP1 and above (Vista) systems can also be used on XP and 2003 systems.
The first tool available to dump (and analyze) the contents of Physical Memory from Windows 2003 SP1 systems and above was the KntTools from George M. Garner, Jr. Then came ManTech's MDD, Matthieu Suiche's win32dd, GSI's winen (and winen64, for 64-bit systems), and Mandiant's Memoryze. All of these are great tools, but like any tool, each has it's strengths and weaknesses.
For example, right on the main page for the MDD tool, it states, "The software can copy up to 4 GB of memory to a file for later analysis." I'll leave it to smarter folks to tell you why, but I think that most tools have this same limitation. Matthieu's win32dd will dump memory in a raw, dd-style format as well as a crash dump-compatible format in case you'd like to use MS Debugger tools to analyze the dump. GSI's winen dumps memory in the EWF-style format (requires additional support for most tools to analyze). While most of the other tools download as an EXE, Memoryze downloads as an MSI file, and creates quite a footprint on the system.
One tool that must be mentione
d here is F-Response. By itself, F-Response does not provide the capability to dump the contents of physical memory, but the most recent version of F-Response provides you with remote, read-only access to physical memory on Windows systems; you can then use tools like FTK Imager, or any other acquisition tool (dd.exe, dcfldd.exe, etc.) to acquire your memory dump. The figure I've posted here shows what physical memory on a remote system "looks like" on your investigation system...in this example, it shows up as \\.\PhysicalDrive2, and can be accessed by tools such as FTK Imager. Go here to see how to install F-Response EE remotely on Windows systems.
All of these tools work best if tested and deployed before an incident occurs, before the tool itself is actually needed. Tools such as mdd.exe and win32dd.exe can be deployed on CD or a thumb drive, and F-Response can be deployed remotely (even in stealth mode) over the network, allowing you to accelerate your response.
Note: I don't want to leave out hibernation files. While I don't recommend hibernating a system as the default process for collecting the contents of physical memory, there may be times when its the only option. For example, if a system already has a hibernation file on it, IMHO, I'd prefer to use that file for historical analysis, to establish or validate a timeline of activity on the system. However, if the system is capable of hibernating, there may be times when forcing the system to hibernate may be the only way to collect the contents of physical memory. You can use powercfg.exe to configure the system to hibernate, and then use run32dll.exe to force it to hibernate.
Analysis
There are some frameworks available that provide a means of analysis on memory dumps from several versions of Windows, such as Andreas's PTFinder Collection. Andreas's Perl scripts are primarily used to list processes (and pool tags) from within Windows memory dumps.
About the only tools I can think of that provide more than what Andreas's scripts provide for analyzing Windows 2000 memory dumps are my own scripts, which are still available on SourceForge, as well as on the Windows Forensic Analysis DVD (and they will be provided on the DVD with the second edition of WFA).
When it comes to analyzing memory dumps from Windows XP SP2 and 3 systems for an incident response perspective, the Volatility Framework is the way to go. Yes, I know it's CLI, requires Python (which is free), but to be honest, this framework gives you unprecedented access to the contents of the memory dump. I say "contents" because not only can you get things like the active process list and active network connections at the time of the dump, but you can also run a linear scan through the dump for exited processes and expired network connections. The DFRWS 2008 Rodeo includes a memory dump you can try this out on. The output of the various commands can be easily redirected to files, and then correlated using Perl or Python scripts (such as vol2html.pl).
Volatility includes the capability of working with hibernation files (incorporating Matthieu's work; note that Matthieu has also released a standalone hibernation shell, in alpha) and crash dump-format memory dumps, in addition to the raw, dd-style format dumps. Also, Volatility is extensible, and others have taken the opportunity to create modules that can be easily installed and used with the framework (ie, Jesse Kornblum's cryptoscan and suspicious modules, and Moyix's Windows message queue module).
Addendum: I've recently seen the release of additional plugins; malfind from MNIN Security, and moddump from Moyix. I've gotta take a look at and try these plugins...man, it's it AWESOME the way Volatility can be extended??
Note: This is one of those places where I have seen folks say, "It doesn't work." As of now, Volatility works on XP SP 2 and 3 memory dumps. Please feel free to try it on other memory dumps, but as a courtesy, please refrain from stating "it doesn't work" (most of us already know that), as well as asking "why doesn't it work?" Thanks!
Mandiant's Memoryze is an XML-based tool that started life as part of the Mandiant Intelligent Response (MIR) product, and will allow you to collect and analyze memory dumps from Windows XP, 2003, and Vista systems. To install Memoryze, download the MSI file and the installation wizard will guide you through the process. Memoryze ships with a number of batch files that make it a bit more user-friendly, and Mandiant also include the Audit Viewer, a wxPython-based GUI tool that makes viewing the output of Memoryze a bit easier. Posts on the M-unition blog that describe how to use and extend Memoryze.
Also, please feel free to use tools such as strings or grep to extract information from memory dump files. However, keep in mind that if these tools are run against the entire dump file, the information you find may be without context. However, using any of the available tools to dump process memory for a memory dump file, and then searching it using strings/grep will provide you with a modicum of context.
It wouldn't be fair of me not to note HBGary's Responder product. I had an opportunity to try out the Responder Pro product a while ago, and found it be very useful for malware analysis. I haven't had an opportunity to try the Field edition.
Collection
I tend to separate collection and analysis...I've found that it's better to do each one right separately than it is to try to do both at the same time and split your resources.
XP/2003
There are a number of tools that allow for collection of physical memory on Windows XP and 2003 systems. The first and perhaps best known was a version of dd.exe modified by George M. Garner, Jr. This tool is no longer available, but it was used as the exemplar tool for collecting physical memory for the DFRWS 2005 Memory Challenge. Another tool is dcfldd.exe, written by Nick Harbour (currently with Mandiant). However, this blog post is one of several locations where it seems that someone's discovered that attempting to dump the \\.\PhysicalMemory object doesn't work, but dumping /dev/mem (yes, on Windows) appears to have an affect. Nigilant32 is a GUI-based tool that you can use to dump the contents of RAM, as well.
These tools are also available on the Helix CD. In addition, HBGary released their fastdump tool for dumping physical memory.
The delineation mark for the tools came with Windows 2003 SP1, as that's when MS removed user-mode access to the PhysicalMemory object. This, in turn, required a change in tools to collect physical memory.
2003 SP1 and Above
The tools used to collect the contents of physical memory for Windows 2003 SP1 and above (Vista) systems can also be used on XP and 2003 systems.
The first tool available to dump (and analyze) the contents of Physical Memory from Windows 2003 SP1 systems and above was the KntTools from George M. Garner, Jr. Then came ManTech's MDD, Matthieu Suiche's win32dd, GSI's winen (and winen64, for 64-bit systems), and Mandiant's Memoryze. All of these are great tools, but like any tool, each has it's strengths and weaknesses.
For example, right on the main page for the MDD tool, it states, "The software can copy up to 4 GB of memory to a file for later analysis." I'll leave it to smarter folks to tell you why, but I think that most tools have this same limitation. Matthieu's win32dd will dump memory in a raw, dd-style format as well as a crash dump-compatible format in case you'd like to use MS Debugger tools to analyze the dump. GSI's winen dumps memory in the EWF-style format (requires additional support for most tools to analyze). While most of the other tools download as an EXE, Memoryze downloads as an MSI file, and creates quite a footprint on the system.
One tool that must be mentione
d here is F-Response. By itself, F-Response does not provide the capability to dump the contents of physical memory, but the most recent version of F-Response provides you with remote, read-only access to physical memory on Windows systems; you can then use tools like FTK Imager, or any other acquisition tool (dd.exe, dcfldd.exe, etc.) to acquire your memory dump. The figure I've posted here shows what physical memory on a remote system "looks like" on your investigation system...in this example, it shows up as \\.\PhysicalDrive2, and can be accessed by tools such as FTK Imager. Go here to see how to install F-Response EE remotely on Windows systems.All of these tools work best if tested and deployed before an incident occurs, before the tool itself is actually needed. Tools such as mdd.exe and win32dd.exe can be deployed on CD or a thumb drive, and F-Response can be deployed remotely (even in stealth mode) over the network, allowing you to accelerate your response.
Note: I don't want to leave out hibernation files. While I don't recommend hibernating a system as the default process for collecting the contents of physical memory, there may be times when its the only option. For example, if a system already has a hibernation file on it, IMHO, I'd prefer to use that file for historical analysis, to establish or validate a timeline of activity on the system. However, if the system is capable of hibernating, there may be times when forcing the system to hibernate may be the only way to collect the contents of physical memory. You can use powercfg.exe to configure the system to hibernate, and then use run32dll.exe to force it to hibernate.
Analysis
There are some frameworks available that provide a means of analysis on memory dumps from several versions of Windows, such as Andreas's PTFinder Collection. Andreas's Perl scripts are primarily used to list processes (and pool tags) from within Windows memory dumps.
About the only tools I can think of that provide more than what Andreas's scripts provide for analyzing Windows 2000 memory dumps are my own scripts, which are still available on SourceForge, as well as on the Windows Forensic Analysis DVD (and they will be provided on the DVD with the second edition of WFA).
When it comes to analyzing memory dumps from Windows XP SP2 and 3 systems for an incident response perspective, the Volatility Framework is the way to go. Yes, I know it's CLI, requires Python (which is free), but to be honest, this framework gives you unprecedented access to the contents of the memory dump. I say "contents" because not only can you get things like the active process list and active network connections at the time of the dump, but you can also run a linear scan through the dump for exited processes and expired network connections. The DFRWS 2008 Rodeo includes a memory dump you can try this out on. The output of the various commands can be easily redirected to files, and then correlated using Perl or Python scripts (such as vol2html.pl).
Volatility includes the capability of working with hibernation files (incorporating Matthieu's work; note that Matthieu has also released a standalone hibernation shell, in alpha) and crash dump-format memory dumps, in addition to the raw, dd-style format dumps. Also, Volatility is extensible, and others have taken the opportunity to create modules that can be easily installed and used with the framework (ie, Jesse Kornblum's cryptoscan and suspicious modules, and Moyix's Windows message queue module).
Addendum: I've recently seen the release of additional plugins; malfind from MNIN Security, and moddump from Moyix. I've gotta take a look at and try these plugins...man, it's it AWESOME the way Volatility can be extended??
Note: This is one of those places where I have seen folks say, "It doesn't work." As of now, Volatility works on XP SP 2 and 3 memory dumps. Please feel free to try it on other memory dumps, but as a courtesy, please refrain from stating "it doesn't work" (most of us already know that), as well as asking "why doesn't it work?" Thanks!
Mandiant's Memoryze is an XML-based tool that started life as part of the Mandiant Intelligent Response (MIR) product, and will allow you to collect and analyze memory dumps from Windows XP, 2003, and Vista systems. To install Memoryze, download the MSI file and the installation wizard will guide you through the process. Memoryze ships with a number of batch files that make it a bit more user-friendly, and Mandiant also include the Audit Viewer, a wxPython-based GUI tool that makes viewing the output of Memoryze a bit easier. Posts on the M-unition blog that describe how to use and extend Memoryze.
Also, please feel free to use tools such as strings or grep to extract information from memory dump files. However, keep in mind that if these tools are run against the entire dump file, the information you find may be without context. However, using any of the available tools to dump process memory for a memory dump file, and then searching it using strings/grep will provide you with a modicum of context.
It wouldn't be fair of me not to note HBGary's Responder product. I had an opportunity to try out the Responder Pro product a while ago, and found it be very useful for malware analysis. I haven't had an opportunity to try the Field edition.
