So what is included in Memoryze and Audit Viewer 1.4? Well, here is the short of it.
 

Memoryze:

• Support for Windows 2003 x64 SP2
• Improved support of Vista SP1 and SP2 including port enumeration and a better installer
• Enumeration of digital signatures for all loaded modules in a processes’ address space, hooked and hooking drivers, and all drivers found by driver signature scans
• Enumeration of MD5/SHA1/SHA256 hash on disk for all loaded modules in a process’ address space and all drivers found by driver signature scans
• Updated documentation
• Single installer for 64-bit and 32-bit versions

 
Audit Viewer:

• Improvements to the Malware Rating Index (MRI)
•      Report visualization of MRI results
•      MRI rule editors that will allow users to graphically edit the MRI rule file
•      Handle Trust view to help identify suspicious handles
• Ability to search results within a specific process
• Multi-select with copy
• Multi-select and export to a CSV file

 
Those who attended the CanSecWest Training in March have already been enjoying many of these features in beta form for months, and we are committed to ensuring that those who attend the Advanced Memory Forensics in Incident Response class at Black Hat will get early access to the next version of Memorzye, which will support Windows 7 64-bit.
 
As for the Black Hat training, there is a lot of new and updated content for 2010.

• Coverage of 64-bit operating systems
• New section on malware covering different malware techniques and how they stand out in memory
• Four new case studies ranging from real Advanced Persistent Threat (APT) incidents, to spear phishing attacks, and everything in between
• Student receive early access Memoryze and Audit Viewer for Windows 7 64-bit
• Students receive the only free tool to analyze Windows Vista
• Students receive the only free tool to analyze Windows 2003 64-bit
• Better data collection to help identify processes and drivers as malicious or not
• Added the Malware Rating Index (MRI), which helps automatically identify many malware behaviors discussed in the class. Through a simple user interface, students learn how to write rules to identify malware in their own work environments. MRI then uses those rules to score processes as suspicious or not.

 
I would like to thank James Long who pointed out an issue with the batch scripts* and Peter Villadsen who worked so hard to improve the build process and installation for Memoryze. Peter and I would also like to thank all our loyal users. We appreciate all your feedback, and we hope to see you in Las Vegas.

 
* When specifying an output directory from the command line with the batch scripts in Memoryze, the directory must already exist.

The prizes MANDIANT will be offering to those that place in the top three are:

First Place: $100 gift card to Best Buy
Second Place: Backpack
Third Place: MANDIANT swag

In the event of a tie, we will divide the prize(s) equally.

The submission deadline is April 18th so act fast.
Banking Troubles

Please do not send your submissions to MANDIANT. If you are a winner of the challenge, contact info at MANDIANT after the winners are announced. Peter Silberman and other MANDIANT employees may submit a solution; however, employees are not eligible for prizes. If a MANDIANT employee places in the top three of submissions, all prizes will be allocated to the remaining, non-employees to place in the top three.

Peter and I have been busy planning for CanSecWest in a week. The course, Advanced Memory Forensics in Incident Response, is constantly evolving. It has been about a year and a half since Memoryze was released, and just over a year for Audit Viewer. Honestly, it seems a lot longer, but that is not a bad thing. This week my team will be handing over to QA Windows 2003 64-bit support. While that is in testing, Peter will be making improvements to Audit Viewer that you the user have recommended, and he will be verifying everything works correctly with the 64-bit output. The Malware Rating Index (MRI), which is in Audit Viewer, really changes the case studies in the training. For some exercises, we have to turn MRI off because the malware becomes obvious if you know how to use the tool. I expect MRI will evolve a lot over the next six months as we think of news ways to visualize, sort, and search the data as well as identify new pieces of data to collect. If you are curious how visualization and sorting can help, check out how Harlan Carvey and Chris Pogue use it.

We have gotten a lot of great feedback from the user community, but what Windows operating system support or feature would you like see next? Yes, MANDIANT Intelligent Response has a roadmap, but Memoryze allows us to play a little bit. It is really a labor of love. So let us know what you think. You can reach us at peter.silberman or james.butler plus company name.com. We currently support:

- Windows 2000 SP4
- Windows XP SP2 and SP3
- Windows Vista SP1 and SP2 (better installer coming in next release)
- Windows 2003 SP1 and SP2
- Windows 2003 SP2 64-bit (** next release **)

So if you cannot make the training at CanSecWest in a week, Black Hat USA has just opened their training schedule, and we will be there for the weekend and weekday offerings of Advanced Memory Forensics in Incident Response. I hope to see you soon. Keep your eyes open for official update releases of Memoryze/Audit Viewer and Webinars/presentations.

The webinar entitled Malware Behaving Badly is on Thursday, February 18, at 2:00 p.m. EST. The webinar title is a cute play on my DOD Cyber Crime (DC3) talk where I first introduced Malware Rating Index (MRI) into Audit Viewer (which is available for download).

