Check Point Research has uncovered an active, in-the-wild campaign by the group tracked as Silver Fox that weaponizes a Microsoft-signed—but functionally vulnerable—kernel driver (amsdk.sys / WatchDog Antimalware) to terminate protected security processes and deliver the ValleyRAT backdoor across modern Windows systems.
Windows has steadily hardened its kernel and driver model—introducing Protected Processes (PP/PPL), Kernel Mode Code Integrity (KMCI), Hypervisor‑protected Code Integrity (HVCI), and a Microsoft Vulnerable Driver Blocklist to limit the ability of legacy or flawed drivers to be abused. Despite these measures, adversaries are increasingly adopting BYOVD (Bring Your Own Vulnerable Driver) tactics: loading legitimate, signed drivers that expose privileged operations and abusing their trusted status to neutralize endpoint defenses.
Check Point’s investigation describes a compact, cross‑version loader that embeds two Zemana‑SDK‑derived drivers: a known legacy vulnerable Zemana driver for older Windows (ZAM.exe) and a previously unclassified WatchDog Antimalware driver (amsdk.sys, v1.0.600) used for modern Windows 10/11 targets. The loader uses the driver device interface to register a malicious process and then invoke an IOCTL that triggers arbitrary process termination, including processes marked as protected (PP/PPL). After blinding endpoint protections, the loader decodes and executes a ValleyRAT downloader which ultimately fetches the ValleyRAT backdoor. Multiple independent telemetry and public analyses corroborate ValleyRAT’s role in related Chinese‑language campaigns and the group now tracked as Silver Fox; vendors such as Fortinet and industry reporting connect ValleyRAT (aka “Winos”) with modular remote‑access capabilities and similar multi‑stage delivery chains. (proofpoint.com)
[*]Isolate and collect: If you detect suspected infection, isolate the host, collect kernel and memory artifacts, gather EDR logs (DeviceIoControl activity, service creations), and preserve the suspicious driver files for analysis. Kernel‑level compromises are often difficult to fully remediate without reimaging. [/LIST]
Windows has steadily hardened its kernel and driver model—introducing Protected Processes (PP/PPL), Kernel Mode Code Integrity (KMCI), Hypervisor‑protected Code Integrity (HVCI), and a Microsoft Vulnerable Driver Blocklist to limit the ability of legacy or flawed drivers to be abused. Despite these measures, adversaries are increasingly adopting BYOVD (Bring Your Own Vulnerable Driver) tactics: loading legitimate, signed drivers that expose privileged operations and abusing their trusted status to neutralize endpoint defenses.Check Point’s investigation describes a compact, cross‑version loader that embeds two Zemana‑SDK‑derived drivers: a known legacy vulnerable Zemana driver for older Windows (ZAM.exe) and a previously unclassified WatchDog Antimalware driver (amsdk.sys, v1.0.600) used for modern Windows 10/11 targets. The loader uses the driver device interface to register a malicious process and then invoke an IOCTL that triggers arbitrary process termination, including processes marked as protected (PP/PPL). After blinding endpoint protections, the loader decodes and executes a ValleyRAT downloader which ultimately fetches the ValleyRAT backdoor. Multiple independent telemetry and public analyses corroborate ValleyRAT’s role in related Chinese‑language campaigns and the group now tracked as Silver Fox; vendors such as Fortinet and industry reporting connect ValleyRAT (aka “Winos”) with modular remote‑access capabilities and similar multi‑stage delivery chains. (proofpoint.com)
What was found (high‑impact findings)
- A Microsoft‑signed driver, amsdk.sys (WatchDog Antimalware v1.0.600), built on the Zemana Anti‑Malware SDK, is abused in the wild to perform privileged operations (arbitrary process termination, raw disk read/write, and LPE primitives) and was not present in the Microsoft Vulnerable Driver Blocklist or community blocklists at the time of discovery.
- The campaign uses a dual‑driver strategy: a legacy Zemana driver for older OS versions and the WatchDog driver for modern Windows 10/11 hosts—both embedded in a single all‑in‑one loader that includes anti‑analysis checks, persistence, the EDR/AV killer logic, and a ValleyRAT downloader.
- After disclosure, the vendor released a patched driver wamsdk.sys (v1.1.100). The vendor patch addressed some Local Privilege Escalation (LPE) vectors (e.g., hardening device DACL propagation), but initially did not block arbitrary termination of PP/PPL processes—leaving the core abuse vector intact. The adversary subsequently adapted by producing a modified copy of the patched driver with a single‑byte change in the unauthenticated timestamp (countersignature) area—preserving Authenticode validity while altering the file hash to bypass hash‑based blocklists. (research.checkpoint.com, research.checkpoint.com, research.checkpoint.com, research.checkpoint.com, research.checkpoint.com, proofpoint.com, infosecurity-magazine.com)
- Microsoft’s documentation on the Vulnerable Driver Blocklist explains the blocklist’s role, its update cadence, and limitations—most importantly that the blocklist may not include every vulnerable driver and that it is updated on a schedule rather than continuously. This explains how a newly abused but previously unclassified driver can be weaponized before it appears on blocklists.
- Technical background on Authenticode timestamping and countersignatures (PKCS#7 unsigned/unauthenticated attributes) clarifies why modifying the timestamp/countersignature can change the PE hash without invalidating the main signature: the countersignature is an unauthenticated attribute relative to the original SignerInfo, and some timestamp elements are not included in the digest used for signature validation. This is not a novel cryptographic hole but an operational quirk defenders must account for. (security.stackexchange.com)
Attribution and limitations
Attribution to Silver Fox is based on:- Use of ValleyRAT (a tool previously associated with Silver Fox / Winos).
- C2 hosting patterns (multiple observed servers in China and hosting providers commonly used by Chinese‑language campaigns).
- Targeting and process termination lists focusing on East Asian / Chinese security products.
[*]Isolate and collect: If you detect suspected infection, isolate the host, collect kernel and memory artifacts, gather EDR logs (DeviceIoControl activity, service creations), and preserve the suspicious driver files for analysis. Kernel‑level compromises are often difficult to fully remediate without reimaging. [/LIST]
Medium‑term hardening
- Enforce strict driver installation policies: limit who can install drivers via group policy, WDAC/AppLocker, and restrict local administrative rights. Reduce the set of accounts that can write to
%windir%\system32\drivers. - Deploy behavior / telemetry detection: signature‑agnostic telemetry that flags unusual kernel device usage, abrupt security service termination, or cross‑process injection sequences will detect variants and signature‑manipulation techniques better than hash lists alone. Configure EDR to monitor for processes issuing DeviceIoControl toward uncommon devices.
- Monitor driver signing anomalies: detect legitimately signed drivers whose PE checksum, WIN_CERTIFICATE padding, or timestamp countersignature differ from expected vendor builds. Don’t rely solely on signature presence; track provenance, expected file hashes, and certificate chains. Check Point’s research and earlier analyses demonstrate attackers can produce many validly signed variants by changing non‑hashed fields. (blog.talosintelligence.com)
Long‑term strategy
- Move from reactive hash‑blocking to proactive allow‑listing: explicit allow‑lists for kernel drivers (and user binaries) reduce risk far more effectively than ad‑hoc blocklists. Use App Control for Business to enforce whitelists and ensure only approved signed drivers are permitted.
- Vendor engagement and secure lifecycle: push vendors to adopt secure driver development practices (set FILE_DEVICE_SECURE_OPEN, enforce strict DACLs on device objects, validate PP/PPL checks in sensitive IOCTLs) and to proactively deprecate SDKs with high abuse potential. Check Point’s reporting to the driver vendor led to a patched release—this shows responsible disclosure works but also reveals how patching may not be sufficient if core logic remains exploitable.
Red flags and detection recipes (concise)
- Processes invoking CreateFile/DeviceIoControl on
\.\amsdkor\.\zam*device names. - Calls to IOCTL codes such as 0x80002010 (register) followed by 0x80002048 (terminate).
- Sudden termination of known EDR/AV service processes (MsMpEng.exe, SecurityHealthHost.exe, vendor service names on the China‑focused list) immediately preceding network connections to strange C2 IPs.
- Reflective DLL loading or shellcode execution with XOR/Xor‑like simple ciphers and reverse‑stored IP
ort entries (observed in ValleyRAT downloader configs). (research.checkpoint.com)
Strengths and weaknesses of the response landscape
Strengths:- Microsoft’s Vulnerable Driver Blocklist and App Control policies provide a systemic mechanism to stop many classes of BYOVD; enabling HVCI and applying the blocklist generally raises the baseline.
- Vendor and community research (Check Point, Fortinet, Forescout, others) is actively tracking these campaigns and publishing actionable YARA/IoC material that security teams can operationalize quickly. (research.checkpoint.com, research.checkpoint.com, research.checkpoint.com, research.checkpoint.com, research.checkpoint.com, learn.microsoft.com)
Source: Check Point Software Chasing the Silver Fox: Cat & Mouse in Kernel Shadows - Check Point Research