SURIQ
For years, the practical answer to a malicious kernel driver was a list. You blocked the known-bad .sys file by hash or name, and the attack that depended on it died. A new Silver Fox campaign takes that answer apart. The malware carries three interchangeable vulnerable drivers and reuses one loader to deploy whichever the target machine will accept, so blocking any single driver just sends it to the next one.
The finding comes from Cato Networks' CTRL threat research team, which documented the chain after it hit a Japanese industrial manufacturer. Cato attributes the activity to Silver Fox, a China-linked cybercrime group, with moderate-to-high confidence, based on the use of the ValleyRAT remote-access trojan, a familiar registry marker, and infrastructure that lines up with earlier Silver Fox operations. The story that matters for defenders is not the specific drivers. It is that the technique behind bring-your-own-vulnerable-driver (BYOVD) attacks has become modular, and a control built on naming bad drivers ages badly against a kit designed to swap them.
Why the kit carries three drivers, not one
The loader embeds three signed-but-vulnerable drivers in encrypted resources: BootRepair.sys, EnPortv.sys (originally shipped with the EnCase forensic suite), and wsftprm.sys (tracked as CVE-2023-52271). Each reaches ZwTerminateProcess from kernel mode, which lets the malware kill endpoint protection before that software can react. Two of the three, BootRepair.sys and EnPortv.sys, had not been tied to Silver Fox before this campaign.
What makes this an evolution is the plumbing around the drivers. Cato describes one reusable workflow for all three: extract and decrypt the driver, write it to disk, create and start a service, open the device object, and send the control code. Only the driver image, the device name, and the control code change between them. That design turns a driver blocklist from a wall into a speed bump. If BootRepair is blocked or incompatible on a given host, the same routine tries EnPortv, then wsftprm, until one loads. We have watched this technique harden over several campaigns, from a productized EDR killer to ransomware that ships its own signed driver. The redundancy is the new part.
The signed PDF app nobody thought to block
Delivery starts with an invoice-themed phishing email, the same lure pattern we saw in the ManageEngine RMM backdoor campaign, with payloads staged on legitimate QQ and Tencent Cloud services, as independent reporting on the campaign confirms. The interesting move is what runs the malicious code. The attackers place a hostile PDFCORE8.dll next to two legitimate, unmodified, digitally signed applications from Zeon Corporation: ConvertToPDF.exe and PDFDirect.exe. Neither had been documented as a sideloading host before. Because Windows resolves an imported DLL from the program's own directory first, launching the signed executable loads the attacker's DLL with the trust of the real vendor. One variant renamed the executable to MicrosoftEdgeUpdate.exe to blend into normal update noise. This is not a flaw in Zeon's software; it is abuse of how Windows loads dependencies, and it is why allow-listing a signed binary is not the same as trusting what it loads.
Unhooking hides it from your agent, not your kernel
Before calling sensitive Windows functions, the malware overwrites the loaded code section of ntdll.dll in memory with a fresh copy pulled off disk. That strips the user-mode inline hooks many endpoint agents install to watch API calls. It is effective against the part of your stack that lives in user space, and it is worth being honest about the limit it creates for defenders who lean only on user-mode hooking.
Here is the part the wire coverage skips. Unhooking ntdll in memory does nothing to the telemetry generated below it. When the loader registers a new kernel service and loads one of its drivers, that driver-load event is produced by the kernel itself, at a layer the in-memory unhook cannot reach. So a defender who watches kernel-sourced driver-load events keeps exactly the visibility this chain was built to erase. The evasion is real, but it is aimed at one layer, and it leaves the layer underneath it fully lit.
| Stage | What the attacker does | Where it still shows |
|---|---|---|
| Sideload | A signed Zeon PDF app loads a planted PDFCORE8.dll | A DLL loading from a user-writable folder beside a signed binary |
| Kill EDR | A swapped-in vulnerable driver terminates security tools from the kernel | A new kernel service registers, then your agents go quiet at once |
| Unhook | ntdll is restored in memory to strip user-mode hooks | Kernel driver-load events, which the in-memory unhook cannot touch |
| Inject | Shellcode runs inside a suspended svchost process | svchost spawned suspended, with a remote write and a thread-context change |
| Persist | ValleyRAT plus a watchdog that checks every 30 seconds | cmd.exe polling tasklist and find on a fixed 30-second loop |
It puts itself back together in 30 seconds
Persistence is doubled. An internal routine in the loader checks whether its injected payload, running inside a suspended svchost.exe, is still alive and recreates it if not. Separately, a batch script pulled from the DLL's resources runs through cmd.exe and checks every 30 seconds whether the loader itself is still running, relaunching it if it disappears. Cato's point is that a defender has to interrupt both components at once, because either one restores the other.
That detail should reset the muscle memory of anyone doing hands-on response. Killing the malicious process, the reflex move, triggers a rebuild within half a minute. On a host showing this behavior, network-isolate first, then remove both stages together. A single-process kill on a live box is not containment here, it is a restart.
Hunt the sequence, not the driver name
The defensive shift this campaign forces is from indicators to behavior. A driver name or hash is a control the attacker can rotate; the sequence of actions is not. The chain still generates a recognizable order of events at the kernel and process level, and that order is what to alert on. Map it to MITRE ATT&CK and the coverage is concrete: DLL side-loading (T1574.002), impairing defenses through a vulnerable driver (T1562.001 with T1068), thread execution hijacking (T1055.003), and a scheduled or scripted watchdog for persistence.
-
A new kernel service registering an unusual driver, closely followed by one or more security agents going silent. This pairing is the highest-value BYOVD signal, and it survives the unhooking.
-
A signed application such as
ConvertToPDF.exeorPDFDirect.exerunning from%TEMP%or another user-writable path, loading aPDFCORE8.dllfrom its own directory. -
A suspended
svchost.execreated with a remote memory allocation, a remote write, and a thread-context change, rather than a normal service launch. -
Binary values dropped into the registry, the command-server configuration under
HKLM\SOFTWARE\IpDates_sunand the payload underHKCU\Console\0, alongside acmd.exeprocess pollingtasklistandfindon a fixed loop. -
Outbound contact to the campaign's command server at
43.128.26.132.
Keep the baseline controls too. Microsoft's Vulnerable Driver Blocklist and memory integrity (HVCI) still raise the cost of loading a known-bad driver, and they should be on. Just do not treat them as the finish line: this kit exists specifically to find the driver your blocklist missed. The durable detection is a managed layer that watches kernel driver-load events and process-termination sequences and maps them to attacker behavior, so the alert fires on the pattern even when the file, the driver, and the user-mode hooks have all been changed to hide it.
Silver Fox picked an industrial manufacturer for a reason worth sitting with. Engineering and production-adjacent Windows endpoints are the machines most likely to run exempted or older endpoint protection and least likely to enforce a kernel driver blocklist. That is the soft spot a swap-in-any-driver kit is built to find, and it will not stay limited to one manufacturer in Japan.