Shulou(Shulou.com)05/31 Report--

In this issue, the editor will bring you how to understand the Volatility-based memory analysis technology Part 1. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

Memory forensics (sometimes called memory analysis) refers to the analysis of volatile data in computer memory dumps. Information security professionals can use in-memory forensics to investigate and identify attacks or malicious acts that do not leave a trace in the hard drive data.

Through in-memory forensics, security personnel can learn about various system activities at run time, such as open network connections or recently executed commands and processes.

Before a program can run on a computer, it needs to be loaded into memory, which makes memory forensics very important-which means that all programs or data created, checked, or deleted will be saved to RAM. This includes images, all Web browsing activities, encryption keys, network connections, or injected code snippets. In many cases, some evidence can only be found in RAM, such as open network connections that existed during a crash. Because attackers can develop malware that resides only in memory and does not land on the hard disk, it is almost invisible to standard computer forensics methods. This makes memory forensics tools more and more important.

Volatility is an advanced memory forensics framework. It provides investigators with many automatic tools, and people can use its advanced memory analysis technology to reveal malicious activity on the host. It is important to point out that the framework is implemented in python and is open source. The download address of the framework is https://github.com/volatilityfoundation/volatility, and the related document address is https://github.com/volatilityfoundation/volatility/wiki/Command-Reference-Mal.

We will take the Coreflood Trojan as an example to introduce the relevant memory forensics methods.

Coreflood is a Trojan horse and botnet created by a group of Russian hackers and released in 2010. FBI has added "approximately 17 state or local government agencies, including 1 police station; 3 airports; 2 defense contractors; 5 banks or financial institutions; approximately 30 colleges or universities; approximately 20 hospitals or medical companies; and hundreds of enterprises" [1] to the list of infected systems. As of May 2011. It has infected more than 2.3 million computers around the world; so far, it remains a huge threat. Wikipedia

For the sample software, you can download it from the following address (.vmem file):

Https://github.com/mgoffin/malwarecookbook/blob/master/16/6/coreflood.vmem.zip

The goal of this article series is to use volatility to understand the behavior of this malware and the corresponding memory forensics methods. I will try to discover all the forensics tools about Coreflood to find out what the motive behind this malware is. I hope to learn something new from this forensics analysis and teach you something new!

In order to start the investigation, I want to find out what processes are running on the host. To do this, we can see if there are obviously suspicious processes running with the help of the pslist command.

Windows uses a circular double-linked list _ EPROCESS structure to track all active processes; and this list is located in the kernel. Volatility takes advantage of this fact: first, it looks for a PsActiveProcessHead pointer because it points to the beginning of the kernel's list of _ EPROCESS structures; then Volatility iterates through the list to find all the processes that are running.

All processes running on the host: output of the volatility-f coreflood.exe pslist command

We can see that everything seems to be normal, but there are a few things that have caught our attention. Currently, while the IE browser is running and cmd is running, it seems that the right thing to do is to check outbound connections, as malware may disguise itself as an Internet Explorer browser to hide its own traffic with Internet Explorer C.

In addition, we can also check what cmd is doing over there, which will be discussed later.

One of the easiest operations is to check the outbound connection. If the IE outbound connection does not find anything suspicious, we need to look for signs of malicious activity elsewhere.

Next, we will use the connscan command to check the previously terminated and currently active connections:

"to use the pool label scan feature to find the _ TCPT_OBJECT structure, use the connscan command. The advantage of this is that we can search for evidence not only from active connections, but also from previously terminated connections." -- extracted from the official documentation of Volatility

In fact, this works by scanning physical memory to find a 4-byte signature 0x54455054 ("TCPT"), and then parsing the next 28 bytes as a complete _ TCPT_OBJECT structure.

Output of the volatility-f coreflood.vmem connscan command

Judging from the output above, the host appears to be having normal communication, all of which is created by the pid 2044 process (IEXPLORE.EXE). I checked the location of these IP, they are registered in the name of some big companies, such as Microsoft, AT&T and other companies. Of course, the data on these IP may have changed, because the vmem files currently being examined are a little old, and it is also possible that hackers tampered with the IP address data in order to deceive investigators.

To ensure that there is no malicious communication, we should check that the inbound connection is secure. To do this, we can use the sockscan command, which scans the _ ADDRESS_OBJECT structure in memory. By scanning this memory structure in memory, we can gain an in-depth understanding of previously opened sockets and currently open sockets.

