On October 21, 2016, the Mirai botnet directed approximately 1.2 terabits per second of traffic at Dyn, a DNS provider whose infrastructure supported a significant fraction of the US internet's DNS resolution. Twitter, Reddit, Spotify, GitHub, PayPal, and dozens of other major services became unreachable for large parts of the US East Coast for most of a day. Mirai's source code had been published online three weeks earlier by its creator, and the attack that took down Dyn was not even the original operator's work - it was launched by copycats using the public code.
Mirai was not sophisticated in concept. It scanned the internet for IoT devices - routers, IP cameras, DVRs - and logged in to them using a hardcoded list of 61 factory default username/password combinations. Devices that hadn't had their default credentials changed were immediately enlisted in the botnet. The power of Mirai was purely the scale of the IoT device population: hundreds of millions of internet-connected devices with default credentials and no mechanism for the owners to know or care about security. The Dyn attack demonstrated that the internet's fundamental infrastructure could be disrupted by assembling an army of webcams.
The Creator and the Release
Mirai was created by Paras Jha, a Rutgers University student who used it initially to knock competing Minecraft servers offline - a DDoS-for-hire service targeting the competitive Minecraft hosting market. Jha worked with two associates, Josiah White and Dalton Norman, under the handle "Anna-senpai." They used Mirai to attack ProxyPipe, a DDoS protection service, and various Minecraft servers, establishing a protection racket in which they would offer to stop attacking a server if the operator purchased their DDoS protection service.
As Mirai grew and Brian Krebs published an investigation into DDoS-for-hire services, Jha became concerned about identification. In late September 2016, Anna-senpai posted Mirai's source code to Hackforums - a deliberate release intended to create plausible deniability by flooding the landscape with Mirai variants and copycat operators. The plan partially worked in the short term: the subsequent attacks, including the Dyn attack, were conducted by operators who had taken the public code and built their own botnets. Jha, White, and Norman pleaded guilty in December 2017 after being identified through a joint FBI/DHS investigation.
The Technical Architecture
Mirai's scanning was relentless and distributed. Each infected device ran the scanner component, which generated random IP addresses and attempted telnet connections on ports 23 and 2323. When a device responded to telnet, Mirai attempted all 61 credential pairs from its hardcoded list. Successful logins reported back to a loader server, which executed a shell command sequence to download and execute the Mirai bot binary for the target device's architecture (Mirai supported multiple CPU architectures common in IoT devices: x86, x86-64, ARM, MIPS, PPC, SH4, SPARC, ARC).
The bot binary had two main functions: maintain connection to the C2 server and wait for attack instructions, and run the scanner to find and report new vulnerable devices. It also took steps to prevent competitors: Mirai killed other known botnet processes on infected devices and blocked telnet access from other scanners to prevent the device from being taken over again. The C2 protocol used a custom binary format over TCP, with C2 servers behind load balancers to resist takedown.
Attack modules supported multiple DDoS techniques: HTTP floods, SYN floods, ACK floods, DNS floods, UDP floods, and several application-layer attacks. The Dyn attack used primarily DNS query floods - legitimate-looking DNS queries at massive scale that exhausted Dyn's query processing capacity. The attack traffic was distributed across hundreds of thousands of source IPs (the infected devices), making simple IP-based blocking ineffective.
The Dyn Attack and Its Scope
Dyn provided DNS resolution infrastructure for many major internet properties. When Dyn's infrastructure became unable to process queries, users trying to reach Twitter, Reddit, Spotify, and other services received DNS failures rather than IP addresses. The services themselves were unaffected - their servers were up - but users could not reach them because DNS, the phone book of the internet, was not answering.
The attack came in three waves on October 21. The first wave began around 7 AM Eastern and lasted approximately two hours. Dyn mitigated it. A second wave began around noon and was larger. A third wave came in the afternoon. The total disruption lasted most of the business day for users in eastern North America; European users were largely unaffected because they used different DNS infrastructure.
The attack demonstrated a vulnerability in the internet's DNS architecture: concentration of DNS resolution for many major properties in a small number of providers creates a single point of failure. The post-Dyn response included both DNS provider diversification (major internet properties began using multiple DNS providers simultaneously so that any single provider's outage would not take them offline) and renewed attention to the fundamental problem of IoT device security.
The Broader IoT Security Problem
Mirai's success rested entirely on the industry practice of shipping IoT devices with default credentials and no mechanism to force credential changes. Devices from multiple major manufacturers - Dahua, Hikvision, and dozens of others - shipped with factory default usernames and passwords documented in their manuals and unchanged by the vast majority of buyers who simply plugged them in and connected them to the internet.
The economic incentives did not favor security. IoT devices are sold on price in highly competitive markets. Security engineering costs money. Buyers do not see or evaluate security in their purchasing decisions. The consequences of insecurity fall on third parties (targets of DDoS attacks) rather than the manufacturer or device owner. This is a classic negative externality: the cost of bad IoT security is externalized to the internet at large, while the cost of good security would be internalized by manufacturers competing on price.
Legislative responses took years to develop. California's IoT Security Law (SB-327), effective 2020, required manufacturers selling IoT devices in California to include a "reasonable security feature" and prohibited default passwords shared across multiple devices - each device must have a unique default password, or require users to set one before use. The UK followed with the Product Security and Telecommunications Infrastructure Act. These requirements addressed the default credential problem but left many other IoT security issues unaddressed.
Mirai's Legacy: Derivative Botnets
The public release of Mirai's source code created an ecosystem of derivative botnets. Satori, JenX, Masuta, OMG, Wicked, and dozens of other variants modified Mirai's credential list, added new exploit modules, changed the C2 protocol, or targeted specific device types. Some added cryptocurrency mining payloads. Others were used for click fraud, spam, or proxy services rather than DDoS.
Meris, a 2021 botnet that generated records of 21.8 million requests per second in attacks against Yandex and Cloudflare customers, used MikroTik routers rather than consumer IoT devices and exploited a MikroTik vulnerability rather than default credentials - demonstrating that the Mirai model of network infrastructure exploitation had expanded beyond the initial consumer camera/DVR target base to enterprise-grade network equipment.
The fundamental structural problem - hundreds of millions of internet-connected devices with persistent security vulnerabilities and no patching mechanism - has not been resolved. IoT device populations continue to grow, security varies widely across manufacturers, patching rates are low, and many devices will operate for years or decades without firmware updates. Mirai demonstrated the DDoS potential of this population in 2016; future exploitation of the same population for different purposes (ransomware staging, critical infrastructure proxies, information collection) represents a persistent threat that manufacturer and legislative responses have addressed only partially.