Mirai Botnet: how it infects IoT devices
and launches DDoS attacks

Back to Blog

The Source Code Leak That Changed DDoS Forever

On September 30, 2016, a user named "Anna-senpai" posted the full source code of the Mirai botnet to the Hackforums community. The post was matter-of-fact: "I made my mass money, there's lots of eyes looking at IoT now, so it's time to GTFO." Within hours, the code was mirrored across GitHub and paste sites worldwide. The author was later identified as Paras Jha, a Rutgers University student who, along with Josiah White and Dalton Norman, had built Mirai to target competing Minecraft server hosting operations before realizing the botnet's broader commercial potential in DDoS-for-hire services.

Before the source leak, Mirai had already demonstrated its destructive capability. In September 2016, it powered a 620 Gbps attack against the security journalist Brian Krebs (KrebsOnSecurity), forcing Akamai to drop him as a pro-bono client. Days later, it hit OVH with over 1 Tbps of traffic sourced from roughly 145,000 compromised CCTV cameras and DVRs. But the source code release was the inflection point. It gave every script kiddie, cybercriminal group, and nation-state actor a production-ready IoT botnet framework. Within months, dozens of Mirai variants appeared, each with modified credential lists, new exploits, and adapted C2 protocols. The IoT botnet era had begun in earnest.

Understanding how Mirai works at the technical level matters today because the core infection mechanics remain largely unchanged in modern IoT botnets. The variants have evolved, but the fundamental lifecycle of scan, brute-force, load, propagate, and attack is still the dominant model for IoT-based DDoS infrastructure nearly a decade later.

The Infection Lifecycle

Mirai's infection chain is a five-stage process. Each compromised device immediately becomes a scanner, creating an exponential growth curve that allowed the original botnet to scale from zero to 600,000 bots in a matter of weeks.

Stage 1: Scanning for Targets

Every active Mirai bot runs a scanning loop that generates random IPv4 addresses and sends SYN packets to TCP ports 23 (Telnet) and 2323 (alternate Telnet). The random IP generation is not truly random. Mirai's source code contains a hardcoded exclusion list that avoids scanning certain address ranges to reduce the risk of drawing attention from security researchers and government agencies:

# Mirai's IP exclusion list (from scanner.c)
# These ranges are skipped during random target generation:

127.0.0.0/8       # Loopback
0.0.0.0/8         # Invalid
3.0.0.0/8         # General Electric (later AWS)
15.0.0.0/7        # Hewlett-Packard
56.0.0.0/8        # US Postal Service
10.0.0.0/8        # RFC 1918 private
192.168.0.0/16    # RFC 1918 private
172.16.0.0/14     # RFC 1918 private
100.64.0.0/10     # Carrier-grade NAT
169.254.0.0/16    # Link-local
198.18.0.0/15     # Benchmarking
224.0.0.0/4       # Multicast
6.0.0.0/7         # Army Information Systems Center
11.0.0.0/8        # DoD
21.0.0.0/8        # DDN-RVN
22.0.0.0/8        # DISA
26.0.0.0/8        # DISA
28.0.0.0/7        # DSI-North
30.0.0.0/8        # DSI-North
33.0.0.0/8        # DLA Systems Automation Center
55.0.0.0/8        # DoD Network Info Center
214.0.0.0/7       # DoD

The exclusion of Department of Defense (DoD) and IANA reserved ranges is deliberate. Mirai's authors wanted the botnet to grow as fast as possible without triggering military or federal monitoring systems. The scanning itself is lightweight: each bot sends raw SYN packets using non-blocking sockets and tracks open connections via an internal state table. When a SYN-ACK response arrives from port 23 or 2323, the bot knows it has found a device with an open Telnet service and proceeds to the brute-force stage.

Stage 2: Credential Brute-Force

Once a responsive Telnet service is found, the bot attempts to authenticate using a hardcoded table of default credentials. The original Mirai source contained 62 username/password combinations targeting IoT devices shipped with factory-default login credentials. Here are some of the most common entries from the original credential table:

# Mirai default credential table (partial)
# Format: username / password

