❌

Normal view

There are new articles available, click to refresh the page.
Before yesterdayMain stream

GoSerpent: a persistent threat evolves with sophisticated data collection and exfiltration

16 July 2026 at 08:00

Introduction

In February 2026, we discovered a set of malicious activities that had been ongoing since late 2025. These activities involved a RAT module written in Go with proxy capabilities, which served as the main stage of the attack. The attack targeted government and diplomatic entities in Southeast Asia and showed a level of sophistication that caught our attention.

During the attack, the main malware, dubbed GoSerpent, received an encrypted argument and started communicating with a remote server. It was also used to deploy further malicious tools to collect sensitive data and dump credentials on the system.

Monitoring the activities of this threat actor revealed that in May 2026, they came back with an evolved set of malicious tools: a new RAT and proxy tool, Stowaway, which resembled the initial malware, as well as an additional stealthy tool to exfiltrate sensitive data collected in the previous few months through network shares.

We found earlier versions of the GoSerpent backdoor used since 2021 against victims in Southeast Asia with relatively simpler code that received command-line arguments in plain text. Even though the newer variant is stealthier, the attackers continued using the simpler version alongside the latest one in their recent attacks.

What makes this threat particularly concerning is the strategic deployment of various tools with sophisticated data collection and exfiltration capabilities.

In this article, we introduce the malicious tools uncovered by us, which have been used since late 2025.

Technical details

Initial phase of the attacks

The initial phase of the attacks involved deployment of the GoSerpent backdoor, followed by additional malicious tools. During this phase, the main goal was to collect sensitive files and store them for future exfiltration, which was done by a data collecting tool, ThumbcacheService. The attackers also needed system credentials to exfiltrate the collected data through network drives at a later stage. This was achieved through a number of credential dumping tools deployed in this phase via the GoSerpent backdoor.

GoSerpent backdoor

The primary weapon in this campaign is the GoSerpent backdoor, a sophisticated Go-based remote access Trojan that has been active since at least 2021, with the most recent variant deployed in 2026.

This malware receives encrypted and base64-encoded command-line arguments containing a C2 server address and communication password, which are decrypted using AES-CBC mode with a fixed IV (31323334353637383930616263646566) and keys derived from predefined strings.

The backdoor connects to command-and-control servers using ChaCha20 encryption for communications, with the SHA256 hash of the communication password serving as the encryption key.

GoSerpent supports multiple C2 commands by receiving special command values. The commands include the following:

Command Symbol (as derived from corresponding function names) Description
2BA1 Sync Respond to the server to show the infection is active
3BA2 Exit Exit process
4BA3 Ls Start listening on a port
5BA4 Connect Connect to a remote server
6BA5 Hello Create a shell on the infected machine
7BA6 Ul Upload a file or directory to the server
8BA7 Dl Download from the server
9BA8 Ss5 Start a SOCKS5 proxy on the infected machine
ABA9 Cl Close a listening port
CBAB RF Forward to a connected node

GoSerpent can establish SOCKS5 proxy servers to route traffic through compromised hosts, enabling attackers to access other networks while masking their true IP addresses. The backdoor is capable of deploying additional malicious tools, including ThumbcacheService for file collection, Mimikatz for credential dumping, and QuarksDumpLocalHash for local account password hash extraction. The malware exhibits strong persistence mechanisms and uses filenames that mimic legitimate system processes such as lass.exe and updates.exe to evade detection.

McMx RAT

McMx is a basic Go-based proxy and remote access tool that represents a simpler variant of the GoSerpent backdoor, apparently compiled from a different GitHub repository path.

Unlike the latest variant of GoSerpent, which uses encrypted command-line arguments, McMx receives input parameters from text files in plaintext format β€” in a way that resembles older versions of GoSerpent. The malware features similar function names with apparent typos present in both tools.

Before executing McMx, attackers manipulate batch files to generate configuration files containing C2 parameters. The patterns observed show the use of echo commands to create configuration files with parameters like remote host addresses, ports, and secret keys. The McMx malware is then deployed with this configuration.

The tool shares core functionalities with GoSerpent, including:

  • SOCKS5 proxying
  • port forwarding
  • file transfer
  • remote shell capabilities

Data collection and credential dumping tools

Following initial deployment of the GoSerpent backdoor, attackers typically wait several days before utilizing it to download and execute additional malware components for data collection and credential dumping.

ThumbcacheService

ThumbcacheService is a malicious DLL deployed as a Windows service that functions as a sophisticated file collection mechanism within the GoSerpent ecosystem. The malware employs XOR encryption with a single-byte key of 0x13 for string obfuscation. It decrypts embedded strings and creates a database file named thumbcache_605a.db in the C:\Users\Public\ directory to store collected sensitive files. It specifically targets documents with the following extensions: .doc, .docx, .pdf, .xls and .xlsx.

The targeted files are then archived using 7-Zip and protected with a predefined password @vx0a9n5W2M0c3D6.#, enforcing a 20MB size limit for archives.
The malicious service also monitors the $Recycle.Bin directory for deleted files with the extensions of interest, ensuring comprehensive data collection.

Credential dumping tools

The threat actor deploys the following tools via GoSerpent backdoor to dump credentials:

  1. Mimikatz β€” dumps memory from the LSASS process to extract credential material, including cached credentials and Kerberos tickets.
  2. QuarksDumpLocalHash β€” extracts local account password hashes from the SAM registry hive, allowing for offline password cracking attacks.

These tools work together to maximize information extraction from compromised systems. The stolen credentials were used in later stages of the attack to facilitate the exfiltration of sensitive files collected by ThumbcacheService.

Second stage of the attacks

After the initial phase of the malware deployments, the attackers allowed a few weeks for the ThumbcacheService to silently collect sensitive files without exfiltrating them. In the meantime, the credential dumping tools also continued to steal credentials. In May 2026, the threat actor came back with a set of new tools. The main malware of this round of activity was another Go-based RAT and proxy tool, Stowaway. It was used to deploy the two-stage data exfiltration tool TmcLoader/TmcPayload, which was the last piece of the data theft puzzle.

Stowaway

Stowaway is a proxy and remote access tool compiled from an open-source framework with customized functions to make the infection stealthier. This malware features both network admin and agent capabilities, enabling attackers to establish chained proxy paths across multiple hosts with the following functionalities:

  • SOCKS5 proxying
  • port forwarding
  • reverse tunneling
  • remote shell access
  • file transfer
  • SSH-based tunneling

Communications are transported over TCP, HTTP, or WebSocket channels protected by AES-256-GCM or TLS encryption.
As the next step, the attackers deliver two files to the victim machine via Stowaway:

  • TmcLoader with an embedded payload
  • {BBF061R2-BE25-4F6D-8B2D-1A6A39C3FSA2}.db β€” an encrypted configuration file

TmcLoader/TmcPayload

TmcLoader is a stealthy C++ loader module registered as a Windows service. The malware embeds an encrypted payload dubbed TmcPayload within its .data section, which is decrypted and loaded into the memory space of the svchost process to maintain persistence and avoid detection.

TmcLoader employs dynamic API resolution through a circular XOR encryption, where each byte is XORed with the value of the subsequent byte, combined with Base64 encoding for string obfuscation to hide API names.

The loader creates a unique event to prevent multiple infections on the same system. After that, it extracts and decrypts the embedded TmcPayload. This payload component is responsible for exfiltrating sensitive data from the victim’s machine.

TmcPayload generates a file path from an obfuscated string: C:\Users\Public\Libraries\{BBF061R2-BE25-4F6D-8B2D-1A6A39C3FSA2}.db.

It then checks for the existence of this configuration file. If the file doesn’t exist, it delays execution for a random period of time before rechecking. The configuration file contains encrypted network share credentials and destination paths for data exfiltration. It specifically references the thumbcache_605a.db file created by ThumbcacheService as the file to be exfiltrated, demonstrating the integrated nature of the attack chain.

Toolset integration

What distinguishes this threat actor’s approach is the deliberate integration between different components of their toolset. The chain from ThumbcacheService to TmcLoader/TmcPayload demonstrates sophisticated operational planning:

  1. ThumbcacheService: deployed via GoSerpent, collects and archives sensitive files into the thumbcache_605a.db database file.
  2. Credential dumping tools: deployed via GoSerpent to retrieve system credentials.
  3. Configuration file: delivered via Stowaway, contains credentials and file paths for data exfiltration.
  4. TmcLoader/TmcPayload: deployed via Stowaway, reads the configuration file for data exfiltration.
  5. Data transfer: using network credentials and destination paths from the configuration file, TmcPayload transfers the exact same thumbcache_605a.db.

This integration shows that the threat actor has carefully orchestrated their tools to work together seamlessly, ensuring that data collected by one component is available for exfiltration by another component.

Infrastructure

The malware operators leverage legitimate hosting providers, including Alibaba Cloud and UCLOUD HK, for their command-and-control infrastructure. The use of legitimate hosting platforms demonstrates operational security awareness, making detection more challenging.
The technical similarities between GoSerpent and the newer Stowaway tools strongly suggest the threat actor’s deep familiarity with network proxy technologies. The consistent use of legitimate domain names as secret keys, with GoSerpent employing www.microsoft.com and www.spacex.com and Stowaway utilizing github.code, indicates a standardized operational methodology.

Attribution

While the exact attribution of the GoSerpent campaign remains uncertain, there are indications of a potential link to the TetrisPhantom threat actor. The similarities in victim targeting, technical capabilities, and operational methodologies suggest a possible connection. However, further investigation is necessary to confirm this association.

Conclusion

The GoSerpent campaign represents a sophisticated and evolving threat to government and diplomatic entities in Southeast Asia. The threat actor’s use of customized tools, such as the GoSerpent backdoor, Stowaway, and TmcLoader, demonstrates a high degree of technical expertise and operational planning. The integration of these tools to collect and exfiltrate sensitive data highlights the actor’s focus on long-term access and intelligence gathering. As the threat landscape continues to shift, it is essential for organizations to remain vigilant and implement robust security measures to detect and prevent such attacks. By understanding the tactics, techniques, and procedures (TTPs) employed by this threat actor, defenders can better prepare themselves to counter similar threats in the future.

Indicators of compromise

File hashes

GoSerpent
EBFFD5A76AAA690BCDB922F82E0BACC5
DC506FF7BB72735444FB3703A6BEE6D8

McMx
D6E86BF8A90E9B632ADD5FA495F97FBC

ThumbcacheService
CB6C4C70A3B171FA3404B8E1A3382116
64E9D1950E42BC98486DFD9919463D1C

Stowaway
CBBB6D483737EA3566726E51752DFF40
7F223EE0716CE2AD56F55D3744419449
19F8BEFCB035F52BF70094E6B4F5779A
846EF7C1C7323849B2A778C5E4CDA162

TmcLoader
D08A059E8B815E3B891505BC8777FC28
93A1569D5D5AB2C4761FEDF84F83709E

C2 IP addresses

152.32.160[.]239
8.220.194[.]108
8.220.214[.]132
8.220.209[.]155
8.220.193[.]189
101.36.104[.]87
144.48.6[.]46
103.138.13[.]30
47.80.22[.]58
152.32.222[.]113
43.106.30[.]226

OkoBot: new sophisticated malware framework targets cryptocurrency users

15 July 2026 at 06:00

Introduction

In January 2026, we identified multiple attacks involving unknown malware that captures the contents of cryptocurrency wallet windows. During the investigation, we reconstructed the complete infection chain, which consisted of four tightly linked stages initiated by the execution of the previously described malicious PowerShell script TookPS. However, this campaign differs from previous activity in that it uses a new framework to deliver all malicious modules and orchestrate them via an SSH tunnel. In total, the framework includes more thanβ€―20 malicious payloads and implants, covering a wide variety of functions. At the time of writing, the threat remains active.

Kaspersky’s products detect this threat as Trojan-Downloader.Win32.TookPS.*, Trojan.Win64.BypassUAC.*, Trojan-Banker.Script.Agent.gen, Trojan.Win32.Dllhijack.*, Backdoor.Win32.TeviRat.*, Trojan-PSW.Win64.Stealer.*, Trojan-Spy.Win64.Keylogger.*, Trojan-Spy.Win64.Agent.*, Trojan.Win64.Agent.*.

Background

TookPS is a downloader used for retrieving malicious commands and scripts from attacker-controlled servers to further propagate attacks. The first campaign using TookPS was discovered in Marchβ€―2025. At that time, malicious scripts delivered a Python‑based infostealer along with a script that installed and configured an SSH tunnel on the victim’s machine. The next wave appeared in Aprilβ€―2025: the payload was changed, and TookPS was used to deliver the TeviRAT malware with the same SSH installer.

Then at the end of April 2025, TookPS underwent minor changes, yet its attack chain was completely redesigned. Unlike previous incidents, in this case, TookPS was used solely for the initial infection, with an automated SSH bot responsible for payload delivery. This new malicious campaign has multiple stages that cover the full attack lifecycle, from initial infection to persistence and data exfiltration. Among various malware strains, at one of the stages, the TeviRAT backdoor is delivered to the compromised host, ultimately fetching another version of a TookPS script.

We dubbed this updated TookPS campaign β€œOkoBot”.

Original OkoBot infection chain

Original OkoBot infection chain

We will break down this chain in greater detail later in the article. However, this is not the only version of OkoBot we were able to find. Already in Marchβ€―2026, we discovered a new phase in the development of the framework, with Volume2 now being installed directly using TookPS. The HDUtil launcher β†’ extl injector β†’ Rilide chain was found to be abandoned in this newer version since it was replaced in full by the identical ext_daemon Volume2 plugin. TeviRAT was also removed, most likely because its functions were covered by the new plugins dispatcher.

New OkoBot infection chain

New OkoBot infection chain

Initial infection

The initial infection is primarily delivered through two vectors: a ClickFix attack, and malware distributed through GitHub that masquerades as legitimate software. One such example is the fake SQL Server Management Studio (SSMS) package distributed through GitHub. In fact, it is actually the legitimate AudacityΒ β€” a popular audio editorΒ β€” compiled with a malicious implant embedded in one of its libraries. Because the repository was indexed by most search engines and appeared at the top of the results for the query SSMS, the malware looked legitimate and quickly earned users’ trust.

Malicious application distribution report

Malicious application distribution report

This repository was created at the end of Marchβ€―2025 and existed until June of that year. It consisted of a single file, README.md, which provided a fake SSMS installation guide written in an official style and likely derived from excerpts of Microsoft’s documentation. However, the download link for the program, located at the beginning of the guide, pointed to the latest release in the same repository.

Both infection vectors trigger the execution of the malicious script TookPS, which installs SSH on the victim’s system, establishes a connection to the attacker-controlled SSH server and subsequently forwards the SSH daemon port. Following a delay, an automated SSH bot connects to the forwarded port.

Back connection

The automated SSH bot collects system information such as usernames, antivirus software installed, the IP address, and OS version. It harvests cryptocurrency wallet files, browser cookies, profiles, and other credentials through an SSH tunnel. For subsequent delivery of malicious modules, it disables Windows Defender notifications via a registry modification. Moreover, it gains access to the graphical session on the victim’s system using the following sequence:

  1. Open firewall ports for inbound RDP traffic
  2. Create a user in the β€œRemote Desktop Users” group
  3. Replace the legitimate termsrv.dll with a patched one to permit multiple concurrent RDP sessions
  4. Create a scheduled task named Apple Sync to maintain a reverse SSH tunnel that forwards the local RDP port every hour

After that, the SSH bot begins retrieving malicious modules over SFTP.

Launcher with advanced options

One of the deployed modules is HDUtil, an auxiliary utility protected with VMProtect and heavily obfuscated. This launcher is used by the SSH bot during an attack to deploy various malicious modules via the target command. Additionally, it implements three auxiliary commands that were not observed during the attacks we analyzed. Nevertheless, their presence and potential capabilities further demonstrate the high degree of integration among all components of the framework.

Active sessions

At startup, the launcher verifies its execution environment by checking the HWID in the contents of %PROGRAMDATA%\hwid.dat, a technique consistently employed throughout the framework. If the file is missing or contains invalid data, such as a non‑MD5 hash, the launcher terminates without performing any further actions. Otherwise, the specified commands are executed. For example, enumsessions provides a list of sessions along with detailed information, including the session type (Console, Services, RDP, and others), username, connection host, and domain. In turn, enumadapters returns the names of all graphics adapters present on the system.

Example output of HDUtil enumeration commands

Example output of HDUtil enumeration commands

UAC bypass

The most important command of the launcher is target, which enables payload execution on the system. An optional nouac argument enables automatic UAC bypassing via Windows RPC and an auto-elevated msconfig.exe program, allowing the payload to run with elevated privileges stealthily. This technique has been known for a long time, discovered and described in 2019 by the Project Zero team, who provided a full report with a detailed technical description.

Below is the list of all HDUtil commands.

Command Description
target [nouac [user=<user>]] [noattach] <file> Starts file and prints its output.
If optional argument noattach passed, command to be executed in background.
If optional argument nouac passed, automatic UAC bypass to be performed.
If optional argument user passed, new process to be executed under , otherwise default local administrator to be chosen.
pcopy <file> <dir_src> <dir_dst> Copies file <file> located in <dir_src> to <dir_dst>. Not used by SSH bot.
enumadapters Prints names of graphical adapters on current system. Not used by SSH bot.
enumsessions Prints all sessions on current system. Not used by SSH bot.

Browser extensions loader

The first malicious module delivered to the infected system via SFTP is executed using the previously described launcher with the command .\HDUtil.exe target extl.exe. It is a heavily obfuscated DLL injector protected with VMProtect. At startup, the module enters an infinite loop and uses the EnumWindows and IsWindowVisible API methods to enumerate the PIDs of active windows and retrieve the corresponding executable filenames. For processes associated with widely used Chromium‑based browsers, the module invokes a routine that injects a specialized implant.

The injector opens a process, allocates a memory region, and writes the payload directly into this region as unencrypted raw bytes. Then it resolves two exported implant functions, LdrInitMain and LdrCallMain, based on a pre-specified hash derived from a modified version of DJB2 hash function. The first function performs the final PE unpacking, including rebase operations and the initialization of the import and exception tables. The second function directly initiates malware execution.

Setting up protections on the regions and launching the implant

Setting up protections on the regions and launching the implant

This loader installs malicious browser extensions and hides them from the user. It uses an internal engine that resolves the addresses of stripped functions by analyzing the byte patterns of their calls using YARA-style syntax. This approach enables the malicious code to access critical Chromium engine functions required for extension installation and management. This functionality is also implemented for other browsers with appropriate modifications. For example, in the case of Microsoftβ€―Edge, the corresponding DLL msedge.dll is hooked using the specific patterns.

List of the functions hooked by the malware

List of the functions hooked by the malware

Using the obtained address of the BrowserProcess object, the loader traverses the inheritance hierarchy and subsequently resolves a pointer to the function responsible for registering observers of browser‑window creation, specifically ProfileManager::BrowserListObserver::OnBrowserAdded. With a specialized built‑in engine, they are hooked using the attacker’s own implementations while preserving the original function’s address.

The loader replaces the functions it finds with its own

The loader replaces the functions it finds with its own

When a new Chromium window is opened, a hooked function is invoked that silently installs extensions. This routine scans the user’s %APPDATA% directory, loads all .crx files (Chromium-based browsers extension format), and records them in the ext_table. The extensions are then installed in the browser.

During installation, the extension is unpacked into a non‑default extensions directory, Local Extension Settings, and its manifest is dynamically modified. An object named custom_args is added, containing the fields hwid (the identifier of the infected system) and browser (the name of the browser in which the extension is installed). Then, using previously resolved internal functions of chrome.dll, the extension is installed and all requested permissions are granted.

Extensions are unpacked into a non-default directory

Extensions are unpacked into a non-default directory

All extensions loaded in this manner are added to a special array to be subsequently identified among regular extensions and to remain hidden from the user.

The remaining patched functions are used to hide the installed malicious extensions from the user. When invoked with registered extensions as parameters, they perform no operation and return a constant value. This enables the threat actor to suppress notifications related to the malicious nature of the extensions and to exclude them from the displayed list of installed extensions. As a result, the behavior of other extensions remains unaffected.

Stub for hiding malicious extensions

Stub for hiding malicious extensions

During the attack, the Rilide extension was installed on the victim’s system using the previously described loader. Rilide is a stealer targeting Chromium-based browsers that has been frequently used by Russian-speaking threat actors since April 2023. The malware is designed to steal sensitive user data, including login credentials, cookies, and financial information, with a specific emphasis on cryptocurrency theft.

Plugins dispatcher

The final module delivered via SFTP is an open-source utility called Volume2, which is executed with elevated privileges using the command .\HDUtil.exe target nouac noattach Volume2.exe. The executable was linked with the malicious protobuf.dll library. Although the library seems identical to the legitimate DLL, it has been modified to include a malicious exported function, ProtobufGetVer2. This function decrypts and initiates a malicious implant. The payload is encrypted using AESβ€―GCM, initialized with a static 256‑bit key and a 96‑bit nonce. The GCM authentication tag is omitted, resulting in the absence of integrity verification. Starting in Marchβ€―2026, the name of protobuf.dll was changed to version.dll, although its contents remained a modified ProtoBuf library.

Decrypting implant using AES GCM and subsequent mapping

Decrypting implant using AES GCM and subsequent mapping

The loaded implant functions as a malicious plugin dispatcher. Upon initialization, it reads and verifies the HWID before establishing communication with the C2 server via the HTTP protocol. Each request follows a predefined binary format: a 2-byte numeric bot identifier encoded in little-endian format, followed by an AES CBC-encrypted JSON object. By default, the BotID is set to 0, and the key and IV consist of 32 and 16 bytes of 0xff, respectively. The implant polls the server every 20 seconds to retrieve new commands. The request contains client data encoded in Base64, and the server may respond with a command containing three mandatory fields: TaskIndex (the command number from the dispatcher), TaskID (a unique task identifier), and HWID (the client identifier). The dispatcher supports four built-in commands:

Task index Action
1 Reconfigure client: update session keys, assign ID, switch to another C2
2 Load DLL implant into memory and run its entry point
3 Load plugin into process and register tasks with RegisterPlugin function
4 Restart dispatcher as new process
x If the task number is none of the above, search for it among the registered plugins

Each plugin is required to export two functions: RegisterPlugin and PluginDispatch. These functions are used to manage and configure plugins. The RegisterPlugin function registers the plugin’s tasks with the dispatcher, whereas the PluginDispatch function is invoked when the plugin is called. Both these functions, as well as other external API functions, are located within the base libraries using one algorithm. This algorithm iterates through the export table and uses a specialized callback that calculates the MurmurHash3 hash and compares it against the target value to identify the appropriate function.

Resolving a plugin initialization function

Resolving a plugin initialization function

During the analysis, we were able to discover five plugins that implement functions under their unique task identifiers.

  • CMD wrapper (10xx): allows running scripts and individual commands in cmd.
  • PowerShell wrapper (11xx): allows running scripts and individual commands in PowerShell.
  • Environment enumerator (12xx): gathers system information, active sessions, and processes.
  • Dropper (14xx): downloads an additional payload directly onto the system both from embedded Base64-encoded binary blob and via URL.
  • Process injector (16xx): launches additional malicious implants on the target system by injecting them into legitimate processes.

We identified four malicious implants that are delivered to the system via the process injector plugin.

ext daemon

The malware is functionally identical to the browser extensions loader (extl.exe) described above, but less obfuscated and not protected with VMProtect.

SeedHunter

Similarly to extl.exe, this malware monitors the list of active processes in the system and injects an implant into Trezor Suite, Ledger Wallet, and Ledger Live processes. The implant is malware that collects seed phrases of Ledger and Trezor cryptocurrency wallets. Initially, it verifies the HWID, and if it fails, it terminates immediately. Then, based on the value of BaseDllName, the malware determines the process context and uses the corresponding implementation for either Trezor or Ledger. It then utilizes the previously described technique to hook the internal Electron framework functions.

List of functions hooked by the malware

List of functions hooked by the malware

Then the malware communicates with the C2 (moonsand[.]store) over HTTPS, sending a Base64-encoded JSON request containing the fields Pid, HWID, and Build. In response, it receives a JSON payload containing the Wait flag. If this flag is set to true, the malware initiates periodic USB device scans filtered by VID and PID (Vendor and Product ID). Upon detecting a connected Trezor or Ledger hardware wallet, it invokes the hooked functions to display a hard‑coded phishing page designed for seed phrase recovery, with a distinct layout used for each identified wallet. If the Wait flag is set to false, the phishing page is displayed immediately.

When the seed phrase is entered and validated, the JavaScript code of the page outputs the phrase to the console prefixed with @:app:print. This prefix helps identify the malware messages in the hooked function mal_LogConsoleMessage.

Phishing pages for seed phrase recovery

Phishing pages for seed phrase recovery

The obtained seed phrase is subsequently sent to the C2 server within a JSON payload containing fields such as App (ledger or trezor), Build, DeviceName, DeviceHardwareId, and SeedData. Furthermore, an identical JSON, encrypted with the RC4 algorithm using the HWID as the key, is saved in a temporary directory under the filename sh_<ts>.json, where <ts> is the file creation timestamp.

MC Keylogger

This module is a keylogger that, in addition to recording user input, performs three malicious activities:

  1. Clipboard logging: periodically checks various clipboard formats, including CF_HDROP for files dragged between windows, CF_DIB for copied bitmap images, and CF_UNICODETEXT for Unicode text. Each format is handled appropriately, and all copy events are logged under the Clipboard section. Text data is written directly to the log, while copied files are recorded by their file paths. Images are saved as JPG files following the naming pattern bf_YYYY-MM-DD hh_mm_ss.jpg, and the path to the saved image is added to the log.
  2. Logging connected devices: logs information about USB devices connected to the system, including hardware characteristics like VID, PID, manufacturer, and other details.
  3. Screenshot creation: creates a screenshot every five minutes with a name in the format sc_YYYY-MM-DD hh_mm_ss.jpg. A corresponding message is recorded in the log under the Screenshot section, including the path to the screenshot.

Thus, the keylogger creates three types of different file artifacts, which are placed in a temporary directory. Below is an example of a log file generated by the keylogger.

Example of the keylogger log file

Example of the keylogger log file

OkoSpyware

This module, which we dubbed OkoSpyware, captures both keystrokes and the video stream of the target application’s window. It first compiles a list of overβ€―100 executable names, including cryptocurrency wallet applications (such as Exodus or Litecoinβ€―QT), password managers (such as KeePassXC or 1Password), and other widely used applications, to identify which processes should be monitored among all active system processes. For each identified process, the module uses a bundled FFmpeg instance to capture an MP4 video of the window while concurrently logging keystrokes within that window. The resulting video file is saved in %TEMP% as media_<ts> (where <ts> is the recording’s start timestamp). In the same folder, a JSON file named oko_<ts>.json is created, containing metadata about the captured stream, such as the process name, intercepted input, the stream’s MD5 hash, and additional details.

Example of an OkoSpyware metadata file

Example of an OkoSpyware metadata file

The malware also monitors the state of browsers, and when the window title matches a specified regular expressionΒ β€” for instance, a MetaMask or Tonkeeper wallet extension pageΒ β€” it performs video recording and input logging, adding the window title value to the corresponding field in the JSON metadata file.

Artifacts exfiltration

The TookPS script launched via a scheduled task receives a PowerShell exfiltration script as its payload from the C2. All files created by the MC Keylogger and OkoSpyware are sent to the C2 server to the endpoint ir-post.php. After that, the files are deleted from the victim’s system and a command history file, ConsoleHost_history.txt, is cleared.

Sequential exfiltration of artifacts from the temporary directory

Sequential exfiltration of artifacts from the temporary directory

Victims

At the time of writing, we have detected hundreds of victims of the OkoBot campaign in more than 25 countries, with the largest proportion of attacked end users found in Brazil, Vietnam, Canada, Mexico, and TΓΌrkiye.

Distribution of users attacked by OkoBot by country, April 2025–June 2026 (download)

Attribution

At the time of writing, we can’t attribute this malicious campaign to any known crimeware actor. However, during the analysis, we observed that the servers hosting the PowerShell scripts used in the initial infection stage implement server-side geoblocking. When attempting to retrieve the malicious script using an IP from Russia or CIS countries, the server returns an empty response. This technique is very popular among Russian-speaking threat actors.

It was previously mentioned that the campaign uses the malicious Rilide extension, an infostealer that is actively spreading on Russian-speaking, invitation-only cybercrime forums. Additionally, the source code of the SeedHunter phishing pages includes comments in Russian.

Conclusion

The framework described here has numerous modulesΒ β€” mostly written in C and C++Β β€” that are obfuscated and use a variety of packing techniques. Across all stages, specific patterns and techniques can be identified that are borrowed and used in other modules, which allows us to conclude that there is a close interconnectedness among all stages, forming a full‑fledged high‑level framework. Overall, these modules enable a wide range of functions, such as collecting local files, executing remote commands, downloading arbitrary browser extensions, and stealing crypto wallets.

The OkoBot campaign has been ongoing for over a year, and it remains active at the time of publication. Moreover, it is adapting, which indicates that this framework is being maintained and distribution campaigns continue.

Indicators of compromise

Additional information about this threat, with a comprehensive IoC list and decryption scripts, is available to customers of the Kaspersky Threat Intelligence Reporting service. Contact: intelreports@kaspersky.com.

Dispatcher

B07D451EE65A1580F20A784C8F0E7A46 # protobuf.dll
187A1F68AE786E53D3831166DC84E6D2 # protobuf.dll
D84E8DC509308523E0209D3CD3544619 # protobuf.dll
83E6B8FCB92A0B13E109301F8FF649CF # version.dll

Plugins

7306885BB4C98F2A9F056104CF092BC9 # PowerShell wrapper
B4C2E16CDB513BE4DC798F88E2527334 # CMD wrapper
2157D2429124AD28DB7A26F2477CB985 # Environment enumerator
77CECF5E2A622AE07D8AE9913457AB57 # Dropper
E0C3BC27A65750E740C4F1719E531C7D # Process injector

Injector payloads

3D2B43F91F65BFBF36A9C71B6B418876 # ext_daemon.exe
70FEF9FD6E351F4D53CFEEE8DCDFCD99 # seedhunter_x64.exe
ACD31C9941B6C1CABD4E45E6877B9038 # keylog_x64.dll
DD52F5108A176C62AD807C327734AD12 # oko.dll

SSH bot utilities

AC93A821617AEA1F56D4BC0BEF4AF327 # HDUtil.exe
11DBC8A2BEA04B15F8F68F3F01E8FAF9 # extl.exe

File paths

%USERPROFILE%\.ssh\go.bat
%PROGRAMDATA%\HDVideo\HDUtil.exe
%PROGRAMDATA%\hwid.dat
%PROGRAMDATA%\oko_ver
%TEMP%\extl.exe
%APPDATA%\hwid.dat

Domains and IPs

2baserec2[.]guruΒ Β Β Β Β Β Β Β Β  # TookPS
recavb22[.]onlineΒ Β Β Β Β Β Β Β  # TookPS
kbeautyreviews[.]comΒ Β Β Β Β  # TookPS
coffeesaloon[.]onlineΒ Β Β Β  # TookPS
104.243.43[.]16Β Β Β Β Β Β Β Β Β Β  # SSH bot
104.243.32[.]213Β Β Β Β Β Β Β Β Β  # SSH bot
62.210.188[.]209Β Β Β Β Β Β Β Β Β  # SSH bot
livewallpapers[.]onlineΒ Β Β  # Volume2 C2
thatwascringe[.]comΒ Β Β Β Β Β Β  # Volume2 C2
moonsand[.]storeΒ Β Β Β Β Β Β Β Β  # SeedHunter C2

From cause to cash: a cross-border look at hacktivist activity

By: Kaspersky
8 June 2026 at 04:00

While tracking the activities of 4BID we uncovered a new string of campaigns that appear to be the work of several interconnected actors. While politically motivated groups generally limit their scope to specific nations – for 4BID and its peers, primarily Russian and occasionally Belarusian organizations – our latest findings reveal a shift. The actual geographic footprint of these attacks became broader than expected, striking companies across Kazakhstan, the UAE, Syria, and Egypt.

What triggered our investigation was spotting a cluster of indicators of compromise within a breached Russian organization’s infrastructure. We used these footprints to successfully track down other environments hit by the same threat actors and piece together the bigger picture.

This article dives into the software deployed throughout these hacktivist campaigns:

  • New ransomware samples
  • Scripts used at various stages of the attacks
  • Commercially available IT remote monitoring and management (RMM) tools

These include both updated versions of known threat-actor tools and previously unseen software.

Overlapping activity streams

