The Mirai Botnet: How It Changed IoT Security Forever

The Creators

Mirai was not built by a nation-state intelligence agency or a sophisticated criminal syndicate. It was built by three college students. Paras Jha, Josiah White, and Dalton Norman created Mirai in 2016 while running a DDoS mitigation business - and simultaneously using DDoS attacks to drive customers to their service.

Jha, a Rutgers University computer science student, had previously been involved in DDoS attacks against the university's network. White handled the scanning infrastructure that found vulnerable devices. Norman identified and integrated new exploits as they became available. Together, they built one of the most destructive pieces of malware in internet history.

The name "Mirai" is Japanese for "future" - an unintentionally fitting name for a botnet that would define the future of IoT security concerns.

How Mirai Scanned and Recruited

Mirai's scanning engine was brutally simple. It generated random IP addresses and attempted to connect via Telnet on ports 23 and 2323. When it found an open Telnet port, it tried a hardcoded list of 62 default username and password combinations. If any combination worked, the device was infected.

graph TD
    subgraph "Mirai Infection Cycle"
        A[Mirai Bot] --> B[Generate Random IP]
        B --> C[TCP SYN to Port 23/2323]
        C --> D{Port Open?}
        D -->|No| B
        D -->|Yes| E[Try 62 Default Credentials]
        E --> F{Login Success?}
        F -->|No| B
        F -->|Yes| G[Report to C2 Server]
        G --> H[Loader Downloads Payload]
        H --> I[New Bot Starts Scanning]
        I --> B
    end

Mirai infection cycle - each new bot immediately starts scanning for more victims

The scanning was aggressive. At its peak, Mirai bots collectively scanned the entire IPv4 address space approximately every 10 minutes. The malware ran entirely in memory - it never wrote to disk on the infected device. This meant that a simple reboot would clear the infection, but since most IoT devices are never rebooted, this was not a practical limitation.

Once infected, a device performed two functions: it scanned for new victims, and it waited for DDoS attack commands from the command-and-control (C2) server. The malware also killed other known botnet processes on the device, ensuring it had exclusive control.

The Credential Table

The 62 credential pairs in Mirai's source code read like an indictment of the IoT industry. They included factory defaults from IP cameras, DVRs, routers, and other embedded devices. Combinations like root/root, admin/admin, root/123456, and admin/password were common. Device-specific defaults appeared too: root/xc3511 (Xiongmai cameras), root/vizxv (Dahua DVRs), and root/54321 (various Chinese manufacturers).

These credentials were not obscure. They were documented in product manuals and had been publicly known for years. Many devices had no mechanism to force a password change during initial setup. Some had hardcoded credentials that could not be changed at all - the Telnet service was baked into the firmware with a fixed password.

The scale was staggering. Researchers estimated that hundreds of thousands of devices on the public internet were accessible with these default credentials. Mirai did not need sophisticated exploits. It needed a list of passwords and patience.

The Dyn DDoS Attack

On October 21, 2016, Mirai launched a DDoS attack against Dyn, a major DNS infrastructure provider. The attack peaked at approximately 1.2 Tbps - an unprecedented volume at the time. Because Dyn provided DNS resolution for thousands of major websites, the attack caused widespread outages across the internet.

graph TD
    subgraph "Dyn DDoS Impact Chain"
        A[Mirai C2 Server] --> B[Command: Attack Dyn DNS]
        B --> C[100,000+ IoT Bots]
        C --> D[1.2 Tbps Traffic Flood]
        D --> E[Dyn DNS Servers Overwhelmed]
        E --> F[DNS Resolution Fails]
        F --> G[Twitter Unreachable]
        F --> H[Netflix Unreachable]
        F --> I[Reddit Unreachable]
        F --> J[GitHub Unreachable]
        F --> K[CNN Unreachable]
        F --> L[Spotify Unreachable]
    end

The Dyn DDoS cascading impact - one DNS provider down meant dozens of major sites went offline

Twitter, Netflix, Reddit, GitHub, CNN, Spotify, Airbnb, and dozens of other sites became unreachable for users primarily on the US East Coast, with intermittent outages worldwide. The attack came in three waves throughout the day, each requiring Dyn's engineers to implement new mitigations.

