Key Points

• Check Point Research (CPR) has discovered that certain AI assistants that support web browsing or URL fetching can be abused as covert command-and-control relays (“AI as a proxy”), allowing attacker traffic to blend seamlessly into legitimate, commonly permitted enterprise communications.
• This technique was demonstrated against platforms such as Grok and Microsoft Copilot, leveraging anonymous web access combined with browsing and summarization prompts
• The same mechanism can also enable AI-assisted malware operations, including generating reconnaissance workflows, scripting attacker actions, and dynamically deciding “what to do next” during an intrusion.
• CPR outlines a near-term evolution in malware development, where implants shift from static logic to prompt-driven, adaptive behavior that can autonomously plan operations, prioritize targets and data, and adjust tactics in real-time based on environmental feedback.

Introduction

AI is rapidly becoming embedded in day-to-day enterprise workflows, inside browsers, collaboration suites, and developer tooling. As a result, AI service domains increasingly blend into normal corporate traffic, often allowed by default and rarely treated as sensitive egress. Threat actors are already capitalizing on this shift. Across the malware ecosystem, AI is being used to accelerate development and operations: generating and refining code, drafting phishing content, translating lures, producing PowerShell snippets, summarizing stolen data, assisting operators with next decisions during an intrusion, and, in extreme cases, developing full C2 frameworks such as Voidlink. The practical outcome is simple: AI reduces cost and time-to-scale, and helps less-skilled actors execute more complex playbooks.

But the next step is more consequential: AI isn’t only helping attackers write malware, it can become part of the malware’s runtime. In AI-Driven malware, the implant’s behavior is shaped dynamically by model output. Instead of relying solely on hardcoded decision trees, an implant can collect host context such as environment artifacts, user role indicators, installed software, domain membership, and geography, and use a model to triage victims, choose actions, prioritize data, and adapt tactics. This prompt-driven approach can make campaigns more flexible and harder to predict, especially as it shifts decision-making away from static code and toward external reasoning.In this research, Check Point Research demonstrates a concrete building block that connects these trends: AI assistants with web-browsing and URL-fetch capabilities can be abused as covert command-and-control relays, effectively using AI as a C2 proxy. We show how Grok and Microsoft Copilot can be driven through their web interfaces to fetch attacker-controlled URLs and return responses, creating a bidirectional channel that tunnels victim data out and commands back in. Crucially, this can work without an API key or a registered account, reducing the effectiveness of traditional kill switches such as key revocation or account suspension.

We then connect the technique to the broader trajectory: once AI services can be used as a stealthy transport layer, the same interface can also carry prompts and model outputs that act as an external decision engine, a stepping stone toward AI-Driven implants and AIOps-style C2 that automate triage, targeting, and operational choices in real time.

AI-Driven (AID) Malware

AI-Driven malware is malware that uses an AI model as part of its runtime decision loop, not just during development. Instead of executing a fixed, preprogrammed flow, the implant collects local signals from the infected host and uses a model to interpret them and decide what to do next. In practice, the model output can influence which capabilities are activated, which targets or data are prioritized, how aggressive the malware should be, and whether the host is worth continuing to operate on. This shifts part of the malware’s logic from static code into model-driven, context-aware behavior, which can make campaigns more adaptive and less predictable than traditional rule-based decision trees.

A useful way to think about AID malware is that the model becomes an external or internal decision engine. The implant provides a compact “situation report” (environment artifacts, user and domain context, installed software, file and process metadata, observed security controls, and other host indicators) and receives back guidance that can shape subsequent execution. Over time, this enables behavior that is more tailored per-host, can change across infections without code changes, and can reduce repeatable patterns that defenders often rely on for signatures and sandbox detonation.

There are two primary integration approaches:

1. API-based integration

• The malware interacts with a remote model or agent through an API. That model can be hosted by a mainstream provider, a niche platform, or attacker-controlled infrastructure running an agent. This approach is operationally flexible and keeps the implant lightweight, but it introduces network dependencies and creates telemetry that defenders may be able to hunt for. It can also create a potential kill switch if the workflow depends on revocable credentials, unless the actor can blend or relay the traffic through intermediate layers.

2. Embedded model

• The model is packaged locally, either inside the binary or as a bundled component. This removes the need for external inference calls and can reduce network exposure, but it increases payload size and resource requirements, and makes model updates harder. In real-world terms, embedded approaches trade operational convenience for stealth and independence from external services.