Within the initial organization’s infrastructure, we found numerous activity indicators linked to several interconnected hacktivist groups – which ultimately set the direction for our follow-up analysis. We can attribute the following findings to hacktivist activity with a medium level of confidence:

  • Several samples of BlackReaperRAT, which we attribute to the 4BID group, were found alongside scripts designed to download Panorama9 RMM, AnyDesk, and Dev Tunnels.
  • Besides the artifacts listed above, we discovered ClearWater ransomware in other compromised infrastructures. Interestingly, during this same window, public sources showed Hakerskii Kit claiming a successful attack on a Russian factory. Also detected in that facility’s infrastructure was ClearWater ransomware, with the attackers publicly thanking the Π‘.A.S. group for their contribution.
  • We uncovered several samples of Warp RAT within the hit infrastructures, which we link to the Goffee threat group. A detailed report on this specific activity will be published at a later date.

Technical details

Vulnerable web servers and fd.aspx

Analysis of the compromised environments revealed that the attackers gained initial access in most cases by exploiting the ProxyShell vulnerability in Microsoft Exchange, which allows for full server compromise.

Once inside, the attackers deployed the fd.aspx web shell – a modular ASP.NET file designed for remote control, file transfers, and system reconnaissance. Communication with the web shell relied on a basic security check: if the key parameter in an incoming request failed to match the AUTH_KEY constant, fd.aspx simply returned β€œAccess Denied”.

Access key verification

Access key verification

If the verification was successful, the command contained in the request’s scriptText parameter was passed directly to PowerShell, and the output returned to the operator in the body of the HTTP response. In environments where PowerShell execution was restricted, the web shell swapped it out for cmd.exe. The CreateNoWindow: true and UseShellExecute: false flags were used to keep the command execution hidden from the user.

Beyond running commands, the web shell features bidirectional Base64-encoded file transfers. This allows any binary data – like executables, archives, or certificates – to be passed right inside the body of an HTTP request. The UploadFile function writes files to any directory the web server process can access, which makes it easy to drop additional shells or swap out legitimate files. The DownloadFile function exfiltrates any accessible file from the compromised system back to the attackers’ C2 server.

The web shell also includes a system reconnaissance feature that grabs the following data points:

  • OSVersion: operating system version
  • MachineName: hostname
  • UserName: current username
  • UserDomainName: domain name
  • ProcessorCount: number of processors
  • SystemDirectory: system directory path
  • CurrentDirectory: current working directory
  • Version: .NET Framework version

Additionally, the reconnaissance feature uses the DriveInfo.GetDrives() function to enumerate running processes and map out connected drives – along with the amount of free space available on each. This file system reconnaissance is topped off with LastWriteTime metadata for each object, which helps the operator quickly spot recently modified files and get their bearings within the storage layout.

Alongside the web shells, we encountered a variety of scripts and C2 frameworks across all compromised infrastructures, which we break down below.

Scripts deployed

Once the attackers gained control over a target system, they moved on to the next phase: loading their required toolkit via custom scripts. Variations of these scripts were consistently found alongside fd.aspx on compromised hosts. Most of them interact with legitimate tools, which makes them look almost identical to routine administrative scripts at first glance. The only real giveaway is the code comments, written in Ukrainian. One such script is responsible for deploying AnyDesk on the compromised host.

The build quality of these scripts is worth discussing separately. Several of them show telltale signs of AI generation; inside some compromised systems, we found multiple iterations of the exact same script, a few of which were completely broken. AI-generated code typically fails to work out of the box and requires manual tweaking to run properly.

First, the script checks for admin privileges, as it cannot proceed without them. If that check passes, it looks for an active anydesk.exe process. If the process is missing, the script fetches and installs the application directly from the official website. Once AnyDesk is successfully installed, the script configures an unattended access password and pulls the unique AnyDesk ID. All the collected details are compiled into a report and exfiltrated to the attackers’ server at 185.221.153[.]121. Because we spotted simultaneous activity from multiple groups – 4BID, Hakerskii Kit, and C.A.S. – on the analyzed hosts, this IP address could potentially belong to any one of them.

Besides AnyDesk, the threat actors leverage other legitimate tools. One example is Microsoft Dev Tunnels, a Microsoft service that exposes a local server to the internet. It’s brought into the system by a separate script that, much like the one for AnyDesk, checks if the utility is already present before downloading it from the official site. In certain instances, the utility was fetched directly from the attackers’ server instead:


Once installed, the application runs, and the resulting connection details are saved to a file named login.txt. The contents of this file consist of standard instructions for using a provided code to authenticate on a Microsoft page through a web browser.

To sign in, use a web browser to open https://login.microsoft.com/device and enter the code [CODE].

As a final step, the script opens up the required ports and creates the tunnel, giving the attackers a back door into the compromised host.

Another script we uncovered handles the installation of Panorama9, a legitimate remote monitoring and management utility. Immediately after downloading that application, the attackers configure it via the registry to hide both its system tray icon and its installation folder. To camouflage the Panorama9 services, the attackers rename them to Windows Update Helper and Windows Update Helper Cache and swap out their descriptions, making the utility look almost identical to standard system components. Once the utility finishes its job, the script clears its tracks.

The attackers used a dedicated script to establish persistence on the system. When executed, it used the net user command to spin up a local user account and then hid it via the registry. The script added this new user to every available local group; if the machine was domain-joined, it also attempted to inject the user into all Active Directory groups.

At the same time, the script tweaked RDP settings: it set the minimum encryption level through the registry, added a firewall rule to allow port 3389, and ran the relevant services.


After it wrapped up its main tasks, the script wiped the event logs, command history, temporary files, and finally itself. Once the attackers got what they wanted out of the infected host, they triggered another script that removed the previously created user account, cleaned out the registry keys generated during the earlier phases, and then deleted itself as well.

The scripts described here are just the most telling examples out of dozens of samples we found. An analysis of the attackers’ toolkit reveals a clear trend: they aren’t just fine-tuning the solutions they’ve used in the past (specifically, the AnyDesk deployment script), but are actively broadening their arsenal with new tools like Panorama9, Dev Tunnels, and others.

Publicly available utilities

As previously mentioned, the attackers leverage a broad spectrum of dual-use public software, such as all kinds of remote monitoring and management utilities. While they use the scripts discussed above to drop some of the utilities onto systems, we didn’t encounter scripts for others, so we can’t confirm whether any exist. We observed the following tools deployed across the campaigns in question:

  • AnyDesk: a remote administration tool
  • Advanced IP Scanner: a network scanning utility
  • Dev Tunnels: a Microsoft service used for exposing a server to the internet
  • Panorama9: an IT infrastructure management and monitoring service
  • Nezha Monitoring: a server status monitoring utility
  • Tactical RMM: a remote monitoring and management tool

C2 and communications

To gain a foothold in the victim’s infrastructure, the attackers relied on several post-exploitation frameworks. Some of these are publicly available utilities, while others are custom-built.

Among the publicly available tools in the group’s arsenal are:

  • Sliver
  • Havoc
  • Apollo Mythic
  • Adaptix

We also discovered a previously undocumented backdoor, dubbed BlackSalt, which contacts the C2 server to fetch commands and executes them via cmd.exe.

Sliver

On several hosts, following the initial Microsoft Exchange server compromise, files named upd.exe, winhost.exe, update1.exe, update.exe, and akolo.exe were dropped alongside the previously mentioned fd.aspx files and scripts. All of them were located in the C:\Windows\System32\inetsrv\ directory and were configured as SFX archives with nearly identical payloads, which ran an install.bat script upon extraction.

Contents of the SFX archive

Contents of the SFX archive

The install.bat script contents

The install.bat script contents

The script copies the malicious components into the Windows folder and installs servicechecker.bat as a system service. To do this, it leverages the legitimate Windows Service Wrapper (WinSW) utility included in the archive under the filename backupsrv.exe. The archive also contains the WinSW configuration file, backupsrv.xml, which specifies exactly which script should be registered as a service. Once installed, servicechecker.bat is configured to run automatically on system boot.

The servicechecker.bat script, in turn, runs backupagnt.exe, a loader for the main malicious component housed in WindowsInternal.UpdateComponent.dll. This file was built with the help of the Donut utility and is encrypted with a simple single-byte XOR key (0x0F). Its primary job is to inject the Sliver code straight into the device’s memory.

The backupagnt.exe loader code

The backupagnt.exe loader code

All Sliver instances uncovered during this investigation were configured to communicate with the C2 server at 185.221.153[.]121 over mTLS.

Havoc

Inside a similar SFX archive located in the user directory $user\desktop\ under the filename demon.x64.exe, we found another post-exploitation framework: Havoc. This instance was configured to communicate with the C2 server at 77.72.85[.]62.

Apollo

