Memory Collection and Analysis

As a follow-on to my previous post regarding OMFW, there have been some developments in the area of memory dumping and parsing (ie, collection and analysis) that have occurred over the past couple of months.

Lance Mueller posted on the new standalone memory dumping tool that is part of EnCase 6.11. Interesting tool as it apparently dumps the contents of physical memory from Windows (Windows 2000 through Vista) to an EnCase .E0x file format, for inclusion in a case. According to the documentation, there's functionality to extract that memory dump from the .E0x file format to something usable by HBGary's Responder product. Note: Initial testing indicates that FTK Imager will successfully convert the resulting .E0x files to a dd-style format for use with other tools.

Jesse Kornblum referred mdd to me. This one looks promising...captures memory from Windows versions through Vista and 2008. Jesse posted some clarifications about this tool on his blog. As it stands, this appears to be the first free tool to dump RAM from Windows 2000 through 2008, inclusive, in a dd-style format. Note: Updated version 1.1 was released on 17 June.

So available tools for collecting the contents of physical memory are becoming more available. From an analysis standpoint, I really think that you want to keep your eyes on the guys over at Volatility Systems, though.

Addendum: win32dd is available from Matthieu Suiche. I just found out about this so I haven't had an opportunity to try it...but I am looking forward to adding it to the list of tools to test!

Andreas blogs on the new tools...great stuff, very comprehensive view of where this all stands at the moment.

More Free Tools

To continue adding to the list of free tools (earlier posts here and here), here are a couple of gems I found recently...

NetworkMiner - a free network forensic analysis tool that takes analysis of network traffic captures to another level. Very cool tool...I love how WireShark lets you reassemble streams, but NetworkMiner lets you do a bit more, and it's Windows-based. Don't have any packet captures available to try it with? Check out the HoneyNet Project's SotM #27.

Thanks goes to Claus for pointing these out...

Stinger and MVC...these are NOT full-bore AV applications, but rather free tools meant to target specific malware. Use these on a live system, or mount the acquired image as a live file system (as opposed to booting the image...) and scan the files.

OpenFilesView - Neat little tool to see which files are open on a system; GUI based but comes with command line options, making it a great tool for use in IR batch files. Say you've got a suspected intrusion and you need to know if sensitive data (pursuant to PCI, HIPAA, etc.) is being siphoned off of the system...well, grab process information w/ tools like tlist.exe and correlate that information to files opened on the system by process...

MUICacheView - The NirSoft site says, "Each time that you start using a new application, Windows operating system automatically extract the application name from the version resource of the exe file, and stores it for using it later, in Registry key known as the 'MuiCache'." This is one of those things I've looked into, and I'm not able to find what the OS would use this for...but hey, who am I to complain about it, right?

By the way, RegRipper has a plugin for this key, which means that you can parse the contents of this key by either extracting the hive from an image, or by firing up F-Response. ;-)

Addendum: Claus posted some of his own bloggy goodness about Evidence Collector, and from that post I learned about USBHistory, a nice little tool that extracts historical information about USB devices connected to a live system. The author even gives a shout out to ol' watashe-wa and his book! Very cool!

Free Analysis

What??!? "Free" (as in 'beer') analysis? A bit ago, I blogged about Forensic Analysis on the Cheap, and I wanted to revisit that topic, particularly to mention a couple of tools I've run across since then...

Event Logs
In an earlier post, I mentioned some tools you could use to perform Event Log analysis. I still like the functionality in EvtUI (although I may be seen as biased because I wrote it), but if tools like this scare you, there are other options available. For example, Event Log Explorer is a nice little little app, and you can obtain a free license for its use. In direct mode, it works just like EvtUI, accessing the event records directly within a .evt file extracted from an acquired image.

Registry Analysis
I have to say that I'm really partial to RegRipper and its associated CLI utility, rip.exe. A couple of minor tweaks, as well as some new plugins, both of which were recently added, make this an immensely useful (not to mention unique) tool.

When looking for things I may want/need to add as plugins to RegRipper, my favorite Registry Viewer to use is MiTeC's RFV. I can go through the hive file and look at things, and fire rip.exe off against it without having to unload the hive or anything like that. RFV is a great Registry Viewer that facilitates the development of plugins.

