I conducted some analysis recently where I used timeline analysis, Volatility, and the Sniper Forensics concepts shared by Chris Pogue to develop a thorough set of findings in relatively short order.

I was analyzing an image acquired from a system thought to have been infected with Poison Ivy.  All I had to go on were IPS alerts of network traffic originating from this system on certain dates...but I had no way to determine how "close" the clocks were for the system and the monitoring device.

I started by creating a timeline, and looking for the use of publicly documented persistence mechanisms employed by the malware in question (Windows service, StubPath values within "Installed Components" Registry keys, etc.), as well as looking for the use of NTFS alternate data streams.  All of these turned up...nothing.  A quick review of the timeline showed me that McAfee AV was installed on the system, so I mounted the image via FTK Imager and scanned it with ClamWin 0.98 and MS Security Essentials (both of which were updated immediately prior to the scan).  MSSE got a hit on a file in the system32 folder, which later turned out to be the initial installer.  I searched the timeline, as well as the Software and System Registry hives for the file name, and got no hits beyond just the existence of that file within the file system.

The system was a laptop system and had a hibernation file, which was last modified the day that the system itself had been shut down.  I exported the hibernation file for analysis, and then downloaded the Win32 standalone version of Volatility version 2.3.1, and used that to convert the hibernation file to raw format, then identify the profile (via the imageinfo plugin) and get a process list (via the pstree plugin).

I got in touch with Jamie Levy (@gleeda), who pointed me to this post, which was extremely helpful.  Based on the output of the malfind plugin, I was able to identify a possible process of interest, and I searched the timeline for the executable file name, only to find nothing.  However, I did have a process ID to correlate to the output of the pstree plugin, and I could see that the process in question was a child of services.exe, which told me not only where to look, but also that the installation process required at least Administrator-level privileges.  Correlating information between the RegRipper samparse.pl and profilelist.pl plugins, I was able to see which user profiles (both local and domain) on the system were members of the appropriate group.  This also provided me with the start time for both processes, which correlated to the system being started.

A fellow team member had suggested running strings across the memory dump, and then searching the output for specific items; doing so, I found what appeared to be the configuration information used by Poison Ivy (which was later confirmed via malware RE performed by another team member).  As a refinement to that approach, I ran the Volatility vaddump plugin, targeting the specific process, and dumped all of the output files to a folder.  I then ran strings across all of the output folders, and found a similar list of items as when I'd run strings across the entire memory dump.

I validated the configuration item findings via the Volatility handles plugin, looking for mutants within the specific process.  I also dumped the process executable from the memory dump via the procmemdump plugin; the first time I did it, MSSE lit up and quarantined the file, so I disabled MSSE and re-ran the plugin (I set my command prompts with QuickEdit and Insert modes, so re-running the command line as as simple as hitting the up-arrow once, and then hitting Enter...).  I was able to ship the dumped PE file and the initial wrapper I found to a specialist for analysis while I continued my analysis.

I then ran the svcscan plugin and searched the output for the executable file name, and found the Windows service settings, to include the service name.  I also ran the dlllist plugin to see if there were any DLLs that I might be interested in extracting from the image.

I also ran the netscan plugin, and reviewing the output gave no indication of network connections associated with the process in question.  Had there been a connection established associated with the process of interest, I would've run Jamaal's ethscan module, which he talked about (however briefly) at the recent OMFW.

I had downloaded the Poison Ivy plugin, which according to the headers, is specific to one version of the PIvy server.   The plugin ran for quite a while, and because I had what I needed, I simply halted it before it completed.


In short, the process (with Volatility plugins) looks like this:
- convert, imageinfo, pstree
- malfind - get PID
- run vaddump against the PID, then run strings against the output
- run handles against the PID
- run procmemdump against the PID (after disabling AV)
- run dlllist against the PID
- run netscan; if connections are found associated with the PID, run ethscan

At this point, I had a good deal of information that I could add to my timeline in order to provide additional context, granularity, and relative confidence in the data I was viewing.  File system metadata can be easily modified, but Windows Event Log records indicating service installation and service start can be correlated with process start times, assisting you in overcoming challenges imposed by the use of anti-forensics techniques.

It's also important to point out that Registry, timeline, and memory analysis are all tools, and while they're all useful, each of them in isolation is nowhere near as powerful as using them all together.  Each technique can provide insight that can either augment or be used as pivot points for another.

Resources
A couple of interesting items have popped up recently regarding memory acquisition and analysis, and I thought it would be a good idea to provide them here:

• Jamie also pointed me to this post, which, while it wasn't directly helpful (the image I was working with was from a Win7SP1 system), it does show the thought process and work flow in solving the challenge
• From MoonSols, some new features in DumpIt
• Mark Baggett's ISC Diary posts on winpmem and its uses: here, and here
• Page_brute - check out how you can incorporate the pagefile into your analysis, until Volatility v3 hits the streets

I ran across a tweet recently from Andrew Case (@attrc on Twitter) regarding a Registry key with some interesting entries; specifically, the key HKLM\Software\Microsoft\RADAR\HeapLeakDetection.

Andrew also recently released his Registry Decoder, "an open source tool that automates the acquisition, analysis, and reporting of Microsoft Windows registry contents. The tool was initially funded by the National Institute of Justice (NIJ) and is now ready for public release." I had an opportunity to take a look at a beta version of this tool, and I can definitely see the value of having all of the listed functionality available in one application.

