Cracking ValleyRAT: From Builder Secrets to Kernel Rootkits

Highlights:

• 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.
• By analyzing the publicly leaked builder and development structure (Visual Studio solutions and project files, without source code), we were able to accurately correlate artifacts and reverse engineer the functionality of all “main” plugins. The analysis reveals the advanced skills of the developers behind ValleyRAT, demonstrating deep knowledge of Windows kernel and user-mode internals, and consistent coding patterns suggesting a small, specialized team.
• The “Driver Plugin” contains an embedded kernel-mode rootkit that, in some cases, retains valid signatures and remains loadable on fully updated Windows 11 systems, bypassing built-in protection features. Through detailed reverse engineering, previously unknown capabilities were uncovered, including stealthy driver installation, user-mode shellcode injection via APCs, and forceful deletion of AV/EDR drivers.
• The detection statistics for ValleyRAT plugins in the wild (ITW), derived from carefully crafted detection rules and verified using both internal telemetry and public services, highlight the recent surge in ValleyRAT usage, with approximately 85% of detected samples appearing in the last six months, coinciding with the public release of the builder.
• The research underscores the growing accessibility of the ValleyRAT builder and development artifacts, emphasizing that future usage cannot be easily attributed to specific Chinese-speaking threat actors, such as Silver Fox.

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 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.

Background & Key Findings

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:

1. The ValleyRAT developers stole the source code of Sun‑RAT and built their backdoor on top of it, or
2. The leaked ValleyRAT source code was repurposed to create a commercial product marketed as a legitimate Chinese tool.

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.

Technical Analysis: ValleyRAT Builder

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:\Windows\System32 --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.

ValleyRAT Builder: Main Plugins

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.

ValleyRAT Builder: Auxiliary Plugins

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.

Technical Analysis: ValleyRAT Rootkit Plugin

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.

ValleyRAT Rootkit Plugin: User-Mode Client

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 (Normal or Stealth mode)
• Enable or disable the driver
• Query driver state
• Add or remove hidden objects (files, directories, registry keys, and registry values)
• Add or remove protected processes
• Enumerate protected objects
• Force-delete arbitrary files
• Trigger user-mode shellcode injection via the rootkit driver
• Update driver configuration values

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: HKLM\SYSTEM\CurrentControlSet\Services\kernelquick\. 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:

1. 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.

2. The client temporarily modifies the TEB → ClientId.UniqueProcess field to spoof the PPID to dwm.exe.
3. Token objects are stolen from the dwm.exe process and used to invoke commands via:
   • CreateProcessWithTokenW (primary)
   • CreateProcessWithLogonW (fallback, maintains PPID spoofing but without impersonation)

4. After the commands are executed, the client restores the original UniqueProcess value.
5. Driver installation via 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 HKLM\SOFTWARE\IpDates.

When commanded, the rootkit retrieves this user-mode shellcode and performs APC-based injection:

• Into dwm.exe during initial activation
• Into any process ID supplied via IOCTL

ValleyRAT Rootkit Plugin: Kernel-Mode Rootkit Driver

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:

1. Rebuilt the original Hidden rootkit using the configuration extracted from the leaked ValleyRAT Visual Studio project.
2. Loaded the rebuilt driver into IDA, applied the PDB symbols, and created strict FLIRT signatures.
3. Generated a Diaphora database for structural diffing.
4. Loaded the ValleyRAT driver, applied the FLIRT signatures, and created its own Diaphora database.
5. Performed a differential analysis between the two drivers.

This approach allowed us to:

• Automatically match preserved functions
• Ignore superficial edits
• Highlight substantial refactoring
• Isolate genuinely new ValleyRAT functionality

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.

Summary of Changes (ValleyRAT vs. Hidden rootkit)

Preserved functionality (from the original Hidden rootkit):

• Registry hiding (keys and values)
• File and directory hiding
• Process protection (setting limited access to processes)
• Process exclusion lists (exclude specific processes from protection features)

Removed functionality:

• Process hiding (unlinking from active process lists) – Removed entirely due to BSOD risk triggered by modern Windows mitigations such as PageGuard.

Configuration changes:

Registry keys used for initialization were renamed or reorganized. These values are remotely configurable via Driver Plugin.dll.

Added functionality:

1. UMInjection() – APC-based user-mode shellcode injection
2. ForceDeleteFile() – kernel-level forced deletion of arbitrary files
3. SetDriverStartType_SystemStart() – elevated persistence by switching service start type

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():

• Retrieves stored shellcode from HKLM\SOFTWARE\IpDates
• Locates dwm.exe (hardcoded target)
• Passes its PID to 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:

• Opens files via a custom IRP_MJ_CREATE
• Resets attributes via IRP_MJ_SET_INFORMATION (FileBasicInformation)
• Marks files for deletion via FileDispositionInformation
• Temporarily detaches section objects to bypass file locks, including memory-mapped executables

It is triggered:

• Automatically during driver initialization (see Appendix A – Targeted Deletion of EDR/AV Drivers)
• Via IOCTL 0x222140 from 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.

Conclusion

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.

Protections

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.

References

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

Appendix A – Targeted Deletion of EDR/AV Drivers

Table providing details about the EDR/AV drivers targeted by ForceDeleteFile() during the ValleyRAT rootkit driver initialization.

Appendix B – IOCs