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 this malware family is widely used, modular, and often associated with Chinese threat actors such as Silver Fox, we decided to take a deeper look at its development, plugin system, and the capabilities exposed through individual components.
At first, we focused on collecting as much information as possible from publicly available sources. However, after the initial survey, we realized that despite the first report related to ValleyRAT being dated to early 2023, the existing material is quite limited. Most publications discuss only the specific plugins that happened to be deployed to victims or malware labs during analysis, which in many cases means only one or two plugins.
When a potential victim, including a malware lab, is infected with the ValleyRAT backdoor, the initial modules deployed are usually first-stage plugins such as the “ **Online Module**” or “ **Login Module**”. These act as initial beacons and are responsible for retrieving and loading additional plugins from the ValleyRAT C2 server. It is entirely up to the attacker to decide whether a victim appears interesting enough to receive further components and expose more of the backdoor’s capabilities. Many victims, especially malware labs, do not meet this threshold, meaning analysts only get to see the plugins that operators intentionally delivered.
Because of this limitation, we shifted our attention to searching for leaked ValleyRAT **builders** and **source code**. Normally, materials like these circulate on the dark web within small, restricted communities. Fortunately, in today’s “share whatever, wherever” environment, we were able to obtain them from several publicly available GitHub repositories.
ValleyRAT is strongly associated with Chinese-speaking threat actors, so we expanded our search with Chinese keywords and phrases that seemed relevant to the malware. This approach was successful: we found not only the ValleyRAT builder but also its development structure, including Visual Studio solutions and project files. Although the actual **source code was missing**, we were still able to link individual Visual Studio projects to plugin binaries extracted from the builder.
It is worth mentioning that we achieved these results only after going through many trojanized repositories, including ValleyRAT builders infected with other backdoors. Hackers hacking hackers. Eventually, we located repositories that contained exactly the information we were looking for.
In this publication, we focus on a full dissection of the ValleyRAT modular system. We describe the builder, outline our extraction and analysis methodology, and provide detailed explanations for every plugin used by the malware. We also include an in-depth analysis of one of the most interesting components, the “ **Driver Plugin**”, which embeds a kernel-mode **rootkit**. Special attention is given to the rootkit and its user-mode client, along with the techniques they implement. Finally, with carefully crafted detection rules for all plugins, we present their in-the-wild detection statistics based on both our internal telemetry and public services.
The first interesting repository we identified is related to the ValleyRAT builder, which also functions as a C2 panel and has been publicly available since March 2025. Below is a comparison between the original Chinese repository and its translated version.
The claim about the “ **Effective date: March 25, 2025**” mentioned in the repository structure (with the builder archive itself uploaded on March 26, 2025) correlates with the PE compilation timestamp of the builder: **Wednesday, 26.03.2025 04:10:15 UTC**. This suggests that it is likely one of the latest versions of the ValleyRAT builder.
The second repository, which is slightly older (June 2024), contains development artifacts related to the ValleyRAT plugin system, including Visual Studio solutions and project structures ( **without source code**). A translated version of this repository can be seen below.
The fact that the development structure (without source code) has been publicly available for a while suggests that the **leaked ValleyRAT source code** itself has probably been circulating in the wild as well.
Both repositories are in Chinese, and as an initial step, we focused on the one containing the Visual Studio structure. We then attempted to locate matching artifacts inside the compiled builder package from the first repository.
While the development structure referenced both “ **main**” and “ **auxiliary**” plugins, only the compiled “ **main**” plugins were present inside the builder’s PE resources.
During the analysis of the development structure, one component immediately stood out: a plugin named “ **Driver Plugin**”, which appears to include a kernel‑mode driver component.
We were later able to locate this compiled plugin inside the builder’s resources.
The “Driver Plugin” is a DLL that acts as a user‑mode client for an embedded rootkit driver. Its original filename can be recovered from the Export Directory.
The rootkit driver is stored within the `.data` section of the `Driver Plugin.dll`. After careful extraction that preserved its original `WIN_CERTIFICATE` structure, we identified the exact sample on VirusTotal. The driver retains the original PDB path that closely matches the Visual Studio project path from the development structure.
The driver’s compilation timestamp appears intact: **Sunday, 23.04.2023 08:10:50 UTC**. However, despite being compiled in 2023, it is signed using an expired certificate valid only between **2013–2014**. We believe this certificate was stolen and used to sign the driver.
Even though the certificate had expired, the signature still fell under the Windows Driver Signing Policy – Exceptions (the legacy driver category). For this reason, the rootkit driver could be loaded even on the latest Windows 11 systems. During our initial investigation, the certificate had not yet been revoked, allowing the driver to load successfully; later revocation prevented this.
Using carefully crafted internal detection rules covering the entire ValleyRAT modular system (all “main” plugins and the rootkit driver), we identified approximately **6,000 ValleyRAT‑related samples** in the wild between November 2024 and November 2025. Notably, around **85%** of these detections occurred within the last six months of that period, which correlates with the time the ValleyRAT builder first appeared publicly. This clearly reflects the growing adoption of this modular backdoor.
Another notable observation is that among the detected samples, we found **30 distinct variants** of the ValleyRAT builder and **12 variants** of the rootkit driver. The majority of the detected rootkits were compiled in 2025, based on PE compilation timestamps that appeared intact. Seven of the drivers were still signed with valid (non‑revoked) certificates. Despite all certificates being expired long ago (validity periods ending before 2015), they fall under the driver signing policy exceptions for end‑entity certificates issued before July 29th 2015 that chain to a supported cross‑signed CA. We confirmed that several of these drivers were not properly detected by Microsoft Defender Antivirus, were absent from the latest version of the Microsoft Vulnerable Driver Blocklist, and could still be loaded on fully updated Windows 11 systems with all protection features enabled (including HVCI and Secure Boot). We responsibly disclosed these findings to the **Microsoft Security Intelligence** team.
As expected, an APT‑level threat actor deployed this capability for a reason. ValleyRAT includes a kernel‑mode module that functions as a rootkit and remains loadable even on the latest Windows versions with modern security mitigations in place.
We also discovered an interesting connection between the Chinese Sun‑RAT “company” website ( `https://www.sun-rat.com/`), which advertised a commercial remote‑administration tool, and the ValleyRAT builder. While the main page of the website was accessible during our initial investigation, it has since disappeared, though some subpages (such as the contact and login sections) remain online. By obtaining the Sun‑RAT demo product, we were able to compare it with the ValleyRAT builder.
**Sun-RAT software:**
**ValleyRAT builder:**
The similarities strongly suggest one of two possibilities:
We believe the second scenario is more likely.
In the next section, we dive into the ValleyRAT builder internals, the plugin extraction process, and the functionality of each component in the modular system.
The obtained ValleyRAT builder is a 32-bit PE file, compiled on **Wednesday, 26.03.2025 04:10:15 UTC**, containing the plugins inside its resources. As previously mentioned, the builder includes only the “ **main**” plugins and not the “ **auxiliary**” ones.
To analyze all compiled plugins and any additional utilities embedded elsewhere in the builder (some were found in the `.data` section) or even within the plugins themselves, we needed a reliable extraction strategy. To increase confidence in the correctness of the extraction, we adopted a dual-tool methodology: DIE – Extractor (operating as a smart carver capable of pulling PE32/PE64 files even when nested inside another PE) and Resource Hacker. To validate the extraction results across DIE + Resource Hacker, we compared authentihashes and output sizes of the extracted PE files against expected PE sizes. Below is an example script demonstrating authentihash computation using LIEF:
“`
#!/usr/bin/env python3 “”” Compute Authenticode authentihash for all PE files in a directory using LIEF. Usage: python authentihash_lief.py /path/to/dir [–algo sha256] [–recurse] Example: python authentihash_lief.py C:WindowsSystem32 –algo sha256 “”” import os import sys import argparse import lief # Map user-friendly names to LIEF enum values ALGO_MAP = { “sha1”: lief.PE.ALGORITHMS.SHA_1, “sha256”: lief.PE.ALGORITHMS.SHA_256, “sha384”: lief.PE.ALGORITHMS.SHA_384, “sha512”: lief.PE.ALGORITHMS.SHA_512, } def compute_authentihash(path, algo_enum): “””Return the authentihash (bytes) computed by LIEF for the given PE file.””” pe = lief.parse(path) if pe is None: raise RuntimeError(“Failed to parse PE file”) digest = pe.authentihash(algo_enum) return digest.hex() def scan_dir(directory, algo_enum, recurse=False): “””Iterate through directory and print t.””” for root, dirs, files in os.walk(directory): for fn in files: full = os.path.join(root, fn) try: with open(full, “rb”) as f: if f.read(2) != b”MZ”: continue digest = compute_authentihash(full, algo_enum) print(f”{full}t{digest}”) except Exception as e: print(f”[!] {full}tERROR: {e}”, file=sys.stderr) if not recurse: break def main(): parser = argparse.ArgumentParser(description=”Compute Authenticode authentihash for PE files using LIEF”) parser.add_argument(“directory”, help=”Directory to scan”) parser.add_argument(“–algo”, default=”sha256″, choices=[“sha1”, “sha256”, “sha384”, “sha512″], help=”Hash algorithm (default: sha256)”) parser.add_argument(“–recurse”, action=”store_true”, help=”Recursively scan subdirectories”) args = parser.parse_args() algo_enum = ALGO_MAP[args.algo.lower()] scan_dir(args.directory, algo_enum, recurse=args.recurse) if __name__ == “__main__”: main()
“`
Using this approach, we successfully extracted all plugins, helper tools, and—most importantly—the rootkit driver, which we analyze in depth later. Among the extracted helper utilities were known third-party tools such as **UPX**, **BoxedApp SDK**, and an extended logging library.
The core focus, however, is on the extracted “ **main**” plugins present in both 32-bit and 64-bit variants. In total, we obtained **19 distinct main plugins**, and their counts and names (based on VS project structure and compiled PE metadata) match the layout of the original development environment.
To verify the functionality of all 38 plugins (19×32-bit + 19×64-bit) along with the ValleyRAT rootkit driver, we automated the reverse-engineering workflow using two AI-assisted approaches: a **live IDA MCP server** and an **offline IDA export pipeline**, similar to the process described in our publication _Generative AI as a Force Multiplier for Reverse Engineering_. All automatically generated results were manually validated, with several plugins fully reverse engineered to investigate artifacts and noteworthy code paths highlighted by the AI methods.
All plugins are capable of establishing TCP or UDP connections to a specified C2 host and exchanging plugin-specific serialized data, typically encrypted using custom XOR-based schemes. The received data generally correspond to commands that trigger specific plugin functionality. The table below summarizes all available “ **main**” plugins and their primary capabilities.
The “ **auxiliary**” plugins are not included in the compiled ValleyRAT builder, meaning their functionality could not be verified through reverse engineering of actual binaries. Instead, their expected behavior can only be inferred by analyzing the logical structure of the leaked Visual Studio solutions and the functionality implied by the associated project files. Because neither source code nor compiled versions were available, the listed capabilities remain educated assumptions based on naming conventions and references within the VS project structure.
With a clearer view of ValleyRAT’s modular design, it is apparent that most plugins implement common backdoor functionality. From a research perspective, the most interesting components are those capable of providing rare or high-impact capabilities. For that reason, the next section focuses on the ValleyRAT **“Driver Plugin**”, particularly its embedded kernel-mode rootkit.
The ValleyRAT rootkit module is embedded inside one of the “main” plugins, originally named `驱动插件` (EN: `Driver Plugin.dll`). This plugin is compiled in both 32-bit and 64-bit variants and acts as the user-mode client and installer for the rootkit. The embedded driver itself, however, is always a 64-bit kernel-mode binary. It functions as a Windows kernel device, a file system minifilter, a registry filter, and a process/thread monitoring driver.
The user-mode client ( `Driver Plugin.dll`) serves as the controller for the kernel rootkit. It maintains an active TCP/UDP connection to the C2 server and processes inbound commands. Each command is translated into an appropriate **IOCTL request**, which is then sent to the driver to control its runtime behavior. Supported operations include:
**Driver Installation and Initial Configuration:**
When executing the driver installation command in **Normal Mode** (calling `DropAndInstallRootkit()` directly), the client drops the embedded driver to disk and installs it as a kernel service named `kernelquick`, creating the corresponding key: `HKLMSYSTEMCurrentControlSetServiceskernelquick`. The service is registered as a `SERVICE_KERNEL_DRIVER` with **demand start**.
During installation, the client writes the initial configuration values used by the driver to hide and protect itself:
`KernelQuick_HideFsFiles(list of files to hide)` `KernelQuick_ProtectedImages(process images to protect)`
Additional configuration values can be set to control stealth and filtering behavior:
`KernelQuick_State(on/off for overall functionality)` `KernelQuick_StealthMode(whether to hide the driver/service)` `KernelQuick_HideFsDirs(list of directories to hide)` `KernelQuick_HideRegKeys(registry keys to hide)` `KernelQuick_HideRegValues(registry values to hide)` `KernelQuick_IgnoredImages(process images to ignore/exclude)` `KernelQuick_hideFS_comprise(additional file hiding rules)`
All these configuration values define the hiding rules, protection lists, and ignore lists the driver uses. Any of them can be updated later through the corresponding IOCTL operations issued by the client (triggered by a command from the C2 server).
**Driver Installation: Stealth Mode (MalSeclogon-Based):**
In addition to the “ **Normal Mode**” of the driver installation described above, the client can also trigger “ **Stealth Mode**”. In that case, the `DropAndInstallRootkit()` function is supplemented by additional routines: `GetProcID_dwm()`, `CreateProcessMalseclogon()`.
This mode primarily aims to **disrupt network connectivity during installation** and use MalSeclogon-based **impersonation** to reduce detection likelihood. To disrupt network connectivity, the client launches commands such as `cmd /c start /min ipconfig /release` and `cmd /c start /min ipconfig /renew`. The MalSeclogon technique is then used to execute these commands under an impersonated context with **PPID spoofing**:
`GetProcID_dwm()locates the PID of` `dwm.exe(Desktop Window Manager) using the` `FILE_INFORMATION_CLASS::FileProcessIdsUsingFileInformation. This approach reliably returns the correct PID without causing false positives.` `TEB → ClientId.UniqueProcessfield to spoof the` `dwm.exe.` `dwm.exeprocess and used to invoke commands via:` `CreateProcessWithTokenW(primary)` `CreateProcessWithLogonW(fallback, maintains` `UniqueProcessvalue.` `DropAndInstallRootkit()occurs during the network disruption window.`
The result is a stealthy installation sequence executed under a trusted Windows process, significantly reducing behavioral detection signals. The following process tree shows how this activity appears when Stealth Mode is used:
**User‑Mode Shellcode Storage and Injection:**
The client also supports **user-supplied shellcode injection**, storing the operator-provided shellcode inside `HKLMSOFTWAREIpDates`.
When commanded, the rootkit retrieves this user-mode shellcode and performs **APC-based injection**:
`dwm.exeduring initial activation`
The embedded 64-bit driver is based on the publicly available open-source project Hidden. The ValleyRAT authors significantly modified the original codebase, introducing refactoring changes, compatibility improvements for recent Windows versions, and entirely new functionality not present in the original project. Like the original _Hidden_ rootkit, the ValleyRAT driver acts as a kernel device, file system minifilter, registry filter, and process/thread monitoring driver.
During initialization, it creates a device named `HiddenGate` and assigns `IrpDeviceControlHandler()` as its device-control dispatcher for IOCTL communication with the user-mode client.
**Differential Analysis Methodology:**
Because the ValleyRAT driver is derived from a publicly accessible codebase, we focused our reverse-engineering efforts on **only the modified functionality** to maximize efficiency.
To accomplish this, we:
This approach allowed us to:
Out of roughly 200 functions, only ~25 remained unmatched, representing the newly introduced ValleyRAT features. From this point on, we could concentrate exclusively on analyzing these new additions. A simplified overview of the modifications between the ValleyRAT rootkit and the original Hidden rootkit is shown below.
**Preserved functionality (from the original Hidden rootkit):**
**Removed functionality:**
**Configuration changes:**
Registry keys used for initialization were renamed or reorganized. These values are remotely configurable via `Driver Plugin.dll`.
**Added functionality:**
`UMInjection()–` `ForceDeleteFile()–` `SetDriverStartType_SystemStart()–`
**Added functionality: UMInjection()**
`UMInjection()` introduces kernel-mode to user-mode APC-based shellcode injection. It is invoked during driver initialization, creating a system thread that executes `UMInjectionRoutine()`.
`UMInjectionRoutine()`:
`HKLMSOFTWAREIpDates` `dwm.exe(hardcoded target)` `UMInject()`
`UMInject()` can also be triggered directly via IOCTL `0x222144` to target any process. It locates a suitable thread, queues a **kernel-mode APC**, and triggers `UMInjectExecShellcode()`, which allocates user-mode memory, writes the shellcode, and queues a **user-mode APC** to execute it.
**Added functionality: ForceDeleteFile()**
`ForceDeleteFile()` is a custom low-level re-implementation of file deletion using direct kernel IRP calls. **It:**
`IRP_MJ_CREATE` `IRP_MJ_SET_INFORMATION(` `FileBasicInformation)` `FileDispositionInformation`
It is triggered:
`0x222140from the user-mode client`
**Added functionality: SetDriverStartType_SystemStart()**
This function updates the `kernelquick` service to use `SERVICE_SYSTEM_START`, elevating persistence from on-demand loading to loading at system startup.
In summary, the comparison between the original Hidden rootkit and the ValleyRAT-adapted variant shows that the authors did not rewrite the rootkit from scratch. Instead, they selectively refactored and modernized the existing codebase to ensure its continued viability on current Windows versions. Most changes revolve around structural refactoring, updated APIs, and compatibility adjustments that allow the rootkit to function reliably on Windows 10 and Windows 11 systems.
The newly introduced components—roughly 25 functions out of an otherwise large and legacy-heavy codebase—represent targeted functionality upgrades rather than a major redesign. These additions primarily reinforce the rootkit’s integration with the wider ValleyRAT ecosystem, improve persistence and communication paths, and address stability issues caused by OS-level changes over the past decade.
Overall, the modifications reflect a pragmatic development approach: preserve the core functionality of a proven rootkit, update the parts that would break on modern systems, and extend the code just enough to support ValleyRAT’s operational requirements. This strategy gives the actor a working kernel-mode stealth component while avoiding the engineering cost and detection risk associated with designing a new rootkit from scratch.
In this publication, we fully dissected the ValleyRAT modular system and mapped out every major component of its architecture. We analyzed all available plugins, documented their capabilities, and provided a comprehensive view of how they operate as part of a larger, well-structured backdoor ecosystem. By sharing these findings, we aim to strengthen the collective understanding of this widespread and actively abused malware family and contribute to better defensive measures across the security community.
Throughout the analysis, one theme remains consistent: the developers behind ValleyRAT possess a deep understanding of internal Windows mechanisms. Many plugins implement functionality that requires reversing complex kernel‑mode and user‑mode structures, undocumented behavior, and sensitive system interactions. The overall design shows a level of consistency across different modules that strongly suggests a small, tightly coordinated development team rather than a loosely assembled collection of contributors.
A significant part of our research focuses on the **ValleyRAT kernel‑mode rootkit** driver. We reverse engineered the **modified variant** used by ValleyRAT and compared it against the **original Hidden** rootkit. Despite relying on an older codebase, the actor successfully adapted it for modern Windows platforms through **refactoring** and compatibility updates. More concerning is the fact that we observed **several in‑the‑wild** samples **signed** with technically **valid** certificates, allowing the driver to load even on **fully updated Windows 11** systems with **all protections enabled**. This highlights a real-world security gap and demonstrates the ongoing operational capability of the threat actor’s tooling.
The broader threat landscape reflects similar trends. More than **85%** of all ValleyRAT samples we observed appeared within the **last six months**, closely correlating with the period shortly after the builder was leaked. With the full build chain now publicly available, continued growth in **ValleyRAT activity** is not only expected but **likely inevitable**, especially as more actors experiment with the leaked tooling.
Finally, the public availability of both the builder and the source code **complicates attribution**. While ValleyRAT has historically been linked to Chinese-affiliated threat activity, including groups like Silver Fox, the current situation makes such **attribution unreliable**. Anyone can now compile, modify, and deploy ValleyRAT independently, blurring previous indicators and making traditional attribution approaches far less meaningful.
ValleyRAT has effectively transitioned from a previously actor-linked threat to an openly available malware framework with an active and accelerating presence in the wild. Our goal with this research is to provide defenders with the technical depth needed to **understand**, **detect**, and **counter** this evolving threat.
Check Point Threat Emulation and Harmony Endpoint provide comprehensive coverage of attack tactics, filetypes, and operating systems and protect against the attacks and threats described in this report.
CPR – Chasing the Silver Fox: Cat & Mouse in Kernel Shadows: https://research.checkpoint.com/2025/silver-fox-apt-vulnerable-drivers/
CPR – Generative AI as a Force Multiplier for Reverse Engineering: https://research.checkpoint.com/2025/generative-ai-for-reverse-engineering/
ValleyRAT builder: https://github.com/GkaMei/winos4.0
ValleyRAT development structure: https://github.com/Logkiss/Rat-winos4.0-gh0st/tree/master/银狐Winos
Original “Hidden” rootkit driver: https://github.com/JKornev/hidden
Sun-RAT company website: https://www.sun-rat.com/
Detect-It-Easy tool: https://github.com/horsicq/Detect-It-Easy
Resource Hacker tool: https://www.angusj.com/resourcehacker/
LIEF: https://lief.re/
Microsoft Driver Signing Policy – Exceptions: https://learn.microsoft.com/en-us/windows-hardware/drivers/install/kernel-mode-code-signing-policy–windows-vista-and-later-#exceptions
Microsoft Vulnerable Driver Blocklist: https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/design/microsoft-recommended-driver-block-rules
MalSeclogon: https://github.com/antonioCoco/MalSeclogon
Diaphora IDA plugin: https://github.com/joxeankoret/diaphora
Table providing details about the EDR/AV drivers targeted by `ForceDeleteFile()` during the ValleyRAT rootkit driver initialization.