Home Contact

M-unition

The Ammunition You Need to Find Evil and Solve Crime

About Us

Welcome to M-unition, the MANDIANT blog. Here we share our insights about the tools we create and use to find evil and solve crime.

The changing battlefield in Memory

Written by Peter Silberman

Steve Davis and I gave a talk at Blackhat and at Defcon called Metasploit Autopsy: Reconstructing the scene of the crime. Giving the talk was a blast; both Steve and I were thrilled to be given an opportunity to give a defensive security talk on the Metasploit track.  During our talk and in several interviews, we stated that some aspects of computer security are a cat and mouse game. When you make a technique, tool, or other knowledge public people have a chance to analyze what you have done. This analysis can lead to better code, improvements to ideas, or in some cases the breaking of said tools. In the case of Metasploit Forensic Framework (MSFF), the newest release of Metasploit flat out broke MSFF. First, let me give you some background. When we first started writing the tool, we quickly realized that breaking MSFF would take a single line change to Meterpreter. The fix is simple. In our talk, we discussed that when meterpreter called free the received/sent packets were not scrubbed and lay around memory for hours. MSFF capitalized on this using Memoryze to acquire the processes address space which included the process’s freed memory.  HD and crew were nice enough to wait to patch Meterpreter until after our talk. Meterpreter was patched Saturday with memset’s, which zero out the packet data before the memory is freed.

With this fix, our current technique to reconstruct what Meterpreter sent or received does not work. The Metasploit project has broken that ability successfully (something we expected). Our detection will evolve, and HD discussed some ideas he had to make detecting the Meterpreter binary harder. Currently, MSFF can still be used to identify the injected binaries in a process’s address space. The Meterpreter binary contains too much code and has too many features to effectively hide in memory. If and when HD patches the reflective loader to scrub Meterpreter’s binary data, we’ll update MSFF with some fix, more as a proof concept than anything else, to continue to identify the injected DLLs. Hope everyone’s recovered from Vegas!

A huge thanks go to Ping, Nikita, Jeff Moss, Val Smith and HD for putting the Metasploit track together. It was not easy, but it went great. A huge thanks to the defcon speakers, who were very flexible.

Tags: , , , , , ,

. 13 Aug 09 | General | Comments (0)

MindSniffer, Updated Audit Viewer released

Written by Peter Silberman

I’m currently writing this blog post from my hotel room at Blackhat Federal. Jamie and I wrapped up our “Advanced Memory Forensics in Incident Response” class on Tuesday. It went very well and we are both looking forward to teaching it again in Las Vegas. I just finished giving my talk “Snort my Memory.” I detailed the talk in a previous blog post. This post now includes links to available software. MindSniffer is available here. If you have any questions comments suggestions please feel free to contact me peter.silberman@mandiant.com.
Following the release of MindSniffer I am thrilled to announce a NEW version of Audit Viewer. This version includes the following features:

  • Process are marked in red if they have injected dlls
  • View imports/exports of PE files in memory. This can be done by right clicking on memory sections
  • Signature Manager built into Audit Viewer to support py files generated by MindSniffer
  • Added sections and semaphore handle types
  • Memoryze Launcher – this a GUI wrapping Memoryze and allowing you to configure Memoryze all from a user interface. No more batch scripts or xml files. To utilize Memoryze Launcher, click “Launch Memoryze.” You can configure multiple jobs to run at once once they will all run, then the results are auto loaded into Audit Viewer for easier integration. This is a huge feature and I’m very excited to get feed back on it.
  • Numerous bug fixes
  • Updated documentation

Grab the new audit viewer at its new location Audit Viewer
Please feel free to e-mail comments suggestions ideas and anything else you think I should know regarding Audit Viewer.
Enjoy,
Peter

Tags: , , , , ,

. 19 Feb 09 | General | Comment (1)

Memoryze now supports Vista SP1 and F-response

Written by Jamie Butler

Vista

If you ever tried to run Memoryze on Vista, you may have been pleasantly surprised to find it already supported memory acquisition on this platform. It was designed with that in mind from the start, but it was still kind of cool when I tested it and it worked. Now, I am happy to report that Memoryze 1.3.0 has beta support for memory analysis on Vista SP1.

 

What does beta support mean? Well since Memoryze has moved ahead of the roadmap for MANDIANT Intelligent Response with this Vista rollout, we have not had the months of testing on this platform or at an enterprise level with all the possible configurations.  That said, we do have two known issues:

 

  • Memoryze 1.3.0 does not yet support port enumeration on Vista.
  • When enumerating sections, Memoryze may find process sections that are invalid (they have been freed and are no longer in use). These invalid sections may have incorrect start addresses or a size that is too large because the kernel has overwritten part of the section data. This only becomes an issue if you are enumerating strings and Memoryze hits an invalid section range. This will result in extremely long run times for the audit (imagine trying to find all the strings in a 600 MB section).

 

Should I download Memoryze 1.3.0 if I am not concerned with analyzing Vista memory? Yes, we have made many improvements in this release related to sanitizing the dataset.

 

F-response

While testing this release, we thought it would be cool to try Memoryze in conjunction with F-response. F-response can expose a remote host’s memory as a physical drive and Memoryze can open that physical drive just like a saved memory image and analyze it. When running against an image, Memoryze always checks the size of the file so it does not seek past the end of the file during analysis. The only tweak we had to make was to make that check a disk size check as opposed to a file size check.

 

How do you use Memoryze with F-response? Simply setup F-response according to the directions and set your input file in Memoryze’s batch scripts to \\.\PhysicalDrive2 or whatever drive F-response exposes as the target’s memory.

 

I would like to thank Matthew Shannon for providing me with an evaluation license of F-response.

 

Download Memoryze 1.3.0 now!

 

Jamie

Tags: , , ,

. 09 Feb 09 | General | Comment (1)

Memoryze is the 2008 Toolsmith Tool Of the Year

Written by Michael J. Graven

Russ McRee recently wrote that Memoryze is the 2008 Toolsmith Tool of the Year, and how it helped him find the full name of a malware author. He also wrote up a great description of using Memoryze to chase down a password stealing trojan in the February 2009 issue of the ISSA Journal.

 

One of the interesting things about Russ’s approach in both cases is his use of the strings option. It turned up some great investigative information. However, strings generates a lot of data, and in a large environment that could be a bit of a challenge (imagine running Memoryze on, say, 20,000 systems.) But on the third hand, what if one of those strings in memory is truly your best indicator of compromise?

 

The key to solving that problem – large-scale searching for very specific information – is prefiltering the results (and indexing them). Using an XPath expression to match only your desired indicator-of-evil lets the investigator focus on just the relevant data. It also lets you scale up the search to very large numbers of systems.

 

We’ve built our Intelligent Response product for exactly that need, including features from Memoryze as well as other IR tools. If you’d like to hear more about it, or see a demo, drop me a line.

Tags: , , , , ,

. 05 Feb 09 | Products | Comment (1)

Live analysis and its footprint

Written by Jamie Butler

Recently there was a conversation on Harlan’s Windows Incident Response blog which mentioned the footprint of Memoryze and other tools. Every tool has positives and negatives depending on the use case.

 

First, the blog entry mainly mentions the footprint on disk, which is larger than other acquisition tools because Memoryze does both acquisition and analysis in the same package. What you may not have known is that Memoryze runs completely fine from a USB key. You can install Memoryze to your USB key and use it on the target machine. This mitigates the concern of a large disk footprint.

 

Second, Matthieu Suiche pointed out that some may be concerned with the memory footprint as well. Because Memoryze is a portion of MANDIANT Intelligent Response, it was built with the enterprise in mind. In an enterprise, it is not practical to acquire and bring back 15,000 or 20,000 memory images to analyze offline. With compression, analysis, and filtering capabilities, Memoryze’s memory footprint is larger. How do you mitigate this? We make use of the paging file(s). So if we force a page out of memory, Memoryze can still analyze it from the paging file(s).

 

Why do you do live analysis? First, as I stated above, it simply is not practical to bring back an image of RAM off of every host when the number of hosts grows larger than you can count on a hand or two. Second, by doing live analysis, we can make use of the paging file(s). If we were to acquire memory and then acquire the paging files, the synchronization issues between the two would be more severe. Third, the risk of doing the analysis on the host is similar to the risk associated with acquiring memory on the host. A.) The attacker can block access to physical memory, or B.) as Darren Bilby pointed out in his talk at Ruxcon06, the attacker can intercept the calls to map the view of physical memory. Sidebar: It is necessary to map portions of physical memory into your address space in order to acquire or analyze memory. Both attacks are possible when doing acquisition or analysis. If attack A is carried out, memory acquisition tools including Memoryze will error out. If attack B is used, neither acquisition nor analysis tools will be effective. Joanna Rutkowska demonstrated the equivalent of attack B even when doing hardware acquisition. However, attack B also requires the attacker to know the physical address of their malware in memory.

 

Thanks to Matthieu for engaging me in this discussion. If you have not read his work on the hibernation file in Windows, it is very interesting.

 

Jamie Butler

 

By the way, you may be asking yourself why you cannot run Memoryze or other acquisition tools from a CD. Basically, Microsoft will not load a driver from a CD. It must first be copied to the local host. This is similar to trying to map a network drive with Memoryze and using it. Microsoft will not allow you to load a driver that is located on a network share. Check back in the coming weeks. We just might copy that single driver file to the local host so you can run it from a CD.

Tags: , , , , , ,

. 14 Jan 09 | General | Comments (0)

Integrate EnCase, Memoryze, and Audit Viewer with MemScript

Written by Kelcey Tietjen

