Reverse Engineering and observing an IoT botnet


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.


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 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.

Overview of DDoS attack methods

Identifier Attack type Description
udp UDP flood Send large amount of UDP packets to target server.
hex UDP based attack -
syn SYN flood Send large amount of TCP SYN packets to target server. SYN packets request a connection.
ack ACK flood Send large amount of TCP ACK packets to target server. ACK packets validate that a packet is received.
udpplain UDP flood with less options, optimized for higher PPS UDP flood with different options set.
tcpall TCP flood with all options set TCP packets with all options set.
tcpfrag TCP fragmentation attack TCP flood targeting TCP reassembly mechanisms, which put together fragmented data packets.
stomp TCP stomp flood Abusing the STOMP protocol. After initial connect over TCP, junk STOMP packets are send. These are processed and can lead to a server crash.
xmas Christmas Packet attack Send packets with every single option set for whatever protocol is in use.
vse Source Engine Query Attack UDP based attack. Abuses TSOURCE ENGINE QUERY requests send to game servers. Attack is geared specifically to attack game servers.
greip Generic Routing Encapsulation attack over IP GRE is a protocol with the purpose of simplifying connections between networks. This attack abuses this protocol.
greeth Generic Routing Encapsulation attack over Ethernet Same as GREIP, but focusing on the Ethernet layer.
udpbypass Probably UDP flood with anti defense mechanisms Not implemented yet.
tcpraw TCP flood Send random data over TCP to target server.
std UDP based attack -

C2 Protocol

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.

Overview of C2 commands

C2 Format Description  
[IP],[PORT],[DDOS ATTACK METHOD],[DURATION] Start DDoS attack on remote host with delivered ip address  
![IP] Kill forked process with is currently attacking the delivered ip address  

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.

Collecting C2 commands

Finally we can reimplement the C2 protocol and start communicating with the C2 server. The C2 server will believe that a valid infected machine sent the initial beacon and will start sending C2 commands to execute.,80,hex,100,30028,hex,30,3074,hex,400,30028,hex,30,3074,hex,400,80,hex,120,30120,hex,30,30028,hex,300,27060,hex,45,3074,std,120,3074,hex,300,3074,hex,300,3074,hex,400,50004,std,10,3074,greip,300,50004,tcpall,10,80,hex,200


The block above shows a chunk of C2 commands, we received over a period of 2 days. As seen above, the hex attack type was issued very often.


Final words

The variant we just reverse engineered and tracked, is one of many common cases that are usually found in the IoT threat landscape. When dealing with IoT malware, you will find many similar cases like this.

Therefore it is very important for researchers to understand cases like this in the same way as it is important to distinguish between a more sophisticated banking trojan like Emotet and a malware written by some hacker, that is writing malware only for the thrill of it. Understanding differences like this, helps us to look out for more advanced IoT malware like the Mozi malware, that appeared around September 2019. IoT malware can and will advance forward and we will keep an eye open.

Indicators of compromise (IOCs)

Sample name Architecture Sha256
FederalAgency.arm5 Armv5 a1ffd6f459720014d7e54c023183b32f55fdd3811301922d623c96b2b4dcd024
FederalAgency.arm6 Armv6 a401e7ff574bcc5c34c6842e57fe5e4e7a00f9c8c52658abf033f0534a31ba90
FederalAgency.arm7 Armv7 f63f6c6549f238cca61b179d9b85aebce08348ce23c3c9db218038cb4f2d13f4
FederalAgency.mips Mips cbe3ad269c4b89027f9f475ee2b3d9be04cd48711a5ab85c3609b6389079ecb1
FederalAgency.ppc PowerPc 59be5962169607dc9a0f0cea3056dc097b5c981f4fd9bca6dfc4c805b43b56b2
FederalAgency.x86 x86 4126ccad08f12e61c06869726e1867e8970d705cd9c649ff7326141530eb5ed4

Icons created by Freepik