Malware
Hunting for A New Stealthy Universal Rootkit Loader
In this entry, we discuss the findings of our investigation into a piece of a signed rootkit, whose main binary functions as a universal loader that enables attackers to directly load a second-stage unsigned kernel module.
In one of our recent threat hunting investigations, we came across an interesting new threat activity cluster that we initially thought was a false positive detection for a Microsoft signed file. However, this turned out to be a novel piece of a signed rootkit that communicates with a large command-and-control (C&C) infrastructure for an unknown threat actor that we are currently tracking and that we believe that is the same threat actor behind the rootkit FiveSys. This malicious actor originates from China and their main victims are the gaming sector in China. Their malware seems to have passed through the Windows Hardware Quality Labs (WHQL) process for getting a valid signature. We reported our findings to Microsoft's Security Response Centre (MSRC) in June 2023.
The main binary acts as a universal loader that allows the attackers to directly load a second-stage unsigned kernel module. Each second-stage plug-in is customised to the victim machine it’s deployed on, with some containing even a custom compiled driver for each machine. Each plug-in has a specific set of actions to be carried out from the kernel space.
The found variants are composed of eight main clusters based on the extracted vendor specific metadata from the SPC_SP_OPUS_INFO fields in the signatures (Authenticode) revealed various publishers that these variants signed on their behalf (Figure 1).
Malicious actors currently use different approaches to sign their malicious kernel drivers, typically by:
- Abusing Microsoft signing portals
- Using leaked and stolen certificates
- Using underground services
In this blog entry, we will shed some light on a threat that apparently followed the first approach: abusing WHQL to have a valid signature on a malicious driver that can be successfully loaded on recent Windows versions (Figure 3). We will also provide technical details on this newly discovered malware that comes as a standalone kernel driver signed directly by Microsoft, which is an evolving attack vector that has been frequently appearing in today’s malware landscape. Despite how complex is to build such capabilities, it seems that current malicious actors are exhibiting competence and consistent usage of such tools, tactics, and procedures (TTPs), regardless of their final motive and objectives.
Historical WHCP abuses
Figure 4 shows a timeline for the reported abuses for Windows Hardware Compatibility Programme (WHCP) that led to compromises of the Windows kernel trust model. In June 2021, the Netfilter rootkit was reported, after which Microsoft published an advisory detailing that it was used as a means of geo-location cheating within the gaming community in China. Bitdefender then disclosed FiveSys in October 2021, a rootkit that was mainly used to target online gamers with the main goal of credential theft and in-game-purchase hijacking. Finally, Mandiant reported the last known abuse that revealed Poortry malware, which had been used in a number of cyberattacks that included ransomware-based incidents.
Hunting approach for modern rootkits
Hunting for 64-bit signed rootkits now is not as easy in the days when kernel mode code signing (KMCS) policies mechanisms were introduced as the number of 64-bit signed drivers has increased, as shown in Figure 5. Back then, the volume of signed drivers with at least one detection was much smaller, also the threat actor did not favour it because of the higher development cost for modern kernel rootkits, and the lake of technical capabilities to include kernel rootkits in their malware arsenal or access to the techniques needed to bypass the security defences added to newer Windows versions. This makes hunting for such threats more difficult, but this does not indicate that such threats have completely disappeared from today’s malware landscape.
As shown in Figure 6, we assessed our Windows kernel driver samples based on:
- Their signed driver’s signature being revoked or otherwise
- Their having one or more positive detections based on malware search engines, including the VirusTotal malware repository
Table 1 shows how we segregated each set of the threat samples we have gathered:
| Samples set | Description |
| Set 1 | Signed drivers that have not been revoked with zero positive detection |
| Set 2 | Signed drivers that have not been revoked with one or more positive detection from different engines |
| Set 3 | Signed drivers that have been revoked with zero positive detection |
| Set 4 | Signed drivers that have been revoked with one or more positive detection from different engines |
Hunting for new samples submissions from set 1 and set 2 for malicious behaviour (Figure 7) led us to investigate this emerging samples cluster and the underlying C&C infrastructure serving the second stage plug-ins.
First stage analysis
Based on the collected samples from this campaign, we identified two different clusters that share multiple similarities between their samples (Figure 8). We observed a pattern of having some samples obfuscated with VMProtect and newer samples with more functionality signed later without any obfuscation, which indicates that the malicious actor behind these samples is still in the testing and developing phase.
Most of the samples are “Microsoft Windows Hardware Compatibility Publisher”-signed drivers. We provide an analysis below for a sample from the first cluster.
The driver first cheques if there is another instance on the driver loaded to memory (Figure 9) by trying to open the symbolic name “\??\ea971b87”, which is created by the driver during initialisation. If it successfully opened it, the return error code “0FFFFCFC7” from DriverEntry stops the driver from loading. Then, if the driver is not already loaded, it creates a symbolic name “\??\ea971b87” and initialises its handler’s functions; it only uses “IRP_MJ_DEVICE_CONTROL” and “IRP_MJ_SHUTDOWN” based on the current variants we had observed (Figures 10 and 11).
Then, the driver cheques whether the binary compilation is a debug build or a release, as shown in Figure 12. In case of a debug build, it prints some debug messages throughout the execution; this indicates that the current samples are still under development and testing. Then, the driver disables the User Account Control (UAC) and Secure Desktop mode by editing the registry and initialises Winsock Kernel (WSK) objects for initiating a network activity with the C&C server (Figure 13).
First-stage network initialisation
The first-stage driver is responsible for all network communication with the C&C servers. It initiates all the communication from the kernel space using WSK, a kernel-mode Network Programming Interface (NPI). With WSK, kernel-mode software modules can perform network I/O operations using the same socket programming concepts that are supported by user-mode Winsock2 (Figure 15).
It uses a Domain Generating Algorithm (DGA) algorithm to generate different domains (Figure 16). If it fails to resolve an address, it connects directly to fallout IPs that are hard coded inside the driver. It connects to the driver on port 80 and creates a TCP socket for communication.
Then, it periodically connects to the C&C server to get configuration. It has the option to be a kernel driver loader:
- It receives the data from the C&C server byte by byte (Figure 21)
- It decodes and decrypts the received data (Figure 20)
- It loads the received kernel drivers to the memory directly without writing it to the disc (Figure 22)
- It parses the received Portable Executable (PE) file and does all the relocation
- It calls the driver entry point (Figures 23 and 24)
This way, the kernel plug-in will never touch the disc and will be only in memory, which makes it stealthier and enables it to bypass detections.
Second-stage plug-ins
The downloaded second-stage driver is self-signed, as it’s completely loaded by the first-stage loader, bypassing the Windows native driver loader (Figure 25). Hence, there is no need to sign these second-stage variants. It opens the file “C:\WINDOWS\System32\drivers\687ae09e.sys” then reads its data and encodes it (Figure 26). Then, it divides the data into chunks of memory and writes them to registry path “\Registry\Machine\Software\PtMyMem” alongside its size and MD5 (Figures 27 and 28). After that, it deletes the file “C:\WINDOWS\System32\drivers\687ae09e.sys” from the disc (Figure 29).
Achieving persistence
The first-stage shutdown notification function cheques if a kernel plug-in has been received and loaded in memory from the C&C server for cleanup purposes. It also cheques the registry key “\Registry\Machine\Software\PtMyMem” if it presents, then it iterates on all its subkeys and decodes the data, writing it to the disc with the “C:\WINDOWS\System32\drivers\687ae09e.sys” path. Finally, it creates a service with the name “BaohuName” that will run when the system starts again.
The first stage alongside the second stage (the plug-in downloaded from the C&C server) work together as part of the attackers’ self-protection and persistence method. This technique, combined with the downloaded kernel plug-in from the C&C server, will be the main persistence mechanism for this driver. The detailed analysis for this specific second stage plug-in is as follows:
- The first-stage driver connects to C&C sever to download second-stage driver
- The second-stage driver reads the first-stage driver from disc and write it to registry, then deletes it from disc
- Then, the first-stage and second-stage drivers are only present in memory
- Before rebooting, the first-stage shutdown notification routine is executed
- The shutdown routine will read itself from registry, write itself back to disc, and creates a service that starts the next time the system reboots
Defender terminator plug-in
The main objective of this driver is to stop Windows Defender software. It first disables the anti-spyware detection from the registry key “HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows Defender” (Figure 30), disables the “SecurityHealthService” service (Figure 31), and stops antivirus cheques (Figure 32).
It then adds an entry for all Windows Defender processes in the “Image File Execution Options” registry (Figures 33, 34, and 35), so when any of them crashes, another process will start (Figure 36). The executable that will start is “C:\\Users\\Administrator\\Desktop\\111111111.exe,” which indicates that these plug-ins are customised, and the threat actor is actively developing new divers as needed. It eventually terminates all Windows Defender processes (Figure 37).
Proxy plug-in
This plug-in is responsible for installing a proxy on the machine and redirecting web browsing traffic to a remote proxy machine. It first edits the Windows proxy configuration “hxxp[:]//4dpyplftay8g90qb7l.kkvgsytcw4hsn3g0nc5r[.]xyz:17654/api/pac/PacReback?key=10252”.
Then, it injects a JavaScript inside the browser that, based on the URL, might redirect it to another server (Figure 40). As of May 31, 2023, the observed script that cheques the URL excludes the following suffixes:
- .edu
- .edu:
- .edu/
- .gov
- .gov:
- .gov/
If the URL is one of the domains that is being monitored, it will redirect the traffic to the following addresses:
- HTTP will be redirected to “nt32vn1-redyf[.]gj2oydber4xfa6c[.]com[:]10385”
- HTTPS will be redirected to “ybqjb6[.]ady4111523[.]com[:]10385”
Here are some of the monitored domains:
- www[.]68chuanqi[.]com
- www[.]ooyy[.]com
- www[.]v8cq[.]com
- www[.]bairimen[.]com
- www[.]980cq[.]cn
It also excludes the following domains (Figure 42):
- www[.]baidu[.]com
- e[.]so[.]com
- www[.]sogou[.]com
On January 6, 2023, we observed that the script had changed and started to exclude all URLs that had the following extensions:
- .edu.
- .edu:
- .edu/
- .js
- .css
- .jpg
- .bmp
Also, it stopped to redirect any of the DGA-generated domains and the proxy servers were changed to the following:
- HTTP were now redirected to: 103.45[.]162[.]204:10252
- HTTPS were now redirected to: 103.45[.]162[.]217:10252
Here are some of the monitored domains:
- Angdao[.]com[.]cn
- www[.]newsensation.com[.]cn
Based on this, we believe that the attacker is optimising their filter mechanism to reduce noise.
Attribution analysis
Upon analysis, we have discovered that the drivers and the well-known FiveSys rootkit exhibit numerous similarities in terms of functionality, code similarity, infrastructure, and victimology:
- There are similarities in the C&C infrastructure used by both FiveSys and the newly signed drivers.
- Both the FiveSys rootkit and the second stage of the signed rootkit are functionality focused on redirecting web browsing traffic to a custom proxy server controlled by the attacker. Additionally, they both have the capability to instal a custom root certificate to redirect HTTPS traffic. The primary purpose of the FiveSys rootkit is to monitor and redirect web traffic, but this functionality has evolved and can now be found in the newly signed rootkit, indicating advancements in its capabilities.
- The newly signed rootkit shares numerous functions that are identical to those found in FiveSys, such as hooking the file system functions, and the pre-create mini-filter function (Figure 44).
- Only Chinese systems have reported instances of FiveSys infections, just like the newly discovered drivers that our sensors have detected exclusively within China. One of the suspected entry points for these infections was a trojanized Chinese game, much like FiveSys.
Conclusion
Malicious actors who are actively seeking high-privilege access to Windows operating systems use techniques that attempt to combat the increased protection that endpoint protection platform (EPP) and endpoint detection and response (EDR) technologies provide users and processes. Because of these added layers of protection, attackers tend to opt for the path of least resistance to get their malicious code running via the kernel layer or even lower levels. This is why we believe that such threats will not disappear from threat actors’ toolkits anytime soon.
Malicious actors will continue to use rootkits to hide malicious code from security tools, impair defences, and fly under the radar for long periods of time. These rootkits will see heavy use from sophisticated groups that have both the skills to reverse-engineer low-level system components and the required resources to develop such tools. These malicious actors also tend to possess enough financial resources to either purchase rootkits from underground sources or to buy code-signing certificates to build a rootkit. This means that the main danger involving these kinds of rootkits lies in their ability to hide complex targeted attacks that will be used early in the kill chain, allowing an attacker to impair defences before their actual payloads are launched in victim environments.
We are currently working to make the indicators of compromise (IOCs) available to the public as part of our ongoing efforts.