Memoryze is a great tool for memory analysis, but what makes it even stronger is that it can be integrated with other tools to help with incident response.  These other tools can be leveraged to bring Memoryze’s capabilities to remote hosts. If your organization has not deployed or piloted MANDIANT Intelligent Response (MIR), you can use Encase Enterprise Edition (EEE) to gain access to remote memory. Just like with MIR, using EEE you are able to collect volatile data with “snapshots” and also have the ability to access memory on a remote system.  Once you have access to the remote memory object is when Memoryze comes in handy. The ability to access this remote memory object with EEE is how the “MemScript” was born.  The MemScript is an EnScript that integrates a couple of programs to automate memory analysis with EnCase.  First, MemScript is integrated with Memoryze.  MemScript accesses the memory entry and uses Memoryze to do the analysis.  Secondly, MemScript then takes the results from Memoryze’s analysis and launches MANDIANT’s Audit Viewer. Using MemScript is easy and even easier to setup.  The first step in using MemScript is having the tools it integrates. You will need the following tools.

  • EnCase
  • Memoryze
  • Audit Viewer

    Note: Please make sure you have updated to Memoryze 1.2.18.0 and Audit Viewer 1.0.0.7 released this week.

Audit Viewer does require Python and a Python GUI library so getting these installed  is also required to use MemScript. These requirements can be found at the following links:

Once all the tools are on the system, you can begin the analysis by adding the memory entry to a case.  To add the memory object to a case go to “Add Device”.  In this window, check the box for Physical Memory.  At this point, you should have a window, which is illustrated in Figure 1.

Figure 1: Enabling the memory object.


If your windows are similar to the ones above, double click on the Local Drives in the right hand table (it would be a remote machine with EEE).  The next window will show whether you have access to the systems memory.  If you do have access, the window in Figure 2 should appear.

Figure 2: Adding the RAM device.


At this window, double click on the RAM. This will give you a new window with just the RAM.  Once here, click the finish button. The memory object is now added to your case and analysis can begin.  Before we start the MemScript, we need to blue check the “PhysicalMemory” entry.  When this is finished, you should have a window that looks similar to the one in Figure 3.

Figure 3: Blue checked PhysicalMemory entry.


With the PhysicalMemory entry blue checked start the MemScript EnScript.  Figure 4 is the window that appears when the MemScript is started.

Figure 4: MemScript start page.


The first tab that appears is the Process Audit Tab.  This tab will run process audits on the memory.  The options available are for the ports, sections, handles and strings. These options are detailed in the Memoryze documentation and a synopses of these are in the help button.  You are also able to specify either a specific process name or a specific PID.  By default, the process audit is always ran when using MemScript.  One tip: while running this audit is  the strings option is very taxing on the size of the results.  To get around this problem, it is easier to look at strings for a specific process name or PID rather than across the whole memory image. The other audits available with MemScript are Driver Audits, Driver Signature Audits, and Rootkit Audits.  All of these audits are detailed in the Memoryze documentation as well.  These audits can be ran along with a process audit and multiple audits can be ran and the same time.  Running these audits is done by checking whether they should be performed or not. An example of selecting the Rootkit Audit to run is shown in Figure 5.

Figure 5: Example of running the Rootkit Audit.


All of the audits are stored in the case’s export folder.  These audits can then be viewed with Internet Explorer or Audit Viewer.  If Audit Viewer is already installed on the machine, you can set up MemScript to automatically launch the Audit Viewer when the analysis is done.  Setting up to launch Audit Viewer automatically is done in the Options tab.  The options tab is shown  in Figure 6 with MemScript configured to launch Audit Viewer when the memory analysis is finished.


Figure 6: Setting the options to launch Audit Viewer.


The other option in MemScript is to change the install directory of Memoryze. By default MemScript looks for Memoryze in “C:\Program Files\Mandiant\Memoryze” but it can be changed by selecting this option. Figure 7 shows the install directory being changed for MemScript.

Figure 7: Changing the install directory for Memoryze.


Now that all of the options and audits have been walked through, you can start the analysis by pressing the OK button.

During the analysis a couple of command line boxes will pop up depending on the options you set.  If you set the option to launch the Audit Viewer, you will have two command boxes pop up, but only one command box pops up if Audit Viewer is not set to launch.  The first command box to pop up is Memoryze running its analysis.  Please leave this command box open, it should close when Memoryze’s analysis is done.  Since the Audit Viewer is also launched from a command shell, the next box to open will also need to be kept open until you are done looking at the results with Audit Viewer.

When the analysis is done the results will be populated in the Audit Viewer.  Figure 8 below shows the result of running a Process Audit and Driver Signature Audit.

Figure 8: Results of MemScript in Audit Viewer.


The results of the Process Audit are shown in the ProcessAuditMemory tab.  The Driver Signature Audit results will be displayed in the DriverAuditSignature tab.  Another nice feature of using MemScript is that when the Audit Viewer is launched you can acquire processes from the memory image you are analyzing.  The memory image file is exported to your case’s export folder and populated in the Audit Viewer.  To get started using MemScript get all the required tools plus the EnScript below:

MemScript

Tags: , , , , ,

. 18 Dec 08 | General | Comments (0)
« Previous Posts
Next Posts »