SilverFox's 3-Driver BYOVD Chain: Delivering ValleyRAT to Manufacturing
Has anyone else parsed the latest report on SilverFox targeting the Japanese industrial sector? They've really escalated their BYOVD (Bring Your Own Vulnerable Driver) game. Instead of relying on a single driver to kill AV/EDR, they are employing a 3-driver chain to progressively lower defenses before delivering ValleyRAT (also identified as Winos 4.0).
The attack flow is concerning because once they get that kernel-level execution via the third driver, they effectively own the box and can load the RAT for persistent C2. For industrial environments, ValleyRAT's capabilities for data exfiltration are particularly nasty.
I've updated our hunting queries to flag any driver signed by vendors not in our allowlist attempting to load immediately after a user login or unexpected process execution. We are currently looking for drivers with revoked or weak signatures using this snippet in our environment:
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-DriverFrameworks-UserMode/Operational'; ID=1003} |
Where-Object { $_.Message -match 'revoked' -or $_.Message -match 'untrusted' } |
Select-Object TimeCreated, Message
Note that Event ID 1003 tracks driver load operations; if you see failures related to known bad signatures, it often indicates an attempt was blocked—or perhaps a retry with a different exploit.
Given that Microsoft's Vulnerable Driver Blocklist is updated via Microsoft Defender, is it actually enough to stop this, or are we seeing a lag time where custom blocklists via WDAC are becoming mandatory?
We stopped relying on just the default blocklist months ago. The gap between a driver being publicly exploited and Microsoft adding it to the blocklist is just too wide. We implemented WDAC (Windows Defender Application Control) with a base policy that explicitly denies known vulnerable drivers by hash.
It creates some management overhead, but it stops the BYOVD chain dead in its tracks before the second driver even loads.
From a pentester's view, this 3-stage chain is interesting because it serves as a rudimentary AV-evolution check. If the first driver fails (EDR blocks it), they don't burn the second, more sophisticated one.
For detection, correlation is key. Watch for the staging of the driver files (usually .sys) landing in C:\Windows\Temp or AppData followed immediately by a service creation or fltmc load commands.
I'd add that enabling Hypervisor-Protected Code Integrity (HVCI) / Memory Integrity is critical here. While not a silver bullet, it significantly raises the bar for kernel exploits. ValleyRAT usually requires disabling some of these protections to maintain persistence. If the hardware supports it, turn HVCI on—it invalidates a lot of the memory manipulation techniques these drivers use.
Solid insights. Beyond prevention, detection is vital since these chains often move laterally before HVCI catches them. We've deployed a Sigma rule specifically hunting for the unusual sequential loading of drivers within a short window.
For a quick audit of your current non-Microsoft drivers—which helps identify a baseline to flag anomalies against—you can run:
Get-WmiObject Win32_PnPSignedDriver | Where-Object {$_.DriverProviderName -ne "Microsoft"} | Select-Object DeviceName, DriverProviderName, DriverDate | Format-Table -AutoSize
Identifying the 'normal' third-party drivers makes spotting the BYOVD payloads significantly easier.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access