Memory CTF with Volatility Part 1

By Guy Nguyen-Phuoc on December 2, 2021

Introduction

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 (a banking worm malware) Capture The Flag (CTF) provided by the Volatility Foundation.

Fileless Malware

Memory can be regarded into two categories, primary and secondary. Primary memory is volatile meaning it does not retain any information after a device powers down. The most known primary memory device is the random access memory (RAM). Secondary memory references to memory devices that remain information without the need of constant power. Devices such as hard disk drives (HDD) come to mind. Fileless malware takes advantage of the properties of primary memory and conducts their operations within them, thus they are fileless as they are not written to any secondary memory device. Fileless malware uses tactics such as Command and Scripting Interpreter (T1059) [4] through the use of powershell, python, unix shell and visual basic to achieve this. Traditional methods of digital forensics would find it difficult with assessing this type of malware; making tools like Volatility all the more important.

Installation

Initial analysis

To begin our analysis, enter: volatility -f cridex.vmem imageinfo. Imageinfo will provide us with some preliminary information and meta-data. The image below presents some of the information you can glem off of this simple command. Information such as, PAE type, number of processors, operating system (OS), etc.

volatility teriminal output of imageinfo

 
Here we can see that the memory dump comes from a Windows XP system. We can use the profiles command to select that type of OS while continuing the investigation by typing:
“–profile=WinXPSP2x86” in all subsequent commands. 

You can find the full list of profiles by entering the following command:
“python vol.py –info”

We can now begin to analyze the memory dump.

PSTREE/PSLIST

We will start by looking at the pslist (pstree on unix systems) or the current running processes of the OS. Enter in the following command:
“volatility -f cridex.vmem –profile=WinXPSP2x86 pslist”

You should see something familiar in the image below.

volatility teriminal output of pslist

 
Read more about some of the standard Windows processes here:
https://book.hacktricks.xyz/forensics/basic-forensic-methodology/windows-forensics/windows-processes

From here we can see an odd process “reader_sl.exe”, its Parent Process Identification Number (PPID) matches that of the PID 1484 of the explorer.exe process. Before we analyze this process further check to see if there are any hidden processes with the “psxview” command. Image below highlights the command in use.

volatility teriminal output of psview

 
Does not seem to be any “False” flags in the “pslist” or the “psscan” columns so we can rule out any hidden processes and move on to investigate the “reader_sl.exe” process.

connscan, netscan and sockets

To check for any open connections or sockets we can run a few commands. Connscan will provide us with TCP connections. Sockets will showcase a list of open sockets. Netscan does both but will only work for Vista and later editions.

The connscan results:

volatility teriminal output of psview

 
The socket results:

volatility teriminal output of sockets

 
At a quick glance we can see an open connection tied to the 1484 PID process (explorer.exe). Two IP addresses: 41.168.5.140 and 125.19.103.198 over the 8080 port.

Conclusion

We can clearly see information that is highly valuable to an analyst. Information such as the network connections is possible due to the unique insights memory forensics allows with data that would solely exist in system memory. This concludes part 1 of the CTF article.

References

[1] Case A, Richard GG III (2017) Memory forensics: the path forward. Digit Investig 20:23–33

[2] Mcafee, “What Is Fileless Malware,” Octo. 15, 2018. https://www.mcafee.com/enterprise/en-us/security-awareness/ransomware/what-is-fileless-malware.html

[3] GeeksforGeeks, “Difference between Primary and Secondary Memory,” April 7, 2020. https://www.geeksforgeeks.org/difference-between-primary-and-secondary-memory/

[4] MITRE, ATT&CK, “Command and Scripting Interpreter,” Sept. 2021. https://attack.mitre.org/techniques/T1059/

[5] Github, “Volatility Installation,” Sep. 28, 2016. https://github.com/volatilityfoundation/volatility/wiki/Installation

[6] SpringerOpen, “An emerging threat Fileless malware: a survey and research challenges,” Jan. 14, 2020. https://cybersecurity.springeropen.com/articles/10.1186/s42400-019-0043-x

[7] DIGITALGUARDIAN, “What Are Memory Forensics? A definition of Memory Forensics,” Sept. 29, 2020. https://digitalguardian.com/blog/what-are-memory-forensics-definition-memory-forensics

[8] SANS, “Techniques and Tools for Recovering and Analyzing Data from Volatile Memory,” March 26, 2009. https://sansorg.egnyte.com/dl/S2wfxDfQS3/

[9] P4N4Rd1, “First steps to volatile memory analysis,” Jan. 13, 2019. https://medium.com/@zemelusa/first-steps-to-volatile-memory-analysis-dcbd4d2d56a1

[10] HackTricks, “Windows Processes,” Sept. 2021. https://book.hacktricks.xyz/forensics/basic-forensic-methodology/windows-forensics/windows-processes

[11] TRENDMICRO, “CRIDEX,” Jan. 26, 2016. https://www.trendmicro.com/vinfo/us/threat-encyclopedia/malware/cridex

[12] TurgenSec Community, “Create a .raw memory dump with Volatility,” July 23, 2020. https://community.turgensec.com/create-a-raw-memory-dump-with-volatility/