Output of the volatility-f coreflood.vmem sockscan command

As we can see, there are some very strange inbound connections in process pid 2044 (that is, IEXPLORE.EXE). This looks very suspicious, so it's time to take out our memory forensics artifact Volatility and check to see if malware is hidden in the process.

We say that Volatility is a memory forensics artifact because it provides many powerful malware analysis tools.

The first analysis tool we often use is the malfind command. This command can be used to find the injected code in the process memory. It does this by looking for segments of allocated memory (by looking at the VAD tree data structure) and checking them for clues to executable code that is not mapped to any file on disk.

"the VAD node also references some other kernel structures that can be very useful to investigators. Therefore, if the memory area is used for a mapped file, such as a loaded DLL, you can reference the corresponding _ FILE_OBJECT structure and extract the name of the file. This can provide investigators with an alternative way to list the modules loaded by the process, which can then be compared with the modules found by other methods to find evidence of library injection and hidden modules. " -- Science Direct

The way to check whether a piece of memory contains injected code is to check the page permissions of VAD, such as EXECUTE permissions, and so on. If a segment in memory has execute permission and it is not mapped to any executable on disk, it is likely that there is injected code here.

The output of the volatility-f coreflood.vmem malfind command. There seems to be a false positive.

As we can see in the figure above, the output of this command does not seem to bring much really valuable information.

This may be because the malware does not load any explicit PE (Portable executable) code into memory, but only injects some shellcode, or the header of the image is paged. In addition, it is possible that malware clears the PE header from memory by calling VirtualFree on the injected DLL's ImageBase to avoid detection. Of course, it is also possible that this part of the memory is paged or inaccessible for some reason. In any case, we are not sure that there is malicious activity here, because we have not found any definite evidence.

The next command we can use is apihooks.

"it can be used to find IAT, EAT, Inline hook, and several special types of hook. For Inline hook, it can detect CALL and JMP instructions in direct and indirect locations... and calls to unknown code pages in kernel memory." -- Volatility official documentation

To understand what's going on here, we need to take a quick look at IAT and EAT.

When the executable is loaded for the first time, the Windows loader is responsible for reading the PE structure of the file and loading the image of the executable into memory. One step is to load all the dll used by the application and map them to the process address space.

In addition, the executable indicates all the functions needed in each dll. However, because the function address is not static, we must develop a mechanism to allow these variables to be modified so that we do not have to modify all compiled code at run time.

This is done by importing the address table (IAT); IAT is actually the function pointer table that the windows loader fills in when it loads dll.

EAT works in much the same way as IAT, except that it is used by the code base to export functions to an image executable so that programs can import function addresses into IAT from there (I won't go into more details).

Malware can manipulate these two memory structures to make executables call other functions rather than the ones they were supposed to call.

I use the apihooks parameter on IEXPLORE.EXE because based on the output of sockscan, I already suspect that it may have been tampered with.

We will use the apihooks parameter and save the output in a text file

Unbelievable! Internet Explorer has been hooked a dozen times to call the same function.

The above image is excerpted from a text file that saves the output of the apihooks command. In fact, this is just one of a dozen different functions' hook; they all call the same address 0x7ff82a6e.

We can see that in this example, malware "hooks" LoadLibrary in WINHTTP.dll.

LoadLibrary can be used to load the library module into the address space of the process and return a handle that can be used by GetProcAddress to obtain the address of the DLL function. Therefore, LoadLibrary is a very obvious hook object, because we know that many PE will use other dll and import related functions in these libraries.

We need to figure out what the malware is trying to achieve here. To do this, we need to try to dig into the code that the malware is trying to execute. Therefore, we will use Volatility's volshell tool. Volshell is a very powerful tool that can be used to browse the contents of memory. We can jump to various parts of memory, and after that, we can not only view the contents, but also disassemble or read them.

Enter the volshell command and follow the process.

After entering the volshell command, I use cc (

The highlighted text above (from top to bottom) shows us the address that has been hooked, and below it, it highlights the address to which the malware wants our code to jump.

As shown in the figure above, in order to understand the intent of the malware, we need to disassemble the relevant address. To do this, I copy this address as an argument to the volshell command dis (

The final output we get is the maliciously injected code.

We will introduce the role of this malicious code in a later article. Eager readers can also try it on their own.

The above is the editor for you to share the Volatility-based memory analysis technology Part 1 how to understand, if you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.