The attack demonstrated a critical dependency: much of the internet relies on a small number of DNS providers. Taking out one provider could cascade into widespread outages affecting services that had no direct relationship to the target.

Code Release and Mutation

On September 30, 2016 - three weeks before the Dyn attack - a user named "Anna-senpai" released the complete Mirai source code on the HackForums website. This was likely Paras Jha attempting to create plausible deniability by making the code widely available before the FBI investigation closed in.

The release had consequences far beyond what the creators intended. Within weeks, dozens of Mirai variants appeared. Operators modified the credential list, added new exploits, changed the C2 protocol, and targeted different device types. Some variants added cryptomining capabilities. Others focused on specific industries or regions.

By 2026, Mirai descendants remain among the most active botnet families. Security researchers track hundreds of variants under names like Mozi, Gafgyt, Hajime, and IoT Reaper. The core scanning-and-credential-stuffing technique persists because the underlying problem - devices with default credentials exposed to the internet - has not been fully solved.

Regulatory Aftermath

Mirai accelerated regulatory action on IoT security. California passed SB-327 in 2018, becoming the first US state to require IoT devices to ship with unique passwords or force a password change on first use. The law took effect on January 1, 2020.

graph TD
    subgraph "Regulatory Timeline"
        A[2016: Mirai Attacks] --> B[2018: California SB-327 Passed]
        B --> C[2020: SB-327 Takes Effect]
        A --> D[2019: UK Code of Practice]
        D --> E[2022: UK PSTI Act Passed]
        E --> F[2024: UK PSTI Act Enforced]
        A --> G[2022: EU Cyber Resilience Act Proposed]
        G --> H[2024: EU CRA Adopted]
        H --> I[2027: EU CRA Full Enforcement]
    end

Regulatory timeline following Mirai - it took years for legislation to catch up

The UK followed with the Product Security and Telecommunications Infrastructure (PSTI) Act in 2022, enforced from April 2024. It bans universal default passwords for consumer IoT devices sold in the UK and requires manufacturers to provide a public point of contact for vulnerability reporting.

The EU Cyber Resilience Act, adopted in 2024 with full enforcement expected by 2027, goes further. It requires manufacturers to ensure cybersecurity throughout a product's lifecycle, provide security updates for a defined support period, and report actively exploited vulnerabilities.

These regulations represent progress, but enforcement remains uneven. Cheap IoT devices from manufacturers who ignore regulations continue to enter markets through online retailers and gray-market channels.

Why Default Credentials Persist

Despite Mirai and subsequent regulations, default credentials remain a problem. Several factors contribute to their persistence.

Manufacturing economics play a role. Setting unique credentials per device requires either a per-device provisioning step in the factory (adding cost) or a forced-change mechanism in the firmware (adding development cost). For devices with razor-thin margins, manufacturers resist any cost increase.

Legacy devices are a larger issue. Regulations apply to new products, not the billions of devices already deployed. IP cameras installed in 2015, industrial sensors deployed in 2012, and building management systems from 2010 will remain in service for years or decades. Many cannot be updated. Many have been forgotten by the organizations that deployed them.

User behavior also contributes. Even devices that prompt for a password change on first setup are sometimes configured with simple passwords by installers who prioritize speed over security. The password "admin1" is technically not a default, but it provides little more protection than "admin".

Detecting IoT Exposure

The BLEShark Nano can help identify IoT devices on your local network through WiFi scanning. During authorized security assessments, mapping the wireless environment reveals devices that may be running with default configurations - IP cameras, smart home hubs, industrial sensors, and other equipment that often ships with known credentials.

Understanding your network's IoT footprint is the first step toward securing it. You cannot change default passwords on devices you do not know exist. A physical walkthrough with a WiFi scanner often reveals devices that do not appear in IT asset inventories - shadow IoT deployed by individual departments, forgotten test equipment, or devices installed by building management that predate the current IT team.

Mirai proved that IoT insecurity is not an abstract risk. It is a concrete, measurable threat that has already caused billions of dollars in damage and disrupted critical services worldwide. The scanning and enumeration capabilities of tools like the BLEShark Nano make the invisible visible - and visibility is where security begins.