Mirai strikes | Mirai searched the internet for IoT devices

All it took was one malware to form a botnet that left the domain-based internet inaccessible to many on the eastern coast of the United States and in Europe on October 21st, 2016. It was the largest cyber attack to cause internet downtime in US history. We’re coming up on the second anniversary of the notorious Mirai botnet.

A botnet is when many computers get infected with zombie malware which enables them to be controlled by a central server in order to conduct cyber attacks with their collective computing power and bandwidth. They’re a popular way to conduct distributed denial of service (DDoS) attacks which can take down all kinds of different types of networking appliances and internet servers. Denial of service attacks are deployed by overwhelming a network target with packets until its memory buffer is filled over capacity and it’s forced to shut down. The distributed part implies that many computers are coordinated in conducting a denial of service attack.

Mirai searched the internet for IoT (Internet of Things) devices through the Telnet port. If a device had an open Telnet port, the Mirai malware would try a combination of 61 known default username and password combinations in order to find one that would allow it to maliciously authenticate. If one combination worked, the device was added to the massive and growing Mirai botnet. Most of the devices infected by Mirai malware were internet connected closed circuit TV cameras and routers.

The first major internet server attack conducted by the Mirai botnet targeted OVH, a French cloud services provider. Two DDoS attacks with a bandwidth of up to 799Gbps took down some OVH hosted Minecraft servers. By then, the botnet consisted of 145,607 devices.

Comodo malware researcher Venkat Ramanan has been watching the Mirai botnet since its discovery. “The first incident of the Mirai botnet was spotted in august 2016. Millions of IoT device attacks were noted during the same year. Mirai’s cyber criminal gang uploaded Mirai’s source code on Github in October 2016.”

On October 21st 2016, the Mirai botnet hit the Dyn network of DNS servers. DNS servers resolve domain names (such as google.com) to IP addresses (such as 8.8.8.8) so that human beings don’t have to remember those IP addresses in order to access internet services. Dyn is a widely used DNS provider, so their downtime made domain-based internet use inaccessible to lots of people. Dyn released their analysis of the attack after their incident response:

“On Friday October 21, 2016 from approximately 11:10 UTC to 13:20 UTC and then again from 15:50 UTC until 17:00 UTC, Dyn came under attack by two large and complex Distributed Denial of Service (DDoS) attacks against our Managed DNS infrastructure. These attacks were successfully mitigated by Dyn’s Engineering and Operations teams, but not before significant impact was felt by our customers and their end users.

The first attack began around 11:10 UTC on Friday October 21, 2016. We began to see elevated bandwidth against our Managed DNS platform in the Asia Pacific, South America, Eastern Europe, and US-West regions that presented in a way typically associated with a DDoS attack…

This attack has opened up an important conversation about internet security and volatility. Not only has it highlighted vulnerabilities in the security of ‘Internet of Things’ (IoT) devices that need to be addressed, but it has also sparked further dialogue in the internet infrastructure community about the future of the internet. As we have in the past, we look forward to contributing to that dialogue.”

The attack not only brought attention to how vulnerable IoT devices can be, but it also served as an excellent reminder to always change the default settings on your internet connected devices- especially usernames and passwords!

Well now, Mirai is back and badder than ever. One of the challenges of developing IoT malware is how very different IoT devices are from each other. There’s tremendous diversity in IoT devices because they can manifest as anything from industrial controllers to medical devices, from children’s toys to kitchen appliances. They can run a multitude of different operating systems and embedded software, so malicious code that can exploit the vulnerabilities on one particular device can’t usually exploit most other devices. But with the help of the Aboriginal Linux project, the latest Mirai malware can exploit a wide range of IoT devices. A malware researcher discovered it in the wild:

“At the end of July, I came across a live remote server hosting multiple malware variants, each for a specific platform. As with many Mirai infections, it starts by firing a shell script on a vulnerable device. That shell script sequentially tries downloading and executing individual executables one by one until a binary compliant with the current architecture is found…

While this is similar behavior to the Mirai variants we’ve seen so far, what makes it interesting is the compiled binary. These variants have been created by leveraging an open-source project called Aboriginal Linux that makes the process of cross-compilation easy, effective, and practically fail-proof. It should be noted that there is nothing malicious or wrong with this open-source project, the malware authors are once again leveraging legitimate tools to supplement their creations, this time with an effective cross compilation solution.

Given that the existing code base is combined with an elegant cross-compilation framework, the resultant malware variants are more robust and compatible with multiple architectures and devices, making it executable on a wide variety of devices ranging from routers, IP cameras, connected devices, and even Android devices.”

If you have IoT devices that run a version of Linux or Android and you want to security harden against this latest version of Mirai, here’s what you can do. Disable Telnet logins if possible, and block the Telnet port altogether. If you’re using default usernames and passwords, change them! Disable Universal Plug and Play (UpnP) if you can, and deploy wired Ethernet in lieu of WiFi if you’re able to. If you need to use WiFi, only connect to encrypted WiFi (WPA2 or the upcoming WPA3 is best), and have a complex password for your wireless access point.