Memory CTF with Volatility Part 2
By Guy Nguyen-Phuoc on December 2, 2021
Memory analysis or Memory forensics is the process of analyzing volatile data from computer memory dumps. With the advent of “fileless” malware, it is becoming increasingly more difficult to conduct digital forensics analysis. Memory analysis not only helps solve this situation but also provides unique insights in the runtime of the system’s activity: open network connections, recently executed commands, and the ability to see any decrypted malicious file. In this article we will go over a memory analysis tool called Volatility and begin an initial analysis of the Cridex malware provided by the Volatility Foundation. This is part 2 of the CTF memory series.
Cmdscan, consoles and cmdline
Last time we left off with some network scans, checking opening ports and previous connections. After some time, we found an open connection established on the image. This time we will look at command line histories.
Begin by entering in the command: “volatility -f cridex.vmem –profile=WinXPSP2x86 cmdline”. The image below is a snippet of the full result.
From the above snippet we can see that “Reader_sl.exe” is related to Adobe Reader 9.0 and we know that this process “1640” was opened by “explorer.exe” and that process was running a connection towards an external IP address.
Some background on the cmdline plugin. The cmdline plugin displays the process command-line arguments with the full paths. Two other commands: “consoles” and “cmdscan” scan the history of commands used from “_CONSOLE_INFORMATION” AND “_COMMAND_HISTORY” respectively.
Extracting the PID
We can analyze the 1640 PID with procdump and memdump by specifying the “-p” flag and outputting the dump into a directory with “–dump-dir” flag.
Enter the following to extract the information from procdump:
“volatility -f cridex.vmem –profile=WinXPSP2x86 procdump -p 1640 –dump-dir.”
Enter the following to extract the information from memdump:
“volatility -f cridex.vmem –profile=WinXPSP2x86 memdump -p 1640 –dump-dir .”
The results are an executable (executable.1640.exe) of “Reader_sl.exe” and a memory dump of the 1640 process labeled “1640.dmp”, the addressable memory of the process.
Analyzing the Executable
We can now do simple analysis on these files by using the “strings” command. First we will examine the known IP address that has an open connection: “18.104.22.168”.
Strings is a command that prints any ascii based characters within a file. We then limit the search for “22.214.171.124” with the grep command, flag “F” is so every line is a Fixed string pattern, separated by newlines, and flag “i” is to ignore case. The “C” flag shows five lines above a match and five lines below a match.
What is interesting about this result is that the “Reader_sl.exe” executable is making a POST request towards the suspicious IP address.
Analyzing the memory dump
Entering the command: “strings 1640.dmp | less” gives us the ascii characters for the 1640 memory dump, with the less command showing us a snippet of the results and waits for further inputs before showing more.
A selection of the results show in the image below.
A series of domain names all themed around banks and the financial sector. Judging from the data we have aggregated so far we can safely say that this executable is a malware or malicious file.
Using online dynamic analysis
We can use dynamic analysis online tools like VirusTotal or Hybrid Analysis to check this malware to see if it has been spotted in the wild before.
At Least 29 anti viruses deem this as malware, and it was recently scanned 7 days ago. Meaning this same malware is still circulating. And with that, this is the final nail in the coffin and with the results from VirusTotal we can safely conclude, without a doubt, it is a malicious file. This concludes part 2 and in part 3 we will go over prevention methods and use all the data we gathered to create Incidents of Compromise (IOC) to filter out any future variants of this malware.
This concludes part 2 of the CTF article.