File Carving
I've mentioned scalpel before as a tool for file carving...XaberSoft provides a GUI interface for setting up the scalpel config file

Another useful tool for file carving is PhotoRec. Even though its intended for extracting image files, I'm sure that there are a number of folks out there interested in doing just that...

Other Tools
Shadow Explorer - I haven't had an opportunity to try this tool yet, but I'm told that it's great for recovering files using Vista's Volume Shadow Copy Service. If you can boot an acquired image using LiveView, and log into the running image, you may be able to get some useful information or recover some files using this tool.

Alternative Methods of Analysis

Do I need to say it again? The age of Nintendo Forensics is gone, long past.

Acquiring a system is no longer as simple as removing the hard drive, hooking it up to a write blocker, and imaging it. Storage capacity is increasing, devices capable of storing data are diversifying and becoming more numerous (along with the data formats)...all of which are becoming more ubiquitous and common-place. As the sophistication and complexity of devices and operating systems increases, the solution to the issue of backlogs due to examinations requiring additional resources is training and education.

Training and education lead to greater subject-matter knowledge, allowing the investigator to ask better questions, and perhaps even make better requests for assistance. Having a better understanding of what is available to you and where to go to look leads to better data collection, and more thorough and efficient examinations. It also leads to solutions that might not be readily apparent to those that follow the "point and click execution" methodology.

Take this article from Police Chief Magazine, for example. 1stSgt Cohen goes so far as to specifically mention the collection of volatile data and the contents of RAM. IMHO, this is a HUGE step in the right direction. In this instance, a law enforcement officer is publicly recognizing the importance of volatile data in an investigation.

It's also clear from the article that training and education has led to the use of a "computer forensics field triage", which simply exemplifies the need for growth in this area. It's also clear from the article that a partnership between law enforcement, the NW3C and Purdue University has benefited all parties. It would appear that at some point in the game, the LEs were able to identify what they needed, and were able to request the necessary assistance from Purdue and NW3C...something known in consulting circles as "requirements analysis". At some point, the cops understood the importance of volatile memory, and thought, "we need this...now, how do we collect it in the proper manner?"

So what does this have to do with alternative methods of analysis? An increase in knowledge allows you to seek out alternative methods for your investigation.

For example, take the Trojan Defense. The "purist" approach to computer forensics...remove the hard drive from the system, acquire an image, and look for files...appears to have been less than successful, in at least one case in 2003. The effect of this decision may have set the stage for other similar decisions. So, let's say you've examined the image, searched for files, even mounted the image as a file system and hit it with multiple AV, anti-spyware, and hash-comparison, and still haven't found anything. Then lets assume you had collected volatile data...active process list, network connections, port-to-process mapping, etc. Parsing that data, wouldn't the case have been a bit more iron-clad? You'd be able to show that at the time the system was acquired, here are the processes that were running (along with their command line options, etc.), installed modules, network connections, etc.

At that point, the argument may have been that the Trojan included a rootkit component that was memory-resident and never wrote to the disk. Okay, so let's say that instead of running individual comments to collect specific elements of memory (or, better yet, before doing that...), you'd grabbed the contents of RAM? Tools for parsing the contents of RAM do not need to employ the MS API to do so, and can even locate an exited or unlinked process, and then extract the executable image file for that process from the RAM dump.

What if the issue had occurred in an environment with traffic monitoring...firewall, IDS and IPS logs may have come into play, not to mention traffic captures gathered by an alert admin or a highly-trained IR team? Then you'd have even more data to correlate...filter the network traffic based on the IP address of the system, isolate that traffic, etc.

The more you know about something, the better. The more you know about your car, for example, the better you are able to describe the issue to a mechanic. With even more knowledge, you may even be able to diagnose the issue and be able to provide something more descriptive than "it doesn't work". The same thing applies to IR, as well as to forensic analysis...greater knowledge leads to better response and collection, which leads to more thorough and efficient analysis.

So how do we get there? Well, someone figured it out, and joined forces with Purdue and NW3C. Another way to do this is through online collaboration, forums, etc.

Windows Memory Analysis

