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):