Muhstik Malware Targets Message Queuing Services Applications

Summary: This blog post discusses a new campaign of Muhstik malware targeting the Apache RocketMQ platform, exploring how the attackers exploit vulnerabilities in RocketMQ and analyzing the impact of the malware on compromised instances.

Threat Actor: Muhstik | Muhstik
Victim: Aqua Nautilus | Aqua Nautilus

Key Point :

• A new campaign of Muhstik malware has been discovered, targeting the Apache RocketMQ platform.
• The attackers exploit a known vulnerability in RocketMQ to download the Muhstik malware onto compromised instances.
• The blog post explores the impact of the malware on compromised instances and analyzes the number of vulnerable RocketMQ instances worldwide.
• RocketMQ is a distributed messaging and streaming platform with low latency, high performance, and reliability.
• The platform was developed by Alibaba and later donated to the Apache Software Foundation.
• RocketMQ is considered a cloud-native messaging and streaming platform.

Aqua Nautilus discovered a new campaign of Muhstik malware targeting message queuing services applications, specifically the Apache RocketMQ platform. Our investigation revealed that the attackers downloaded the known malware Muhstik onto the compromised instances by exploiting a known vulnerability in the platform. In this blog, we will explore how the attackers exploit the existing vulnerability in RocketMQ, examine how the Muhstik malware affects the compromised instances, and analyze the number of RocketMQ instances worldwide vulnerable to this type of attack. 

What is RocketMQ? 

RocketMQ is a distributed messaging and streaming platform with low latency, high performance, and reliability, trillion-level capacity, and flexible scalability. The platform was first developed as open source by Alibaba, which then decided to donate the code to the Apache Software Foundation. The platform has evolved over the years and is nowadays considered a cloud-native messaging and streaming platform, making it simple to build event-driven applications. Since its inception, Apache RocketMQ has been widely adopted by enterprise developers and cloud vendors due to its simple architecture, rich business functionality, and extreme scalability. 

RocketMQ consists of several key components that work together to provide messaging and streaming capabilities. The main components are Producers, Consumers, NameServers, and Brokers. 

Producer: A producer serves as a data source that optimizes, writes, and publishes messages to one or more topics. Producers load balance data among brokers through MessageQueue. They support fail-fast and retries during message sending. 

Consumer: Consumers are client applications that consume messages from RocketMQ brokers. They subscribe to one or more topics and receive messages sent to those topics by producers.  

Name Server: The NameServer is a simple Topic routing registry that supports dynamic registration and discovery of Topics and Brokers. 

Broker: The Broker is mainly responsible for message storage, delivery, and query, and ensuring high availability of services. 

CVE-2023-33246: The Apache RocketMQ remote code execution vulnerability 

In 2023, a remote code execution vulnerability was discovered for RocketMQ versions 5.1.0 and below. RocketMQ elements, such as NameServer, Broker, and Controller, are accessible from the extranet without needing permission checks. This creates an opportunity for attackers to exploit the flaw. By leveraging the update configuration function, attackers can execute commands within the system, operating under the same user privileges as those utilized by RocketMQ. 

As noted earlier, the broker is responsible for message storage, delivery, and high availability. Upon initialization, the Broker node registers itself with the NameServer node. 

Originally, the broker was never intended to be exposed to the internet, and its inherently insecure design includes a range of administrative functions that allow, among other things, the modification of the broker configuration file and its update without any authentication. 

The Muhstik campaign  

We’ve detected dozens of attacks on our honeypots aimed at our vulnerable RocketMQ platform. Upon exploiting the vulnerability, the attackers proceeded to download the Muhstik malware, as previously explained. Muhstik is a well-known threat targeting IoT devices and Linux-based servers, notorious for its ability to infect devices and utilize them for cryptocurrency mining and launching Distributed Denial of Service (DDoS) attacks.  

According to prior research, it has been active since 2017. Muhstik malware belongs to the Kaiten family, which also includes the Tsunami malware. It maintains the DDoS functionality of this family by connecting to a server and accepting commands via a specified IRC channel. Various reports suggest that Muhstik malware bears similarities to the Mirai code. During the attack, we observed some resemblances to attacks associated with Mirai malware, which is not surprising since the Mirai malware source code was released by a hacker in 2016. Following the availability of the code, numerous cybercriminals exploited the malware for their own purposes. 

As depicted in Figure 1, the attack flow is the same in all the attacks that were implemented against our honeypot. After gaining the ability to upload the malicious payload by exploiting the RocketMQ vulnerability, the attacker is able to execute their malicious code, which downloads the Muhstik malware. 

Next, we will walk you through the different phases that the attack includes. 

Initial Access 

We created a vulnerable RocketMQ (CVE-2023-33246) service and exposed port 10911/tcp in one of our honeypots, it was scanned and detected by the attackers, who verified that this is a vulnerable RocketMQ version by inspecting the broker.log file. 

Once the vulnerability is detected the attackers initiate a request to update the RocketMQ broker configuration file: 

