IoT-23 In Depth: CTU-IoT-Malware-Capture-3-1

This blog post was authored by Lisandro Ubiedo (@_lubiedo) on 2020-02-17.

This post is a continuation of the IoT-23 In Depth series based on the IoT-23 Dataset, the first dataset of malicious and benign IoT network traffic, that consists of 23 scenarios [1]. In this blog post we show an analysis of Scenario 19 [2], CTU-IoT-Malware-Capture-3-1. This malware sample is called Muhstik and it’s a variant of the STD/Tsunami bot. The STD/Tsunami bot is an IoT malware capable of different types of DDoS attacks and it uses the IRC protocol to communicate with its C&C server.

The SHA256 hash of the malware sample executed is fce7b8bbd1c1fba1d75b9dc1a60b25f49f68c9ec16b3656b52ed28290fc93c72 [3].  VirusTotal identified the malware as Linux.Tsunami and gave it a score of 25/59 (meaning that 25 out of 59 engines detected this file) [4]. The sample was executed on a RaspberryPi 3+ (ARMv7) with Raspbian OS. The timeline of the traffic capture for this malware is:

  • Sat May 19 20:56:36 CEST 2018 Traffic capture started.

  • Sat May 19 20:57:40 CEST 2018: Malware executed.

  • Mon May 21 09:05:05 CEST 2018: Device disconnected.

Quick Sample Overview

The malware sample executed is an ELF32 ARM binary, statically linked and stripped, with plain-text strings that could be used to identify the malware itself (Figure 1) and link it against other variants of the Tsunami malware.

Figure 1. This Muhstik sample has embedded a phrase taken from the anime Bakemonogatari.

Figure 1. This Muhstik sample has embedded a phrase taken from the anime Bakemonogatari.

The binary was packed using the UPX packer but, as reported by MalwareMustDie while analyzing other variants [5], unpacking the sample using an out-of-the-box upx tool is not possible because of the custom UPX headers in this binary. One easy way to unpack it is dumping it directly from memory after the uncompression process is carried out. Another way, is to fix the UPX headers which will involve the process done in a previous post while we analysed Hajime [6] and also remove the random bytes added to confuse the unpacker. The steps we carried out to unpack the sample are:

  1. Modify the UPX header at file offset 0x78 from 0x0A000000 to 0x55505821 (“UPX!”) to restore the UPX magic number (Figure 2)

  2. Remove the junk bytes added at the end of the file (12 bytes at file offset 0xC0BC8) 

  3. Add the UPX magic number 0x55505821 (“UPX!”) at the UPX header located at the end of the file (also at file offset 0xC0BC8).

After these modifications, the packed binary can be unpacked using the upx tool (as shown in Figure 3).

Figure 2. UPX magic number being restored using radare2. Any hex editor is suitable for this type of edition.

Figure 2. UPX magic number being restored using radare2. Any hex editor is suitable for this type of edition.

Figure 3. After fixing the Muhstik binary the upx tool is able to parse the binary and the unpacking is possible.

Figure 3. After fixing the Muhstik binary the upx tool is able to parse the binary and the unpacking is possible.

The sample contains the IPv4 addresses and domains of its C&C (command and control) servers hardcoded into the binary, as well as the username “muhstik”, realname “muhstik-11052018”, key “:8974” and chat room “#a925d765” used to establish the IRC (Internet Relay Chat) [7] connection to them. This is the list of servers hardcoded into the binary:

  • 51.38.81.99

  • 54.39.23.28

  • 185.61.149.22

  • 185.47.129.56

  • 111.230.241.23

  • irc.de-zahlung.eu

  • irc.deutschland-zahlung.net

  • irc.deutschland-zahlung.eu

The list of commands accepted from the C&C is shown in Figure 4. Among the commands we can find instructions to perform flooding attacks (ie. connection saturation), download files to the infected device, SSH brute forcing, execution of shell commands and custom IRC commands.

Figure 4. IRC commands available in this Muhstik bot to be executed by the botmaster. This is the available command list sent to the botmaster via the HELP command.

Figure 4. IRC commands available in this Muhstik bot to be executed by the botmaster. This is the available command list sent to the botmaster via the HELP command.

In the first run the malware is going to check that only one instance is running in the device. To accomplish this, the following actions are taken:

  1. Check for the lock file .ubntmuh in a set of directories:

    1. /dev/shm/

    2. /var/tmp/

    3. /var/lock/

    4. /var/run/

    5. /tmp/

  2. Bind to port 61000/TCP at localhost.

