Mirai Botnet Malware Removal Guide

Signs of Infection

Mirai primarily targets Linux-based IoT devices and embedded systems. Infection signs are often subtle due to the malware’s focus on resource efficiency for DDoS attacks.

File System Artifacts:

• Unauthorized, hidden, or suspicious binary files in common directories like /tmp, /var/tmp, /dev/shm, or /bin/. Common names observed include x, a, m, pty, or strings like bot, scan, or telnet.
• Modified or replaced system binaries, particularly busybox, to include malicious functions.
• Creation of a writable directory at /etc/.work/ or similar hidden paths used for temporary payload storage.
• Unauthorized entries in startup scripts like /etc/rc.local, /etc/init.d/, or crontab files (/etc/crontab, user crontab -l).

Process & System Behavior:

• Unusual process names that are random alphanumeric strings or mimic system processes (e.g., a process named [kworker/u:0] but with an unusual PID or parent process).
• High, unexplained network traffic (especially outbound) when the device should be idle, indicating participation in DDoS attacks or scanning.
• Unexpected listening ports, particularly on high ports (e.g., 48101, 65000) or ports associated with Mirai’s command-and-control (C2) or propagation.
• Sudden degradation of device performance or stability due to CPU/memory consumption from scanning or attack processes.
• Inability to run certain network diagnostic tools (like tcpdump or netstat) if Mirai has killed competing processes.

Network Indicators:

• Outbound connection attempts on TCP port 23 (Telnet) and port 2323 to random IP addresses, indicative of the malware’s propagation routine scanning for vulnerable devices.
• Connections to known or suspected Mirai C2 servers on IRC ports (6667, 6668) or other designated ports. Traffic often uses plaintext commands.
• DNS queries to suspicious, algorithmically generated domain names used for dynamic C2.
• Spikes in outbound UDP, TCP SYN, or GRE flood traffic directed at external IPs, signaling an active DDoS attack.

Immediate Containment Steps

Within the first 15 minutes of detecting a suspected Mirai infection, take these steps to prevent spread and damage.

1. Network Isolation:

   • Immediately disconnect the infected device from the network at the switch port or firewall level. If a dedicated IoT network segment exists, block all traffic to/from that VLAN.
   • Update firewall rules to block all outbound traffic from the infected device’s IP, especially to common Mirai C2 ports (e.g., 6667, 6668, 48101) and to prevent it from scanning (outbound port 23/Telnet).
   • If the device is critical and cannot be fully disconnected, place it in a highly restricted quarantine VLAN with no internet access and only allow necessary management traffic from a trusted jump host.

2. Process Termination:

   • If you have shell access, identify the malicious process using commands like ps aux, top, or ls -la /proc/[PID]/exe. Look for processes running from /tmp or with random names.
   • Terminate the process and any related child processes using kill -9 [PID]. Be aware that Mirai may have a watchdog process that respawns the main binary.

3. Credential Rotation Priorities:

   • Change all default credentials on the infected device via a console connection if possible. Mirai primarily propagates via weak/default Telnet credentials.
   • Rotate credentials for any other devices on the same network segment that share similar or default passwords, as they are likely targeted.
   • Change passwords for any management interfaces (SSH, web admin) on the device itself.

Manual Removal Process

This process assumes you have console or recovery mode access to the infected system.

Step 1: Terminate Malicious Processes

• Boot into a recovery mode or single-user mode if possible to prevent persistence mechanisms from restarting the malware.
• List all processes: ps aux | grep -E '(tmp|var/tmp|dev/shm|\.work)'
• Kill identified malicious processes: kill -9 [PID1] [PID2]
• Check for and kill any processes hiding behind legitimate names by examining the executable path: ls -l /proc/[PID]/exe

Step 2: Disable Persistence Mechanisms

• Inspect and clean auto-start locations:
  • cat /etc/rc.local
  • ls -la /etc/init.d/ (look for suspicious symlinks or scripts)
  • ls -la /etc/rc[0-9].d/
• Check crontab for all users and root:
  • crontab -l
  • crontab -l -u root
  • Look for entries running scripts from /tmp or /var/tmp.
