A Technical Analysis of the Mirai Botnet Phenomenon

Picture a threat so cunning it can surface anywhere, bring down any target, and still remain inconspicuous. Welcome to the Mirai (i.e., Japanese “future”) of cyber-crime, a dissolute place where every internet-capable device can be converted into weapons with incredible offensive potential. A couple of years ago, the media caught wind of a Governmental zombie defense strategy that has been in place since the 30^th of April. Concocted by the Pentagon, the slightly inflammatory document details several ‘real-life’ undead invasion scenarios and ways to defend against ‘potential’ cephalalgic cadavers.

Such make-believes are best left to Tinsel Town moviemakers and cosmic horror writers, but the concept of zombism isn’t entirely fictional. Mirai or the topic of today’s article is as close we’re going to get to real-life, bipedal brain-munchers and it’s one of the many reasons why you should change your device’s default password; we’ll get to that later in the article. To what is Mirai, researchers have dubbed it the “uncrowned botnet king”, being capable of infecting hundreds of thousands of unsecured hosts in a timeframe so narrow, it would not allow for counteractions.

Mirai made headlines in September 2016 by taking down several high-value targets including Krebs on Security, the private cloud provider OVH, and DNS provider Dyn. What makes Mirai stand out in a crown is its IoT propensity; while most botnets target servers, personal computers, networking peripherals, Mirai zeroes in on Internet-of-Things devices (e.g., connected appliances, biometric scanners, wearable health monitors, smart security cameras, DVRs, etc.).

At its peak, the Mirai ‘zombified’ network totaled over 600,000 infected IoT devices coordinated by no less than 484 unique Command-and-Control servers, as per the Q4 2016 State of Security report.  What is the relevance of debating a five-year-old worm-like malware? Even though the Mirai ‘blight’ came to end in 2017 when the authorities identified and arrested Mirai’s author, its legacy lives on – in March 2018, ZDNet wrote about Mukashi, a new type of botnet that targets NADs (i.e., network-attached devices) and IoTs; cybersecurity researchers revealed that Mukashi’s reminiscent of Mirai, a fact proven by its voracity for unsecured IoT devices.

In this article, we’re going to explore the various facets of Mirai – source code, phylogeny, infectious mechanisms, dissemination, timeline, actions performed on a target, and countermeasures.

Mirai Botnet Timeline

Krebs on Security

On the 20^th of September 2016, the Mirai Botnet hits Krebs on Security’s website resulting in a crippling DDoS that lasted for 77 hours. Akamai, Krebs on Security’s CDN provide at the time, stated that 24,000 Mirai-infected IoT devices were used to subdue the website. During the course of the same month, five more Mirai attacks would have been launched against the website.

To date, the Krebs on Security affair is considered one of the largest DDoS attacks ever to go on record – estimates place the amplitude at around 600 to 700 million bits per second. Following the series of incidents, Akamai stepped back from its role as Krebs on Security’s CDN provider. To prevent further attacks, the site was taken offline for several more days in order to make the transition from Akamai to Google’s Project Shield.

Source code published

On the 1^st of October 2016, a hacker that went by the name of Anna-Senpai published Mirai’s source code along with instructions on how to muster bots for DDoS attacks. Interestingly enough, Mirai’s author published his ‘work’ on many clear web code repositories, including GitHub.

Dyn

On the 21^st of October 2016, Mirai moves against Dyn, a US-based DNS provider that serves several well-known brands such as Netflix, Airbnb, and Twitter. During the day in question, Dyn registered three Mirai attacks, two of which brought the entire operation to a standstill. As noted by several reputed cybersecurity researchers, the Dyn attack was much more severe and better coordinated compared to Krebs case.

The botnet that DDoSed the DNS provider totalized over 100,000 unique IPs. Of particular interest in the Dyn case is that the attacker sought to decommission the DNS provider’s datacenters and, at the same time, harvest enough credentials that would later be used to conduct similar operations. For the record, the third attack sustained by Dyn was successfully disrupted in time by the company’s IT staff.

Liberian telecom

On the first of November 2016, Mirai goes up against several Liberian telecom companies, actively disrupting Internet connectivity throughout the country. Early incident reports have suggested that mobile internet connections may have also been disrupted in the attack but were never confirmed. Several attacks were recorded throughout the day; variable in length, some lasted as much as 20-30 seconds, while others lasted minutes at an end.

