Mirai Malware Detection Guide
Behavioral Indicators
Mirai exhibits distinct runtime behaviors focused on propagation and launching DDoS attacks. Upon execution, the malware process typically spawns multiple child processes. Look for a primary process, often named with random or generic system-like names, forking or creating processes that perform network scanning. These child processes will make rapid, sequential connections to random IP addresses on ports associated with Telnet (23), SSH (22), and other services like ports 2323, 80, or 8080.
The malware uses brute-force credential attacks. Monitor for processes making an unusually high volume of failed login attempts via telnet or ssh system calls or commands. It will attempt to log in using a hardcoded list of common username and password pairs. Successful logins are followed by the execution of commands to download the Mirai payload onto the compromised device. The main process will also attempt to “kill” competing malware and security processes. It uses commands like busybox and searches for processes containing strings related to other botnets or security tools, then issues kill -9 commands against them.
For persistence, the malware may attempt to disable certain services or functions. On Linux-based IoT devices, watch for processes that write to critical system directories or attempt to modify the iptables firewall to allow inbound traffic on its C2 ports.
Network Indicators
Mirai’s network activity is characterized by scanning, C2 communication, and attack traffic.
Scanning Phase: Infected hosts will generate massive, sustained outbound TCP SYN packets to random IP addresses, targeting a small set of ports (22, 23, 2323, 80, 8080). This traffic is not stealthy and originates from the infected device itself, not a spoofed IP.
Command and Control (C2): Upon successful infection, the malware connects to its C2 server. Communication is typically over TCP on a hardcoded port. Common ports observed include 23, 2323, 48101, and 80. The protocol is a simple binary protocol. Initial beaconing is often immediate upon startup and then maintains a persistent connection, waiting for commands. The C2 server may send periodic “keep-alive” packets. Data exfiltration is minimal; the primary purpose is to receive attack commands.
Attack Traffic: When commanded, the host will generate high-volume DDoS traffic. The type is specified by the C2 server and can include:
- UDP Floods: Large volumes of UDP packets to random ports on the target.
- TCP SYN Floods: Spoofed or non-spoofed SYN packets.
- ACK Floods, GRE IP Floods, and HTTP Layer 7 Attacks: The malware supports multiple vector attacks. Look for a single source IP generating an extreme volume of one protocol type toward a single destination IP/port.
DNS queries are not a primary C2 mechanism for core Mirai, but later variants may use domain generation algorithms (DGAs). Typically, the C2 IP is hardcoded.
File System Artifacts
Mirai is designed for lightweight systems and leaves minimal file system traces, often running entirely in memory. However, initial infection and propagation create artifacts.
Downloaded Payload: The initial downloader script or binary may be placed in a writable directory. Common paths on IoT devices include /tmp/, /var/run/, /dev/shm/, or within the web server directory (e.g., /www/). Filenames are often random alphanumeric strings (e.g., x84gH, an0n) or masquerade as system files (e.g., busybox, init). The main Mirai binary is typically small, often between 30KB and 100KB for ARM/MIPS architectures.
Script Artifacts: The brute-force script used to propagate may be downloaded to temporary locations. Look for shell scripts that contain wget or tftp commands to pull the binary from a remote server, followed by chmod +x and execution.
Device-Specific Paths: On specific devices, Mirai may attempt to write to the filesystem for persistence. For example, on some routers, it may try to modify files in /etc/ or create scripts in /etc/crontab/ or /etc/init.d/. The primary binary is often deleted after execution to hide its presence, leaving only the running process in memory.
Registry and Persistence Mechanisms
Traditional Windows registry persistence is not applicable to Mirai, as it primarily targets Linux-based IoT devices, routers, and cameras. Its persistence mechanisms are tailored to these environments:
Cron Jobs: The malware may install a cron job to re-infect the device after a reboot. Check system crontabs (/etc/crontab) and user cron directories (/var/spool/cron/) for entries that download and execute a payload from a remote URL. The entry may point to a script in /tmp/ or directly use a wget or curl command in a pipe to sh.
Init Scripts: It may add or modify startup scripts in /etc/init.d/ or symlinks in /etc/rc.d/ to ensure the malware is restarted on system boot. Look for new or modified scripts with suspicious commands.
Binary Replacement: In some cases, Mirai replaces common system binaries like busybox with a trojanized version that includes the malware’s functionality. File integrity monitoring on critical binaries can detect this.
Process Hiding: The malware may not use traditional persistence but relies on the device rarely being rebooted. Its main persistence is often just the running process, which it defends by killing other processes that might stop it.
YARA Rule Guidance
Focus on the unique combination of lightweight binary structure, hardcoded strings, and functionality present in Mirai samples.
Target Strings: Look for the hardcoded list of common credentials used for Telnet/SSH brute-forcing. These include pairs like root:xc3511, root:vizxv, root:admin, admin:admin, and support:support. Also, target strings related to its process-killing functionality, such as busybox, grep, %s: %d, and commands like kill -9. Include strings for common C2 commands like SCANNER, KILLER, ATK, PING.
Binary Patterns: Mirai binaries are statically linked and stripped. Look for a lack of section names or standard library function names. The entrypoint may be very low (e.g., 0x10000 or 0x10074 common in MIPS/ARM ELF files). The file size is small. You can create a condition checking for a small file size (e.g., filesize < 150KB) for non-debug samples.
Structural Characteristics: Target the sequence of bytes that set up the socket for the C2 connection or the scanning loop. Look for network-related constants in the binary (e.g., 0x17 for TCP, 0x1770 for port 6000). Since the C2 IP is often hardcoded, you can search for the 4-byte sequence of common C2 server IPs (in hex, little-endian and big-endian). Also, target the specific sequence of system calls (socket, connect, send) used in its network functions.
Architecture-Specific Opcodes: For rules targeting specific architectures (ARM, MIPS, x86), identify common opcode sequences at the start of the scanning or attack functions.
For the latest samples and specific indicators of compromise, refer to the following resources: