In our previous blog post on ARM Exploitation, we covered the most recent examples of IoT attacks on ARM devices with the objective of indicating the threats surrounding contemporary ARM gadgets and to recommend why it is important to get familiar with ARM exploitation. You can read the full blog post here.

In this post, we will be providing a retrospective analysis of Mirai — the infamous Internet-of-Things botnet that temporarily disabled a few high-profile administrations, for example, OVH, Dyn, and Krebs on Security via massive distributed denial-of-service (DDoS) attacks using hundreds of thousands of compromised Internet-Of-Things devices like air-quality monitors, personal surveillance cameras and home routers.

At its peak in September 2016, Mirai attacks were reported to have surpassed 1 Tbps by OVH—the largest on the public record and had contaminated more than 600,000 IoT gadgets by November 2016.

Before digging further into Mirai's story, let's take a quick look at how Mirai functions, how it propagates, and its offensive capacities.

Mirai's Structure and Activity

Mirai spread by first entering a quick scanning stage where it proliferates by haphazardly sending TCP SYN probes to pseudo-random IPv4 addresses, on Telnet TCP ports 23 and 2323.

Once Mirai discovers open Telnet ports, it tries to infect the devices by brute forcing the login credentials. Mirai tries to login using a list of ten username and password combinations. These ten combinations are chosen randomly from a pre-configured list 62 credentials which are frequently used as the default for IoT devices.

After successfully logging in, Mirai sends the victim IP and related credentials to a reporting server. Initially, Mirai tries to assess and identify the environment in which it is running. This information is then used to download second stage payloads and device specific malware. For instance, the payload for a ARM based device will be different than a MIPS one.

After successfully infecting a device, Mirai covers its tracks by deleting the downloaded binary and using  a pseudo-random alphanumeric string as its process name. As a result, Mirai infections do not persist after system reboots. So as to strengthen itself, the malware also terminates different services which are bound to TCP/22 or TCP/23, including other Mirai variations. At this point, the bot waits for commands from it’s command and control server (C2) while at the same time looking out for other vulnerable devices.
This wide extent of methodologies allow Mirai to perform DDoS techniques such as UDP flooding, HTTP flooding, and all TCP flooding along with application-layer attacks, volumetric attacks, and TCP state-exhaustion attacks.

Mirai DDoS events timeline

Mirai first struck OVH, one of the largest European hosting providers, on Sept 19, 2016, which later was found to target Minecraft servers that are used to battle DDoS strikes.

After this massive attack, Mirai’s alleged author "Anna-Senpai" published the source code online (a strategy often adopted) by virus makers for plausible deniability; the creators knew that their code would be further copied and improved upon and in that case, one person cannot be held responsible.

From then on,  the Mirai attacks sparked off a rapid increase in unskilled hackers who started to run their own Mirai botnets, which made tracing the attacks and recognizing the intention behind them significantly harder. While there were numerous Mirai variations, very few succeeded at growing a botnet powerful enough  to bring down major sites.

The big strike on Oct 12 was launched by another attack group against DYN, a facilities company that among other things provides DNS solutions to a lot of big businesses.The impact of this major attack was felt by users when hugely popular websites such as Netflix, Amazon, AirBnB, Twitter, Reddit, Paypal, HBO, and GitHub, were left inaccessible. According to The FBI,  this attack was not meant to “take down the internet” but eventually aimed at gaming web servers.

With these attacks and the Mirai botnet code released, it had become quite easy for anybody to try their hand at infecting IoT devices and unleashing DDoS strikes. Many cybercriminals have done just that, or are modifying and improving the code to make it even more hard to take down.

On October 31st, Mirai chose its next target -  Lonestar Cell, one of the biggest Liberian telecom operators. Over the next couple of months, the telecom giant endured 616 attacks, the maximum in the history of Mirai attacks. It was later discovered that the Mirai cluster responsible for this attack had no relation with the first Mirai or the DYN variant showing that they were arranged by an entirely different artist instead of the original creator.

On November 26, 2016, one of the biggest German Internet suppliers Deutsche Telekom, endured an immense blackout after 900,000 of its routers were knocked offline . Unexpectedly, this blackout was not due to another Mirai Distributed Denial of Service (DDoS) attack but, due to an advanced version of Mirai that left these gadgets disconnected while attempting to compromise them.

What enabled this variation to impact such huge numbers of routers was the inclusion of a router exploit targeting  the CPE WAN Management Protocol (CWMP) within its replication module. The CWMP protocol is an HTTP-based protocol utilized by numerous Internet providers to auto-configure and remotely manage modems, home routers, and other client on-premises (CPE) hardware.
The increasing number and easy availability of insecure IoT gadgets on the Internet makes it likely that they will be the major points of DDoS assaults for a long time to come.

Besides its scale, this dreadful episode is a stark reminder of how the wrong use of progressively complex IoT vulnerabilities by hackers can prompt exceptionally intense botnets. We hope the Mirai occasion acts as a wake-up call and pushes towards making IoT auto-update mandatory. This is genuinely necessary to check the huge risk posed by compromised IoT gadgets, given the poor track record of Internet users manually patching their IoT devices .

Mirai and subsequent IoT botnets can be averted if IoT vendors start to follow security best practices such as eliminating default credentials, making auto-patching mandatory, and enforcing login rate limiting to prevent brute-force attacks.