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

(a) AS Stability

(b) Device Stability

Figure 5: Stability of Measured Properties — From the temporal Pearson correlation of ASes (a) and device labels (b), we found

that our measurements were largely stable despite external factors like DHCP churn. Rapid growth of CWMP-based infections in

late November caused instability but calmed shortly thereafter.

Password

Device Type

123456

ACTi IP Camera

anko

ANKO Products DVR

pass

Axis IP Camera

888888

Dahua DVR

666666

Dahua DVR

vizxv

Dahua IP Camera

7ujMko0vizxv

Dahua IP Camera

7ujMko0admin

Dahua IP Camera

666666

Dahua IP Camera

dreambox

Dreambox TV Receiver

juantech

Guangzhou Juan Optical

xc3511

H.264 Chinese DVR

OxhlwSG8

HiSilicon IP Camera

cat1029

HiSilicon IP Camera

hi3518

HiSilicon IP Camera

klv123

HiSilicon IP Camera

Password

Device Type

klv1234

HiSilicon IP Camera

jvbzd

HiSilicon IP Camera

admin

IPX-DDK Network Camera

system

IQinVision Cameras

meinsm

Mobotix Network Camera

54321

Packet8 VOIP Phone

00000000

Panasonic Printer

realtek

RealTek Routers

1111111

Samsung IP Camera

xmhdipc

Shenzhen Anran Camera

smcadmin

SMC Routers

ikwb

Toshiba Network Camera

ubnt

Ubiquiti AirOS Router

supervisor

VideoIQ

Vivotek IP Camera

Password

Device Type

1111

Xerox Printer

Zte521

ZTE Router

1234

Unknown

12345

Unknown

admin1234

Unknown

default

Unknown

fucker

Unknown

guest

Unknown

password

Unknown

root

Unknown

service

Unknown

support

Unknown

tech

Unknown

user

Unknown

zlxx.

Unknown

Table 5: Default Passwords — The 09/30/2016 Mirai source release included 46 unique passwords, some of which were traceable to

a device vendor and device type. Mirai primarily targeted IP cameras, DVRs, and consumer routers.

about underlying software (e.g., “postgres”) and not an as-

sociated device. The devices we identified were primarily

network-attached storage appliances, home routers, cam-

eras, DVRs, printers, and TV receivers made by dozens

of different manufacturers (Table 5).

Mirai’s intended targets do not necessarily reflect the

breakdown of infected devices in the wild. We leveraged

the device banners collected by Censys to determine the

models and manufacturers of infected devices. Our results

across all five protocols indicate that security cameras,

DVRs, and consumer routers represent the majority of

Mirai infections (Table 6). The manufacturers responsi-

ble for the most infected devices we could identify are:

Dahua, Huawei, ZTE, Cisco, ZyXEL, and MikroTik (Ta-

ble 7).

We note that these results deviate from initial media

reports, which stated that Mirai was predominantly com-

posed of DVRs and cameras [34,53,60]. This is likely due

to the evolution of the Mirai malware over time, which

changed the composition of infected devices. Looking at

the longitudinal Pearson correlation of top device vendors,

we observe modest stability with the exception of two

event periods: the rapid growth phase in mid-September

2016 and the onset of CWMP in late November 2016

(Figure 5b). During the rapid growth, the emergence of

consumer routers manufactured by ASUS, Netgear, and

Zhone supplanted D-Link routers and Controlbr DVRs

in the top 20 devices. Dahua, Huawei, ZyXEL, and ZTE

devices consistently remained in the Top 20.

Our data indicates that some of the world’s top man-

ufacturers of consumer electronics lacked sufficient se-

curity practices to mitigate threats like Mirai, and these

manufacturers will play a key part in ameliorating vul-

nerability. Unfortunately, as discussed in the previous

section, the menagerie of devices spanned both countries

and legal jurisdictions, exacerbating the challenge of co-

ordinating technical fixes and promulgating new policy to

safeguard consumers in the future.

1100    26th USENIX Security Symposium

USENIX Association

---

CWMP (28.30%)

Telnet (26.44%)