root        xc3511        # XiongMai Technologies (DVRs, IP cameras)
root        vizxv         # Dahua DVRs
root        admin         # Generic
admin       admin         # Generic routers, cameras
root        888888        # Various DVRs
root        xmhdipc       # XiongMai IP cameras
root        default       # Various
root        juantech      # Juan Technologies cameras
root        123456        # Generic
root        54321         # Generic
support     support       # Generic
root        (none)        # Empty password
admin       password      # Generic routers
root        root          # Generic Linux devices
root        12345         # Generic
user        user          # Generic
admin       (none)        # Empty password
root        pass          # Generic
admin       admin1234     # Generic
root        1111          # Polycom cameras
admin       smcadmin      # SMC Networks
admin       1111          # Various
root        666666        # Dahua DVRs
root        password      # Generic
root        klv123        # HiSilicon-based cameras
root        klv1234       # HiSilicon-based cameras
root        Zte521        # ZTE routers
root        hi3518        # HiSilicon media processors
root        jvbzd         # Dahua DVRs
root        anko          # Anko products
root        zlxx.         # Various Chinese OEM devices
root        7ujMko0vizxv  # Dahua technology
root        7ujMko0admin  # Dahua technology
root        system        # Various
root        ikwb          # Toshiba network cameras
root        dreambox      # Dreambox satellite receivers
root        user          # Various
root        realtek       # Realtek-based routers
root        00000000      # Various
admin       1234          # Various
admin       12345         # Various
admin       54321         # Various
guest       guest         # Various

The brute-force process is sequential but fast. The bot opens a Telnet connection, waits for a login prompt, sends a username, waits for a password prompt, sends the password, and checks whether it receives a shell prompt. For devices with default credentials, this takes less than two seconds. The bot tries each credential pair in sequence until one succeeds or the list is exhausted.

The genius of Mirai was not in sophisticated exploitation. It was in recognizing that millions of IoT devices were deployed on the public internet with factory-default credentials that their owners never changed. No zero-days required.

Stage 3: The Loader

When a bot successfully authenticates, it does not install the malware directly. Instead, it reports the compromised device's IP address, port, and working credentials back to a separate infrastructure component called the loader (also called the "ScanListen" server in Mirai's source). The loader is a dedicated server operated by the botnet operator that handles the actual binary deployment.

The loader connects to the newly compromised device using the reported credentials, determines the device's CPU architecture, and pushes the appropriate bot binary. Mirai was compiled for multiple architectures to maximize compatibility with the heterogeneous IoT device landscape:

# Mirai supported architectures (from cross-compile build scripts)

arm      # ARM (most IP cameras, DVRs, smart home devices)
arm7     # ARMv7 (newer cameras, routers)
mips     # MIPS big-endian (Broadcom/MediaTek routers)
mipsel   # MIPS little-endian (various routers)
x86      # Intel/AMD 32-bit (some NAS devices, Linux servers)
x86_64   # Intel/AMD 64-bit
ppc      # PowerPC (some older routers)
sparc    # SPARC (some enterprise equipment)
m68k     # Motorola 68k (legacy embedded systems)
sh4      # SuperH (some Japanese electronics)

The loader uses multiple delivery methods to get the binary onto the device, trying each in sequence until one succeeds:

1. wget: If wget is available on the device, the loader instructs it to download the binary from a staging HTTP server.
2. tftp: If wget is unavailable, the loader tries TFTP, which is common on embedded Linux systems.
3. echo: As a last resort, the loader uses echo with escape sequences to write the binary byte-by-byte to a file. This is slow but works on virtually any Linux shell.

Once the binary is on the device, the loader executes it, and the new bot process starts. One of the first things the bot does is delete its own binary from disk and renames its process to a randomized string to make detection harder. It then kills any other processes listening on ports 22 (SSH), 23 (Telnet), or 80 (HTTP) to lock out competing botnets and to prevent the device owner from logging in remotely.

Stage 4: C2 Registration

After startup, the bot resolves the C2 (command and control) domain hardcoded in its binary and connects to the C2 server over a custom encrypted protocol. The original Mirai C2 communication used a simple XOR-based encryption scheme over TCP. Upon connecting, the bot sends a registration message containing basic information about the compromised device (architecture, memory, connection speed). The C2 server adds the bot to its pool and acknowledges the registration.

The C2 protocol is deliberately minimal. The bot maintains a persistent TCP connection to the C2 server and waits for attack commands. There is no periodic check-in, no heartbeat overhead, and no complex protocol negotiation. This simplicity is by design: IoT devices have limited CPU and memory resources, so the bot must be as lightweight as possible to avoid degrading device performance to the point where the owner notices and reboots.

Stage 5: Self-Propagation