It's been a while since I've blogged on memory analysis, I know. This is in part due to my work schedule, but it also has a bit to do with how things have apparently cooled off in this area...there just doesn't seem to be the flurry of activity that there was in the past...

However, I could be wrong on that. I had received an email from someone telling me that certain tools mentioned in my book were not available (of those mentioned...nc.exe, BinText, and pmdump.exe, only BinText seems to be no longer available via the FoundStone site), so I began looking around to see if this was, in fact, the case. While looking for pmdump.exe, I noticed that Arne had released a tool called memimager.exe recently, which allows you to dump the contents of RAM using the NtSystemDebugControl API. I downloaded memimager.exe and ran it on my XP SP2 system, and then ran lsproc.pl (a modified version of my lsproc.pl for Windows 2000 systems) against it and found:

0 0 Idle
408 2860 cmd.exe
2860 3052 memimager.exe
408 3608 firefox.exe
408 120 aim6.exe
408 3576 realsched.exe
120 192 aolsoftware.exe(x)
1144 3904 svchost.exe
408 2768 hqtray.exe
408 1744 WLTRAY.EXE
408 2696 stsystra.exe
244 408 explorer.exe

Look familiar? Sure it does, albeit the above is only an extract of the output. Memimager.exe appears to work very similar to the older version of George M. Garner, Jr's dd.exe (the one that accessed the PhysicalMemory object), particularly where areas of memory that could not be read were filled with 0's. I haven't tried memimager on a Windows 2003 (no SPs) system yet. However, it is important to note that Nigilant32 from Agile Risk Management is the only other freely available tool that I'm aware of that will allow you to dump the contents of PhysicalMemory from pre-Win2K3SP1 systems...it's included with Helix, but if you're a consultant thinking about using it, be sure to read the license agreement. If you're running Nigilant32 from the Helix CD, the AgileRM license agreement applies.

I also wanted to followup and see what AAron's been up to over at Volatile Systems...his Volatility Framework is extremely promising! From there, I went to check out his blog, and saw a couple of interesting posts and links. AAron is definitely one to watch in this area of study, and he's coming out with some really innovative tools.

One of the links on AAron's blog went to something called "Push the Red Button"...this apparently isn't the same RedButton from MWC, Inc. (the RedButton GUI is visible in fig 2-5 on page 50 of my first book...you can download your own copy of the "old skool" RedButton to play with), but is very interesting. One blogpost that caught my eye had to do with carving Registry hive files from memory dumps. I've looked at this recently, albeit from a different perspective...I've written code to locate Registry keys, values, and Event Log records in memory dumps. The code is very alpha at this point, but what I've found appears fairly promising. Running such code across an entire memory dump doesn't provide a great deal of context for your data, so I would strongly suggest first extracting the contents of process memory (perhaps using lspm.pl, found on the DVD with my book), or using a tool such as pmdump.exe to extract the process memory itself during incident response activities. Other tools of note for more general file carving include Scalpel and Foremost.

So...more than anything else, it looks like it's getting to be a good time to update processes and tools. I mentioned an upcoming speaking engagement earlier, and I'm sure that there will be other opportunities to speak on Windows memory analysis in the future.

Mounting a DD image

One of the things I mentioned in my new book was an alternative analysis method for performing computer forensic analysis. I specifically mentioned the use of Mount Image Pro for mounting a dd image as a read-only file structure, which opens up some areas of analysis that many may benefit from using. For example, during an intrusion case, one thing you may want to do is scan the image with AV software. This may save you a great deal of time trying to locate hacker tools by hand. Also, this is something you may want to do when you may be faced with the "Trojan Defense".

Another thought/useful option is this - we all have things that we look for everytime we open an acquired image of a Windows system, and there are other things that we look for on a case-by-case basis. Most often we do this through our forensic analysis software package, such as ProDiscover or EnCase. However, even though these packages ship with scripts to do some initial data collection and parsing for us, sometimes, they aren't as complete as they could be, or we'd like them to be, and it takes forever to get scripts updated because the few folks that actually write their own scripts are busy with other things. Sometimes you may be in a rush or under pressure, and may forget something that you would normally look for. So what if we had a script or a tool that would run through an image, pulling things out for us each time...all automated so that we wouldn't have to remember all of the different places could look, but at the same time, its all documented? Say, the tool would check to see if the Recycle Bin had been disabled, and then move on to parsing the INFO2 file for one user, or all users. Or, the tool would collect the audit policy from the system, check the Registry entries for the Event Logs, and then collect statistics from the Event Log files themselves, or automatically parse the Event Log files to .csv format (or both). Would that be useful?

