SANS Digital Forensics and Incident Response Blog

Digital Forensics How-To: Memory Analysis with Mandiant Memoryze

Mandiant's Memoryze tool is without question one of the best forensic tools available. It is an incredibly powerful memory analysis suite that should be part of every incident responder's toolkit. It's free, but requires some patience to traverse the learning curve. Memoryze was built by Jamie Butler and Peter Silberman, a couple of hardcore memory / malware analysts that operate on a completely different level than most of us mere mortals. In this post I'll cover how to get started with Memoryze, because if you haven't added memory analysis to your intrusion investigations, there is a whole lot of evil out there that you are missing.

Getting Started

The first step is to go out and download the tool. An important thing to keep in mind is that Memoryze actually consists of two components: Memoryze and Audit Viewer. Each must be downloaded individually from the free tools section of the Mandiant site. The two tools are divided logically by function: Memoryze for data collection and analysis, and Audit Viewer for presenting and interacting with the collected information. The split is also for practical purposes — the code behind Memoryze is taken from Mandiant's MIR commercial incident response product, which should ensure continued support and development in the future.

Installing Memoryze on Removable media

Before adding Memoryze to our incident response kit, we first need to get it installed. I typically keep a copy on a large USB thumbdrive, but you can put it virtually anywhere, including on a CD/DVD. The process is simple:

msiexec /a MemoryzeSetup.msi /qb TARGETDIR=portable_drive_and_folder

This copies the necessary files to the portable drive, but there is one more step. Several configuration and settings files are created the first time you run Memoryze. So if you plan on putting it on read-only media, make sure you run it at least once from a writeable location.

While you are at it, go ahead and extract Audit Viewer to a folder on your removable device (no installation necessary). It can be handy to have this tool with you when you are away from your forensic workstation and need to quickly look at a memory image.

Acquiring a Memory Image

The easiest way to acquire an image is using Memoryze via the command-line. Audit Viewer has a mechanism to capture an image as well, but we'll cover that in a later section. A batch script is included called MemoryDD.bat. MemoryDD generates a settings script and calls memoryze.exe with the proper parameters.

G:\memoryze\MemoryDD.bat —output G:\images

Your results will be placed in a nice folder structure allowing multiple memory images to be stored in the same output folder without confusion. Output folders are formatted in the following manner:

.\Audits\[Machine Name]\[Date/Time of Acquisition]

While the acquisition process is easy, that doesn't mean it is always foolproof. Memoryze requires loading a kernel-level driver, giving access to raw memory. No driver, no memory image. Several things can prevent the driver from being loaded, with the most common being not running the tool from an Administrator account (or an Administrator-level command prompt). Another common hindrance is anti-virus software. Malware also tries to access memory and as such any anti-malware solutions present may need to be disabled so they don't block driver installation (see Figure 1). If you are still failing to get an image after checking these things, I recommend trying a different acquisition tool. I always keep backup tools like win32/64dd.exe and FTK Imager handy because even slight differences in a tool's implementation can sometimes make a difference on a peculiar system.

Figure 1: Driver Installation FailureFigure 1: Driver Installation Failure

Opening the Memory Image for Review

A key point to keep in mind is that Audit Viewer can be used to analyze and view any raw memory image — not just those captured by Memoryze. That being said, we first need to take a step back and determine what operating system (OS) the memory image came from. Memory structures can vary significantly by operating system, and even by patch level. Thus every memory analysis tool must be specifically written to parse structures from a given OS. I can't tell you how many times I have had someone tell me that Memoryze is broken, just to find they are trying to analyze an unsupported platform like Windows XP SP 1. Lucky for us, Memoryze supports a wide range of the most common Windows platforms:

  • Windows 2000 Service Pack 4 (32-bit)
  • Windows XP Service Pack 2 and Service Pack 3 (32-bit)
  • Windows Vista Service Pack 1 and Service Pack 2 (32-bit)
  • Windows 2003 Service Pack 2 (32-bit)
  • Windows 2003 Service Pack 2 (64-bit)
  • Windows 7 Service Pack 0 (32-bit) - beta
  • Windows 7 Service Pack 0 (64-bit)
  • Windows 2008 Service Pack 0 (64-bit) - beta

A memory image from a non-supported system is still valuable; it just can't be analyzed using this tool. Regardless of the current support available, you should still acquire a memory image. Though you may have to perform manual analysis or wait until a tool arrives that supports that platform.

Assuming our image is from a supported OS, we will use Audit Viewer to open it for analysis. Run auditviewer.exe and select "Configure Memoryze" (Figure 2). While tempting, ignore the option "Open Existing Results" — it refers to re-opening an existing analysis file.

Figure 2: Configure MemoryzeFigure 2: Configure Memoryze

Click next and tell AuditViewer where your copy of memoryze.exe is located and where you would like to save the analysis results (Figure 3).

Figure 3: Specify PathsFigure 3: Specify Paths

Next tell AuditViewer to analyze "dead" memory and browse to the location of the memory image just acquired. (Figure 4)

Figure 4: Analyze Dead MemoryFigure 4: Analyze Dead Memory