AI Agent As A C2 Proxy

Abusing legitimate services for C2 is not new. We’ve seen it with Gmail, Dropbox, Notion, and many others. The usual downside for attackers is how easily these channels can be shut down: block the account, revoke the API key, suspend the tenant. Directly interacting with an AI agent through a web page changes this. There is no API key to revoke, and if anonymous usage is allowed, there may not even be an account to block.

Our proposed attack scenario is quite simple: an attacker infects a machine and installs a piece of malware. Then the malware communicates directly with either Grok or Copilot through the web interface, sending a prompt that causes the AI agent to issue an HTTP(S) request to an attacker-controlled URL, retrieve content from that site, and return the attacker’s response via the AI output back to the malware.

Web App PoC

To test if our attack scenario is possible, we have set up two basic requirements:

• No authentication requirement: zero restrictions on the request, no account, no API key.
• Arbitrary web fetch with data in and out: the AI must be able to fetch a website we control, carry data in query parameters, and return content from that site in its response.

We found two AI providers that meet these requirements: Grok and Copilot. There were some minor restrictions, such as not being able to send data to direct IPs or plain HTTP, so we set up a fake HTTPS website to serve as our C2 server. We registered a domain, deployed a simple site, and in the spirit of things, let AI help us generate the entire thing.

The result is a Siamese cat fan club website. One of the pages is a “breed comparison” page. For example, we can ask Copilot at https://copilot.microsoft.com to summarize that page; no account is needed. The same applies to Grok at https://grok.com.

Now, in a real attack scenario, we would want to send data to the C2 (for example, the result of system reconnaissance on the infected machine) and receive data back (a command or at least an acknowledgment). That’s easy: we append the data, in some structured format, to the URL’s query parameters. There do appear to be safeguards: if we make it too obvious that we’re sending clearly malicious or sensitive data, some services try to block or sanitize it. However, simply encrypting or encoding the data in a high-entropy blob is enough to bypass these checks.

On the server side, we set up a breed comparison table, comparing different cat breeds. But one can’t really compare a cat breed without knowing what the cat breed’s “favorite Windows command to execute” is. For “stealth”, we made the page only display this command column when the my_breed_data URL parameter is present. We instruct the AI to visit the page and “return the cat’s favorite Windows command” based on a pattern embedded in the HTML.

As shown in the image, both Grok and Copilot gladly followed up on our prompt, fetched our site, and returned a response containing the command we planted. Of course, in a real attack, this command (or the whole payload) could be further encoded or encrypted to avoid triggering any model-side safeguards.

This demonstrates the feasibility of implementing the behavior end-to-end in a browser with no logged-in user. The next question is: how would actual malware do this from software, without relying on a visible browser window or any human interaction?

WebView Instead of API

Confirming that the technique works in a regular browser is one thing. Making it usable from malware is another. For our PoC, we set ourselves a constraint: get it working in C++, without relying on a direct API key or random HTTP requests to the AI provider’s website. Sending raw HTTP requests that don’t look like a normal browser session is more likely to hit rate limits, CAPTCHA, or behavioral checks. Instead, we decided to emulate a browser from within our C++ program.

For that, we used WebView2, an embedded browser component that lets native Windows apps display and interact with web content. The WebView2 runtime is preinstalled on all Windows 11 systems and has been broadly rolled out to modern Windows 10 versions via updates. Even if it’s missing, an attacker could bundle it with the malware or download it on first run.

Using WebView, we created a quick PoC: a C++ program that opens a WebView pointing to either Grok or Copilot. From there, we have two slightly different flows:

• Grok: Once the page is loaded, we can inject our prompt directly into the q parameter in the URL, and Grok will automatically follow our prompt without any further steps.
• Copilot: the flow is a bit trickier and uses JavaScript inside the loaded page to submit the prompt to the Copilot UI.

Either way, it works. Our program does the following:

1. Enumerate some basic information about the machine.
2. Append it to the URL of our fake Siamese cat C2 site
3. Open a (hidden) WebView window to the AI provider’s website.
4. Ask the AI to fetch and “summarize” that URL.
5. Parse the AI’s response and act on the embedded command.

WebView is just one example of how to do this in C++. Other platforms and languages have similar embedded browser controls that can achieve the same goal.

