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 w
as 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!
The name should be mdd, short for ManTech dd.
ReplyDeleteHow did the image from mdd work with Volatility? What kinds of data could you extract from it?
The dump grabbed w/ mdd worked great with Volatility...in fact, there was one process that I found with Volatility and the 'dlllist' command that threw some Python exceptions...but that was from the winen/FTK RAM dump. The mdd dump ran a bit cleaner in that regard.
ReplyDeleteI'll add that to the actual post itself to be a bit more clear...
It might be a bit easier to use EnCase tools to do the analysis if you capture with winen.exe. I don't know if you have tried my EnScript (http://eddandforensics.blogspot.com/) but it gets the running and exited processes from a memory dump (XP SP2) and cuts out the work of converting from .E01 to dd to use with volatility. PyFlag also has a nice user interface and can do analysis on .E01 memory files but it is a bit buggy.
ReplyDeleteI just ran an image created by mdd in Volatility, just trying everything out. The mdd image worked perfectly using Volatility in Windows with ActivePython (thanks Harlan for blogging about it!). I've run the pslist and dlllist functions against the mdd image and had no errors. More experimenting to do.
ReplyDeleteThis is an image from an XP SP3 machine. This stuff is really cool. :)
KP
I don't understand why you bother collecting all of the memory when you can just run trusted CLI tools to get the same data...
ReplyDeleteIs the evidence somehow more trustworthy similar to how analyzing a file system image is more trustworthy than analyzing a live system which could be manipulated by a rootkit?
It's more trustworthy because it does not rely on the native APIs, which can be hooked or otherwise made to lie. This is not to say that the acquisition process could not be corrupted by a rootkit, but at present DDefyM (http://www.root.net.nz/projects.html) is the only known tool that can do this (and AFAIK it only works on Garner's old dd.exe). One could also try to capture image using a hardware-based method, such as Firewire or a PCI-based card, which should be quite reliable (although even these could be fooled in some specific circumstances -- see Joanna Rutkowska's talk from Blackhat DC 2007 for details).
ReplyDeleteIn theory it also lessens the impact on the system, as only a single tool has to be run, so the memory footprint can be minimized.
Also, you get the advantage of repeatability -- running Volatility's connections module will always show you the same output; if you're using live response tools the answer might change depending on the state of the system at that moment. A memory image gives you a frozen snapshot of the system's state to work with.
Finally, you can go back to the memory image and ask new questions as you think of them, or informed by new information. For example, your initial live response may not check for hidden processes running on the machine. With a memory image, once you realize that there might be hidden processes, you can go back and search the image for them. If only live response is used, the system may have changed significantly (turned off, rebooted, even reinstalled) by the time you go back to run your live tools again.
That answers a lot of questions I had, thanks moyix!
ReplyDeleteI don't understand how to use Volatility in Windows. I installled ActviePython and typed python setup.py install in cmd.prompt. Build folder was populated. Now what?
ReplyDeletesorry goit ran
ReplyDelete"python volatility psllist -f c:\file.dmp" from cmd prompt-thanks
Moyix, on DDefyM, in actual fact, it worked against all known tools at the time I wrote it (although I didn't have a copy of encase to test).
ReplyDeleteI haven't tested it against mdd or win32dd due to time constraints, but looking at the code they will get duped just the same. It installs a generic hook on ZwMapViewOfSection in the kernel so unless you bypass that the rootkit will win. It also fools a number of anti-rootkit tools that use the same kind of access for raw reads.
There are a few other methods for detection and more reliable capture, but they all suffer from pretty obvious weaknesses.
I've been thinking of resurrecting the code into something useful given the new interest, but just haven't had the time.
Ah, I stand corrected re: DDefyM and what tools it fools. To clarify: reliable acquisition on a system when an adversary is actively trying to subvert you (for example, through a rootkit) is hard-to-impossible.
ReplyDeleteHowever, *given* a reliable image, the results should be accurate, and not fooled by things like syscall hooking.
Hi all!
ReplyDeleteI'm trying to create mdd.exe from mdd version 1.1's zip file. I got one exe, but not working correctly
-my new mdd.exe:
output
-> ERROR: Unable to extract driver!
-> ERROR: Failed to open PhysicalMemory section!
Is there any new updates of mdd source code availbale???????
ReplyDeletePlease reply
You should be contacting the authors, not posting here...
ReplyDelete"However, *given* a reliable image, the results should be accurate, and not fooled by things like syscall hooking."
ReplyDeleteSpecifically, how does this distinguish memory forensics from conventional methods of acquiring volatile evidence? MDD and win32dd don't use sysenter?
- Rossetoecioccolato.
Has anyone tried using the pagefile.sys with Volatility? If so, how? It doesn't recognize it as an acceptable file - dump. Thanks!
ReplyDeleteTim,
ReplyDeleteAre you referring to incorporating the pagefile with a memory dump, or running it through Volatility instead of the memory dump?
If it's the latter...well, that's not what Volatility was intend for...
Yes, I'm trying to substitute the physical memory dump for pagefile.sys in Volatility.... any suggestions? Thanks for the response.
ReplyDeleteNo suggestions...other than to say that you can't do that.
ReplyDelete