Understanding the Mirai Botnet. This 2017 study by Manos Antonakakis and colleagues appeared at the USENIX Security Symposium. They reconstructed how Mirai discovered devices, built an infection population and received attack instructions. The episode focuses on that machinery, how the team measured it, what the evidence established and where it stops.

Mirai rapidly searched pseudorandom IPv4 addresses for exposed Telnet remote-login services and tried a hard-coded list of 62 username and password pairs. When one worked, Mirai reported the successful login and loaded malware built for the device’s processor architecture.

The operational questions are concrete: how did that login-guessing loop become a large infection population, how did operators and competing strains change it, and what attack instructions followed? Connecting those pieces helps defenders separate the initial access path, the control infrastructure and the victim-facing activity. The result is a reconstruction of the system rather than merely a count of observed addresses.

The measurements ran from August through the following February. The researchers combined a network telescope covering 4.7 million Internet addresses with Internet-wide scans and decoy Telnet systems. They also used malware samples, passive and active domain-name-system data, command-and-control observations and victim traces.

During its first measured day, the outbreak infected about 64,500 devices. The estimated population later settled in the hundreds of thousands and briefly approached 600,000. Infections were geographically concentrated, while the device mix reflected both manufacturer market share and security decisions. A later variant began scanning for a CWMP exploit and caused another spike; rapid operator patching then pushed affected networks back toward their earlier distribution.

Across the malware samples, the researchers found multiple credential dictionaries, hundreds of unique passwords and competing strains. Releasing Mirai’s source code accelerated that competition, although its evolution had already begun. The researchers also observed more than 15,000 DDoS, which stands for distributed denial-of-service, attack commands against thousands of victims across many countries. One attack on Krebs on Security reached 623 Gbps. Addresses associated with the Dyn incident substantially overlapped Mirai scanners, but other hosts may also have participated.

These measurements were extensive but incomplete. They captured parts of Mirai’s operation that were visible from the Internet, along with collected malware and selected victim traces—not every infected device, operator or consequence. Internet addresses can be reassigned over time, and the researchers could not always identify devices precisely. The resulting counts therefore contain uncertainty and cannot establish actual device ownership or the full harm caused by Mirai.

For device makers and security architects, the recommendations fall into a few practical themes. Reduce the exposed attack surface by switching off unneeded management services, restricting software privileges and using memory protections that make code locations harder to predict. Maintain devices through secure automatic updates with rollback, clear device and firmware identification, and explicit support lifecycles. Network providers and response teams can strengthen that work by improving notifications about vulnerable equipment. These are proposed design and policy responses, not measured outcomes from the observational work.

The plain-language takeaway is that Mirai becomes clearer when its infection mechanics, population changes, competing strains and attack instructions are reconstructed together. That evidence can help device-security teams, network defenders and incident responders prioritize closed-by-default management services and supported update lifecycles. But the population estimates are not a complete census, proof of who owned each device or a measure of every resulting harm.