This paper is included in the Proceedings of the 26th usenix security Symposium August 16–18, 2017 • Vancouver, bc, Canada

08/01/2016 

Mirai surfaces

09/18/2016 

OVH attacks

begin

09/30/2016 

Source code released

10/21/2016 

Dyn attacks

10/31/2016 

Liberia Lonestar

attacks begin

01/18/2017 

Mirai author 

identified

02/23/2017 

Deutsche Telekom 

attacker arrested

11/26/2016 

Deutsche Telekom

CWMP exploit

Sept

Oct

Nov

Dec

Jan

Feb

09/21/2016 

Krebs on Security 

peak attack

Figure 1: Mirai Timeline — Major attacks (red), exploits (yellow), and events (black) related to the Mirai botnet.

on Security, OVH, and Dyn), but also numerous game

servers, telecoms, anti-DDoS providers, and other seem-

ingly unrelated sites. While DDoS was Mirai’s flavor

of abuse, future strains of IoT malware could leverage

access to compromised routers for ad fraud, cameras for

extortion, network attached storage for bitcoin mining,

or any number of applications. Mirai’s reach extended

across borders and legal jurisdictions, and it infected de-

vices with little infrastructure to effectively apply security

patches. This made defending against it a daunting task.

Finally, we look beyond Mirai to explore the security

posture of the IoT landscape. We find that the absence of

security best practices — established in response to desk-

top worms and malware over the last two decades — has

created an IoT substrate ripe for exploitation. However,

this space also presents unique, nuanced challenges in the

realm of automatic updates, end-of-life, and consumer no-

tifications. Without improved defenses, IoT-based attacks

are likely to remain a potent adversarial technique as bot-

net variants continue to evolve and discover new niches

to infect. In light of this, Mirai seems aptly named — it is

Japanese for “the future.”

2

The Mirai Botnet

Mirai is a worm-like family of malware that infected

IoT devices and corralled them into a DDoS botnet. We

provide a brief timeline of Mirai’s emergence and discuss

its structure and propagation.

Timeline of events

Reports of Mirai appeared as

early as August 31, 2016 [89], though it was not until

mid-September, 2016 that Mirai grabbed headlines with

massive DDoS attacks targeting Krebs on Security [46]

and OVH [74] (Figure 1). Several additional high-profile

attacks later targeted DNS provider Dyn [36] and

Lonestar Cell, a Liberian telecom [45]. In early 2017, the

actors surrounding Mirai came to light as the Mirai author

was identified [49]. Throughout our study, we corroborate

our measurement findings with these media reports and

expand on the public information surrounding Mirai.

Another significant event in this timeline is the public

release of Mirai’s source code on hackforums.net [4]. We

rely on this code to develop our measurement method-

ology (Section 3). Furthermore, as we detail later (Sec-

tion 5), this source code release led to the proliferation

of Mirai variants with competing operators. One notable

variant added support for a router exploit through CPE

WAN Management Protocol (CWMP), an HTTP-based

protocol that enables auto-configuration and remote man-

agement of home routers, modems, and other customer-

premises equipment (CPE) [15]. This exploit led to an out-

age at Deutsche Telekom late November 2016 [47], with

the suspected attacker later arrested in February 2017 [13].

In this work, we track Mirai’s variants and examine how

they influenced Mirai’s propagation.

Botnet structure & propagation

We provide a sum-

mary of Mirai’s operation in Figure 2, as gleaned from

the released source code. Mirai spread by first entering

a rapid scanning phase (

x) where it asynchronously and

“statelessly” sent TCP SYN probes to pseudorandom IPv4

addresses, excluding those in a hard-coded IP blacklist, on

Telnet TCP ports 23 and 2323 (hereafter denoted TCP/23

and TCP/2323). If Mirai identifies a potential victim, it en-

tered into a brute-force login phase in which it attempted

to establish a Telnet connection using 10 username and

password pairs selected randomly from a pre-configured

list of 62 credentials. At the first successful login, Mirai

sent the victim IP and associated credentials to a hard-

coded report server (

y).

A separate loader program (

z) asynchronously in-

fected these vulnerable devices by logging in, determining

the underlying system environment, and finally, down-

