Malware Analysis IoT Case Study — Mirai/Echobot

8 min readMar 11, 2024

Executive Summary

Mirai is a malware that was discovered by MalwareMustDie — a malware research group in August 2016. The malware infects devices running Linux such as routers, firewalls, cameras, servers and other smart home IoT devices, transforming them into remotely controlled bots that can be used by the attacker to simulate large DDoS attacks to targeted domains in order to disrupt services and platforms.

This malware analysis case study will go over a Mirai variant called ‘Echobot’ that was discovered by Palto Alto Network Researchers in June 2019. We will go over the capabilities of the malware from our own analysis and at the end of the case study provide recommendations for mitigating and preventing the malware from spreading.

Mitre Att&ck Matrix

Threat intel insights

There is not enough evidence or information to attribute this attack to a specific group or threat actor. Motivations for the threat actor behind the Echobot attack in 2019 are unknown.

IoT Malware has become more prevalent over the past few years due to the leaking of the Mirai source code, allowing possibly anyone to create their own IoT botnets with little skill and by modifying snippets of the code to suit their needs. With multiple IoT devices being rarely patched long-term, and more vulnerabilities being found and exploited there may be a steady increase of IoT Botnets and malware in the wild.

Targets

In this case study, we used an architecture-specific virtual machine for ARM to dynamically analyze our specified malware sample ‘ECHOBOT.arm6’ via Qemu 4.1.1 and BuildRoot 2. Using Docker, to import the ARM-machine we ran the sample for 60 seconds to collect system calls and network traffic.

**Figure 2.1 — Using Docker, Qemu/BuildRoot to analyze the Mirai sample dynamically**

Network traffic was then saved into a PCAP in which we further analyzed via Wireshark. The following figure below displays the GeoIP location sources of botnet traffic we collated and sorted via analyzing our Echobot sample’s network traffic.

**Figure 2.2 — Botnet Traffic sources of infected devices used for DDoS collated via Wireshark**

Main Malware Sample

The malware sample we analyzed, ECHOBOT.arm6 was hosted on an open server 80.82.67.184 where multiple other malicious executables for different processor architectures including ARM, MIPS, SPARC were hosted. Echobot.arm6 was one of such malicious executables used to spread the Mirai variant to new IoT devices, adding more infected devices to the Echobot botnet to deliver DDoS attacks.

Exploits/Vulnerabilities

This Echobot variant uses multiple RCE (Remote Code Execution) exploits to infect and propagate to other vulnerable IoT devices to be used in the botnet. Most of the common vulnerabilities we found targeted network routers, smart home devices, wireless cameras, cloud platforms, NAS systems and linux servers. We counted more than 20 exploits that were used in this sample. A list of some of the CVE exploits that we found are listed below while analyzing the malware statically via binutils and ghidra. (Rest can be seen on Github)

System Reconnaisance

As many IoT Devices use different hardware such as ARM, MIPS or SPARCE, the Echobot Mirai variant tries to gather information on these Linux devices before infecting them. This malware sample uses multiple shell commands for system scanning before trying to maintain persistence.

Some shell commands we noticed were: whoami, cat, ls, rm, cd. The malware also uses wget, curl and chmod to interact with multiple malicious payloads hosted within the C2 server (80.82.67.184).

The malware also tries to examine more about target platforms by gathering information about CPU cores and information in /proc/cpuinfo and CPU usage in /proc/stat.

Figure 3.1 — This Echobot variant gathers system information as seen in Zelos

When analyzing the malware dynamically via strace and zelos some information gathering syscalls were found:

· getsockopt, getsockname, gettimeofday, getppid

Other functions found in the malware’s non-stripped binary include:

· fstat() — To return information on files

· getpagesize() — Returns kernel symbol PAGE_SIZE which is dependent on architecture and machine model

Defense Evasion

This Echobot Mirai variant will try to disable the watchdog process in infected IoT devices. The watchdog process is used in embedded systems to monitor if a system is running and will reboot hanged systems by default due to unrecoverable software errors, booting the system back into a clean state. This will in turn remove the malware which many attackers do not want so they will try to disable this process whenever they can to avoid early detection.

**Figure 4.1 — Prevention of watchdog process rebooting in infected devices in both Mirai and Echobot**

When analyzing the malware’s system calls dynamically via zelos we can see the malware trying to open and edit the watchdog process in both /dev/watchdog and /dev/misc/watchdog to prevent watchdog from rebooting devices.

**Figure 4.2 — Prevention of watchdog process rebooting seen in Zelos**

Mirai DDoS Functionality

Echobot contains many malicious capabilities used to attack networks and systems which we can analyze and correlate alongside the original Mirai source code. Interestingly enough, this custom variant does not use HTTP flooding as one of its many main attack vectors. The following attack vectors this Echobot variant uses is listed below.