To get an idea of what this key might be all about, I did some research and found this page at the Microsoft site, with an embedded video.  From watching the video, I learned that RADAR is a technology embedded in Windows 7 that monitors memory leaks so that data can be collected and used to correct issues with memory leaks in applications.  The developer being interviewed in the video give four primary goals for RADAR:

- To perform as near real-time as possible memory leak detection

- To perform high granularity detection, down to the function

- To perform root cause analysis; data must be sufficient enough to diagnose the issue

- To respect user privacy (do not collect user data)

So, what does this mean to the analyst?  Well, looking around online, I see hits for gaming pages, but not much else, with respect to the Registry keys.  Looking at one of my own systems, I see that beneath the above key that there is a subkey named "DiagnosedApplications", and beneath that several subkeys with the names of applications, one of which is "Attack Surface Analyzer.exe".  Beneath each of these keys is a value called "LastDetectionTime", and the QWORD data appears to be a FILETIME object.

At first glance, this would likely be a good location to look for indications of applications being run; while I agree, I also think that we (analysts) need to have a better understanding of what applications would appear in these keys; under what conditions are artifacts beneath these keys created or modified.  There definitely needs to be more research into this particular key.  Perhaps one way of determining this is to create a timeline of system activity, and add the LastDetectionTime information for these keys to the timeline.

Tools
Claus (no, I'm not saying that Claus is a tool...) has posted a nice summary of some of the free tools posts from WindowsIR and added some really nice grep tools for the Windows platform. Using tools like this would greatly increase an analyst's capabilities with respect to some of the Analysis stuff I've mentioned recently. For instance, if you're interested in doing searches for PANs/CCNs, you can use BareGrep and consult the Regex reference for syntax in writing your regex; of course, additional checks will be necessary (in particular, the Luhn formula) to reduce false positives, but it's a start.

Memory
JL's got a new Misc Stuff post goin' on over on her blog. I'd picked up on the demise of support for mdd.exe from her blog post, as well as from Volatility (note the recommendation to use Matthieu Suiche's windd for your memory dumping needs). She also points out that MHL has some new and updated Volatility plugins, even one that incorporates YARA for scanning of malware!

Analysis
Speaking of malware analysis, Kristinn posted on PDF Malware Analysis over on the SANS Forensic Blog, as well. Add this information to Lenny's cheat sheet, and you can develop a pretty decent approach for determining the method by which a system was compromised or infected. This is often one of the most difficult aspects of analysis, and very often left to speculation in a report. Many times, the assumption is made that the initial infection/compromise vector was via web browser "drive-by" ("browse-by"??)...I say "assumption" because there is no specific data or analysis within the report which supports the statement. In most cases, the assumption is based on malware write-ups provided by AV vendors; this may be an initial indicator, but the analysis of identified files using techniques such as those identified by Kristinn and others, and listed in Lenny's cheat sheet, can provide definitive answers, and potentially even identify sources and additional issues.

Anti-Analysis
Remember the hoopla surrounding MS's COFEE being leaked? Well, check out DECAF. I wonder how this will affect other response toolkits and techniques that are similar to COFEE? Check out this post from the Praetorian Prefect blog on DECAF (thanks to Claus for the mention of the blog...).

A bit ago, Rich over at HBGary was nice enough to provide me with a dongle for Responder Field Edition, so that I could take a look at it and work with it from an incident response perspective. Having that kind of access to that kind of tool is really pretty amazing, as it provides a perspective to the overall environment that you don't get through reviewing web sites and testimonials.

First, some quick background...if you haven't been by the redesigned HBGary site, go by and take a look. Also, be sure to add the Fast Horizon blog to your RSS feed. The Fast Horizon blog gives some interesting insight into technical aspects of the Responder product (i.e., Digital DNA, etc.) that you won't get even by working with the tool. Also, as I'm working with the Field Edition, I don't have access to Digital DNA, so I won't be able to comment on that.

Okay, to make things even better when using tools like Responder to perform memory analysis, Hogfly has started a memory snapshot project, and has posted a memory snapshot from a VM guest running Windows XP (part II is posted here), with actual malware running. Pretty cool, and a great idea at that! This not only provides access to memory dumps with something to actually look for, but it also provides a great example of why you'd want to dump memory in the first place!

I'll be taking a look at Hogfly's first memory snapshot (.vmem file) with Responder and Volatility, as the snapshot is of a Windows XP system. I won't be using Memoryze, as I downloaded the MemoryzeSetup.msi file and ran it several times, and had nothing installed. I tried specifying a path for the installation, as well as using the default path. I even tried re-downloading the MSI file. Nothing worked.

Responder Field Edition
Responder provides a very easy to use GUI interface for working with memory dumps or snapshots. You simply select the memory snapshot to import, select a few options for what to do during processing, maybe add some keywords to search for, and then you let the tool do its thing.

A couple of very interesting things that Responder will do is look for "keys and passwords" (a string search for components that might include passwords) as well as for "Internet History" or URLs. When locating both of these, the column display in Responder includes a field for the offset where the string is located; this is useful as you may be able to map something interesting to a location in memory to give that string some context. In reviewing the recovered URLs from Hogfly's memory snapshot, I found a LOT of Microsoft- and MSN.com-related entries, as well as some others, such as:

http://192.168.30.129/malware/
http://*:2869/
http://www.iec.ch
http://%s:%u http://[::1]:8080/

There are a number of others (too many to list here), and there were also references to tunes.com and musicblvd.com.

