Within the toolset of the different APT groups, one of the most interesting elements and the one that generally worries the most, are their capabilities in Ring0, generally RootKit/Bootkit type threats that act with the maximum level of privileges.
An example of this type of threats is the RootKit module of ZxShell RAT used by Emissary Panda (APT27), of which there is a relatively recent sample (Uploaded to Virustotal since 2019-09-21 17:59:39) that is also correctly signed, so it can be loaded in the latest version of Windows 10 and is perfectly functional as far as we have been able to check.
A complete analysis of this threat can be found made by the analyst Ori Damari (@0xrepnz) in his blog (https://repnz.github.io/posts/autochk-rootkit-analysis/). After analyzing this threat and describing its capabilities, he has rewritten the source code from a sample of this threat uploaded in 2018 to Virustotal, and published it in GitHub, which greatly facilitates the analysis of newer versions. As he describes in his blog, the capabilities of this Rootkit are basically the following:
- File Redirection – Redirect malicious files to benign files. If you try to call CreateFile() to open a malicious file you’ll get a handle to a benign file.
- Network Connection Hiding – Hide network connections from tools like netstat,proceshacker…
We found interesting to analyze the differences between the 2018 version and the most recent 2019 version in order to try to identify new capabilities or changes in its capabilities. After comparing both samples using the GitHub source code, we have been able to see that most of the functions are identical, except for 5 of them (including the Driver’s entrypoint):
After analyzing the differences between this 5 funtcions, we have been able to observe that all the changes are focused on avoiding detections by slightly “obfuscating” some IOCs hardcoded as strings and code modification without impact in the capabilities on the driver…
In total, there are three notable changes between the two versions:
- The first one basically consists in that they have reversed the list of strings that identify the files that the Driver hides by default when it is loaded:
At code level, the impact this has had is that the function that redirects these files, now uses the “wcrev” function that flips the strings before passing them to the function that hides the files:
- Secondly, they have tried to disguise their use of the undocumented Microsoft API “ObReferenceObjectByName”, which is used to get the pointer to the different Driver_Object drivers they intend to hook in each case. Until now, they had the name of this function in their strings, and used it to resolve it by passing its name to the MmGetSystemRoutineAddress API which returns a pointer to it. Now they only keep part of the name, and complete the rest in a slightly more complex way before calling MmGetSystemRoutineAddress by building it from characters they store in the registers and other areas of the binary:
- Finally, they have moved part of the logic of some functions to another point, maintaining the same functionality. An example is the end of the driver entry function, where untill now, at the end they only called two functions that initialized the logic of hiding connections and redirecting files, and now, they have extracted part of the logic of these functions and moved it right after each one of them, but without any impact on the capabilities and behavior of the Driver: