SilverFox Deploys 3-Driver BYOVD Chain and ValleyRAT Against Japanese Manufacturer

A China-linked threat cluster reportedly leaned on three vulnerable drivers at once to clear a path for ValleyRAT — a driver-hygiene problem for defenders more than a single bug to patch.

TEL AVIV — Researchers at Cato CTRL have documented a campaign in which SilverFox — a threat cluster described in prior reporting as China-linked — reportedly used a three-driver bring-your-own-vulnerable-driver (BYOVD) chain to deliver the ValleyRAT remote-access trojan to a Japanese manufacturer, according to reporting published by The Hacker News on July 30, 2026.

The detail that distinguishes this wave is the count. Rather than abusing a single signed-but-vulnerable driver, SilverFox reportedly carried three — an arrangement Cato reads as a way to keep the intrusion working across whatever endpoint configuration it lands on. This piece summarizes what the disclosure documents and what defenders can verify, in defender terms, without reconstructing how the driver abuse is performed. As reported by The Hacker News and detailed in Cato CTRL's write-up, the intrusion began with an invoice-themed lure and ended with a Gh0st-derived remote-access trojan on the target network.

What Cato CTRL Reported

The primary account comes from Cato CTRL, whose researchers dissected the intrusion; The Hacker News summarized it for a wider audience on July 30, 2026. In defender terms, the reported chain runs from a socially engineered starting point — an invoice-themed lure — through a loader stage, to the deployment of ValleyRAT, a remote-access trojan the researchers place in the Gh0st RAT lineage. The through-line the reporting emphasizes is not a novel exploit but the reuse of legitimate-but-vulnerable signed drivers to weaken the endpoint before the trojan lands.

Cato names three drivers in the chain — BootRepair.sys, EnPortv.sys, and wsftprm.sys — and reports that two of them had no prior public association with this cluster. The researchers describe the three-driver bundling as a plug-and-play design meant to keep the intrusion functional across differing environments. The CyberSignal is deliberately not reproducing the mechanics of how each driver is abused; the defender-relevant facts are the driver names themselves, which double as hunting terms, and the fact that at least one — wsftprm.sys — is associated in public tracking with CVE-2023-52271.

It remains, in the reporting reviewed, a single documented victim in industrial manufacturing. Whether the same tooling has reached other organizations across Japan is not established here, and The CyberSignal treats that as an open question rather than an assertion.

The BYOVD Tradecraft Class and Microsoft's Driver-Block-List Defense

BYOVD — bring your own vulnerable driver — is a well-understood tradecraft class, and translating it for a defender team matters more than restating its name. The pattern relies on drivers that are validly signed yet carry a flaw; because the signature is genuine, the driver can load on a system that trusts signed code. The defensive countermeasure most directly in scope is Microsoft's Vulnerable Driver Blocklist, which refuses known-bad drivers at load time when it is enabled and current. That is the same weakening-the-endpoint problem The CyberSignal has tracked in coverage of efforts to disable Microsoft Defender at the kernel layer.

The reason the three-driver framing is worth pausing on is that it reframes the fix. There is no single product patch that closes "BYOVD" in the abstract; the defense is driver hygiene — keeping the blocklist current, enforcing it, and monitoring for the specific vulnerable drivers that adversaries are known to carry. A chain that packs three drivers is, in effect, hedging against exactly that control: if one driver is already blocked in a given environment, another may not be.

What Defenders Should Verify (Driver-Block-List Version)

The single most actionable step is verification, not new tooling. Confirm that the Microsoft Vulnerable Driver Blocklist is enabled and that endpoints are running the current version. Microsoft distributes blocklist updates through Windows Update and the Microsoft Download Center; the most recent publicly referenced refresh at the time of writing is the May 2026 update, and the April 2026 security updates separately added a known-vulnerable driver to the enforced list. Environments running an older blocklist, or with enforcement disabled, are the ones a three-driver chain is designed to exploit.

