Reverse Engineering and observing an IoT botnet

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.

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.

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.

The C2 protocol is fairly simple and indicates that the author plans to keep the functionalities limited to DDoS attacks. Upon infection it sends an initial beacon message to the C2 server, which has to be sent to the C2 server only once. Afterwards, it keeps a TCP connection with the server and waits for further commands. All in all, the attacker implemented 2 different C2 commands.

Once a C2 command is received by the bot, a new child process is created. The child process utilises a small trick to change its process name. First, it takes the target ip address and appends it to an exclamation mark. Next it calls prctl with option 15 to change its own process name. The child process name now contains a substring of the attacked ip address.

The second C2 command can be used to kill an ongoing DDoS attack. Once a kill command is received, it scans the status file in the proc directory for the attacked ip adress. If found, the process is killed.