(In-depth Memory Analysis) (Part-2)
Part 1 : Process Injection
Part 2 : Rootkit Analysis
This is the part-2 of the analysis where we will be analyzing the Rootkit portion of the malware. We have analyzed and identified Process Injection in the part-1.
PART 2 — Rootkit
Now, let us focus on the module (C:\windows\system32\str.sys) cue that we got earlier. As I mentioned earlier, I could not see this module in the modules & modscan plugins. I could not see this module in recently unloaded modules as well. So, we do not get any idea about this module in a straightforward way, hence, we need to check its presence indirectly.
While I was looking for the presence of the str.sys module, I made a note of one strange entry in the modules output. This weirdly named driver,0004A2A was loaded in the kernel memory.
This is a good time to check if any hooks are present in the kernel memory. Let us start with SSDT auditing for hooks. Look at the following snapshot for the same.
Cool, we have discovered the malicious hooks in the SSDT and that too by that strange looking module that we have seen in the modules output.
Couple of things to notice in this output, first is pretty obvious — the hooks. There are system calls related to Registry, Process, Threads, System Information are hooked to the malicious module 0004A2A. The second observation is interesting one — you can notice that there are 3 entries (marked in florescent green) for SSDT[0]. Generally, in a clean system, there would be only one entry for SSDT[0]. This gives us an idea the technique used to patch SSDT. This is “table duplication” technique.
Table duplication is a technique where rootkit creates duplicate copies of SSDT with patched system functions, leaving original SSDT intact, and make all or some threads pointing to this newly created SSDT. So, the when a thread/process makes a systemcall, it refers the patched SSDT for translation of the systemcall address and it will be redirected to the rootkit. The original SSDT still be pointing in to the correct address but it is never referred by the patched threads. You can see in the following snapshot that the hooked function (NtEnumerateValueKey) still pointing correctly in the ntoskrnl.exe in the original SSDT and the same function is pointing in to the rootkit in duplicate SSDTs.
Now, Rootkit has created the duplicated patched SSDTs but now the threads need to be patched in order to make them refer these patched table.
Let us analyse the registered callbacks to investigate further. Look at the screenshot below.
You can see the callback “PsSetCreateThreadNotifyRoutine” is registered with the malicious module. This is the callback that patches the threads. In 32-bit systems, each thread has a filed named _ETHREAD.Tcb.ServiceTable and this table points at the SSDT that needs to be used for systemcall translation. So, by replacing this value, the threads can be made point to hooked SSDT and that is exactly what this callback function does. Let us examine some patched threads. Please have a look at the following two screenshots of the patched threads where their servicetable entry is hooked to the poisoned SSDT.
BE2 infects the machines with a rootkit that patches the SSDT. Moreover, it injects the code(dll) in to the process svchost.exe (PID 856 in this case). We can jump on to the reversing the dll & module after dumping it to know further. But I leave that to you guys.
I hope you find this article insightful. Thanks for reading.
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
A CISA, CISSP professional with 14+ yrs of experience in various domains of Cyber Security. Kirtar currently works as a Cyber Threat Specialist at a service provider in Australia that works with major banks. Previously he’s worked at Sydney Airport, Qualys and Infosys, and within the UK and Norway. This experience has allowed Kirtar to work with clients all across the world.
Aside from this, Kirtar has published multiple articles LinkedIn and Securityaffairs.co. He specializes in DFIR, Threat Hunting, CTI, IR, SIEM, Splunk, DevSecOps, and MITRE’s ATT&CK Framework.
References
