Memory Acquisitions. (Memoryze, FTK imager, Sleuthkit, etc.)

First we need an image of memory. There are options for either a partial or complete image of memory. Circumstances will usually dictate which one will be provided. And it goes without saying, the more complete your image, the more artifacts you will have at your disposal.

So where can we find or obtain these images of memory? Generally, there are about Six different memory image formats that are available to an investigator, that can be utilized for an investigation when analyzing artifacts that were in the systems memory. Some of them are "whole" captures of memory, while others are only partial captures of memory. You'll generally get a raw dd image from a live acquisition, while the other alternate sources of evidence listed below you can find on the secondary storage in case you can't perform a live acquisition, or you can simply supplement these files alongside your raw acquisition.

Some of the files discussed below are hidden files in windows 8 & 10. To view them you'll need to open explorer, click the view tap in the top left, click the option tab in the top right, then click view in the folder options box. Once there, uncheck "Hide protected operating system files", then click apply. Then the Hiberfil.sys, Pagefile.sys, and the Swapfile.sys file's will be viewable in your C:\ drive:

A) raw dd image: When an acquisition tool images memory, it will create an image file that will be either a raw dd image, or structured will be a format that is it's own particular proprietary format. (For example, HB Gary's responder tool is in .hpak format.) Acquiring a dd image is the most common method of acquisition, and the acquisition tool should include the systems pagefile.sys, for a more complete memory capture. This would be a "complete" memory capture. A limitation with some acquisition tools is that they only have access to the physical memory address spaces, and don't include the "virtual" addresses (page files) that are necessary for a complete image.

B) Pagefile.sys: Its size can grow to be 150% of your current RAM size, depending on what your OS configuration settings are adjusted to. This file is only a piece of the memory puzzle (when analyzed by itself), mainly because it's containing data that is less visited than compared to the data that is executing or waiting to be executed in memory. The file offers some help alone with string searches, but becomes even more helpful when supplementing it into your memory analysis. (ex: ftk imager does). These files work with virtual memory mechanisms that use a page tables to keep track of the noncontiguous pages (4K) of a program, which have been paged out to disk instead of into memory. There can be up to 16 page files, each one made up of memory pages, that can be built up to a large size.

C) Swapfile.sys: Seen in windows 8 & 10, alongside with the pagefile.sys. I also think they were used in older versions of windows like XP. In the newer versions of Windows like 8 & 10, this file caters to the "universal applications" that are used. This virtual memory mechanism doesn't just store and allocate pages like is done with the pagefile.sys, instead, the swapfile.sys will swap out entire programs to disk, when they aren't frequently being used. Page file = swaps the small pages of code out to disk, whereas Swapfile.sys = swaps out entire programs to disk.

E) Hiberfil.sys: Contains a partially compressed copy of memory. To analyze this file as it is, can be more of a pain than it should be, since you would have to worry about decompression each time you analyze a certain segment of the file. You'll need to convert the file to a raw dd, with one of the Volatility plugins. If you don't have a raw image of the memory with an acquisition tool, this would be your best second option. Just realize, if your system hasn't been put in a hibernated state in days or maybe even weeks, the hiberfil.sys file could be too outdated to be relevant.

Here's how to recover a hiberfil.sys file from an imaged (dd) 300 gb drive, obtained via FTK imager, of an NTFS hard drive with The Sleuthkit:

• 1) Find the starting sector of our PRIMARY NTFS partition with the TSK command "mmls NTFSimage.dd":  or you can use a native "fdisk -l NTFSimage.dd".

• As you can see, we have three partitions that exist on this drive. dd2, which is 297.6G in size, is clearly our partition of interest, (where all our data is stored). So we will use its starting byte offset number "206848", as our indicator to any of the commands that we will feed to TSK with the -o parameter. 
• 2) Now we're going to use "grep", an ASCII text searching tool, with "fls". "fls" will searching your partition, when you provide it with the -o 206848 parameter, and all it finds, will be piped through and filtered via "grep hiber", leaving you with any system files that contains that string. So here is our command: "fls -206848 | grep hiber":

• Those three numbers in the bottom left, tell us the inode number of the file, and some attribute indicators. For now, we're focusing on the inode number 41446.
• 3) We're going to supply that inode number to 'icat', which is a TSK tool that will extract the space that is allocated to the inode number it is provided, in this case, the data units of our hiberfill.sys file, and forward it to our desktop, and naming it "hiberfil.sys". Here's the command: 'icat -o 206848 NTFSimage.dd 41446 > /root/Desktop/hiberfil.sys". The hyberfil.sys file that we have named and created on our desktop, is now going to contain the data units of our actual hiberfill.sys image file. icat basically searches for files according to the metadata address you provided it, which is great, just in case it is an unallocated file, it will still find it. And regardless of the file, once you extract it, you can then view the contents of whatever you extracted. If it was a photo, you could view the photo. Since our hiberfil.sys file is going to contain raw data, it's really not going to be viewable unless you supply it to a forensic tool (Volatility), or a hex editor. 

You can use the same process to extract the pagefile.sys from a dd image.

F) Crash file: There are about three different types of crash dumps: small 64 kb, kernel, and a complete crash dump. A complete will contain a complete copy of the contents in RAM. In windows, there are proprietary headers that are added to the dump, compliments of Microsoft. This allows you to work with  a Windows crash dumb with their developed debugging tools, like the native WinDbg. I don't have any experience using debuggers, but much like these other formats, Volatility plugins allow you to convert a crash file to a raw image. All you need to know is how to create, and locate a crash dump file. Many systems are configured to write crash dumps to disk upon a BSOD, to the %systemroot%\Memory.dmp directory. Here are the steps to create a .dmp to the C:\ directory in Windows 10:

1. Click "Search the web and Windows"
2. Search "This PC"
3. Right click on This PC > Properties.
4. On the left side of the menu, click Advanced system settings.
5. Click settings under Startup and Recovery.
6. Under "write debugging information", click the arrow, and select "complete memory dump". Also, make sure you have checked "automatically restart", and checked "overwrite any existing file", before clicking OK. 
7. Your computer will prompt you to restart.
8. After restarting, start the run command, and type %systemroot%. (make sure you're hidden files are showing. If not, refer to steps up top.)
9. Scroll down and view your MEMORY.DMP file.

G) VMware files: When you install VMware, there are four primary VMware files that are created to simulate a computing environment, and are installed and stored to your host drive. (There are more than four VM files created in order to run a virtual environment, these are just the ones found most interesting when forensically analyzing a virtual system). I'm running my VMware on my Mac, so locating your VM files will be a different process in Windows.

After you've installed a virtual machine in VMware, a virtual machine directory was created under Documents. Locate your vm file and right click > select show package contents, and you will see all the VM files used to run your simulated machine.

Using the "Suspend" feature and/or the "Snapshot" feature within VMware allows you to freeze the running state of the virtual system, which will then create some of these files you see in the photo above. (Suspend or Snapshot does not create the .vmdk file for example). You can analyze a VM either in a running state, or acquire these files, which contain data that are the equivalent to what you would acquire during a live acquisition. Since these VM files contain the bit by bit copies of the system, they are considered raw, and also contain unallocated data as well.
Both FTK and Encase are fully capable of viewing the contents of a .vmdk a file.
Another thing to keep in mind, is since there are many .vmdk files, each one containing a portion of the file systems data, you'll need to combined these files with something like vmware-vdiskmanager.exe, which comes with the workstation version of vmware, if you plan to mount the image, and view it in something OTHER than FTK imager, or Encase.

I'm getting somewhat ahead of myself. So here are the Four main files, VMware uses to simulate a virtual environment:

1. .vmdk: These are the files that hold your file system data. Their sizes vary, and have a maximum limit that is dictated by your vmware settings. When you first boot up a running VM, you will see these files sitting in their VM's directory. In other words, they exist before you create your first snapshot. But, when you create your first snapshot, a whole new list of about 20 of these files are created, and are used to store file system data for your newly running current state. VMDK's are just raw binary files, that you can easily mount or convert in either FTK Imager, or Encase, to view their contents. The windows version of VMware comes with command line utilities that allow you to combined these files, to mount and analyze the entire virtual drive (of a specific snapshot). Since this has nothing to do with memory data, just put this on the back burner for now. 
2. .vmsn (snapshots): (Here we begin our discussion of the next three files that will contain actual contents of physical memory). The .vmsn file will contain a small amount of some memory content, and is created when you take a snapshot of the VM, and will store the state of the VM at the time of the snapshot. A .vmsn file contains a fairly complex structure layout which holds the physical memory runs, the VM configuration data, CPU registers, and even a PNG thumbnail of the VM screen at the time of the snapshot was taken. Every VM will have their own .vmsn files, one per snapshot taken. It is possible to convert a .vmsn file to a raw dd-style memory dump, by extracting the physical memory runs to a separate file by using the Volatility imagecopy plugin. (volatility-labs.blogspot.com). This file, although not a complete memory dump of the VM's RAM, still contains data essential to reconstructing a memory dump. 
3. .vmss (A primary image of ALLOCATED memory): When you push the suspend button, this file will pop up, along with a .vmem file that is created at the same time. You could use the .vmem file with volatility, as it is a more complete image of your RAM, but the .vmss file is also sufficient enough to use with volatility, as it contains all of the allocated space in memory at the time in which the image was taken. This file is used to store the active contents of memory, so it can be used to quickly restore your VM, when you press play again. When you SUSPEND your virtual machine, this file will be created in your virtual machine directory. There is only one of these files, since there can only be one session suspended at a time. Once you press play, and run your VM, the .vmss file disappears. You can use the vmss2core (a windows binary), to convert the .vmsn/.vmss files to a raw memory dump format, if there is a forensic analysis tool that will require a specific format to recognize in order to perform an analysis. 
4. .vmem: (A primary image of RAW memory). This file is the real deal. This is the file you want to use when running plugins against it with the Volatility program. This file has the same physical structure as a raw dd memory dump. So this .vmem file will not only contain the allocated space of RAM, but the physical unallocated space as well. This file will exist when you create a Snapshot of a VM, (a .vmem for each snapshot), and also, when you suspend a VM. This is the crown jewel of all the VM files, since it is practically the equivalent to a memory dump file. Since this file is a physical replica of your VM's RAM, you will get all the same benefits and artifacts you could find in any other raw RAM dump. There are a bunch of Volatility plugins that work very well with these files. As a bit of a sum up, all these VM files can be handled by the Volatility framework, without the need to convert them first. (There also may be some issues when trying to parse a memory dump file that is more than 4GB in size with Volatility). 

How to use FTK imager from a USB drive

The methods i would choose when acquiring an image of a targets memory, would be to first install a memory acquisition tool on a "safe" system first, find the file path in which the acquisition program has been installed to, drag and drop the programs folder onto your usb drive. For example, when you install FTK imager on a safe system, it's installed to my C:\Program Files\AcessData\FTK Imager location.

Before plugging your USB drive into the target system, use a write blocking device like Wiebitech Forensic Ultradock in between your drive and the suspects computer to prevent any writes to the targets disk. I don't have this device, so i couldn't tell you if FTK imager will run properly from this sort of a setup. FTK Imager and FTK imager Lite, (which has a smaller memory footprint), are said to be less intrusive on a suspects computer during a live acquisition. The writes to memory are very small, and the writes to disk are reportable non existent. But, on AccessData's website, they do say to be forewarned that FTK imager may write to your targets disk. So, there may be files written to the AppData directories in windows, or there may not be. (Hence the importance of a write blocker.) It is also worth mentioning, if the tool doesn't install files into the AppData directory, there still will be minor changes to the registry hives that maintain USB history artifacts, shellbags, or prefetch directories, which will all be inevitably altered when running a program from a usb drive.