The PoC we created is intentionally simple, but it can easily be extended to behave more like real-world malware. In a full implementation, the implant could first send host enumeration data and register itself with the C2 server. The C2 server could then instruct the backdoor to sleep, collect additional information, check in at a later time, download further payloads, or execute arbitrary commands. None of this would be difficult to achieve once we have demonstrated that a bidirectional communication channel between malware and a C2 server can be established through an AI agent. Once the PoC was functional, we responsibly disclosed these findings to the Microsoft security team and the xAI security team.

Many More Possibilities

This technique is one example of how a threat actor can abuse an AI web app by using it as a proxy for C2, but it is far from the only option. The same interface could be used to request AI-generated commands to locate files, enumerate the system, search for sensitive data, or generate PowerShell code to move laterally across the network. Instead of relying on a skilled human operator, malware could directly task an AI agent for what to do next.

Beyond direct command generation, an attacker could also rely on AI to handle decision-making logic that is usually embedded in the malware itself. For example, an implant might send a short description of the host (domain, user role, installed software, geography) and ask the AI whether this system is worth further exploitation, which tools to deploy next, or how aggressively to move laterally without raising suspicion. The agent’s response would then shape the rest of the campaign, effectively turning the AI into a remote “brain” for the malware.

In the rest of this article, we focus on broader AI-Driven (AID) malware concepts and how future campaigns may integrate AI into their decision-making and operations. Our goal is not just to highlight one clever C2 trick, but to show how the same building blocks, web-accessible AI agents, and flexible prompts evolve into full AI-assisted attack workflows.

(Near)-Future AI-Driven Malware

While current AI-Driven (AID) threats have not yet been utilized in an optimal way, the practical impact of AID malware or AI-assisted attacks remains limited, largely experimental, inconsistent, or easily replicable using traditional decision-tree logic.

However, we can identify at least one major area where AI could become pivotal in the future: data analysis and infection targeting. AI has the potential to dramatically accelerate the identification of valuable data within compromised systems, the prioritization of targets, and the optimization of infection spread. By automating reconnaissance and decision-making steps that currently require human effort, AI could enable attackers to execute campaigns much faster and with greater precision. This capability, when it matures, could mark a significant turning point in how cyberattacks are conducted, shifting the balance between speed, accuracy, and scale in favor of malicious operators.

The three future AI use cases mentioned below represent the scenarios we believe will genuinely advance threat actors’ capabilities. At the core of these developments lies one central concept: data analysis and infection targeting.

As some of these techniques may already be implemented, we assess that in the near future, the methods described below will be expanded upon and widely adopted by threat actors, particularly those capable of leveraging advanced AI-driven capabilities.

AID – Anti-Sandbox Technique

The majority of modern malware families are designed to collect detailed system information from infected machines. This typically includes data such as the username, domain name, computer name, installed software, running processes, startup programs, and other environment details. Such reconnaissance allows the malware to better understand its execution context, whether it’s operating within a corporate network, a sandbox, or a personal device, and to adjust its behavior accordingly.

A potential future scenario involves a Remote Access Trojan (RAT), infostealer, Loader, or similar type of malware leveraging an AI model or API as part of its operational logic. In this case, the malware could utilize a predefined prompt combined with system data it has already collected and send this information to an AI service. The AI agent would then analyze the data and determine the likelihood that the environment is a real target or a sandbox used for malware analysis.

This method could function as an advanced AI anti-sandbox and environment validation technique. Instead of relying solely on hardcoded checks or local heuristics, the malware could offload the decision-making process to a remote AI system. If the AI’s response indicated “no sandbox detected,” the malware could proceed to execute its full capabilities, including data exfiltration, persistence installation, and communication with its C&C.

If malware begins to outsource environment verification to AI services, detecting and attributing infections will become significantly harder. An AI-Driven validation step can cause sandboxes and automated analysis tools to fail to trigger malicious behavior, because the payload may remain dormant until a remote model confirms the host is a “real” target. As a result, traditional signature- and sandbox-based detection pipelines may produce fewer observable indicators, while telemetry that would normally reveal malicious activity may never appear in analyst environments. This reduces the visibility defenders rely on and increases the chance that sophisticated campaigns slip through initial analysis windows.

AID – Command and Control Servers