Mythic Apollo is a cross-platform post-exploitation agent used within the Mythic framework to manage compromised systems. It provides a persistent connection to the C2 server, executes operator commands, handles file uploads/downloads, runs arbitrary code, and supports expansion via plugins. We previously provided a detailed breakdown of the Mythic framework in our post, Hunting for Mythic in Network Traffic.

Here is an example of the Mythic Apollo configuration we encountered in these hacktivist attacks:


This specific sample of the .NET Mythic Apollo agent was compiled with an extensive suite of modules and supports multiple transport profiles that enable communication via HTTP, TCP, WebSocket, SMB, named pipes, and web shells. The C2 address 77.72.85[.]62 is hardcoded into its configuration.

Adaptix

AdaptixC2 is another post-exploitation framework in the attackers’ arsenal. This is a relatively new open-source project, which we broke down in our post, Adapt or pay:an analysis of the AdaptixC2 framework.

The agent samples discovered during our investigation into these hacktivist campaigns consist of a packed AdaptixC2 Beacon delivered via a custom x64 loader. Upon execution, the payload decrypts an embedded shellcode, allocates memory, and executes the malicious payload using the CreateThread WinAPI function. Packed inside the shellcode is the AdaptixC2 Beacon agent in DLL format, featuring a configuration encrypted using RC4.

According to the AdaptixC2 classification system, this agent falls under the BEACON_HTTP type. It is capable of executing commands, performing file operations, enumerating and killing processes, launching new programs, and exfiltrating data back to the C2. It also supports SOCKS port forwarding and BOF modules.

AdaptixC2 uses encryption to keep its configuration under wraps. The corresponding block contains the data size, the actual RC4-encrypted configuration, and a 16-byte key.

Example agent configuration

Example agent configuration

Example of agent requests pinging the C2 address, as flagged by Kaspersky solutions and displayed in Kaspersky Threat Lookup

Example of agent requests pinging the C2 address, as flagged by Kaspersky solutions and displayed in Kaspersky Threat Lookup

BlackSalt Backdoor

During the investigation, we also came across target infrastructures running vulnerable versions of Microsoft Exchange where – much like the Sliver cases – SFX archives named WindowsServiceHelper.exe were discovered in the C:\Windows\System32\inetsrv\ directory. Once extracted, the archive executed an install.bat file.

SFX archive contents (09d0517a1f69feff8186655ae3b567e0)

SFX archive contents (09d0517a1f69feff8186655ae3b567e0)

The install.bat script contents

The install.bat script contents

Similar to the other archives of this type, the script uses the WinSW utility to install the malicious components. In this specific case, however, the primary payload is a file named svc.exe, which turns out to be an obfuscated backdoor written in VBS. Much like the deployment scripts used for the remote management utilities, the code of this setup BAT script was clearly put together with AI tools and features comments in Ukrainian.

Main backdoor loop

Main backdoor loop

The backdoor is essentially a textbook reverse shell. Its capabilities boil down to fetching commands from the C2 server at 45.150.109[.]2, executing them via cmd.exe, and piping the output back to the C2.

EDR killers

In their attacks, the threat actors deploy what are known as EDR killers: malicious tools designed to disable security software on the system. In the vast majority of cases, these utilities rely on the BYOVD technique.

On the hosts compromised during these hacktivist operations, we discovered samples named kil.exe and Killer.exe. These are modified versions of the public, Rust-based BYOVD project EDRKiller. The attackers streamlined the utility to act strictly as a client for the driver and expanded the hardcoded list of security processes to terminate. The sample targets the vulnerable Warsaw_PM driver, though it lacks the functionality to load the driver itself – the attackers drop it onto the system separately.

The general workflow plays out as follows:

  1. In user mode, the program finds the PID of the target process.
  2. It opens a handle to \\.\Warsaw_PM.
  3. It constructs a buffer containing the target process’s PID.
  4. It calls DeviceIoControl.
  5. The driver executes the calls:
    • ZwOpenProcess;
    • ZwTerminateProcess.

The EDR killer continuously enumerates processes, repeatedly sending the IOCTL and terminating the target processes every single time they pop up.

Example of the process list storage inside the EDR killer

Example of the process list storage inside the EDR killer

Both kil.exe and Killer.exe share the exact same list of processes targeted for termination:

MsMpEng.exe, SenseIR.exe, SenseNdr.exe, SenseCncProxy.exe, SenseSampleUploader.exe, NisSrv.exe, avp.exe, kavfs.exe, bdagent.exe, bdservicehost.exe, vsserv.exe, AvastSvc.exe, AvastUI.exe, aswidsagent.exe, avgsvc.exe, mfemms.exe, mfefire.exe, mfevtps.exe, dwengine.exe, dwservice.exe, elastic-agent.exe, elastic-endpoint.exe, Sysmon.exe, wazuh-agent.exe, ipban.exe

Another utility used to kill security software processes is ghostdriver.exe, an unmodified build of the open-source project GhostDriver. In this case, the attackers simply pulled a version straight from GitHub and didn’t modify any of its code.

Example of output from the GhostDriver utility

Example of output from the GhostDriver utility

The tool operates through the following stages:

  1. Identify target processes
    The program takes a list of process names (such as msmpeng.exe) via command-line arguments. If no list is specified, it falls back to a default set.
  2. Enumerate system processes
    To locate PIDs, the tool relies on standard Windows APIs:
    • CreateToolhelp32Snapshot
    • Process32First
    • Process32Next
  3. Generate a list of processes to kill.
  4. Load the vulnerable driver
    This is the core phase of the utility’s operation. During this step:
    • The sys driver is written to disk.
    • A SERVICE_KERNEL_DRIVER type service is created.
    • The driver is kicked off via the Service Control Manager (SCM).

GhostDriver.sys is hardcoded inside the GhostDriver executable and is a binary driver known as RentDrv2 (BadRentdrv2).

It contains the CVE-2023-44976 vulnerability, which allows it to:

  • Accept user-mode commands via DeviceIoControl.
  • Perform operations on processes from kernel mode.
  • Bypass security mechanisms, including Protected Process.

Upon execution, GhostDriver drops RentDrv2 to disk, loads it into the Windows kernel, and connects to it via the virtual device \\.\rentdrv2. The utility then issues command 0x22E010 to the driver, passing along the target process ID, and the driver terminates that process directly from kernel mode.

GhostDriver runs in a continuous loop. Every ~700 ms, it rescans for the target processes and sends out termination commands.

After the driver starts up, the utility attempts to delete the ghostdriver.sys file. To do this, it opens a file handle, uses the SetFileInformationByHandle WinAPI function to rename it to something like :GhostDriver, reopens the handle, and marks the file for deletion via FileDispositionInfo. Before wrapping up, it also tries to stop and remove the driver service, and delete the C:\rentdrv.log file where the driver writes its logs.

Example of the adversary command execution launching GhostDriver:

Current versions of Kaspersky products are resilient to these types of attacks: the utilities described in this post cannot terminate their processes.

Connection to the ClearWater ransomware

Alongside the previously described Mythic Apollo samples (C2: 77.72.85.62), backupagnt.exe loaders, and Panorama9 deployment scripts, we discovered a new ransomware strain named ClearWater across several compromised infrastructures. Written in C++ and compiled with GCC (MinGW), the sample is a 64-bit Windows executable. It features zero obfuscation; in fact, the binary wasn’t stripped of its DWARF debug information. This makes analyzing the sample significantly easier and points to either sloppiness or a lack of technical expertise on the developers’ part.

Original function names preserved within the Trojan's body

Original function names preserved within the Trojan’s body

When executed, ClearWater logs its progress in a separate console window.

The console window displayed upon launching the Trojan

The console window displayed upon launching the Trojan

File encryption

Like most ransomware strains, ClearWater is a Trojan designed to locate and encrypt the victim’s files. The Trojan executable contains a hardcoded RSA-2048 primary public key in PEM format.

For every file it processes, the ransomware generates a new 32-byte key and a 12-byte nonce – though only 8 of those 12 bytes are actually used – and encrypts the file’s contents via the ChaCha20 symmetric algorithm. The ChaCha key is then RSA-encrypted and appended to a specific data structure at the end of the file. To pull this off, the malware leverages cryptographic implementations from the open-source libsodium library.

struct
{
	uint8_t label[4];			//'M', 'Y', 'E', 'K' marker
	uint32_t rsa_encr_size;		//size of RSA-encrypted data
	uint8_t rsa_encr_data[256];	//RSA-encrypted ChaCha key
};

