Dumping DarkComet config out of memory using volatility
February 24, 2014 Leave a comment
Ian over at TekDefense has a great post up on using volatility to analyze a computer that has been compromised with the DarkComet RAT. While reading through his post I noticed a section where he was using strings to find the config of the DarkComet RAT. Since the config was all in plain text I figured I could find it using volatility and volshell and maybe even write a plugin to dump the config.
I used the memory sample that Ian has linked to from the post listed above to use for my initial testing. I fired up the VM that I had from the volatility training I took in Reston, VA in 2013 and did the following:
First I need to figure out what OS the memory image was taken under, imageinfo to the rescue:
In Ian’s post he provided a yara rule that looks for the mutex in darkcomet. First lets run yarascan with that rule and see what we get:
Hmm looks like Process runddl32.exe Pid 1524 might be the culprit. Juts for giggles lets do a quick handles and look for any mutants that contain DC_MUTEX in them.
The pid matches. Now lets open up volshell, set the current context to Pid 1524
and then print out the bytes as a canonical hexdump from the address where we had the yara hit.
Oohh look we see the mutex and a lot of the same config options as referenced in Ian’s post, it looks like the entire config is stored in plain text in memory.
In Ian’s post there is also the string #BEGIN DARKCOMET DATA — I wonder if that can be found using volshell as well. Lets print the bytes again but this time lets move back 21 bytes from the address where we have the yara hit for the darkcomet mutex.
db(0x012a539 – 0x21, length=512)
Yup sure enough its there. Now I begin to think this is a great case for a volatility plugin to dump the config. Brian Baskin has a great post about how easy it is to create a volatility plugin that I used to help guide me through this process. Below is what I came up with:
In my testing I decided to look for the #BEGIN DARKCOMET and #EOF DARKCOMET instead of the mutex. The reason being I have seen a few dark comet instances with DCMIN_MUTEX as the mutex. Take a look at this search query over at totalhash to find some samples that have the DCMIN_Mutex.
Also, in my config due to the way I decided to try and dump the config I have had to build in a dumper that will dump 400 bytes after the start address. If anyone has any suggestions or improvements to the code I would be more than happy to incorporate them :) Below is the output of the config dumper using the memory image provided by Ian.
Thankfully, DarkComet stores the config in plain text and made this plugin quite easy to write. If you haven’t tried out volatility you really should it is amazing what you can do with it.
I have put the plugin up on github so feel free to grab it and test it. Let me know what you think and as always happy hunting!