Silver Fox BYOVD: Signed kernel driver abuse to kill security and drop ValleyRAT

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.

Background / Overview​

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. (fortinet.com, 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, learn.microsoft.com)
• The campaign culminates in deployment of ValleyRAT, a modular RAT heavily used in Chinese‑language campaigns and attributed to Silver Fox by infrastructure, targeting patterns, and prior reporting. ValleyRAT’s downloader and payload stages use reflective loading and in‑memory execution to reduce on‑disk traces. (research.checkpoint.com, fortinet.com)

These findings together show a clear operator tradecraft: combine a signed, powerful kernel component with compact loader engineering and signature‑aware modification techniques to evade both trust‑based and simple hash‑based controls.

---

Technical anatomy: how the attack works​

Loader and staging​

The attack is delivered as a compact all‑in‑one PE (often UPX‑packed). On execution the sample performs anti‑analysis and environment checks (VM/sandbox/hypervisor detection, ISP/org checks via ip‑api, and a whitelist of developer VM hostnames that allow execution to proceed). If the checks pass, the loader creates a persistent folder (C:\Program Files\RunTime), drops a runtime binary (RuntimeBroker.exe) and an embedded driver (Amsdk_Service.sys), creates two services—Termaintor for loader persistence and Amsdk_Service to load the driver—and then proceeds to load the embedded vulnerable driver appropriate to the OS.

Abusing the driver: device, registration, and termination​

Both Zemana‑SDK drivers expose a device interface (e.g., .\amsdk). The loader opens the device and issues a sequence of IOCTLs to:

• Register the malicious process with the driver (IOCTL_REGISTER_PROCESS / 0x80002010).
• Issue an IOCTL to terminate arbitrary processes by PID (IOCTL_TERMINATE_PROCESS / 0x80002048).

The driver accepts a register request and subsequently allows the registered handle to request termination of any process, including Protected Process Light (PPL) / PP processes used by modern anti‑malware products; the driver’s termination routine did not verify PP/PPL flags. This is the practical mechanism used to kill security services and blind EDR/AV before final payload retrieval. Check Point includes a straightforward PoC demonstrating these operations.

ValleyRAT fetch and in‑memory loading​

Following EDR/AV neutralization, an embedded downloader (a UPX packed DLL converted to shellcode) is reflectively loaded into a target process (typically svchost.exe). The downloader contains an obfuscated config (C2 servers often hosted in China) and uses a simple XOR cipher for communications. The decrypted payload is the ValleyRAT DLL, loaded and executed in memory, giving the operators persistent remote access and plugin capability. Fortinet and others have observed the same multi‑stage reflective loading pattern in ValleyRAT campaigns. (research.checkpoint.com, fortinet.com)

---

Why this combination is dangerous​

• Signed driver trust bypasses allow‑lists: Because amsdk.sys is signed by “Microsoft Windows Hardware Compatibility Publisher” (i.e., an accepted signing path), it can be loaded by Windows even on fully patched Windows 10/11 hosts—unless blocked by the Microsoft Vulnerable Driver Blocklist or other enterprise policies. The signature gives reputation and loading privileges that static allow‑lists often trust. (research.checkpoint.com, learn.microsoft.com)
• Process termination of PP/PPL: Terminating processes that are intentionally protected by the OS nullifies a fundamental defensive boundary between standard unprivileged processes and EDR/AV kernel components. Once those protections are gone, in‑memory delivery and execution become trivial and noiseless.
• Signature‑preserving hash evasion: By changing parts of the Win_CERTIFICATE / timestamp countersignature or noncharged PE fields that are not covered by the signed digest, attackers create a new SHA‑256 hash while preserving Authenticode validity. That defeats blunt hash‑based blocklists and forces defenders to rely on behavior, metadata, or allow‑list logic rather than file hashes alone. This technique has been previously observed and explicitly described in Check Point’s prior work on legacy drivers and by other research groups. (research.checkpoint.com, blog.talosintelligence.com)
• Cross‑version compatibility: Bundling both legacy (Zemana/ZAM) and modern (WatchDog/amsdk) drivers in a single loader maximizes the campaign’s reach—Windows 7 through the latest Windows 10/11—making one sample relevant across diverse estates.

---

Corroboration and independent context​

Check Point’s technical narrative is corroborated by multiple independent outlets and vendor research:

• Fortinet’s write‑up on ValleyRAT documents the same reflective loader and staged delivery behavior that Check Point observed, and attributes ValleyRAT to the same actor set consistent with Silver Fox reporting.
• Industry reporting and vendor telemetry (Proofpoint, Forescout, Infosecurity) confirm ValleyRAT’s history, China‑hosted C2 infrastructure, and ties to the actor cluster tracked as Silver Fox, including prior use of similar TTPs (DLL sideloading, process injection, reflective loading). (proofpoint.com, industrialcyber.co, 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. (learn.microsoft.com, 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.

These signals are strong but not definitive on their own. Attribution in cyber operations is inherently probabilistic; infrastructure or tooling overlaps can mislead. Check Point and other vendors present a defensible linkage based on TTPs and infrastructure, but defenders should treat attribution as an operational context rather than an immutable fact. (research.checkpoint.com, industrialcyber.co)

---

Detection, mitigation, and remediation (practical guidance)​

This campaign exposes practical gaps in the common defensive models. Defenders should adopt a layered response that combines policy hardening, detection hunts, and vendor/patch action.

Immediate steps (24–72 hours)​

• Inventory and block: Query endpoints for suspicious driver files—look for amsdk.sys, wamsdk.sys, ZAM.exe, and the file hashes provided by vendors where available. If any of these drivers are present and not required, remove and quarantine them. Note: driver removal may require reboots and can affect legitimate products. (research.checkpoint.com, learn.microsoft.com)
• Apply Microsoft controls: Ensure the Microsoft Vulnerable Driver Blocklist is applied centrally (App Control for Business or the Windows Update optional blocklist refresh), and enable the ASR rule Block abuse of exploited vulnerable signed drivers. Validate HVCI/Memory Integrity where hardware permits.
• Hunt for IOCTL abuse and unusual DeviceIoControl patterns: Add EDR hunts for non‑system processes opening device interfaces like \.\amsdk or calling DeviceIoControl with unusual control codes; flag processes that call DeviceIoControl repeatedly or register with kernel devices then perform privilege operations. Correlate with sudden stoppage of security services and unusual svchost or RuntimeBroker process activity.
• Look for reflective loading and in‑memory DLL patterns: Hunt for processes performing reflective DLL loads, unusual memory protections changes (RWX/execute mapping), and short lived child processes that inject into svchost.exe. ValleyRAT stages use reflective loading and simple XOR obfuscation; look for deobfuscation patterns or registry‑stored shellcode. (fortinet.com, research.checkpoint.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.

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. (research.checkpoint.com, 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 \.\amsdk or \.\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 IPort entries (observed in ValleyRAT downloader configs). (fortinet.com, 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, fortinet.com)

Weaknesses / risks:

• The trust model around code signing and Authenticode timestamps can be manipulated in ways that preserve signature validity while changing file hashes—rendering hash‑based defenses brittle. Attackers can produce many unique, validly‑signed variants without breaking OS signature checks. (research.checkpoint.com, learn.microsoft.com)
• Blocklists are updated periodically—not continuously—and newly abused drivers can be operational for weeks before being added, especially if a vendor patch isn’t released or is incomplete. Check Point’s timeline shows how quickly operators adapt to partial patches. (research.checkpoint.com, bleepingcomputer.com)
• BYOVD is fundamentally an operational problem: defenders must balance driver compatibility with security. Aggressive blocking risks breaking legitimate hardware/software; permissive policies invite abuse.

---

Practical takeaways for Windows administrators​

• Inventory driver footprint: run regular scans for unexpected signed drivers (amsdk.sys, wamsdk.sys, zam64 / ZAM), and map which signers are present in your environment. Remove drivers not required.
• Enforce least privilege and application control (WDAC/AppLocker), and enable the Microsoft Vulnerable Driver Blocklist centrally where possible.
• Add behavioral detections for DeviceIoControl patterns, reflective DLL loading, and abrupt termination of security services—these are stronger indicators than static file hashes for this class of attack. (research.checkpoint.com, fortinet.com)
• Treat kernel‑level incidents as high‑confidence reimaging candidates: once a driver is abused to operate at kernel privilege, forensic assurance of a complete clean‑up without rebuild is hard to achieve. Preserve evidence and plan for reimaging as part of incident response.

---

Conclusion​

The Silver Fox campaign exposed by Check Point is a textbook demonstration of a modern BYOVD attack: combine a legitimately signed kernel driver that exposes privileged primitives, a compact all‑in‑one loader with anti‑analysis measures, and a modular RAT delivered via in‑memory reflective loading. The operator tradecraft—especially the signature‑preserving timestamp manipulation that produces new file hashes—exposes the limits of hash‑only defenses and the continuing fragility of a trust model based solely on code signing.
Defenders must respond by shifting emphasis from static indicators to behavior‑based telemetry, tighter driver installation controls, and strict allow‑listing for kernel modules. Apply Microsoft’s blocklist and ASR rules where possible, hunt for DeviceIoControl anomalies, and treat driver‑level incidents with the urgency appropriate to kernel‑level compromise. The cat‑and‑mouse game in kernel shadows will continue; the most effective defenses are layered, proactive, and informed by the kind of deep technical analysis Check Point and other vendors are now publishing. (research.checkpoint.com, fortinet.com, learn.microsoft.com)

---

Source: Check Point Software Chasing the Silver Fox: Cat & Mouse in Kernel Shadows - Check Point Research