Immediately after registering with the C2 server, the new bot begins its own scanning loop. This is the critical feedback mechanism that makes Mirai's growth exponential. Each infected device scans for new targets independently, and every successful infection produces another scanner. With a pool of 100,000 bots each scanning thousands of IPs per minute, Mirai could discover and infect nearly every vulnerable device on the internet within days of a new credential being added to the list.

# Mirai propagation math:
#
# Assume:
#   - 1 initial bot
#   - Each bot infects 2 new devices per hour (conservative)
#   - No overlap in scanning (optimistic)
#
# Hour 0:     1 bot
# Hour 1:     3 bots
# Hour 2:     9 bots
# Hour 5:     243 bots
# Hour 10:    59,049 bots
# Hour 15:    14.3 million (saturates available targets)
#
# In practice, overlap and network constraints slow this down,
# but Mirai reached ~600,000 bots within weeks of deployment.

C2 Protocol and Attack Commands

The Mirai C2 server is a relatively simple application that manages a list of connected bots and dispatches attack commands. The operator interacts with the C2 through a command-line interface (or, in commercial variants, a web panel). Attack commands specify the target IP or subnet, the attack duration, and the attack vector. Mirai's original source included the following attack methods:

• UDP flood: High-bandwidth generic UDP packets to overwhelm the target's link capacity.
• VSE flood: Valve Source Engine query flood targeting game servers with amplified responses.
• DNS water torture: Sends random subdomain queries to authoritative DNS servers, exhausting resolver resources (also called NXDOMAIN attacks or random-prefix attacks).
• SYN flood: Standard TCP SYN flood to exhaust the target's connection table or SYN backlog.
• ACK flood: TCP ACK packets to bypass stateless firewalls and consume server resources.
• GRE flood: GRE-encapsulated IP packets. Particularly effective against targets behind GRE tunnels.
• GRE ETH flood: GRE with Ethernet framing for targeting bridged environments.
• HTTP flood (GET/POST): Application-layer attacks with randomized headers to exhaust web server resources.
• STOMP flood: TCP payload floods using the STOMP messaging protocol.

Attack commands are broadcast to all connected bots or to a subset identified by architecture or capability. A typical attack command in Mirai's protocol looks like this:

# Mirai attack command structure (pseudocode):
#
# ATTACK_CMD = {
#     target_ip:     "203.0.113.50"
#     target_port:   80
#     duration:      120          # seconds
#     attack_type:   ATK_UDP      # UDP generic flood
#     flags: {
#         payload_size: 1024      # bytes per packet
#         source_port:  0         # 0 = random
#     }
# }
#
# The C2 serializes this into a compact binary format,
# XOR-encrypts it with a hardcoded key, and sends it
# over the persistent TCP connection to each bot.

The XOR encryption in the original Mirai was trivial. The key was a single 4-byte value embedded in the binary. Security researchers reversed this within hours of the source code release, enabling passive monitoring of C2 traffic on compromised networks. Modern Mirai variants have moved to stronger encryption, but the command structure remains functionally similar.

Mirai Variants and Evolution

The source code release spawned an entire ecosystem of Mirai-derived botnets. Researchers have tracked hundreds of distinct variants since 2016, each modifying the original codebase in different ways:

• Satori/Okiru: Added exploitation of CVE-2017-17215 (Huawei HG532 router RCE) instead of relying purely on credential brute-forcing. This was one of the first Mirai variants to incorporate actual vulnerability exploits.
• Masuta: Exploited CVE-2017-17215 and CVE-2014-8361 (Realtek SDK UPnP SOAP command injection). Expanded the target device base beyond cameras and DVRs into consumer routers.
• Mozi: A hybrid botnet combining Mirai's scanning and credential brute-force with a DHT (Distributed Hash Table) peer-to-peer C2 protocol instead of centralized C2 servers. This made takedowns significantly harder.
• Gafgyt/BASHLITE crossover: Several variants merged code from Mirai and the older Gafgyt (BASHLITE) botnet, combining Mirai's efficient scanning with Gafgyt's broader exploit capabilities.
• Aisuru/Kimwolf: A more recent variant family with expanded credential dictionaries, additional protocol exploits (including targeting enterprise IoT devices), and improved evasion techniques including polymorphic binary generation.
• InfectedSlurs: Discovered in late 2023, this variant exploited two zero-day vulnerabilities in NVR (Network Video Recorder) and router firmware to achieve infection without any credential brute-forcing at all.
• IZ1H9: An aggressive variant that integrates over 13 different exploits targeting D-Link, TP-Link, Zyxel, and other consumer router brands, rapidly rotating through new CVEs as they are published.

