Looking at LockerGoga Ransomware in Memory

This is a repost from a year ago, but since migrating to Medium, this is still a relevant exercise when analyzing malware in memory.

Over the past couple of weeks, the LockerGoga ransomware has been targeting many victims. In this post, I will take you through how one could analyze the memory-dump of a machine infected with ransomware.

We start with the setup of a basic VM with Windows 7, enough memory and disk-space to circumvent any particular evasion techniques used in certain malware families to detect if it’s detonated in a VM. All tools are installed and a snapshot is made.

First, we run the malware as a test to see if it was properly working. Immediately we noticed that the machine became slow, although plenty of memory and cores:

It turned out that the ransomware was using full CPU power. Once finished and the ransom-note was visible, attempting to create a memory-dump was not working. Many functions like downloading tools, copy/paste data, etc all did not work. Time for a different strategy. Back to my base-image by reverting the snapshot. Before running the malware, started up the memory-dump tool to be ready, setup Process Explorer and next detonate the malware. In my first run, the ransomware took an average of 6–7 minutes to encrypt most of my decoy files on the machine. In the second run, after 4 minutes, we started to dump the memory and once the dump was done, stop the processes of the ransomware using Process Explorer. Bingo, we have a memory-dump file we can use for analysis.

The first step in Volatility is to get the imageinfo
command: vol.py -f [filename] imageinfo

The output in our case is the Win7SP1x64 profile, which we will use in the rest of our Volatility commands.

What is the process running on our VM and which ones could be suspicious? Knowing that we ran Process Explorer before detonating the malware, we should be able to identify suspicious process pretty easy.
command: vol.py -f LockerGmemdump.mem — profile=Win7SP1x64 pslist

In the output of the command, we identify the process-name “zzbdrimp8247.e” with a PID of 3136. Also down the list, we see similar process-names, with different PIDs but the same parent PID 3136.

If you are working in Incident Response, you would run a few other commands to see if the process had network communications. The next step would be to dump the process mentioned above:

command: vol.py -f LockerGmemdump.mem — profile=Win7SP1x64 procdump -p 3136 -D Dump2/

Next, the output file would be uploaded to VirusTotal for example for a verdict. Since we already know this is a LockerGoga sample, I decided to test one of my Yara-rules I created for this particular family:

Confirmed! (and my Yara skills seem not too bad ;) Rule can be downloaded from this location if you want to use it: LINK

The Yara rule itself could also be used to scan the full memory-dump for artifacts of this ransomware family:
command: vol.py -f LockerGmemdump.mem — profile=Win7SP1x64 yarascan — yara-file=RANSOM-LockerGoga.yar

The rule hit several sections, an example below where we again see the PID of 3992.

We want to dig a little deeper and look at some of the ways the ransomware is running. We already dumped the process list earlier, but how are the sub-processes running? This can be done running the following:
command: vol.py -f LockerGmemdump.mem — profile=Win7SP1x64 pstree

This will result in a listing of processes and subprocesses of the system. To make it a bit better, one can visualize it by using the following command:

command: vol.py -f LockerGmemdump.mem — profile=Win7SP1x64 pstree — output=dot — output-file=lockerg.dot

The output of the pstree command will be visualized and written to a .dot file that can be opened by using GraphViz:

In my case, I used the following command to transform the .dot file to a png file so it can be opened with multiple viewers:

command: dot -Tpng lockerg.dot -o LockerG.png

Zooming in on the processes, we discover our ransomware executable again:

Note the number of handles that each of the processes is opening, hence the CPU usage going to 100 percent.

Any other interesting artifacts? There are a lot of plugins available to dig deeper. One of them I often like to use when analyzing malware-memory-dumps is using the ‘handles’ plugin and look for the file and mutant artifacts.

command: vol.py -f LockerGmemdump.mem — profile=Win7SP1x64 handles -p 3136 -t File,Mutant

In the output of the command, we see a mutant with the name “MX-zzbdrimp”. Next, you could use that value as an input for the yarascan plugin to discover memory areas where this mutant is used:

command: vol.py -f LockerGmemdump.mem — profile=Win7SP1x64 yarascan -Y “MX-zzbdrimp”

In the output we can read extensions, that might be the ones that the ransomware attempts to encrypt (confirmed by static analysis). Also, we notice switches like -l, -s, and -i. By static analysis, it is confirmed that these switches are used for different purposes. The -l is for logging-function, the -s to run it as a slave (where -m is for master), and the -i switch indicates mapped memory. Plenty of static analysis articles are being posted on this, just use your preferred search engine.

Happy Memory Hunting!

Saved by His Grace • Visionary Threat Research leader•synth lover •opinions are my own• Speaker•