Another use of something like this is for forensic analysis training. Mounting the image as a drive letter lets you dig into aspects of forensic analysis that while accessible via commercial forensic analysis applications, may be somewhat easier to grasp and work with, particularly for new students, or junior members of an IR/CF team or CSIRT.

Okay, so now, how do we do this? How do we start with just a dd image, and get to a read-only drive letter (ie., F:\, G:\) so that we can point an AV scanner or some other tool at it?

To get the dd image to begin with, you can use ProDiscover, Helix, straight dd, or even FTK Imager Lite. If you're using ProDiscover, you can use the Tools -> Image Conversion Tools -> VMWare Support for DD Images... option to create the necessary .vmdk file.

Another option for creating the .vmdk file is to use LiveView. Point LiveView at the dd image, choose "Generate Config Only" in the GUI (maybe even designate the OS rather than having LiveView guess it) and you'll end up with several files, to include two .vmdk files and a snapshot. LiveView makes use of the VMWare DiskMount utility (don't forget the free VMPlayer), and even though this does not mount the image as a read-only file structure, you can set the read attribute on the image file itself (attrib +r imagefile) as a precaution. Use the vmware-mount.exe to mount the snapshot (imagefile-000001.vmdk)and all of the writes will end up in the snapshot.

Another option is to look at FileDisk. From the screenshot, FileDisk appears to have a read-only (/ro) option. I haven't tried this one yet...installation requires a reboot for the driver to be installed. However, FileDisk will also let you mount ISOs as CDs using the "/cd" switch.

Once you have your .vmdk file, take a look at VDK and VDKWin (scroll down to VDKWin). VDK gives you the .exe and .sys file for mounting image files as read-only file structures (according to the credits, VDK owes a great deal to FileDisk), and VDKWin gives you a GUI for managing it all. A nice thing I noticed about VDKWin is that it's simply a GUI for managing all of the command line switches in VDK. For example, let's say you image a Dell system that wasn't reformatted before being installed, and it has one of those Dell maintenance partitions at the beginning of the physical drive. VDK lets you list available partitions, and then select the one you want to mount. Rememer, when you grab VDKWin, don't forget to also get the core files from the top of the page.

I did test this out using a sample image. I started with the ProDiscover solution, and launched the .vmdk file via VDKWin with no problems. I tried LiveView, and though the DiskMount (vmware-mount.exe) approach worked fine, VDKWin balked at an "unknown extent type". The extent description section of the LiveView .vmdk file had two lines...simply deleting the second one caused VDKWin to hang. So, I removed the second line, and added the size entry to the first line, in essence replicating what I found in the .vmdk file produced by ProDiscover, and then everything worked just fine.

One caveat: I already have VMWare installed on my system...I read in a Google News post somewhere that in order to use some of these tools, you may need to have VMPlayer or one of the VMWare products installed, as the tools may use some of the DLLs. Just be aware of this if this is an avenue you're going to take.

So, what we're left with is a Windows-based solution, using freeware tools, to obtain an image, and then mount that image as a read-only file structure, for analysis. Many of the tools on the DVD that comes with my book, such as SAMParse, are designed to be run against raw Registry files and are perfect for use with this methodology. Sweet!

Addendum: I have an image that was created using FTK Imager Lite, broken into 2GB chunks. I opened the image in ProDiscover using the PDS file format, and started my analysis. Last night, I used the ProDiscover capability for creating .vmdk files ("VMWare support for DD images...") to create the .vmdk file by pointing the tool at the .pds file. Then, I installed VDK and VDKWin, but not any of the other VMWare tools. After setting the read-only bit on all of the image files (attrib +h), I ran VDKWin and successfully mounted the image as the K:\ drive, in read-only mode.

Even though I use a fully licensed version of ProDiscover IR, ProDiscover Basic is free (as in beer) and includes the ability to create the .vmdk files.