The attack’s strength was estimated at around 500 Gbps. Cybersecurity experts argued that the Liberian strike was anything but wanton – the companies that came under attack manage the Africa Coast to Europe (ACE) submarine cable, a massive fiber optic cord that spans the entire West African coast and Europe.

Deutsch Telekom

On the 30^th of November, an altered version of Mirai decommissions numerous Speedport and Zyxel routers owned and operated by ISP Deutsch Telekom company. Following the massive DDoS attack, over 900,000 DT customers were denied access to Internet resources. Most cybersecurity researchers agree that an attack on Deutsche Telekom is Mirai’s next evolutionary milestone – Mirai now scans for all vulnerable devices, not just those affected by a specific type of vulnerability.

Authors caught

In January 2017, Krebs on Security concludes the investigation into the September 2016 attack. Based on Krebs’ security report, the authorities are able to identify and bring into custody Mirai’s authors. In late December, Josiah White, Pharas Jha, and Dalton Norman – all US citizens – were each sentenced to five years of probation, and ordered to cover a small amount of the financial prejudice caused by the Mirai botnet.

Although the perpetrators were apprehended and sentenced, the source code published on GitHub welcomed new aggressions. One year later, Mirai’s first variant surfaced; dubbed OMG, the botnet had refined attack capabilities, while retaining most of Mirai’s original source code.

In addition to the highly aggressive attack & kill capabilities, OMG established itself as a RaaS provider – some of the ‘zombified’ IoT devices were turned into proxy servers and sold for an undisclosed sum. A major advantage in turning an infected device into a proxy is anonymization; threat actors hiding behind multiple proxy servers are virtually impossible to trace.

The latest Mirai variants called ZHtrap and Mukashi appear to have capitalized on the botnet’s ‘original’ binaries, with some reworked features, borrowed from other botnets (e.g., ZHtrap has, more or less, the same features as Matryosh). ZHtrap is an interesting case, using honeypots to harvest additional IP addresses and other atomic indicators.

To sum up this section:

1. September 2016 – Mirai attacks Krebs on Security.
2. October 2016 – Anna-Senpai publishes Mirai’s source code.
3. 21^st October 2016 – Mirai strikes Dyn.
4. November 2016 – Mirai attacks several Liberian telecom companies.
5. 30^th November 2016 – Mirai attacks ISP Deutsch Telekom
6. January 2017 – Krebs concludes the investigation. Mirai’s authors are arrested and sentenced.
7. 2018 – OMG, Mira’s first variant, is detected in the wild.
8. 2021 – ZHTrap and Mukashi are detected in the wild.

The info’s also included in the image below.

Mirai Botnet – Attack, infection mechanism, transmission, and actions on target

In this section, we are going to discuss the Mirai botnet’s infection mechanism (action on a bot), attack patterns (actions on bot and actions on end-target), propagation methods, end-target infiltration techniques, and actions performed on end-target.

Synopsis: Mirai displays worm-like features (i.e., a non-carrier-dependent virus). The botnet has five major components: the virus, which carries ten attack vectors (i.e., Generic UDP, VSE, DNS, Plain UDAP, TCP SUN, TCP ACK, TCP STOMP, GRE IP, GRE Ethernet, and HTPP), the Command & Control Server, the bot, reporting server, and the loader server. Bots (i.e., IoT devices) are compromised via multiple dictionary/brute-force attacks. A compromised bot will send the identity & credentials to the command-and-control server. Infected bots will conduct continuous scans in order to identify and corrupt other hosts. When the C2 sever amasses sufficient bots, it unleashes them upon the end-target for DDoS purposes.

Malicious content description

Mirai botnet’s root folder – as stated by GitHub’s jgamblin entry – contains four folders and six subfolders. The directories are:

• Dlr – subfolder Release.
• Loader –  subfolders src and Bins
• Mirai – subfolders  Bot, cnc, and Tools
• Scripts – no subfolders.

Dlr, Mirai’s first folder, contains the files needed to implement the so-called echo loader, a webpack loader that is commonly employed to print out to the console the filename handler by another application. Mirai’s 1KB echoloader simulates the wget command (i.e., cmd line utility used to download Internet-hosted resources), being further employed to upload the malicious binary to the (weak) IoT devices.