While communicating with an AI API endpoint or embedding a model locally can generate noisy telemetry, a more subtle application of AI could occur at the Command and Control. C&C servers could use AI to automatically identify and categorize compromised hosts. For example, an AI-Driven triage step might discard obvious sandboxes and withhold second-stage payloads from those hosts.

Beyond sandbox detection, AI applied at the C&C could score victims based on available PII. This enables prioritization of follow-on actions and lateral movement. Once AI determines that an infection is a high-value target (such as corporate accounts or servers), the bot will receive different commands from the C&C, and distinct workflows will be applied to this infection, including a notification to prioritize the “manual” lateral movement. In the other case, the C&C might deploy a simple miner to a low-value victim, as further actions might not be of interest to the threat actor.

Another potential implementation would mirror the concept of MCP servers, but instead of integrating various red-teaming tools, the attacker could connect an existing malware family directly to an MCP server.

AID – Ransomware, Wipers & Data Exfiltration

The same concept used to identify valuable users or high-value targets can also be applied to files. An AI model could score which files are worth encrypting or exfiltrating based on metadata (file names, sizes, creation and modification timestamps, paths, …), as well as their content. By prioritizing high-value files, an attacker can accelerate encryption or data theft while generating far fewer I/O events, thereby reducing the likelihood of triggering volume-based alarms and increasing the chances of ignoring decoy or bait files.

Many ransomware detection workflows in XDRs rely on volume or rate thresholds and therefore only declare malicious activity after a sizable number of files have been encrypted. If an attacker limits activity to a much smaller, carefully chosen pool of files, this can undermine those heuristics and create detection gaps.

In a notable 2022 analysis, Splunk researcher Shannon Davis measured the time it takes several prominent ransomware families to encrypt large volumes of data, reporting times that ranged from a couple of minutes for the fastest families to several hours for slower ones. These experiments showed that some ransomware variants can encrypt ~100 GB in a matter of minutes.

The worrying question for AI-Driven ransomware is straightforward: What if an attacker does not need to encrypt 100 GB to achieve their objective? If an AID payload can prioritize and target only a small set of high-value files (for example, critical databases, business documents, or encryption keys) using model-driven scoring, the time to accomplish effective damage could be dramatically less than the bulk-encryption numbers. In other words, targeted encrypt-and-extort campaigns could succeed in seconds or minutes while generating far fewer observable file-I/O events. The same dynamics apply to data exfiltration, where ransomware groups frequently steal sensitive data and then publish it on their onion sites or leak it on their leak blogs.

Advanced persistent threat (APT) actors customize their malware and prompts to fit the target’s profile, infrastructure, and the value of the data they expect to find. For example, attackers focused on defense contractors, research labs, or critical infrastructure operators will prioritize reconnaissance and payloads that can discover, collect, and exfiltrate technical schematics, classified reports, or proprietary designs. Ignoring unwanted documents that could potentially cause high-volume data exfiltration.

AID wipers may target specific files instead of everything to take down a specific machine. Or wipers may avoid taking down the machine and instead target specific programs, making various processes unusable.

(Near)-Future AI-Driven Campaigns

While we previously discussed how AI-Driven (AID) malware could eventually find its optimal use cases, this section outlines how such implementations may realistically occur. Although AID Embedded-Model malware offers superior stealth, as no input or output is observable by external AI providers (such as OpenAI, Anthropic, and Gemini), we believe that AID API-Based implementations will likely be preferred. This is primarily due to practicality, embedding or bundling a model significantly increases the binary size, which usually goes against the common preference for lightweight payloads. Currently, there is a growing number of AI platforms advertising malicious capabilities, such as FraudGPT, EvilAI, MalwareGPT, etc., which could theoretically be used to power API-based AID malware. However, from a defensive standpoint, these connections are relatively easy to detect just by blacklisting known malicious domains. For an AID API-based approach to achieve real stealth, threat actors would need to employ AI proxy servers to relay requests to these malicious AI platforms. This setup would conceal direct communication with the malicious AI service, making network detection challenging. Alternatively, attackers could host their own local AI model on a remote server. In that case, the server would operate more like an AIOps Command and Control Server (AIOps-C&C) rather than a mere proxy, enabling AI-assisted decision-making and automation while keeping communication hidden within the attacker’s infrastructure.

Conclusion