If any of these actions fail, then the malware will exit abruptly. If not, it will carry out different actions to persist in the device by modifying the crontab entries (Figure 5), the inittab file which is in charge of running processes depending on the runlevel, and the rc.local/rc.conf file which decides which applications run at boot time. The malware will also copy itself to these directories, modifying the inittab and crontab files if the copying was successful:

  • /dev/shm/

  • /var/tmp/

  • /var/lock/

  • /var/run/

  • ~ ($HOME)

Figure 5. The Muhstik malware creates crontab entries to persist in the device. In this case, the malware will be executed every 5 minutes.

Figure 5. The Muhstik malware creates crontab entries to persist in the device. In this case, the malware will be executed every 5 minutes.

Then it will check if the user ID is 0 (root) and if that’s true it will add the DNS 8.8.8.8 (Google’s DNS) to the device’s nameserver list. 

Once the activities have finished, the collection of information is sent to the C&C server as part of the IRC NICK [7] that must be unique for device. In the case of this device the NICK was A5|1|5358668|black-pe and has this structure:

  • “A5”: a constant string added to all NICKs.

  • ”1”: A binary number representing if the user is root or not. In this case the user running the malware was root.

  • “5358668”: A unique number generated randomly in a range from 1000000 to 9999999.

  • “black-pe”: Part of the device hostname.

What’s curious and might indicate that the code of this malware was reused is the fact that the majority of the information collected (Figure 6) during this process (ie. Model name) is not even used as it is not seen in the final nickname used during the IRC session.

Figure 6. Files read by the malware while constructing the NICK. This unique nickname is used by the C&C to identify unique instances.

Figure 6. Files read by the malware while constructing the NICK. This unique nickname is used by the C&C to identify unique instances.

This bot has the capability of performing SSH login brute force attacks via the SSH command (as seen in Figure 4), to a range of IP addresses. To do this the bot uses a fixed wordlist to attack default login (Figure 7). After connecting via SSH to any instance, the malware is capable of dropping new code to perform further actions in the device (Figure 8).

Figure 7. List of default usernames and passwords to be used by the SSH brute force attack. Some of these range from default cloud passwords to common passwords used by end users.

Figure 7. List of default usernames and passwords to be used by the SSH brute force attack. Some of these range from default cloud passwords to common passwords used by end users.

Figure 8. Code executed after a successful SSH connection to another instance. This is executed using the HTTP URL and TFTP host provided to the IRC command by the C&C admin.

Figure 8. Code executed after a successful SSH connection to another instance. This is executed using the HTTP URL and TFTP host provided to the IRC command by the C&C admin.

Malware Traffic Analysis

All IRC traffic to the C&C servers is sent to the port 2407/TCP, hardcoded in the binary. During this communication to the C&Cs, 5 out of 8 C&C servers were used (Figure 9) and  approximately 374 kilobytes of data were transmitted between the device and the servers. Something to point out is that the IP addresses for the hosts irc.de-zahlung.eu and irc.deutschland-zahlung.net are already hardcoded in the binary, and that the hostname irc.deutschland-zahlung.eu could not be resolved.

Figure 9. Conversation statistics between the infected device and the C&C servers.

Figure 9. Conversation statistics between the infected device and the C&C servers.

As soon as the bot connects to one of the C&C IRC servers, it performs these steps:

  1. Establish its unique nick, username and realname for the botmaster to identify the new bot.

  2. After that, the IRC server will send a PING with a specific server which it’s answered by the infected device with a PONG.

  3. It will modify its user mode for this IRC session by using MODE <nick> -xi. This will show the bot’s IP address and make it visible in the room, which later confirms by using the WHO command.

  4. Joins the chatroom #a925d765 using the user’s key “:8974”. The key is a password used to access the chatroom.

Something seen after the bot connects to any of the C&C servers is that exactly every hour the user T!T@null will send a private message to the whole channel to execute the bot’s SSH command. The format of that command is:

SSH <192 or 192.168 or 192.168.0> <threads> <minutes> <http_string> <tftp_host>

This command will brute force SSH services in a range of IPv4 addresses specified by the botmaster and represented by the first octet (ie. 161 being the range 161.0.0.0/8).

If a successful SSH connection is made from the bot to an attacked IP then it will send a series of commands to the device to download malware from the HTTP URL 77.37.146.157/.x (in this scenario). As seen on Figure 8, this URL is then constructed to these final endpoints and used to distribute more malware:

  • http://77.37.146.157/.x/1sh

  • http://77.37.146.157/.x/2sh

  • http://77.37.146.157/.x/3sh

These URLs were not detected by VirusTotal nor URLhaus as malicious and contain shell scripts that will get executed by the malware and will drop the final malware from: http://138.197.99.34/.x/.

