SilverFox used three BYOVD drivers to protect ValleyRAT

On 30 July 2026, researchers described a new SilverFox campaign targeting a Japanese industrial manufacturer. The intrusion ended with ValleyRAT, also known as Winos 4.0, but its defensive resilience was the most notable component: three vulnerable drivers, DLL side-loading, NTDLL unhooking, process injection and two independent watchdogs.

This is an evolved Bring Your Own Vulnerable Driver (BYOVD) chain. An attacker does not need a new kernel zero-day. They bring a legitimately signed but vulnerable driver and abuse its privileged functions to interfere with security controls.

The confirmed campaign chain

Cato CTRL’s analysis, covered in 30 July reporting, identifies an invoice-themed phishing message as the entry point. Content was hosted on legitimate QQ and Tencent Cloud services, improving apparent trust and frustrating domain-reputation-only controls.

The downloaded ZIP contained an executable that retrieved components for DLL side-loading. A malicious PDFCORE8.dll was loaded by legitimate ConvertToPDF.exe or PDFDirect.exe applications associated with Zeon Corporation.

The loader embedded three drivers:

• BootRepair.sys;
• EnPortv.sys;
• wsftprm.sys.

SilverFox had previously used vulnerable amsdk.sys and wsftprm.sys drivers. Researchers observed BootRepair.sys and EnPortv.sys in this campaign context for the first time. That does not make every product containing a similarly named file malicious. Risk depends on the exact version, vulnerability, load path and subsequent behaviour.

Why use three drivers?

The modules provided deliberate redundancy and a replaceable BYOVD framework. If one driver failed on a Windows release, was policy-blocked or detected, the operator could use another without rebuilding the rest of the chain.

The design provides:

1. compatibility across more environments;
2. resilience against a single hash or certificate block;
3. modularity, allowing drivers to change independently of the loader and ValleyRAT.

A rule that blocks only wsftprm.sys remains useful but incomplete. Defenders need to detect the class: an unusual process loading a new driver immediately before interference with endpoint protection.

A digital signature is not a safety guarantee

Kernel drivers require elevated system trust. A signature confirms origin and integrity relative to a signed version; it does not guarantee that the driver’s interfaces are safe.

BYOVD exploits precisely that gap. A signed driver may expose arbitrary memory read/write, physical-memory mapping, process termination or kernel configuration functions created for diagnostics or hardware support. Once loaded by an attacker, they become offensive primitives.

Driver policy should evaluate:

• publisher and signature;
• exact hash and version;
• inclusion on Microsoft’s Vulnerable Driver Blocklist;
• installation source;
• loading process and identity;
• intended kernel operation;
• behaviour immediately after installation.

DLL side-loading as a quiet launch path

Windows applications load libraries required for operation. If an application searches its working directory before a trusted system location, an attacker can place a malicious library with the expected name beside a legitimate executable.

Here, legitimate PDF converters loaded PDFCORE8.dll. A user and some controls could see a recognised, signed EXE while code execution originated in the untrusted DLL.

Detection should correlate:

• a signed executable started from a user or archive directory;
• an unsigned or mismatched DLL beside it;
• an unusual parent process;
• creation of a driver service;
• writes of .sys files;
• subsequent EDR manipulation and injection.

Private DLL loading is not inherently malicious. Location, origin, signature and follow-on events establish the stronger signal.

NTDLL unhooking to reduce EDR visibility

Endpoint products often hook user-mode functions to observe native Windows API activity. The SilverFox loader performed NTDLL unhooking, restoring cleaner code and removing some inline hooks.

That does not disable every endpoint control. EDR can collect kernel, ETW, driver, network and behavioural telemetry. Unhooking removes an important observation point and becomes more effective when combined with BYOVD.

Potential signals include mapping a fresh NTDLL copy, copying code sections into the loaded module, changing page protections and sudden function-prologue differences. Rules require care because legitimate diagnostic and security software can also work with system libraries.

Injecting ValleyRAT

The loader contacted 43.128.26[.]132, retrieved shellcode and created a new svchost.exe. Thread-context hijacking then began execution inside that process.

The final implant was ValleyRAT, a Gh0st RAT variant providing command-and-control, task execution and post-compromise functions. The svchost.exe name does not establish legitimacy. Review:

• parent process;
• image path;
• token and session;
• creation time relative to archive execution;
• memory regions without file backing;
• network connections;
• thread start addresses outside normal modules.

Dual watchdogs create a recovery loop

The chain used an internal monitor for the injected payload and an external batch script watching the loader. If ValleyRAT inside svchost.exe stopped, the loader recreated it. If the defender killed the loader, the scheduled watchdog relaunched it.