• filterServerNums – the value is updated to be 1. The value must be greater than 0 to trigger the callShell method, which is responsible for executing system commands and necessary to execute the attacker’s malicious command. 
• rocketmqHome – this is the default user main directory. The payload is saved to this variable, which can later be called and executed. 

As can be seen, the configuration update request is initiated from the IP address of the attacker’s server. 

Then, the broker configuration file is updated with the malicious “rocketmqHome” variable. It is important to note that at this point, the malicious command is not executed but rather written into the configuration file, replacing the current configuration, so it can be executed later on. 

At this point, the attacker can remotely execute code on our instance by exploiting the vulnerability described above.

Execution 

In Figure 4, we can see that the FilterServerManager class, which manages Filters, executes the malicious shell command using the CallShell method. 

As the curl command is available on our machine, the second condition in the or statement is executed. This execution downloads the 3sh shell script. 

As seen in Figure 5 above, the shell script contains the download of several binaries from the same remote server using the curl command. After each binary is downloaded, it is provided with execution permissions and changed to be available to the owner only, with no permissions for any other users (using the commands chmod +x and chmod 700), and then the file is executed. 

We can observe that the attackers provide all the necessary conditions to ensure the attack will be executed. First, they check which command is available on the machine in order to perform the download (wget or curl) and based on this, they build a suitable shell script that will download the binaries with the available command. Moreover, the shell script also provides the download of the Muhstik malware for each computer architecture to ensure the attack could be performed on any environment without interruption. 

Our vulnerable RocketMQ platform architecture is x86_64. The malicious Muhstik malware – pty3 has the same architecture and is designed to run on our honeypot. 

According to VirusTotal, the file was found malicious by 39 vendors and classified as Muhstik malware by ClamAV. 

Persistence 

In our attack, like prior attacks in which attackers were using the Muhstik malware, we can see several persistence techniques. 

As we saw earlier, the malicious binary file pty3, recognized as the Muhstik malware, executed on our machine. As a first step, the binary spawned the process f0sfwjsfj51tc5h, which is responsible for copying the Muhstik malware to the following directories: 

• /dev/shm/pty3 
• /var/tmp/pty3 
• /run/lock/pty3 
• /run/pty3 

Tthe attackers then edited the inittab file, which is a configuration file that defines the behavior of the init process. The attackers used therespawncommand to instruct the init process to automatically restart the pty3 process in each directory it was copied to, providing the attackers with persistence by ensuring their access to the machine. 

Defense Evasion 

According to our signatures, it was revealed that the Muhstik malware, downloaded as pty3, is detected as packed software. This means the file signature was changed in an attempt to avoid signature-based detection. 

As mentioned above, the file is saved with the name pty3. pty is a known mechanism in Linux that facilitates communication between processes. The attackers provided the file with a seemingly legitimate name, which is supposed to evade detection. 

Furthermore, the Muhstik malware was detected as fileless malware, as mentioned above the pty3 malware was written to the directories listed above (/dev/shm, /var/tmp, /run/lock, and /run). These often involve temporary files or in-memory objects. This means it performs its operation without leaving traces of files on the file system of the compromised machine. This technique allows the malware to execute code directly from memory. Malware that operates from memory or uses temporary directories may evade detection by security tools like volume-based scanning and traditional antivirus scanners, as it doesn’t leave traces on the file system. This technique allows the malware to execute code directly from memory, bypassing security measures that could detect and block it. 

Discovery  

The attackers queried the machine for details using the uname command to retrieve system information. This information is later used by the attackers and transferred through the IRC protocol.  

Moreover, the Muhstik malware checks if the network tools strace and tcpdump are available on the machine it is running on. It uses the pidof command to check if there is a running process of one of these tools and sends the output to /dev/null, which discards the received output. Checking for the presence of network monitoring tools allows the attackers to gather information about the system’s current processes and potentially its security posture. 

Lateral Movement 

The malware has the ability to perform scanning for SSH services and also indicates attempts to authenticate and potentially gain access to other machines over SSH. Scanning for SSH services and attempting to log in with credentials are common methods that allow attackers to enter, move laterally across a network, and gain control over remote systems. 

Command and Control 

After the Muhstik malware executed on our machine, it performs a DNS request towards a malicious domain – “p.de-zahlung[.]eu”, which resolved to the IP address 51.79.19.53. The domain was found malicious according to VirusTotal, and the community identified that the domain has been in use in other attacks found to be related to the Muhstik malware. 

According to the traffic, we can see that this server is used as a command-and-control server, where the attacker maintains communication with our compromised machine over the IRC protocol.  

In Figure 8 above, we can see the communication between the client and the IRC server: 