This process can be seen in Figure 10.

Figure 10. Steps taken by then bot and command sent from the C&amp;C. All IRC sessions have this same structure.

Figure 10. Steps taken by then bot and command sent from the C&C. All IRC sessions have this same structure.

During this traffic capture the bot scanned different network ranges to find default or weak SSH passwords and reproduce itself inside the instances. Those ranges were:

  • 5.0.0.0/8
  • 17.0.0.0/8
  • 31.0.0.0/8
  • 32.0.0.0/8
  • 51.0.0.0/8
  • 69.0.0.0/8
  • 74.0.0.0/8
  • 80.0.0.0/8
  • 90.0.0.0/8
  • 95.0.0.0/8
  • 104.0.0.0/8
  • 114.0.0.0/8
  • 118.0.0.0/8
  • 121.0.0.0/8
  • 131.0.0.0/8
  • 133.0.0.0/8
  • 137.0.0.0/8
  • 141.0.0.0/8
  • 144.0.0.0/8
  • 148.0.0.0/8
  • 155.0.0.0/8
  • 157.0.0.0/8
  • 161.0.0.0/8
  • 167.0.0.0/8
  • 182.0.0.0/8
  • 183.0.0.0/8
  • 191.0.0.0/8
  • 196.0.0.0/8
  • 197.0.0.0/8
  • 200.0.0.0/8
  • 202.0.0.0/8
  • 203.0.0.0/8
  • 204.0.0.0/8
  • 219.0.0.0/8

Overall, the bot attempted to connect to 64,182 hosts and was able to successfully connect to 209 SSH services.

In the case of the C&C server 111.230.241.23 the IRC service hit its clients max and the bot wasn’t able to connect (Figure 11). After that, the malware will connect to the next server in the list, this way iterating through all the servers and continue scanning.

Figure 11. The IRC C&amp;C server was full and the bot wasn’t able to connect.

Figure 11. The IRC C&C server was full and the bot wasn’t able to connect.

There are different IRC servers and based on the ERROR message it can suggest that the server could be a UnrealIRCd IRC server [8] and, if the administrator of the C&Cs is using the example configuration, the server that is full could be supporting around 500 clients which can give away the amount of actual bots connected to that specific C&C server.

During this scenario no HTTP attack was captured nor ordered from the C&C. Either way, there’s a varied list of user-agents that the bot is able to use during its requests, ranging from normal desktop browsers to game consoles or smartphone browsers:

  • Mozilla/5.0 (Windows NT 10.0; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0
  • Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.9a8) Gecko/2007100620 GranParadiso/3.1
  • Mozilla/5.0 (compatible; U; ABrowse 0.6; Syllable) AppleWebKit/420+ (KHTML, like Gecko)
  • Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.11) Gecko/20071128 Camino/1.5.4
  • Mozilla/5.0 (Windows; U; Windows NT 6.1; rv:2.2) Gecko/20110201
  • Mozilla/5.0 (X11; U; Linux i686; pl-PL; rv:1.9.0.6) Gecko/2009020911
  • Mozilla/5.0 (Windows; U; Windows NT 6.1; cs; rv:1.9.2.6) Gecko/20100628 myibrow/4alpha2
  • Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; MyIE2; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0)
  • Mozilla/5.0 (Windows; U; Win 9x 4.90; SG; rv:1.9.2.4) Gecko/20101104 Netscape/9.1.0285
  • Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.8) Gecko/20090327 Galeon/2.0.7
  • Mozilla/5.0 (PLAYSTATION 3; 3.55)
  • Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 Lightning/4.0.2
  • wii libnup/1.0
  • Mozilla/4.0 (PSP (PlayStation Portable); 2.00)
  • PSP (PlayStation Portable); 2.00
  • Bunjalloo/0.7.6(Nintendo DS;U;en)
  • Doris/1.15 [en] (Symbian)
  • BlackBerry7520/4.0.0 Profile/MIDP-2.0 Configuration/CLDC-1.1
  • BlackBerry9700/5.0.0.743 Profile/MIDP-2.1 Configuration/CLDC-1.1 VendorID/100
  • Opera/9.80 (X11; Linux i686; Ubuntu/14.10) Presto/2.12.388 Version/12.16
  • Opera/9.80 (Windows NT 5.1; U;) Presto/2.7.62 Version/11.01
  • Mozilla/5.0 (X11; Linux x86_64; U; de; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 Opera 10.62
  • Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36
  • Mozilla/5.0 (Linux; Android 4.4.3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.89 Mobile Safari/537.36
  • Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.39 Safari/525.19
  • Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0; chromeframe/11.0.696.57)
  • Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; uZardWeb/1.0; Server_JP)
  • Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_7; en-us) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Safari/530.17 Skyfire/2.0
  • SonyEricssonW800i/R1BD001/SEMC-Browser/4.2 Profile/MIDP-2.0 Configuration/CLDC-1.1
  • Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/4.0; FDM; MSIECrawler; Media Center PC 5.0)
  • Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110517 Firefox/5.0 Fennec/5.0
  • Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; FunWebProducts)
  • MOT-V300/0B.09.19R MIB/2.2 Profile/MIDP-2.0 Configuration/CLDC-1.0
  • Mozilla/5.0 (Android; Linux armv7l; rv:9.0) Gecko/20111216 Firefox/9.0 Fennec/9.0
  • Mozilla/5.0 (compatible; Teleca Q7; Brew 3.1.5; U; en) 480X800 LGE VX11000
  • MOT-L7/08.B7.ACR MIB/2.2.1 Profile/MIDP-2.0 Configuration/CLDC-1.1

Conclusion

From the network analysis we could see that it uses IRC as a medium to communicate with its C&C servers. Muhstik is capable of performing DDoS and  SSH brute forcing attacks. It can also function as a dropper for other kinds of malware and replicate itself thanks to this capability. 

Based on the binary analysis, this malware makes no attempts to hide inside the device nor to avoid its detection.

These are the indicators of compromise identified in this analysis:

  • Multiple connections to port 2407/TCP

    • Protocol used in those connections is IRC.

    • C&C servers communicating via IRC:

      • 51.38.81.99

      • 54.39.23.28

      • 185.61.149.22

      • 185.47.129.56

      • 111.230.241.23

      • irc.de-zahlung.eu

      • irc.deutschland-zahlung.net

      • irc.deutschland-zahlung.eu

  • Crontab is modified and malware is added to run every 5 minutes.

  • Listens locally on port  61000/TCP.

  • Creates the lock .ubntmuh file inside the file system.

  • Shell scripts and executables downloaded from:

    • 77.37.146.157

    • 138.197.99.34

Acknowledgement

This research was done as part of our ongoing collaboration with Avast Software in the Aposemat project. The Aposemat project is funded by Avast Software.

 
logo-avast.png
 

References

  1. Stratosphere Labs (2020, January). CTU-IoT-Malware-Capture-3-1. Retrieved February 6, 2020, from https://mcfp.felk.cvut.cz/publicDatasets/IoT-23-Dataset/IndividualScenarios/CTU-IoT-Malware-Capture-3-1/

  2. Stratosphere Labs (2020, January 22). Aposemat IoT-23: A Labeled Dataset With Malicious And Benign IoT Network Traffic. Retrieved February 6, 2020, from https://www.stratosphereips.org/blog/2020/1/22/aposemat-iot-23-a-labeled-dataset-with-malicious-and-benign-iot-network-traffic

  3. Stratosphere Labs (2020, January). CTU-IoT-Malware-Capture-3-1. Retrieved February 6, 2020, from https://mcfp.felk.cvut.cz/publicDatasets/IoT-23-Dataset/IndividualScenarios/CTU-IoT-Malware-Capture-3-1/fce7b8bbd1c1fba1d75b9dc1a60b25f49f68c9ec16b3656b52ed28290fc93c72.zip

  4. VirusTotal (2018, July 30). Retrieved February 6, 2020, from https://www.virustotal.com/gui/file/fce7b8bbd1c1fba1d75b9dc1a60b25f49f68c9ec16b3656b52ed28290fc93c72/detection

  5. The MalwareMustDie Blog (2016, April 16). MMD-0053-2016 - A bit about ELF/STD IRC Bot: x00's CBack aka xxx.pokemon(.)inc. Retrieved February 6, 2020, from https://blog.malwaremustdie.org/2016/04/mmd-0053-2016-bit-about-elfstd-irc-bot.html

  6. Lisandro Ubiedo, Stratosphere Labs (2020, February 4). IoT-23 In Depth: CTU-IoT-Malware-Capture-9-1. Retrieved February 6, 2020, from https://www.stratosphereips.org/blog/2020/2/3/iot-23-in-depth-ctu-iot-malware-capture-9-1

  7. J. Oikarinen, D. Reed (1993, May). RFC 1459: Internet Relay Chat Protocol. Retrieved February 9, 2020, from https://tools.ietf.org/html/rfc1459#page-14

  8. The UnrealIRCd Team (2005). Unreal/m_nick.c. Retrieved February 10, 2020, from https://github.com/unrealircd/unrealircd/blob/bd9c1afce36f42bc8cccea3adcf315f72b36afa6/src/modules/m_nick.c#L876-L881