Not all programs can run from a USB drive without formatting or installing certain programs to the drive first, but FTK Imager Lite and Memoryze from Mandiant both can. (With Memoryze you do you have to do some special formatting first.) Since i already started discussing FTK's version already, let me pick up where i left off.

So if you've already installed FTK Imager on a safe computer, drag the 'AccessData' folder from the location C:\Program Files\AcessData\FTK Imager, and drop it into your USB drive. That's it! You don't have to do any test runs like you will with Memoryze. You can now plug your drive into your targets machine.

Once plugged in:

1. Open cmd as administrator. (This is not a trusted shell. Use other method if this is a concern.)
2. Type the letter in which your USB drive is located. (Mine is located in the E: path.)
3. cd to the directory in which your FTKI tools are located. (Mine are under the 'FTK Imager' folder.)
4. Then type the command: start "FTK Imager.exe" "\FTK Imager\FTK Imager.exe". This first quotation parameter is holding the executable to be run inside the USB drive, and the second set of quotations are listing the file path in which it exists inside the USB drive. Include the quotations in your command and ftp will start.

I'm not going to screenshot every step on how to button push FTKI, into creating a memdump.mem image. Just make sure you select "include pagefile", and don't select "create AD1 file". Once the imaging is complete, you will have two files; the memdump.mem, and the pagefile.sys. You will have to analyze these two files separately, having the option to run strings and/or use Volatility for both. But yes, the .mem is going to be your most valuable source of artifacts, especially if you are investigating a malware incident, since the .mem is where your more current artifacts will be. And i also should mention, there is a lite version of FTKI, which is better suited for usb to live acquisitions. I just already had FTKI installed on my usb drive.

How to use Memoryze from a USB drive

1) Install memoryze from fire eye.
2) Then create an empty folder on your USB drive called "Memoryze". ex: "cd E:\Memoryze".
3) Go to the Fireeye page and download the MSI package installer for memoryze. The installer is loaded to my documents location at C:\Users\Aaron\Documents. We will use this location in a following step. Below you can see the MSI in our documents location.

4) Start the run command, type cmd, press enter.
5) With cmd open, type 'cd Documents', to enter the directory in which our MSI package is located.
6) Type: msiexec /a MemoryzeSetup3.0.msi /qb TARGETDIR=path to memorize folder in our usb' = 'msiexec /a MemoryzeSetup3.0.msi /qb TARGETDIR=E:\Memoryze'.
7) Now you have all the scripts and bat files that come with Memoryze for both 32 and 64 bit systems installed on your usb drive. Just double click on your x86 folder and you will see these are the scripts for a 32 bit operating system.

8) You can now plug this drive into your target system.
9) While plugged in, open cmd with admin privileges, navigate to were your x86 folder is, since we are imaging a 32 bit system.
10) In cmd, simply type: 'start MemoryDD.bat' and memoryze will now start to image the systems RAM, and automatically send it to the 'Audits' folder, that is automatically created under x86.
11) As you can see, our image of RAM is a little more than 3GB's, which is much less than what our physical RAM size equates to, which is 4GB.

12) You can now take this image, and analyze it in Mandiants "Redline".  The image you create with Memoryze is intended to be analyzed with Redline, but i'm sure there are other forensic tools out there that can recognize this .img format. Not to mention, there are other image formats that Redline can recognize when analyzing a memory dump for potential malicious activity, and also a way to tailor some of the redline bat scripts to only collect certain partitions of memory. But all that falls under the category of analysis. This is just a how to in acquisitions.