1. The client connects to the IRC server, setting their nickname and user information. 
2. Then, the client and IRC server exchange PING and PONG messages between each other. The client sends PING requests for a response from the server to ensure the connection is still active, and PONG is the response from the server. 
3. Next, we observe a sequence of actions and responses between the client and server in an IRC session. A private message is sent (PRIVMSG) querying the version of the user’s client. Then, there are messages that are typically sent when a user connects to provide information about the server and session, and at the end the user joining to the channel.  
4. The following commands are used for managing user visibility, joining channels, and retrieving information about the user in this IRC session. It makes the user visible (MODE) and shows their hostname by removing invisible and hostname-hiding modes. It joins to a certain channel (#ex86) with a password (8974), and queries detailed information about the user. 
5. Now, the user joins to the specified channel, and the server informs about a topic in the channel and specifies the timestamp of when it was set. Then, another user (T) sends an encrypted message (PRIVMSG) to the channel. It is common for attackers to use this method to send their malicious command via a private message. Aqua Tracee eBPF based tool recorded the encrypted command in clear text – ‘/bin/dash: sh -c export PATH=/bin:/sbin:/usr/bin:/usr/local/bin:/usr/sbin;killall kdevtmpfsi kinsing cnrig kswapd0 trace xr tsm; kill $(ps aux | grep ‘cnrig|kinsing|kdevtmpfsi’ | awk ‘{print $2}’)’. This command is used to clean-up malicious or unwanted processes on the system. At first it sets the PATH environment variable to ensure necessary executables are available, then terminates specific processes by name using killall, and further ensures that any remaining processes matching certain patterns are also terminated. 
6. Finally, it sends a notice to the user (T), which is empty, therefore an error message is sent from the server, and then the client and server exchange PING and PONG messages – to check if the client is still connected and confirming the connection is active.  

Impact 

Throughout the campaign of Muhstik malware, we examined how it tries to evade security tools and stay under the radar while spreading over the network and attacking compromised machines. During our investigation, we observed that the malware has the ability to perform different types of flooding attacks. The attackers can leverage this ability to overwhelm network resources and cause denial-of-service conditions. Moreover, in previous campaigns, cryptomining activity was detected after the execution of the Muhstik malware. These objectives go hand in hand, as the attackers strive to spread and infect more machines, which helps them in their mission to mine more cryptocurrency using the electrical power of the compromised machines. 

MITRE Framework

RocketMQ vulnerability in the wild 

RocketMQ is a message queuing service application, by incorporating RocketMQ into the SDLC, cloud-native applications benefit from a robust messaging infrastructure that supports efficient development, deployment, and operations, ultimately leading to more resilient and scalable systems.  

After analyzing the attack and understanding how it can impact many organizations, we were interested in knowing how many instances around the world are vulnerable to CVE-2023-33246. Using the Shodan engine, we learned that there are 5,216 vulnerable instances of RocketMQ.   

This data indicates how frequent this issue is, where a new vulnerability is published, yet there are still instances that were not updated and remain exposed to attacks by malicious threat actors.  

Secure your cloud native environment 

As the risk of your environment being exposed to new vulnerabilities or certain misconfigurations caused by human mistakes continues to grow, it is important to secure your cloud-native environment and provide it with comprehensive protection.  

Aqua’s Cloud Native Application Platform (CNAPP) offers that kind of solution to protect your cloud-based environment. It allows you to scan your environment, including your code, container images and cloud workloads, and detect threats like known vulnerabilities, concealed malware, hidden secrets, configuration errors, and open source license issues.  

As explained earlier, the attack was initiated against our RocketMQ honeypot, which was built with a certain vulnerability. Aqua’s Platform, which includes Aqua Trivy’s premium version, is able to scan the container image and detect the Apache RocketMQ vulnerability CVE-2023-33246 in our instance, among other threats that it contains. 

Aqua’s platform also provides runtime protection and can detect suspicious behaviors in our workload as we observe in our attack. 

How to protect your organization? 

In this blog we saw how a certain vulnerability in the RocketMQ instances allows attackers to abuse the RocketMQ platform and execute the Muhstik malware. This grants the attackers persistency on the compromised machine and the ability to hijack resources to achieve their desired impact. Moreover, we demonstrated how widespread this attack can be. Using the Shodan engine, we revealed that there are still vulnerable instances.  

The number of vulnerable instances around the world emphasizes how important it is to strengthen your security measures and be aware of any security updates the distributors publish.  

In the meantime, we suggest you follow the following guidelines:

Secure your environment – As mentioned above, misconfigured and vulnerable instances can be exploited by attackers looking to implement their attacks. The first precaution is to adhere to security guidelines in your organization, follow security updates and distributor notes about new releases, and keep your organization up to date. 

Scan your environment – Nowadays attackers invest all their resources to implement their attacks, and the number of attacks continues to grow. It is important to secure your organization with the proper security measures. It is recommended to use runtime detection and response solutions which can detect suspicious behavior on your organization’s instances and alert you about it. 

Educate your employees – It is important to harden the security in your organization and stay updated with any security alerts, but the most important thing you can do for your organization is to educate your employees and make them aware of existing threats. When the entire organization is harnessed for the cause, it will be more efficient to apply the security guidelines. 

Source: https://www.aquasec.com/blog/muhstik-malware-targets-message-queuing-services-applications

---

“An interesting youtube video that may be related to the article above”