Attackers typically try to pass off malware as legitimate applications or as potentially unwanted programs that users deliberately search for and download, such as cheats or cracks. They often rely on ad and affiliate networks to deliver their creations to victims’ devices. This post examines a less conventional case: a well-known backdoor distributed under the guise of adware. The attackers may have chosen this distribution method because the adware was signed by the developer. On top of that, users often manually add these apps to exclusions, so their useful features don’t get blocked.

Some time ago, a client asked us to analyze a file with the MD5 hash c24e99f9437feacaa63766a3cde3fe3d and add it to our detection database. We initially classified it as adware, but a cursory analysis turned up suspicious network activity, which prompted us to dig deeper. It turned out the sample did far more than serve ads. In fact, its advertising functionality doesn’t even work; instead, it triggers an infection chain that delivers the ValleyRAT backdoor.

Malicious installer

The file the client shared with us turned out to be an installer that performed different actions depending on the two-letter suffix used in the file name, positioned just before the numeric string.

These actions are most likely designed to divert the user’s attention away from the sample’s malicious functionality. Regardless of the file name, the installer deploys a modified Chinese desktop wallpaper management tool called QN Wallpaper (hxxps://qnwallpaper[.]keansoft[.]cn/) and adds it to the registry’s autorun entries.

The original version of QN Wallpaper is genuine adware: on installation, it delivers bundled partner apps to the device and then displays ad banners to the user. In this case, however, the attackers use it to carry out DLL sideloading, a technique that allows malicious code to run under the guise of a signed process by way of a malicious DLL.

The QN Wallpaper modules, along with the malicious components, are unpacked to C:\Program Files\QNWallpaper\5.4.0.1662\<random string of letters and digits>. The following files are saved in that directory:

After unpacking, the installer uses the DisableAntiSpyware registry key to disable Windows Defender and then launches QnWallpaper.exe.

Disabling Windows Defender

DLL Sideloading via libcef.dll

QnWallpaper.exe has dependencies in libcef.dll, so this library gets loaded when the process starts. QnWallpaper.exe also launches QnwPlayer.exe, which likewise calls libcef.dll.

QnWallpaper and QnwPlayer won’t actually function correctly, because the functions exported from libcef.dll are put into an infinite sleep. However, in case that sleep is ever interrupted, the attackers have implemented a function that loads all the necessary functions from the original library into memory, provided it can locate that library on the system.

Example of an exported function

Loading functions from the original libcef.dll

The malicious functionality in libcef.dll is invoked by a call to DllMain, which runs automatically when the library is loaded. That said, alongside the original exports, the library also contains a function named RunDLL, which likewise initiates execution of the malicious code. QnWallpaper never calls this function. We suspect the attackers intended to invoke it manually via rundll32 or planned to use a separate executable for this purpose, one that wasn’t included in the package downloaded by the sample.

The RunDLL function

Running the malicious code

When the library is loaded, code runs that ensures QnWallpaper.exe persists at startup: it adds a file extension association and drops a file with the corresponding extension in C:\Documents and Settings\<username>\Start Menu\Programs\Startup\.

This is followed by a chain of wrapper functions whose main job is to call the next one. Execution eventually reaches the function that contains the actual malicious code. For convenience, we’ll refer to it as mw_entry.

Inside mw_entry, the malware checks two things:

• Whether the current user belongs to the Administrators group
• Which process the DLL is running inside

Checking for administrator privileges

If the user isn’t a member of the Administrators group, the program attempts to obtain administrator privileges by using the runas utility.

Relaunching the process to obtain administrator privileges

Once it has administrator privileges, the malicious code determines which process the DLL has been loaded into, and selects the payload accordingly:

• If the library is running inside QnWallpaper.exe, the payload is loaded from the PeLoader file.
  

  Encrypted payload

• If the library is running inside QnwPlayer.exe, the payload is loaded from libcef.dll resources.
  

  Retrieving the payload from a resource

Both payloads are AES-encrypted DLLs that contain the ValleyRAT backdoor. The only difference between them is their configuration, specifically, the C2 server addresses. After decryption, libcef.dll checks the magic signatures in the resulting PE file’s headers to confirm the sample is valid. If this check fails, the library releases its resources and takes no further action.

Validating the PE file headers after decryption

If the headers check out, libcef.dll loads the payload into the process’s memory space and hands control over to the backdoor by calling DllMain.

Calling DllMain

ValleyRAT

ValleyRAT begins its operation by parsing its configuration, which consists of key:value pairs concatenated into a single string. To obfuscate this configuration, the attackers wrote the string in reverse.

Obfuscated configuration

During parsing, the backdoor restores the correct character order and reads the key values one by one. The set of keys is the same regardless of which process the backdoor is running in.

Parsing the configuration

Some of the configuration fields are listed below:

The backdoor uses several techniques to protect its process. Some are configuration-dependent, while others are always applied:

• Injecting code into svchost to restart the process: a configurable option. The backdoor allocates memory inside the svchost process, injects code into it, and sets PAGE_NOACCESS permissions on the memory page containing the injected data. It then creates a suspended thread, waits 60 seconds, grants read, write, and execute permissions on the page, and resumes the thread.
  

  Injecting code into svchost

  The function injected into the process has a single job: restart the backdoor if its execution is interrupted for any reason.

  

  Injected function

• Marking its own process as critical (so that terminating it triggers a blue screen of death): a configurable option.
  

  Setting its own process as critical

• Restarting on an unhandled exception. This protection mechanism is always active, regardless of the backdoor’s configuration.
  

  Restarting on exceptions

The backdoor also has spyware functionality. While running, it tracks keystrokes and the currently focused window by using functions from the DirectInput8 library. It also captures clipboard contents. All collected data is saved to a file on disk.

Capturing clipboard data

If the ll key in the configuration is set to 1, ValleyRAT periodically checks for active windows belonging to applications that could be used to analyze processes or traffic. Window enumeration is done via the EnumWindows function, using the following callback:

Window name checks

After completing these checks, the backdoor collects system information, including:

• Host name
• Host IP addresses
• User idle time
• Detailed Windows version information (ProductName, EditionId, DisplayVersion)
• Number of CPU cores
• Free disk space
• Graphics adapter
• Currently focused window and its title
• System bitness
• Language settings
• Path to the system directory

On command, the backdoor can perform the actions typical of this malware category:

• Rebooting the computer
• Shutting down the computer
• Taking a screenshot
• Wiping logs
• Updating its C2 addresses
• Downloading additional modules
• Sending keylogger logs along with clipboard contents

Snippet of the command handler

Let’s take a closer look at the module-loading functionality. Upon receiving the corresponding command with a link from its operator, the backdoor downloads the file at that link and executes it. The download can come from either the C2 server or a third-party address.

The DownloadPeFile function is responsible for downloading a PE file

The DownloadAndExecute function calls DownloadPeFile, then launches the downloaded module

Additional modules can take the form of purpose-built dynamic libraries or shellcode. If the payload is shellcode, the backdoor uses process hollowing with svchost to launch the module.

Implementation of the process hollowing technique

If the module is a dynamic library, the backdoor loads the PE file into its own process, calls DllMain, and searches for a Main function among the exported functions. Once Main has been called, the library is unloaded from memory.

Calling DllMain after the backdoor loads the PE file

Targets and attribution

Over the course of 2026, we detected the ValleyRAT backdoor and its associated malware more than 100,000 times, with more than 1500 unique users affected, primarily in China and India.

This attack geography, combined with the use of the ValleyRAT backdoor, points to Silver Fox, a known operator of this malware family, as the likely group behind the campaign.

Conclusion

This case is a clear example of how adware and affiliate networks can turn out to be far more dangerous than they appear. ValleyRAT is a sophisticated backdoor capable of collecting sensitive data such as keystrokes and clipboard contents, taking screenshots, and delivering additional malicious modules. The attackers exploited a well-known adware application to run the backdoor under the guise of a signed process, which complicates detection.

Motivated by both cyberespionage and financial gain, Silver Fox targets organizations across multiple countries. To stay protected, organizations should keep employee cybersecurity awareness up to date and enforce clear policies on the use of third-party software on work devices.

For individual users, we recommend avoiding the installation of software with a questionable reputation, and, even more importantly, never adding such software to your security solutions’ exclusion lists.

IoC

MD5

07ddbbe2c71c45577a7a4fbcdba0df91
c24e99f9437feacaa63766a3cde3fe3d
8a626d844943da3456b044f38deae3a2

Network

103.45.66.18:441
103.45.66.18:442
103.45.66.18:443
192.253.225.173:6666
192.253.225.173:8888

The vulnerability landscape shifted significantly in Q2 2026. First, the number of registered CVEs reached an unprecedented level. This is driven primarily by the widespread adoption of AI, both for application development and search for security flaws. This resulted in entire new classes of vulnerabilities emerging, particularly in the Linux networking subsystem.

Second, security researchers have been publishing exploits for unpatched vulnerabilities more frequently. Publications like these can generate significant fallout, since they potentially open the door for attackers to target unprotected systems.

Statistics on registered vulnerabilities

This section provides statistical data on registered vulnerabilities. The data comes from Kaspersky’s vulnerability knowledge base, which draws on the CVE database as well as the Russian BDU database and GitHub Advisory (GHSA). As a result, the figures for previous reporting periods may differ from those published in earlier reports.

We examine the number of registered vulnerabilities for each month over the last five years. As the chart below shows, this number continues to surge, a trend reflected across all the databases we track. It’s driven primarily by the widespread adoption of AI tools: as we predicted in our previous report, these tools have played a major role in the discovery of vulnerabilities in third-party software. Meanwhile, these tools often contain security issues of their own. For example, OpenClaw, a popular AI project, ranked 12th among those with the highest number of vulnerabilities discovered and published in Q2, with over 200 CVEs registered during the reporting period. Finally, AI development tools are also contributing to the vulnerability landscape, since the quality of the code they produce can vary widely. Therefore, the rate at which new vulnerabilities are discovered will inevitably keep growing.

Total published vulnerabilities per month from 2022 through 2026 (download)

Next, we analyze the number of new critical vulnerabilities (CVSS > 9.0) over the same period.

Total critical vulnerabilities published per month from 2022 through 2026 (download)

As the chart shows, the number of published critical vulnerabilities jumped sharply in Q2. This is because using AI for vulnerability research makes it possible to analyze massive amounts of previously unexamined code, uncover new attack surfaces, and identify entire classes of vulnerabilities that have gone unnoticed for decades. In particular, AI was used to find a series of Dirty Frag vulnerabilities in the Linux kernel.

Exploitation statistics

This section presents statistics on vulnerability exploitation for Q2 2026. The data draws on open sources and our telemetry.

Windows and Linux vulnerability exploitation

Q2 2026 saw a new precedent in the publication of vulnerabilities in Windows components and exploits for these: researchers no longer waiting for CVE registration, let alone patches. A case in point: a researcher who goes by Nightmare Eclipse (also known as Chaotic Eclipse) published a list of new “named” vulnerabilities across various Windows subsystems. At the time the technical details were published, none of the vulnerabilities had been assigned a CVE identifier:

• BlueHammer: a local privilege escalation vulnerability in Windows Defender. During signature database updates, a time-of-check to time-of-use (TOCTOU) race condition occurs, allowing an attacker to substitute the directory where temporary update files are written. The researcher published a fully functional exploit for the vulnerability.
• RedSun: another logical vulnerability in Windows Defender with a working exploit. Suspicious and malicious files marked as “cloud” can be overwritten or restored to their original directory with elevated privileges. The exploit incorporates fragments of algorithms that make it possible to leverage various logical vulnerabilities in Windows, effectively combining a large number of popular exploitation techniques.
• YellowKey: a vulnerability that lets the user bypass BitLocker full-disk encryption and access system data through the Windows Recovery Environment (WinRE). A fully functional exploit was also published.
• GreenPlasma: a vulnerability that enables system object injection via the CTF loader for the Collaborative Translation Framework (CTFMON) service in Windows. The original publication included an exploit with limited functionality.
• RoguePlanet: yet another Windows Defender vulnerability that, like BlueHammer, stems from a TOCTOU issue, this time in the engine responsible for real-time system scanning. The published exploit uses the vulnerability to overwrite the system file wermgr.exe with a malicious one.
• UnDefend: another vulnerability in the Windows Defender service. This time, the exploit causes a denial of service and blocks updates.

Even though such cases remain isolated for now, we believe they’ll grow into a full-fledged trend. Early publication of exploits gives attackers an advantage over software developers, who are left with no time to fix the issues.

Veteran vulnerabilities in Windows software also remain relevant. These are the ones our solutions most frequently detect exploits for:

• CVE-2018-0802: a remote code execution (RCE) vulnerability in the Equation Editor component
• CVE-2017-11882: another RCE vulnerability also affecting Equation Editor
• CVE-2017-0199: a vulnerability in Microsoft Office and WordPad that allows an attacker to gain control over the system
• CVE-2023-38831: a vulnerability in WinRAR that involves improper handling of objects within an archive
• CVE-2025-6218 (formerly ZDI-CAN-27198): another WinRAR vulnerability allowing the specification of relative paths to extract files into arbitrary directories, potentially leading to malicious command execution
• CVE-2025-8088: a vulnerability similar in exploitation method to CVE-2025-6218. The attackers used NTFS Streams to circumvent controls on the directory into which files are being unpacked

The vulnerabilities listed here can be leveraged to gain initial access to a vulnerable system and for privilege escalation. This underscores the critical importance of timely software updates.

That said, the number of Windows users who encountered exploits declined slightly in Q2, hitting an 18-month low.

Dynamics of the number of Windows users encountering exploits, Q1 2025 – Q2 2026. The number of users who encountered exploits in Q1 2025 is taken as 100% (download)

Linux also hit a rough patch in Q2 2026. Specifically, the period saw the disclosure of the Dirty Frag family of vulnerabilities, which lets an attacker reliably escalate privileges within the operating system.

All the vulnerabilities published in Q2 2026 were, in one way or another, related to the Linux caching subsystem. Here are the ones being most actively exploited:

• CVE-2026-31431 (Copy Fail): a local privilege escalation vulnerability in the Linux kernel that lets an unprivileged user modify the page cache and gain root privileges. Especially dangerous for cloud and containerized environments
• CVE-2026-43284, CVE-2026-43500 (Dirty Frag): a family of vulnerabilities in the Linux networking subsystem (IPsec ESP and RxRPC) that lets a local user overwrite the page cache and escalate privileges to root
• CVE-2026-46300 (Fragnesia): a local privilege escalation vulnerability in the Linux kernel related to packet fragment handling and the page cache mechanism. It lets an unprivileged user gain root privileges and is also classified as part of the Dirty Frag family
• CVE-2026-31635 (DirtyDecrypt): a Linux kernel vulnerability that lets a local attacker escalate privileges due to improper handling of decryption operations and page cache data modification
• CVE-2026-43494 (PinTheft): a Linux kernel vulnerability that lets a local user gain elevated privileges due to errors in the memory page pinning mechanism
• CVE-2026-46331 (pedit COW): a vulnerability in the Linux kernel’s traffic control subsystem (tc-pedit) that exploits a flaw in copy-on-write to modify the page cache and subsequently escalate privileges to root

The vulnerabilities described above were quickly embraced by attackers. At the same time, our solutions continue to detect exploitation attempts targeting older vulnerabilities as well:

• CVE-2022-0847: a vulnerability known as Dirty Pipe, which enables privilege escalation and the hijacking of running applications
• CVE-2019-13272: a vulnerability caused by improper handling of privilege inheritance, which can be exploited to achieve privilege escalation
• CVE-2021-22555: a heap out-of-bounds write vulnerability in the Netfilter kernel subsystem
• CVE-2023-32233: another Netfilter subsystem vulnerability that allows for Use-After-Free conditions and privilege escalation through improper processing of network requests

Dynamics of the number of Linux users encountering exploits, Q1 2025 – Q2 2026. The number of users who encountered exploits in Q1 2025 is taken as 100% (download)

In Q2 2026, the number of Linux users who encountered exploits declined slightly compared to Q1. Given that a significant share of new vulnerabilities are tied to the operating system’s caching subsystem, we recommend installing patches as quickly as possible, or disabling vulnerable kernel modules if patching isn’t an option.

Most common published exploits

The distribution of published exploits by software type in Q2 2026 includes categories that haven’t appeared in the sample for a long time. For instance, we’re once again seeing exploits targeting SharePoint. It’s worth noting that while several vulnerability write-ups for Exchange and SharePoint were published during the quarter, most turned out to be fake, AI-generated research. While the articles and exploit source code themselves look fairly polished, they describe nonexistent problems in the software or its components — often close to genuinely vulnerable mechanisms — in order to mislead researchers. This type of attack is aimed at increasing the time it takes to detect real vulnerabilities. In some cases, the description of a nonexistent vulnerability came bundled with completely unrelated malware.

Distribution of published exploits by platform, Q1 2026 (download)

Distribution of published exploits by platform, Q2 2026 (download)

Vulnerability exploitation in APT attacks

We analyzed which vulnerabilities were exploited in APT attacks during Q2 2026. The rankings provided below include data based on our telemetry, research, and open sources.

TOP 10 vulnerabilities exploited in APT attacks, Q2 2026 (download)

In Q2 2026, a trend emerged in APT attacks toward exploiting new vulnerabilities right from the moment they’re published. As before, we’re also seeing a large number of zero-day vulnerabilities. The Langflow vulnerability deserves particular attention: it’s one of the first cases of an APT group exploiting AI technology, which many organizations are only just beginning to integrate. Because most of this tech is proprietary, it has a considerable number of security blind spots. Therefore, given the growing number of AI-based automation tools, we strongly recommend going beyond the usual patching and developing secure procedures for credential use and sensitive data handling in systems that rely on agents and LLMs.

C2 frameworks

In this section, we examine the most popular C2 frameworks used by APT groups and analyze the vulnerabilities targeted by the exploits that interacted with C2 agents in APT attacks.

The chart below shows the frequency of known C2 framework usage in attacks during Q2 2026, according to open sources.

TOP 10 C2 frameworks used by APTs to compromise user systems, Q2 2026 (download)

Sliver, Havoc, AdaptixC2, and Metasploit remain the most widely used C2 frameworks. After studying open sources and analyzing samples of malicious C2 agents that contained exploits, we determined that the following vulnerabilities were utilized in APT attacks involving the C2 frameworks mentioned above:

• CVE-2026-35273: a vulnerability in Oracle PeopleSoft PeopleTools that security vendors classify as server-side request forgery (SSRF). The details of the vulnerability have never been disclosed, although some research covers the post-exploitation steps
• CVE-2023-46604: an insecure deserialization vulnerability in Apache ActiveMQ that allows arbitrary code execution in the context of the service process
• CVE-2024-12356 and CVE-2026-1731: command injection vulnerabilities in BeyondTrust software that allow an attacker to send malicious commands even without system authentication
• CVE-2023-36884: a vulnerability in the Windows Search component that allows commands to be run on the system, bypassing the mark-of-the-web (MoTW) mechanism
• CVE-2025-53770: an insecure deserialization vulnerability in Microsoft SharePoint that allows for unauthenticated command execution on the server
• CVE-2025-8088 and CVE-2025-6218: similar directory traversal vulnerabilities in WinRAR that allow files to be extracted from an archive to a predetermined path, potentially without the archiving utility displaying any alerts to the user

These vulnerabilities show that attackers used them for initial access and privilege escalation on vulnerable systems, setting the stage for launching a C2 agent. They include both zero-day vulnerabilities and fairly well-known security issues.

LLM/AI tool vulnerabilities

This section analyzes data published in Kaspersky’s vulnerability knowledge base. We reviewed the Q2 2026 version of the knowledge base.

As mentioned above, AI tools, plugins, and technologies have proven fairly effective at automating the search for problematic code and anomalous behavior. The high speed at which new vulnerabilities are being discovered has naturally created a need to fix them just as quickly. AI is often used for this too, which increases the volume of code being generated. However, neither code written without human involvement nor AI-generated advice is always correct.

The chart below covers registered vulnerabilities in AI tools for 2025–2026.

Number of published vulnerabilities in LLMs, AI tools, and plugins with similar functionality, 2025–2026 (download)

As the charts show, AI tools are racking up a substantial number of registered vulnerabilities, and that number keeps growing quarter over quarter. It’s also worth looking at how AI tool vulnerabilities break down by type, according to the CWE system:

TOP 6 vulnerability types in products that implement or use AI/LLM logic, 2025–2026

Interestingly, vulnerabilities of an undetermined type have ranked first in every quarter since the start of 2025. Traditionally-made software has the same issue, and it doesn’t look like the growing number of AI tools will fix it. It’s also notable that the list includes classes CWE developers themselves don’t recommend using for vulnerability classification, since they lump together a whole range of more specific types. CWE-284 is an example of this.

Looking at the most common classes, the key issues found in AI-related software can be summed up as follows:

• Inadequate access control over critical system objects
• Improper implementation of authentication and authorization mechanisms
• Injections

It’s worth noting that injection-related vulnerabilities were relatively rare before AI agents took off (previously, they mostly affected web apps). Recently, though, these security issues have become relevant again.

Looking back at a year and a half of the AI boom, one conclusion stands out regarding registered vulnerabilities: AI tool developers are more focused on expanding functionality than on security. This is worth keeping in mind when using these tools. Let’s look at the projects and applications that either integrated AI tools or offered them as the core product. Below is a list of the those with the highest number of registered vulnerabilities for 2025–2026.

TOP AI/LLM-related projects by number of published vulnerabilities, 2025–2026 (download)

Notable vulnerabilities

This section highlights the most significant vulnerabilities published in Q2 2026 that have publicly available descriptions. Since the above already covers several significant vulnerabilities published during the reporting period, this section consists mainly of LLM/AI tool vulnerabilities.

CVE-2026-25253: a gatewayUrl vulnerability in OpenClaw

The issue stems from the fact that the OpenClaw user interface trusts the value of the gatewayUrl parameter passed in the URL and automatically establishes a WebSocket connection to the specified address. During this connection process, it sends an authentication token without any additional user confirmation.

The attack algorithm exploiting this vulnerability works as follows:

1. The application obtains a critical connection address from an external source (the gatewayUrl URL parameter), which is controlled by the attacker.
2. There is no validation before use.
3. The client automatically initiates a connection to the address specified in the parameter, which belongs to the attacker.
4. While connected, the application sends credentials (an access token) to the specified address.

If the attacker obtains a valid token, the consequences depend on that token’s level of access within the system. In general, this could lead to:

• User session compromise
• Execution of operations on the user’s behalf
• Modification of the AI agent configuration
• Unauthorized access to tools and resources connected to the agent
• Under certain OpenClaw configurations, further compromise of the host running the agent

It’s worth noting that the risk of exploitation arises from a combination of several factors: the automatic connection and token transmission, the lack of address trust verification, and the high privileges granted to the local AI agent.

CVE-2026-41948: a path traversal vulnerability in the Dify AI platform

The vulnerability lets an authenticated user craft a request that enables the application to escape its permitted tenant and gain access to internal REST APIs that weren’t meant for that user. The root cause is insufficient normalization and validation of the URL path before it’s passed to the internal service.

Depending on the Dify configuration, the consequences can include:

• Unauthorized access to internal service interfaces
• Breach of isolation between workspaces
• Exposure of internal service information
• Conditions favorable to further attacks when combined with other vulnerabilities

The use of Dify in enterprise AI platforms is particularly risky, since internal services there tend to hold elevated privileges.

CVE-2026-45386: an improper access control vulnerability in Open WebUI

In Open WebUI, pin/unpin operations on messages are write operations, since they modify that message’s metadata (is_pinned, pinned_by, pinned_at). In vulnerable versions, however, before performing these actions, the API only checked for read access to the channel (a chat between a user or group and the AI) containing the message, not permission to modify its content. As a result, a user with a role limited to viewing messages could still change a message’s pinned status.

The vulnerability’s mechanism works as follows:

1. The user initiates an action that changes the state of an object.
2. The application treats this action as a regular read request.
3. Only channel view permission is checked.
4. The application performs a write without verifying the required user authorization.

This violates one of the fundamental principles of access control models — namely, that any operation that changes the state of data must be checked for the appropriate write or moderation permissions, regardless of whether the object itself is readable.

Although the vulnerability doesn’t lead to arbitrary code execution or compromise of sensitive data, it can affect data integrity and collaborative workflows. Potential consequences of exploitation include unauthorized pinning or unpinning of messages, disruption of channel moderators’ and administrators’ activities, changes to the display order of important information, and even the potential spread of false or misleading information by altering the channel containing a pinned message.

Open WebUI is widely used as an interface for interacting with local and enterprise LLMs. In these systems, pinned messages often contain important instructions, announcements, or tips for users. The ability to modify them with minimal privileges can disrupt collaborative workflows, cause confusion, and undermine trust in information published by administrators and moderators.

CVE-2026-45501: a vulnerability in Microsoft Exchange

The vulnerability stems from improper neutralization of user input when generating Exchange web pages. As a result, the browser may interpret specially crafted data as active content instead of plain text.

Although Microsoft categorizes the potential impact of exploiting this vulnerability as spoofing, flaws like this can lead to alteration of displayed content, imitation of trusted interfaces, actions on behalf of the user within an active session, and abuse of user trust.

It’s worth noting that issues like this are still relevant in modern software, given that mechanisms like Content Security Policy and various parsers were specifically created to help developers neutralize dangerous parts of user page content.

Conclusion and advice

Q2 brought the first significant results of AI automation adoption in software development and vulnerability hunting tools. This research shows that beyond traditional patch management, organizations now need real-time monitoring of systems and access controls, since infrastructure and everyday applications now contain far more AI functionality that could lead to compromise.

Accordingly, besides quickly detecting infrastructure vulnerabilities and managing security patches, modern enterprise-grade security solutions need to provide a broad range of preventive measures for tracking the overall health of systems and workstations. Kaspersky Next meets these requirements by combining proactive mechanisms with the ability to respond promptly to emerging threats.

While monitoring Android threats in June 2026, we discovered a new piece of Android malware. What struck us as unusual was that it installed like an ordinary user app yet made no attempt to disguise itself as legitimate software: it had no user interface at all. This led us to suspect the app might be reaching users’ devices without their knowledge. Further investigation confirmed that hypothesis and allowed us to reconstruct the entire infection chain.

Key findings:

• We identified new Android malware: a multi-stage downloader whose ultimate purpose is ad fraud and creation of a proxy botnet.
• The malware spread through the built-in updaters of Android-based automotive head unit firmware. This is the first documented case of malware found on a car head unit with an infection chain specific to that type of device.
• We attribute this activity, with high confidence, to the MoYu Group, an actor linked to the BADBOX botnet.

Kaspersky solutions detect the threats described below under the following detection names:

• HEUR:Trojan-Dropper.AndroidOS.Agent.vu
• HEUR:Trojan-Downloader.AndroidOS.Agent.ov
• HEUR:Trojan-Proxy.AndroidOS.Zhima.*
• HEUR:Trojan.AndroidOS.Vo1d.*

Head unit firmware overview

A head unit is a system that combines multimedia functions with partial control over certain vehicle functions. Head units may come as part of a car’s factory equipment or as an aftermarket upgrade. The main attack vectors for these systems are compromise via physical access and vulnerabilities in the head unit’s OS or components, both of which we’ve covered previously.

In some cases, head units run on Android, primarily because it’s convenient for manufacturers: Android’s source code already accounts for use cases within automotive head units. Android also allows manufacturers to add their own system applications during the build process, which they can use for a range of purposes: customizing the UI, adding system components tailored to the vendor’s needs, and more.

Most apps developed for Android devices can also run on an Android-based head unit, and that is true for malware as well. That said, it’s hard to imagine certain categories of smartphone-targeted malware being used to attack a head unit. Banking Trojans are a good example: since mobile banking is used almost exclusively on smartphones, infecting a head unit with a banking Trojan would be a waste of the attacker’s resources.

It’s worth noting that head units often include SIM card slots and can connect to the internet, enabling features like navigation and software updates. Since a head unit typically holds nothing of value to an attacker, one of the more likely attack scenarios using “classic” Android malware is infecting the device to recruit it into a botnet – similar to attacks on IoT devices.

During our research, we found exactly that kind of malware. The design of firmware for DoFun head units enabled attackers to distribute malware. We notified the vendor about the distribution scheme, and they subsequently reported fixing the security issues.

Below is the entire infection chain:

Head unit infection scheme

Let’s look at exactly how these head units became infected.

The TWCore app

TWCore is a legitimate system application responsible for collecting analytics data and updating the head unit software. Let’s take a closer look at how the update function works.

The process is fairly simple. An MQTT message broker hosted on the subdomain cardoor[.]cn sends a message containing information about the APK files that need to be downloaded and installed on the head unit. Notably, the object describing this message includes an installNotExists field, a Boolean flag that can be set to true or false. This flag allows TWCore to install apps that weren’t originally present on the device.

TWCore only checks whether an app is already installed on the device when installNotExists = false

The APK file is downloaded to <TWCore external cache dir>/push/apk/ for installation.

The path TWCore uses to download APK files

Our telemetry revealed previously unknown malware at these file paths. On top of that, our data indicates that in every observed case, the malware was installed by an app with the package name com.tw.core, which matches the TWCore package name.

Next, we’ll break down the malware installed by TWCore: the JarService dropper.

Stage 1: the JarService dropper

As mentioned earlier, JarService is a small dropper app with no UI of any kind. It decrypts data stored as encrypted blocks within the Trojan’s code. Each block is XOR-encrypted with a single-byte key that shifts linearly from block to block. The decrypted data contains serialized information about the payload version and entry point, along with the malware’s own code for further loading.

Decrypting and deserializing information about the stage 2 payload

In the version of JarService we analyzed, the entry point for the next-stage payload was the wa method of the com.c.j.qbh class.

Stage 2: the loader

This stage’s payload is a malicious loader. Its code contains encrypted strings that are later used as class names to execute the stage 3 payload using the reflection mechanism. The loader sends implant information to one of the attackers’ servers via a POST request. Example of a request to the C2 server:

{
    "userId": "REDACTED",
    "dexVersion": "1.7",
    "dexType": 1,
    "channelId": "2039",
    "packageName": "com.tw.jar1",
    "appVersion": 12,
    "appName": "JarService"
}

In response to the POST request, the C2 server returns a link for downloading the stage 3 payload. An example of a C2 response is shown below.

{
    "code": 200,
    "data": {
        "dexUrl": "hxxp://144.217.243[.]201/vr34der34/dex3.68.png",
        "dexVersion": 3.680,
        "status": 0
    }
}

The Trojan uses the link in the dexUrl field of the data object to download serialized data for loading the next stage. This data begins with a single-byte integer, a key used to decrypt the strings in the loader’s code. Immediately following this number is a four-byte floating-point value used to XOR-decrypt the stage 3 payload, which itself is located after these keys.

Decrypting the stage 3 payload

In the decrypted payload, the entry point is the init method of the com.ast.sdk.BillingMain class, shown in the screenshot below.

Entry point of the stage 3 payload

While analyzing this stage, we noticed that the download link for the next-stage payload includes a version number. We decided to try other version numbers to retrieve different payload versions, and ultimately obtained seven distinct variants, which we list under “Indicators of Compromise” at the end of this report. The earliest version, numbered 3.57, uses a different decoding algorithm than the one described above. This may indicate that an earlier version of the infection chain used a different loader between JarService and the stage 3 payload.

Stage 3: clicker / reverse proxy loader

In this stage, the malware sends a POST request to /cpc/api/task every 90 minutes by default, containing information about the infected device (display resolution, device model, the SSID of the connected Wi-Fi network, MAC address, and so on) along with the Trojan’s configuration version. If the configuration is outdated, the C2 server returns an updated configuration containing new C2 addresses and new paths for sending HTTP requests. An example of a response is shown below. Note that at the time of our research, the most up-to-date configuration version was 3.82.

{
    "code": 100,
    "data": {
        "configVersion": 3.820,
        "hosts": ["hxxp://t2.kshahnd[.]sbs", "hxxp://t2.mdsjhd[.]sbs", "hxxp://t2.nmnsny[.]sbs", "hxxps://t2.nmnsny[.]sbs"],
        "interval": 5500000,
        "reportApi": "/cpc/api/report",
        "tagName": "config",
        "taskApi": "/cpc/api/task",
        "updates": ["hxxp://a2.kshahnd[.]sbs", "hxxp://a2.mdsjhd[.]sbs", "hxxp://a2.nmnsny[.]sbs", "hxxps://a2.nmnsny[.]sbs"],
        "vn": 1.010
    }
}

If the configuration version doesn’t need updating, the C2 server instead returns integer command identifiers, which the attackers refer to as productId. The Trojan maps each identifier to command information, which it stores as a serialized JSON object using the SharedPreferences API. Each identifier also has its own version, expressed as a UNIX timestamp. If the C2 response includes an unknown productId or one whose version is outdated, the malware sends a GET request to the attackers’ server at /cpc/api/xml to retrieve the command contents for all such identifiers. The C2 server responds with command information for each unknown identifier. An example of a response is shown below.

{
    "code": 200,
    "data": [{
        "productId": 979,
        "script": "{\n  \"loadType\": 1,\n  \"reload\": true,\n  \"method\": \"start\",\n  \"url2\": \"hxxp://144.217.243[.]201/vr34der34/sh65.io\",\n  \"md52\": \"de77c3303e93c9450424759f1741441c\",\n  \"name\": \"zhima\",\n  \"className\": \"com.miyc.transfer.Client\",\n  \"thread\": true,\n  \"tagName\": \"loadlib2\",\n  \"params\": [\n    {\n      \"type\": \"Context\"\n    },\n    {\n      \"type\": \"String\",\n      \"value\": \"107.151.248[.]132\"\n    },\n    {\n      \"type\": \"String\",\n      \"value\": \"1002\"\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 1337\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 7777\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 8888\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 15000\n    }\n  ],\n  \"url\": \"hxxp://144.217.243[.]201/vr34der34/sh65.io\",\n  \"md5\": \"de77c3303e93c9450424759f1741441c\"\n}",
        "version": 1778650942
    }, {
        "productId": 1019,
        "script": "{\n  \"loadType\": 1,\n  \"reload\": true,\n  \"method\": \"start\",\n  \"url2\": \"hxxp://144.217.243[.]201/vr34der34/sh65.io\",\n  \"md52\": \"de77c3303e93c9450424759f1741441c\",\n  \"name\": \"zhima\",\n  \"className\": \"com.miyc.transfer.Client\",\n  \"thread\": true,\n  \"tagName\": \"loadlib2\",\n  \"params\": [\n    {\n      \"type\": \"Context\"\n    },\n    {\n      \"type\": \"String\",\n      \"value\": \"128.14.210[.]58\"\n    },\n    {\n      \"type\": \"String\",\n      \"value\": \"1002\"\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 9999\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 7777\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 8888\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 15000\n    }\n  ],\n  \"url\": \"hxxp://144.217.243[.]201/vr34der34/sh65.io\",\n  \"md5\": \"de77c3303e93c9450424759f1741441c\"\n}",
        "version": 1766001509
    }, {
        "productId": 3505,
        "script": "{\n\"tagName\":\"http\",\n\"url\":\"hxxps://api.kookjar[.]com/sayhi?channel=daihai&uuid={get_uuid_10}\"\n}",
        "version": 1776656317
    }],
    "msg": ""
}

The command information includes a tagName field, which is the command name. The code maps each name to the corresponding class responsible for executing it.

List of executable commands

At the time of our research, the attackers had implemented nine commands. The table below lists command names, brief descriptions, and arguments. The functionality of these commands suggests that the malware can be used to display ads, commit ad fraud (serving as a clicker), and download additional malicious code.

However, attackers use only a relatively small subset of these commands in real-world attacks. As shown in the example C2 response above, at the time of publishing this report the attackers were using the loadlib2 and http commands. The payload downloaded via the loadlib2 command is a reverse proxy module named “zhima”, which researchers from the Nokia Deepfield Emergency Response Team independently discovered in TV set-top boxes around the same time as we did and also described in their report. This confirms that the attackers’ ultimate goal is building a proxy botnet.

While investigating this stage of the attack chain, we noticed that the zhima download link also included a version number. As with the previous stage, we tried other possible version numbers and found eight variants of the zhima module, the earliest of which was version 57. The complete list of identified zhima modules is provided under “Indicators of Compromise” below.

Attribution

While analyzing the complete infection chain, we noticed that the stage 2 loader created a thread with the meaningful name mosdk-host-loader. We decided to investigate what mosdk referred to in that name. This led us to a malicious app installed on various TV set-top boxes with the package name com.abc.nexus (3AD4BF5A86D26FFBF09CAE42AF330A98). It consists of several components (including a dropper similar to JarService), each used by the attackers to covertly monetize the device’s computing power. Each malicious component in the app corresponds to its own service, and the service containing the launch code for the JarService-like dropper is named AdmoyuService. In light of this and the name of the malicious thread found in the payload code, we concluded that moyu in the service name referred to MoYu Group, one of the actors linked to the BADBOX malware platform, which had been described by researchers at HUMAN. This assessment is further supported by extensive overlap between the malware’s network infrastructure and that of MoYu Group, which was independently identified by researchers from the Nokia Deepfield Emergency Response Team around the same time as our own research. Based on these similar naming patterns and prominent infrastructure overlap between the activity of MoYu Group and the attacks described in this report, we attribute it to the same actor with high confidence.

While investigating the malware downloaded by TWCore, we noticed that the domain admin.uipoxy[.]com resolved to the IP address 128.14.210[.]58, one of the C2 servers for the zhima reverse proxy module. It appears that the URL hxxp://admin.uipoxy[.]com/proxy/u/login hosts the zhima admin panel. Interestingly, this panel allows anyone to register as long as they have a valid invite code.

The malware operator registration page

During registration, users are prompted to review the terms of use and privacy policy. Both documents are hosted on links under the pxyedge[.]com domain, which belongs to PXYEDGE, a vendor specializing in the sale of residential proxies.

On the registration page hosted at admin.uipoxy[.]com, we also found the string copyright © 2020 proxyforu[.]com all rights reserved, which linked to hxxps://proxyforu[.]com, the website of ProxyForU, another vendor of residential proxy services.

We found several similarities in the authentication APIs across all of these sites:

• The sign-in page was hosted on an admin.* subdomain.
• The sign-in page was located at /proxy/u/login.
• The signup page was located at /proxy/register?channelKey=<invitation code>.

Based on this, we believe these services are connected to MoYu Group.

Conclusion

Despite efforts by cybersecurity professionals and law enforcement to shut down the BADBOX botnet, individual actors linked to it continue their malicious activity, infecting devices worldwide. Delivery methods for this kind of malware vary widely, from downloads via pre-installed backdoors to infected builds of IPTV apps. The case examined here demonstrates an even more sophisticated delivery method: distribution through the legitimate update functionality of a system application. Attackers are also actively expanding into new platforms. This malware is the first known malicious app targeting head units, which means these platforms now require protection against malware as well.

Indicators of compromise

Stage 1: JarService

ba27951b4ee1c341f4415d033369ecd3
d63bacd6d6709dd68a10ef9d374c7835
6c2e34b30da42085240ede53ab6107d4
8b5e513144a6138a966ea59e68bf9da2
e119845877089d6f4b0a70dc7388f316

Stage 2: loader

e9f3a0dab6949ce2cddab9e0aa80ae1a

Stage 3: loader/clicker

0fbaa7092204f4b1494e0b840b014774
1dcf031c40ce456b6a36a00b0acf3d11
44b6b213a6a3f299eaf88e078de95ecb
67dc78e544ebce16b85dc7c195dfbc58
9642ae619b3165d23c6349002d1abe24
b067d5b0dbecbd6498bcdfba45dba77e
f0e3f7eba2cde91e2dedb921bab47422

zhima module

412e9243f2981bbea3894254d105b3b8
71ab5517f71866279d0d87d37f2ae320
89ef78f716a75964539f2db6520be362
a4223ce4288a230d1e6c3ff2c7639045
bd4d81cd27125ad3d9a114922d468499
c6bfb1643ac7474ed8a7b4f96a187fdb
de77c3303e93c9450424759f1741441c
f8cf8c23ff597700d471fb7767df8bac

Domains and IP addresses

xmsae[.]sbs
ishano456[.]sbs
xshaon123[.]sbs
kshahnd[.]sbs
mdsjhd[.]sbs
nmnsny[.]sbs
kookjar[.]com
ty54fgd435[.]my
ue886578433[.]online
ty4523[.]space
144.217.243[.]201
107.151.248[.]132
128.14.210[.]58

Addresses used to download JarService

hxxp://ovcloudcontrol.cdn.cardoor[.]cn/upgrade/2026-06-08/bd80bd3c3d0e4bf6b5b4a825650d01f5.apk
hxxp://ovcloudcontrol.cdn.cardoor[.]cn/upgrade/2025-06-10/fe71af9ecf174de48d2b2ccc2c15fb04.apk
hxxp://ovcloudcontrol.cdn.cardoor[.]cn/upgrade/2024-11-07/fa831c3c23824b99871163387bcda7ad.apk

Hashes of TWCore (the legitimate software used to distribute JarService)

2a64c3efc11bf224aa54f24e876446c9
7a4d3ba2dacccfdda55859a5dfee2671
ea24487996eb70c1780922fb3063bcc5

Attackers typically try to pass off malware as legitimate applications or as potentially unwanted programs that users deliberately search for and download, such as cheats or cracks. They often rely on ad and affiliate networks to deliver their creations to victims’ devices. This post examines a less conventional case: a well-known backdoor distributed under the guise of adware. The attackers may have chosen this distribution method because the adware was signed by the developer. On top of that, users often manually add these apps to exclusions, so their useful features don’t get blocked.

Some time ago, a client asked us to analyze a file with the MD5 hash c24e99f9437feacaa63766a3cde3fe3d and add it to our detection database. We initially classified it as adware, but a cursory analysis turned up suspicious network activity, which prompted us to dig deeper. It turned out the sample did far more than serve ads. In fact, its advertising functionality doesn’t even work; instead, it triggers an infection chain that delivers the ValleyRAT backdoor.

Malicious installer

The file the client shared with us turned out to be an installer that performed different actions depending on the two-letter suffix used in the file name, positioned just before the numeric string.

These actions are most likely designed to divert the user’s attention away from the sample’s malicious functionality. Regardless of the file name, the installer deploys a modified Chinese desktop wallpaper management tool called QN Wallpaper (hxxps://qnwallpaper[.]keansoft[.]cn/) and adds it to the registry’s autorun entries.

The original version of QN Wallpaper is genuine adware: on installation, it delivers bundled partner apps to the device and then displays ad banners to the user. In this case, however, the attackers use it to carry out DLL sideloading, a technique that allows malicious code to run under the guise of a signed process by way of a malicious DLL.

The QN Wallpaper modules, along with the malicious components, are unpacked to C:\Program Files\QNWallpaper\5.4.0.1662\<random string of letters and digits>. The following files are saved in that directory:

After unpacking, the installer uses the DisableAntiSpyware registry key to disable Windows Defender and then launches QnWallpaper.exe.

Disabling Windows Defender

DLL Sideloading via libcef.dll

QnWallpaper.exe has dependencies in libcef.dll, so this library gets loaded when the process starts. QnWallpaper.exe also launches QnwPlayer.exe, which likewise calls libcef.dll.

QnWallpaper and QnwPlayer won’t actually function correctly, because the functions exported from libcef.dll are put into an infinite sleep. However, in case that sleep is ever interrupted, the attackers have implemented a function that loads all the necessary functions from the original library into memory, provided it can locate that library on the system.

Example of an exported function

Loading functions from the original libcef.dll

The malicious functionality in libcef.dll is invoked by a call to DllMain, which runs automatically when the library is loaded. That said, alongside the original exports, the library also contains a function named RunDLL, which likewise initiates execution of the malicious code. QnWallpaper never calls this function. We suspect the attackers intended to invoke it manually via rundll32 or planned to use a separate executable for this purpose, one that wasn’t included in the package downloaded by the sample.

The RunDLL function

Running the malicious code

When the library is loaded, code runs that ensures QnWallpaper.exe persists at startup: it adds a file extension association and drops a file with the corresponding extension in C:\Documents and Settings\<username>\Start Menu\Programs\Startup\.

This is followed by a chain of wrapper functions whose main job is to call the next one. Execution eventually reaches the function that contains the actual malicious code. For convenience, we’ll refer to it as mw_entry.

Inside mw_entry, the malware checks two things:

• Whether the current user belongs to the Administrators group
• Which process the DLL is running inside

Checking for administrator privileges

If the user isn’t a member of the Administrators group, the program attempts to obtain administrator privileges by using the runas utility.

Relaunching the process to obtain administrator privileges

Once it has administrator privileges, the malicious code determines which process the DLL has been loaded into, and selects the payload accordingly:

• If the library is running inside QnWallpaper.exe, the payload is loaded from the PeLoader file.
  

  Encrypted payload

• If the library is running inside QnwPlayer.exe, the payload is loaded from libcef.dll resources.
  

  Retrieving the payload from a resource

Both payloads are AES-encrypted DLLs that contain the ValleyRAT backdoor. The only difference between them is their configuration, specifically, the C2 server addresses. After decryption, libcef.dll checks the magic signatures in the resulting PE file’s headers to confirm the sample is valid. If this check fails, the library releases its resources and takes no further action.

Validating the PE file headers after decryption

If the headers check out, libcef.dll loads the payload into the process’s memory space and hands control over to the backdoor by calling DllMain.

Calling DllMain

ValleyRAT

ValleyRAT begins its operation by parsing its configuration, which consists of key:value pairs concatenated into a single string. To obfuscate this configuration, the attackers wrote the string in reverse.

Obfuscated configuration

During parsing, the backdoor restores the correct character order and reads the key values one by one. The set of keys is the same regardless of which process the backdoor is running in.

Parsing the configuration

Some of the configuration fields are listed below:

The backdoor uses several techniques to protect its process. Some are configuration-dependent, while others are always applied:

• Injecting code into svchost to restart the process: a configurable option. The backdoor allocates memory inside the svchost process, injects code into it, and sets PAGE_NOACCESS permissions on the memory page containing the injected data. It then creates a suspended thread, waits 60 seconds, grants read, write, and execute permissions on the page, and resumes the thread.
  

  Injecting code into svchost

  The function injected into the process has a single job: restart the backdoor if its execution is interrupted for any reason.

  

  Injected function

• Marking its own process as critical (so that terminating it triggers a blue screen of death): a configurable option.
  

  Setting its own process as critical

• Restarting on an unhandled exception. This protection mechanism is always active, regardless of the backdoor’s configuration.
  

  Restarting on exceptions

The backdoor also has spyware functionality. While running, it tracks keystrokes and the currently focused window by using functions from the DirectInput8 library. It also captures clipboard contents. All collected data is saved to a file on disk.

Capturing clipboard data

If the ll key in the configuration is set to 1, ValleyRAT periodically checks for active windows belonging to applications that could be used to analyze processes or traffic. Window enumeration is done via the EnumWindows function, using the following callback:

Window name checks

After completing these checks, the backdoor collects system information, including:

• Host name
• Host IP addresses
• User idle time
• Detailed Windows version information (ProductName, EditionId, DisplayVersion)
• Number of CPU cores
• Free disk space
• Graphics adapter
• Currently focused window and its title
• System bitness
• Language settings
• Path to the system directory

On command, the backdoor can perform the actions typical of this malware category:

• Rebooting the computer
• Shutting down the computer
• Taking a screenshot
• Wiping logs
• Updating its C2 addresses
• Downloading additional modules
• Sending keylogger logs along with clipboard contents

Snippet of the command handler

Let’s take a closer look at the module-loading functionality. Upon receiving the corresponding command with a link from its operator, the backdoor downloads the file at that link and executes it. The download can come from either the C2 server or a third-party address.

The DownloadPeFile function is responsible for downloading a PE file

The DownloadAndExecute function calls DownloadPeFile, then launches the downloaded module

Additional modules can take the form of purpose-built dynamic libraries or shellcode. If the payload is shellcode, the backdoor uses process hollowing with svchost to launch the module.

Implementation of the process hollowing technique

If the module is a dynamic library, the backdoor loads the PE file into its own process, calls DllMain, and searches for a Main function among the exported functions. Once Main has been called, the library is unloaded from memory.

Calling DllMain after the backdoor loads the PE file

Targets and attribution

Over the course of 2026, we detected the ValleyRAT backdoor and its associated malware more than 100,000 times, with more than 1500 unique users affected, primarily in China and India.

This attack geography, combined with the use of the ValleyRAT backdoor, points to Silver Fox, a known operator of this malware family, as the likely group behind the campaign.

Conclusion

This case is a clear example of how adware and affiliate networks can turn out to be far more dangerous than they appear. ValleyRAT is a sophisticated backdoor capable of collecting sensitive data such as keystrokes and clipboard contents, taking screenshots, and delivering additional malicious modules. The attackers exploited a well-known adware application to run the backdoor under the guise of a signed process, which complicates detection.

Motivated by both cyberespionage and financial gain, Silver Fox targets organizations across multiple countries. To stay protected, organizations should keep employee cybersecurity awareness up to date and enforce clear policies on the use of third-party software on work devices.

For individual users, we recommend avoiding the installation of software with a questionable reputation, and, even more importantly, never adding such software to your security solutions’ exclusion lists.

IoC

MD5

07ddbbe2c71c45577a7a4fbcdba0df91
c24e99f9437feacaa63766a3cde3fe3d
8a626d844943da3456b044f38deae3a2

Network

103.45.66.18:441
103.45.66.18:442
103.45.66.18:443
192.253.225.173:6666
192.253.225.173:8888

Microsoft Threat Intelligence has observed a TerminalFix campaign, a variant of ClickFix, targeting organizations across multiple industries. The campaign uses compromised websites to display a fake Cloudflare CAPTCHA verification overlay that tricks users into copying and executing a malicious PowerShell command. While traditional ClickFix campaigns direct victims to the Windows Run dialog, TerminalFix campaigns apply the same technique but direct users to Windows Terminal or PowerShell instead, increasing the likelihood that complex, multi-line scripts execute successfully. Unlike earlier ClickFix variants that typically deliver a single infostealer, this TerminalFix campaign deploys a sophisticated multi-stage attack chain that combines DLL sideloading, steganographic payload extraction, extensive Active Directory reconnaissance, and a custom reverse-tunnel implant – giving the attacker persistent, network-level proxy access through the compromised host.

Once executed, the PowerShell command masquerades as a Cloudflare verification process while downloading a ZIP archive containing a legitimate binary (LockScreenContentServer.exe) and a malicious DLL (dui70.dll) used for sideloading. The sideloaded DLL drives an elaborate second stage: downloading payloads concealed inside PNG images using steganography, establishing dual persistence through Registry Run keys and scheduled tasks, conducting thorough domain reconnaissance—including domain trust enumeration, domain admin discovery, Active Directory user description harvesting, and targeted server ping sweeps—and ultimately deploying a Python-based reverse-tunnel C2 implant that tunnels arbitrary TCP traffic back through an encrypted WebSocket channel to attacker infrastructure.

This type of intrusion is particularly dangerous because it provides attackers with direct access to an organization’s internal network through the reverse tunnel. The observed reconnaissance and reverse-tunnel capability could enable an attacker to identify and reach additional systems from a compromised host. Microsoft did not observe the downstream actions described below in the analyzed chain. Organizations should treat affected devices as potential network pivot points and investigate for lateral movement and credential exposure. In the hands-on-keyboard phase that typically follows, attackers leverage this access to escalate privileges, disable security controls, exfiltrate sensitive data, and deploy ransomware across the organization. The combination of stealth techniques (DLL sideloading, steganography, hidden folders) and persistent network access make this TerminalFix campaign a serious threat to enterprise environments.

In this blog, we share our detailed analysis of the TerminalFix attack chain – from initial compromise through network tunneling—along with indicators of compromise, detection details, and hunting guidance to help defenders identify and respond to this threat.

Attack chain overview

The TerminalFix campaign follows a multi-stage attack chain that progresses from social engineering through payload delivery, persistence, reconnaissance, and ultimately network tunneling:

1. Initial access via compromised website – A compromised website displays a fake Cloudflare Turnstile CAPTCHA verification overlay. The user is instructed to copy and paste a “verification” command.

2. PowerShell execution – The pasted command runs a disguised PowerShell script that downloads a ZIP archive from attacker infrastructure, extracts it to C:\ProgramData, and silently launches a batch file.

3. DLL sideloading — The batch file executes LockScreenContentServer.exe, a signed legitimate binary, which automatically loads the co-located malicious dui70.dll.

4. Steganographic payload retrieval – The sideloaded DLL executes PowerShell that downloads PNG images from attacker domains, extracts embedded executables and DLL fragments hidden within pixel data, and reassembles them on disk.

5. Persistence – The malware establishes persistence through both HKCU\…\Run registry keys and scheduled tasks that re-execute LockScreenContentServer.exe every 60 minutes.

6. Reconnaissance – Extensive domain discovery is performed: domain trust enumeration, domain admin group membership, Active Directory computer and user enumeration, targeted server pinging, and system information collection in both English and Spanish locales.

7. Command execution loop – A persistent PowerShell file-watch loop monitors a text file for new commands, executes them via Invoke-Expression, and writes results to an output file-, creating a primitive but effective asynchronous command shell.

8. Reverse tunnel deployment – A Python runtime and a custom client.py tunneling implant are downloaded and launched via pythonw.exe with no visible window, establishing a reverse WebSocket tunnel to gitnow[.]dev:443 that gives the attacker full SOCKS-style TCP proxy access through the victim’s network.

Attack chain

1. Initial access: Fake CAPTCHA and the TerminalFix lure

The attack begins when a user visits a compromised website that displays a fake Cloudflare Turnstile verification overlay. The original page is briefly displayed before being replaced by a convincing Cloudflare Turnstile verification overlay. This overlay spoofs the Cloudflare CAPTCHA interface, complete with the Cloudflare logo, “Verify you are human” checkbox, and a spinner animation, tricking users into believing they must complete a verification step to access the site.

When the user interacts with the fake verification prompt, a malicious PowerShell command is silently copied to their clipboard. The on-screen instructions then guide the user to open Windows Terminal or PowerShell and paste the command. The command is carefully crafted to appear legitimate by printing reassuring Cloudflare-themed status messages in color-coded terminal output:

The command performs the following actions:

• Clears the terminal and prints a fake “Starting Cloudflare verification…” message in cyan color formatted
• Downloads a ZIP archive from the attacker’s infrastructure using a custom User-Agent header
• Extracts the archive to C:\ProgramData\f47f2a8c21c9df4e
• Launches a batch file (1.bat) that executes LockScreenContentServer.exe silently in the background
• Prints a convincing “I am not a robot – Cloudflare ID: f47f2a8c21c9df4e” confirmation message in green text

2. Payload delivery: DLL sideloading via LockScreenContentServer.exe

The downloaded ZIP archive (SHA-256: 18c2090e8a0ae0568af9b87e59eaf8270f23d2909600ed9db91a9444fd8b278f) contains two files:

LockScreenContentServer.exe is a legitimate, signed binary that has a static import dependency on dui70.dll, the Windows DirectUI Engine.

Here is the example view of LockScreenContentServer application importing dui70.dll function:

The attacker abuses this dependency by dropping a malicious dui70.dll alongside the executable. Because the Windows loader resolves the application directory before the System32 directory, the planted DLL is loaded in place of the legitimate one, a technique known as DLL sideloading (T1574.001). Execution therefore begins inside a trusted, signed process, allowing the attacker to inherit its reputation and evade controls that key on process identity.

The malicious dui70.dll embeds a heavily obfuscated payload in its resource section. On load, the DLL’s initialization path retrieves this resource, decodes it entirely in memory, and transfers execution to it, staging the next phase of the infection without ever writing the decoded payload to disk (Figures 5 and 6).

3. Second-stage delivery: Steganography and image-based payload extraction

Once sideloaded, the malicious DLL launches an elaborate PowerShell script that retrieves additional payloads concealed within PNG image files, a technique known as steganography. The script downloads three images from attacker-controlled domains, extracts binary data encoded in pixel values, and reassembles the components on disk.

Content domains

The script uses a failover mechanism across two domains:

Steganographic extraction

The Extract-RawFileFromImage function reads each pixel’s RGBA channels and reconstructs an embedded binary. The first 8 bytes encode the payload length as a 64-bit integer, and the remaining bytes contain the file data:

The script downloads three images via POST requests to the content domains, extracts the executable from the first image, extracts two halves of the DLL from the second and third images, and concatenates the DLL fragments:

Encoding payload data in PNG files can make file type and content inspection more difficult. Splitting the DLL across two images further obscures the complete payload in transit, the payloads aren’t recognizable as executables in transit, and splitting the DLL across two images further complicates detection. After extraction, the source images are deleted to reduce forensic artifacts.

4. Persistence mechanisms

The TerminalFix campaign establishes redundant persistence through two independent mechanisms, ensuring the payload survives reboots and re-executes on a recurring schedule. The dropped batch script takes the payload path as a command-line argument, validates that the file exists, and then configures both mechanisms under the same masquerading name LockScreenContentServer_MuODG5yBM chosen to blend in with the legitimate Windows Lock Screen component abused earlier in the chain.

Registry Run key

The malware creates a Run key entry with a randomized service-like name:

Scheduled task

A scheduled task ensures the malware re-executes every 60 minutes:

Folder hiding

The malware directory is hidden using system and hidden file attributes:

5. Reconnaissance and domain discovery

After establishing persistence, the sideloaded malware conducts extensive reconnaissance of the victim’s environment. This activity is consistent with a hands-on-keyboard operator or an automated pre-assessment script designed to evaluate whether the compromised host is a valuable target – particularly whether it is domain-joined and near high-value infrastructure.

System information collection

The attacker collects system metadata and the script includes English, Spanish, and German locale variants, indicating an attempt to operate across systems configured in multiple languages:

Active Directory enumeration

The malware performs domain trust discovery, domain admin enumeration, and Active Directory user and computer searches:

Infrastructure probing

The malware systematically pings named servers to map the internal network topology:

The observed names correspond to common infrastructure roles, including domain controllers, databases, backup, gateways, and mail systems. This probing could help an attacker identify accessible target systems for follow-on activity.

6. Asynchronous command execution loop

The malware deploys a persistent PowerShell file-watch loop that creates an asynchronous command-and-control channel through the local filesystem. This mechanism monitors a “watch” file for changes, executes its contents via Invoke-Expression, and writes results to an output file:

This loop provides the attacker with a way to execute arbitrary PowerShell commands by writing them to the watched text file. The output is captured to a separate file, which the attacker can read back through the reverse tunnel. This decoupled execution model allows the attacker to issue commands asynchronously and retrieve results at their convenience.

7. Reverse tunnel deployment: The custom Python-based tunneling implant

The most significant post-compromise capability observed is the deployment of a custom Python-based reverse-tunnel implant. The attacker brings their own interpreter: an unmodified, signed embeddable Python runtime pulled directly from the official python.org distribution. The malicious logic lives entirely in the accompanying client.py, giving the operator a portable, cross-version-tolerant execution environment that inherits the trust of a legitimate open-source runtime.

The deployment is orchestrated in PowerShell. It removes any prior install directory, extracts the implant kit, downloads the embeddable Python 3.14.5 archive over TLS 1.2, unpacks it into the same directory, and launches the tunnel with no visible window via pythonw.exe:

Tunneling implant analysis

The client.py script is a compact but full-featured reverse tunnel. It dials outbound to the C2 over TLS/443, upgrades the session to a WebSocket, and uses that channel to relay arbitrary TCP connections on behalf of the operator. On the wire, the traffic is indistinguishable from an ordinary encrypted web session to a single destination

The tunnel carries a lightweight custom protocol with eight message types spanning implant identification, connection setup, data relay, keepalive, and remote termination:

Turning the victim into a network pivot: The implant’s SOCKS5-style address parsing enables the C2 server to reach any host visible from the victim’s network. Combined with the reconnaissance data gathered earlier (domain controllers, SQL servers, backup servers, gateway), this turns the compromised machine into a full network pivot point:

The choice to launch with pythonw.exe (no visible window Python interpreter) means no console window is visible to the user. Combined with DEBUG = False by default and all logging going to stderr, the implant operates completely silently.

Mitigation and protection guidance

Microsoft recommends the following mitigations to reduce the impact of this threat:

• Restrict PowerShell and Run dialog execution – Use AppLocker, Application Control for Windows, or Group Policy to restrict PowerShell execution for standard users.
• Consider blocking or auditing the Windows Run dialog (Win+R) where it is not required for daily work.
• Monitor for DLL sideloading indicators — Alert on LockScreenContentServer.exe executing from non-standard paths (anything other than C:\Windows\SystemApps). Use the LockScreenContentServer.exe sideloading from non-standard paths advanced hunting query provided below to identify this activity across your environment.
• Educate users about ClickFix tactics – Train employees to recognize fake CAPTCHA verification pages that instruct them to paste commands into Terminal or the Run dialog.
• Investigate affected hosts thoroughly – Organizations that find indicators of this campaign should assume the attacker has network-level access through the compromised host. Credential rotation should be prioritized for any credentials accessible from the affected machine, including domain admin accounts if the host was domain-joined.
• Check your Microsoft 365 email filtering settings to ensure spoofed emails, spam, and emails with malware are blocked. Use Microsoft Defender for Office 365 for enhanced phishing protection and coverage against new threats and polymorphic variants. Configure Defender for Office 365 to recheck links on click and delete sent mail in response to newly acquired threat intelligence. Turn on safe attachments policies to check attachments to inbound email.
• Consider using enterprise-managed browsers, which provide multiple security features including security update requirements and data compliance policies.
• Block web pages from automatically running Flash plugins.
• Enable network protection and web protection in Microsoft Defender for Endpoint to safeguard against malicious sites and internet-based threats.
• Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
• Turn on cloud-delivered protection in Microsoft Defender Antivirus, or the equivalent for your antivirus product, to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a majority of new and unknown variants.
• Enable PowerShell script block logging to detect and analyze obfuscated or encoded commands, providing visibility into malicious script execution that might otherwise evade traditional logging.
• Enforce use of PowerShell Constrained Language Mode where possible, in addition to use of execution policies such as setting AllSigned or RemoteSigned to help reduce the risk of malicious execution by ensuring only trusted, signed scripts are executed, adding a layer of control.
• Use Group Policy to deploy hardening configurations throughout your environment, if certain features are not necessary:
  • Create an App Control policy that prohibits the launch of native Windows binaries from Run. This can be accomplished by defining a rule based on the specific process that is launching binaries like PowerShell.
  • Configure Windows Terminal access and settings to warn users when the text they’re pasting contains multiple lines.
• Microsoft Defender XDR customers can also implement the following attack surface reduction rules to harden an environment against PowerShell techniques used by threat actors:
  • Block execution of potentially obfuscated scripts
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion
  • Block JavaScript or VBScript from launching downloaded executable content

Microsoft Defender XDR detections

Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run prebuilt promptbooks to automate investigation and response tasks related to this threat. Useful promptbooks for this activity include Incident investigation, Microsoft User analysis, Threat actor profile, Threat Intelligence 360 report based on MDTI intelligence, and Vulnerability impact assessment. Some promptbooks require access to Microsoft Defender XDR, Microsoft Sentinel, or related Microsoft security plugins.

For this campaign, Security Copilot can help analysts summarize affected devices running LockScreenContentServer.exe from non-standard locations, trace the PowerShell steganography extraction chain, and build containment and credential rotation plans for affected domain-joined endpoints.

Threat intelligence reports

Microsoft customers can use Microsoft Defender XDR Threat analytics and related Microsoft threat intelligence reporting to stay current on the malicious activity, indicators, detection coverage, and recommended response actions associated with this compromise. These reports provide investigation context, protection guidance, and updated intelligence that security teams can use to prevent, mitigate, or respond to related activity in customer environments.

Advanced hunting queries

Microsoft Defender XDR customers can run the following advanced hunting queries to find related activity in their networks:

ClickFix PowerShell execution which executes payload

DeviceProcessEvents
| where InitiatingProcessFileName =~ "powershell.exe"
| where FileName =~ "cmd.exe" and ProcessCommandLine has_all (@"\ProgramData\", "1.bat", "LockScreenContentServer.exe")

LockScreenContentServer.exe sideloading from non-standard paths

DeviceImageLoadEvents
| where InitiatingProcessFileName =~ "LockScreenContentServer.exe"
| where FileName =~ "dui70.dll"
| extend path = tostring(parse_path(FolderPath).DirectoryPath)
| where path =~ InitiatingProcessFolderPath
| where not(path has_any (@"\Windows\System32", @"\Windows\SysWOW64", @"\winsxs\", @"\program files", @"\Windows Defender\", @"\Microsoft Security Client\", @"\Program Files\Windows", @"\Program Files\Microsoft", @"\ProgramData\Microsoft\", @"\Microsoft\Windows", @"\amd64_windows-defender-service", @"\Microsoft Defender for Endpoint\"))

Custom reverse tunnel implant execution

DeviceProcessEvents
| where FileName in~ ("pythonw.exe", "python.exe")
| where ProcessCommandLine has_all ("client.py", "--server", "--uuid", “cert.pem”, “gitnow.dev”)

Outbound connections to known C2 domains

DeviceNetworkEvents
| where RemoteUrl has_any ("gitnow.dev", "bestsocialmedianewspapper.com",
                            "offlineupdater.com")
| project Timestamp, DeviceName, RemoteUrl, RemotePort,
          InitiatingProcessFileName

MITRE ATT&CK Techniques observed

The following MITRE ATT&CK mappings reflect behaviors observed during this activity.

Initial Access

• T1189 Drive-by Compromise | A compromised website delivers a fake CAPTCHA overlay.

Execution

• T1059.001 Command and Scripting Interpreter: PowerShell | A malicious PowerShell command is pasted by the user into Terminal.
• T1204.002 User Execution: Malicious File | The user pastes and executes a clipboard-hijacked command.

Persistence

• T1547.001 Boot or Logon Autostart Execution: Registry Run Keys | An HKCU Run key is set to execute LockScreenContentServer.exe.
• T1053.005 Scheduled Task/Job: Scheduled Task | A scheduled task is created to execute every 60 minutes.

Defense Evasion

• T1574.002 Hijack Execution Flow: DLL Side-Loading | Malicious dui70.dll is side-loaded by the legitimate LockScreenContentServer.exe.
• T1027.003 Obfuscated Files or Information: Steganography | Payloads are hidden in PNG image RGBA pixel data.
• T1564.001 Hide Artifacts: Hidden Files and Directories | The attrib +h +s command is applied to the payload directory.
• T1036.005 Masquerading: Match Legitimate Name or Location | The DLL is named dui70.dll to match the legitimate Microsoft DUI framework.

Discovery

• T1018 Remote System Discovery | An ADSI query identifies Windows Server computers and performs a ping sweep.
• T1069.002 Permission Groups Discovery: Domain Groups | The net group “domain admins” /domain command is used for enumeration.
• T1482 Domain Trust Discovery | nltest /domain_trusts and /dclist: are used for domain enumeration.
• T1087.002 Account Discovery: Domain Account | An ADSI searcher enumerates user descriptions.
• T1082 System Information Discovery | systeminfo is used with multilingual findstr filters.

Command and Control

• T1572 Protocol Tunneling | A reverse WebSocket tunnel communicates over TLS with gitnow[.]dev:443.
• T1071.001 Application Layer Protocol: Web Protocols | Command-and-control communication occurs over HTTPS/WebSocket.
• T1105 Ingress Tool Transfer | A Python runtime and implant kit are downloaded and extracted.

Indicators of Compromise (IOCs)

File indicators

Network indicators

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.  

• Learn more about securing Copilot Studio agents with Microsoft Defender 
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.
• Microsoft 365 Copilot AI security documentation
• How Microsoft discovers and mitigates evolving attacks against AI guardrails

The post TerminalFix campaign deploys a reverse tunnel through multistage intrusion appeared first on Microsoft Security Blog.

The vulnerability landscape shifted significantly in Q2 2026. First, the number of registered CVEs reached an unprecedented level. This is driven primarily by the widespread adoption of AI, both for application development and search for security flaws. This resulted in entire new classes of vulnerabilities emerging, particularly in the Linux networking subsystem.

Second, security researchers have been publishing exploits for unpatched vulnerabilities more frequently. Publications like these can generate significant fallout, since they potentially open the door for attackers to target unprotected systems.

Statistics on registered vulnerabilities

This section provides statistical data on registered vulnerabilities. The data comes from Kaspersky’s vulnerability knowledge base, which draws on the CVE database as well as the Russian BDU database and GitHub Advisory (GHSA). As a result, the figures for previous reporting periods may differ from those published in earlier reports.

We examine the number of registered vulnerabilities for each month over the last five years. As the chart below shows, this number continues to surge, a trend reflected across all the databases we track. It’s driven primarily by the widespread adoption of AI tools: as we predicted in our previous report, these tools have played a major role in the discovery of vulnerabilities in third-party software. Meanwhile, these tools often contain security issues of their own. For example, OpenClaw, a popular AI project, ranked 12th among those with the highest number of vulnerabilities discovered and published in Q2, with over 200 CVEs registered during the reporting period. Finally, AI development tools are also contributing to the vulnerability landscape, since the quality of the code they produce can vary widely. Therefore, the rate at which new vulnerabilities are discovered will inevitably keep growing.

Total published vulnerabilities per month from 2022 through 2026 (download)

Next, we analyze the number of new critical vulnerabilities (CVSS > 9.0) over the same period.

Total critical vulnerabilities published per month from 2022 through 2026 (download)

As the chart shows, the number of published critical vulnerabilities jumped sharply in Q2. This is because using AI for vulnerability research makes it possible to analyze massive amounts of previously unexamined code, uncover new attack surfaces, and identify entire classes of vulnerabilities that have gone unnoticed for decades. In particular, AI was used to find a series of Dirty Frag vulnerabilities in the Linux kernel.

Exploitation statistics

This section presents statistics on vulnerability exploitation for Q2 2026. The data draws on open sources and our telemetry.

Windows and Linux vulnerability exploitation

Q2 2026 saw a new precedent in the publication of vulnerabilities in Windows components and exploits for these: researchers no longer waiting for CVE registration, let alone patches. A case in point: a researcher who goes by Nightmare Eclipse (also known as Chaotic Eclipse) published a list of new “named” vulnerabilities across various Windows subsystems. At the time the technical details were published, none of the vulnerabilities had been assigned a CVE identifier:

• BlueHammer: a local privilege escalation vulnerability in Windows Defender. During signature database updates, a time-of-check to time-of-use (TOCTOU) race condition occurs, allowing an attacker to substitute the directory where temporary update files are written. The researcher published a fully functional exploit for the vulnerability.
• RedSun: another logical vulnerability in Windows Defender with a working exploit. Suspicious and malicious files marked as “cloud” can be overwritten or restored to their original directory with elevated privileges. The exploit incorporates fragments of algorithms that make it possible to leverage various logical vulnerabilities in Windows, effectively combining a large number of popular exploitation techniques.
• YellowKey: a vulnerability that lets the user bypass BitLocker full-disk encryption and access system data through the Windows Recovery Environment (WinRE). A fully functional exploit was also published.
• GreenPlasma: a vulnerability that enables system object injection via the CTF loader for the Collaborative Translation Framework (CTFMON) service in Windows. The original publication included an exploit with limited functionality.
• RoguePlanet: yet another Windows Defender vulnerability that, like BlueHammer, stems from a TOCTOU issue, this time in the engine responsible for real-time system scanning. The published exploit uses the vulnerability to overwrite the system file wermgr.exe with a malicious one.
• UnDefend: another vulnerability in the Windows Defender service. This time, the exploit causes a denial of service and blocks updates.

Even though such cases remain isolated for now, we believe they’ll grow into a full-fledged trend. Early publication of exploits gives attackers an advantage over software developers, who are left with no time to fix the issues.

Veteran vulnerabilities in Windows software also remain relevant. These are the ones our solutions most frequently detect exploits for:

• CVE-2018-0802: a remote code execution (RCE) vulnerability in the Equation Editor component
• CVE-2017-11882: another RCE vulnerability also affecting Equation Editor
• CVE-2017-0199: a vulnerability in Microsoft Office and WordPad that allows an attacker to gain control over the system
• CVE-2023-38831: a vulnerability in WinRAR that involves improper handling of objects within an archive
• CVE-2025-6218 (formerly ZDI-CAN-27198): another WinRAR vulnerability allowing the specification of relative paths to extract files into arbitrary directories, potentially leading to malicious command execution
• CVE-2025-8088: a vulnerability similar in exploitation method to CVE-2025-6218. The attackers used NTFS Streams to circumvent controls on the directory into which files are being unpacked

The vulnerabilities listed here can be leveraged to gain initial access to a vulnerable system and for privilege escalation. This underscores the critical importance of timely software updates.

That said, the number of Windows users who encountered exploits declined slightly in Q2, hitting an 18-month low.

Dynamics of the number of Windows users encountering exploits, Q1 2025 – Q2 2026. The number of users who encountered exploits in Q1 2025 is taken as 100% (download)

Linux also hit a rough patch in Q2 2026. Specifically, the period saw the disclosure of the Dirty Frag family of vulnerabilities, which lets an attacker reliably escalate privileges within the operating system.

All the vulnerabilities published in Q2 2026 were, in one way or another, related to the Linux caching subsystem. Here are the ones being most actively exploited:

• CVE-2026-31431 (Copy Fail): a local privilege escalation vulnerability in the Linux kernel that lets an unprivileged user modify the page cache and gain root privileges. Especially dangerous for cloud and containerized environments
• CVE-2026-43284, CVE-2026-43500 (Dirty Frag): a family of vulnerabilities in the Linux networking subsystem (IPsec ESP and RxRPC) that lets a local user overwrite the page cache and escalate privileges to root
• CVE-2026-46300 (Fragnesia): a local privilege escalation vulnerability in the Linux kernel related to packet fragment handling and the page cache mechanism. It lets an unprivileged user gain root privileges and is also classified as part of the Dirty Frag family
• CVE-2026-31635 (DirtyDecrypt): a Linux kernel vulnerability that lets a local attacker escalate privileges due to improper handling of decryption operations and page cache data modification
• CVE-2026-43494 (PinTheft): a Linux kernel vulnerability that lets a local user gain elevated privileges due to errors in the memory page pinning mechanism
• CVE-2026-46331 (pedit COW): a vulnerability in the Linux kernel’s traffic control subsystem (tc-pedit) that exploits a flaw in copy-on-write to modify the page cache and subsequently escalate privileges to root

The vulnerabilities described above were quickly embraced by attackers. At the same time, our solutions continue to detect exploitation attempts targeting older vulnerabilities as well:

• CVE-2022-0847: a vulnerability known as Dirty Pipe, which enables privilege escalation and the hijacking of running applications
• CVE-2019-13272: a vulnerability caused by improper handling of privilege inheritance, which can be exploited to achieve privilege escalation
• CVE-2021-22555: a heap out-of-bounds write vulnerability in the Netfilter kernel subsystem
• CVE-2023-32233: another Netfilter subsystem vulnerability that allows for Use-After-Free conditions and privilege escalation through improper processing of network requests

Dynamics of the number of Linux users encountering exploits, Q1 2025 – Q2 2026. The number of users who encountered exploits in Q1 2025 is taken as 100% (download)

In Q2 2026, the number of Linux users who encountered exploits declined slightly compared to Q1. Given that a significant share of new vulnerabilities are tied to the operating system’s caching subsystem, we recommend installing patches as quickly as possible, or disabling vulnerable kernel modules if patching isn’t an option.

Most common published exploits

The distribution of published exploits by software type in Q2 2026 includes categories that haven’t appeared in the sample for a long time. For instance, we’re once again seeing exploits targeting SharePoint. It’s worth noting that while several vulnerability write-ups for Exchange and SharePoint were published during the quarter, most turned out to be fake, AI-generated research. While the articles and exploit source code themselves look fairly polished, they describe nonexistent problems in the software or its components — often close to genuinely vulnerable mechanisms — in order to mislead researchers. This type of attack is aimed at increasing the time it takes to detect real vulnerabilities. In some cases, the description of a nonexistent vulnerability came bundled with completely unrelated malware.

Distribution of published exploits by platform, Q1 2026 (download)

Distribution of published exploits by platform, Q2 2026 (download)

Vulnerability exploitation in APT attacks

We analyzed which vulnerabilities were exploited in APT attacks during Q2 2026. The rankings provided below include data based on our telemetry, research, and open sources.

TOP 10 vulnerabilities exploited in APT attacks, Q2 2026 (download)

In Q2 2026, a trend emerged in APT attacks toward exploiting new vulnerabilities right from the moment they’re published. As before, we’re also seeing a large number of zero-day vulnerabilities. The Langflow vulnerability deserves particular attention: it’s one of the first cases of an APT group exploiting AI technology, which many organizations are only just beginning to integrate. Because most of this tech is proprietary, it has a considerable number of security blind spots. Therefore, given the growing number of AI-based automation tools, we strongly recommend going beyond the usual patching and developing secure procedures for credential use and sensitive data handling in systems that rely on agents and LLMs.

C2 frameworks

In this section, we examine the most popular C2 frameworks used by APT groups and analyze the vulnerabilities targeted by the exploits that interacted with C2 agents in APT attacks.

The chart below shows the frequency of known C2 framework usage in attacks during Q2 2026, according to open sources.

TOP 10 C2 frameworks used by APTs to compromise user systems, Q2 2026 (download)

Sliver, Havoc, AdaptixC2, and Metasploit remain the most widely used C2 frameworks. After studying open sources and analyzing samples of malicious C2 agents that contained exploits, we determined that the following vulnerabilities were utilized in APT attacks involving the C2 frameworks mentioned above:

• CVE-2026-35273: a vulnerability in Oracle PeopleSoft PeopleTools that security vendors classify as server-side request forgery (SSRF). The details of the vulnerability have never been disclosed, although some research covers the post-exploitation steps
• CVE-2023-46604: an insecure deserialization vulnerability in Apache ActiveMQ that allows arbitrary code execution in the context of the service process
• CVE-2024-12356 and CVE-2026-1731: command injection vulnerabilities in BeyondTrust software that allow an attacker to send malicious commands even without system authentication
• CVE-2023-36884: a vulnerability in the Windows Search component that allows commands to be run on the system, bypassing the mark-of-the-web (MoTW) mechanism
• CVE-2025-53770: an insecure deserialization vulnerability in Microsoft SharePoint that allows for unauthenticated command execution on the server
• CVE-2025-8088 and CVE-2025-6218: similar directory traversal vulnerabilities in WinRAR that allow files to be extracted from an archive to a predetermined path, potentially without the archiving utility displaying any alerts to the user

These vulnerabilities show that attackers used them for initial access and privilege escalation on vulnerable systems, setting the stage for launching a C2 agent. They include both zero-day vulnerabilities and fairly well-known security issues.

LLM/AI tool vulnerabilities

This section analyzes data published in Kaspersky’s vulnerability knowledge base. We reviewed the Q2 2026 version of the knowledge base.

As mentioned above, AI tools, plugins, and technologies have proven fairly effective at automating the search for problematic code and anomalous behavior. The high speed at which new vulnerabilities are being discovered has naturally created a need to fix them just as quickly. AI is often used for this too, which increases the volume of code being generated. However, neither code written without human involvement nor AI-generated advice is always correct.

The chart below covers registered vulnerabilities in AI tools for 2025–2026.

Number of published vulnerabilities in LLMs, AI tools, and plugins with similar functionality, 2025–2026 (download)

As the charts show, AI tools are racking up a substantial number of registered vulnerabilities, and that number keeps growing quarter over quarter. It’s also worth looking at how AI tool vulnerabilities break down by type, according to the CWE system:

TOP 6 vulnerability types in products that implement or use AI/LLM logic, 2025–2026

Interestingly, vulnerabilities of an undetermined type have ranked first in every quarter since the start of 2025. Traditionally-made software has the same issue, and it doesn’t look like the growing number of AI tools will fix it. It’s also notable that the list includes classes CWE developers themselves don’t recommend using for vulnerability classification, since they lump together a whole range of more specific types. CWE-284 is an example of this.

Looking at the most common classes, the key issues found in AI-related software can be summed up as follows:

• Inadequate access control over critical system objects
• Improper implementation of authentication and authorization mechanisms
• Injections

It’s worth noting that injection-related vulnerabilities were relatively rare before AI agents took off (previously, they mostly affected web apps). Recently, though, these security issues have become relevant again.

Looking back at a year and a half of the AI boom, one conclusion stands out regarding registered vulnerabilities: AI tool developers are more focused on expanding functionality than on security. This is worth keeping in mind when using these tools. Let’s look at the projects and applications that either integrated AI tools or offered them as the core product. Below is a list of the those with the highest number of registered vulnerabilities for 2025–2026.

TOP AI/LLM-related projects by number of published vulnerabilities, 2025–2026 (download)

Notable vulnerabilities

This section highlights the most significant vulnerabilities published in Q2 2026 that have publicly available descriptions. Since the above already covers several significant vulnerabilities published during the reporting period, this section consists mainly of LLM/AI tool vulnerabilities.

CVE-2026-25253: a gatewayUrl vulnerability in OpenClaw

The issue stems from the fact that the OpenClaw user interface trusts the value of the gatewayUrl parameter passed in the URL and automatically establishes a WebSocket connection to the specified address. During this connection process, it sends an authentication token without any additional user confirmation.

The attack algorithm exploiting this vulnerability works as follows:

1. The application obtains a critical connection address from an external source (the gatewayUrl URL parameter), which is controlled by the attacker.
2. There is no validation before use.
3. The client automatically initiates a connection to the address specified in the parameter, which belongs to the attacker.
4. While connected, the application sends credentials (an access token) to the specified address.

If the attacker obtains a valid token, the consequences depend on that token’s level of access within the system. In general, this could lead to:

• User session compromise
• Execution of operations on the user’s behalf
• Modification of the AI agent configuration
• Unauthorized access to tools and resources connected to the agent
• Under certain OpenClaw configurations, further compromise of the host running the agent

It’s worth noting that the risk of exploitation arises from a combination of several factors: the automatic connection and token transmission, the lack of address trust verification, and the high privileges granted to the local AI agent.

CVE-2026-41948: a path traversal vulnerability in the Dify AI platform

The vulnerability lets an authenticated user craft a request that enables the application to escape its permitted tenant and gain access to internal REST APIs that weren’t meant for that user. The root cause is insufficient normalization and validation of the URL path before it’s passed to the internal service.

Depending on the Dify configuration, the consequences can include:

• Unauthorized access to internal service interfaces
• Breach of isolation between workspaces
• Exposure of internal service information
• Conditions favorable to further attacks when combined with other vulnerabilities

The use of Dify in enterprise AI platforms is particularly risky, since internal services there tend to hold elevated privileges.

CVE-2026-45386: an improper access control vulnerability in Open WebUI

In Open WebUI, pin/unpin operations on messages are write operations, since they modify that message’s metadata (is_pinned, pinned_by, pinned_at). In vulnerable versions, however, before performing these actions, the API only checked for read access to the channel (a chat between a user or group and the AI) containing the message, not permission to modify its content. As a result, a user with a role limited to viewing messages could still change a message’s pinned status.

The vulnerability’s mechanism works as follows:

1. The user initiates an action that changes the state of an object.
2. The application treats this action as a regular read request.
3. Only channel view permission is checked.
4. The application performs a write without verifying the required user authorization.

This violates one of the fundamental principles of access control models — namely, that any operation that changes the state of data must be checked for the appropriate write or moderation permissions, regardless of whether the object itself is readable.

Although the vulnerability doesn’t lead to arbitrary code execution or compromise of sensitive data, it can affect data integrity and collaborative workflows. Potential consequences of exploitation include unauthorized pinning or unpinning of messages, disruption of channel moderators’ and administrators’ activities, changes to the display order of important information, and even the potential spread of false or misleading information by altering the channel containing a pinned message.

Open WebUI is widely used as an interface for interacting with local and enterprise LLMs. In these systems, pinned messages often contain important instructions, announcements, or tips for users. The ability to modify them with minimal privileges can disrupt collaborative workflows, cause confusion, and undermine trust in information published by administrators and moderators.

CVE-2026-45501: a vulnerability in Microsoft Exchange

The vulnerability stems from improper neutralization of user input when generating Exchange web pages. As a result, the browser may interpret specially crafted data as active content instead of plain text.

Although Microsoft categorizes the potential impact of exploiting this vulnerability as spoofing, flaws like this can lead to alteration of displayed content, imitation of trusted interfaces, actions on behalf of the user within an active session, and abuse of user trust.

It’s worth noting that issues like this are still relevant in modern software, given that mechanisms like Content Security Policy and various parsers were specifically created to help developers neutralize dangerous parts of user page content.

Conclusion and advice

Q2 brought the first significant results of AI automation adoption in software development and vulnerability hunting tools. This research shows that beyond traditional patch management, organizations now need real-time monitoring of systems and access controls, since infrastructure and everyday applications now contain far more AI functionality that could lead to compromise.

Accordingly, besides quickly detecting infrastructure vulnerabilities and managing security patches, modern enterprise-grade security solutions need to provide a broad range of preventive measures for tracking the overall health of systems and workstations. Kaspersky Next meets these requirements by combining proactive mechanisms with the ability to respond promptly to emerging threats.

While monitoring Android threats in June 2026, we discovered a new piece of Android malware. What struck us as unusual was that it installed like an ordinary user app yet made no attempt to disguise itself as legitimate software: it had no user interface at all. This led us to suspect the app might be reaching users’ devices without their knowledge. Further investigation confirmed that hypothesis and allowed us to reconstruct the entire infection chain.

Key findings:

• We identified new Android malware: a multi-stage downloader whose ultimate purpose is ad fraud and creation of a proxy botnet.
• The malware spread through the built-in updaters of Android-based automotive head unit firmware. This is the first documented case of malware found on a car head unit with an infection chain specific to that type of device.
• We attribute this activity, with high confidence, to the MoYu Group, an actor linked to the BADBOX botnet.

Kaspersky solutions detect the threats described below under the following detection names:

• HEUR:Trojan-Dropper.AndroidOS.Agent.vu
• HEUR:Trojan-Downloader.AndroidOS.Agent.ov
• HEUR:Trojan-Proxy.AndroidOS.Zhima.*
• HEUR:Trojan.AndroidOS.Vo1d.*

Head unit firmware overview

A head unit is a system that combines multimedia functions with partial control over certain vehicle functions. Head units may come as part of a car’s factory equipment or as an aftermarket upgrade. The main attack vectors for these systems are compromise via physical access and vulnerabilities in the head unit’s OS or components, both of which we’ve covered previously.

In some cases, head units run on Android, primarily because it’s convenient for manufacturers: Android’s source code already accounts for use cases within automotive head units. Android also allows manufacturers to add their own system applications during the build process, which they can use for a range of purposes: customizing the UI, adding system components tailored to the vendor’s needs, and more.

Most apps developed for Android devices can also run on an Android-based head unit, and that is true for malware as well. That said, it’s hard to imagine certain categories of smartphone-targeted malware being used to attack a head unit. Banking Trojans are a good example: since mobile banking is used almost exclusively on smartphones, infecting a head unit with a banking Trojan would be a waste of the attacker’s resources.

It’s worth noting that head units often include SIM card slots and can connect to the internet, enabling features like navigation and software updates. Since a head unit typically holds nothing of value to an attacker, one of the more likely attack scenarios using “classic” Android malware is infecting the device to recruit it into a botnet – similar to attacks on IoT devices.

During our research, we found exactly that kind of malware. The design of firmware for DoFun head units enabled attackers to distribute malware. We notified the vendor about the distribution scheme, and they subsequently reported fixing the security issues.

Below is the entire infection chain:

Head unit infection scheme

Let’s look at exactly how these head units became infected.

The TWCore app

TWCore is a legitimate system application responsible for collecting analytics data and updating the head unit software. Let’s take a closer look at how the update function works.

The process is fairly simple. An MQTT message broker hosted on the subdomain cardoor[.]cn sends a message containing information about the APK files that need to be downloaded and installed on the head unit. Notably, the object describing this message includes an installNotExists field, a Boolean flag that can be set to true or false. This flag allows TWCore to install apps that weren’t originally present on the device.

TWCore only checks whether an app is already installed on the device when installNotExists = false

The APK file is downloaded to <TWCore external cache dir>/push/apk/ for installation.

The path TWCore uses to download APK files

Our telemetry revealed previously unknown malware at these file paths. On top of that, our data indicates that in every observed case, the malware was installed by an app with the package name com.tw.core, which matches the TWCore package name.

Next, we’ll break down the malware installed by TWCore: the JarService dropper.

Stage 1: the JarService dropper

As mentioned earlier, JarService is a small dropper app with no UI of any kind. It decrypts data stored as encrypted blocks within the Trojan’s code. Each block is XOR-encrypted with a single-byte key that shifts linearly from block to block. The decrypted data contains serialized information about the payload version and entry point, along with the malware’s own code for further loading.

Decrypting and deserializing information about the stage 2 payload

In the version of JarService we analyzed, the entry point for the next-stage payload was the wa method of the com.c.j.qbh class.

Stage 2: the loader

This stage’s payload is a malicious loader. Its code contains encrypted strings that are later used as class names to execute the stage 3 payload using the reflection mechanism. The loader sends implant information to one of the attackers’ servers via a POST request. Example of a request to the C2 server:

{
    "userId": "REDACTED",
    "dexVersion": "1.7",
    "dexType": 1,
    "channelId": "2039",
    "packageName": "com.tw.jar1",
    "appVersion": 12,
    "appName": "JarService"
}

In response to the POST request, the C2 server returns a link for downloading the stage 3 payload. An example of a C2 response is shown below.

{
    "code": 200,
    "data": {
        "dexUrl": "hxxp://144.217.243[.]201/vr34der34/dex3.68.png",
        "dexVersion": 3.680,
        "status": 0
    }
}

The Trojan uses the link in the dexUrl field of the data object to download serialized data for loading the next stage. This data begins with a single-byte integer, a key used to decrypt the strings in the loader’s code. Immediately following this number is a four-byte floating-point value used to XOR-decrypt the stage 3 payload, which itself is located after these keys.

Decrypting the stage 3 payload

In the decrypted payload, the entry point is the init method of the com.ast.sdk.BillingMain class, shown in the screenshot below.

Entry point of the stage 3 payload

While analyzing this stage, we noticed that the download link for the next-stage payload includes a version number. We decided to try other version numbers to retrieve different payload versions, and ultimately obtained seven distinct variants, which we list under “Indicators of Compromise” at the end of this report. The earliest version, numbered 3.57, uses a different decoding algorithm than the one described above. This may indicate that an earlier version of the infection chain used a different loader between JarService and the stage 3 payload.

Stage 3: clicker / reverse proxy loader

In this stage, the malware sends a POST request to /cpc/api/task every 90 minutes by default, containing information about the infected device (display resolution, device model, the SSID of the connected Wi-Fi network, MAC address, and so on) along with the Trojan’s configuration version. If the configuration is outdated, the C2 server returns an updated configuration containing new C2 addresses and new paths for sending HTTP requests. An example of a response is shown below. Note that at the time of our research, the most up-to-date configuration version was 3.82.

{
    "code": 100,
    "data": {
        "configVersion": 3.820,
        "hosts": ["hxxp://t2.kshahnd[.]sbs", "hxxp://t2.mdsjhd[.]sbs", "hxxp://t2.nmnsny[.]sbs", "hxxps://t2.nmnsny[.]sbs"],
        "interval": 5500000,
        "reportApi": "/cpc/api/report",
        "tagName": "config",
        "taskApi": "/cpc/api/task",
        "updates": ["hxxp://a2.kshahnd[.]sbs", "hxxp://a2.mdsjhd[.]sbs", "hxxp://a2.nmnsny[.]sbs", "hxxps://a2.nmnsny[.]sbs"],
        "vn": 1.010
    }
}

If the configuration version doesn’t need updating, the C2 server instead returns integer command identifiers, which the attackers refer to as productId. The Trojan maps each identifier to command information, which it stores as a serialized JSON object using the SharedPreferences API. Each identifier also has its own version, expressed as a UNIX timestamp. If the C2 response includes an unknown productId or one whose version is outdated, the malware sends a GET request to the attackers’ server at /cpc/api/xml to retrieve the command contents for all such identifiers. The C2 server responds with command information for each unknown identifier. An example of a response is shown below.

{
    "code": 200,
    "data": [{
        "productId": 979,
        "script": "{\n  \"loadType\": 1,\n  \"reload\": true,\n  \"method\": \"start\",\n  \"url2\": \"hxxp://144.217.243[.]201/vr34der34/sh65.io\",\n  \"md52\": \"de77c3303e93c9450424759f1741441c\",\n  \"name\": \"zhima\",\n  \"className\": \"com.miyc.transfer.Client\",\n  \"thread\": true,\n  \"tagName\": \"loadlib2\",\n  \"params\": [\n    {\n      \"type\": \"Context\"\n    },\n    {\n      \"type\": \"String\",\n      \"value\": \"107.151.248[.]132\"\n    },\n    {\n      \"type\": \"String\",\n      \"value\": \"1002\"\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 1337\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 7777\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 8888\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 15000\n    }\n  ],\n  \"url\": \"hxxp://144.217.243[.]201/vr34der34/sh65.io\",\n  \"md5\": \"de77c3303e93c9450424759f1741441c\"\n}",
        "version": 1778650942
    }, {
        "productId": 1019,
        "script": "{\n  \"loadType\": 1,\n  \"reload\": true,\n  \"method\": \"start\",\n  \"url2\": \"hxxp://144.217.243[.]201/vr34der34/sh65.io\",\n  \"md52\": \"de77c3303e93c9450424759f1741441c\",\n  \"name\": \"zhima\",\n  \"className\": \"com.miyc.transfer.Client\",\n  \"thread\": true,\n  \"tagName\": \"loadlib2\",\n  \"params\": [\n    {\n      \"type\": \"Context\"\n    },\n    {\n      \"type\": \"String\",\n      \"value\": \"128.14.210[.]58\"\n    },\n    {\n      \"type\": \"String\",\n      \"value\": \"1002\"\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 9999\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 7777\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 8888\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 15000\n    }\n  ],\n  \"url\": \"hxxp://144.217.243[.]201/vr34der34/sh65.io\",\n  \"md5\": \"de77c3303e93c9450424759f1741441c\"\n}",
        "version": 1766001509
    }, {
        "productId": 3505,
        "script": "{\n\"tagName\":\"http\",\n\"url\":\"hxxps://api.kookjar[.]com/sayhi?channel=daihai&uuid={get_uuid_10}\"\n}",
        "version": 1776656317
    }],
    "msg": ""
}

The command information includes a tagName field, which is the command name. The code maps each name to the corresponding class responsible for executing it.

List of executable commands

At the time of our research, the attackers had implemented nine commands. The table below lists command names, brief descriptions, and arguments. The functionality of these commands suggests that the malware can be used to display ads, commit ad fraud (serving as a clicker), and download additional malicious code.

However, attackers use only a relatively small subset of these commands in real-world attacks. As shown in the example C2 response above, at the time of publishing this report the attackers were using the loadlib2 and http commands. The payload downloaded via the loadlib2 command is a reverse proxy module named “zhima”, which researchers from the Nokia Deepfield Emergency Response Team independently discovered in TV set-top boxes around the same time as we did and also described in their report. This confirms that the attackers’ ultimate goal is building a proxy botnet.

While investigating this stage of the attack chain, we noticed that the zhima download link also included a version number. As with the previous stage, we tried other possible version numbers and found eight variants of the zhima module, the earliest of which was version 57. The complete list of identified zhima modules is provided under “Indicators of Compromise” below.

Attribution

While analyzing the complete infection chain, we noticed that the stage 2 loader created a thread with the meaningful name mosdk-host-loader. We decided to investigate what mosdk referred to in that name. This led us to a malicious app installed on various TV set-top boxes with the package name com.abc.nexus (3AD4BF5A86D26FFBF09CAE42AF330A98). It consists of several components (including a dropper similar to JarService), each used by the attackers to covertly monetize the device’s computing power. Each malicious component in the app corresponds to its own service, and the service containing the launch code for the JarService-like dropper is named AdmoyuService. In light of this and the name of the malicious thread found in the payload code, we concluded that moyu in the service name referred to MoYu Group, one of the actors linked to the BADBOX malware platform, which had been described by researchers at HUMAN. This assessment is further supported by extensive overlap between the malware’s network infrastructure and that of MoYu Group, which was independently identified by researchers from the Nokia Deepfield Emergency Response Team around the same time as our own research. Based on these similar naming patterns and prominent infrastructure overlap between the activity of MoYu Group and the attacks described in this report, we attribute it to the same actor with high confidence.

While investigating the malware downloaded by TWCore, we noticed that the domain admin.uipoxy[.]com resolved to the IP address 128.14.210[.]58, one of the C2 servers for the zhima reverse proxy module. It appears that the URL hxxp://admin.uipoxy[.]com/proxy/u/login hosts the zhima admin panel. Interestingly, this panel allows anyone to register as long as they have a valid invite code.

The malware operator registration page

During registration, users are prompted to review the terms of use and privacy policy. Both documents are hosted on links under the pxyedge[.]com domain, which belongs to PXYEDGE, a vendor specializing in the sale of residential proxies.

On the registration page hosted at admin.uipoxy[.]com, we also found the string copyright © 2020 proxyforu[.]com all rights reserved, which linked to hxxps://proxyforu[.]com, the website of ProxyForU, another vendor of residential proxy services.

We found several similarities in the authentication APIs across all of these sites:

• The sign-in page was hosted on an admin.* subdomain.
• The sign-in page was located at /proxy/u/login.
• The signup page was located at /proxy/register?channelKey=<invitation code>.

Based on this, we believe these services are connected to MoYu Group.

Conclusion

Despite efforts by cybersecurity professionals and law enforcement to shut down the BADBOX botnet, individual actors linked to it continue their malicious activity, infecting devices worldwide. Delivery methods for this kind of malware vary widely, from downloads via pre-installed backdoors to infected builds of IPTV apps. The case examined here demonstrates an even more sophisticated delivery method: distribution through the legitimate update functionality of a system application. Attackers are also actively expanding into new platforms. This malware is the first known malicious app targeting head units, which means these platforms now require protection against malware as well.

Indicators of compromise

Stage 1: JarService

ba27951b4ee1c341f4415d033369ecd3
d63bacd6d6709dd68a10ef9d374c7835
6c2e34b30da42085240ede53ab6107d4
8b5e513144a6138a966ea59e68bf9da2
e119845877089d6f4b0a70dc7388f316

Stage 2: loader

e9f3a0dab6949ce2cddab9e0aa80ae1a

Stage 3: loader/clicker

0fbaa7092204f4b1494e0b840b014774
1dcf031c40ce456b6a36a00b0acf3d11
44b6b213a6a3f299eaf88e078de95ecb
67dc78e544ebce16b85dc7c195dfbc58
9642ae619b3165d23c6349002d1abe24
b067d5b0dbecbd6498bcdfba45dba77e
f0e3f7eba2cde91e2dedb921bab47422

zhima module

412e9243f2981bbea3894254d105b3b8
71ab5517f71866279d0d87d37f2ae320
89ef78f716a75964539f2db6520be362
a4223ce4288a230d1e6c3ff2c7639045
bd4d81cd27125ad3d9a114922d468499
c6bfb1643ac7474ed8a7b4f96a187fdb
de77c3303e93c9450424759f1741441c
f8cf8c23ff597700d471fb7767df8bac

Domains and IP addresses

xmsae[.]sbs
ishano456[.]sbs
xshaon123[.]sbs
kshahnd[.]sbs
mdsjhd[.]sbs
nmnsny[.]sbs
kookjar[.]com
ty54fgd435[.]my
ue886578433[.]online
ty4523[.]space
144.217.243[.]201
107.151.248[.]132
128.14.210[.]58

Addresses used to download JarService

hxxp://ovcloudcontrol.cdn.cardoor[.]cn/upgrade/2026-06-08/bd80bd3c3d0e4bf6b5b4a825650d01f5.apk
hxxp://ovcloudcontrol.cdn.cardoor[.]cn/upgrade/2025-06-10/fe71af9ecf174de48d2b2ccc2c15fb04.apk
hxxp://ovcloudcontrol.cdn.cardoor[.]cn/upgrade/2024-11-07/fa831c3c23824b99871163387bcda7ad.apk

Hashes of TWCore (the legitimate software used to distribute JarService)

2a64c3efc11bf224aa54f24e876446c9
7a4d3ba2dacccfdda55859a5dfee2671
ea24487996eb70c1780922fb3063bcc5