Case Study 31.1: The Mirai Botnet — IoT Devices as DDoS Weapons

When Security Cameras Took Down the Internet

Background

On October 21, 2016, large portions of the internet became unreachable for millions of users across the United States and Europe. Twitter, Netflix, Reddit, Spotify, GitHub, PayPal, and dozens of other major websites went offline or experienced severe degradation. The cause was not a sophisticated nation-state cyberattack or a critical software vulnerability — it was hundreds of thousands of compromised IoT devices, primarily consumer security cameras and digital video recorders, that had been recruited into a massive botnet and directed to overwhelm the internet infrastructure provider Dyn (now Oracle DCS) with a distributed denial-of-service (DDoS) attack.

The Mirai botnet, as it was named, represented a watershed moment in cybersecurity. It demonstrated that the billions of insecure IoT devices deployed worldwide were not just individually vulnerable — they were collectively a weapon capable of disrupting critical internet infrastructure. Mirai fundamentally changed how the security industry, regulators, and manufacturers think about IoT security.

The Technical Architecture

Scanning and Infection. Mirai's infection mechanism was remarkably simple. The malware scanned the internet for IoT devices that had Telnet (port 23) or SSH (port 22) accessible, then attempted to log in using a table of 62 common factory-default username and password combinations. These credentials were hardcoded into the malware and included combinations like:

These were not generic password guesses — they were the actual factory-default credentials for specific manufacturers' IP cameras, DVRs, and routers. The credential list reflected deep knowledge of the IoT device landscape.

Exploitation and Persistence. Once Mirai successfully logged into a device, it: 1. Downloaded a platform-specific payload (supporting ARM, MIPS, x86, and other architectures) 2. Killed competing malware processes (to claim exclusive control) 3. Blocked Telnet and SSH access (to prevent the device from being taken over by competitors or cleaned by administrators) 4. Began scanning for additional vulnerable devices 5. Awaited commands from the command-and-control (C2) infrastructure

Mirai's scanning was aggressive — each infected device generated significant network traffic as it scanned random IP addresses for additional targets. This scanning behavior was one of the early indicators that security researchers used to identify and track the botnet.

Command and Control. Mirai used a centralized C2 architecture. Infected devices connected to C2 servers and awaited commands, primarily DDoS attack instructions. The botnet supported multiple DDoS attack types: - UDP floods - TCP SYN floods - ACK floods - GRE protocol floods - DNS query floods - HTTP GET/POST floods

The Dyn Attack. On October 21, 2016, an estimated 100,000 Mirai-infected devices launched a coordinated DDoS attack against Dyn, a major DNS service provider. Because Dyn provided DNS resolution for many of the internet's most popular websites, overwhelming Dyn's infrastructure effectively made those websites unreachable. The attack came in multiple waves throughout the day, with traffic volumes estimated at 1.2 Tbps — among the largest DDoS attacks ever recorded at that time.

Root Cause Analysis

Default Credentials. The fundamental vulnerability was painfully simple: IoT devices shipped with known default credentials that users rarely changed. Many devices did not even provide a mechanism to change the credentials, or the credentials were hardcoded into the firmware and could not be modified.

Telnet/SSH Exposure. These management interfaces were accessible over the internet by default. Devices were designed for ease of setup (connect to the network and immediately accessible), not security. Universal Plug and Play (UPnP) in home routers often exposed these ports to the internet without the user's knowledge.

Lack of Update Mechanisms. Most affected devices had no practical firmware update mechanism. Even when manufacturers released patches, consumers had no easy way to apply them. Many devices were deployed in set-and-forget configurations — security cameras mounted on walls, DVRs tucked in closets — where they would never receive attention again.

Monoculture of Insecurity. A small number of OEM manufacturers (Original Equipment Manufacturers) produced the hardware and firmware used across hundreds of different brands. A single firmware vulnerability affected products sold under dozens of brand names, creating a massive monoculture of identical insecurity.

ISP Negligence. Internet Service Providers (ISPs) could have detected and mitigated the outbound scanning and attack traffic from infected devices on their networks, but most lacked the monitoring capabilities or economic incentive to do so.

The Perpetrators

In December 2017, three young Americans — Paras Jha (21), Josiah White (20), and Dalton Norman (21) — pleaded guilty to creating and operating the Mirai botnet. Their original motive was not to attack internet infrastructure; they created Mirai to gain an advantage in the competitive world of Minecraft server hosting. By launching DDoS attacks against competing Minecraft servers, they could drive players to their own servers and increase revenue.