HTTPS (19.13%)

FTP (17.82%)

SSH (8.31%)

Router

4.7%

Router

17.4%

Camera/DVR

36.8%

Router

49.5%

Router

4.0%

Camera/DVR

9.4%

Router

6.3%

Storage

1.0%

Storage

0.2%

Storage

0.2%

Camera/DVR

0.4%

Firewall

0.2%

Firewall

0.1%

Media

0.1%

Security

0.1%

Other

0.0%

Other

0.1%

Other

0.2%

Other

0.0%

Other

0.0%

Unknown

95.3%

Unknown

73.1%

Unknown

56.4%

Unknown

49.0%

Unknown

95.6%

Table 6: Top Mirai Device Types — We list the top types of infected devices labeled by active scanning, as a fraction of Mirai

banners found in Censys. Our data suggests that consumer routers, cameras, and DVRs were the most prevalent identifiable devices.

CWMP (28.30%)

Telnet (26.44%)

HTTPS (19.13%)

FTP (17.82%)

SSH (8.31%)

Huawei

3.6%

Dahua

9.1%

Dahua

36.4%

D-Link

37.9%

MikroTik

3.4%

ZTE

1.0%

ZTE

6.7%

MultiTech

26.8%

MikroTik

2.5%

Phicomm

1.2%

ZTE

4.3%

ipTIME

1.3%

ZyXEL

2.9%

Huawei

1.6%

Other

2.3%

Other

3.3%

Other

7.3%

Other

3.8%

Other

1.8%

Unknown

93.1%

Unknown

79.6%

Unknown

20.6%

Unknown

54.8%

Unknown

94.8%

Table 7: Top Mirai Device Vendors — We list the top vendors of infected Mirai devices labeled by active scanning, as a fraction

of Mirai banners found by Censys. The top vendors across all protocols were primarily camera, router, and embedded device

manufacturers.

4.5

Device Bandwidth

As an additional confirmation of embedded composition,

we examined the bandwidth of infected devices as gleaned

from their scan rate, which is not artificially rate-limited

by the original source code. Starting with the observed

scanning rate and volume on our network telescope, we

extrapolate across the entire IPv4 Internet by factoring in

the size of our network telescope (4.7 million IPs) and

the size of Mirai’s default IP blacklist (340.2 million IPs).

We found about half of the Mirai bots that scanned our

network telescope sent fewer than 10,000 scan packets

(Figure 6). We further note that the majority of bots

scanned at an estimated rate below 250 bytes per second.

We note however this is a strict underestimate, as Mirai

may have interrupted scanning to process C2 commands

and to conduct brute force login attempts. In contrast,

SQL Slammer scanned at 1.5 megabytes/second, about

6000 times faster [68], and the Witty worm scanned even

faster at 3 megabytes/second [81]. This additionally hints

that Mirai was primarily powered by devices with limited

computational capacity and/or located in regions with low

bandwidth [3].

5

Ownership and Evolution

After the public release of Mirai’s source code in late

September 2016, multiple competing variants of the bot-

net emerged. We analyze the C2 infrastructure behind

Figure 6: Network Capacity Distribution — Scan duration,

probes, and bandwidth were extrapolated to reflect scanning

network capacity across the full IPv4 Internet. A majority of

probes scan below 250 Bps for over 2,700 seconds.

Mirai in order to uncover the relationships between strains,

their relative sizes, and the evolution of their capabilities.

5.1

Ownership

In order to identify the structure of Mirai command and

control servers, we turned to active and passive DNS data,

which we used to cluster C2 IPs and domains based on

shared network infrastructure. Seeding DNS expansion

with the two IPs and 67 domains that we collected by

reverse engineering Mirai binaries, we identified 33 inde-

pendent C2 clusters that shared no infrastructure. These

varied from a single host to the largest cluster, which con-

tained 112 C2 domains and 92 IP addresses. We show

the connectivity of the top six clusters by number of C2

domains in Figure 7. The lack of shared infrastructure be-

tween these clusters lends credence to the idea that there

USENIX Association

26th USENIX Security Symposium    1101

---