, ,

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

, ,

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

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 13 [2], CTU-IoT-Malware-Capture-8-1. This malware sample is called Hakai and it’s a variant of Linux.Mirai/Gafgyt. Mirai is an IoT malware family capable of different types of DDoS attacks, telnet brute force attacks and it uses different sets of exploits to infect other devices, such as routers.

The SHA256 hash of the malware sample executed is f05e731a3dca8868af3a05ae4867a39f397e0d54221229c0be74c8a20d00e364 [3].  VirusTotal identified the malware as Linux.Gafgyt and Linux.Mirai, and gave it a score of 34/57 (meaning that 34 out of 57 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:

  • Tue Jul 31 16:27:14 CEST 2018: Malware executed.

Quick Sample Overview

The malware sample is an 32-bit ELF executable binary, compiled statically using uClib instead of glibc, unstripped (ie. function names still in the binary after compilation). It was compiled with debug or DWARF (“Debugging With Arbitrary Record Formats”) [5] headers which is a debugging format aimed to aid the debugging process by appending extra information, like variable types. This shows that the creator had no interest in avoiding detection nor making the reverse engineering task more difficult.

Upon execution, the malware checks the presence of the Python interpreter. If it’s available it will use sshd as a process name to hide itself. If it isn’t, it will use dropbear which is a lightweight adaptation of sshd (Figure 1).

image.png
Figure 1. Check which SSH server name to use and impersonate the process using prct(). The creator could use Python’s presence on the device to identify which OS is being used.

Figure 1. Check which SSH server name to use and impersonate the process using prct(). The creator could use Python’s presence on the device to identify which OS is being used.

Then, it will proceed to retrieve the device IP address by calling getOurIP() that tries to contact Google’s DNS server 8.8.8.8 (port 53/UDP). If that’s not possible then it will try to get it from the system file /proc/net/route. Once the IP address has been obtained, the main table with all the obfuscated values is initialized. This part is an unaltered version of what could be found in the Mirai source code [6] but only the XOR key was changed to 0xDEDEFFBA or 0x45. The table management works like this:

  1. The values to be added to the table have previously been XORed using the key.

  2. table_init() is called to populate the table with those values.

    1. add_entry() is used and each call holds those values as parameters.

  3. Whenever a value needs to be retrieved table_unlock_val() needs to be called to deobfuscate and unlock the value.

  4. Once the value is deobfuscated, table_retrieve_val() is called to get the plan text value.

  5. After the value is used then a call to table_lock_val() will lock the data again, obfuscating it.

Figure 2. After imitating the toggle_obj() function the C&C server information can be decrypted.

Figure 2. After imitating the toggle_obj() function the C&C server information can be decrypted.

By using this information is easy to retrieve the C&C information used by this malware to send scanning reports to (Figure 2):

  • Server: hakaiboatnet.pw

  • Port: 1991

These scanning reports announce to the C&C server that a brute force effort was successful.

Using this same method it is also possible to deobfuscate the username and passwords table used by the scanner capability of this bot to brute force Telnet services across the internet (Figure 3).

Additions to Mirai Codebase

Figure 3. Usernames and passwords used during the telnet scanning and brute force process. These were deobfuscated using the process previously detailed.

Figure 3. Usernames and passwords used during the telnet scanning and brute force process. These were deobfuscated using the process previously detailed.

One of the first functions executed that’s unique to this variant is initConnection(). This function is in charge of creating a connection with the C&C server (Figure 4):

  • Server: 178.128.185.250

  • Port: 50/TCP

Figure 4. Command and Control port and IP address, both hardcoded into the binary.

Figure 4. Command and Control port and IP address, both hardcoded into the binary.

If this connection with the C&C is not possible the malware will sleep for 5 seconds and retry the connection until it is successful. Once connected it will send the build type (“ARM-4” in this case) and will wait for commands to be processed by processCmd(). These commands are:

  • “SC”: Toggle the scanning and exploitation ON or OFF (Figure 5). 

  • “H”: HTTP flooding. HTTP requests are sent to the victim using a hardcoded set of 1021 bytes (“/x38/xFJ/x93/xID/x9A/x38”) as URL path.

  • “U”: UDP flooding. Sends UDP packages using random data.

  • “S”: STD flooding. This is an UDP flooding attack but using larger packets. Setings 

  • “T”: TCP flooding. Sends TCP packages and is capable of setting different TCP flags.

Figure 5. If command “SC” is toggled ON it will call the functions exploit_worker() and scanner_init(). This will start the exploitation and brute force process.

Figure 5. If command “SC” is toggled ON it will call the functions exploit_worker() and scanner_init(). This will start the exploitation and brute force process.

We will focus on the exploit_worker() function of this specific malware. This function is the one in charge of forking of the main process and starting the execution of different sets of exploits against different targets. It works by generating a random IP address for each exploit and then launching an exploit to that address (Figure 6). These exploits are used by the malware to infect vulnerable devices dropping and executing a binary from this HTTP address (hardcoded in the binary): https://178.128.185.250/e

This URL was detected by 5 out of 72 engines by VirusTotal [7] and appears to have been retired already.

Figure 6. For each exploit an IP address is generated and the exploit is sent to that address. This way the malware will keep infecting vulnerable devices.

Figure 6. For each exploit an IP address is generated and the exploit is sent to that address. This way the malware will keep infecting vulnerable devices.

image.png

This is the list of vulnerabilities that are being exploited by this malware:

Function Exploit CVE Advisory
exploit_socket_gpon8080 GPON routers OS Command Injection CVE-2018-10562
exploit_socket_dlinkdsl D-Link DSL-2750B OS Command Injection N/A
exploit_socket_hnap DIR-806 OS Command Injection CVE-2019-10891
exploit_socket_crossweb Unknown CCTV-DVR OS Command Injection N/A
exploit_socket_huawei Huawei HG532 OS Command Injection CVE-2017-17215
exploit_socket_jaws MVPower DVR OS Command Injection N/A
exploit_socket_netgear Netgear DGN1000 OS Command Injection N/A
exploit_socket_r7064 Unknown Router OS Command Injection N/A
exploit_socket_realtek Realtek SDK Miniigd UPnP
SOAP Command Execution		 CVE-2014-8361
exploit_socket_tr064 Eir D1000 Router OS Command Injection N/A
exploit_socket_vacron Vacron NVR CCTV OS Command Injection N/A

These exploits are publicly available and this exploitation process seems to be taken from a public code found in pastebin [8], adapted to be used on this piece of malware.

Malware Traffic Analysis

Now that we know different aspects of this malware we can analyze the traffic to port 50/TCP. During this traffic capture the malware tried to reach the C&C server at IPs 178.128.185.250 and 128.185.250.50, the second probably being a programming error made by the creator as the last octet is the port number (Figure 7). According to the connectionTimeout() function used to contact the C&C, the timeout for each connection is 30 seconds so each packet sent to the C&C is inside that timespan.

Figure 7. Overall, 12334 packets were sent by the malware to the C&C. Half of those were sent to a different, and probably wrong, IP address.

Figure 7. Overall, 12334 packets were sent by the malware to the C&C. Half of those were sent to a different, and probably wrong, IP address.

In this scenario the C&C was already down and there was no actual traffic to analyze. No scanning nor exploitation process was detected either.

Conclusion

This scenario is part of the IoT-23 Dataset. This analysis is about a Mirai/Gafgyt malware variant, Hakai, executed in a RaspberryPi in the Aposemat IoT Laboratory.

The sample is able to conduct aggressive exploitation and scanning processes that will impact IoT devices such as CCTV cameras or home routers, and thus creating a botnet. From the networking aspect we were not able to make a detailed analysis as this sample’s C&C is already defunct.

These are the indicators of compromise identified in this analysis:

  • Multiple connection attempts to port 50/TCP to these addresses:

    • 178.128.185.250

    • 128.185.250.50

  • Reports are sent to hakaiboatnet.pw and port 1991/TCP 

  • IoCs are similar to those found in Mirai.

  • Active exploitation attacks coming out of the device.

    • Traffic contains any of the previously mentioned attacks.

  • In case of an active HTTP flooding, “/x38/xFJ/x93/xID/x9A/x38” is in the path of the multiple requests being made via that protocol

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 22). Aposemat IoT-23: A Labeled Dataset With Malicious And Benign IoT Network Traffic. Retrieved February 18, 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-8-1. Retrieved February 18, 2020, from https://mcfp.felk.cvut.cz/publicDatasets/IoT-23-Dataset/IndividualScenarios/CTU-IoT-Malware-Capture-8-1/

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

  4. VirusTotal (2018, November 14). Retrieved February 19, 2020, from https://www.virustotal.com/gui/file/f05e731a3dca8868af3a05ae4867a39f397e0d54221229c0be74c8a20d00e364/detection

  5. DWARF Committee (2017, October). DWARF FAQ. Retrieved February 19, 2020, from http://wiki.dwarfstd.org/index.php?title=DWARF_FAQ

  6. Anna-Senpai (Unknown). jgamblin/Mirai-Source-Code. Retrieved February 19, 2020, from https://github.com/jgamblin/Mirai-Source-Code

  7. VirusTotal (2020, February 19). Retrieved February 19, 2020, from https://www.virustotal.com/gui/url/e55e330a8118813793f41c82019db35a1c11688534c316abf49499203be3b623/detection

  8. WTFBBQ (2018, July 13). routerpwn.c .Retrieved February 20, 2020, from https://pastebin.com/UGe1vNEJ

Protecting the civil society through high quality research