Ransomware Memory Analysis With Volatility
Description: Performing memory analysis on a Windows machine infected with ransomware Blue Team Labs Online Memory Analysis Ransomware - https://blueteamlabs.online/home/challenge/1
In this challenge, we’re given a memory dump and told that the computer the memory dump was captured from, is the victim of a ransomware attack.
There’s 7 tasks in this challenge:
- Run vol.py -f infected.vmem --profile=Win7SP1x86 psscanthat will list all processes. What is the name of the suspicious process
- What is the parent process ID for the suspicious process?
- What is the initial malicious executable that created this process?
- If you drill down on the suspicious PID (vol.py -f infected.vmem –profile=Win7SP1x86 psscan | grep (PIDhere)), find the process used to delete files
- Find the path where the malicious file was first executed
- Can you identify what ransomware it is? (Do your research!)
- What is the filename for the file with the ransomware public key that was used to encrypt the private key? (.eky extension)
I would usually say to begin this by running volatility’s imageinfo plugin to determine the profile we’ll be using, but the first task gives that away, Win7SP1x86.
So we run:
vol.py -f infected.vmem --profile=Win7SP1x86 psscan
which outputs:

There’s several normal looking processes running, but there are also a few that stand out, including:
- @WanaDecryptor- PID: 3968
- or4qtckT.exe- PID: 2732
The PID of @WanaDecryptor is 3968 and its Parent Process ID (PPID) is 2732, meaning or4qtckT.exe started @WanaDecryptor, but the PPID of or4qtckT.exe is 1456 which belongs to explorer.exe, this is likely because whoever ran the or4qtckT.exe executable double-clicked it from Windows File Explorer.
Here is a better visualization of this which was outputted by using the pstree plugin:

So now we know the names of 2 suspicious processes:
- @WanaDecryptor
- or4qtckT.exe
But the answer that BTLO is looking for is @WanaDecryptor!
And the PPID of the suspicious process (@WanaDecryptor) is 2732, and the initial malicious executable which created the suspicious process (@WanaDecryptor) is or4qtckT.exe, which can be seen by using the pstree plugin:

Now we’re asked to look for any other processes that has a PPID that belongs to the or4qtckT.exe process. We can do this by running:
vol.py -f infected.vmem --profile=Win7SP1x86 psscan | grep 2732
Which outputs:

- The first column of 4-digit numbers is the PID while the second column of 4-digit numbers is the PPID
And we have a new suspicious process! taskdl.exe which was also started by or4qtckT.exe! taskdl.exe was the process which was responsible for deleting files on the victim’s system!
For the next task, we’re asked to find the path where the malicious file was first executed. A hint here is within the question, first executed, meaning the file that started this entire ransomware process, so we’re looking for the parent process of @WanaDecryptor, which is or4qtckT.exe.
My first thought was to scan for past executed commands via cmdline:
vol.py -f infected.vmem --profile=Win7SP1x86 cmdline

And now we have the full path of where the executable was located: C:\Users\hacker\Desktop\or4qtckT.exe!
Now we have to identify what ransomware variant this is. Judging by the executable named @WanaDecryptor@.exe, I’m going to take a wild guess that this is the WannaCry ransomware variant, but I want to be 100% sure, so we can extract the ransomware executable from memory and upload it to Virus Total to confirm our theory:
vol.py -f infected.vmem --profile=Win7SP1x86 procdump -p 3968 --dump-dir Dumped-Executables

You could’ve also extracted the or4qtckT.exe (PID 2732) executable and uploaded it to VirusTotal to confirm the ransomware variant:

Now onto the last task!
We have to identify the filename of the public key that was used to encrypt the private key, and we’re given the hint that this file will have a .eky extension!
This can be solved by using the memdump plugin to dump the region of memory of the running malicious process or4qtckT.exe (PID 2732):
vol.py -f infected.vmem --profile=Win7SP1x86 memdump -p 2732 --dump-dir Dumped-MemRegions
- NOTE: I believe that the reason we wouldn’t be able to use the same method of searching through the strings of the executables we extracted earlier is because any mention of the filename string in the executable is likely to be encrypted. But if we dump the region of memory where the executable was already running, it’s likely that the filename string is going to be decrypted in memory which we can then dump & read.
Then we can use the strings utility to look for anything that contains the .eky file extension:
strings 2732.dmp | grep .eky

Our filename is: 00000000.eky!
- You can also acquire the filename by dumping the explorer.exe(PID: 1456) process. I believe this is because the00000000.ekyfile was being interacted with, so its filename was stored in the memory of theexplorer.exeprocess for easy future access.