Finally, the AuditViewer wizard will step you through a series of analysis and acquisition options. Instead of covering these ad nauseam, I'll use this opportunity to point you towards the excellent user guide (Userguide.pdf) that is included within the AuditViewer archive. Mandiant does a great job of documenting their tools, and this is no exception. At the conclusion of the wizard, a progress meter is displayed, culminating in an interactive view of all of the identified processes and their corresponding dlls, handles, memory sections, etc. Expect processing to take some time, particularly if some of the more computationally intensive options were chosen.

Figure 5: Successful Loading of Dead MemoryFigure 5: Successful Loading of Dead Memory

A full primer on conducting memory analysis is out of scope for this How-To, but as a starting point I did want to mention a couple of tips. First, you need to double-click the process you are interested in to populate the tabs on the right-hand side of Audit Viewer. Second, look for the "Occurrences" column available in some of the tabs. This feature is based on the Least Frequency of Occurrence (LFO) work that Peter Silberman has been touting. The idea is simple, but very powerful: malware artifacts tend to be relatively unique across a filesystem or an enterprise. By focusing on those outliers, you can often quickly identify a malicious dll or registry key.

Performing Live Memory Analysis

If memory analysis is finally coming into its own, then live memory analysis is the new cutting edge. I credit Memoryze with bringing this technique into the mainstream. It turns out that performing live memory analysis has some valuable benefits beyond just triage. When Memoryze is utilized in live mode, it can include the system page file in its analysis as well as perform digital signature checks on all loaded executables. This information is fed back into Memoryze's Malware Rating Index (MRI), providing an amazingly fast way to identify a wide range of malware. For more information on MRI, check out Silberman describing it on Mandiant's blog (

Performing a live analysis is relatively simple. Plug your removeable device into the system you wish to analyze and execute AuditViewer. Similar to opening a dead memory image, point AuditViewer to the Memoryze and output paths. Then select "Acquire (and/or) Analyze Live Memory (Figure 6). The rest of the wizard options will mirror those covered previously with the exception of additional features being available (like digital signature checks). At the completion of the wizard, Memoryze will begin to analyze the host system's memory, showing the AuditViewer GUI when complete.

Figure 6: Analyze Live MemoryFigure 6: Analyze Live Memory

Keep in mind that just because you are doing a live analysis doesn't mean that you can't also take a memory image first. In most instances I recommend doing both. You never know when you may want to go back and look for something in that original memory image. To acquire a memory image using audit viewer, make sure to select "Memory Acquisition" when prompted for which acquisition methods you would like to use (Figure 7). This is easy to miss, so read carefully!

Figure 7: Acquire Memory during Live AnalysisFigure 7: Acquire Memory during Live Analysis

Additional Reading

Dave Hull finds malware using Memoryze

Russ McRee's excellent ISSA article on Memoryze

Memoryze Forum

Chad Tilbury, GCFA, has spent over ten years conducting computer crime investigations ranging from hacking to espionage to multi-million dollar fraud cases. He teaches FOR408 Computer Forensic Essentials and FOR508 Computer Forensic Investigations and Incident Response for the SANS Institute. Find him on Twitter @chadtilbury or at


Posted November 8, 2010 at 2:58 PM | Permalink | Reply

Rob Lee

Great Article Chad!
The biggest complaint I hear on memoryze is that it takes too long to execute (sometimes a full day). This can easily be avoided by minimizing the analysis techniques and not being to "check happy" with auditviewer.
There is a tendency to "check all boxes" when using memoryze. For example, simply adding the check for "extract strings" will take a long time. I asked Peter Silberman what options should be checked when auditing processes to enable analysis more quickly. He mentioned that "extract strings" should probably not be checked on first pass as it could take hours to produce results. If you acquire the memory image you could extract strings overnight.
Only check what you need. If you are not familiar what "Hook detection" or "driver enumeration" will accomplish, Id recommend to stick with the basic "Process enumeration" and then check most of the options except "extract strings."
Memoryze also gives you the ability to obtain hashes when you accomplish a live analysis/acquisition (MD5 and Sha). Remember this will hash every dll and program associated with the process. This could take considerable time. Do not select ALL the hash formats. Only select the one you will use. Generally, I find md5 sufficient.
Again great article'' if anyone else would like to post on case studies using Volatility, HBGary Responder, or Memoryze please send an email to anyone on the blog author team and we would love to have you guest author.

Posted November 8, 2010 at 7:45 PM | Permalink | Reply

Dave Hull

I've been putting Memoryze through its paces of late in an enterprise environment. I haven't had issues with the analysis taking a long time, but there are times when pulling a memory image off of a remote system can take hours due to slow links, even with compression enabled. If you can narrow the list of suspects to a select few processes, dumping those rather than the entire system memory will obviously speed things up, but sometimes that's not possible when relying on built-in utilities to show network connections and processes (i.e. if the box has been rootkit'd).

Posted November 18, 2010 at 3:12 PM | Permalink | Reply

Andrew Tappert

I agree wholeheartedly on the importance of memory acquisition and analysis during an investigation, and not just on Windows. Check out Second Look for Linux memory forensics, from my company, Pikewerks.