The common thread across all these variants is that the core Mirai architecture remains sound. The scan-brute-load-propagate-attack lifecycle works, and each new variant simply extends the "brute" and "load" stages with additional credentials and exploits while keeping the rest of the framework largely intact.

What Mirai Traffic Looks Like on Your Network

If your infrastructure is targeted by a Mirai-based DDoS attack, the traffic profile on the receiving end has several distinguishing characteristics that set it apart from reflection/amplification attacks:

Source IP Distribution

Unlike reflection attacks where source IPs belong to legitimate servers (DNS resolvers, NTP servers, domain controllers), Mirai attack traffic comes from the actual compromised IoT devices. These source IPs are overwhelmingly residential and small-business addresses. You will see IPs from consumer ISPs across dozens of countries, concentrated in regions with high IoT deployment density: Southeast Asia, South America, Eastern Europe, and Africa. Reverse DNS lookups on source IPs will often resolve to ISP customer ranges rather than data centers or enterprise networks.

# Sample source IP analysis during a Mirai UDP flood:
#
# $ tcpdump -nn -r mirai-attack.pcap 'udp' | \
#     awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -rn | head -20
#
#   847  186.215.xxx.xxx    # Brazil (Vivo/Telefonica residential)
#   631  103.78.xxx.xxx     # Indonesia (residential ISP)
#   589  41.206.xxx.xxx     # Nigeria (residential ISP)
#   512  177.39.xxx.xxx     # Brazil (NET Virtua cable)
#   498  113.172.xxx.xxx    # Vietnam (VNPT residential)
#   477  85.117.xxx.xxx     # Turkey (TurkTelekom residential)
#   441  190.108.xxx.xxx    # Colombia (Claro residential)
#   423  36.73.xxx.xxx      # Indonesia (Telkomsel mobile)
#   398  102.89.xxx.xxx     # Nigeria (Airtel mobile)
#   371  45.225.xxx.xxx     # Brazil (regional ISP)
#
# Key indicators:
# - All residential/mobile ISP ranges
# - Concentrated in developing nations with high IoT adoption
# - Each source contributes moderate PPS (not a single heavy hitter)
# - Thousands of unique source IPs across 50+ countries

Packet Characteristics

Mirai's UDP flood generates packets with randomized payloads. The packet sizes are configurable by the operator but typically range from 512 to 1400 bytes. Unlike reflection attacks where packet sizes cluster around a specific value (e.g., 4800 bytes for CLDAP), Mirai's direct floods show more uniform size distribution. SYN floods from Mirai use standard 60-byte TCP SYN packets with randomized source ports and sequence numbers. The TTL (Time To Live) values across source IPs will be inconsistent, reflecting the diverse geographic distribution of infected devices with varying hop counts to your network.

# Mirai attack traffic signatures:
#
# UDP flood:
#   - Source ports: random (full 1-65535 range)
#   - Destination port: target-specified (often 80, 443, 53, or game ports)
#   - Payload: random bytes (no protocol structure)
#   - Packet size: 512-1400 bytes (configurable)
#   - TTL: highly variable (reflecting diverse global sources)
#
# SYN flood:
#   - Source ports: random
#   - TCP flags: SYN only (0x02)
#   - Window size: varies across bots
#   - Sequence numbers: randomized
#   - No TCP options in some variants (abnormal for modern OS stacks)
#
# HTTP flood:
#   - Valid HTTP GET/POST requests
#   - Randomized User-Agent strings (from hardcoded list)
#   - Randomized URL paths or query parameters
#   - Keep-Alive connections (to consume server resources)
#   - No JavaScript execution (fails bot-detection challenges)

PPS and Bandwidth Profile

Mirai-based attacks tend to produce high PPS with moderate per-packet size. A 600 Gbps UDP flood at 1024-byte packets generates approximately 73 million packets per second. The attack ramps up quickly (within 2-5 seconds of the C2 command) as all active bots begin transmitting simultaneously. The bandwidth is sustained at a relatively constant level for the configured attack duration, with minor fluctuations as individual bots drop offline or reconnect.

Detecting Mirai DDoS Traffic with Flowtriq