Stopping the most suspicious process can therefore trigger recovery. Containment must cover:

• the injected process;
• loader;
• scheduled task;
• watchdog script;
• drivers and services;
• source archive;
• C2 and download path.

Perform the work on an isolated host while preserving memory and artifacts.

Who is exposed

The confirmed case involved a Japanese manufacturing organisation. There is no public evidence of a campaign against every manufacturer or deployment of the same three drivers in Poland. Manufacturing remains attractive because of intellectual property, production continuity, suppliers and legacy systems.

The pattern matters to any Windows environment where:

• users run unapproved software;
• vulnerable drivers are not blocked;
• EDR does not observe kernel-service installation;
• allowlisting trusts every signed binary;
• production endpoints have broad network access;
• invoice recipients have installation privileges.

Layered detection

A single IOC will age quickly. A stronger strategy connects stages:

1. delivery — cloud-hosted archive after invoice mail;
2. execution — a PDF converter from an unusual path;
3. side-loading — untrusted PDFCORE8.dll;
4. kernel — BootRepair.sys, EnPortv.sys or wsftprm.sys;
5. defence evasion — security-process termination and NTDLL unhooking;
6. injection — new svchost.exe with an unusual thread;
7. persistence — watchdog and scheduled task;
8. C2 — traffic to research infrastructure.

Create medium-weight analytics for individual stages, then correlate them over a short time window. Our Sigma and SIEM detection-engineering guide explains the process.

Response and recovery

When signals correlate:

1. isolate the host;
2. preserve memory and enumerate drivers, services, tasks and connections;
3. do not stop at killing svchost.exe;
4. identify both watchdogs and the loader;
5. establish which security controls were disabled;
6. hunt for the ZIP, DLL, drivers and infrastructure;
7. map accounts and resources reachable from the endpoint;
8. rebuild from a trusted image when kernel access is confirmed;
9. rotate credentials used on the system;
10. monitor identity activity after restoration.

Kernel-level access reduces confidence in local evidence. Rebuilding is generally safer than manually removing only known artifacts.

A driver policy that blocks the pattern

The three filenames are useful hunting seeds but a weak long-term strategy. A driver can be renamed, and an operator can substitute another known-vulnerable release. A stronger policy combines Microsoft’s vulnerable-driver blocklist, application-control rules, restricted installation rights and telemetry for kernel-service creation. Every exception needs an owner, business justification, approved version and review date.

Test four outcomes in a non-production ring: whether policy blocks each observed artifact, whether it alerts before execution, whether legitimate operational drivers continue to work, and whether an attempted EDR shutdown creates a signal in an independent layer. The last condition matters because BYOVD exists specifically to weaken the control expected to report later stages.

A new kernel service should be rare on office endpoints. Industrial systems may require a broader approved set, but that set is often more stable. This makes role-based behavioural baselines more durable than trust based only on a filename or valid digital signature.

In the telemetry timeline, connect driver installation with its parent process, file origin, change in protection state and creation of a new svchost.exe. A particularly valuable sequence is an application in a user directory creating a kernel service, a security process disappearing and a system process making a new connection moments later. Each signal can have a legitimate explanation in isolation; together they describe the purpose of BYOVD more reliably than a single hash.

Retention needs to cover delivery of the archive, not only the alert time. This lets responders identify everyone who received the same lure and whether the file was copied to other endpoints.

Attribution boundaries

Cato attributes the observed chain to SilverFox. ValleyRAT and several techniques are associated with the group across multiple campaigns. Separate analysis of 146 Atlas RAT samples suggested broader tool distribution, but the Atlas-to-SilverFox link was described as circumstantial.

Do not attribute every ValleyRAT or Atlas RAT sample—or every vulnerable-driver use—to one operator. The behavioural chain matters more defensively than the group label. Our Cyber Threat Intelligence lifecycle helps preserve confidence levels and competing hypotheses.

Source findings versus Breachroad conclusions

Cato confirms the invoice lure, QQ/Tencent services, legitimate Zeon binaries, three drivers, NTDLL unhooking, thread-context hijacking, dual watchdogs and ValleyRAT. Public evidence does not establish a broad victim count.

Our correlation, rebuilding and signed-driver evaluation recommendations are defensive conclusions. An IT security audit can assess application control, driver policy, segmentation and telemetry.

Technology and user behaviour need to work together. Cybersecurity training should cover invoice and archive verification, while technical teams must recognise that a signed driver can be an attack tool. Our software supply-chain attack guide provides further trust-chain context.