Saturday, June 18, 2005

Memory collection and analysis follow-up

This topic is by no means closed...in fact, I think that the discussion of dealing with physical memory, memory analysis, etc., for forensics and/or malware analysis is just beginning. Given that I'm one of those folks who has spent the past couple of years knodding my head about using dd.exe to image RAM, simply because I didn't know any better, and given the number of folks I've run into who have done the same thing, it's pretty clear to me that this is an issue that needs to be addressed.

IMHO, the best way to approach this is to provide the knowledge, weigh the pros and cons, and let the user/reader make the decision on how to proceed. For example, sometimes, running tools such as the FSP would be the way to go...correlating and analyzing the results can get you a long way. However, those are user-mode tools and things might be missed...but then again, with the right combination of tools and analysis, you may be able identify those things that are missed, at least...not what the data is, but just the fact that it's missing (think of this as akin to identifying the wind...we can't see it or taste it, but we know it's there based on how it affects the environment).

In other cases, such as malware analysis (and forensics involving specific processes running on the victim system), using the debugger tools to grab the contents of process memory, and then using the same debugger tools to analyze the information retrieved, might be more desireable. You'd get some of the same information about the process as you would with the user-land tools from the FSP (i.e., loaded modules, handles, etc.), but this might be the preferred approach. Putting the tools on a CD and writing the process memory dump file to a thumb drive would be a great way to handle this.

Now, when it comes to a full-out memory dump, so far as I've been able to determine, the only real way to do this is with a crash dump. Crash dumps can be triggered manually, as mentioned in my previous post (via the MS KB article), but doing so requires advanced planning. I'd highly recommend incorporating these changes into malware analysis systems. I'd also recommend that the settings be incorporated into critical systems, as at the very least, analyzing the memory dump would make root cause analysis much easier. One of the methods MS mentions for performing troubleshooting is "send us your crash dump"...Oracle does this as well for their products. For forensic purposes, one has to take this into consideration, but I tend to believe that the benefits may outweigh the risks (i.e., overwriting exculpatory evidence when the full crash dump file is written to disk)...depending upon the situation.

I'd appreciate hearing your thoughts...considering that in the past couple of days, I've completely thrown out the idea of using dd.exe to image physical memory, and thrown out pmdump.exe for getting process memory. Now, I've got to go back and rewrite my already-published articles...

2 comments:

Keydet89 said...

Ok, don't get me wrong...I haven't really "thrown out" the idea of using dd.exe and pmdump.exe for malware analysis, incident response, and forensics. I intended that comment to be tongue-in-cheek, to generate discussion. I firmly believe that the key to furthering the community is to know what tools are available, know their strengths and weaknesses, and to (most importantly) engage in discussion of the topic.

The fact remains that IR and forensics analysis, particularly on Windows systems, lags far behind what the "bad guys" are capable of doing...and what they are actually engaged in. By sharing information, we can improve the quality of response.

John H. Sawyer said...

I am posting this here since it is relevant and figured you would create a new post based on it. Have you checked out the DFRWS memory analysis forensic challenge results? Both of the "winners" used some interesting techniques to analyze a memory dump done with dd.exe from a Helix CD under Windows. The coolest tool was freshly written by Chris Betz and pulled out full process listing and individual process information. Sure beats the freaking MS Debugging Tools. http://www.dfrws.org/2005/challenge/index.html