The Dyn attack was carried out by others who had obtained the Mirai source code. In September 2016, before the Dyn attack, the Mirai source code was released publicly on the HackForums website by a user called "Anna-senpai" (believed to be Paras Jha). This public release led to multiple Mirai variants being created and deployed by different groups, each launching their own attacks.

Broader Impact and Aftermath

Internet Infrastructure Vulnerability. Mirai demonstrated that the internet's infrastructure has concentrated points of failure. Dyn's role as a DNS provider for hundreds of major websites meant that a single-target attack could have cascading effects across the internet.

IoT Security Legislation. Mirai directly influenced IoT security regulation: - The U.S. IoT Cybersecurity Improvement Act (2020) established security requirements for IoT devices purchased by the federal government - California's SB-327 (2018) required IoT devices sold in California to have unique preprogrammed passwords or require users to set a password before first use - The UK Product Security and Telecommunications Infrastructure Act (PSTI, 2024) banned default passwords, required vulnerability disclosure programs, and mandated transparency about security update periods - The EU Cyber Resilience Act (2024) imposed comprehensive cybersecurity requirements on all connected products sold in the EU

ISP-Level Mitigation. Some ISPs implemented programs to detect and quarantine infected IoT devices on their networks, notifying customers and restricting internet access for infected devices until they were remediated.

Manufacturer Response. Major IoT manufacturers began implementing unique default passwords, mandatory password changes during setup, and automatic firmware updates. However, the billions of devices already deployed with insecure configurations remain vulnerable.

Lessons for Ethical Hackers

1. Default credentials are still the number one IoT vulnerability. When testing IoT devices, always check for default and common credentials first. Maintain an up-to-date database of manufacturer default credentials.

2. Network scanning reveals the IoT attack surface. Scanning for Telnet (port 23), SSH (port 22), and common IoT management ports on a network quickly reveals the scale of the vulnerable device population. Tools like Shodan and Censys provide internet-scale visibility.

3. Firmware analysis reveals credential storage. Extracting and analyzing firmware reveals how credentials are stored — hardcoded in binaries, stored in configuration files, or generated from device characteristics. Each approach has different exploitation and remediation implications.

4. IoT security testing must consider collective risk. A single insecure camera is a minor finding. A thousand insecure cameras on a hospital network (like MedSecure's) is a catastrophic risk — not just because each device is vulnerable, but because they collectively represent a massive DDoS capability and lateral movement surface.

5. Post-deployment security is the real challenge. Finding vulnerabilities in IoT devices is relatively straightforward. The hard problem is remediation — devices with no update mechanism, devices in inaccessible locations, devices whose users have no security awareness. Assessment recommendations must account for these realities.

Discussion Questions

1. Mirai exploited devices with default passwords — a vulnerability that has been known for decades. Why has the IoT industry been so slow to address this fundamental issue? What economic and market dynamics contribute to this failure?

2. The Mirai source code was publicly released, enabling anyone to create their own variant. Debate the ethics of publishing offensive tool source code. Does public availability of attack tools improve or harm overall security?

3. The Dyn attack affected websites that had no direct relationship with the IoT devices used in the attack. How should liability be allocated in such scenarios — among device manufacturers, device owners, ISPs, or the DNS provider?

4. California's SB-327 and the UK PSTI Act require unique passwords on IoT devices. Is regulation the most effective approach to IoT security, or are there better alternatives (market incentives, security ratings, insurance requirements)?

5. If MedSecure's hospital network contained 500 insecure IP cameras (installed by a facilities contractor), what should the penetration testing team recommend? Consider the practical challenges of remediating hundreds of devices with no update mechanism.

Timeline

References

• Krebs, Brian. "Who is Anna-Senpai, the Mirai Worm Author?" KrebsOnSecurity, January 18, 2017.
• Antonakakis, Manos, et al. "Understanding the Mirai Botnet." USENIX Security Symposium, 2017.
• U.S. Department of Justice. "Three Admit Roles in Creating and Operating Mirai Botnet." Press Release, December 13, 2017.
• Kolias, Constantinos, et al. "DDoS in the IoT: Mirai and Other Botnets." IEEE Computer, 2017.
• Dyn. "Dyn Statement on 10/21/2016 DDoS Attack." October 2016.
• Cloudflare. "Inside the Infamous Mirai IoT Botnet: A Retrospective Analysis." Blog, 2018.