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.
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.
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
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 фнс.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
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
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
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
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 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:
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:
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
XOR decryption with a hardcoded key.Most loaders used the hardcoded key RSL_STEG_2025_KEY.
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
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
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
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
The values between the “|” delimiters are written in reverse order. By restoring the correct character sequence, we obtain the following string:
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
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:
Using the InternetReadFile function with the User-Agent PythonDownloader
The archive was saved to the path %LOCALAPPDATA%\appclient\111.zip.
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:
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:
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
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:
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:
Windows registry: It adds "<path_to_pythonw.exe>" -m appclient to the value HKCU:\Software\Microsoft\Windows\CurrentVersion\Run:AppClient, e.g:
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)
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:
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
– 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:
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:
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:
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:
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
When executed, the SFX archive ran the following 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 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
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
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.
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
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 фнс.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
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
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
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
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 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:
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:
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
XOR decryption with a hardcoded key.Most loaders used the hardcoded key RSL_STEG_2025_KEY.
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
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
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
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
The values between the “|” delimiters are written in reverse order. By restoring the correct character sequence, we obtain the following string:
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
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:
Using the InternetReadFile function with the User-Agent PythonDownloader
The archive was saved to the path %LOCALAPPDATA%\appclient\111.zip.
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:
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:
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
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:
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:
Windows registry: It adds "<path_to_pythonw.exe>" -m appclient to the value HKCU:\Software\Microsoft\Windows\CurrentVersion\Run:AppClient, e.g:
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)
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:
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
– 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:
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:
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:
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:
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
When executed, the SFX archive ran the following 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 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
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
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.
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
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
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:
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
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.
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:
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
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.
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
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
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:
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
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.
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:
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
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.
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:
The special malware command clipper:set:[ADDR1,...] with the attackers’ crypto‑wallets addresses passed as arguments launches the clipper injection thread.
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.
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.
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.
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:
The special malware command clipper:set:[ADDR1,...] with the attackers’ crypto‑wallets addresses passed as arguments launches the clipper injection thread.
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.
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.
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.
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)
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
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)
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:
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.
Check permissions. Pay attention to the permissions that applications request, especially those related to accessibility and installation of third-party packages.
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.*
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)
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
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)
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:
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.
Check permissions. Pay attention to the permissions that applications request, especially those related to accessibility and installation of third-party packages.
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.*
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.
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.
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
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
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
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:
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
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
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 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 loader also ensures NetSupport persistence by adding it to startup using the following three methods:
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
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
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)
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:
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:
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:
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 95db93454ec1d581311c832122d21b20, the NetSupport loader described here
Decoy documents in both campaigns look identical.
Decoy document 5d840b741d1061d51d9786f8009c37038c395c129bee608616740141f3b202bb from the campaign reported by Group-IB
Decoy document 106911ba54f7e5e609c702504e69c89a used in the campaign described here
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.
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
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
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
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:
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
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
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 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 loader also ensures NetSupport persistence by adding it to startup using the following three methods:
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
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
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)
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:
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:
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:
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 95db93454ec1d581311c832122d21b20, the NetSupport loader described here
Decoy documents in both campaigns look identical.
Decoy document 5d840b741d1061d51d9786f8009c37038c395c129bee608616740141f3b202bb from the campaign reported by Group-IB
Decoy document 106911ba54f7e5e609c702504e69c89a used in the campaign described here
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.
In early 2025, security researchers uncovered a new malware family named Webrat. Initially, the Trojan targeted regular users by disguising itself as cheats for popular games like Rust, Counter-Strike, and Roblox, or as cracked software. In September, the attackers decided to widen their net: alongside gamers and users of pirated software, they are now targeting inexperienced professionals and students in the information security field.
Distribution and the malicious sample
In October, we uncovered a campaign that had been distributing Webrat via GitHub repositories since at least September. To lure in victims, the attackers leveraged vulnerabilities frequently mentioned in security advisories and industry news. Specifically, they disguised their malware as exploits for the following vulnerabilities with high CVSSv3 scores:
In the Webrat campaign, the attackers bait their traps with both vulnerabilities lacking a working exploit and those which already have one. To build trust, they carefully prepared the repositories, incorporating detailed vulnerability information into the descriptions. The information is presented in the form of structured sections, which include:
Overview with general information about the vulnerability and its potential consequences
Specifications of systems susceptible to the exploit
Guide for downloading and installing the exploit
Guide for using the exploit
Steps to mitigate the risks associated with the vulnerability
Contents of the repository
In all the repositories we investigated, the descriptions share a similar structure, characteristic of AI-generated vulnerability reports, and offer nearly identical risk mitigation advice, with only minor variations in wording. This strongly suggests that the text was machine-generated.
The Download Exploit ZIP link in the Download & Install section leads to a password-protected archive hosted in the same repository. The password is hidden within the name of a file inside the archive.
The archive downloaded from the repository includes four files:
pass – 8511: an empty file, whose name contains the password for the archive.
payload.dll: a decoy, which is a corrupted PE file. It contains no useful information and performs no actions, serving only to divert attention from the primary malicious file.
rasmanesc.exe (note: file names may vary): the primary malicious file (MD5 61b1fc6ab327e6d3ff5fd3e82b430315), which performs the following actions:
Escalate its privileges to the administrator level (T1134.002).
Disable Windows Defender (T1562.001) to avoid detection.
Fetch from a hardcoded URL (ezc5510min.temp[.]swtest[.]ru in our example) a sample of the Webrat family and execute it (T1608.001).
start_exp.bat: a file containing a single command: start rasmanesc.exe, which further increases the likelihood of the user executing the primary malicious file.
The execution flow and capabilities of rasmanesc.exe
Webrat is a backdoor that allows the attackers to control the infected system. Furthermore, it can steal data from cryptocurrency wallets, Telegram, Discord and Steam accounts, while also performing spyware functions such as screen recording, surveillance via a webcam and microphone, and keylogging. The version of Webrat discovered in this campaign is no different from those documented previously.
Campaign objectives
Previously, Webrat spread alongside game cheats, software cracks, and patches for legitimate applications. In this campaign, however, the Trojan disguises itself as exploits and PoCs. This suggests that the threat actor is attempting to infect information security specialists and other users interested in this topic. It bears mentioning that any competent security professional analyzes exploits and other malware within a controlled, isolated environment, which has no access to sensitive data, physical webcams, or microphones. Furthermore, an experienced researcher would easily recognize Webrat, as it’s well-documented and the current version is no different from previous ones. Therefore, we believe the bait is aimed at students and inexperienced security professionals.
Conclusion
The threat actor behind Webrat is now disguising the backdoor not only as game cheats and cracked software, but also as exploits and PoCs. This indicates they are targeting researchers who frequently rely on open sources to find and analyze code related to new vulnerabilities.
However, Webrat itself has not changed significantly from past campaigns. These attacks clearly target users who would run the “exploit” directly on their machines — bypassing basic safety protocols. This serves as a reminder that cybersecurity professionals, especially inexperienced researchers and students, must remain vigilant when handling exploits and any potentially malicious files. To prevent potential damage to work and personal devices containing sensitive information, we recommend analyzing these exploits and files within isolated environments like virtual machines or sandboxes.
We also recommend exercising general caution when working with code from open sources, always using reliable security solutions, and never adding software to exclusions without a justified reason.
Kaspersky solutions effectively detect this threat with the following verdicts:
In early 2025, security researchers uncovered a new malware family named Webrat. Initially, the Trojan targeted regular users by disguising itself as cheats for popular games like Rust, Counter-Strike, and Roblox, or as cracked software. In September, the attackers decided to widen their net: alongside gamers and users of pirated software, they are now targeting inexperienced professionals and students in the information security field.
Distribution and the malicious sample
In October, we uncovered a campaign that had been distributing Webrat via GitHub repositories since at least September. To lure in victims, the attackers leveraged vulnerabilities frequently mentioned in security advisories and industry news. Specifically, they disguised their malware as exploits for the following vulnerabilities with high CVSSv3 scores:
In the Webrat campaign, the attackers bait their traps with both vulnerabilities lacking a working exploit and those which already have one. To build trust, they carefully prepared the repositories, incorporating detailed vulnerability information into the descriptions. The information is presented in the form of structured sections, which include:
Overview with general information about the vulnerability and its potential consequences
Specifications of systems susceptible to the exploit
Guide for downloading and installing the exploit
Guide for using the exploit
Steps to mitigate the risks associated with the vulnerability
Contents of the repository
In all the repositories we investigated, the descriptions share a similar structure, characteristic of AI-generated vulnerability reports, and offer nearly identical risk mitigation advice, with only minor variations in wording. This strongly suggests that the text was machine-generated.
The Download Exploit ZIP link in the Download & Install section leads to a password-protected archive hosted in the same repository. The password is hidden within the name of a file inside the archive.
The archive downloaded from the repository includes four files:
pass – 8511: an empty file, whose name contains the password for the archive.
payload.dll: a decoy, which is a corrupted PE file. It contains no useful information and performs no actions, serving only to divert attention from the primary malicious file.
rasmanesc.exe (note: file names may vary): the primary malicious file (MD5 61b1fc6ab327e6d3ff5fd3e82b430315), which performs the following actions:
Escalate its privileges to the administrator level (T1134.002).
Disable Windows Defender (T1562.001) to avoid detection.
Fetch from a hardcoded URL (ezc5510min.temp[.]swtest[.]ru in our example) a sample of the Webrat family and execute it (T1608.001).
start_exp.bat: a file containing a single command: start rasmanesc.exe, which further increases the likelihood of the user executing the primary malicious file.
The execution flow and capabilities of rasmanesc.exe
Webrat is a backdoor that allows the attackers to control the infected system. Furthermore, it can steal data from cryptocurrency wallets, Telegram, Discord and Steam accounts, while also performing spyware functions such as screen recording, surveillance via a webcam and microphone, and keylogging. The version of Webrat discovered in this campaign is no different from those documented previously.
Campaign objectives
Previously, Webrat spread alongside game cheats, software cracks, and patches for legitimate applications. In this campaign, however, the Trojan disguises itself as exploits and PoCs. This suggests that the threat actor is attempting to infect information security specialists and other users interested in this topic. It bears mentioning that any competent security professional analyzes exploits and other malware within a controlled, isolated environment, which has no access to sensitive data, physical webcams, or microphones. Furthermore, an experienced researcher would easily recognize Webrat, as it’s well-documented and the current version is no different from previous ones. Therefore, we believe the bait is aimed at students and inexperienced security professionals.
Conclusion
The threat actor behind Webrat is now disguising the backdoor not only as game cheats and cracked software, but also as exploits and PoCs. This indicates they are targeting researchers who frequently rely on open sources to find and analyze code related to new vulnerabilities.
However, Webrat itself has not changed significantly from past campaigns. These attacks clearly target users who would run the “exploit” directly on their machines — bypassing basic safety protocols. This serves as a reminder that cybersecurity professionals, especially inexperienced researchers and students, must remain vigilant when handling exploits and any potentially malicious files. To prevent potential damage to work and personal devices containing sensitive information, we recommend analyzing these exploits and files within isolated environments like virtual machines or sandboxes.
We also recommend exercising general caution when working with code from open sources, always using reliable security solutions, and never adding software to exclusions without a justified reason.
Kaspersky solutions effectively detect this threat with the following verdicts:
Login