Note that Mirai only uses echoloader when it can’t upload via the Trivial File Transfer Protocol (TFTP) or wget.  Release, dlr’s subfolder contains the binary files of the echoloader. For the most part, Mirai’s source code what written in C, although several GitHub contributors pointed out that there are traces of Go, Shell, and Objective-C in it.

Mirai, the second folder, hosts the necessary files to deploy the virus, as well as the Command & Control Server and the reporting server. Bot, Mirai’s first subfolder contains the C-written files needed to execute the virus on each discovered host. Cns, Mirai’s second subdirectory hosts Go-written C2 files. Tools, the third Mirai subfolders hosts various utilities which are employed for string encryption and reporting server deployment.

Loader, Mirai’s third folder, host the files needed to deploy and execute the loader server. The Loader folder contains two sub-folders: src and Bins. The src sub-folder hosts C-written files that are necessary to deploy the malicious loader server. Bins, Loader’s second sub-folder contains the malware binaries, as well as the binary folders required to deploy echoloader. The latter component has been compiled for each type of device architecture.

Scripts, Mirai’s fourth folder, contains a set of scripts that are mostly used to support Mirai deployment and for accurate code compilation.

Mirai Botnet Phylogeny

USENIX’s Mirai botnet analysis clues us in Mirai’s phylogeny. The authors wrote:

However, Mirai’s family tree has more ramifications than those covered by USENIX’s paper. In “DDoS-Capable IoT Malwares: Comparative Analysis and Mirai Investigation”, the authors pointed out that Mirai’s DDoS capabilities are hardly unique and can potentially be traced back to Linux.Hydra, the first DDoS-capable IoT malware.

A complete overview of Mirai’s phylogeny can be found in the work of Benjamin Vignau et al. entitled “10 years of IoT Malware: A Feature-Based Taxonomy”. Below, we have reproduced the phylogeny graph enclosed in the above-mentioned work.

Source

Attack methodology. Host infection mechanism.

Attack classification:

• Telnet.
• TCP – SYN, ACK, STOMP.
• UDP- UDP, VSE, DNS, UDPPLAIN.
• GRE – GRE-IP, GRE-ETHERNET.
• APP – HTTP.

Telnet Attack Mechanism

TELNET (Teletype network) is a layer 7 (application), text-oriented communication protocol, utilized to virtually access a machine (i.e., personal computer, IoT device, etc). Telnet provides bidirectional text-based communication between the two, virtually-linked, endpoints. The default TELNET port is TCP 23 but can be changed to anything from 1024 to 32,767. This TCP-spun comm protocol is notoriously unsecure, meaning that anyone monitoring the communication channel can intercept exchanged usernames and passwords in plaintext.

MO: Mirai uses the C-written scanner (located in the Mirai\bot folder) to identify devices communicating over TELNET port 23 (TCP) or port 223 (TCP). Once the device is discovered, the malware will attempt to establish a connection. The IoT will prompt the malware to provide a username and password. Once Mirai registers the prompt, it will brute-force its way into the device using a pre-defined set of username-password pairs. Mirai’s basic attack dictionary includes 46 to 62 common username-password pairs, but the number of pairs increases exponentially as Mirai infects more devices. Here’s an example of what Mirai’s attack dictionary looks like:

Once Mirai has successfully brute-forced its way in the device, it will log the credentials and transmit them to the loader servers using a port defined under the TABLE_SCAN_CB_PORT section, which is a part of the lookup table. The paper “An Extended Analysis of an IoT Malware from a Blackhole Network” provides us with an answer on how the loader discovered and resolved:

The ciphered domain name of the loader domain is hardcoded in table.c. This domain is resolved from the name server of Google that is 8.8.8.8 on port UDP 53. The bots wait for multiple IPs and one is chosen randomly. The decryption key is defined in the file table.c.

Source

To identify more targets (e.g., servers or devices) Mirai will generate random IPv4 addresses. These newly generated addresses will further be confronted against publicly disclosed blacklists and other open-source resources. Raw-socketing the hosts provides Mirai with an answer regarding the state of a TCP connection.  If the TELNET connection is labeled as opened and there’s enough space in the so-called connection table, Mirai will proceed to brute-forcing ports 2323 or 23 in order to gain access to the device.

