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

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

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 provide an analysis of Scenario 20 [2], CTU-IoT-Malware-Capture-1-1. This malware sample is called Hide-and-Seek. This variant is an IoT malware family capable of different types of DDoS attacks, exploits vulnerabilities in other devices, such as routers and wireless cameras, and to brute force the Telnet service across the Internet to expand its botnet. This malware makes use of the custom peer-to-peer (P2P) protocol to transfer data.

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

• Wed May  9 17:30:31 CEST 2018: Traffic capture started. The malware sample was executed before the network traffic capture started.

• Mon May 14 09:24:43 CEST 2018: Traffic capture ended.

Quick Sample Analysis

Figure 1. Obfuscated data found in the binary and later decrypted when it’s going to be used.

The binary is an 32-bit ELF executable compiled for ARM systems, statically linked and stripped from symbols. This means that all necessary libraries are compiled along with the binary and that symbol names are removed from the binary. This makes it difficult for the reverse engineering and recognizance process. At first glance, the binary presents no clear strings which could indicate that the strings were encrypted before compilation and are being decrypted on-the-fly during execution.

This method of obfuscating strings (popularized by Mirai) is using the bitwise operation XOR to mutate the bytes that compose the string by XORing them against a “key” before the compilation of the binary. Those mutated bytes are still part of the binary and usually reside in the .data or .rodata sections of the ELF structure [6] (Figure 1).

By following where this data was used it's easy to find the function in charge of obfuscating and deobfuscating the strings (this is shown in Figure 2). Once the function was found, all strings could be decrypted to find out their real purpose as seen in Figure 3.

Figure 2. Function that obfuscates and deobfuscates the strings during execution used by the Hide-and-seek malware.

Figure 3. Data from Figure 1 deobfuscated by imitating the obfuscation function.

After taking a look at the deobfuscated strings it becomes evident that there are similarities between those and the ones found in Mirai’s source code [7]. This made possible the recognizance of the vast majority of the functions being used, although some were modified and new functions were added.

This malware also scans for other malware variants in the infected device (Figure 4). It does this by iterating over all the processes running in the device and searching for specific strings in memory. These strings are:

• REPORT %s:%s

• HTTPFLOOD

• LOLNOGTFO

• XMNNCPF"

• zollard

• putin

• bigbotPein

If any of those strings is found in the process memory, that particular process is killed. This will ensure the malware that it is the only one running in the device and also a way to shrink competitors’ botnets.

Figure 4. Malware checks for other malware variants running in the infected device.

When this malware starts running, it will feed its randomness buffers and check for any command line arguments. Some of those command line arguments are:

• k<int>: This parameter is used by the malware to kill a process by port and bind to that port.

• l<int>: Use the specified port to listen to UDP for P2P communication.

• s <path>: Copy itself to an specified path and don’t remove itself.

If no command line argument is specified then it will fork into a new process, if that’s not possible then it will sleep for 1 second and exit. The child process, if created, will set its priority (or niceness) to 19, the least favorable so other processes are not affected by the malware presence. And then it will remove itself from the filesystem.

After that, the malware will ignore any signal that could stop it from functioning and will create the UDP socket that will be used for the P2P communication (Figure 5).

Figure 5. Measures taken after execution by the malware in order to run uninterrupted.

For the creation of that UDP socket, this malware uses the port specified in the command line arguments or a pseudorandomly generated port number. Once the socket is created and has started listening, it modifies the iptables rules to accept anything coming from that UDP port (Figure 6). This modification is done via a forked child to avoid the main process from failing.

Figure 6. Malware executes the command iptables to add an acceptance rule for its listening UDP port.

If the UDP socket was created successfully, the malware will proceed to start killing bots and processes in the infected device, and then start the scanning/attacking process against other devices (the portion of the code performing that action is shown in Figure 7). It is important to note that this UDP socket is so valuable for the malware that, in the case this socket wasn’t created the process will exit abruptly. The steps are the following:

Figure 7. Core procedures taken from the main function after the UDP socket is created.

1. Setting up everything necessary to start the scanning and attacking process.

2. Kill other malware or processes in the device (as shown in Figure 4).

3. Start the reception of commands using a custom peer-to-peer protocol.

4. Starting the scanning and attacking process.

For step (1), the malware will set up the connection table and the raw socket used for scanning. It will also set up the command to verify if the infected device is a busybox instance. This is done by executing a random busybox command on the remote device and then checking if the error output matches the default error string. If it matches then the remote device was, in fact, infected by the malware.

In step (2) the author of this malware copied the killer_init() function almost verbatim from the Mirai source code (Figure 8). This function kills any process running an specific port (if any is specified in the arguments) and also looks into every process in /proc searching for specific strings in their memory. If those strings are found then the process is killed.

Figure 8. Similarities between the killer function in the original Mirai source code and Hide N’ Seek’s decompiled function. Also, functions like util_strcpy and util_strlen were also copied.

In step (3) the custom P2P communication is initialized. With the UDP socket already created then it will start receiving data from any other peer that reaches that random UDP port and process it as a command [8] (Figure 9). This communication could come from any other random peer previously infected. The malware searches for these peers by scanning the whole internet waiting for a specific challenge response.

Figure 9. If any data is received from the UDP socket initialized for the custom P2P communication it will be processed.

Last step (4) is the scanning and exploitation process. This process is a combination between the original Mirai’s telnet scanning procedure and a custom exploitation process created by the malware author. Exploitation is done by exploiting two vulnerabilities: a remote backdoor in TP-Link routers [9] and a remote code execution vulnerability in Netgear routers [10].

