Silent Killers: Unmasking a Large-Scale Legacy Driver Exploitation Campaign

Highlights

• CPR uncovered a large-scale ongoing campaign involving thousands of first-stage malicious samples used to deploy an EDR/AV killer module in its initial stage. This module was first detected and recorded in June 2024. It was observed leveraging and exploiting more than 2,500 distinct variants of the legacy version 2.0.2 of the known vulnerable driver Truesight.sys, which is the RogueKiller Antirootkit Driver and part of Adlice’s product suite. This driver has a known vulnerability in versions below 3.4.0.
• The attackers exploited the legacy version 2.0.2 of the Truesight driver to take advantage of a Windows policy loophole (Exception in Driver Signing Policy), allowing the driver to be loaded on the latest versions of Windows OS. Notably, the attackers specifically selected the 2.0.2 version because it retains the vulnerable code while also bypassing the latest Microsoft Vulnerable Driver Blocklist and common detection mechanisms, such as those introduced by the LOLDrivers project, none of which detect this version.
• To further evade detection, the attackers deliberately generated multiple variants (with different hashes) of the 2.0.2 driver by modifying specific PE parts while keeping the signature valid. We detected over 2,500 validly signed variants of this driver.
• The attackers leveraged infrastructure in a public cloud’s China region to host payloads and operate their C2 servers. Around 75% of the victims are located in China, while the remainder come from other parts of Asia (e.g., Singapore, Taiwan).
• The initial-stage samples act as downloaders/loaders and often disguise themselves as well-known applications. They are typically distributed via phishing methods, including deceptive websites and phishing channels in messaging apps. Along with the EDR/AV killer module, they are designed to prepare the infected machine to deliver final-stage payloads, such as Gh0st RAT variants.
• CPR reported this issue to MSRC, leading to an updated version of the Microsoft Vulnerable Driver Blocklist (available since December 17, 2024), effectively preventing all variants of the legacy driver exploited in this campaign.

Introduction

While the abuse of vulnerable drivers has been around for a while, those that can terminate arbitrary processes have drawn increasing attention in recent years. As Windows security continues to evolve, it has become more challenging for attackers to execute malicious code without being detected. As a result, the attackers often aim to disable security solutions by targeting their crucial components. These components, usually a part of security solutions for Windows OS, run as protected processes (PP/PPL) using the kernel modules of these solutions to support their functionality.

Since directly terminating protected processes (PP/PPL) from user-mode using conventional methods is highly challenging, attackers turn to exploiting vulnerabilities instead. Vulnerable drivers have become a key focus, providing attackers with a pathway to bypass these protections and prepare the compromised machine for further stages of infection.

A few months ago, we released our research on vulnerable drivers and shared a methodology for hunting not-known-to-be-vulnerable drivers. Inspired by that, we tried to adopt the attacker´s mindset and deployed specific future-focused hunting rules that, instead of detecting the abuse of already known vulnerable drivers (e.g., LOLDrivers), detect the potential abuse of not-known-to-be-vulnerable drivers.

This hunting technique has a rather high false positive ratio, so we filtered these FPs away until we uncovered a massive ongoing campaign involving thousands first-stage malicious samples deploying an EDR/AV killer module in its initial stage.

This module was observed leveraging and exploiting more than 2,500 distinct variants of the same legacy version, 2.0.2, of the known vulnerable driver Truesight.sys – the RogueKiller Antirootkit Driver, part of Adlice’s product suite.

Although the Truesight driver has a known vulnerability (Arbitrary Process Termination) affecting versions below 3.4.0 (version 3.4.0 is already patched), and some of its versions (e.g., 3.3.0) are known to be abused in the wild and properly detected, the legacy version 2.0.2 flew under the radar. It was not recognized as a known-vulnerable driver by the Microsoft Vulnerable Driver Blocklist or by other common detection mechanisms, such as those introduced by the LOLDrivers project.

This publication takes a deep dive into this sophisticated campaign, unraveling how and why the attackers exploited the legacy Truesight driver to bypass advanced security measures. We’ll explore the techniques they used to stay undetected for months, from manipulating the driver to create thousands of variants to evading blocklists and detail the broader implications for defenders. Additionally, we’ll share how the attackers employed other advanced techniques throughout the infection chain, from persistence mechanisms and DLL side-loading to the use of commercial protectors, ultimately leading to the final payload delivery.

Background & Key Findings

From a research perspective, it’s always beneficial to create future-focused hunting rules. While these rules are often far from production-ready (and often feel more like Ghostbusters waiting for a ghost that might never appear), they can still lead to valuable discoveries. Such rules may help uncover new techniques or ongoing campaigns that have flown under the radar for some time. When we become aware of a new, non-public technique or methodology that hasn’t been observed in active use yet, it doesn’t mean attackers are unaware of it or won’t adopt it in the future. This is precisely the moment to start crafting future-focused rules.

With this approach in mind, we focused on hunting for potential abuse of not-known-to-be-vulnerable drivers and initially detected hundreds of interesting samples that led to uncovering a massive, ongoing campaign.

When we began analyzing one of the detected samples, at first glance we observed the malicious sample dropping a known vulnerable driver, Truesight.sys – the RogueKiller Anti-Rootkit Driver, which is part of Adlice’s product suite (notice the File Version of this driver 2.0.2 – it can be easily missed).

