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.
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.
86.92.237.5,80,hex,100
20.50.217.147,30028,hex,30
73.89.110.85,3074,hex,400
20.50.217.147,30028,hex,30
73.16.216.56,3074,hex,400
192.223.25.100,80,hex,120
51.255.70.104,30120,hex,30
20.50.217.147,30028,hex,300
149.202.223.210,27060,hex,45
86.172.193.255,3074,std,120
73.58.228.123,3074,hex,300
73.16.216.56,3074,hex,300
73.89.110.85,3074,hex,400
188.122.88.176,50004,std,10
73.16.216.56,3074,greip,300
188.122.88.176,50004,tcpall,10
101.112.14.171,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
Andreas Klopsch
Virus Analyst