loading and executing architecture-specific malware (

{).

After a successful infection, Mirai attempted to conceal

its presence by deleting the downloaded binary and ob-

fuscating its process name in a pseudorandom alphanu-

meric string. As a consequence, Mirai infections did not

persist across system reboots. In order to fortify itself,

the malware additionally killed other processes bound

to TCP/22 or TCP/23, as well as processes associated

with competing infections, including other Mirai vari-

ants, .anime [25], and Qbot [72]. At this point, the bot

1094    26th USENIX Security Symposium

USENIX Association

---

Command 

& Control 

Loader

Report 

Server

Devices

Infrastructure

Attacker

DDoS Target

Send command

Dispatch

 

Attack

 

Report

Scan

Load

 

Relay

Victim

Bots

Figure 2: Mirai Operation — Mirai bots scan the IPv4 address

space for devices that run telnet or SSH, and attempt to log in us-

ing a hardcoded dictionary of IoT credentials. Once successful,

the bot sends the victim IP address and associated credentials to

a report server, which asynchronously triggers a loader to infect

the device. Infected hosts scan for additional victims and accept

DDoS commands from a command and control (C2) server.

listened for attack commands from the command and con-

trol server (C2) while simultaneously scanning for new

victims.

Malware phylogeny

While not directly related to

our study, the Mirai family represents an evolution of

BASHLITE (otherwise known as LizardStresser, Torlus,

Gafgyt), a DDoS malware family that infected Linux

devices by brute forcing default credentials [86]. BASH-

LITE relied on six generic usernames and 14 generic pass-

words, while the released Mirai code used a dictionary

of 62 username/password pairs that largely subsumed

BASHLITE’s set and added credentials specific to con-

sumer routers and IoT devices. In contrast to BASHLITE,

Mirai additionally employed a fast, stateless scanning

module that allowed it to more efficiently identify vulner-

able devices.

3

Methodology

Our study of Mirai leverages a variety of network vantage

points: a large, passive network telescope, Internet-wide

scanning, active Telnet honeypots, logs of C2 attack

commands, passive DNS traffic, and logs from DDoS

attack targets. In this section, we discuss our data sources

and the role they play in our analysis. We provide a

high-level summary in Table 1.

3.1

Network Telescope

Mirai’s indiscriminate, rapid scanning strategy lends it-

self to tracking the botnet’s propagation to new hosts. We

monitored all network requests to a network telescope [9]

composed of 4.7 million IP address operated by Merit

Network over a seven month period from July 18, 2016

to February 28, 2017. On average, the network telescope

received 1.1 million packets from 269,000 IP addresses

per minute during this period. To distinguish Mirai traffic

from background radiation [94] and other scanning ac-

tivity, we uniquely fingerprinted Mirai probes based on

an artifact of Mirai’s stateless scanning whereby every

probe has a TCP sequence number — normally a random

32-bit integer — equal to the destination IP address. The

likelihood of this occurring incidentally is 1/2

32

, and we

would expect to see roughly 86 packets demonstrating

this pattern in our entire dataset. In stark contrast, we

observed 116.2 billion Mirai probes from 55.4 million IP

addresses. Prior to the emergence of Mirai, we observed

only three IPs that perform scans with this fingerprint.

Two of the IP addresses generated five packets; two on

TCP/80 and three on TCP/1002. The third IP address be-

longs to Team Cymru [1], who conducts regular TCP/443

scans.

We caution that the raw count of IP addresses seen

scanning over time is a poor metric of botnet size due to

DHCP churn [87]. To account for this, we tracked the size

of the botnet by considering the number of hosts actively

“scanning” at the start of every hour. We detected scans

using the methodology presented by Durumeric et al. [23],

in which we group packets from a single IP address in

a temporal window into logical scans. We specifically

identified scans that targeted the IPv4 address space at an

estimated rate of at least five packets per second, expiring

inactive scans after 20 minutes. We geolocated IPs using

Maxmind [61].

3.2

Active Scanning

While Mirai is widely considered an IoT botnet, there

has been little comprehensive analysis of infected devices

over the botnet’s entire lifetime. In order to determine the

manufacturer and model of devices infected with Mirai,

we leveraged Censys [22], which actively scans the IPv4

space and aggregates application layer data about hosts on

the Internet. We focused our analysis on scans of HTTPS,

FTP, SSH, Telnet, and CWMP between July 19, 2016 and

February 28, 2017.

A number of challenges make accurate device labeling

difficult. First, Mirai immediately disables common out-

ward facing services (e.g., HTTP) upon infection, which

prevents infected devices from being scanned. Second,

Censys scans often take more than 24 hours to complete,

USENIX Association

26th USENIX Security Symposium    1095

---