Chasing the Silver Fox: Cat & Mouse in Kernel Shadows
Chasing the Silver Fox: Cat & Mouse in Kernel Shadows August 28, 2025 Highlights: Check Point Research (CPR) uncovered an ongoing in-the-wild campaign attributed to the Silver Fox APT which involves the abuse of a previously unknown vulnerable driver, amsdk.sys (WatchDog Antimalware, version 1.0.600). This driver, built on the Zemana Anti-Malware SDK, was Microsoft-signed, not listed in the Microsoft Vulnerable Driver Blocklist, and not detected by community projects like LOLDrivers. The attackers leveraged this unknown vulnerable driver to terminate protected processes (PP/PPL) associated with modern security solutions, allowing EDR/AV evasion on fully updated Windows 10 and 11 systems without triggering signature-based defenses. A dual-driver strategy was employed to ensure compatibility across Windows versions: a known vulnerableZemana driver for legacy systems, and the undetected WatchDog driver for modern environments. Both were embedded in a single self-contained loader which also included anti-analysis layers and the ValleyRAT downloader. Following CPR’s disclosure, the vendor released a patched driver (wamsdk.sys, version 1.1.100). Although we promptly reported that the patch did not fully mitigate the arbitrary process termination issue, the attackers quickly adapted and incorporated a modified version of the patched driver into the ongoing campaign. By flipping a single byte in the unauthenticated timestamp field, they preserved the driver’s valid Microsoft signature while generating a new file hash, effectively bypassing hash-based blocklists. This subtle yet efficient evasion technique mirrors patterns seen in earlier campaigns. The final payload delivered in all observed samples was ValleyRAT, a modular Remote Access Trojan attributed to the Silver Fox APT with infrastructure located in China. This campaign highlights a growing trend of weaponizing signed-but-vulnerable drivers to bypass endpoint protections and evade static detection. Introduction While Microsoft Windows has steadily strengthened its security model—through features like Protected Processes (PP/PPL) and enhanced driver verification—threat actors have adapted by shifting their tactics to exploit lower-level weaknesses that bypass these protections without triggering defenses. Among the most effective of these techniques is the abuse of vulnerable kernel-mode drivers, particularly those capable of arbitrary process termination. These drivers, when exploited, can disable or neutralize endpoint protection products, creating a clear path for malware deployment and persistence. In this publication, we present our findings on a recently detected in-the-wild (ITW) campaign that leverages such a driver-based evasion technique. At the center of this operation is the Silver Fox APT, which used an unknown-to-be-vulnerable WatchDog Antimalware driver, (amsdk.sys, version 1.0.600), to terminate processes associated with security solutions and facilitate the delivery of the ValleyRAT backdoor. This driver, although built upon the same SDK (Zemana Anti-Malware SDK) as previously known vulnerable components, was not classified as vulnerable, was signed by Microsoft, and not detected by Microsoft’s Vulnerable Driver Blocklist or community-driven sources like the LOLDrivers database. Our research builds upon the vulnerable driver detection methodology we published in 2024, where we identified thousands of at-risk drivers, including those used in security solutions. One of the previously reported drivers from that research, the WatchDog Antimalware driver, is now confirmed as abused ITW in this campaign. The attackers used this driver to disable core EDR (Endpoint Detection and Response) and antivirus protections before delivering their final payload: ValleyRAT, a modular backdoor attributed to Silver Fox APT, with infrastructure located in China. The campaign’s architecture is centered around all-in-one loader samples, which combine anti-analysis features, embedded drivers, EDR/AV killer logic, and the ValleyRAT downloader into a single binary. These loaders are tailored to function across both legacy and modern systems (Windows 7 – Windows 10/11), using two different drivers to ensure compatibility. While one of the drivers—a legacy Zemana-based driver (ZAM.exe)—is already known and blocked, the second driver used in modern environments was previously unknown and therefore remained undetected. We provide a comprehensive analysis of the observed campaign, detailing how the attackers: Exploited vulnerable drivers to terminate protected processes and bypass OS-level protections. Delivered multi-stage payloads using sophisticated loader construction. Leveraged a Microsoft-signed driver to evade trust-based detection mechanisms. Modified a patched version of the driver to avoid hash-based detection, without breaking digital signature validity. Ultimately delivered ValleyRAT as the final payload, providing remote access and control capabilities. In addition, we discuss the implications of signed-but-exploitable drivers and the broader risks posed by attackers leveraging modified versions of previously patched components. We reported all relevant findings to Microsoft’s MSRC and the Watchdog company, resulting in partial mitigations but the campaign continues to evolve. Background & Key Findings In late May 2025, we observed an ITW attack attributed to the Silver Fox APT group which targeted Windows systems with a custom loader designed to abuse kernel drivers to terminate security-related processes. The campaign marked a significant shift from using only known vulnerable drivers to deploying a previously unclassified, signed vulnerable driver that bypassed traditional detection mechanisms. The abuse focused on two drivers, both derived from the Zemana Anti-Malware SDK. The first, Advanced Malware Protection driver (ZAM.exe, version 3.0.0.000), is long known for its weaknesses and is blocked by the Microsoft Vulnerable Driver Blocklist. Its inclusion in the campaign served compatibility purposes for older systems like Windows 7. More critically, the attackers deployed WatchDog Antimalware driver (amsdk.sys, version 1.0.600), which despite sharing the same SDK foundation, was not publicly known to be vulnerable, not on any blocklist, and was signed by Microsoft—enabling it to be loaded even on fully updated Windows 10/11 systems. These drivers facilitated arbitrary process termination, including processes running under PP/PPL protection, which enabled the campaign’s custom EDR/AV killer logic to disable a wide range of security solutions. Each malware sample we analyzed was a self-contained all-in-one loader, composed of: Loader stub with an anti-analysis and persistence setup. Two embedded vulnerable drivers. Custom logic for terminating security processes based on a hardcoded list. A ValleyRAT downloader module configured to fetch and install the final payload. Throughout the short monitoring window, we observed the campaign evolve to include multiple variants of these loaders and driver combinations. Some samples integrated new drivers still not known to be vulnerable, suggesting an ongoing effort to evade detections and bypass updated defenses. Following our disclosure, Watchdog company released a patched version of the WatchDog Antimalware driver (wamsdk.sys, version 1.1.100). While this patch mitigated local privilege escalation (LPE) vectors, the updated driver still allowed arbitrary process termination, including protected processes, thereby failing to fully close the original attack vector. We disclosed this remaining issue to the vendor. Soon afterwards, we identified a new sample abusing a modified version of the patched driver, once again attributed to the same APT group. The attackers altered a single byte in the unauthenticated timestamp field of the driver’s Microsoft Authenticode signature. Because this field is not covered by the main signature digest, the driver remained validly signed and trusted by Windows, while presenting a new file hash and therefore bypassing hash-based blocklists. This subtle yet powerful evasion technique mirrors those seen in our earlier publication on large-scale legacy driver exploitation. The final payload across all samples was ValleyRAT, also known as “Winos”. This RAT offers a full set of capabilities for remote surveillance, command execution, and data exfiltration. Its use, along with infrastructure hosted in China and targeted security process lists aligned with East Asian vendors, confirms the campaign’s attribution to Silver Fox APT. This campaign demonstrates how threat actors are moving beyond known weaknesses to weaponize unknown, signed drivers—a blind spot for many defense mechanisms. The exploitation of a Microsoft-signed, previously unclassified vulnerable driver, combined with evasive techniques such as signature manipulation, represents a sophisticated and evolving threat. Despite some mitigations by the vendor, the attacker’s ability to quickly adapt—evidenced by the use of altered but validly signed driver variants—highlights the need for proactive, behavior-based detection methods and deeper scrutiny of signed kernel-mode drivers. Infrastructure & Victimology All detected command-and-control (C2) servers used in the final stage of the attack, specifically for deploying the ValleyRAT backdoor, are hosted within China, often leveraging public cloud or web services. The victimology suggests a globally distributed targeting pattern. In most observed cases, the malware is delivered via .rar archives containing either a single executable (.exe) or a dynamic-link library (.dll) that is side-loaded through a legitimate application. The exact infection vector remains unidentified. As detailed in Appendix A – List of Processes to be Terminated, the malware is configured to terminate processes associated with security and antivirus solutions commonly used in China. Combined with the geographic location of the C2 infrastructure, this strongly suggests that the primary targets are located in Asia, particularly within China. Technical Analysis: All-In-One Loader All samples we analyzed were deployed as self-contained, all-in-one loaders. The loader is composed of several parts, each with a specific role: The loader stub – Implements anti-analysis techniques and sets up persistence. Two embedded vulnerable drivers – Abused for arbitrary process termination. EDR/AV killer logic – Targets and disables security processes. ValleyRAT downloader module and configuration – Fetches and executes the final payload. In most cases (~75 % of detected samples) these loaders are not packed. Occasionally, however, the attackers use unaltered versions of common public packers, such as UPX. One such example is a 64-bit, UPX-packed PE with the internal name Runtime Broker. The sample retains its original compilation timestamp, 2025-06-03 06:38:30 UTC, roughly two weeks after we first observed the campaign in the wild. Anti-analysis Techniques Upon execution, the sample performs a few common anti-analysis checks, such as Anti-VM (detection of virtual environments), Anti-Sandbox (detection of execution within a sandbox), hypervisor detection, and others. If any of these checks fail, the execution is aborted, and a fake system error message is displayed. The virtual environment and hypervisor detection routines include a defined exclusion that allows execution to continue if the computer name is set to any of the following values: DESKTOP-T3N3M3Q, DESKTOP-03AMF90, or WIN-VMHH95J6C26. We believe this exclusion is intended to prevent execution from being aborted on systems used by the attackers during malware development. We observed that some of the detected samples include an additional anti-analysis check using the public service http[://]ip-api[.]com/json. This service is used to retrieve information about the infected machine’s public IP address, including the ISP (Internet Service Provider) and ORG (Organization) fields. If the ISP or ORG values match any entry from a predefined list (shown in the table below), the process is terminated, and a fake error message, “The program does not support your configuration.”, is displayed. Persistence Settings To establish persistence, the loader creates a folder named RunTime under the system path C:\Program Files\RunTime. The all-in-one loader sample and the appropriate version of the vulnerable driver—selected based on the infected system’s Windows OS version—are dropped into this folder with the filenames RuntimeBroker.exe and Amsdk_Service.sys, respectively. Subsequently, specific services are created to ensure the dropped files are executed automatically on system startup. The service named Termaintor is responsible for maintaining persistence for the previously dropped copy of the all-in-one loader (RuntimeBroker.exe). The second created service, Amsdk_Service, is simply a configured registry key required to load the dropped vulnerable driver. We believe the name Termaintor is a deliberate typographical error and also a possible indication that the EDR/AV killer logic was inspired by the publicly available PoC—a tool named “Terminator” that abuses the known vulnerable Zemana Anti-Malware driver. Embedded Payloads While most globally defined strings in the analyzed sample are simply Base64-encoded, the embedded payloads use a combination of hexadecimal encoding and Base64. These payloads are embedded directly as encoded byte strings within the .rdata section of the binary. Two of the encoded payloads are different vulnerable drivers used by the EDR/AV killer logic. Only one of them is deployed on the infected system, depending on the detected Windows version. The older driver is a 64-bit, validly signed Advanced Malware Protection driver, ZAM.exe, version 3.0.0.000. This driver is already known to be vulnerable and is detected by both LOLDrivers and the Microsoft Vulnerable Driver Blocklist. It is used only if the infected system is running an older version of Windows (e.g., Windows 7). The newer driver is a 64-bit, validly signed WatchDog Antimalware driver, amsdk.sys, version 1.0.600. This driver was not previously known to be vulnerable and bypasses both LOLDrivers and Microsoft’s blocklist. It is used only if the infected system is running a modern version of Windows (e.g., Windows 10 or 11). The final embedded payload is the encoded ValleyRAT downloader module, including its hardcoded configuration. ValleyRAT Downloader As previously mentioned, the ValleyRAT downloader stage is embedded within the all-in-one loaders in an encoded format combining Base64 and hexadecimal string. Once decoded, it results in a 64-bit, UPX-packed DLL that is converted into shellcode. This shellcode includes a stub responsible for in-memory reflective loading and is injected into an already running process, typically an instance of svchost.exe. The internal name of the DLL, 上线模块.dll (translated as “Online module.dll”), is preserved in the Export Directory, along with three exported functions: load, run, and a second run. The exported functions provide alternative entry points for executing and loading the DLL, such as using a custom-supplied configuration instead of the hardcoded one, while ultimately triggering the same core logic as the DllMain function. The C2 servers are defined in the embedded configuration. Notably, both the IP addresses and ports are stored in reverse order. For example: 156[.]234[.]58[.]194:52110 and 156[.]234[.]58[.]194:52111. The communication between the ValleyRAT downloader and the C2 servers is encrypted using a simple XOR cipher with the key 363636003797e4383a36. After decrypting the traffic, we found that the downloaded content includes the final payload: the ValleyRAT backdoor (also known as Winos). Technical Analysis: EDR/AV Killer The EDR/AV killer routine is embedded directly within the all-in-one loaders. Initially, depending on the Windows version of the infected system, one of the two embedded vulnerable drivers is dropped. As both drivers are based on the Zemana Anti-Malware SDK, the exploitation logic remains the same i.e. abusing their ability to terminate arbitrary processes. The figure below shows the routine responsible for creating the service required to load the vulnerable driver. Specifically, the service Amsdk_Service (of type SERVICE_KERNEL_DRIVER) is created using the Windows API functions RegCreateKeyW and RegSetValueExW, followed by a call to the NT API NtLoadDriver to initiate the driver loading process. Once the driver is loaded, its created device amsdk is opened to enable communication with the driver, which is later used in the main EDR/AV killing routine (KillEDRMain function). The core EDR/AV killer logic, implemented in the KillEDRMain function, iterates over a Base64-encoded list of target processes to be terminated. This list, defined as TERMINATE_PROCESS_LIST, contains 192 unique process names (see Appendix A – List of Processes to be Terminated). When any of the listed processes is found running on the system, it is terminated by issuing a sequence of IOCTLs, 0x80002010 (IOCTL_REGISTER_PROCESS) followed by 0x80002048 (IOCTL_TERMINATE_PROCESS), via the Windows API function DeviceIoControl that communicates directly with the driver’s device. We provide further details about the drivers abused in this campaign, including descriptions of the vulnerabilities, their impact, and example PoC code, in the following section. Technical Analysis: New Vulnerable Driver While the all-in-one loaders described in the previous section can abuse two versions of vulnerable drivers (depending on the targeted Windows system version), both are based on the Zemana Anti-Malware SDK. In this section, we shift our focus to the one not previously known to be vulnerable, despite its exploitation and impact being almost identical to the known variant. As mentioned earlier, the abused driver, WatchDog Antimalware driver version 1.0.600, is a 64-bit, validly signed Windows kernel device driver. It is still actively used and was originally part of the Watchdog Anti-Malware product. Even though the internal name is amsdk.sys, the original PDB path still references zam64.pdb, suggesting reuse of the Zemana Anti-Malware SDK. We confirmed that the WatchDog Antimalware driver is indeed based on the Zemana Anti-Malware SDK through a detailed inspection of its code. Some parts of the code (not just the metadata of the compiled PE) were changed by the WatchDog Antimalware developers, particularly those responsible for the driver’s device creation. These changes were likely made in response to the well-known vulnerabilities affecting drivers derived from the Zemana Anti-Malware SDK. In fact, there are publicly available PoCs (for over two years) exploiting “Zemana” drivers as EDR/AV killing tools, such as Terminator. As this driver is signed by Microsoft (Microsoft Windows Hardware Compatibility Publisher), it can be loaded and used even on the latest fully updated Windows 10/11 systems. In addition, due to the diversity of the WatchDog Antimalware driver, common detection and prevention mechanisms, such as LOLDrivers and the Microsoft Vulnerable Driver Blocklist which cover “Zemana” drivers, are ineffective against the WatchDog Antimalware driver. As a result, there is no obstacle to its use. Despite modifications to the codebase intended to mitigate known vulnerabilities in “Zemana” drivers, the WatchDog Antimalware driver remains vulnerable with similar impacts, including LPE, unrestricted raw disk read/write access, arbitrary process termination, and more. Vulnerability Description There are multiple vulnerabilities affecting the WatchDog Antimalware driver. First, the driver can terminate arbitrary processes without verifying whether the process is running as protected (PP/PPL), which is common for Anti-Malware services. As a result, it is a convenient candidate for the BYOVD (Bring Your Own Vulnerable Driver) technique where it is abused as an EDR/AV killer. BYOVD attacks are not usually considered vulnerabilities in the traditional sense, as the attacker must first deploy and load the vulnerable driver on the targeted system. These are procedures that require Administrator privileges (elevation from Administrator to System does not cross a security boundary). However, if the driver is already present on the targeted system (e.g., as part of the Watchdog Anti-Malware product), even a non-privileged user can abuse it to disable security solutions. A more critical driver vulnerability is its ability to cross the security boundary from a non-privileged user to System, resulting directly in LPE (Local Privilege Escalation). The root cause lies in the routine responsible for the driver’s device creation. IoCreateDeviceSecure, a more secure kernel function than IoCreateDevice because it lets you specify a DACL, is used. A strong DACL is set on the created device via the SDDL string D:P(A;;GA;;;SY)(A;;GA;;;BA), granting access only to System and Administrators, but the DeviceCharacteristics do not explicitly include the FILE_DEVICE_SECURE_OPEN flag. Without this flag as part of the device characteristics, the strong DACL does not apply to the entire device namespace, allowing even non-privileged users to communicate with the device. Every device has its own namespace, where names in the namespace are paths that begin with the device´s name. For a device named \Device\DeviceName, its namespace consists of any name with the form \Device\DeviceName\anyfile. The lack of the FILE_DEVICE_SECURE_OPEN flag can be abused to obtain a full access handle to the device itself, even by a non-privileged user, because the strong DACL is not propagated to the namespace, e.g., opening a handle to \Device\DeviceName\anyfile will return a handle for the device itself \Device\DeviceName. Below, we can see the driver´s initialization routine, where the device object is created with a strong DACL, but without the FILE_DEVICE_SECURE_OPEN characteristics flag. The converted DACL, part of the SDDL string: By combining unrestricted access to the driver’s device with its ability to perform privileged operations, all of the previously described vulnerabilities can be exploited. These capabilities of the WatchDog Antimalware driver are triggered by issuing specific IOCTLs during communication with the device. The most critical examples are summarized in the table below: Below is a simplified view of the DispatchDeviceControl callback function, which is responsible for handling IOCTL requests and executing the corresponding routines. The arbitrary process termination capability, abused by the threat actor in the campaign we describe here, is triggered via the IOCTL 0x80002048 (IOCTL_TERMINATE_PROCESS), which directly invokes the TerminateProcessById function. Notably, before this action, the attacker-controlled process must first register itself (be added to the allowlist to bypass mitigation) by issuing IOCTL 0x80002010 (IOCTL_REGISTER_PROCESS). The TerminateProcessById function blocks termination only if the target process is marked as critical (to prevent a system crash). However, it does not handle protected processes (PP/PPL), which are typically used by anti-malware services. As a result, security solution processes can be freely terminated. The PoC demonstrating the driver’s arbitrary process termination capability is relatively simple and the exploit can be implemented as follows: #define IOCTL_REGISTER_PROCESS 0x80002010 #define IOCTL_TERMINATE_PROCESS 0x80002048 // Loading the amsdk.sys driver DWORD pidTerminate = 1337; // Pid of process to be killed, PP/PPL processes possible DWORD pidRegister = GetCurrentProcessId(); HANDLE hDevice = CreateFileA("\\\\.\\amsdk\\anyfile", GENERIC_READ | GENERIC_WRITE, NULL, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); DeviceIoControl(hDevice, IOCTL_REGISTER_PROCESS, &pidRegister, sizeof(pidRegister), NULL, 0, NULL, NULL); DeviceIoControl(hDevice, IOCTL_TERMINATE_PROCESS, &pidTerminate, sizeof(pidTerminate), NULL, 0, NULL, NULL); The core of the vulnerability in the WatchDog Antimalware driver is not complex and can easily be addressed. Specifying the FILE_DEVICE_SECURE_OPEN device characteristic ensures the propagation of the strong DACL to the whole device namespace and prevents access by non-privileged users. An additional check to verify if the targeted process to be terminated is running as protected (PP/PPL) will mitigate the possibility of disabling Anti-Malware solutions. Final Stages: The ValleyRAT Backdoor All the samples we analyzed (see Appendix B – IOCs) deployed the well-known ValleyRAT backdoor (also known as Winos) as the final stage. This malware strain is strongly attributed to, and associated with, the well-known APT group Silver Fox. Similar to the ValleyRAT downloader, the deployed ValleyRAT backdoor is delivered as a 64-bit DLL converted to shellcode (the DLL is preceded by stub shellcode responsible for in-memory reflective loading). The internal name 登录模块.dll (translated as “LoginModule.dll”) of this DLL is preserved in the Export Directory, along with a single exported function, run. This exported function is almost identical to DllMain, triggers the same main logic, and likely serves as an alternate execution mechanism. One of the first executed functions to avoid detection is a callback invoked via the Windows API EnumWindows. The callback function, EnumFunc, is responsible for detecting processes with window titles associated with analysis tools, primarily those used for network analysis, commonly found in sandboxes or malware labs. If any of the defined window titles is detected, execution is delayed by a 20-second sleep, and the enumeration continues until none of the tools are detected. As previously described, the attackers abuse two vulnerable drivers to terminate processes associated with security solutions. While the older one—Advanced Malware Protection driver, ZAM.exe, version 3.0.0.000—was classified as known-vulnerable by the Microsoft Vulnerable Driver Blocklist and by other common detection mechanisms such as those implemented by the LOLDrivers project, the newer one—WatchDog Antimalware driver, amsdk.sys, version 1.0.600—bypasses all of them. As we saw, the all-in-one loaders used in this campaign are tailored to support not only the latest versions of Windows OS (Windows 10/11) but also older ones (e.g., Windows 7), meaning even legacy systems remain at risk. The Microsoft Vulnerable Driver Blocklist uses advanced detection mechanisms, beyond simple hash-based checks, to protect against known vulnerable drivers. As it is built into the Windows OS, we reported the issue to MSRC. As the primary risk in this detected in-the-wild campaign stems from the previously unknown vulnerable WatchDog Antimalware driver, we reported the campaign and the driver abuse to its vendor, the Watchdog company. As a result, the vendor released a patch: WatchDog Antimalware driver, wamsdk.sys, version 1.1.100. All Watchdog products are now deployed with this updated version of the driver. We confirmed that the new driver mitigates the LPE risk by enforcing a strong DACL (allowing access only for SYSTEM and Administrator accounts) and by setting the FILE_DEVICE_SECURE_OPEN device characteristic, which ensures the propagation of the DACL across the entire device namespace. Unfortunately, it does not mitigate the arbitrary process termination issue. It still lacks a check for whether the targeted process is running as protected (PP/PPL). As a result, this driver can still be abused similarly to how it was used in the described campaign to disable anti-malware solutions. We reported this to the vendor. This sample remains associated with the same campaign attributed to the Silver Fox APT, once again deploying the ValleyRAT backdoor as the final stage. We reported this new finding to the Watchdog company. The patched driver (WatchDog Antimalware Driver, wamsdk.sys, version 1.1.100) is abused in a way where the attackers create a modified variant by altering just a single byte within the PE binary’s WIN_CERTIFICATE structure—specifically in the unauthenticated attributes of the embedded Microsoft Authenticode signature. This byte is part of the RFC 3161 timestamp (counter-signature) applied by Microsoft’s time-stamping authority. Because unauthenticated attributes are not covered by the primary signature’s digest, this change does not affect the validity of the embedded Microsoft signature, and does not break the chain of trust. As a result, Windows continues to treat the driver as validly signed and trusted, even on the latest versions. However, the file’s overall hash (e.g., SHA-256) is now different, which allows attackers to create a modified, uniquely hashed but still validly signed version of the original driver. 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. As we cannot ensure that all the vulnerable drivers abused in this campaign will be added to the Microsoft Vulnerable Driver Blocklist, we provided YARA rules (see Appendix C – YARA) to detect them and recommend monitoring and preventing their abuse. Conclusion We revealed a sophisticated campaign, attributed to the Silver Fox APT group, that exploits vulnerable signed drivers to bypass security protections and deploy the ValleyRAT backdoor. By abusing two vulnerable drivers, one previously known and one newly identified, attackers achieved arbitrary process termination, allowing them to disable anti-malware solutions and maintain stealth across multiple Windows versions, including the latest Windows 10 and 11. The newly identified abuse of the WatchDog Antimalware driver demonstrates that even signed and seemingly trusted drivers can contain critical vulnerabilities. The attackers’ technique of modifying unauthenticated attributes within the driver’s digital signature to evade detection while preserving trustworthiness exposes the limitations of relying solely on hash-based or signature-based detection methods. Our findings highlight the need for layered defense strategies, encompassing not only timely application of Microsoft’s Vulnerable Driver Blocklist and custom detection rules like YARA signatures, but also robust behavior-based detection capable of heuristically identifying and blocking such threats. These combined measures are vital to detect and prevent the abuse of vulnerable drivers before attackers can escalate privileges or disable security software. Our final point is that our research reinforces the need for ongoing efforts of security vendors and users to stay vigilant against the emerging abuse of legitimate drivers. Proactive identification, reporting, and patching of these vulnerabilities are critical to strengthening Windows systems against evolving threats leveraging Bring Your Own Vulnerable Driver (BYOVD) techniques. 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. Detects 64-bit, valid-signed WatchDog Antimalware driver, amsdk.sys, version 1.0.600 (bypassing LOLDrivers and Microsoft Vulnerable Driver Blocklist): import "pe" rule watchdog_antimalware_driver_64bit_ver10600 { meta: description = "Detects 64-bit, valid-signed WatchDog Antimalware driver, version 1.0.600" author = "Jiri Vinopal @ Check Point Research" hash = "12b3d8bc5cc1ea6e2acd741d8a80f56cf2a0a7ebfa0998e3f0743fcf83fabb9e" 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 OriginalFilename "amsdk.sys" and FileVersion "1.0.600" pe.version_info["OriginalFilename"] == "amsdk.sys" and pe.version_info["FileVersion"] == "1.0.600" 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) } Detects 64-bit, valid-signed WatchDog Antimalware Driver, wamsdk.sys, version 1.1.100 (bypassing LOLDrivers and Microsoft Vulnerable Driver Blocklist): import "pe" rule watchdog_antimalware_driver_64bit_ver11100 { meta: description = "Detects 64-bit, valid-signed WatchDog Antimalware driver, version 1.1.100" author = "Jiri Vinopal @ Check Point Research" hash = "5af1dae21425dda8311a2044209c308525135e1733eeff5dd20649946c6e054c" hash = "0be8483c2ea42f1ce4c90e84ac474a4e7017bc6d682e06f96dc1e31922a07b10" 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 OriginalFilename "wamsdk.sys" and FileVersion "1.1.100" pe.version_info["OriginalFilename"] == "wamsdk.sys" and pe.version_info["FileVersion"] == "1.1.100" 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) } Detects 64-bit, valid-signed Advanced Malware Protection driver, ZAM.exe, version 3.0.0.000 (detected by LOLDrivers and Microsoft Vulnerable Driver Blocklist): import "pe" rule zam_advanced_malware_protection_driver_64bit_ver300000 { meta: description = "Detects 64-bit, valid-signed Advanced Malware Protection driver, version 3.0.0.000" author = "Jiri Vinopal @ Check Point Research" hash = "9c394dcab9f711e2bf585edf0d22d2210843885917d409ee56f22a4c24ad225e" 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 OriginalFilename "ZAM.exe" and FileVersion "3.0.0.000" pe.version_info["OriginalFilename"] == "ZAM.exe" and pe.version_info["FileVersion"] == "3.0.0.000" 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) } “The Turkish Rat” Evolved Adwind in a Massive Ongoing Phishing Campaign Check Point Research Publications August 11, 2017 “The Next WannaCry” Vulnerability is Here Check Point Research Publications March 12, 2026 “Handala Hack” – Unveiling Group’s Modus Operandi SUBSCRIBE TO CYBER INTELLIGENCE REPORTS We value your privacy! BFSI uses cookies on this site. We use cookies to enable faster and easier experience for you. By continuing to visit this website you agree to our use of cookies.
research.checkpoint.comAug 28, 2025extracted