For incident response purposes, one of the things I really like about Responder is the ability to quickly get the memory snapshot open and locate the issue. In this case, for me, the "offending" process stood out like a sore thumb...svhost.exe, PID: 1824, with a command line of "C:\Windows\msagent\svhost.exe". From there, you can expand the tree listing for that process in order to view specific information about and from that process. For example, we can see that the process has a couple of open file handles, to include the "foo" user's TIF index.dat file, and that the process also has an open TCP socket from port 1059 to a remote IP address on port 9899. This information can be extracted quickly once the memory snapshot has been collected, and the information available can then be used to correlate with other information, such as network packet captures, firewall or network device/appliance logs, etc.

From an incident response perspective, Responder is a great tool to really get you started in quickly identifying issues. I would like to be able to dump the binary, if possible...I selected the process in the Processes tree view (left-most pane of the UI), right-clicked and selected Package, View Binary from the context menu...some dialog boxes flashed, but I didn't end up with a binary, nor did I get anything stating that I couldn't have it. This may be due to the fact that the memory pages for the process executable had been paged out; in cases such as this, using FastDump Pro would've been the way to create a memory snapshot, incorporating the pagefile, as well, providing a more complete picture.

Over all, however, Responder lets you very quickly process information in a graphical format, providing speed and agility for something for which just a couple of years ago, there was no real process or methodology at all available.

Addendum: I heard from Rich with respect to parsing strings from binaries with Responder, and its actually pretty simple. If you select a particular process in the Processes tree view, you then expand the process listing for the Modules (see the above image) and select the executable image, which is also listed as a module. Expanding that tree lets you see Bookmarks and Strings. So with a couple of mouse clicks, you can view the strings extracted from any particular binary. Similarly, viewing, analyzing, or saving a copy of the binary is simply a matter of right-clicking on the name of the EXE file in the Modules tree view, choosing Package, and selecting the option that you want (see figure).

Volatility
Analyzing the memory snapshot with Volatility was somewhat different, as Volatility is a purely command line interface (CLI) tool. However, that does not make Volatility any less powerful when it comes to memory analysis. I won't go through everything Volatility can do, as it's been discussed before (and is rather nicely documented), but suffice to say that I ran the following commands against the memory snapshot:

ident
datetime
pslist/psscan2
connections/connscan2
sockets
files
regobjkeys

The great thing about these commands is that they can be included in a batch file and run all at once, and finished off with tools such as JL's vol2html to tie everything together into a single report (examples here and here). Don't forget that you can also include other modules, such as malfind, moddump, or Moyix's Registry modules. JL's code is a great example of what you can do with these tools, showing the flexibility available through Volatility.

Correlating output like this can make it easier to identify suspicious processes. From there, once you identify a process of interest, you can then use the "procdump" and "memdmp" commands to collect as much of the executable image and process memory, respectively, as you can. In this case, the executable image data appears in the local directory as "executable.1824.exe" and the memory dump appears as "1824.dmp". You can then view the contents of these files in a hex editor, or simply extract the strings. When running the procdump command, however, I received a number of "Memory not accessible" responses, indicating that the memory pages had been paged out.

As you can see, various memory analysis tools have strengths and weaknesses, and should be considered just as they are...tools to do a job. Rather than advocating one specific tool, I'd advocate understanding and using them all. Responder is more OS-complete than some of the other available tools, while Volatility provides a level of granularity not seen in the other tools. At this point, if someone asked me, "which tool do you recommend...Responder, Volatility, or Memoryze", I'd have to say "yes".

Another thing to remember is that looking at these tools in isolation only provides part of the answer, and only taps a small portion of the power available to you as a responder. For example, throw F-Response EE and FEMC, and RegRipper into your toolkit, and you're really expanding your capabilities.

Moyix has done it again! Not only has he updated his Volatility modules for retrieving Registry data from memory, but he's also developed a means to run RegRipper against a memory image! This was also picked up on SANS ISC. Very, VERY cool! Check it out and give it a try...

Thanks to Rich Cummings, I was recently able to take a look at HBGary products that they offer with respect to physical memory collection and analysis; specifically, FastDump Pro and Responder Professional.

First, the FastDump product is pretty cool. The free version of the tool allows you to dump the contents of physical memory from pre-Windows 2003 SP 1 systems (XP, Windows 2003 w/ no Service Pack). Now, a lot of folks are going to look at FastDump Pro and wonder why it's available for a fee; well a close look at the write up for the FastDump Pro should very quickly make anyone realize that the tool is definitely worth what they're charging; FDPro is not encumbered by the 4GB limit, works up to Windows 2008 (Windows 7 Ultimate Beta shouldn't be a problem, either), and it handles both 32- and 64-bit versions of Windows. That's A LOT packed into a $100 executable! FDPro also has the capability to incorporate collection from the pagefile, as well; however, in the limited testing I've done so far, analysis tools other than Responder won't necessarily "understand" the .hpak format.

Before we look at the Responder product, I'll have to upfront about my testing...my focus was incident response, and I really didn't intend to fully exploit Responder's malware analysis capabilities. So, essentially, while I had access to an evaluation version of the Responder Pro product, I was really using what amounted to the capabilities in the Field Edition. However, one of the things I've really been pushing with respect to incident response is speed...when an incident occurs, information collection and analysis needs to start as soon as possible, and tools like FastDump Pro and F-Response give you that speed in collection; Responder gives you speed in analysis for a range of Windows operating systems through a common interface.

So I started off by creating a case in Responder and loading the first memory dump/snapshot from the DFRWS 2005 Memory Challenge. Now, the snapshot can be a raw memory dump, collected via dd.exe (no longer available), F-Response + {enter a tool here}, FastDump, FastDump Pro, etc. Responder will identify the operating system of the memory dump and extract a good deal of information, making it available to the responder via the user interface (UI). So, once the memory dump has been collected, it just takes a couple of mouse clicks to get to the point where the responder is actually looking at the contents of the memory dump, viewing things such as the active process list, network connections, etc.

When I first looked at the Responder product a bit ago, as an incident responder, one of the issues I had as being able to quickly and easily find what I was looking for...in particular, the command line used to launch each of the processes in the active process list. Well, not only is this now available in the current version of the product, but you can also drag the columns in the UI to a more suitable location. For example, I dragged the column for the process command line over to line up the process name, PID, parent PID, and command line so that I could see everything together and quickly run through the entries.

You can also view the open network sockets from the memory dump in a very netstat-like format. An option that the Responder product provides is the ability to export the data you're viewing in a variety of formats (Note: the export functionality was disabled in the evaluation version). This allows you to use either screen scrapes of the Responder UI or exports of the data for reporting, or you export the data you've got and use tools similar to Gleeda's vol2html.pl to modify the format a bit.

Now, one of the options when importing a snapshot is to "Extract and Analyze All Suspicious Binaries"; this allows for a modicum of analysis to occur while importing the snapshot. What is "suspicious" is defined by rules visible in a text file, which means that as you become more familiar with the tool, you can comment out some of the rules, uncomment some, or add your own.

With Responder, you can also view the open handles and network sockets for a specific process, view, analyze, or save a copy of a binary (exe or DLL/module), run strings against a binary, etc. There is a great deal of capability in this tool, and there's no way I'm even beginning to scratch the surface. From an IR perspective, tools like this provide the first responder with a means of getting answers quickly, while at the same time being able to "answer new questions later". This is an extremely powerful capability...imagine quickly triaging an incident and being able to narrow down from your 500 possible systems the 12 or so that may be "in scope". Consider the cost savings. And when you do acquire physical memory, you've also got a copy of the malware (if there is any) in an unencrypted, un-obfuscated state.

Admittedly, Responder doesn't give you the same granularity, deep-dive capabilities, and flexibility of Volatility, but it does allow you to import memory snapshots from a range of Windows versions and puts the tools in your hands to quickly get the answers you need; that in itself is a huge plus! Again, I did not really dig into the full spectrum of capabilities of FastDump Pro and Responder, so if you're interested in really exploiting HBGary's capabilities for doing malware analysis, you should definitely consider giving them a call.

I was chatting with a friend the other day, and we got to talking about the issue of the memory footprints of various tools. We agreed on the need to capture the contents of physical memory first during incident response activities, before doing anything else. I'm also a proponent of grabbing the portions of memory (active process list, network connections, etc.) as well, as this information can be used to do a modicum of differential analysis, as well as give you a quicker view into what's going on...but be sure to grab as pristine a copy of memory first. As Nick and Aaron said at BlackHat DC 2007, so you "...can answer new questions later." Sage advice, that.

So we got to talking about the effect that just the first tool will have on memory...whichever tool you choose to use to dump the contents of physical memory, be it F-Response, FastDump, mdd, win32dd, winen, Memoryze, or if you choose to kick it old school on XP, an old, unsupported copy of dd.exe. Regardless, when you launch the tool, the EXE is loaded into memory to be run, establishing a presence in memory and a "footprint". This is something that cannot be avoided...you cannot interact with a live system without having some effect on the system. Responders should also be aware that the converse is true...during incident response for something like a major data breach (not naming names here...Heartland), the system will continue to change even if you don't touch the keyboard at all. Such is the nature of live response.

When the EXE is loaded into memory, it consumes pages that have been marked as available; these pages are not currently in use, but may contain remnants that may be valuable later in the examination, much like artifacts found in unallocated space on the hard drive. This is somewhat intuitive, if you think about it...if Windows were to launch a new process using pages already in use by another process, then you'd have random crashes all over the place. Depending on the amount of memory in the system, the memory manager may need to write some of the pages being used by other processes out to the pagefile/swap file in order to free up space...but again, the new process will not consume pages currently being used by another process.

I know that this is an overly simplistic view of the whole process, but its meant to illustrate a point...that point being that there's a LOT of discussion about "memory footprints" of various tools, but when I listen to the discussion, I'm struck by the fact that it hasn't changed a great deal in the past 5 years, and that it doesn't incorporate either the experts in the field, or actual testing. In fact, what strikes me most about these conversations is that the primary concern about "memory footprints" in many cases comes from the folks who "don't have the time" to conduct the very research and quantitative analysis that they seem to be asking for. I think that for the most part, many of use accept the fact that there, yes, Virginia, there is a Santa...I mean, there will be memory footprints of our live response actions, but that it is impossible to quantify the content that is overwritten.

I think that we can agree that memory pages (and content, given pool allocations, which are smaller than a 4K memory page) are consumed during live response. I think that we can also agree that from a technical perspective, while some pages may be swapped out to the page file, the only pages that will actually be consumed or overwritten with new content, and their old content will no longer be available (either in physical memory or in the page file) are those marked as available by the operating system. From an analyst's perspective, this is similar to what happens when files are deleted from a disk, and sectors used by those files are overwritten. This will lead to instances in which you can "see" data available in a RAM dump (through the use of such tools as strings or grep), but as the content may be in pages marked available for use, that data will have little context (if any) as it cannot be associated with a specific process, thread, etc.

A couple of very interesting things have come about lately; in particular, Brendan has released some new Volatility modules for extracting Registry hives from memory dumps! Very cool stuff! From his post, not only has Brendan done a fantastic job extracting the data, but he's looking ahead to integrating RegRipper into this in order to perform analysis!

Also, don't forget about Brendan's moddump.py and threadqueues.py modules!

Matt Shannon introduced me to Peter Mercer yesterday, and pointed me toward Intella, which looks like a fantastic product. Peter also mentioned the tool here (holy GUI, Batman!), and looking at it's capabilities, it's not just a PST/NSF file parser.

Over on the Security Ripcord blog, Don Weber has worked up a variant of Yara called "Scout Sniper"...if you know or have met Don, that makes complete and total sense. Don's some great work with the tool, you should definitely take a look.

In addition to Intella, I will be taking a look at a couple of other tools shortly. John Sawyer commented on one of my blog posts, which includes a press release from HBGary about their FastDump Pro tool that you should really take a look at.

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 mentioned 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.

Matthieu has made his Exploiting Windows Hibernation File presentation available...for anyone interested at all in Windows memory analysis, his presentation is well worth a look. Matthieu is the first person that I'm aware of to come up with a means of exploiting or taking advantage of the hibernation file as a viable source of data, and is a contributor to the Volatility framework. Other presentations and demos can be found here.

Volatility 1.3 is out! Volatile Systems (AAron, et al.) improves upon their venerable open-source memory analysis tool with this latest version, adding capabilities for extracting executables and a process's addressable memory, support for formats other than a dd-style memory dump (such as via mdd). Volatility 1.3 supports memory dumps from Windows XP SP2 & 3, and in addition, there is preliminary support for Linux memory dumps, as well.

The world of incident response is seeing changes. Incident responders have known for some time that particularly in the face of state notification laws and compliance standards from regulatory bodies, a new dimension has been added to what we do. Simple containment and eradication...get the bad guy or malware out...is no longer sufficient, as traditional first response obviates an organizations ability to answer questions about data exfiltration. Its long been known that new procedures and methodologies are needed, and in many cases, new tools. Well, folks, Volatility is one of those tools. When combined with tools like F-Response, the speed of response is maximized, allowing for greater data protection and business preservation. With F-Response increasing a responder's ability to collect data, and Volatility increasing the breadth and depth of analysis that can be performed on the memory dumps, a brave new world is opened up for incident responders!

The need for speed (without sacrificing a thorough and accurate response) is further illustrated in this SecurityFocus article, which illustrates something that incident responders and forensic analysts see all the time...AV doesn't always work the way we think it should.

Not only that, Volatility adds to a forensic analyst's toolkit, as well. The latest version has the ability to parse crash dumps, as well as hibernation files. Thanks to Moyix for all of his current and up-coming contributions, as well as folks such as Matthieu, Jesse, and all of those who put effort into the framework. Forensic analysts now have the capability to parse through and analyze additional historic remnants on a system.

Volatility requires Python, which for Windows systems is freely available from ActiveState.


Addendum: Yesterday, Matthieu updated both win32dd and the Sandman Framework. I tried out win32dd, and it worked like a champ! My first attempt resulted in some issues as a result of operator error...if you hit Ctrl-C while win32dd is running, you will get an error during every consecutive attempt to run the tool again, until you reboot. However, one of my tests as to run mdd and win32dd consecutively, and the result was files of identical size. The next step is to run Volatility 1.3 against each of them and see if there are any differences in results.

One of the questions that comes up from time to time during an examination is "whodunnit?" Take an examination involving, let's say...illicit images. The accused claims that they didn't do it, so the question becomes, who did? Sometimes the answer might be that someone else sat at the keyboard of the computer and performed the actions that lead to the images being on the system, and in other cases, the answer might be that the images were the result of a remote attacker/hacker or malware. The latter is sometimes referred to as the Trojan Horse Defense, or malware defense. In 2003, this guy used the malware defense and was acquitted of breaking into gov't computer systems...his claim was that someone had hacked his system and then launched the attack. From the article:

A forensic examination of Mr Caffrey's PC had found no trace of a hidden program with the instructions for the attack.

And yet, he was still acquitted. Since then, this has been a concern to many a forensic examiner and law enforcement officer...what happens if the accused makes that claim? How can a forensic examination corroborate that claim, or disprove it all together?

First, let me say that there is no 100% certainty in every examination that any or all of these techniques are going to work. There are certain things that computer forensic analysis will not reveal...one of them being things that simply are not there (ie, an analyst cannot find CCNs or artifacts of an intrusion if there simply are none to be found). However, what I'd like to discuss is some of the finer points of technical forensic analysis that can provide a good deal of information, such that the proper authorities (counsel, jury, etc.) have a better foundation on which to base their decision.

One of the areas of incident response that we're moving into fairly rapidly now...this area has been picking up steam a good bit lately since its introduction in 2005...is the collection and analysis of physical memory. In just about a week, the OMFW will occur and there will be a good number of folks presenting on and discussing this topic. There are a number of tools available now that will allow a responder to dump the contents of physical memory from a Windows system (XP, as well as Vista), and then analyze that dump...locate running processes, network connections, etc. In addition, PTFinder (Andreas appears to be attending OMFW) may still allow the examiner to identify exited processes (lsproc does this for Windows 2000 and can be ported to other versions of Windows)...procL from ScanIT appears to do something similar. A number of other articles provide information on retrieving image files, Registry keys, and even Event Log records from a physical memory dump. Further, a recent print issue of Linux Pro Magazine has an article on pg. 30 entitled Foremost and Scalpel: Restoring deleted files, in which the authors state, "Foremost and Scalpel ignore the filesystem and can even restore data from RAM dumps and swap files."

Within the realm of computer forensic analysis, there are a number of areas of a Windows system in which artifacts indicating user activity may be found. These go beyond the traditional examination of browser history artifacts, etc., and can provide indications of user activity, as well as historical indications of when the user was logged into the system. Windows Event Log and Registry analysis are two of these areas, along with the overall correlation of artifacts from different parts of the system...the more artifacts that the examiner is able to pull together, the more complete a picture that can be developed.

For example, for a backdoor to be useful to an intruder, it has to remain persistent (see Jesse Kornblum's paper, Exploiting the Rootkit Paradox with Windows Memory Analysis) across reboots. There are only so many ways this can occur, with persistent stores being primarily within the Registry and the file system. Using tools such as RegRipper, the persistence mechanisms with the system and user Registry hive files can be displayed, and the file system persistence mechanisms can be viewed, as well, for any indications of suspicious entries.

The Windows Registry holds a wealth of information about software applications installed on the system. Some of this information differentiates between those apps run by the user, and those run automatically by the system. In addition, the applications themselves have traces and artifacts...antivirus applications generally maintain configuration information in addition to log files. The Windows firewall installed on XP and above maintains it's configuration information in the Registry. Many GUI applications...to include image and movie viewing apps...maintain lists of files that have been opened and viewed by those applications.

Knowing where to look and what to look for can give the analyst the ability to paint a very detailed picture of what occurred on the system. Windows XP is something of a fickle lover, as it will provide the knowledgeable examiner with a wealth of information, while at the same time using it's own inherent anti-forensic techniques to deprive more traditional examiners of those artifacts on which they traditionally rely. Remember Harlan's Corollary to the First Law of Computer Forensics?

The great thing about all this is that while it may appear to be magical, requiring knowledge beyond the reach of all but a few individuals...that's simply not the case at all. All of this can be incorporated into the examiner's forensic analysis process and methodology.

So, the question isn't, was there or was there a Trojan or backdoor on the system what was responsible for this activity...it's now, do you want to answer the Trojan Defense before you walk into the interview room with the defendant and their attorney?

Resources:
Ex Forensis post

Based on my last post, I wanted to throw some quick tests together and see how things worked out...here's the results of what I found...

So, first off, I wanted to run ManTech's mdd...or memdd.exe, as it were. That worked out very well...ended up with a nice output file after running memdd.exe (renamed to mdd.exe) version 1.1:

06/17/2008 10:51 AM 23,520 mdd.exe 06/17/2008 10:56 AM 3,210,854,400 test.dmp

Next, I ran winen.exe, the tool available from GSI, as part of the EnCase 6.11 install (yes, I am a "dongled", licensed user). As I was running this on a Windows XP SP2 system with 2.99GB of RAM (4GB on the board) and used the defaults in the configuration file (except for where I was required to make an entry), I ended up with a total of five .E0x files. I then opened the .EO1 file as an evidence item in FTK Imager Lite v2.5.1 and, as expected, Imager did not recognize the file system. However, Imager appears to have read the EWF header info just fine, because it recognized what I had entered into the config file.

So I then chose Create Disk Image from Imager's File menu item, and chose Image File from the Select Source dialog. During the process of selecting options, I chose to have Imager output the image in 2000MB files (as opposed to the default 640MB file sizes used by winen). This resulted in two image files (winen.001 and .002), which I then cat'd together using the type command on Windows into a single file (winen.bin):

06/17/2008 01:18 PM 2,097,152,000 winen.001
06/17/2008 01:19 PM 1,113,702,400 winen.002
06/17/2008 01:42 PM 3,210,854,400 winen.bin

Notice that the file size for the final winen.bin file is the same as the test.dmp file created using mdd. Very cool.

Now...what to do with it? Well, that's where Volatility 1.1.1 comes in...I grabbed ActivePython, installed it, and was up and running with Volatility 1.1.1 in no time! I was able to view the process list, run the 'dlllist' command to get modules and the command line for each process, etc...all very cool stuff. Volatility worked very well on both memory dumps...not just the winen/FTK one, but the mdd RAM dump, as well.

So what's next? Well, I'd like to see about digging a bit deeper into the dumps, including:

- As Moyix discussed, enumerating Registry hives (or just keys and values) from memory
- Run Andreas's PTFinder against the memory dump and develop graphs of the processes using Richard McQuown's PTFinderFE
- Attempt to do file carving via scalpel

Anything else? What's in your wallet? =)

Take aways from this...it's likely that like linen, winen.exe will show up on IR tools distros...but you're not restricted to using EnCase to perform analysis of the memory dumps produced by such tools. Using free tools, you can convert the .E0x files to a dd-style format, and then use other freely available tools to parse through the memory dumps.

Addendum: Got this from someone who ran kern.pl on a memory dump from XP SP3 recently...

File Description : NT Kernel & System
File Version : 5.1.2600.5512 (xpsp.080413-2111)
Internal Name : ntkrnlmp.exe
Original File Name :
Product Name : Microsoft(R) Windows(R) Operating System
Product Version : 5.1.2600.5512

Pretty sweet, eh?

If you're using winen.exe to collect the contents of RAM and you're also using EnCase, you might want to check out these EnScripts from TK_Lane that will pull process information from the .EOx files. I haven't tried them yet, but thanks, TK, for providing them!

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.

There are some interesting events coming up this summer (and beyond) that I wanted to point out to folks...

DFRWS is this summer (11-13 Aug), but the Open Memory Forensics Workshop (OMFW) will be held just prior (info here, update here). OMFW looks like a great opportunity...it's a half-day event, but looking at the list of speakers and panelists...wow! If you haven't already, grab books off of your bookshelf (I *know* most of you recognize author names...) and get your copies signed! OMFW is brought to you by the letters M and S, and these guys.

If anything, this really shows how the interest in analysis of physical memory is really picking up. More than anything, I'd have to say that the interest is really been driven by the guys over at Volatile Systems, along with a host of other names. There is a great deal of extremely valuable information available in physical memory (RAM), and these guys are leading the way in showing us what's there, and providing tools for getting at it and making it available, but more importantly, useful to analysts.

As a side note, if you look around the community/industry, there is a big piece that's missing right now...collection. That's right...there are open source and commercial tools (from Mandiant and HBGary...and HBGary is apparently partnering with GSI) that provide the ability to parse, comb through and analyze a physical memory dump, but very few that provide the ability to extract the contents of RAM from Windows 2003 SP1 and above (e.g., Vista, Win2K8) systems. I even received an email from a friend at MS yesterday asking me if I knew of any such tools. One would naturally assume that we'd eventually see such a tool from MS/SysInternals. One way to go about changing this...buy more F-Response!

Note: Paraben is having an Innovations Conference in Utah in Nov, 2008. They also let you vote for a company or product that you feel is most innovative for 2008...I voted for F-Response.

Okay, back on track...what was I talking about? Oh, yeah...

Looking at the program for DFRWS 2008...yet another impressive line-up. I'm hoping to go...working for a large corporate (think "glacial") entity (think Borg cube), these requests are always in limbo. However, I'm very interested in Timothy Morgan's talk, as well as a couple of others. It also looks as if some of the speakers from OMFW are going to be on deck for DFRWS, as well. Maybe a good opportunity to ply familiar faces and famous names with some of the locally brewed beverages.

Interestingly enough, the local RCFG conference (which overlaps with DFRWS this year) has been cancelled. That's too bad...this conference is held on the GMU campus and for the most part is a nice, smaller conference. However, with the right leadership, it has the potential to really be a premier conference...not just for local LE, but in general. In fact, an interesting thought would be that since some folks are going to be in the area anyway, talking about the same topic...

Also, in Jan 2009, there is the DoD CyberCrime Conference...Jesse mentioned the CfP here. It's too early to list the speakers, but I had an opportunity to visit the conference in 2007 and it was a good one...lots of attendees, lots of events, lots of really great speakers.

I ran across this info today, and thought that I'd post it...it seems quite important, in that it pertains to the use of physical memory (RAM) to deal with whole disk encryption (WDE), referred to as "cold boot attacks on disk encryption".

This looks like very cool stuff. Give it a read, and let me know what you think.

Don't forget that TechPathways provides a tool called ZeroView, which can reportedly be used to detect WDE.

You're probably wondering, "Since when did Metallica have anything to do with Windows forensics?"

My answer to that is...since ALWAYS!

Okay...enough of that. The Sandman I'm referring to isn't the one from the Metallica song. Rather this one has to do with the Windows hibernation file (get it? "sleep". "Sandman". get it? no...you don't...). Evidently Nicholas and Mattheiu has been working on a C library for reading/writing the Windows hibernation file. This sounds really cool, and it looks as if they're going to include Python bindings, as well as a couple of sample apps, one of which will reportedly convert a hibernation file into a dd-style memory dump. Very cool. Keep in mind, however, that a hibernation file doesn't contain the current contents of memory, but rather the contents of memory from when the file was created.

Sandman looks like a good tool to have in your kit, and I can't wait to try it out.

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.

As a follow-on to the tool testing posts, I wanted to throw something else out there...specifically, I'll start with a comment I received, which said, in part:

Tool criteria include[sic] whether the data the tool has acquired actually existed.

This is a slightly different view of RAM acquisition (or "memory dumping") than I've seen before...perhaps the most common question/concern is more along the lines of, does exculpatory evidence get overwritten?

One of the issues here is that unlike a post-mortem acquisition of a hard drive (ie, the traditional "hook the drive up to a write-blocker, etc."), when acquiring or dumping RAM, one cannot use the same method and obtain the same results...reproduceability is an issue. Because you're acquiring the contents of physical memory from a running system, at any given point in time, something will be changing; processes process, threads execute, network connections time out, etc. So, similar to the live acquisition of a hard drive, you're going to have differences (remember, one of the aspects of cryptographic hash algorithms such as MD5 is that flipping a single bit will produce a different hash). I would suggest that the approach we should take to this is to accept it and document it.

That being said, what are some of the questions that we can anticipate addressing, and how would/should we answer them? I'll take a stab at a couple of basic questions (and responses), but I'd really like to see what others have to say:

1. Did you acquire this data using an accepted, validated process?

In order to respond to this question, we need to develop a process, in such a way as to validate it, and get it "accepted". Don't ask me by whom at this point...that's something we'll need to work on.

2. Did this process overwrite evidence, exculpatory or otherwise?

I really think that determining this is part of the validation process. In order to best answer this question, we have to look at the process that is used...are we using third-party software to do this, or are we using some other method? How does that method or process affect or impact the system we're working with?

3. Was this process subverted by malware running on the system?

This needs to be part of the validation process, as well, but also part of our analysis of the data we retrieved.

4. Did you add anything to this data once you had collected it, or modify it in any way?

This particular question is not so much a technical question (though we do have to determine if our tools impact the output file in anyway) as it is a question for the responder or examiner.

As you can see, there's still a great deal of work to be done. However, please don't think for an instant that I'm suggesting that acquiring the contents of physical memory is the be-all and end-all of forensic analysis. It's a tool...a tool that when properly used can produce some very valuable results.

In my last post, I described what you'd need to do to set up a system in order to test the effects of a tool we'd use on a system for IR activities. I posted this as a way of filling in a gap left by the ACPO Guidelines, which says that we need to "profile" the "forensic footprint" of our tools. That post described tools we'd need to use to discover the footprints within the file system and Registry. I invite you, the reader, to comment on other tools that may be used, as well as provide your thoughts regarding how to use them...after all, the ACPO Guidelines also state that the person using these tools must be competent, and what better way to get there than through discussion and exchange of ideas?

One thing we haven't discussed, and there doesn't seem to be a great deal of discussion of, is the effects of the tools we use on memory. One big question that is asked is, what is the "impact" that our tools have on memory? This is important to understand, and I think one of the main drivers behind this is the idea that when IR activities are first introduced in a court of law, claims will be made that the responder overwrote or deleted potentially exculpatory data during the response process. So...understanding the effect of our tools will make us competent in their use, and we'll be able to address those (and other) issues.

When a process is created (see Windows Internals, by Russinovich and Solomon for the details, or go here), the EXE file is loaded into memory...the EXE is opened and a section object is created, followed by a process object and a thread object. So, memory pages (default size is 4K) are "consumed". Now, almost all EXEs (and I say "almost" because I haven't seen every EXE file) include an import table in their PE header, which describes all of the dynamic link libraries (DLLs) that the EXE accesses. MS provides API functions via DLLs, and EXEs access these DLLs rather than the author rewriting all the code used completely from scratch. So...if the necessary DLL isn't already in memory, then it has to be located and loaded...which in turn, means that more memory pages are "consumed".

So, knowing that these memory pages are used/written to, what is the possibility that important 'evidence' is overwritten? Well, for one thing, the memory manager will not overwrite pages that are actively being used. If it did, stuff would randomly disappear and stop working. For example, your copy of a document may disappear because you loaded Solitaire and a 4K page was randomly overwritten. We wouldn't like this, would we? Of course not! So, the memory manager will allocate memory pages to a process that are not currently active.

For an example of this, let's take a look at Forensic Discovery, by Dan Farmer and Wietse Venema...specifically, chapter 8, section 17:

As the size of the memory filling process grows, it accelerates the memory decay of cached files and of terminated anonymous process memory, and eventually the system will start to cannibalize memory from running processes, moving their writable pages to the swap space. That is, that's what we expected. Unfortunately even repeat runs of this program as root only changed about 3/4 of the main memory of various computers we tested the program on. Not only did it not consume all anonymous memory but it didn't have much of an affect on the kernel and file caches.

Now, keep in mind that the tests that were run were on *nix systems, but the concept is the same for Windows systems (note: previously in the chapter, tests run on Windows XP systems were described, as well).

So this illustrates my point...when a new process is loaded, memory that is actively being used does not get overwritten. If an application (Word, Excel, Notepad) is active in memory, and there's a document that is open in that application, that information won't be overwritten...at worst, the pages not currently being used will be swapped out to the pagefile. If a Trojan is active in memory, the memory pages used by the process, as well as the information specific to the process and thread(s) themselves will not be overwritten. The flip side of this is that what does get "consumed" are memory pages that are freed for use by the memory manager; research has shown that the contents of RAM can survive a reboot, and that even after a new process (or several processes) have been loaded and run, information about exited processes and threads still persists. So, pages used by previous processes may be overwritten, as will pages that contained information about threads, and even pages that had not been previously allocated. When we recover the contents of physical memory (ie, RAM) one of the useful things about our current tools is that we can locate a process, and then by walking the page directory and table entries, locate the memory pages used by that process. By extracting and assembling these pages, we can then search them for strings, and anything we locate as "evidence" will have context; we'll be able to associate a particular piece of information (ie, a string) with a specific process. The thing about pages that have been freed when a process has exited is that we may not be able to associate that page with a specific process; we may not be able to develop context to anything we find in that particular page.

Think of it this way...if I dump the contents of memory and run strings.exe against it, I will get a lot of strings...but what context will that have? I won't be able to associate any of the strings I locate in that memory dump with a specific process, using just strings.exe. However, if I parse out the process information, reassembling EXE files and memory used by each process, and then run strings.exe on the results, I will have a considerable amount of context...not only will I know which process was using the specific memory pages, but I will have timestamps associated with process and threads, etc.

Thoughts? I just made all this up, just now. ;-) Am I off base, crazy, a raving lunatic?