Antivirus is no longer enough to keep an organization’s systems secure.

Heimdal® DNS Security Solution

Is our next gen proactive DNS-Layer security that stops unknown threats before they reach your endpoints.

• Machine learning powered scans for all incoming online traffic;
• Stops data breaches before sensitive info can be exposed to the outside;
• Advanced DNS, HTTP and HTTPS filtering for all your endpoints;
• Protection against data leakage, APTs, ransomware and exploits;

Try it for FREE today 30-day Free Trial. Offer valid only for companies.

TCP Attack mechanism – SYN flood, ACK flood, TCP STOMP attack

On the TCP side, Mirai utilizes three attack approaches: SYN flood, ACK flood, and TCP STOMP attack.

SYN Flood

Mirai employs SYN flooding in order to overfill a server’s connection table, thus denying access to a legitimate client. In a normal client-server, TCP connection, the information exchange can occur after the two entities complete the three-way handshake: the client sends SYN, the server receives SYN, the server sends SYN and ACK which is SYN+1, the client sends ACK+1, the server receives ACK+1, and the information exchange can commence. In SYN flooding, the threat actor (Mirai) sends SYN requests on all the open ports, usually from an illegitimate IP address. In turn, the server will reply with an SYN-ACK. The attacker will not send back the expected ACK.

Basically, it’s the computer version of a Mexican standoff. The server will wait some time for the reply. Before the connection times out, the attacker will send another SYN and the process starts all over again. The idea behind the attack is to fill the connection table to the brim, in order to deny access to a legitimate user. That’s just one of the ways Mirai DDoSes its target.

ACK flood

Works in a similar fashion to SYN flooding – the attacker will attempt to overflow the server with ACK packets.

TCP STOMP

STOMP is another layer seven, text-based, communication protocol that mediates communication attempts between clients and message brokers. Mirai’s TCP STOMP is very similar to the ACK flood or, better said, a variation on the said attack. Mirai can use the STOMP protocol in order to open up a regular TCP handshake. Once the authentication process is completed, Mirai will forward multiple STOMP requests. Being bombarded with numerous STOMPs, the target has no other choice but to parse all of them. The foreseeable result is that the server would have exhausted most of its resources in an attempt to figure out if the STOMP requests are legit. STOMPs are mostly used against targets that have anti-DDoS features.

UDP attack mechanisms – UDP flood, Valve Source Engine (VSE) attack, DNS attack, UDPPLAIN attack.

Mirai’s UDP attack methodology includes UDP flooding, VSE attack, DNS attack, the ‘lighter’ UPDPLAIN attack.

UDP flooding

UDP attacks are some of the most effective attack vectors due to the protocol’s connectionless and sessionless features. UDP communications are not subject to three-way handshakes as is the case with TCP, meaning it’s far less secure. Conventionally, UDP comms are employed for things such as VoIP, instant chat, video, and audio streaming, etc. Because of the protocol’s properties, UDP attacks (flooding) are hard to counteract. Mirai will use this attack method in order to subdue firewalls, IDSs, or IPSs.

With enough bots, UDP flooding the target with junk-filled UDP packets, the access to resources becomes ever more limited until the system denies access. Some IoT devices, security cameras, in particular, possess autonomic anti-UDP flooding defensive measures – bombarding the IoT devices with packets will result in the device crashing or rebooting. When a device crashes or reboots, the malware gets purged from the system.

Valve Source Engine (VSE) attacks

Mirai might also employ the so-called VSE attack in order to DDoS online gaming servers. VSE attack is a variation of the UDP attack but directed towards gaming servers. To DDoS Valve-owned serves, Mirai will bombard the target with junk TSource Engine queries to the point that it exhausts all of its resources. The result – denial of services. Interestingly enough, the VSE attack corroborates Mirai’s RaaS quality. Thomas Pore of Plixar, one of the many security experts who have dissected Mirai, stated that that the attacks on Source servers could point to motives other than criminal activity (e.g., disgruntled gamers who are willing to pay for Mirai in order to exact revenge, gain a competitive edge or simply to disqualify an opponent).

DNS attacks

Mirai’s IoT bots will attempt to flood a target domain with numerous DNS queries. The purpose of DNS attacks is to DDoS the victim by bombarding the domain with multiple and random subdomain queries. It should be noted that the subdomains are a part of the victim’s domain.