If you saw my DC3 talk or viewed the slides and are wondering, “hey is this the same talk?” the answer is…well a little bit. The webinar will build off of a lot of the behaviors and theories I discussed at DC3. We will be addressing new behaviors as well as looking at APT vs Mass Malware behaviors.  I’ve added two new configurable behaviors to MRI and did enough research to scrap a third. I’ll share those as well as give more real world examples of how malware exposes itself in memory.

For example the below listing shows the keylogger, the process and the file handle that process has. The file handle is actual the log file the key logger is writing too.

If you didn’t catch my DC3 talk and didn’t understand the slides this is a good time to get an updated version of the talk. I’m going to focus on malware behavior, what it does when it’s installed that makes it stand out in memory. We will cover APT and Mass Malware, and specifically where we see their behaviors intersect. Some of these behaviors are horribly simple, i.e. flag svchost launched from directories other than \windows\system32. Some are as simple but may not be as obvious, for example flag svchost, or iexplore if they have a process handle to cmd.exe. These are rules that should never be true.

When discussing rules, I use that term loosely. Basically in Audit Viewer you now have the option to configure all this information. If you go to Operations -> Configure Malware Rating Index you can configure all these things and a few more not mentioned in this post but mentioned in the webinar. We will wrap up the webinar like always with a live demo. Live demos are the most fun really, it’s like NASCAR except it’s just reputation not lives on the line.

I hope you can join us, it should be fun.

If you would like to learn more in-depth about how physical memory analysis works, use Memoryze and Audit Viewer, understand MRI, or write your own malware rules, join Jamie and I at the CanSecWest training. CanSecWest specializes in technical, hands-on classes with an extremely low student-teacher ratio.

A caveat within MRI I that I want to talk about is Process Path Verification. This rule set is very powerful but there are two ways to define to paths. Neither is documented because currently there is no documentation on MRI.. The first method of specifying a process path is to specify an absolute path such as this:
calc.exe:\windows\system32

MRI interprets this as the only valid path for calc.exe is \windows\system32\calc.exe. However, if I wrote the rule like:
calc.exe:\windows\system32\

MRI would interpret this as calc.exe can be run from any sub directory as long it’s a sub directory within \windows\system32\*

The reason this is important is it gives you flexibility in writing definitions. If I don’t want to specify the exact location of iexplore.exe I can say it needs to be launched from \program files\. This may prove to be too loose, and I may change this behavior going forward. For now you have the flexibility to specify absolute paths or sub paths.

The next “undocumented” tidbit that I want to discuss is within two behaviors. These behaviors actually have the ability to use regex when trying to match up their values. I did not build the regex option into the UI so it has to be manually added to the AuditViewerConfig.xml. The two XML lists that can take regex expressions are IgnoreFilesList, and ProcessSuspiciousHandleList. The regex elements are, IgnoreFileRegex, and HandleRegex. An example IgnoreFileRegex looks like:
<IgnoreFileRegex>mshist.*\\index.dat</IgnoreFileRegex>

This rule specifies that any file matching this regular expression should be ignored when doing process scoring. You can get creative just be careful.

An example HandleRegex looks like:
<HandleRegex>*:.*-7$:mutant:known conficker mutant</HandleRegex>

It breaks down like this:
Process: Regular Expressions : handle type: description

It breaks down like this:
Process: Regular Expressions : handle type: description

This allows you to get more out of your suspicious handles definitions.

Finally, I’d like to take a second to reiterate something I stated at DC3. The “Verify Digital Signatures” option in Memoryze and Audit Viewer wizard can ONLY be run when doing live memory. It is not possible to enable it when doing dead memory analysis. Which means the address scoring is not possible on dead memory, behavioral analysis still works on dead memory. If you are going to acquire memory, please run live analysis jobs as well as acquisition. This way you get the most information possible off the machine. The second thing I wanted to reiterate is that verify digital signatures is great, it really helps potentially speed up an analyst’s job. However, we are only verifying the digital signatures exist and are valid on disk. We are not verifying the module in memory hasn’t been modified. If a userland rootkit exists (again shame on the authors) then we won’t report that. It’s important to remember this. Verifying modules in memory short of doing rootkit detection is not a trivial task. The windows loader is a beast, a behemoth it does a lot to make verification in memory to disk is very hard (not impossible). Thanks again for all the interest in M-Trends, Audit Viewer and Memoryze. As always feedback is always appreciated.

The talk is going to be interactive. And dammit I don’t care if you don’t want to interact with me. I’m both very convincing, persistent and well…charming! You will feel compelled to join in on this talk. I promise. I know this because I’m bringing bribes… And yes, I’m bringing what you are thinking.

This talk will contain a brief intro to memory analysis, a FAQ etc. We are not going to waste much time on the nitty gritty since most people are not interested in how we chop off the last 12 bits to get a physical offset from a virtual address. I know, you just fell asleep a little.  During this talk I will make a case for why memory analysis is important. I will pull from pervious APT investigations where disk analysis failed and had to be used in conjunction with memory analysis. Finally, we will discuss MANDIANT’s Malware Rating Index (MRI). We will finish with real APT incident demos where I’ll walk through the investigation of an infected system with APT.