AI assistants are no longer just productivity tools; they are becoming part of the infrastructure that malware can abuse. In this research, we showed how Grok and Microsoft Copilot can be driven through their web interfaces and abused as covert C2 relays, without any API keys or user accounts. By combining a simple “C2 website” with a WebView2-based C++ implant, we demonstrated a full end-to-end path in which victim data flows out via URL query parameters, and attacker commands flow back in through AI-generated responses.

More importantly, this is not a one-off trick. Any AI service that exposes web fetch or browsing capabilities, especially to anonymous users, inherits a similar level of abuse potential. Today, that may look like a creative way to hide C2 in “normal” AI traffic. Tomorrow, the same pattern can evolve into fully AI-Driven malware and AIOps-style C2, where models help decide which hosts to keep, which files to steal or encrypt, and when to stay dormant to avoid sandboxes and detection.

This is a service-abuse class of issue, not a traditional memory corruption bug. Mitigations, therefore, require changes on both sides. AI providers need to harden web-fetch features, enforce authentication, and give enterprises greater control and visibility into how their models access external URLs. Defenders need to start treating AI domains as high-value egress points, monitor for automated and unusual usage patterns, and incorporate AI traffic into their hunting and incident response playbooks.

As AI continues to integrate into everyday workflows, it will also integrate into attacker workflows. Understanding how these systems can be misused today is the first step toward hardening them for the future, and ensuring that AI remains more useful to defenders than to the malware that tries to hide behind it.