Detecting Mirai-generated DDoS traffic requires per-second visibility into your network's traffic patterns. Traditional SNMP-based monitoring that polls at 5-minute intervals will show you that an attack happened, but only after minutes of downtime. Flowtriq's real-time detection engine identifies Mirai attack signatures within seconds by analyzing multiple traffic dimensions simultaneously:

• PPS spike detection: Flowtriq monitors packets per second on every node. When PPS exceeds your baseline by a configurable threshold, an incident is triggered immediately. Mirai attacks cause sudden PPS jumps (from normal baseline to millions of PPS within seconds) that are unmistakable.
• Source IP entropy analysis: Mirai attacks come from thousands of unique IPs. Flowtriq calculates source IP entropy in real time. A sudden increase in source IP diversity combined with a PPS spike is a strong indicator of botnet-driven DDoS rather than a single-source flood or application issue.
• Protocol classification: Flowtriq classifies attack traffic by protocol and port. A UDP flood on a non-standard port from thousands of residential IPs is immediately flagged as a volumetric botnet attack, distinct from reflection vectors (which show clustered source ports like 53, 123, or 389).
• Geographic distribution: Mirai's global bot distribution creates a distinctive geographic fingerprint. Flowtriq's source geo-analysis detects when traffic suddenly originates from dozens of countries simultaneously, a pattern that almost never occurs in legitimate traffic.
• Packet capture: When an incident is detected, Flowtriq can trigger automatic PCAP captures, giving you forensic-grade packet data for post-incident analysis and evidence collection.

The critical advantage of real-time detection is response time. Knowing that a Mirai UDP flood started 3 seconds ago lets you trigger upstream blackhole routes, activate scrubbing services, or engage your CDN's DDoS protection before your services degrade. Knowing 5 minutes later that an attack happened is a post-mortem, not a defense.

Why IoT Botnets Keep Growing

Nearly a decade after Mirai's source code leak, IoT botnets remain one of the dominant DDoS attack vectors. Several structural factors ensure this will continue:

• Manufacturers still ship default credentials: Despite years of security research and even legislative efforts (the UK's PSTI Act, California's SB-327), a large percentage of IoT devices ship with default or easily guessable credentials. Cost pressure in the consumer electronics market means security is still treated as optional.
• Device lifecycles are long, patching is rare: IP cameras, DVRs, routers, and other embedded devices often run for 5-10 years without firmware updates. Even when patches are available, most device owners never apply them. The devices are "set and forget" by design.
• IPv6 expands the attack surface: As IPv6 adoption grows, IoT devices increasingly receive globally routable IPv6 addresses. While IPv6's address space makes scanning harder, link-local multicast discovery and other IPv6-specific protocols create new reconnaissance vectors that botnet authors are actively exploring.
• More devices, more targets: Industry estimates project 30+ billion connected IoT devices by 2030. Each new device category (smart appliances, industrial sensors, connected vehicles) introduces new firmware, new default configurations, and new attack surface.
• Reboot does not fix the problem: Mirai runs entirely in memory and does not survive a reboot. But because the underlying vulnerability (default credentials) is never fixed, the device is re-infected within minutes of rebooting. The only permanent fix is changing the password or taking the device off the public internet.

Defending Your Infrastructure

If you operate network infrastructure that could be targeted by Mirai-based DDoS, your defense strategy should address both prevention (reducing the chance you are a viable target) and detection (knowing the moment an attack begins):

Reduce Your Exposure

• Audit your own IoT devices: Scan your network for devices with open Telnet (port 23/2323) and SSH (port 22) services. Change all default credentials. Disable remote management on devices that do not require it.
• Segment IoT traffic: Place IoT devices on isolated VLANs with strict egress filtering. If a device is compromised, segmentation prevents it from scanning your internal network and limits its ability to participate in outbound DDoS attacks.
• Implement BCP38: If you operate a network, ensure egress filtering is in place so that compromised devices on your network cannot send spoofed traffic.

Detect and Respond

• Deploy per-second monitoring: 5-minute SNMP polling is not sufficient to detect or respond to modern DDoS attacks. You need per-second PPS and bandwidth visibility on every node.
• Set baseline-aware thresholds: Static thresholds miss attacks that are large relative to your normal traffic but below an arbitrary absolute number. Baseline-aware detection catches anomalies regardless of your traffic scale.
• Automate your response: Pre-configure upstream blackhole routes, scrubbing service activation, and notification channels so that when Flowtriq detects an attack, your response is triggered within seconds, not after a human reads an email.

Back to Blog

Related Articles