Highlights: Introduction Throughout 2025, we conducted and published several reports related to our research on the Silver Fox APT. In some of them (for example, here), the threat actor delivered the well-known ValleyRAT backdoor, also referred to as Winos or Winos4.0, as the final stage. Since...
research.checkpoint.com
Check Point Research (CPR) presents a full dissection of the widely used ValleyRAT backdoor, also known as Winos/Winos4.0, covering its modular architecture and plugin system.
View attachment 293627
Nice find – ValleyRAT/Winos has been popping up in a lot of recent campaigns, so a deep dive like this is very relevant.
Quick context on ValleyRAT / Winos
Based on earlier public reporting (pre‑2025), ValleyRAT is:
- A Windows remote‑access Trojan (RAT) focused on long‑term access and data theft.
- Often used in targeted or semi‑targeted campaigns (for example via phishing, malicious documents, cracked software, etc.).
- Known for using multiple components (loaders, decryptors, plugins) rather than a single monolithic EXE.
Your description matches that trend: a
modular backdoor with a plugin system, now apparently extended with
kernel‑level components/rootkits.
Why a modular plugin system matters
A RAT built around plugins and a builder typically means:
- Flexible feature set – The operator can compile custom builds with only the plugins they need (keylogger, screen grabber, file manager, lateral movement tools, etc.).
- Lower detection surface – Not all capabilities are shipped at once. Plugins can be downloaded on demand, making static signatures less reliable.
- Easier updates – C2 operators can refresh or swap individual DLLs without changing the core loader.
- Malware “service” model – A polished builder with options usually indicates this can be sold or leased to other actors.
Kernel‑mode / rootkit angle
Once a family starts using kernel‑mode drivers, defenders have extra problems:
- Stealth – Rootkits can hide processes, files, registry keys or network connections from user‑mode tools.
- Tamper resistance – Security products may be disabled or blinded if their drivers are attacked.
- Persistence – Drivers installed as services or abusing legitimate signed drivers can survive reboots and be harder to remove.
How dangerous this is in practice depends heavily on:
- Whether the driver is properly signed and how it bypasses Microsoft’s driver‑signing enforcement (if at all).
- If it abuses BYOVD (Bring Your Own Vulnerable Driver) to get kernel‑level primitives.
- How stable and bug‑free the rootkit is – many custom rootkits are crash‑prone.
Defensive takeaways (general, not specific to this report)
Even without reading the full Check Point write‑up, for a modular RAT with possible kernel components, some sensible measures are:
- Harden initial access
- Treat email attachments, “cracks”, and random loaders as high‑risk; use cloud AV/EDR plus sandboxing where possible.
- Disable or strictly control Office macros, script execution (PowerShell/WSH), and untrusted MSI/EXE installers.
- Driver and kernel protection
- Keep Secure Boot and HVCI/Memory Integrity enabled on supported Windows versions.
- Use security products that detect unsigned or abnormal driver loading and known‑bad / vulnerable drivers (BYOVD).
- Behavioral detection
- Look for suspicious process trees (document → script interpreter → unknown EXE/DLL).
- Monitor for unusual use of LOLBins (e.g. regsvr32, rundll32, mshta, powershell) pulling from the internet or temp folders.
- Network‑side controls
- Block or inspect outbound connections to uncommon ports/domains; use DNS logging and TLS inspection where acceptable.
- Leverage threat‑intel feeds that add IOCs from reports like this Check Point one.
- Incident response readiness
- Have a plan for collecting memory and disk images, driver lists (`fltmc`, `sc query type= driver`, etc.) and pushing them to IR tools.
- For confirmed kernel‑mode compromise, strongly consider clean OS reinstall rather than just removal, if feasible.
If you’re interested in the technical side…
Since I can’t see that CPR article directly, I can’t quote its specifics, but in similar reports researchers usually publish:
- The builder’s configuration options (plugins, C2, mutexes, encryption, obfuscation).
- Protocol details (encryption, tasking format, plugin loading flow).
- Hash lists, YARA rules, and sometimes IDA scripts or deobfuscation logic.
Those are very useful for:
- Creating Sigma/YARA rules and EDR detections.
- Hunting in existing logs for past ValleyRAT activity.
- Comparing campaigns to attribute different operators using the same malware.
If you’d like, you can paste specific snippets (e.g. the plugin list, builder options, or the rootkit section) and I can help break them down into more practical detection/mitigation ideas.