The post AI in the Middle: Turning Web-Based AI Services into C2 Proxies & The Future Of AI Driven Attacks appeared first on Check Point Research.

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 <file>\t<authentihash>."""
    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.

CN Name	EN Translation	Main Functionality
上线模块	Online Module	Initial-stage module with embedded C2 configuration + remote shellcode execution (in-process by default; optional tracerpt.exe injection)
登录模块	Login Module	Full-featured main-stage agent (login/recon, system fingerprinting, command processing, reflective plugin loading)
播放监听	Playback Monitoring	Remote audio-output capture module (system playback → transmission)
查注册表	Check Registry	Remote Regedit-like module (Windows Registry management)
视频查看	Video View	Remote webcam capture and streaming module
文件管理	File Management	Full-featured remote file management
远程交谈	Remote Chat	Screen-locking module with integrated remote chat
远程终端	Remote Terminal	Interactive remote shell module (cmd.exe)
语音监听	Voice Monitoring	Remote bidirectional-audio module (microphone capture and remote playback)
差异屏幕	Difference Screen	Classic, simple RDP-like control component
代理映射	Proxy Mapping	Multiplexed reverse-proxy module (tunneling multiple TCP/UDP connections over a single control channel)
键盘记录	Keylogger	Keylogger with clipboard harvesting
系统管理	System Management	Remote system-management module (reconnaissance, command processing, process/service control, code injection)
高速屏幕	High-speed Screen	High-frame-rate remote screen capture module
后台屏幕	Background Screen	Advanced hidden RDP-like remote desktop module with web-browser automation
娱乐屏幕	Entertainment Screen	Remote screen-capture video streaming (using libx264)
压力测试	Stress Test	Feature-rich remote DDoS module (supports multiple modes of TCP/UDP/HTTP/ICMP/RawIP floods)
shellcode	shellcode	Identical to the “Online Module”, compiled as PE .exe
驱动插件	Driver Plugin	Advanced driver-related module (rootkit loader and user-mode client)

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.

CN Name	EN Translation	Likely Functionality
telegram打包上传	telegram Package Upload	Package Telegram data and upload it
telegram自动打包	telegram Auto-Pack	Automated packaging for Telegram
UACME	UACME	UAC-bypass framework/helper
企鹅解密	Penguin Decryption	Obtain decrypted QQ/Tencent data
体积膨胀	Volume Expansion	Binary bloating/padding (?)
内网主机扫描	Intranet Host Scan	LAN host discovery and scanning
写启动目录	Write Startup Directory	Set up persistence in the Startup folder
写注册表启动	Write Registry Startup	Set up persistence via Registry autorun entries
删除360急速安全账号密码	Delete 360 Rapid Security Account Passwords	Remove stored credentials from 360 Total Security
删除chrome账号密码	Delete Chrome Account Passwords	Remove Chrome stored passwords
删除ie账号密码	Delete IE Account Passwords	Remove IE stored passwords
删除qq账号密码	Delete QQ Account Passwords	Remove QQ stored passwords
删除skype账号密码	Delete Skype Account Passwords	Remove Skype stored passwords
删除sogou账号密码	Delete Sogou Account Passwords	Remove Sogou stored passwords
删除telegram账号密码	Delete Telegram Account Passwords	Remove Telegram stored passwords
删除自身	Self Delete	Self-removal/uninstaller
微信解密	WeChat Decryption	Obtain decrypted WeChat databases
提权-CreateProcessInSession0	PrivilegeElevation-CreateProcessInSession0	Privilege elevation – create a process as SYSTEM
提权-EnableDebugPrivilege	PrivilegeElevation-EnableDebugPrivilege	Enable debug privilege
提权-RtlAdjustPrivilege	PrivilegeElevation-RtlAdjustPrivilege	Adjust privileges using RtlAdjustPrivilege
提权ShellExecuteEx	PrivilegeElevation-ShellExecuteEx	Privilege elevation using ShellExecuteEx
本地组策略添加启动	Add Startup via Local Group Policy	Set up persistence via Local Group Policy
桌面录制	Desktop Recording	Record the desktop to video
测试	Test	Test plugin
解密数据	Decrypt Data	Generic data-decryption helper
计划任务	Scheduled Task	Create scheduled tasks for persistence
高级浏览器解密	Advanced Browser Decryption	Decrypt browser-stored credentials (Chrome/Edge/IE)

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.

System Path	Company
C:\Windows\System32\drivers\DsArk64.sys	Qihoo 360
C:\Windows\System32\drivers\360AntiSteal64.sys	Qihoo 360
C:\Windows\System32\drivers\360FsFlt.sys	Qihoo 360
C:\Windows\System32\drivers\360netmon.sys	Qihoo 360
C:\Windows\System32\drivers\360AntiAttack64.sys	Qihoo 360
C:\Windows\System32\drivers\360AntiHijack64.sys	Qihoo 360
C:\Windows\System32\drivers\360AntiExploit64.sys	Qihoo 360
C:\Windows\System32\drivers\360AntiHacker64.sys	Qihoo 360
C:\Windows\System32\drivers\BAPIDRV64.sys	Qihoo 360
C:\Windows\System32\drivers\360reskit64.sys	Qihoo 360
C:\Windows\System32\drivers\360qpesv64.sys	Qihoo 360
C:\Windows\System32\drivers\360Sensor64.sys	Qihoo 360
C:\Windows\System32\drivers\360Box64.sys	Qihoo 360
C:\Program Files (x86)\360\360Safe\deepscan\AtS64.sys	Qihoo 360
C:\Windows\System32\drivers\sysdiag_win10.sys	Huorong Security
C:\Windows\System32\drivers\hrwfpdrv_win10.sys	Huorong Security
C:\Windows\System32\drivers\sysdiag.sys	Huorong Security
C:\Windows\System32\drivers\hrwfpdrv.sys	Huorong Security
C:\Windows\Windows\System32\drivers\hrdevmon_win10.sys	Huorong Security
C:\Windows\Windows\System32\drivers\nxeng.sys	Huorong Security
C:\Windows\System32\drivers\TAOAcceleratorEx64_ev.sys	Tencent
C:\Windows\System32\drivers\TAOAccelerator64.sys	Tencent
C:\Windows\System32\drivers\qmbsecx64.sys	Tencent
C:\Windows\System32\drivers\TFsFltX64_ev.sys	Tencent
C:\Windows\System32\drivers\TAOKernel64.sys	Tencent
C:\Windows\System32\drivers\ksapi64.sys	Kingsoft Corporation
C:\Program Files (x86)\kingsoft\kingsoft antivirus\security\kxescan\kdhacker64_ev.sys	Kingsoft Corporation
C:\Program Files (x86)\kingsoft\kingsoft antivirus\security\kxescan\kdhacker64.sys	Kingsoft Corporation
C:\Windows\System32\drivers\kavbootc64_ev.sys	Kingsoft Corporation
C:\Windows\System32\drivers\KAVBootC64.sys	Kingsoft Corporation
C:\Windows\System32\drivers\kisknl.sys	Kingsoft Corporation
C:\Windows\System32\drivers\bootsafe64.sys	Kingsoft Corporation
C:\Windows\System32\drivers\ksthlp64.sys	Kingsoft Corporation
C:\Program Files (x86)\kingsoft\kingsoft antivirus\security\ksde\kisnetflt64.sys	Kingsoft Corporation
C:\Program Files (x86)\kingsoft\kingsoft antivirus\security\ksnetm\kisnetm64.sys	Kingsoft Corporation
C:\Program Files (x86)\kingsoft\kingsoft antivirus\khwinfo64.sys	Kingsoft Corporation
C:\Windows\System32\drivers\klgse.sys	Kaspersky Lab
C:\Windows\System32\drivers\klhk.sys	Kaspersky Lab
C:\Windows\System32\drivers\klflt.sys	Kaspersky Lab
C:\Windows\System32\drivers\klif.sys	Kaspersky Lab
C:\Windows\System32\drivers\klwtp.sys	Kaspersky Lab
C:\Windows\System32\drivers\klim6.sys	Kaspersky Lab
C:\Windows\System32\drivers\klkbdflt2.sys	Kaspersky Lab
C:\Windows\System32\drivers\cm_km.sys	Kaspersky Lab
C:\Windows\System32\drivers\kldisk.sys	Kaspersky Lab
C:\Windows\System32\drivers\klwfp.sys	Kaspersky Lab
C:\Windows\System32\drivers\kneps.sys	Kaspersky Lab
C:\Windows\System32\drivers\klpd.sys	Kaspersky Lab
C:\Windows\System32\drivers\klupd_klif_arkmon.sys	Kaspersky Lab
C:\Windows\System32\drivers\klupd_klif_klbg.sys	Kaspersky Lab
C:\Windows\System32\drivers\klbackupdisk.sys	Kaspersky Lab
C:\Windows\System32\drivers\klupd_klif_klark.sys	Kaspersky Lab
C:\Windows\System32\drivers\klupd_klif_mark.sys	Kaspersky Lab
C:\ProgramData\Kaspersky Lab\AVP21.3\Bases\klids.sys	Kaspersky Lab

Appendix B – IOCs

File Name (EN)	Purpose	Arch	SHA‑256 Hash
Background Screen.dll	Main Plugin	32-bit	7f5bad67cec7492b023ca08e8fa3ed5db9eb186fab0472b34993fe3cb96383be
Background Screen.dll	Main Plugin	64-bit	a57dd44b7bc6233496657867cf053199213289f58c1c3c8d4eb565ed3707deb1
Check Registry.dll	Main Plugin	32-bit	74d70f53748125eb4439cb790817fb1d0e9159f75c7dd5148444f507ba6dee1d
Check Registry.dll	Main Plugin	64-bit	0a6376107abdf30ea14f4bdaf785b2db7d18e0818bd332511dcce3824b8a42b6
Difference Screen.dll	Main Plugin	32-bit	ed4a064ef099e0ea40faf4b1e3618f20c52833b148ae578f80f09eabd2d6acd2
Difference Screen.dll	Main Plugin	64-bit	2c34d8fc0881d3cd4fb693fc5fe2edf405b8424174d3dbb800385fd70969f39d
Driver Plugin.dll	Main Plugin	32-bit	79daa001c67dc83bdd6189417ccf4bf83ea5da4c6211bbac91c1d7d55f76fa5f
Driver Plugin.dll	Main Plugin	64-bit	14b85b07bfdd134e709ff973871d75d33ecca964457373b76b34a70183c2b1d0
Driver Plugin.dll_Driver Functions.sys_KernelQuick_Hidden.sys	Rootkit Driver	64-bit	2aa029088c04eb10b056c18fcc39395936e6f01ee9ebdeed2558e4899116ee86
Entertainment Screen.dll	Main Plugin	32-bit	1bd71ea3b9409a6e86fac12039258f8ed8b59261ff2509673544e4a548987931
Entertainment Screen.dll	Main Plugin	64-bit	13d7380344bf1f9e17e8970c01127a2fe2528d3e640b36ef478ccd4024033411
File Management.dll	Main Plugin	32-bit	61598b986aeaeb24d7565a7bb3a113e61f88b4d4c6169d2bd7fd0b988d3e41c9
File Management.dll	Main Plugin	64-bit	dee2b2da6b917d2dc7d3dcbbd3c505dd4f128c07059659f9e891000faef2512c
High-speed Screen.dll	Main Plugin	32-bit	746f2d5d727511c1bd1ad936f35ac0851a520aadcf201f0d5e23dc6cd728dd4a
High-speed Screen.dll	Main Plugin	64-bit	9dd0e7dccc7105a30b3a71f10126be4ee5a8e770e743fc4f0bbea0e45cafb39f
Keylogger.dll	Main Plugin	32-bit	96c54665cda4f04e9ff60faebcd993d0cf98988258249d9e00fe563be7923899
Keylogger.dll	Main Plugin	64-bit	aaf8258585d086cce588a3e870eb485270ee135087eee9ef8766db9f86677ecd
Login Module.dll	Main Plugin	32-bit	90f24d6175e1b5fac4e2844e77554ff03dec2174f18c07c008699af540fe2788
Login Module.dll	Main Plugin	64-bit	6f79ee17dbb75d1ed7e0535a7b498c2249d538c0836d6ecee16fec491b200ce9
Online Module.dll	Main Plugin	32-bit	9f456f3125d7f6ce907e13ec637b9b8c6e4a43b1c9f352d233cfebbc2d0fff32
Online Module.dll	Main Plugin	64-bit	93e75eada1b8f155bdb41c1af0f7d7ea390b280c6f49c8834c11af2e8f6c3a1c
Playback Monitoring.dll	Main Plugin	32-bit	054a22279de7a8c0fd75a72b39648dd2429bef07c268756087ed96792dde4a4c
Playback Monitoring.dll	Main Plugin	64-bit	860acd2b9aec21cf03e1c5ec8f79b1ef4e7b78eb9ba7a6c0a915586957356aea
Proxy Mapping.dll	Main Plugin	32-bit	5dcde82f7a2db50dddf9b42dab3e3affabedfe237d7c956a1de660a702fa74b6
Proxy Mapping.dll	Main Plugin	64-bit	4d0517229ef88f2410a2a1983eaf4036872911c8cf31c3ceb38c11210d02e91e
Quick.exe	Builder/C2 Panel	32-bit	9e82fe6322585d613c8409fa445394e2e38f24ef85733b8dafcfa3ce8dc23517
Remote Chat.dll	Main Plugin	32-bit	9ec3c31ca3bcdd4597d3e928e36fb0202a5111da7e5d169c58bd97b4ae61ee38
Remote Chat.dll	Main Plugin	64-bit	35fbedfafa9a2267d8eab711ce0e9db66dca304a4b4379d7a965ce3893b51fc1
Remote Terminal.dll	Main Plugin	32-bit	85296ee0d867175da1b790f472824f6e702930676aa9b41c4f40f62f41e91652
Remote Terminal.dll	Main Plugin	64-bit	e22fb0c295eefaeb4b25a0b9038a0c60cec9389b894fa22902a7122ddb8779a2
shellcode.exe	Main Plugin	32-bit	5e4085553f083d1fd31d673f0746670dfc1f9ebb9911f2fe754e59d9ca6176dc
shellcode.exe	Main Plugin	64-bit	dca90d7d9e5770acbd991af69bafa80fe596430c29c78d5036a8fb08ff900e12
Stress Test.dll	Main Plugin	32-bit	d17bf1c3d50bf4acba18418b0cdcc524be268848b15542e4895a74dd0e4606fb
Stress Test.dll	Main Plugin	64-bit	55c07dd40ffcf07d569b8b762513cdbfc51e7a4c77ce6613524794515b7d6682
System Management.dll	Main Plugin	32-bit	7c9554c18a6b8fe87a570dd5cd5a0f041a782fc2424ab02ac675e474e2e0a9ce
System Management.dll	Main Plugin	64-bit	e60298307befa4b22eeedef02019a39c93729567fcd4a7745350fd27a92538bd
Video View.dll	Main Plugin	32-bit	05e578a967168b704d8bdcba95a8d69fdda25854263e037990add05ccb403115
Video View.dll	Main Plugin	64-bit	e19ae27f03c252d4e7b44c462a4edaa1ae759888bcd25cb7863c3c08c35936f1
Voice Monitoring.dll	Main Plugin	32-bit	a38b91c061157011a00d29c5e3169fbf2b29c0b0cacc0153dc0cf9918e92c9b7
Voice Monitoring.dll	Main Plugin	64-bit	b5949ce7e802740e9548ba83ccdb20470fa405fdf9866b3fc3f85a393882

The post Cracking ValleyRAT: From Builder Secrets to Kernel Rootkits appeared first on Check Point Research.