Now, a little more about MRI. MRI is a huge update to Audit Viewer.  Instead of going after a fish (malware) with a hook (signatures), I’m going after fish (malware) with a drag net (MRI). The goal of this feature is twofold. First it is going to  help pinpoint specific processes that should be investigated further while attempting to eliminate some of the non-suspicious processes and get them out of the analyst’s way. It’s also designed to try and make APT detection easier. A lot of work went into looking at our samples and how they behave etc, and coming up with definable behaviors that trap those little creatures. MRI is made up of two components. The first component is a definable behavior rule set that is completely customizable. It is made up of three different types of rules:

• Process Path Verification – allows users to define what processes should be launched from what directories. This triggers on malware that copies and names itself after svchost or other system processes to subdirectories within system folders. For example a default rule is that svchost can only be executed from \windows\system32. Any time we see it running from somewhere else we flag the process.
• Process User Verification – allows users to define what processes should be running under what users.  This triggers on malware spawning svchost for purposes of unmapping image bases or hiding dlls within spawned svchost. So, for example, if malware copies itself to system32\dllcache and then names itself svchost.exe, you can define a rule saying svchost.exe should be running as local service, network service, or system. When Audit Viewer see svchost running as administrator it gets flagged.
• Process Handle Inspection – this allows you to define specific rules pertaining to malware or generic behavior. For example a default rule is to flag svchost or iexplore anytime it has a process handle to cmd.exe. There is just no good reason for this to _EVER_ happen. You can also define rules based on specific malware, for example if a3c mutant is present then flag the process as being infected with sality.

All of these features are configurable from the UI by going to operations -> Configure MANDIANT MRI.

The second component of MRI is a process address space scoring mechanism. We will be releasing an update to Memoryze at DC3. The new release will contain bug fixes as well as a new feature called “Verify Digital Signatures.” When this parameter is turned on memoryze will perform a “digital signature check” on all loaded modules. This can only be enabled on live memory analysis. The digital signature check verifies the module on disk is digitally signed. We do a bunch of math and use our Least Frequency of Occurrence to trust modules that aren’t signed but occur in more than X% of processes. Where X is defined by the user. We won’t flag or catch modified binaries in memory. So if a rootkit is doing userland hooking (it should be ashamed) we won’t know about it because we are checking disk to determine if it is digitally signed. There are a lot of reasons why we can’t verify in memory digital signatures.  It might make an interesting blog to detail all the reasons. With that said, this new feature gives us a good working idea of how much of the loaded modules in the process address space are signed and therefore trusted. It’s had fantastic results thus far. I’ve been using it on old incidents to see if we could have sped up results using these new methods. The answer seems to be yes in a lot of cases.

After DC3 I’ll have more blogs detailing how you can use and write better rules for MRI. But for now there will be a default distribution that you can use and modify. Again, like always, Audit Viewer is open source and free. Which means you can see the logic and rules behind MRI. Memoryze is and will stay free.

If you are going to be at DC3 and want to grab a beer I will be there from Sun (night)-Weds. Unfortunately I’m going to be missing all the great talks on Thurs so I can leave to compete in the Tough Guy Challenge. You are more than welcome to join at this race in Northern England. As I understand it there are still some open slots! See everyone at DC3!

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.

• 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

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

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.

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.

• 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:

• Python 2.6.1
• Python wx

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

Audit Viewer allows the incident responder or forensic analyst to quickly view complex XML output in an easily readable format. Using familiar grouping of data and search capabilities, Audit Viewer makes memory analysis quicker and more intuitive.

Check out these features:

• Process data can be viewed on a per process basis or in its entirety by double clicking the root node, “Processes”. For example, when you double click on “Processes” and then click on the Files tab, all the file handles open on the host are displayed from least frequently to most frequently occurring.
  
• Ability to search Files, Processes, Mutants, Events, Registry Keys, and Strings using plain text or regex.
  
• Ability to load multiple Memoryze result sets contained in the same directory.
  
• Handle types are separated out into more abstract types representing the logical type of the handle such as Files, Directories (part of the Object Manager’s namespace), Processes, Keys, Mutants, and Events.
  
• Memory sections with names are displayed under the DLLs tab.
  
• Layered drivers are displayed in a tree view. This is useful for finding certain types of keyboard sniffers, network sniffers, and file filtering drivers.
  
• Integrated with Memoryze to seamlessly acquire drivers and processes from live memory and images.
  
• Ability to scan all processes for “questionable” executable sections. These sections have the EXECUTE_READWRITE flag but no name.

Get the goods, Audit Viewer 1.0.0.7!  Want to learn how to harness this power? Check out Audit Viewer PDF.

Special thanks to Peter for spending his nights and weekends to make this available.