• Remove any malicious entries found. For system-wide scripts, edit the file and delete the offending line. For crontab, use crontab -e.

Step 3: Locate and Delete Malicious Files

• Search for and remove common Mirai binaries and payloads:

  find / -type f \( -name "*bot*" -o -name "*scan*" -o -name "a" -o -name "x" -o -name "m" -o -name "pty*" \) -exec ls -la {} \; 2>/dev/null
  find /tmp /var/tmp /dev/shm /etc/.work -type f -exec rm -fv {} \; 2>/dev/null

• Check for and replace compromised system binaries (like busybox). Compare checksums with a known clean version or reinstall the package.
• Search for hidden directories: find / -type d -name ".work" -o -name "..." -o -name ".. "

Step 4: Clean Registry/Configuration (if applicable)

• On standard Linux systems, Mirai does not typically use a Windows-style registry. Focus on configuration files in /etc that may have been modified for persistence.
• For other embedded firmware, consult vendor documentation for any proprietary configuration databases that may store malicious scripts.

Verifying Removal

1. System Scans:

   • Run a full filesystem scan with a dedicated antivirus or EDR solution for Linux, using the latest definitions.
   • Perform a thorough find command search again for any files created in the last 24-48 hours in temporary directories.
   • Verify the integrity of key system binaries using package manager checks (dpkg -V on Debian-based systems) or by comparing checksums.

2. Log Inspection:

   • Review /var/log/auth.log, /var/log/secure, and kernel logs (dmesg) for failed login attempts (especially Telnet) around the time of initial infection.
   • Check lastlog and lastb for suspicious login sessions.
   • Analyze any available firewall (iptables) or network logs for outbound scanning (port 23) or connections to known-bad IPs.

3. Network Traffic Monitoring:

   • Before reconnecting to the main network, monitor the device’s traffic in the quarantine segment.
   • Use a packet analyzer to look for any residual outbound Telnet scanning traffic or beaconing to C2 IPs.
   • Confirm no unexpected ports are listening (netstat -tulpn).
   • Monitor for DNS requests to suspicious domains.

4. Process & Behavior Monitoring:

   • Let the system run in a monitored state for several hours. Use process monitoring tools to ensure no new suspicious processes spawn.
   • Check system resource usage (CPU, memory, network) to ensure it returns to a normal baseline.

Post-Removal Security Hardening

To prevent reinfection and protect your network:

1. Eliminate Attack Vectors:

   • Disable Telnet and other insecure services (FTP, unencrypted HTTP management) on all IoT and network devices. Use SSH with key-based authentication or VPNs for management.
   • Change all default credentials to strong, unique passwords. Enforce this as a mandatory policy for all deployed devices.
   • Segment your network. Place IoT devices on a dedicated VLAN with strict firewall rules that only allow necessary outbound/inbound traffic. Deny all traffic from the IoT VLAN to internal corporate VLANs.

2. Device Configuration & Patching:

   • Establish a strict patch management policy for firmware and software on all embedded and IoT devices.
   • Where possible, disable unused services and ports on devices.
   • Use a configuration management tool to enforce secure baselines and detect drift.

3. Monitoring & Detection Rules:

   • Deploy a network intrusion detection system (NIDS) or SIEM platform with rules to detect:
     • Internal devices making outbound connections on port 23 (Telnet).
     • Traffic to known Mirai C2 ports (e.g., 6667, 6668).
     • Anomalous high-volume UDP/TCP traffic from a single device (potential DDoS participation).
   • Implement endpoint monitoring on critical servers to detect process execution from /tmp or /dev/shm.
   • Configure log aggregation to centralize auth logs from all devices for analysis of brute-force attempts.

4. Policy Updates:

   • Mandate security assessments for all new IoT devices prior to network deployment.
   • Create an inventory of all network-connected devices and their software/firmware versions.
   • Develop and test an incident response plan specifically for IoT malware outbreaks.

For the most current technical indicators, refer to the Current Mirai IOCs. To understand detection efficacy, review the Detection Rate. For more background on this threat, see the Mirai Overview.