Beyond the blocklist, defenders can treat the three reported driver names as hunting terms across endpoint telemetry, watch for anomalous signed-driver load events, and add ValleyRAT indicators to detection content. Importantly, The CyberSignal has not independently confirmed that Microsoft updated the blocklist in direct response to this specific SilverFox activity — historically, closely related SilverFox-abused drivers went for a period without being flagged by the blocklist — so the safe posture is to verify your own version rather than to assume coverage.

The SilverFox / ValleyRAT Continuity Thread

SilverFox and ValleyRAT are not new to trackers. The cluster has appeared repeatedly in reporting pairing signed-driver abuse with ValleyRAT, a trojan in the long-lived Gh0st RAT family that gives an operator remote command execution and post-access control. That continuity is the point: this disclosure reads as an iteration on an established playbook, not a first sighting. It sits alongside The CyberSignal's coverage of other China-linked intrusion clusters that lean on cloud services and custom implants, and of remote-access-trojan delivery chains built for stealth.

The China-linked attribution should be read as prior reporting frames it — attributed, not adjudicated here. What is durable across the SilverFox thread is the tradecraft signature: legitimate-but-vulnerable drivers used to clear a path, followed by a Gh0st-derived trojan. For organizations in Japan specifically, the disclosure lands amid a run of activity The CyberSignal has covered against Japanese targets, including a credential breach at a major Japanese ISP — a reminder that the region is under sustained, varied pressure rather than facing a one-off.

Open Questions

Several specifics remain unresolved at publication. The individual victim manufacturer is not named in the reporting reviewed. Whether the campaign extends beyond the single documented target to other organizations across Japan is not established. And while wsftprm.sys is associated in public tracking with a CVE, complete CVE mapping for all three reported drivers is not fully laid out in the material reviewed.

It is also not confirmed whether Microsoft's Vulnerable Driver Blocklist has been updated specifically in response to this activity, nor whether the drivers named here are enforced by the version an individual organization happens to be running — which is precisely why the guidance above is framed around verifying your own blocklist state rather than assuming it. As Cato's full technical account is examined by other researchers and any vendor or advisory follow-ups emerge, the picture will sharpen.

The CyberSignal Analysis

The reported facts above come from Cato CTRL's research and its reporting; what follows is The CyberSignal's editorial reading. None of the judgments below are new reported facts.

Signal 01 — The Story Is Driver Hygiene, Not a Single Bug

The instinct with any intrusion is to ask which patch closes it. Our reading is that BYOVD frustrates that instinct by design: the exposure is a class of trusted-but-vulnerable drivers, not one defect in one product. Carrying three drivers rather than one makes the point unmistakable — the operators are hedging against the exact control (a driver blocklist) that would stop them.

The consequence for defenders is to shift effort from patch-hunting to hygiene: keep the blocklist current and enforced, know which vulnerable drivers are in circulation, and monitor signed-driver loads. That discipline pays off against the next cluster that reuses the technique, regardless of which specific drivers it carries.

Signal 02 — Read the Attribution As Attributed, Not Adjudicated

Our assessment is that the useful posture is to take the China-linked framing seriously while holding it at the confidence level the reporting supports. Prior reporting associates SilverFox with China; this disclosure does not, on its own, re-prove that. The tradecraft continuity — signed-driver abuse plus a Gh0st-derived trojan — is the more load-bearing detail for defenders than the flag on the actor.

That matters operationally because detection content should key on behavior and indicators, which travel, rather than on attribution, which can shift. Defenders who hunt the drivers and the ValleyRAT footprint are covered whether or not the geopolitical label ever hardens.

Signal 03 — Japan Is Under Sustained, Varied Pressure

The detail we find most durable is regional. A single manufacturer is the documented victim, but this disclosure lands amid a broader run of activity against Japanese organizations that The CyberSignal has tracked across very different vectors. Our view is that defenders in the region should read this less as an isolated event than as one more data point in a pattern.

The organizations best positioned to act are those already treating driver hygiene and RAT detection as standing programs rather than incident-driven scrambles. We would use this disclosure as a prompt to verify blocklist state now — before an intrusion, not after — and to make sure someone owns that verification end to end.

Sources