One peculiar thing is that once the malware has gained execution in the device using any of those methods it is able to set himself as a dropper by using three protocols:

• Direct byte transfer: uses the command line tool echo to save the binary bytes in the device.

• HTTP: Listens on port 80/TCP for any GET request to serve the file. Then it sends a command to use wget to download the file.

• TFTP: Listens on port 69/TCP and modifies the firewall to accept all communication to that port. After that, it will send a command to download the file using the tftp command.

Malware Traffic Analysis

During this malware capture [2] we could see that the search for peers started right away. In this run, the malware chose port 43763/UDP to start the transmission and, as the search continues, the destination address and port will be randomly generated going from the 1.0.0.0/8 to the 255.0.0.0/8 CIDR address spectrum (Figure 10). During this peer searching process the malware sent 399,666 packets but wasn’t able to find an infected device in 24 hrs. time span.

Figure 10. First packet of the capture is a peer search from the malware to reach another possibly infected device.

Meanwhile, the malware continued the scanning and attacking process using Telnet and HTTP protocols. The ports used (all TCP) for this procedure are hardcoded in the binary (Figure 11) and the list is:

• Telnet:

  • 23

  • 2323

• HTTP

  • 80

  • 8080

  • 9527

Figure 11. Ports in their hexadecimal and decimal form are hardcoded in the binary, part of the scanning function.

During its Telnet scanning, the malware was able to connect to 121,714 different hosts using both ports 23 and 2323, and transmitted approximately 2.16 MiB of data during using that protocol. It connected to 29 different telnet services across the internet and executed the busybox command to check if the device could be infected.

In the case of the HTTP scanning there were 3314 HTTP requests made by the malware. Those requests don’t show any kind of attack as none of the responses showed exploitable services as the malware checks if the device is actually vulnerable (Figure 12). This check is done by:

1. Sending a GET / request.

2. Search in the response different patterns to identify if the device is vulnerable.

3. If the device is vulnerable, to check which exploit to use [9][10].

4. Send the exploit and confirm the results.

Figure 12. While scanning the internet for vulnerable devices using the HTTP protocol the malware will process the response and search for strings to make sure it is vulnerable before attacking.

During this capture there was no resulting infection of external devices as the malware wasn’t able to find a vulnerable service nor suitable device.

Conclusion

This scenario is part of the IoT23 Dataset [1]. This analysis is about a Hide N’ Seek malware sample, executed in a RaspberryPi in the Aposemat IoT Laboratory.

The binary analysis demonstrates that there was some effort put into this malware to make it unique in the sense of using its own decentralized protocol that would help in increasing the independence of the botnet and decreasing the detection of the malware author. The analysis also showed that it used the Mirai codebase, although with a new string encryption method, and lack of a centralized C&C as it uses itself as a method for receiving and sending commands as well as a server for binary replication.

In the network analysis we were able to see that it keeps the Mirai capabilities to scan for telnet services using weak or default and also tries to exploit two vulnerabilities found in TP-Link and Netgear routers. Meanwhile it scanned for random IP addresses and UDP ports across the Internet in order to find peers to connect to using it’s custom peer-to-peer protocol.

To summarize, some of patterns found in this malware execution are:

• Firewall rules are modified to open ports:

  • 69/TCP

  • Random UDP port for peer-to-peer communication

• Files are created in the device

  • From the analysis we could see that files named con and none will be created and used in the device.

• Binaries are downloaded from random sites and TFTP servers using the command line tools wget and tftp.

• Increasing number of UDP outgoing connections to random ports and IP addresses.

  • Packets are sent every 1 second.

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.

References

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

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

3.  Panasonic Corporation, Bryant Eastham (2018, January 12). DOF Protocol Specification. Retrieved March 9, 2020, from https://asset.opendof.org/content/org.opendof.core-specifications/specifications/7/DOF_Protocol_Specification.pdf

4. Stratosphere Labs (2020, January). CTU-IoT-Malware-Capture-1-1. Retrieved March 9, 2020, from https://mcfp.felk.cvut.cz/publicDatasets/IoTDatasets/CTU-IoT-Malware-Capture-1-1/ee6fe7f885550af73a6df745d983e16c327ca3253067036744870db17a0c3437.zip

5. VirusTotal (2020, January 25). ee6fe7f885550af73a6df745d983e16c327ca3253067036744870db17a0c3437. Retrieved March 9, 2020, from https://www.virustotal.com/gui/file/ee6fe7f885550af73a6df745d983e16c327ca3253067036744870db17a0c3437/detection

6. Wikipedia (2020, February 25). Data segment. Retrieved March 11, 2020, from https://en.wikipedia.org/wiki/Data_segment

7. Jasper Manuel, Fortinet (2018, April 16). Searching for the Reuse of Mirai Code: Hide ‘N Seek Bot. Retrieved March 11, 2020, from https://www.fortinet.com/blog/threat-research/searching-for-the-reuse-of-mirai-code--hide--n-seek-bot.html

8. Threat Intelligence Team, Avast (2018, December 4). Hide ‘N Seek botnet continues infecting devices with default credentials, building a P2P network and more. Retrieved March 16, 2020, from https://blog.avast.com/hide-n-seek-botnet-continues

9. Sekurak (2013). TP-Link http/tftp backdoor. Retrieved March 16, 2020, from https://sekurak.pl/tp-link-httptftp-backdoor/

10. Mumbai, Roberto Paleari (2013, June 5). Netgear DGN1000 Setup.cgi Remote Command Execution. Retrieved March 16, 2020, from https://www.exploit-db.com/exploits/43055