The Trojan processes all files except those with a .txt extension. This approach can easily break installed software, as it blindly encrypts both libraries and executables; however, it does explicitly skip the system directory during its search. Encrypted files are additionally appended with the .clear extension. The malware scans for targets on local drives as well as SMB network shares, which it maps out by using the net view command.

Additional functionality

Within every directory it processes, the Trojan drops the attackers’ demands into a file named CLEARWATER_README.txt.

Ransom note:

Ransom note:

Additionally, by modifying the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run registry key, the malware sets up a persistence mechanism that automatically opens the ransom note with notepad.exe on startup.

ClearWater is distributed inside a self-extracting archive. The extraction script runs in silent mode (GUIMode=”2β€³), escalates privileges via a UAC prompt, drops the Trojan at C:\ProgramData\ClearWater_x64.exe, and kicks it off. Once the ransomware finishes running, the SFX archive cleans up after itself and wipes the original archive (SelfDelete=”1β€³).

Alongside this script and the Trojan executable, the archive includes a BMP image. The ransomware sets this image as both the desktop wallpaper (by tweaking the HKEY_USERS\<…>\Control Panel\Desktop\Wallpaper registry key and calling SystemParametersInfoA with the SPI_SETDESKWALLPAPER parameter) and the lock screen background (by modifying the LockScreenImagePath and LockScreenImageUrl values under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\PersonalizationCSP).

Two variants of the desktop and lock screen image

Two variants of the desktop and lock screen image

To complicate system recovery after the attack, ClearWater performs several actions typical of ransomware:

  • Deletes shadow copies using the following commands:
  • Wipes the backup catalog and disables Windows Restore:
  • Removes restore points:
  • Disables the system startup recovery option:

ClearWater also features a kill_all_non_whitelisted_processes() function designed to terminate active tasks, though it doesn’t actually call it during execution. This function leverages PowerShell to look up and kill any process whose name isn’t included in a hardcoded allowlist within the Trojan’s body. It uses the following PowerShell code to do this:

Get-Process|Where-Object{$w -notcontains $_.Name.ToLower()}|Stop-Process -Force

The exclusion list contains various essential system processes and breaks down as follows:

system, idle, smss, csrss, wininit, services, lsass, winlogon, svchost, explorer, dwm, shellexperiencehost, runtimebroker, trustedinstaller, tiworker, textinputhost, taskhostw, mousocoreworker, fontdrvhost, audiodg, sihost, spoolsv, taskeng, taskhost, searchui, securityhealthservice, startmenuexperiencehost, searchindexer, backgroundtaskhost, sppsvc, wmiprvse, wudfhost, vboxservice, vboxtray, vmtoolsd, vmwaretray, vboxguest, vmsrvc, vgauthservice, vmacthlp, qemud, qemu-ga, msdtc, searchprotocolhost, wlanext, dllhost, conhost, comppkgsrv, msmpeng, mssecflt, systemsettings, securityhealthsystray, nvtray, nvvsvc, ravbg64, igfxtray, igfxem, igfxcuiservice, igfxhk, igfxext

Updated Blackout Locker

In a previously published report (link in Russian) on collaborations between several hacktivist groups, we highlighted a tool called Blackout Locker. In late January 2026, the 4BID group ran a series of attacks against organizations in Russia using an updated version of this malware. This section breaks down the new version of Blackout Locker and covers its key characteristics uncovered during our analysis.

Rust dropper

The attackers use a dropper written in Rust to distribute Blackout Locker. Depending on the specific sample, the dropper first carries out a series of staging actions. It then writes the payload executable to …\Users\[USERNAME]\AppData\Local\Microsoft\[REDACTED].dat and swaps its extension to EXE by calling the Windows command prompt:


After that, it launches the renamed executable.

Blackout Locker

The primary tool deployed in the attacks in question is an updated version of Blackout Locker.

Our analysis revealed that the key difference in this new version is the addition of a screen locker component, which it drops and executes in tandem with the ransomware’s main background payload.

During the initial phase, the screen locker file is created under the following paths:


To launch the screen locker, several tasks are created:


The screen locker is also written to the following registry keys:


After this, two LNK files, SystemHelper.lnk and WindowsHelper.lnk, are created via PowerShell for subsequent execution:

  • The first file is placed in the %PROFILEPATH%\All users\Start menu\Programs\Startup directory:
  • The second file is placed in the %USERPROFILE%\Start menu\Programs\Startup directory:

As a result, a shortcut is created in the startup folder pointing to WindowsSystemHelper.exe located on the desktop. This ensures the screen locker appears every time the user logs in. Even if the victim enters the correct password into the locker window, it will keep popping back up; while the window itself closes after password entry, the corresponding task is never actually deleted.

Screen locker

During execution, Blackout Locker generates a file named README.txt, which the screen locker later references to pull the text displayed to the user. Some Blackout Locker samples drop a ransom note written in English:

On the lock screen, it may look like this:

Other samples deploy a ransom note in Russian:

If the program fails to read README.txt, it falls back to a hardcoded ransom message. If this fallback message is in Russian but the victim’s operating system lacks support for Cyrillic encodings, the loader’s on-screen output renders as garbled text.

Attack geography

The majority of the compromised infrastructures belong to Russian and Belarusian organizations, which aligns with the stated agenda of these hacker groups. However, for the first time, we identified victims in other countries with no relation to this agenda: Kazakhstan, the UAE, Syria, and Egypt. Within the network of a Kazakh aviation company, we detected multiple post-exploitation frameworks pointing to C2 servers at 77.72.85[.]62 and 185.221.153[.]121, traces of the Panorama9 and Tactical RMM platforms, and backupagnt.exe loaders. A similar footprint was observed in the infrastructure of an Egyptian hospital, though the familiar toolkit was augmented by the fd.aspx web shell. The remaining international victims exhibited a nearly identical combination of artifacts, with only minor variations.

While the primary targeting vector previously centered on Russia and Belarus, the threat actors now appear to be pivoting their attention toward the wider CIS region and the Middle East. This strategic shift correlates with a statement from a member of the 4BID group, who claimed that attacking Russia is no longer profitable.

Takeaways

The hacktivist groups discussed in this report are steadily expanding the geographical footprint of their campaigns, pushing beyond Russia and the wider CIS region. Alongside this expansion, we observe the growing use of ransomware and other tooling consistent with financially motivated operations, which may further influence their choice of victims.

This shift underscores the critical need for continuous threat landscape monitoring. To stay ahead of threat actors, organizations must look beyond the immediate risks facing their perimeter and proactively track emerging threats, including the tactics of groups targeting specific industry verticals or geographic regions.

Detection by Kaspersky solutions

Kaspersky solutions reliably detect the malicious activity in question at every stage of the malware lifecycle. This section outlines potential detection scenarios.
Publicly available dual-use software leaves numerous artifacts on targeted hosts, which helps Kaspersky Endpoint Detection and Response Expert trace the activity of these utilities.

For instance, network connections established with Panorama9 servers both during the initial software launch and throughout the tool’s operation trigger the panorama9_dns_activity rule. The Hunt Hub section of our TI Portal features detection rules for other event types and specific operating systems, searchable with the keyword panorama9. Similar rules exist for the other utilities described in this post: Tactical RMM, Nezha, and Dev tunnels.

GhostDriver.exe relies on an embedded vulnerable driver, which it drops onto the target host. The creation of these drivers is detected by the vuln_driver_created_by_unsigned_process rule family.

Ransomware is inherently quite noisy and so can be detected at various execution phases. The execution graph within Kaspersky Cloud Sandbox on our Threat Intelligence Portal visualizes the entire ClearWater execution chain, capturing key behaviors such as modifying the desktop wallpaper and deleting shadow copies.

ClearWater execution graph in Kaspersky Cloud Sandbox

ClearWater execution graph in Kaspersky Cloud Sandbox

Additionally, the Threat Lookup and Research Graph sections of Kaspersky Threat Intelligence Portal allow you to visualize and analyze the connections between the malicious domains and files used by the adversaries.

Visualization via Research Graph on Kaspersky Threat Intelligence Portal

Visualization via Research Graph on Kaspersky Threat Intelligence Portal

Kaspersky Threat Lookup demonstrating the connection between malicious files and the attackers' IP address

Kaspersky Threat Lookup demonstrating the connection between malicious files and the attackers’ IP address

Monitoring network traffic is another highly effective method for detecting the malicious activity described here. Kaspersky Anti Targeted Attack (KATA) with the NDR module detects the network communications of all malware samples in question utilized throughout this campaign.