UDPPLAIN Attacks

Despite the name, a UDP Plain attack is far more ‘surgical’ (and effective) compared to UDP flooding. The explanation behind the attack’s effectiveness has very much to do with how the attacking bot ‘chooses’ ports. Instead of flooding all of them, the attacking bot will go for the most used one. Focusing the attack in one direction rather than going all-in will undoubtedly increase the odds of success.

GRE attack mechanisms – GREPIP and GRE-ETHERNET

Mirai’s GRE attack vectors are GRE-IP and GRE-ETHERNET (GRE over Ethernet).

GRE-IP and GRE-ETHERNET Attack method

GRE or Generic Routing Encapsulation is a tunneling protocol employed to encapsulate many layer three protocols inside a PP (point-to-point) link or PM (point-to-multipoint) link. As the name suggests, the Generic Routing Encapsulation protocol operates over IP. GRE-over-IP attacks follow the same pattern as UDP, TCP, or VSE flooding – bombarding the victim with so much junk traffic that it overbears the firewall and other network defenses resulting in a Denial-of-Service.

Complementing the GRE-over-IP attack is GRE-over-Ethernet, a Mirai vector that leverages resources from lower OSI layers such as physical and DLL. Delivering the payload over TEB (Transport Ethernet Bridging), Mirai disguises junk data into L2 or Ethernet frame packets.

APP Layer Attack mechanisms – HTTP

Mirai uses HTTP flooding to bring down servers or websites. As a volumetric attack, Mirai will employ a network of zombified endpoints to send junk HTTP POST or GET requests to the victim. The sudden surge in HTTP traffic will result in Denial-of-Service. HTTP floods are more challenging to mount compared to the methods we’ve discussed so far because the attacker requires a higher understanding of the victim’s website, application, or server. Thus, this type of endeavor is usually preceded by an extensive recon session.

Mitigating IoT Malware

Here is a list of the mitigations available for the Mirai Botnet.

1. Telnet attacks. Mitigation: add access list to the default router. Restrict virtual terminal lines. This guide will show you how to set up the process.
2. SYN Flooding. Mitigation(s): packet filtering, larger backlogs, reducing SYN-Received Timer, SYN cache, and enabling SYN cookies. Refer to IETF’s paper on TCP SYN Flooding mitigation for additional information.
3. ACK and PUSH flooding. Mitigation: configure proxy filters to drop flagged packets.
4. STOMP flooding. Mitigation: identify and filter junk packets before they begin to circulate through the network.
5. UDP floods. Mitigation(s): rate-limiting heuristics to block repetitive IPs and implementing Unicast RPF (Unicast Reverse Path Forwarding).
6. DNS attacks. Mitigation(s): drop anomalous, unsolicited, or unexpected DNS queries, force-resend of DNS client’s credentials, cached responses, advanced control management. You should also opt for a solution capable of scanning the DNS, HTTP, and HTTPS traffic for anomalous activity. Heimdal™ Security’s Threat Prevention Endpoint is capable of scanning inbound and outbound traffic, dropping junk and malicious packets.
7. HTTP flooding. Mitigation(S): Application-Ayer mitigation.

Parting thoughts

It’s very unlikely for the Mirai phenomenon to blow over. If anything, botnets are becoming ever more sophisticated, capable of mounting attacks anywhere in the world. Even more disconcerting is the fact that the creators of Mirai-like botnets have started using defensive mechanisms like honeypotting in order to augment the botnet’s attack capabilities. Mirai’s not only redefining the threatscape but also forcing defenders to rethink the mitigation process. I hope you’ve enjoyed this article. Stay tuned for more malware articles and don’t forget to subscribe to Heimdal™ Security’s newsletter.

Newsletter

If you liked this post, you will enjoy our newsletter.

Get cybersecurity updates you'll actually want to read directly in your inbox.

I agree to have the submitted data processed by Heimdal Security according to the Privacy Policy

Vladimir Unterfingher

Senior PR & Communications Officer

Experienced blogger with a strong focus on technology, currently advancing towards a career in IT Security Analysis. I possess a keen interest in exploring and understanding the intricacies of malware, Advanced Persistent Threats (APTs), and various cybersecurity challenges. My dedication to continuous learning fuels my passion for delving into the complexities of the cyber world.