The Truesight driver is well known to be vulnerable and already being abused in the wild. The known vulnerability (Arbitrary Process Termination – affecting versions below 3.4.0) was already utilized by a few publicly available PoCs. In fact, two highly visible GitHub repositories using this driver as an EDR/AV Killer were published over a year ago:

TrueSightKiller (C++): https://github.com/MaorSabag/TrueSightKiller

Darkside (C#): https://github.com/ph4nt0mbyt3/Darkside

Both of them abuse the arbitrary process termination capability of this driver just by issuing appropriate IOCTL 0x22E044, where the exploit can be implemented as simply as:

#define TERMINATE_PROCESS_IOCTL_CODE 0x22e044
// Loading the Truesight.sys driver
DWORD bytesReturned = 0;
DWORD pid = 1337; // Pid of process to be killed, PP/PPL processes possible
HANDLE hDevice = CreateFileA("\\\\.\\TrueSight", GENERIC_READ | GENERIC_WRITE, NULL, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
DeviceIoControl(hDevice, TERMINATE_PROCESS_IOCTL_CODE, &pid, sizeof(DWORD), NULL, 0, &bytesReturned, NULL);

Initially, we assumed it was just another “TrueSightKiller” fork and overlooked the suspicious-looking version of the driver – 2.0.2. What put us in the right trail was the double-checking of the TrueSightKiller repository, where we noticed that it uses the Truesight driver, version 3.3.0. As this version (3.3.0) of the driver was part of a list we deliberately avoided from detection by our hunting rules (already known to be vulnerable, part of the LOLDrivers project and Microsoft Vulnerable Driver Blocklist), we got back to the investigation (checking why the driver was actually detected) where we finally noticed the old version 2.0.2 that is being used by our detected samples.

At first, we quickly confirmed that the original legacy Truesight driver, version 2.0.2, still contains the vulnerable code allowing arbitrary process termination and that this is precisely how the detected samples were abusing the driver (EDR/AV killer module). We followed the lead and searched for the system path C:\\Windows\\System32\\drivers\\189atohci.sys where some of the detected samples dropped the driver. Below, we can see that almost 300 different samples were detected.

Just by reviewing a few of them, we quickly noticed that while they drop the same version of the legacy Truesight driver, version 2.0.2, the file hashes of those drivers differ (notice the same compilation timestamp).

At this moment, we knew we were just one good search away from a crucial discovery. Below, we can see the detection of over 2,500 different variants (unique file hashes) linked to the same legacy Truesight driver, version 2.0.2, abused in this campaign.

To confirm, we searched for all Truesight drivers while excluding the legacy version 2.0.2. As expected, we found close to twenty different versions of the Truesight driver.

It appears that the attackers manipulate the Truesight driver, version 2.0.2, altering it just enough to generate different file hashes while still maintaining its valid digital signature. As a result, VirusTotal telemetry has detected over 2,500 unique variants of the same driver.

Surprisingly, some driver variants (those with an available execution context in VirusTotal) are being used by hundreds of different initial-stage samples. This gives us an idea of the scale of this campaign, suggesting that there could be hundreds of thousands of first-stage samples, which later abuse some of the 2,500+ variants of the legacy Truesight driver, version 2.0.2. It’s important to note that these numbers are based solely on VirusTotal telemetry, meaning the actual figures are likely even higher.

Huorong’s analysis of a September 2024 campaign shared some similarities to our findings related to the execution chain and TTPs which were attributed to the threat actor Silver Fox. While there is overlap, our findings differ in several key areas. Based on the observed infection vector, execution chain, similarities in initial-stage samples to previously attributed campaigns, and historical targeting patterns, CPR assesses with medium-to-high confidence that this campaign is linked to Silver Fox.

More technical details about this campaign, including how and why the attackers created these variations of the driver, as well as their step-by-step progression from the initial stage to the final payload using advanced techniques, will be covered in the technical analysis section.

Infrastructure & Victimology

The attackers are leveraging infrastructure in a public cloud’s China region, both for hosting payloads (downloaded from buckets in the CN region – see the Appendix B) and operating their C2 servers. Around 75% of the victims are located in China, with the remainder coming mostly from other parts of the Asia region (e.g., Singapore, Taiwan).

The initial-stage samples, acting as downloaders, often disguise themselves as known applications, typically distributed via phishing methods, including deceptive websites and phishing channels in popular messaging apps.

One such example of a deceptive website (https[://]bung486[.]com) luring visitors with “best buy” deals on luxury goods is shown below. The domain bung486[.]com was registered on 29 of September, 2024, while the content was captured on 6 of October, 2024.

When visitors click on any messaging app icon, they are redirected to a phishing channel within the corresponding messaging app.

It would be a questionable coincidence that, on October 2, 2024 (the date the ITW URL was scanned), the deceptive website also hosted one of the initial-stage samples involved in this campaign (https[://]bung486[.]com/oot.setup.w06.exe).

The initial infection vector, driven by phishing tactics such as deceptive websites and phishing channels, indicates that the attackers are financially motivated rather than being part of a state-sponsored group engaged in espionage. Due to the broad nature of these phishing methods, the targeted victims are likely wide-ranging, with a high probability that they include individuals or organizations across various sectors rather than being limited to specific companies or industries.

Technical Analysis: Initial Stages

One of the earliest detected initial-stage samples in this campaign, which deployed the legacy version of the Truesight driver, first appeared in mid-June 2024. This sample specifically exploited version 2.0.2 of the original legacy driver. As the campaign evolved, about a month later (July 2024), the initial-stage samples shifted away from using the original driver and instead began exploiting thousands of its variants.

The initial phase of infection involves three separate stages, summarized as follows:

1. Stage1 – downloading the Stage2 + encrypted payloads for Stage2 (mimicking common file types, such as PNG, JPG, and GIF), and the variation of the legacy Truesight driver, version 2.0.2.

2. Stage2 – loading encrypted payloads, downloading Stage3 + encrypted payloads for Stage3 (mimicking common file types, such as PNG, JPG, and GIF).

3. Stage3 involves loading encrypted payloads, in-memory deploying the EDR/AV killer module (retrieved from the encrypted payloads), downloading and in-memory executing the final stage (Gh0st RAT), and connecting to the C2 server.

Acting as downloaders, the first-stage samples often masquerade as legitimate applications, installers, and utilities. The table below provides examples of such samples that we thoroughly analyzed while the attacker’s infrastructure was still active.

Initial Stage SHA-256	VT – First Submission Date	Final Payload	C2 Server
8a955633b93b27bc6c0751064a6ad5d6c0bf7b096d72779ced1a1a73b74cec31	2024-11-15 02:01:45 UTC	Gh0st RAT	8[.]212[.]102[.]228:9000
9446165c038e30d89a877728d767a791b4beec6755834d7eeac5f3c418d4834c	2024-11-29 17:31:17 UTC	Gh0st RAT	8[.]210[.]12[.]177:9011

While the initial Stage1 samples work as simple downloaders without any persistence, Stage2 and Stage3 are both downloaders/loaders executed via persistent scheduled tasks (usually following the scheduled task name pattern MicrosoftEdgeUpdateTaskUA Task-S-1-5-18 [A-Za-z0-9]{5}) that abuse the DLL side-loading technique, setting its target on some benign, original, valid-signed binary. See the example below related to Stage3.

As previously mentioned, the malicious payloads delivered alongside Stage2 and Stage3 are encrypted in a form to resemble common file types like PNG, JPG, and GIF. These encrypted files typically contain either a 32-bit PE binary or shellcode. Once loaded into memory and decrypted, the payloads are either reflectively loaded (for PE binaries) or directly executed (for shellcode).

To complicate the analysis, any decrypted payloads that resolve to a 32-bit PE binary are protected using the commercial tool VMProtect. The attackers appear to have utilized one of the latest versions of VMProtect and intentionally opted for 32-bit code to make analysis and reconstruction significantly more difficult. This decision likely stems from the fact that most publicly available tools and techniques for reversing VMProtected binaries are designed for 64-bit binaries and older versions of the protector.

Notably, while the variants of the legacy Truesight driver (version 2.0.2) are typically downloaded and installed by the initial-stage samples, they can also be deployed directly by the EDR/AV killer module if the driver is not already present on the system. This indicates that although the EDR/AV killer module is fully integrated into the campaign, it is capable of operating independently of the earlier stages.

Technical Analysis: EDR/AV Killer Module

The Stage3 component utilizes the EDR/AV killer module, which is stored as an encrypted payload on disk alongside Stage3. Once decrypted, it reveals a 32-bit DLL named S.dll, containing a single exported function: CLRCreateInstance. Like the initial-stage samples, this module is protected by the commercial tool – VMProtect.

This EDR/AV killer module abuses the legacy version of the Truesight driver (2.0.2) to terminate processes related to certain security solutions. Since reverse engineering VMProtected binaries is particularly challenging, we initially focused on whether the Truesight driver was being exploited in the same manner as publicly available proof-of-concepts (PoCs) – Arbitrary Process Termination via IOCTL 0x22E044. This was quickly confirmed by capturing the communication between the EDR/AV killer module and the Truesight driver, as shown below.

Encouraged by the results of our dynamic analysis, we shifted our focus to recovering the critical sections of the VMProtected code. We successfully reconstructed the most significant parts of the EDR/AV killer module, gaining deeper insights into its development. While the attacker may have drawn inspiration from publicly available PoCs (e.g., TrueSightKiller), the implementation is noticeably different, suggesting it was built from scratch rather than directly reused. Below, we can see the main logic of the module.

The Truesight driver (version 2.0.2) is typically downloaded and installed as a service named TCLService by the initial-stage samples. However, if the driver is not already present on the system, the EDR/AV killer module can deploy it in the same manner. In such cases, the driver is retrieved from a public cloud, following the URL pattern: https[://]22mm[.]oss-cn-hangzhou[.]aliyuncs[.]com/s[.]dat. While the OSS Region ID (e.g., oss-cn-hangzhou) and OSS Bucket Name (22mm) may vary, the location remains within China (CN).

With the recovered code of this module available, we were able to validate our dynamic analysis findings regarding its process termination mechanism. The module utilizes the Windows API function DeviceIoControl to send the IOCTL 0x22E044 (Arbitrary Process Termination) directly to the Truesight driver’s device. This routine targets a hardcoded list of processes primarily associated with security solutions. The complete list, which includes 192 process names, can be seen in Appendix A.

Technical Analysis: The Legacy Truesight Driver

As mentioned in previous sections, the attackers are exploiting the legacy version 2.0.2 of the Truesight.sys driver. They chose to do so for several reasons. Let’s dissect these reasons to better understand their approach.

Readily available PoC – Source of Inspiration

First of all, they took advantage of a known vulnerability in the Truesight driver (Arbitrary Process Termination) and leveraged it in their EDR/AV killer module. This was an easy task for them, as a publicly available PoC has been around for some time, providing a source of inspiration.

Taking advantage of a Windows policy loophole

Secondly, as you may have noticed, we refer to the Truesight driver version 2.0.2 as a legacy driver. The reason for this is that starting with Windows 10 version 1607, Microsoft implemented a new policy that prevents the loading of any new kernel-mode drivers that are not signed via its Developer Portal – that is, signed by Microsoft itself. Unfortunately, Truesight driver version 2.0.2 falls under the exceptions to Microsoft’s driver signature policy validation. Specifically, it belongs to the category of “Drivers signed with an end-entity certificate issued prior to July 29, 2015, that chains to a supported cross-signed CA”.

To clarify, even the latest version of Windows 11 is allowed to load this legacy Truesight driver (see the image below related to the original Truesight driver version 2.0.2).

Bypassing the Microsoft Vulnerable Driver Blocklist

Another reason why the attackers deliberately chose to use the specific 2.0.2 version of the Truesight driver: to bypass the Microsoft Vulnerable Driver Blocklist, a built-in Windows mechanism designed to protect the system against known vulnerable drivers enforced through the WDAC policy. This blocklist is not solely based on hash detection; it can identify and block specific drivers using various attributes, such as the original filename, version range, hash, and TBS hash value of the certificate.

The TBS hash value is used in the Microsoft Vulnerable Driver Blocklist in conjunction with file attributes like the original filename, version range, etc., to accurately detect specific drivers signed by a particular certificate (identified through the calculated TBS hash value). To easily calculate TBS hash values for a specific driver, the built-in PowerShell cmdlet New-CIPolicyRule can be used.

(New-CIPolicyRule -DriverFilePath .\truesight3.3.0.0_original.sys -Level PcaCertificate).Where{$_.UserMode -eq $false} | Format-List -Property Name, Root

Naturally, the Truesight driver, known to be vulnerable, is included in this blocklist. Let’s examine the Denied Signer entry related to the Truesight driver in the latest Microsoft Vulnerable Driver Blocklist. This entry essentially states that drivers with the original filename “Truesight”, from version “0.0.0.0” to “3.3.0.0”, signed with certificates matching specific TBS hash values, are denied from loading. As a result, a wide range of Truesight driver versions are effectively blocked.

<Signer ID="ID_SIGNER_WINDOWS_3RD_PARTY_2012" Name="Microsoft Windows Third Party Component CA 2012">
      <CertRoot Type="TBS" Value="CEC1AFD0E310C55C1DCC601AB8E172917706AA32FB5EAF826813547FDF02DD46" />
      <CertPublisher Value="Microsoft Windows Hardware Compatibility Publisher" />
      <FileAttribRef RuleID="ID_FILEATTRIB_TRUESIGHT"/>
</Signer>
    
<Signer ID="ID_SIGNER_TRUESIGHT_1" Name="Sectigo Public Code Signing Root R46">
      <CertRoot Type="TBS" Value="A229D2722BC6091D73B1D979B81088C977CB028A6F7CBF264BB81D5CC8F099F87D7C296E48BF09D7EBE275F5498661A4"/>
      <FileAttribRef RuleID="ID_FILEATTRIB_TRUESIGHT"/>
</Signer>
    
<Signer ID="ID_SIGNER_TRUESIGHT_2" Name="DigiCert SHA2 High Assurance Code Signing CA">
      <CertRoot Type="TBS" Value="0BF095B845B69928B5D7DFD1C42AE4F90FEB8DC97F7830598C93E848877021FB"/>
      <CertPublisher Value="Adlice"/>
      <FileAttribRef RuleID="ID_FILEATTRIB_TRUESIGHT"/>
</Signer>
<FileAttrib ID="ID_FILEATTRIB_TRUESIGHT" FriendlyName="Adlice Truesight.sys\3807e9a1bc159b9e8fc0c7caad10d7213ff8ed8ad1cea9ea552b093c81bf624b FileAttribute" FileName="Truesight" MinimumFileVersion="0.0.0.0" MaximumFileVersion="3.3.0.0"/>

This policy has proven effective in preventing the loading of, for example, Truesight driver version 3.3.0, as the calculated TBS hash values of the certificate for this version match those defined in the blocklist for the Truesight driver.

The TBS hash value of the certificate associated with the legacy Truesight driver version 2.0.2 is: 1D7E838ACCD498C2E5BA9373AF819EC097BB955C.

After reviewing the latest version of the Microsoft Vulnerable Driver Blocklist, it was found that the TBS hash value 1D7E838ACCD498C2E5BA9373AF819EC097BB955C, which corresponds to the certificate DigiCert High Assurance Code Signing CA-1, is indeed listed as a Denied Signer. However, it is associated with different drivers and not with the Truesight driver.

As a result, the legacy Truesight driver, version 2.0.2, can bypass the Microsoft Vulnerable Driver Blocklist, and its loading will not be blocked by this security mechanism.

Evading the hash-based detection

To further evade detection, the attackers intentionally generated thousands of variants (with different hashes) of the legacy Truesight driver (2.0.2) by altering specific parts of the PE file while ensuring the digital signature remained valid.

More specifically, only two areas of the driver are modified. The first involves a specific part of the PE → NT Header → OptionalHeader → CheckSum (4 bytes), as shown in the image below. This modification does not impact the validity of the digital signature because certain parts of the PE binary are excluded from the hash calculation during the signing process, such as the CheckSum field.

The second modification occurs at the end of the file (4 bytes), which is part of the data related to the WIN_CERTIFICATE structure. This structure holds the attribute certificate entry, which must always align to quadword boundaries (8-byte boundaries). If an entry’s dwLength does not end on an 8-byte boundary, it will be padded with zero bytes to maintain proper alignment.

Modifying this zero-byte padding does not affect the signature or validity of the certificate, as it’s outside the cryptographic data. In the case of the legacy Truesight driver, the attacker can freely modify the 5-byte zero-padding area. In our example, the attacker altered only 4 bytes, even though 5 bytes could have been modified.

In summary, the attacker is modifying 8 bytes of the legacy Truesight driver (4 bytes in the CheckSum and 4 bytes in the WIN_CERTIFICATE padding), allowing the creation of 2^64 unique file hashes for the same driver while still preserving the validity of the driver’s signature. We detected more than 2,500 distinct variants.

The known vulnerability (Arbitrary Process Termination) in the Truesight driver, affecting versions below 3.4.0, was patched over a year ago. A comparison between the original legacy Truesight driver version 2.0.2 and the patched version 3.4.0 reveals the addition of a check for the process to be terminated. If the process runs as protected (PP/PPL), which is typical for security solutions, the termination attempt will be aborted.

Technical Analysis: Final Stages

Among several initial-stage samples, we deeply investigated (with an active attacker´s infrastructure), all of them were deploying the same final stage – a variant of the Gh0st RAT. This well-known Remote Access Trojan (RAT), recognized for its stealth and effectiveness, is designed to remotely control compromised computers, granting attackers unauthorized access for data theft, surveillance, and system manipulation

There are dozens of variants of Gh0st RAT that are derived from the available source code. Although the source code has been publicly available for several years, Gh0st RAT is mainly used by threat actors based in China

An example of a reconstructed Gh0st RAT variant (dumped from memory and repaired), delivered through the initial-stage samples in this campaign, overlaps with the variant described in this publication.

Most of the code routines described in the article are similar to those in our delivered final-stage payload. For instance, both use the EnumWindow and GetWindowTextA functions to enumerate and compare window names (using the same window names) for detection risk assessment.

Another example is a code routine that retrieves new C2 addresses from an ip.txt file hosted on a remote attacker-controlled server.

We believe this is the same Gh0st RAT variant known as HiddenGh0st, as described in this publication. It shares clear similarities with the “string version” of Gh0st RAT, including the “hx” identifier, packet encryption, and network communication via a custom protocol.

One key factor for properly attributing a sample as a Gh0st RAT variant is its custom network protocol encryption algorithm. It typically involves a single-byte XOR operation combined with SUB/ADD operations on each byte, along with the RAT’s specific capabilities.

Here’s an example from our sample: the initial Gh0st RAT network communication, which utilizes the custom network protocol with encryption following a similar logic – applying a single-byte XOR operation combined with an ADD operation on each byte.

As previously mentioned, there are dozens of publicly available versions of the Gh0st RAT malware, and any attacker can easily create their own variant. Since it’s not considered best practice to name every version found in the wild, we have not assigned a specific name to our sample, which only slightly differs from others.

Given the vast number of initial-stage samples involved in this campaign (thousands), the attacker may deploy another final-stage payload, though it will likely retain similar RAT functionality.

Mitigation & Remediation

As previously described, the attackers are modifying the Truesight driver (version 2.0.2), making minimal changes to alter its file hash while preserving its valid digital signature. As a result, hash-based detection alone proves ineffective.

At the time of our investigation, none of the legacy Truesight driver variants were classified as known-vulnerable by the Microsoft Vulnerable Driver Blocklist or by other common detection mechanisms, such as those implemented by the LOLDrivers project.

The Microsoft Vulnerable Driver Blocklist uses advanced detection mechanisms, beyond just hash-based checks, to protect against known vulnerable drivers. Since it is built into the Windows OS, CPR reported the issue to MSRC, resulting in an updated version of the Blocklist (released on December 17, 2024). This update effectively prevents all variants of the legacy driver exploited in this campaign.

We recommend manually applying the latest version of the Microsoft Vulnerable Driver Blocklist, as it is usually auto-updated only once or twice a year.

Conclusion

Detecting the abuse of known vulnerable drivers is essential for mitigating known threats. However, proactively hunting for the abuse of drivers not yet identified as vulnerable can lead to significant discoveries, often uncovering stealthy operations that have been flying under the radar for months or even years. This publication demonstrates how research-driven, future-focused detection rules can reveal hidden threats designed to evade detection for extended periods.

In the uncovered massive campaign, the attackers leveraged thousands of initial-stage malicious samples and exploited over 2,500 distinct variants of the legacy Truesight driver. By modifying specific parts of the driver while preserving its digital signature, the attackers bypassed common detection methods, including the latest Microsoft Vulnerable Driver Blocklist and LOLDrivers detection mechanisms, allowing them to evade detection for months. Exploiting Arbitrary Process Termination vulnerability allowed the EDR/AV killer module to target and disable processes commonly associated with security solutions, further enhancing the campaign’s stealth.

This case highlights a key lesson: hash-based detection alone is not sufficient enough to identify sophisticated attacks. The attackers were able to modify the driver in ways that made hash-based checks ineffective, reinforcing the need for more comprehensive detection strategies. Windows security mechanisms, such as the built-in Microsoft Vulnerable Driver Blocklist, offer a more robust approach by blocking drivers based on attributes beyond just hashes. This multi-faceted approach is critical for improving detection and protection against evolving threats.

The latest updates to the Microsoft Vulnerable Driver Blocklist, which now includes the legacy Truesight driver exploited in this campaign, effectively prevent loading all its variants. We recommend enabling and applying the latest blocklist updates on all Windows systems.

Protections

Check Point Threat Emulation and Harmony Endpoint provide comprehensive coverage of attack tactics, filetypes, and operating systems and protect against the attacks and threats described in this report.

Harmony Endpoint

• Gen.Rep.sys
• Behavioral.Sideloading.p

Threat Emulation

• Backdoor.Wins.Truesight.A

References

• CPR – Breaking Boundaries: Investigating Vulnerable Drivers and Mitigating Risks: https://research.checkpoint.com/2024/breaking-boundaries-investigating-vulnerable-drivers-and-mitigating-risks/ 

• LOLDrivers: https://github.com/magicsword-io/LOLDrivers

• Adlice products: https://www.adlice.com/

• Microsoft Vulnerable Driver Blocklist: https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/design/microsoft-recommended-driver-block-rules

• TrueSightKiller: https://github.com/MaorSabag/TrueSightKiller

• Darkside: https://github.com/ph4nt0mbyt3/Darkside

• Gh0st RAT – Malpedia: https://malpedia.caad.fkie.fraunhofer.de/details/win.ghost_rat

• VMProtect: https://vmpsoft.com/vmprotect

• Huorong Threat Intelligence Center – Silver Fox new variants: https://www.huorong.cn/document/tech/vir_report/1772

• Sangfor FarSight Labs – Gh0st RAT: https://www.sangfor.com/farsight-labs-threat-intelligence/cybersecurity/gh0st-rat-spreads-using-fake-telegram-download-page

• ASEC – HiddenGh0st: https://asec.ahnlab.com/en/57185/

• Catching RATs Over Custom Protocols: https://www.zscaler.com/blogs/security-research/catching-rats-over-custom-protocols

• Microsoft Driver Signing Policy – Exceptions: https://learn.microsoft.com/en-us/windows-hardware/drivers/install/kernel-mode-code-signing-policy–windows-vista-and-later-#exceptions

• Microsoft – The Attribute Certificate Table: https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#the-attribute-certificate-table-image-only

Appendix A – List of Processes to be Terminated

2345AdRtProtect.exe
2345AuthorityProtect.exe
2345ExtShell.exe
2345ExtShell64.exe
2345FileShre.exe
2345LeakFixer.exe
2345LSPFix.exe
2345ManuUpdate.exe
2345MPCSafe.exe
2345PCSafeBootAssistant.exe
2345RTProtect.exe
2345RtProtectCenter.exe
2345SafeCenterSvc.exe
2345SafeSvc.exe
2345SafeTray.exe
2345SafeUpdate.exe
2345ShellPro.exe
2345SysDoctor.exe
2345VirusScan.exe
360FileGuard.exe
360leakfixer.exe
360rp.exe
360rps.exe
360Safe.exe
360sd.exe
360sdrun.exe
360sdupd.exe
360Tray.exe
ad-watch.exe
AgreementViewer.exe
Appvant.exe
ashDisp.exe
aswidsagent.exe
aswToolsSvc.exe
Autoruns.exe
AvastSvc.exe
AvastUI.exe
avcenter.exe
Avira.OptimizerHost.exe
Avira.Spotlight.Bootstrapper.exe
Avira.Spotlight.Common.Updater.exe
Avira.Spotlight.Common.UpdaterTracker.exe
Avira.Spotlight.FallbackUpdater.exe
Avira.Spotlight.Service.exe
Avira.Spotlight.Service.Worker.exe
Avira.Spotlight.Systray.Application.exe
Avira.Spotlight.UI.AdministrativeRightsProvider.exe
Avira.Spotlight.UI.Application.exe
Avira.Spotlight.UI.Application.Messaging.exe
avp.exe
avpui.exe
baiduSafeTray.exe
BaiduSd.exe
Bka.exe
BkavService.exe
BkavSystemServer.exe
BkavSystemService.exe
BkavSystemService64.exe
BkavUtil.exe
BLuPro.exe
BluProService.exe
cefutil.exe
CheckSM.exe
computercenter.exe
ComputerZ_CN.exe
ComputerZMonHelper.exe
ComputerzService_x64.exe
ComputerZService.exe
ComputerZTray.exe
crashpad_handler.exe
dep360.exe
DesktopAssistant.exe
DesktopAssistantApp.exe
DlpAppData.exe
DrvMgr.exe
DSMain.exe
DSMain64.exe
DumpUper.exe
EMDriverAssist.exe
endpointprotection.exe
FileSmasher.exe
FirstAidBox.exe
guardhp.exe
hdw_disk_scan.exe
HipsDaemon.exe
HipsLog.exe
HipsMain.exe
HipsTray.exe
hotfixplatform.exe
HRUpdate.exe
K7TSecurity.exe
KanKan.exe
kauthorityview.exe
kdinfomgr.exe
kislive.exe
knewvip.exe
knsdtray.exe
KSafeTray.exe
kscan.exe
ksoftpurifier.exe
ktrashautoclean.exe
KvMonXP.exe
kwsprotect64.exe
kxecenter.exe
kxemain.exe
kxescore.exe
kxetray.exe
LAVService.exe
Ldshelper.exe
LdsSecurity.exe
LdsSecurityAider.exe
LeAppOM.exe
LeASHive.exe
LenovoAppStore.exe
LenovoAppupdate.exe
LenovoInternetSoftwareFramework.exe
LenovoMonitorManager.exe
LenovoOKM.exe
LenovoPcManager.exe
LenovoPcManagerService.exe
LenovoTray.exe
LISFService.exe
LiveUpdate360.exe
LnvSvcFdn.exe
Lsf.exe
mcapexe.exe
mcshield.exe
McUICnt.exe
MfeAVSvc.exe
mfemms.exe
mfevtps.exe
ModuleUpdate.exe
MpCmdRun.exe
mpcopyaccelerator.exe
MpDefenderCoreService.exe
MsMpEng.exe
MSPCManager.exe
MSPCManagerService.exe
mssecess.exe
NACLdis.exe
NetFlow.exe
NisSrv.exe
PopWndLog.exe
PromoUtil.exe
PSafeSysTray.exe
QHActiveDefense.exe
QHSafeMain.exe
QHSafeScanner.exe
QHSafeTray.exe
QHWatchdog.exe
QMDL.exe
QMPersonalCenter.exe
QQPCMgrUpdate.exe
QQPCPatch.exe
QQPCRealTimeSpeedup.exe
QQPCRTP.exe
QQPCTray.exe
QQRepair.exe
QUHLPSVC.EXE
RavMonD.exe
remupd.exe
rtvscan.exe
SearchEngine.exe
SecurityHealthSystray.exe
SentryEye.exe
SoftMgrLite.exe
SRAgent.exe
StartupManager.exe
SuperKiller.exe
TMBMSRV.exe
TQClient.exe
TQDefender.exe
TQedrname.exe
TQSafeUI.exe
TQTray.exe
TQUpdateUI.exe
TQWatermark.exe
trantorAgent.exe
UnThreat.exe
usysdiag.exe
V3Svc.exe
vsserv.exe
web_host.exe
wsc_proxy.exe
wsctrl.exe
wsctrl10.exe
wsctrl11.exe
wsctrl7.exe
wsctrlsvc.exe
WSPluginHost.exe
WSPluginHost64.exe
ZhuDongFangYu.exe

Appendix B – IOCs

SHA-256 hash list of the initial-stage samples (samples with a behavioral execution context on VT that dropped a variant of the legacy Truesight driver, version 2.0.2 – as of January 31, 2025).

SHA-256 hash list of validly signed variants of the legacy Truesight driver, version 2.0.2, that were abused in the campaign (as of January 31, 2025) – detected by the YARA rule in Appendix C. This list excludes samples found in VT telemetry without a valid certificate or malformed.

The list of domains used by the initial-stage samples.

3syd1z[.]oss-cn-beijing[.]aliyuncs[.]com
tjgohh[.]oss-cn-beijing[.]aliyuncs[.]com
qihbnq[.]oss-cn-beijing[.]aliyuncs[.]com
662hfg[.]oss-cn-beijing[.]aliyuncs[.]com
hdsuer[.]oss-cn-shanghai[.]aliyuncs[.]com
jcoiw1[.]oss-cn-shanghai[.]aliyuncs[.]com
khec3y[.]oss-cn-beijing[.]aliyuncs[.]com
vien3h[.]oss-cn-beijing[.]aliyuncs[.]com
19nsoo[.]oss-cn-beijing[.]aliyuncs[.]com
fyge20[.]oss-cn-beijing[.]aliyuncs[.]com
2uuo9s[.]oss-cn-beijing[.]aliyuncs[.]com
66yuos[.]oss-cn-beijing[.]aliyuncs[.]com
ss2bjo[.]oss-cn-beijing[.]aliyuncs[.]com
129sos[.]oss-cn-beijing[.]aliyuncs[.]com
212soo[.]oss-cn-beijing[.]aliyuncs[.]com
cyerl0[.]oss-cn-beijing[.]aliyuncs[.]com
ylcsn6[.]oss-cn-beijing[.]aliyuncs[.]com
fhdjuc[.]oss-cn-beijing[.]aliyuncs[.]com
hvihei[.]oss-cn-beijing[.]aliyuncs[.]com
sy4fiw[.]oss-cn-beijing[.]aliyuncs[.]com
6ttro[.]oss-cn-beijing[.]aliyuncs[.]com
18os18[.]oss-cn-shanghai[.]aliyuncs[.]com
n7n7so[.]oss-cn-beijing[.]aliyuncs[.]com
ss11oo[.]oss-cn-hangzhou[.]aliyuncs[.]com
yr1212[.]oss-cn-beijing[.]aliyuncs[.]com
n1mm[.]oss-cn-hangzhou[.]aliyuncs[.]com
cnj4ks[.]oss-cn-beijing[.]aliyuncs[.]com
xg51uu[.]oss-cn-beijing[.]aliyuncs[.]com
7syd2u[.]oss-cn-beijing[.]aliyuncs[.]com
jx2zg4[.]oss-cn-beijing[.]aliyuncs[.]com
ry2ihs[.]oss-cn-beijing[.]aliyuncs[.]com
msd1sq[.]oss-cn-beijing[.]aliyuncs[.]com
a8mw1y[.]oss-cn-beijing[.]aliyuncs[.]com
basdy1[.]oss-cn-beijing[.]aliyuncs[.]com
42o[.]oss-cn-beijing[.]aliyuncs[.]com
omss[.]oss-cn-hangzhou[.]aliyuncs[.]com
823ots[.]oss-cn-beijing[.]aliyuncs[.]com
te94os[.]oss-cn-beijing[.]aliyuncs[.]com
temm[.]oss-cn-hangzhou[.]aliyuncs[.]com
m39m[.]oss-cn-hangzhou[.]aliyuncs[.]com
69sso[.]oss-cn-beijing[.]aliyuncs[.]com
209oss[.]oss-cn-beijing[.]aliyuncs[.]com
21o9ss[.]oss-cn-shanghai[.]aliyuncs[.]com
ali288[.]oss-cn-hangzhou[.]aliyuncs[.]com
10mm[.]oss-cn-hangzhou[.]aliyuncs[.]com
101oss[.]oss-cn-beijing[.]aliyuncs[.]com
2o7cn[.]oss-cn-qingdao[.]aliyuncs[.]com
50oos[.]oss-cn-shanghai[.]aliyuncs[.]com
7sso7[.]oss-cn-beijing[.]aliyuncs[.]com
1010so[.]oss-cn-shanghai[.]aliyuncs[.]com
m11m[.]oss-cn-hangzhou[.]aliyuncs[.]com
o107ss[.]oss-cn-hangzhou[.]aliyuncs[.]com
04o0s[.]oss-cn-beijing[.]aliyuncs[.]com
11soso[.]oss-cn-hangzhou[.]aliyuncs[.]com
16sott[.]oss-cn-beijing[.]aliyuncs[.]com
sot18[.]oss-cn-shanghai[.]aliyuncs[.]com
22fifa[.]oss-cn-hangzhou[.]aliyuncs[.]com
23yoss[.]oss-cn-hangzhou[.]aliyuncs[.]com
9lost2[.]oss-cn-beijing[.]aliyuncs[.]com
22mm[.]oss-cn-hangzhou[.]aliyuncs[.]com
82ostt[.]oss-cn-shanghai[.]aliyuncs[.]com
30slot[.]oss-cn-hangzhou[.]aliyuncs[.]com
3tos1[.]oss-cn-beijing[.]aliyuncs[.]com
55osst[.]oss-cn-hangzhou[.]aliyuncs[.]com
oot11[.]oss-cn-shanghai[.]aliyuncs[.]com
7htoss[.]oss-cn-shanghai[.]aliyuncs[.]com

Appendix C – YARA

Detects all variants of the legacy, 64-bit, valid-signed Truesight driver, version 2.0.2.

import "pe"

rule truesight_driver_64bit_ver202
{
    meta:
        description = "Detects all variants of the legacy, 64-bit, valid-signed Truesight driver, version 2.0.2"
        author = "Jiri Vinopal @ Check Point Research"
    condition:
        // Detect PE
        uint16(0) == 0x5a4d and uint16(uint32(0x3c)) == 0x4550 and
        // Detect 64-bit Windows drivers
        uint16(uint32(0x3C) + 0x5c) == 0x0001 and uint16(uint32(0x3C) + 0x18) == 0x020b and
        // Detect InternalName "Truesight" and FileVersion "2.0.2"
        pe.version_info["InternalName"] == "Truesight" and pe.version_info["FileVersion"] == "2.0.2" and
        // Detect only signed drivers, not a real verification
        pe.number_of_signatures > 0 and for all i in (0..pe.number_of_signatures -1):
            (pe.signatures[i].verified)
}