A new in-the-wild campaign by the Silver Fox APT is rubbing salt into the persistent wound of Windows driver security: attackers are using a Microsoft-signed but functionally vulnerable kernel driver to terminate protected security processes and install the ValleyRAT backdoor on fully updated systems. The driver, amsdk.sys (WatchDog Antimalware v1.0.600), was not listed in any public vulnerable driver blocklist when Check Point Research discovered the attacks in late May 2025, giving the campaign a free pass onto Windows 10 and 11 machines.

Instead of a zero-day exploit, Silver Fox relied on the old-fashioned Bring Your Own Vulnerable Driver (BYOVD) technique, but with a twist: they bundled two Zemana SDK‑derived drivers into a single self-contained loader, selecting the right one for the target OS. For modern Windows hosts, they deployed the previously unclassified amsdk.sys; for older versions, they fell back on the long‑known vulnerable ZAM.exe. The loader then registers itself with the driver via a custom IOCTL and immediately uses another IOCTL to kill any process in its hardcoded list of 192 security products—including processes running as Protected Process Light (PP/PPL) that Windows ordinarily shields from termination.

Once the endpoint defenses are blinded, the loader reflectively injects a ValleyRAT downloader into a legitimate svchost.exe process, which fetches the final modular RAT from infrastructure hosted in China. Every step—from the anti‑analysis checks to the in‑memory execution—is designed to leave behind as few forensic traces as possible.

The Campaign’s Anatomy: One Loader, Two Drivers, Zero Tolerance for Security

The all‑in‑one loader samples (often UPX‑packed and carrying the internal name “Runtime Broker”) first perform a series of checks to avoid sandboxes and analyst machines: CPU vendor detection, hypervisor artifacts, and a call to ip‑api.com to see if the ISP or organization matches blacklisted entities like Microsoft Corporation, Google, or Qihoo 360. They also whitelist three specific developer hostnames (DESKTOP‑T3N3M3Q, DESKTOP‑03AMF90, WIN‑VMHH95J6C26), likely to prevent execution from aborting on the attackers’ own test boxes.

If the environment passes, the loader drops itself as RuntimeBroker.exe in C:\Program Files\RunTime, writes the appropriate driver as Amsdk_Service.sys, and creates two services: “Termaintor” for persistence and “Amsdk_Service” to load the kernel module. The name “Termaintor” is almost certainly a deliberate misspelling of the publicly available “Terminator” proof‑of‑concept that already demonstrated how to abuse the Zemana driver. Then, depending on the OS version, it either loads the legacy ZAM.exe (v3.0.0.000) for Windows 7 or the WatchDog driver (v1.0.600) for Windows 10/11.

The driver abuse is elegantly simple. Both drivers expose a device interface (\.\amsdk) that accepts IOCTL 0x80002010 to register the calling process as a trusted client, and then IOCTL 0x80002048 to terminate any process by PID—regardless of PP/PPL protection. The killers iterate through their encoded kill list, containing 192 process names predominantly from Chinese security suites (360 Safe, QQPC, Kingsoft, and many others), and wipe them out. Within seconds, the system is deaf and blind to further malicious activity.

The Accidental Accomplice: amsdk.sys and the Zemana SDK Legacy

At the heart of the attack is the WatchDog Antimalware driver, signed by “Microsoft Windows Hardware Compatibility Publisher,” meaning it is trusted by the OS and can be loaded even on the most hardened Windows 11 box with Memory Integrity enabled—unless blocked by an explicit policy. Check Point’s analysis shows that although the driver’s developers used IoCreateDeviceSecure with a strong DACL (granting access only to SYSTEM and Administrators), they omitted the FILE_DEVICE_SECURE_OPEN flag. As a result, the DACL does not propagate to the device namespace, allowing unprivileged users to open a handle to \.\amsdk\anyfile and gain full control.

Combined with the lack of any PP/PPL verification in the process termination routine, the driver becomes a perfect EDR killer. The DispatchDeviceControl handler directly calls TerminateProcessById after checking only if the target is a critical system process—a check that security service processes easily pass.

“This is not a sophisticated vulnerability,” said a Check Point researcher. “It’s a simple omission of a device characteristic flag and a single missing if‑statement. But because the driver is signed by Microsoft and not on any blocklist, it’s an attacker’s dream.”

From EDR Killer to Full Remote Access: The ValleyRAT Payload

With the security stack neutralized, the loader extracts a Base64‑ and hex‑encoded, UPX‑packed DLL that has been converted to shellcode. This downloader (internal name “Online module.dll”) is reflectively loaded into a running svchost.exe, where it connects to hardcoded C2 servers on ports like 52110 and 52111. The traffic is XOR‑encrypted with a fixed key, and the response contains a ValleyRAT DLL (internal name “LoginModule.dll”) that is similarly loaded and executed in memory.

ValleyRAT, also tracked as Winos, is a modular trojan that has been extensively documented by Fortinet, Zscaler, and others. It supports a full range of remote control capabilities: file exfiltration, command execution, credential harvesting, and plugin‑extensible modules. The variant observed in this campaign includes an anti‑analysis callback (EnumFunc) that checks for window titles associated with network monitoring tools and sandboxes—delaying execution until the coast is clear.

