Reverse Engineering and observing an IoT botnet

[harlan4096]

IoT devices are everywhere around us and some of them are not up to date with todays security standard. A single light bulb exposed to the internet can offer an attacker a variety of possibilities to attack companies or households. The possibilities are endless.
 
If we think about a router or follow the example with the light bulb, such a hijacked device can be used for various malicious activities. For example building a botnet and monetizing it by offering DDoS as a service or using the IoT device as a gateway into a corporate network. There have also been cases, where ransomware was used on IoT devices. And when we talk about IoT in the context of abuse by malicious actors, the term is by no means limited to consumer hardware such as the as the aforementioned lightbulbs. This includes remotely controlled HVAC systems and also things like access control systems for buildings. You will find that the latter can work in more sense than one.

In this article, we will focus on reverse engineering a common IoT malware sample and connect to the C2 server, in order to observe the commands sent from the actor to the infected devices.

Infection

In our case, we observed that the C2 server is responsible for an initial infection. By research, we found evidence that the server with the IP address 103.145.12.11 scans for devices, which are vulnerable to CVE-2019-7256. The CVE describes a Remote Code Execution vulnerability in Access Control Systems from the Linear eMerge E3-Series. This is an access control system commonly found in office and administration buildings. You may have used one of these systems yourself when swiping your key card in the morning, or a visitor's badge. By abusing the CVE-2019-7256 security vulnerability the attacker can inject malicious shell commands to download its malware and execute it on the device.The exploit downloads a sample from the C2 server. Afterwards the executable flag is set for this sample and it is executed. Finally the sample is deleted from the infected device.

We were able to retrieve further samples from the ip address above. This article will focus on the variant targeting the x86 architecture. The corresponding hashes for these samples can be found at the end of this article.

Reverse Engineering the malware

Next, let's dive into the malware and reverse engineer it. Most IoT malware found in the wild can be classified as a Mirai variant. Going through the code, we identified multiple functions, which are also used in the original Mirai code. However, the author modifed the code and came up with some original routines.

At the beginning of the execution, the attacker prints his handle. This is very common for IoT malware and can also be a good factor for further classification, as well as assigning variants to specific authors.
This variant has a list of common default telnet credentials hardcoded. During execution, it generates random IP addresses and tries to connect to the telnet port.

We did not investigate this function completely. However, we believe that once a telnet port is bruteforced sucessfully, it will send the victim ip address, as well as the used credentials to its C2 server. Either the C2 server or the sample itself could trigger the malicious action, which will lead to a device takeover.

Overview of DDoS capabilities

Most of the implemented attack variants are all known to us. We identified two UDP based DDoS attacks, which we did not dive deeper into and were not able to identify yet. The sample also has an attack method with the identifier "udpbypass", which is not implemented yet. This is very interesting, because it indicates that this variant is still a work in progress. 

A table below shows all the DDoS attack types that we found.
...

Continue Reading