{
	"id": "88479334-6e2c-422e-a2f8-3142a3f29b88",
	"created_at": "2026-04-06T00:06:14.564886Z",
	"updated_at": "2026-04-10T03:34:59.743582Z",
	"deleted_at": null,
	"sha1_hash": "976b441529e35b3c13265ccde58de1c8dc854dd8",
	"title": "Muhstik Malware Targets Message Queuing Services Applications",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2880005,
	"plain_text": "Muhstik Malware Targets Message Queuing Services Applications\r\nBy Nitzan Yaakov Nitzan was a Security Data Analyst at Aqua Nautilus research team.\r\nPublished: 2024-06-04 · Archived: 2026-04-05 20:04:50 UTC\r\nAqua Nautilus discovered a new campaign of Muhstik malware targeting message queuing services applications,\r\nspecifically the Apache RocketMQ platform. Our investigation revealed that the attackers downloaded the known\r\nmalware Muhstik onto the compromised instances by exploiting a known vulnerability in the platform. In this\r\nblog, we will explore how the attackers exploit the existing vulnerability in RocketMQ, examine how the Muhstik\r\nmalware affects the compromised instances, and analyze the number of RocketMQ instances worldwide\r\nvulnerable to this type of attack. \r\nWhat is RocketMQ? \r\nRocketMQ is a distributed messaging and streaming platform with low latency, high performance, and reliability,\r\ntrillion-level capacity, and flexible scalability. The platform was first developed as open source by Alibaba, which\r\nthen decided to donate the code to the Apache Software Foundation. The platform has evolved over the years and\r\nis nowadays considered a cloud-native messaging and streaming platform, making it simple to build event-driven\r\napplications. Since its inception, Apache RocketMQ has been widely adopted by enterprise developers and cloud\r\nvendors due to its simple architecture, rich business functionality, and extreme scalability. \r\nRocketMQ consists of several key components that work together to provide messaging and streaming\r\ncapabilities. The main components are Producers, Consumers, NameServers, and Brokers. \r\nProducer: A producer serves as a data source that optimizes, writes, and publishes messages to one or more\r\ntopics. Producers load balance data among brokers through MessageQueue. They support fail-fast and retries\r\nduring message sending. \r\nConsumer: Consumers are client applications that consume messages from RocketMQ brokers. They subscribe to\r\none or more topics and receive messages sent to those topics by producers.  \r\nName Server: The NameServer is a simple Topic routing registry that supports dynamic registration and\r\ndiscovery of Topics and Brokers. \r\nBroker: The Broker is mainly responsible for message storage, delivery, and query, and ensuring high availability\r\nof services. \r\nCVE-2023-33246: The Apache RocketMQ remote code execution vulnerability \r\nIn 2023, a remote code execution vulnerability was discovered for RocketMQ versions 5.1.0 and below.\r\nRocketMQ elements, such as NameServer, Broker, and Controller, are accessible from the extranet without\r\nneeding permission checks. This creates an opportunity for attackers to exploit the flaw. By leveraging the update\r\nhttps://www.aquasec.com/blog/muhstik-malware-targets-message-queuing-services-applications/\r\nPage 1 of 16\n\nconfiguration function, attackers can execute commands within the system, operating under the same user\r\nprivileges as those utilized by RocketMQ. \r\nAs noted earlier, the broker is responsible for message storage, delivery, and high availability. Upon initialization,\r\nthe Broker node registers itself with the NameServer node. \r\nOriginally, the broker was never intended to be exposed to the internet, and its inherently insecure design includes\r\na range of administrative functions that allow, among other things, the modification of the broker configuration\r\nfile and its update without any authentication. \r\nThe Muhstik campaign  \r\nWe’ve detected dozens of attacks on our honeypots aimed at our vulnerable RocketMQ platform. Upon exploiting\r\nthe vulnerability, the attackers proceeded to download the Muhstik malware, as previously explained. Muhstik is a\r\nwell-known threat targeting IoT devices and Linux-based servers, notorious for its ability to infect devices and\r\nutilize them for cryptocurrency mining and launching Distributed Denial of Service (DDoS) attacks.  \r\nAccording to prior research, it has been active since 2017. Muhstik malware belongs to the Kaiten family, which\r\nalso includes the Tsunami malware. It maintains the DDoS functionality of this family by connecting to a server\r\nand accepting commands via a specified IRC channel. Various reports suggest that Muhstik malware bears\r\nsimilarities to the Mirai code. During the attack, we observed some resemblances to attacks associated with Mirai\r\nmalware, which is not surprising since the Mirai malware source code was released by a hacker in 2016.\r\nFollowing the availability of the code, numerous cybercriminals exploited the malware for their own purposes. \r\nhttps://www.aquasec.com/blog/muhstik-malware-targets-message-queuing-services-applications/\r\nPage 2 of 16\n\nFigure 1: Attack Flow\r\nAs depicted in Figure 1, the attack flow is the same in all the attacks that were implemented against our honeypot.\r\nAfter gaining the ability to upload the malicious payload by exploiting the RocketMQ vulnerability, the attacker is\r\nable to execute their malicious code, which downloads the Muhstik malware. \r\nhttps://www.aquasec.com/blog/muhstik-malware-targets-message-queuing-services-applications/\r\nPage 3 of 16\n\nNext, we will walk you through the different phases that the attack includes. \r\nInitial Access \r\nWe created a vulnerable RocketMQ (CVE-2023-33246) service and exposed port 10911/tcp in one of our\r\nhoneypots, it was scanned and detected by the attackers, who verified that this is a vulnerable RocketMQ version\r\nby inspecting the broker.log file. \r\nOnce the vulnerability is detected the attackers initiate a request to update the RocketMQ broker configuration\r\nfile: \r\nfilterServerNums – the value is updated to be 1. The value must be greater than 0 to trigger the callShell\r\nmethod, which is responsible for executing system commands and necessary to execute the attacker’s\r\nmalicious command. \r\nrocketmqHome – this is the default user main directory. The payload is saved to this variable, which can\r\nlater be called and executed. \r\nAs can be seen, the configuration update request is initiated from the IP address of the attacker’s server. \r\nFigure 2: Exploitation of RocketMQ Vulnerability\r\nThen, the broker configuration file is updated with the malicious “rocketmqHome” variable. It is important to note\r\nthat at this point, the malicious command is not executed but rather written into the configuration file, replacing\r\nthe current configuration, so it can be executed later on. \r\nFigure 3: Updated Broker Configuration File\r\nAt this point, the attacker can remotely execute code on our instance by exploiting the vulnerability described\r\nabove.\r\nExecution \r\nIn Figure 4, we can see that the FilterServerManager class, which manages Filters, executes the malicious shell\r\ncommand using the CallShell method. \r\nhttps://www.aquasec.com/blog/muhstik-malware-targets-message-queuing-services-applications/\r\nPage 4 of 16\n\nFigure 4: Execution of Malicious Command in RocketMQ Platform\r\nAs the curl command is available on our machine, the second condition in the or statement is executed. This\r\nexecution downloads the 3sh  shell script. \r\nFigure 5: Malicious Shell Script – ‘3sh’\r\nAs seen in Figure 5 above, the shell script contains the download of several binaries from the same remote server\r\nusing the curl command. After each binary is downloaded, it is provided with execution permissions and\r\nchanged to be available to the owner only, with no permissions for any other users (using the commands chmod\r\n+x and chmod 700 ), and then the file is executed. \r\nWe can observe that the attackers provide all the necessary conditions to ensure the attack will be executed. First,\r\nthey check which command is available on the machine in order to perform the download ( wget  or curl ) and\r\nbased on this, they build a suitable shell script that will download the binaries with the available command.\r\nMoreover, the shell script also provides the download of the Muhstik malware for each computer architecture to\r\nensure the attack could be performed on any environment without interruption. \r\nOur vulnerable RocketMQ platform architecture is x86_64. The malicious Muhstik malware – pty3  has the\r\nsame architecture and is designed to run on our honeypot. \r\nAccording to VirusTotal, the file was found malicious by 39 vendors and classified as Muhstik malware by\r\nClamAV. \r\nFigure 6: VirusTotal Scan of ‘pty3’ Binary File\r\nPersistence \r\nIn our attack, like prior attacks in which attackers were using the Muhstik malware, we can see several persistence\r\ntechniques. \r\nAs we saw earlier, the malicious binary file pty3 , recognized as the Muhstik malware, executed on our machine.\r\nAs a first step, the binary spawned the process f0sfwjsfj51tc5h , which is responsible for copying the Muhstik\r\nmalware to the following directories: \r\nhttps://www.aquasec.com/blog/muhstik-malware-targets-message-queuing-services-applications/\r\nPage 5 of 16\n\n/dev/shm/pty3 \r\n/var/tmp/pty3 \r\n/run/lock/pty3 \r\n/run/pty3 \r\nThe attackers then edited the inittab file, which is a configuration file that defines the behavior of the init\r\nprocess. The attackers used the respawn command to instruct the init process to automatically restart the\r\npty3  process in each directory it was copied to, providing the attackers with persistence by ensuring their access\r\nto the machine. \r\nDefense Evasion \r\nAccording to our signatures, it was revealed that the Muhstik malware, downloaded as pty3 , is detected as\r\npacked software. This means the file signature was changed in an attempt to avoid signature-based detection. \r\nAs mentioned above, the file is saved with the name pty3 . pty  is a known mechanism in Linux that facilitates\r\ncommunication between processes. The attackers provided the file with a seemingly legitimate name, which is\r\nsupposed to evade detection. \r\nFurthermore, the Muhstik malware was detected as fileless malware, as mentioned above the pty3 malware was\r\nwritten to the directories listed above (/dev/shm, /var/tmp, /run/lock, and /run). These often involve temporary\r\nfiles or in-memory objects. This means it performs its operation without leaving traces of files on the file system\r\nof the compromised machine. This technique allows the malware to execute code directly from memory. Malware\r\nthat operates from memory or uses temporary directories may evade detection by security tools like volume-based\r\nscanning and traditional antivirus scanners, as it doesn’t leave traces on the file system. This technique allows the\r\nmalware to execute code directly from memory, bypassing security measures that could detect and block it. \r\nDiscovery  \r\nThe attackers queried the machine for details using the uname  command to retrieve system information. This\r\ninformation is later used by the attackers and transferred through the IRC protocol.  \r\nMoreover, the Muhstik malware checks if the network tools strace and tcpdump are available on the machine\r\nit is running on. It uses the pidof  command to check if there is a running process of one of these tools and sends\r\nthe output to /dev/null, which discards the received output. Checking for the presence of network monitoring tools\r\nallows the attackers to gather information about the system’s current processes and potentially its security\r\nposture. \r\nLateral Movement \r\nThe malware has the ability to perform scanning for SSH services and also indicates attempts to authenticate and\r\npotentially gain access to other machines over SSH. Scanning for SSH services and attempting to log in with\r\ncredentials are common methods that allow attackers to enter, move laterally across a network, and gain control\r\nover remote systems. \r\nhttps://www.aquasec.com/blog/muhstik-malware-targets-message-queuing-services-applications/\r\nPage 6 of 16\n\nCommand and Control \r\nAfter the Muhstik malware executed on our machine, it performs a DNS request towards a malicious domain –\r\n“p.de-zahlung[.]eu”, which resolved to the IP address 51.79.19.53. The domain was found malicious according to\r\nVirusTotal, and the community identified that the domain has been in use in other attacks found to be related to\r\nthe Muhstik malware. \r\nFigure 7: VirusTotal Scan of IRC Server\r\nAccording to the traffic, we can see that this server is used as a command-and-control server, where the attacker\r\nmaintains communication with our compromised machine over the IRC protocol.  \r\nFigure 8: IRC Session Between the Client and Server\r\nIn Figure 8 above, we can see the communication between the client and the IRC server: \r\n1. The client connects to the IRC server, setting their nickname and user information. \r\nhttps://www.aquasec.com/blog/muhstik-malware-targets-message-queuing-services-applications/\r\nPage 7 of 16\n\n2. Then, the client and IRC server exchange PING and PONG messages between each other. The client\r\nsends PING requests for a response from the server to ensure the connection is still active, and PONG is\r\nthe response from the server. \r\n3. Next, we observe a sequence of actions and responses between the client and server in an IRC session. A\r\nprivate message is sent (PRIVMSG) querying the version of the user’s client. Then, there are messages\r\nthat are typically sent when a user connects to provide information about the server and session, and at the\r\nend the user joining to the channel.  \r\n4. The following commands are used for managing user visibility, joining channels, and retrieving\r\ninformation about the user in this IRC session. It makes the user visible (MODE) and shows their\r\nhostname by removing invisible and hostname-hiding modes. It joins to a certain channel (#ex86) with a\r\npassword (8974), and queries detailed information about the user. \r\n5. Now, the user joins to the specified channel, and the server informs about a topic in the channel and\r\nspecifies the timestamp of when it was set. Then, another user (T) sends an encrypted message\r\n(PRIVMSG) to the channel. It is common for attackers to use this method to send their malicious\r\ncommand via a private message. Aqua Tracee eBPF based tool recorded the encrypted command in clear\r\ntext – ‘/bin/dash: sh -c export PATH=/bin:/sbin:/usr/bin:/usr/local/bin:/usr/sbin;killall kdevtmpfsi\r\nkinsing cnrig kswapd0 trace xr tsm; kill $(ps aux | grep ‘cnrig\\|kinsing\\|kdevtmpfsi’ | awk ‘{print\r\n$2}’)’. This command is used to clean-up malicious or unwanted processes on the system. At first it sets\r\nthe PATH  environment variable to ensure necessary executables are available, then terminates specific\r\nprocesses by name using killall , and further ensures that any remaining processes matching certain\r\npatterns are also terminated. \r\n6. Finally, it sends a notice to the user (T), which is empty, therefore an error message is sent from the server,\r\nand then the client and server exchange PING and PONG messages – to check if the client is still\r\nconnected and confirming the connection is active.  \r\nImpact \r\nThroughout the campaign of Muhstik malware, we examined how it tries to evade security tools and stay under\r\nthe radar while spreading over the network and attacking compromised machines. During our investigation, we\r\nobserved that the malware has the ability to perform different types of flooding attacks. The attackers can leverage\r\nthis ability to overwhelm network resources and cause denial-of-service conditions. Moreover, in previous\r\ncampaigns, cryptomining activity was detected after the execution of the Muhstik malware. These objectives go\r\nhand in hand, as the attackers strive to spread and infect more machines, which helps them in their mission to\r\nmine more cryptocurrency using the electrical power of the compromised machines. \r\nMITRE Framework\r\nhttps://www.aquasec.com/blog/muhstik-malware-targets-message-queuing-services-applications/\r\nPage 8 of 16\n\nFigure 9: MITRE Framework\r\nRocketMQ vulnerability in the wild \r\nRocketMQ is a message queuing service application, by incorporating RocketMQ into the SDLC, cloud-native\r\napplications benefit from a robust messaging infrastructure that supports efficient development, deployment, and\r\noperations, ultimately leading to more resilient and scalable systems.  \r\nAfter analyzing the attack and understanding how it can impact many organizations, we were interested in\r\nknowing how many instances around the world are vulnerable to CVE-2023-33246. Using the Shodan engine, we\r\nlearned that there are 5,216 vulnerable instances of RocketMQ.   \r\nhttps://www.aquasec.com/blog/muhstik-malware-targets-message-queuing-services-applications/\r\nPage 9 of 16\n\nFigure 10: Vulnerable RocketMQ Instances Map\r\nThis data indicates how frequent this issue is, where a new vulnerability is published, yet there are still instances\r\nthat were not updated and remain exposed to attacks by malicious threat actors.  \r\nSecure your cloud native environment \r\nAs the risk of your environment being exposed to new vulnerabilities or certain misconfigurations caused by\r\nhuman mistakes continues to grow, it is important to secure your cloud-native environment and provide it with\r\ncomprehensive protection.  \r\nAqua’s Cloud Native Application Platform (CNAPP) offers that kind of solution to protect your cloud-based\r\nenvironment. It allows you to scan your environment, including your code, container images and cloud workloads,\r\nand detect threats like known vulnerabilities, concealed malware, hidden secrets, configuration errors, and open\r\nsource license issues.  \r\nAs explained earlier, the attack was initiated against our RocketMQ honeypot, which was built with a certain\r\nvulnerability. Aqua’s Platform, which includes Aqua Trivy’s premium version, is able to scan the container image\r\nand detect the Apache RocketMQ vulnerability CVE-2023-33246 in our instance, among other threats that it\r\ncontains. \r\nhttps://www.aquasec.com/blog/muhstik-malware-targets-message-queuing-services-applications/\r\nPage 10 of 16\n\nFigure 11: Aqua’s Detection of RocketMQ Vulnerability\r\nAqua’s platform also provides runtime protection and can detect suspicious behaviors in our workload as we\r\nobserve in our attack. \r\nhttps://www.aquasec.com/blog/muhstik-malware-targets-message-queuing-services-applications/\r\nPage 11 of 16\n\nhttps://www.aquasec.com/blog/muhstik-malware-targets-message-queuing-services-applications/\r\nPage 12 of 16\n\nhttps://www.aquasec.com/blog/muhstik-malware-targets-message-queuing-services-applications/\r\nPage 13 of 16\n\nFigure 12: Timeline of Attack Events in Aqua’s Platform\r\nHow to protect your organization? \r\nIn this blog we saw how a certain vulnerability in the RocketMQ instances allows attackers to abuse the\r\nRocketMQ platform and execute the Muhstik malware. This grants the attackers persistency on the compromised\r\nmachine and the ability to hijack resources to achieve their desired impact. Moreover, we demonstrated how\r\nwidespread this attack can be. Using the Shodan engine, we revealed that there are still vulnerable instances.  \r\nThe number of vulnerable instances around the world emphasizes how important it is to strengthen your security\r\nmeasures and be aware of any security updates the distributors publish.  \r\nIn the meantime, we suggest you follow the following guidelines:\r\nSecure your environment – As mentioned above, misconfigured and vulnerable instances can be exploited by\r\nattackers looking to implement their attacks. The first precaution is to adhere to security guidelines in your\r\norganization, follow security updates and distributor notes about new releases, and keep your organization up to\r\ndate. \r\nScan your environment – Nowadays attackers invest all their resources to implement their attacks, and the\r\nnumber of attacks continues to grow. It is important to secure your organization with the proper security measures.\r\nIt is recommended to use runtime detection and response solutions which can detect suspicious behavior on your\r\norganization’s instances and alert you about it. \r\nEducate your employees – It is important to harden the security in your organization and stay updated with any\r\nsecurity alerts, but the most important thing you can do for your organization is to educate your employees and\r\nmake them aware of existing threats. When the entire organization is harnessed for the cause, it will be more\r\nefficient to apply the security guidelines. \r\nIndications of Compromise (IOCs)\r\nType Value Comment\r\nIP Addresses\r\nIP\r\nAddress\r\n94.224.82.40 Attacker IP\r\nIP\r\nAddress\r\n91.148.224.34 Attacker IP\r\nhttps://www.aquasec.com/blog/muhstik-malware-targets-message-queuing-services-applications/\r\nPage 14 of 16\n\nType Value Comment\r\nIP\r\nAddress\r\n89.36.76.42 Attacker IP\r\nIP\r\nAddress\r\n89.36.76.38 Attacker IP\r\nIP\r\nAddress\r\n51.79.19.53 Attacker IP\r\nIP\r\nAddress\r\n54.36.49.151 Attacker IP\r\nIP\r\nAddress\r\n 51.79.19.53 Attacker IP\r\nIP\r\nAddress\r\n139.159.192.50 Attacker IP\r\nIP\r\nAddress\r\n194.59.165.52 Attacker IP\r\nIP\r\nAddress\r\n138.197.78.18 Attacker IP\r\nIP\r\nAddress\r\n91.200.43.22 Attacker IP\r\nIP\r\nAddress\r\n139.180.185.248 Attacker IP\r\nIP\r\nAddress\r\n161.35.219.184 Attacker IP\r\nDomains\r\nDomain p.de-zahlung.eu IRC Server\r\nDomain p.shadow-mods.net IRC server\r\nDomain p.findmeatthe.top IRC server\r\nDomain p.deutschland-zahlung.eu IRC server\r\nFiles\r\nBinary\r\nfile\r\nSha256:\r\n9e28f942262805b5fb59f46568fed53fd4b7dbf6faf666bedaf6ff22dd416572\r\nMuhstik\r\nmalware\r\nhttps://www.aquasec.com/blog/muhstik-malware-targets-message-queuing-services-applications/\r\nPage 15 of 16\n\nType Value Comment\r\nBinary\r\nfile\r\nSha256:\r\n1f9cda58cea6c8dd07879df3e985499b18523747482e8f7acd6b4b3a82116957\r\nMuhstik\r\nmalware\r\nBinary\r\nfile\r\nSha256:\r\n176c57e3fa7da2fb2afcd18242b79e5881c2244f5ab836897d4846885f1bd993\r\nMuhstik\r\nmalware\r\nBinary\r\nfile\r\nSha256:\r\na7bf3c031ab66265ce724fc26c8f7565442a098b06b01ea8871f13179d168713\r\nMuhstik\r\nmalware\r\nBinary\r\nfile\r\nSha256:\r\n6730eb04edf45d590939d7ba36ca0d4f1d2f28a2692151e3c631e9f2d3612893\r\nMuhstik\r\nmalware\r\nBinary\r\nfile\r\nSha256:\r\n86947b00a3d61b82b6f752876404953ff3c39952f2b261988baf63fbbbd6d6ae\r\nMuhstik\r\nmalware\r\nSource: https://www.aquasec.com/blog/muhstik-malware-targets-message-queuing-services-applications/\r\nhttps://www.aquasec.com/blog/muhstik-malware-targets-message-queuing-services-applications/\r\nPage 16 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE",
		"Malpedia"
	],
	"references": [
		"https://www.aquasec.com/blog/muhstik-malware-targets-message-queuing-services-applications/"
	],
	"report_names": [
		"muhstik-malware-targets-message-queuing-services-applications"
	],
	"threat_actors": [
		{
			"id": "77b28afd-8187-4917-a453-1d5a279cb5e4",
			"created_at": "2022-10-25T15:50:23.768278Z",
			"updated_at": "2026-04-10T02:00:05.266635Z",
			"deleted_at": null,
			"main_name": "Inception",
			"aliases": [
				"Inception Framework",
				"Cloud Atlas"
			],
			"source_name": "MITRE:Inception",
			"tools": [
				"PowerShower",
				"VBShower",
				"LaZagne"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "3fff98c9-ad02-401d-9d4b-f78b5b634f31",
			"created_at": "2023-01-06T13:46:38.376868Z",
			"updated_at": "2026-04-10T02:00:02.949077Z",
			"deleted_at": null,
			"main_name": "Cleaver",
			"aliases": [
				"G0003",
				"Operation Cleaver",
				"Op Cleaver",
				"Tarh Andishan",
				"Alibaba",
				"TG-2889",
				"Cobalt Gypsy"
			],
			"source_name": "MISPGALAXY:Cleaver",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "a6c351ea-01f1-4c9b-af75-cfbb3b269ed3",
			"created_at": "2023-01-06T13:46:39.390649Z",
			"updated_at": "2026-04-10T02:00:03.311299Z",
			"deleted_at": null,
			"main_name": "Kinsing",
			"aliases": [
				"Money Libra"
			],
			"source_name": "MISPGALAXY:Kinsing",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775433974,
	"ts_updated_at": 1775792099,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/976b441529e35b3c13265ccde58de1c8dc854dd8.pdf",
		"text": "https://archive.orkl.eu/976b441529e35b3c13265ccde58de1c8dc854dd8.txt",
		"img": "https://archive.orkl.eu/976b441529e35b3c13265ccde58de1c8dc854dd8.jpg"
	}
}