The semester has come to an end, along with my research on Virtual RAM disks. All in all, I would say the project was a success and certainly a great learning experience.

As I mentioned in my last post, the main goal of this project was to examine and recreate ways in which malicious users may make use of RAM disks in order to cover their tracks or conceal the fact that they were present on a machine at all. Previously I had mounted a RAM disk, dropped some files on it, and then dismounted the disk in order to search for remnants of files in RAM after the disk was gone. As I said, the entire structure of the disk and the files located within are indeed deleted after dismounting the disk. For this portion of the research, however, I took a closer look at how malware interacts with a system when it is being run solely from a RAM disk.

Forensic Artifacts

In order to recreate a scenario in which an executable (whether malicious or not) was run from a RAM disk, I wrote a short Python script to use a CLI RAM disk mounting software to accomplish the following:

• Mount a virtual disk
• Download a standalone executable to the disk
• Run the executable
• Dismount the disk

 After running this test scenario, it became obvious that running an executable from RAM still left behind the same forensic artifacts that you would normally see when an executable is run on the system. For example, I was able to prove that the executable was run by examining the Application Compatibility Cache (Shim Cache) using Mandiant's Shim Cache Parser.

As you can see below, an entry for autoruns.exe (the executable I used for the test) is present in the Shim Cache Parser output, including the path of the RAM disk it was run from:

After finding a way to prove that an executable was run from a RAM disk, I chose a piece of malware to run the same script on, to see if it acted similarly to the standalone executable.

After running the malware from the virtual disk and the local system and comparing the artifacts left behind, it became obvious that it runs in virtually the same exact way and leaved behind the same artifacts regardless of the location of the original executable. This is mostly due to the fact that the first thing the malware does is delete itself and recreate a new executable in a temporary directory, as seen below in the ouput of Noriben, a malware analysis tool:

Conclusions

After a semester long of research, I was able to ultimately determine that virtual RAM disks operate extremely similarly to other mountable media such as USB drives. Consequently, virtual RAM disks should not pose much of a challenge to forensic investigators. Executables run from the RAM disk operate nearly identically to those that are run locally, and leave the same artifacts for proving they were executed. Additionally, malicious software that was run from RAM still leaves artifacts on the operating system level. The only real obstacle that RAM disks introduce is the fact that when a disk is dismounted, all files that were on the disk are completely deleted and unrecoverable.

Overall this was a great project to work on and I enjoyed learning about the structure and operations of RAM disk mounting software, as well as recreating ways in which a forensic examiner might handle a case involving a RAM disk.

Research Update

Welcome back to Virtual RAM Disk Forensics! It’s been a while since my last post, and since then I’ve obtained tons of information about RAM disks and how they can be analyzed forensically. I’ve managed to locate mounted disks within RAM, view and interpret their disk structure, find file locations, and also provide some examples of how RAM disks might be used in an anti-forensic manner. Keep reading for an in-depth description of my research.

RAM Disk Structure

Using DumpIt, a memory dumping tool, I was able to obtain an image of RAM while a disk was mounted. Initially, I began to analyze the RAM image with volatility, a memory analysis tool, but I actually found that due to the fact that there was an actual disk mounted in RAM, it was more beneficial for me to analyze the image manually.

In order to view the RAM image, I used a Hex editing tool called HxD. After loading the image into HxD and doing some searching, I was able to locate the actual boot block of the disk I mounted (at offset 0x19DAD000), as seen below.

I knew that this was the boot block for the disk I mounted because the size of the disk can be determined through the hexadecimal values in the boot block. At offset 0x20, a 4 byte entry denoting the size of the volume can be found, which in this case is 0x00063FF0. This is the size of the disk in blocks. Offset 0x0B has a two byte entry outlining the bytes per block, which in this case is 0x0200, or 512. Multiplying the number of blocks by the bytes per block, gives you 209MB. For this example, I mounted a 200 MB disk, which must have about 9MB of overhead.

The next step for analyzing the RAM image was to find the root directory. In FAT, every file and directory on the drive has a root directory entry, which tells the file system information about that file such as its MAC times, offset on the disk, and more. Consequently, being able to locate the root directory would be quite valuable to forensic investigators.

In a normal FAT disk, the root directory would be located directly after the File Allocation Table(s) (FATs), which come directly after the boot block. Information on the number of FATs and the size of the FATs can also be found in the boot block of the disk. After finding this information and doing some math, I determined that the root directory should be located at offset 0x19DB9A00. Unfortunately, when I navigated to this offset within the RAM image, there were no root directory entries to be found, as seen below.

In order to find the root directory, I needed to know the exact hexadecimal characters that would make up an entry for a specific file. As such, I decided to format a thumb drive as FAT, create some test files on it, and analyze the root directory entries of those files. Next, using a tool called TimeStomp, I was able to create another RAM Disk, drop files on it, and manipulate their metadata to be identical to the test files I created. Using this strategy, I was able to locate the root directory entries in the RAM image.

The boot block of this disk was located at offset 0x18FDD000, and the root directory entries I found were located at offset 0x17927FF0, as seen below. Note that this offset is before the offset of the boot block, proving that the disk is certainly not contiguous within RAM.

One of the located root directory entries is highlighted, which in this case is for a file I created called TextFile1.txt.

Analyzing the metadata located within this root directory entry revealed that the file was created on 2/7/2014, which matches the creation date of the file when viewed from Windows Explorer, as seen below. If you would like to read more information about the metadata located within root directory entries, as well as how to convert them into human-readable formats, a great tutorial can be found here.

I am still researching and trying to find the link between the boot block and the root directory, but so far have been unable to determine how the disk is structured within RAM.

Forensics

As an anti-forensic technique, it is possible that someone wishing to conduct illegal activity may store or use files on a RAM disk, and then when finished, dismount the disk in hopes that the files would be gone. Consequently, I conducted another experiment in which I mounted a disk, dropped files on it, and then dismounted the disk.

Searching through the RAM image after the disk was dismounted showed no sign of a FAT boot block, or root directory entries. However, many instances of the files and folder structure on the disk that I created still showed up, as seen below.

The next step in my research is to run an executable from the RAM disk, and attempt to determine whether or not there is any proof that the executable was run after the disk is dismounted, or even after the computer is restarted. I have written a simple batch script to mount a disk, drop an executable on it, and run the executable, using the CLI RAM Disk tool called PrimoRamdisk, but have been unable to get the executable to run properly thus far.

In the next weeks, I am hoping to wrap up my research by possibly finding the link between the root directory and the boot block, and determining whether or not it can be proved that an executable was run from a virtual disk. Come back in a few weeks for a summation of my entire project!