TCP Flooding — This Echobot Mirai variant performs multiple TCP flood attacks including SYN, ACK, XMAS and STOMP. These type of TCP attacks exploit the normal TCP 3-way handshake to consume more bandwidth and resources to disrupt victim servers and services.

**Figure 5.1 — Comparison of TCP-SYN Mirai Module and Echobot TCP-SYN Module**

2. UDP Flooding — This Echobot Mirai variant can perform UDP Flooding attacks including VSE, DNS and UDPPLAIN. The threat actor is able to send multiple UDP packets to overwhelm a victim’s server and to lag responses and disrupt services.

**Figure 5.2 — Comparison of UDP Flood Mirai Module and Echobot UDP Flood Module**

3. GRE Ethernet Flooding — This Echobot Mirai variant can perform GRE Ethernet flood attacks including GREIP and GREETH. In GRE flooding attacks, the threat actor will encapsulate packets with large amounts of data and route them to a victim’s network to exhaust network resources to de-encapsulate the packet payloads.

**Figure 5.3 — Comparison of GRE Flood Mirai Module and Echobot GRE Flood Module**

4. STD Attack — Echobot seems to implement a different attack vector from the original Mirai source code where the malware can send packets similar to a UDPPLAIN attack. Instead of sending the usual 512 bytes payload, the STD attack would send 1024 bytes instead. This has also been implemented in newer Mirai variants such as Owari.

**Figure 5.4 — Comparison of Owari STD Module and Echobot STD Module**

Using the command line tool strace and another python binary emulation tool to supplement our results named Zelos, we were able to analyze the dynamic behavior of the malware when executed, including network activity and system calls. After opening /dev/watchdog or /dev/misc/watchdog the malware will then use a socket to attempt a backdoor, opening up UDP port 53 to establish a connection to the google DNS server 8.8.8.8. This is done to perform a DNS query for the C&C domain and to get a corresponding IPv4 address back. Echobot will then open a random TCP port such as 43891 to the IP of our IoT device (In this case, 10.0.2.15). When Echobot succeeds it will finally close the socket and try to scan and infect other vulnerable IoT devices on networks.

**Figure 5.5 — DDoS Activity of Echobot captured via strace**

Command & Control (C&C)

This malware sample was hosted on a server with IP 80.82.67.184 alongside several other malicious samples. It communicates to the server to fetch a malicious script called ‘Richard’ via wget and curl to download more payloads hosted on the server depending on architecture. The script will then give execution permissions via the chmod command such as chmod +x or chmod 777, executing from the /tmp path to run more payloads and spread to other IoT devices with unpatched vulnerabilities to be used in the Echobot botnet.

Recommended Actions

Although it is impractical to manually block and react to most IoT botnet attacks since most botnet variants use well-known exploits to attack and compromise vulnerable outdated IoT devices, we can still try to prevent and mitigate the chance of our own IoT devices including smart home devices being infected. We can do this by:

· Updating IoT device firmware/software regularly. Many Botnet variants infect IoT devices that are unpatched.

· Make sure access credentials for our own IoT devices are not default and are hardened to stop dictionary and brute force attacks

· Disable and stop using outdated IoT devices and equipment

· If you have a router, configure router settings to detect and deter intrusions

· Make sure IoT devices auto-update whenever possible

· Use legitimate network IoT devices from trusted companies and stores

· Make sure IoT device traffic are encrypted when possible

CONCLUSION

Echobot, a successor to Mirai, is a malicious malware that can infect multiple IoT devices and transform devices into bots that can be controlled in an attacker’s botnet to perform largescale DDoS attacks to disrupt services.

Echobot is able to scan for new IoT devices to infect including routers, wireless IP cameras, NAS devices, cloud platforms, firewalls, smart home hubs and much more by targeting new and old unpatched vulnerabilities in firmware. A leap from the default Mirai which used default credentials to spread to other infected devices. With the Mirai source code being released in 2016, it is without a doubt that the IoT security landscape has changed dramatically and has inspired new attacks and new threat actors to evolve their techniques and malware to be a more serious threat to organizations.

We believe that the IoT Malware development scene will only continue to evolve and may become a larger problem in the future when the potential of IoT attacks become more realized.

Thanks for reading!

Indicators Of Compromise

A following list of IP addresses that were used in the Echobot botnet which we captured in wireshark are listed in the link below: https://github.com/Adumbrati0n/Mirai-Case-Study/blob/main/IPHostBruteForce.txt

Hashes: 78b5d0f5d10792b1d816227015a9296b

URLS:

http://80[.]82[.]67[.]184

http://80[.]82[.]67[.]184/ECHOBOT.arm6

http://80[.]82[.]67[.]184/ECHOBOT.mips

http://80[.]82[.]67[.]184/ECHOBOT.x86

http://80[.]82[.]67[.]184/richard