(In-depth Memory Analysis) (Part-1)
Part 1 : Process Injection
Part 2 : Rootkit Analysis
Memory forensics is no different than any other investigation where “getting a first hit” is the most important thing. We may need to go through and analyse a lot of data patiently before we get our first hit. Once we get the first hit, we can pivot on that hit and substantiate the investigation further.
Today, we are going to revisit the long forgotten master piece of Kernel Rootkit — BlackEnergy 2 (BE2) which was infamous in the year of 2010. We could not see any detailed technical information today on the internet apart form DellSecureWorks’ original blog back in 2010 and scattered discussions on a few forums. Therefore, I have decided to take the BE2 infected memory image and put forth the detailed memory analysis of this “class act” for the readers for their knowledge and thrill.
So, lets get in to it.
Typically, we start the investigation by looking at the processes and analyzing the them from different lenses using pslist,psscan,pstree, and psxview and look for any process related abnormalities. Having said that,
knowing normal is equally important because — your ability to catch abnormal is as good as your knowledge of normal.
Let us look at the outputs of pslist & pstree and analyse if we see any suspicious process.
If we look at the output of pstree, we can see the process with a weird name 1e0f1b69…exe (PID 476) and it is spawning the cmd.exe (PID 1572). That looks suspicious !! Also note that, the parent process of PID476 is PID 1724 which is the “explorer”.
If we look at the output of pslist, we can see that these processes are already exited. If you further notice that these processes do not have any active threads or handles present in the memory. Normally, pslist does not list out the processes that are exited. However, in this case, these processes seem to be dependent processes of some active processes (that have open handles in these processes) and hence they are still not removed from the doubly linked list of the active processes.
The outputs from psscan and psxview have not reported anything unusual activity apart from the processes that we already discussed above.
The next logical thing to look at the fullpath & CommandLines of these processes and see if these processes have anything suspicious there to substantiate. Please look at the following snapshots of dlllist output for both of the suspicious processes. It says that “Unable to read PEB” that means that as these processes are already exited, the PEB structure of _EPROCESS data- structure is destroyed and no longer available in the memory to read.
Let us try to grab the data from UserAssist key and see if we get any information about this binary (1e0f1b….exe)
We got the fullpath to the binary and we could see the number of counts of running this binary. However, we have not got any concrete details to say convincingly that this process is malicious.
Apparently, this process looks suspicious based on the name, full-path and child process (cmd.exe); however, having said that, this process does not have any active threads or handles in the memory. Also, note that this process is already terminated. No other process looks conspicuously suspicious based on the output of the process analysis.
Let us keep this information in mind and try to explore other avenues to identify suspicious artifcats and see if any of those relate back to this abnormality. Let’s try to see any suspicious dlls have been loaded by any of the processes. Let’s take a look at the ldrmodules.
Aha !! looks like we have got our first hit. The process svchost.exe (PID 856) has loaded the dll(msxml3r.dll) that seems to be unlinked in all three “ldr module lists”. This is the sign of dll hiding where the dll is unlinked from the doubly linked lists in PEB. This dll is definitely suspicious and we should pivot on this and the process in which it has been loaded. So, we have now 2 suspects — PID 856 (svchost.exe) and msxml3r.dll.
I thought to see if this suspicious dll (msxml3r.dll) has been loaded anywhere else in the memory. I could not find any other process where this dll was loaded.
Dlllist plugin for process 856 would not even show this dll as it has been unlinked(or unloaded) from the PEB of the process. However, it will give us the idea about the command line passed along with the process.
So, let us examine process 856 further and let’s have a look at the file objects it touches. Look at the snapshot below.
It has a handle to the module named str.sys that is residing under system32 directory. Following this output, I did some cursory checks to see if this driver is loaded, hidden or recently unloaded. However, I did not see that this driver is loaded or recently unloaded in my cursory checks. So, we need to investigate it further how this driver is used and if it is still in a memory.
Before we substantiate driver/module, lets focus on the process and the dll at hand. It looks like that the dll has been injected in this process (PID 856). Let us look for the sign of the injection in the process and dump any suspicious section if the memory of this process using malfind.
let us examine this memory section as it looks like an injected code.
It is a PE (dll) file. We can figure out the same by looking at the signature MZ in the starting of the code section. Hence, it is confirmed that this dll is injected in the memory of this process (PID 856).
Simple Strings shows many suspicious strings. Most of the API functions that are reported in the previously mentioned Dell’s report (as exports by main.dll) can be mapped here.Please refer the screenshots below.
Note: Please note that not all the functioned mentioned in the reports could be found in the output
Hence, we can infer that this is the main.dll that is referred in the Dell’s report. (though this dll is hidden in the memory — both dlllist,ldrmodules do not show) — this must be reflective dll injection that is in memory injection.
Moreover, we can see str.sys in the strings output of the dumped process.
Looking up in to VirusTotal for the hash of the process dump, multiple detection are found.
Strangely, the suspicious and unlinked dll that we found earlier, msxml3r.dll, does not seem to be malicious. I could not find any match in VirusTotal for this dll. Doing some googling around this, I could find that this is a legit binary in windows and used for XML services. Moreover, there is a possibility that this dll was loaded once and its memory section is not overwritten hence this could be false positive.
That’s it for Part-1, folks! We will have a look at the Rootkit in the second part of this article. I am completing this article here to keep this article to a readable length. Lots of goodies in the second part (Part-2) of the article.
Please share your views, feedback and comments with me. My contact details are given below.
That’s it for now, folks !! Happy hunting, fellas !!
Author: Kirtar Oza
Twitter : @Krishna (kirtar_oza)
LinkedIn: https://www.linkedin.com/in/kirtaroza/
email: kirtar.oza@gmail.com