For instance, upon detecting HTTP network activity characteristic of the BlackSalt backdoor, the system triggers an alert for the Backdoor.BlackSalt.HTTP.C&C rule triggering.

Examples of using the Kaspersky Anti Targeted Attack (KATA) platform with the NDR module to detect other agents described here – along with their detailed technical analysis – are available in our dedicated reports on Adaptix and Mythic detection.

Indicators of compromise

Web shells
26100db3f56880110a92a2b4742d6eaf fd.aspx
cf682a6fee80a78be578b1edd82627fa fd.aspx
2d5533fb65ebb50a5a5fd53e62d73b9a fd.aspx
fe04d230db612ea24af3826fda667131 fd.aspx
Scripts
2db94ee3ec69988588702bd77999a5d4 any_local.ps1
f88d2b5c3b885ad5a9c1c44551bccc60 main.ps1
1e1edf879b2dc6c9892a22bfa5985db1 main.ps1
78250fa890220821e2b91e31b965de59 main.ps1
f2af797ac45b9f578c53cc49e5797397 auto_dev.ps1
0c32bfdf83ecebe3a1399d261dc8ff57 auto_dev_test.ps1
e14cc9a959bbe16c48b8dff063b311f3 auto_dev_test_multimple_task.ps1
36b3be503c6e34613ff50cb28e0f3ddb auto_dev_test_multimple_task.ps1
c12ebe625737ed0908b045e811f14ecd tun.ps1, auto_dev_test_multimple_task.ps1
1c0924f5711a24821921de5ad822213b grant.ps1
d78adab5e16c26d4cd14fe38f77e29e6 pan.ps1, pam.ps1
6cf548445c39aff844be96d73c89e376 test.ps1
911a21aa999c324dc960d3498eec528e radiant.ps1
68e310de44c3165ffffa25bc495d6fc5
4f41a22b3e7469fb6b45a42d71ec7087
80e5bde401d6b0ca96015ae9cfeb6535
1c82a94c362a9e98a66ae57d6ff37900
fa04aeedc0d2f5bb6ed357fdae1c1435
AdaptixC2
555a6722436d7cf7de396e0c57d32a27
b974141ff9ad1efb60dd9e16977266ca
7da855b2fd9b52f9088e64d656164637
d08056c2ac28933d6843658c2c8c574f
038cab0c60c53cf12f048272014024c0
c183033d86d2e052b8eb0deb2136ab29
bc0ebf67986eea803b4c9633ed3a4bb5
18618f4b468ba4e64c2e1072a6da2134
1742a9fa35e253614b76ac0f687ba02e
c7eb6da3aa216816079a1b785097552a
3ee38b944e5c83922f99641846f7db0c
d8ff7f417d56fa2a3baf3c8933013a25
1ff222457f5e0e32adfa8341f260dde7
ede8ce887dd9ab7add0f0fc872d51369
1344e6bc51cea35befb4adff7a25899b
2a09162d72aa416e18bab46070043a13
841b7d3863b49f62d4faa9949ff5df38
1bd1ca848b15530e39792b4fe6f31367
Mythic Apollo
b36968b98046d1b033d84f292e7ca1cb
663a479d6d24c767f1d3229a0a91554b
54a308f734095d54ae0e1c86c849a2d8
3137958eb830186826d486afd9222aee
1d09499cb2d7d70df903b60602a58887
d74262f968dc3f378c4021a89d16a292
3d9cbc944f9a9e127550ffb4e8394965
bcd3859f4ddd72c4690d76c3b4ef8955
3a9b0875fc692944c180b165a83a0d17
c558e6a9d0a697c757aa6d7782e269c9
61647db645f7cc221046999ef1dbe1d1
02493e1cb684be6a1a1fc6334a56c516
a3dba01c76571adc0797801ff30f2b90
3f4fbba101b209b00e70787fd5bab819
cd0c5b9e4e47df4231d02ed87ff49f26
b8a13e808b5b5f1836d3e559755139d0
60f8b115aec8a13b0069efc84fc645f5
da55b5612a80ef20ec75b68151e7ff4b
7d35b4961914ad83a57f8832d8e870d8
334abbdc99d359aab2ea371dd4eda5f2
389a1bbdbf5c91bd1c179227f5ae0923
87d48fbccb4aaee95222e215ecb7ebec
76c819185e3c8b8557a2c3986ab80a7c
6d19c8eea11d50c01d20f18382a964d1
Other C2 frameworks
8db0adf8fd6dc6195d7ae55e37e49f97
08f3a14a2337eb9936c38f5159be007c
717ab7624c192f6f8dd38994116c28dc
d1c51b92939aa168f0951a8368841373
5398b7eaa94f0ee570b1c5642b559047
d65a79ea9257637c77cab6e087468912
008cd423ca45134d3343f66cced1d104
9741672506f26813c71839aaa6aa3882
06bed0a0906e52c764b3b7016d6a4428
upd.exe (SFX archive)
08c069f133ac27cbc02a0ed79e4e87ba upd.exe
a36082c998391a3ebaf05ba4f834172c backupagnt.exe
9810ea6752112b3569ddc096e1a72e1d sliver
update1.exe (SFX archive)
10824d14c814524155f2b529cf5fee43 update1.exe
a36082c998391a3ebaf05ba4f834172c backupagnt.exe
9810ea6752112b3569ddc096e1a72e1d sliver
akolo.exe (SFX archive)
242038139842ec79ec1044c64eb0804a akolo.exe
53ba13cc6066adfd67f8098c0a5b8dde backupagnt.exe
9810ea6752112b3569ddc096e1a72e1d sliver
update.exe (SFX archive)
84bb66a982710c5536143a07d84e8749 update.exe
a36082c998391a3ebaf05ba4f834172c backupagnt.exe
9810ea6752112b3569ddc096e1a72e1d sliver
akolo.exe (SFX archive)
fa3c222f6b53d6a2e35a54600f6aa011 akolo.exe
0b1870d57221eec6f3bbef648e71a724 backupagnt.exe
5e81f72614db42615489266be11b1d09 sliver
akolo.exe (SFX archive)
4c8a0531653b5398a35c6b1b80ff1350 akolo.exe
83f66862c0cc40da20236fd6b47138fd backupagnt.exe
5e81f72614db42615489266be11b1d09 sliver
[REDACTED].exe (SFX archive)
56be07e46fd452315008ed246ebbf52b [REDACTED].exe
579e8bbd6a5bcca89b5acd6fb5db32db backupagnt.exe
dd8fea244afc8223b961f1d9d6ac8c5d Apollo
WindowsServiceHelper.exe (SFX archive)
09d0517a1f69feff8186655ae3b567e0 WindowsServiceHelper.exe
62123c39477389d500e74e82782adea5 BlackSalt Backdoor
winexe.exe (SFX archive)
6d365de5c5a13006b7cadd6bc6876e84 winexe.exe
2f40bcee90abed0898e92521da17e52d BlackSalt Backdoor
WindowsServiceHelper.exe (SFX archive)
6dfef58ef68fb7965a23da8be3141af9 WindowsServiceHelper.exe
56d1de3159adbfda20aca593c99901f9 BlackSalt Backdoor
[REDACTED].exe (SFX archive)
96dbdc2651d829bf9ba35674dd4bfcae [REDACTED].exe
129225b3e93c17f131bcc2a982ffb09a BlackSalt Backdoor
test.exe (SFX archive)
9f37fff7e5d22f83fc1c0872ad5332f9 test.exe
cf54f6cbdb4dbf1ce6fc2e5be4ca3b20 BlackSalt Backdoor
1.exe (SFX archive)
e99efd77392e2b4fe4d9bf5728a12b98 1.exe
129225b3e93c17f131bcc2a982ffb09a BlackSalt Backdoor
WindowsServiceHelper.exe (SFX archive)
f2dc794bf93887e281ad89209493065a WindowsServiceHelper.exe
2f40bcee90abed0898e92521da17e52d BlackSalt Backdoor
EDR killers
d13997b1716e4c82ab454285202eafdc killer.exe, 2.exe
ecb57d8793514aa02314417265b1853f kil.exe, 3.exe
3b974ff986445e5944c51179d19bd6be GhostDriver.exe

Network indicators
212.46.12[.]182
185.221.153[.]121
77.72.85[.]62
45.150.109[.]2
130.49.155[.]112
45.112.194[.]82
138.226.236[.]52
85.137.253[.]186

❌
❌