Attribution to Silver Fox rests on overlapping TTPs, the exclusive use of ValleyRAT, and C2 infrastructure consistently hosted in China (Alibaba Cloud, Tencent, and smaller providers like AROSS‑AS). While not definitive, the convergence of these signals across multiple vendor reports makes the link robust.

A Cat‑and‑Mouse Patch Game: One Byte to Bypass Blocklists

After Check Point’s responsible disclosure, the WatchDog company released a patched driver, wamsdk.sys v1.1.100, which fixed the LPE by adding FILE_DEVICE_SECURE_OPEN. However, it did not add a PP/PPL check, leaving the arbitrary process termination vector wide open. Within weeks, Check Point observed a new wave of attacks using a modified version of the patched driver.

The attackers altered a single byte in the unauthenticated timestamp (countersignature) area of the PE’s WIN_CERTIFICATE structure. Because unauthenticated attributes are not covered by the Authenticode signature digest, the modified driver remains validly signed and trusted by Windows—yet its SHA‑256 hash is completely different. This technique, previously documented by Talos and Check Point, lets threat actors spawn an unlimited number of validly signed driver variants that slip past hash‑based blocklists.

“The first rule of BYOVD is that signatures are not enough,” the forum analysis notes. “Attackers can and do manipulate non‑hashed fields to create new signed variants faster than hash lists can be updated.”

Why This Campaign Is a Wake‑Up Call for Windows Defenders

The Silver Fox operation exposes four critical weaknesses that together make BYOVD a persistent threat:

  • Trusted signatures as a Get‑Out‑of‑Jail‑Free card: Because amsdk.sys is signed by Microsoft’s WHCP path, it enjoys full reputation and loading privileges unless proactively blocked. Most organizations do not maintain strict kernel‑driver allow lists.
  • PP/PPL bypass: The ability to kill protected processes means that even the most advanced EDRs can be silenced without triggering alerts—because the OS itself considers the action legitimate.
  • Signature‑preserving hash evasion: A single‑byte change in the timestamp area creates a new file hash while keeping the signature valid. Defenders cannot rely on static hashes alone.
  • Cross‑version compatibility: The dual‑driver approach means one loader can target everything from legacy Windows 7 to the latest 24H2 builds, maximizing the campaign’s reach.

Multiple vendors have corroborated the pattern. Fortinet’s analysis of ValleyRAT details the exact same reflective loader and XOR‑encrypted C2 communications. Forescout and Proofpoint have tracked Silver Fox using similar multi‑stage delivery chains for months.

Practical Detection and Hardening Steps

Organizations need to adopt a layered defense that goes beyond blindly trusting signed drivers. Here’s what to do immediately, in order of priority:

1. Block and Remove the Vulnerable Drivers

  • Apply the Microsoft Vulnerable Driver Blocklist via App Control for Business or enable the corresponding ASR rule (”Block abuse of exploited vulnerable signed drivers”).
  • Inventory all endpoints for amsdk.sys, wamsdk.sys, and ZAM.exe. If not required, remove and quarantine.
  • Update Windows Defender or your EDR with the latest intelligence to block the reported file hashes.

2. Hunt for IOCTL Abuse and Anomalous Device Access

  • Look for non‑system processes creating handles to \.\amsdk or \.\zam devices.
  • Monitor for DeviceIoControl calls with control codes 0x80002010 and 0x80002048.
  • Correlate sudden termination of security service processes (MsMpEng.exe, SecurityHealthService.exe, and any on the published kill list) with network connections to unusual IPs.

3. Detect Reflective Loading and In‑Memory Execution

  • Hunt for processes performing reflective DLL loads (RWX memory mappings, suspicious memory allocation patterns in svchost.exe or RuntimeBroker.exe).
  • Look for simple XOR‑encoded data streams or reverse‑stored IP:port strings in network traffic.
  • Deploy YARA rules (such as those provided by Check Point) to scan for the specific driver versions and the ValleyRAT downloader shellcode.

4. Harden Long‑Term Posture

  • Move from hash‑based blocking to explicit driver allow‑listing with WDAC. Only permit known, approved kernel drivers to load.
  • Scrutinize driver signing anomalies: track expected file hashes, certificate chains, and timestamp countersignature consistency.
  • Treat kernel‑level incidents as grounds for reimaging. A driver‑based attack can achieve such deep access that full trustworthiness cannot be restored without a clean OS installation.

Conclusion: The Kernel Shadows Game Continues

The Silver Fox BYOVD campaign is a textbook example of how adroit attackers exploit the gap between theoretical security and practical implementation. A signed driver—one that reputable vendors still ship—was weaponized to kill security software, and when a patch appeared, a single byte was flipped to bypass it. The industry’s reliance on signatures and hashes, while necessary, is proving brittle against adversaries who understand the inner workings of Authenticode and the Windows driver model.

Defenders must respond with behavior‑based telemetry, proactive allow‑listing, and a swift incident response playbook that assumes kernel compromise until proven otherwise. Check Point’s research, amplified by community insights, provides the detailed indicators and detection recipes needed to mount that defense. In the cat‑and‑mouse game playing out in kernel shadows, the mice have learned to sign their own cheats.