Incident Response Guide: Mirai Botnet

Incident Triage Steps

Within the first 30 minutes, your priority is to determine the scope of the Mirai infection and prevent further propagation. Mirai primarily targets Internet of Things (IoT) devices and Linux systems, scanning for open Telnet, SSH, and other service ports using default or weak credentials.

Immediate Actions:

1. Identify Scanning Activity: Query your SIEM platform and network sensors for internal systems performing rapid, sequential connection attempts on ports 22, 23, 2323 (Telnet variants), 7547 (TR-069), and 5555 (Android Debug Bridge). Mirai bots scan both internal and external IP ranges. A sudden spike in outbound connection failures to random IPs on these ports is a key indicator.
2. Locate the Patient Zero: Review authentication logs (e.g., /var/log/auth.log, /var/log/secure) on Linux servers and network appliances for a high volume of failed login attempts followed by a successful login from an unexpected source IP. This often precedes the download of the Mirai binary.
3. Check for Data Exfiltration: Mirai’s primary purpose is DDoS, not data theft. Focus investigation on network flow data for signs of participation in a Distributed Denial of Service attack. Look for:
   • Unusually high, sustained outbound traffic from an internal device to a single external IP/UDP port (common for DNS or NTP amplification attacks).
   • A large number of TCP SYN packets from an internal IP to a foreign target.
   • Use netflow or firewall logs to identify internal systems communicating with known-bad IPs from threat intelligence feeds.
4. Identify Affected Systems: Run a network-wide scan using a vulnerability management tool to identify devices responding on Telnet/SSH ports. Cross-reference with asset management to find unauthorized or poorly configured IoT devices (IP cameras, routers, DVRs). Check critical Linux servers for unknown processes with names like x86, anime, or random strings.

Evidence Collection

Before containment or removal, preserve forensic artifacts to understand the infection vector and impact. Isolate a sample infected system if possible.

Collect from Infected Hosts:

• Memory Dump: Use a trusted, offline memory acquisition tool to capture RAM from Linux systems. Mirai processes and their arguments may reside in memory.
• Process List & Network Connections: Execute ps auxf and netstat -tunap from a trusted, static binary (e.g., from a read-only USB). Look for processes with no associated argv (shows as empty brackets []) or strange names. Note any connections to IPs on high ports (e.g., 48101, used by some Mirai C2s).
• File System Artifacts:
  • The Mirai binary is often downloaded to /tmp/ or /dev/shm/ with a random name. Collect any suspicious binaries.
  • Check for persistence: Examine /etc/rc.local, /etc/init.d/ scripts, cron jobs (/etc/crontab, crontab -l), and systemd service files for references to the binary path.
  • Check /etc/passwd and /etc/shadow for new, unexpected user accounts added by the malware.
• Log Files: Preserve /var/log/auth.log, /var/log/secure, /var/log/syslog, and kernel logs. Search for entries around the time of initial compromise (failed/successful logins, wget or curl commands downloading payloads).

Collect from Network:

• Full Packet Capture (PCAP): If available, collect network traffic from border firewalls and internal segments showing scanning and C2 communication.
• Firewall & Proxy Logs: Export logs showing the initial inbound connection to the victim and subsequent outbound scanning/C2 traffic from it.
• NetFlow Data: Export records for the suspected patient zero and other infected hosts to map scanning targets and potential C2 servers.

Containment Procedures

Containment aims to halt Mirai’s spread and disrupt its C2 communication without alerting the attacker or destroying evidence.

1. Network Segmentation:

   • Immediately place the identified patient zero system and any other infected hosts into an isolated VLAN with no internet or internal network access. If possible, power down non-critical infected IoT devices.
   • Implement temporary network access control list (ACL) rules at your core switch or firewall to block all outbound traffic from the subnet containing infected devices, except for management traffic from your IR team’s IPs.
   • Segment your network to separate IoT and OT devices from critical corporate servers and data.

2. Credential Reset:

   • Scope: Reset passwords and SSH keys for all Linux/Unix servers, network devices, and any IoT devices that allow credential changes. Prioritize devices that showed failed login attempts in logs.
   • Enforce the use of strong, unique passwords. Disable Telnet and use SSH with key-based authentication where possible.

3. C2 and Attack Traffic Blocking:

   • Update firewall and intrusion prevention system (IPS) rules to block outbound traffic from your network to the identified C2 server IPs and domains.
   • Deploy sinkhole DNS entries on your internal DNS servers for known Mirai C2 domains to prevent bots from resolving the real C2 address.
   • Work with your ISP to implement upstream filtering if your network is sourcing a DDoS attack. They can apply BGP Flowspec or ACLs to mitigate the outbound attack traffic.

Eradication and Recovery

Eradication requires removing the malware from all infected systems. Recovery involves restoring normal operations securely.

1. Complete Removal:

   • Follow the detailed, step-by-step procedures in the Mirai Removal Guide for each affected system type. This includes killing malicious processes, deleting binaries, and removing persistence mechanisms.
   • For IoT devices that cannot be reliably cleaned, perform a factory reset. Only do this after flashing the device with the latest firmware from the vendor to prevent immediate re-infection.

2. Restoring from Backups:

   • For critical servers, restore system volumes from known-clean, offline backups taken prior to the estimated compromise date.
   • Before bringing restored systems online, patch all vulnerabilities, change all credentials, and verify the integrity of system binaries (e.g., using rpm -Va on RPM systems or debsums on Debian).

3. Verifying Clean State:

   • Before re-introducing a system to the network, perform a full antivirus and rootkit scan using updated Linux security tools.
   • Monitor the system closely for 24-48 hours after restoration. Use your EDR solution and network monitoring to confirm the absence of scanning behavior or calls to known-bad IPs.
   • Re-image systems if any doubt about persistence remains.

Lessons Learned Checklist

After containment, conduct a formal post-incident review. Answer these questions specific to Mirai:

• Initial Access: How did Mirai gain entry? Was it via a public-facing device (camera, router) with default credentials? An internet-facing Linux server with weak SSH passwords? An unpatched vulnerability in an IoT service?
• Control Failures: What security controls failed or were absent?
  • Was network segmentation lacking for IoT/OT devices?
  • Were password policies not enforced on Linux systems or network devices?
  • Was multi-factor authentication not used for administrative access?
  • Were vulnerability scans not covering non-standard IoT ports and devices?
• Detection Gaps: How long did the infection persist before detection?
  • Did network monitoring fail to alert on internal horizontal scanning?
  • Were logs from IoT devices and Linux servers not being collected in the SIEM?
  • Were there no baselines for normal outbound traffic to detect DDoS participation?
• Improvement Plan: Based on the above, define actionable improvements:
  • Implement a strict policy to change default credentials and disable unnecessary services (especially Telnet) on all devices.
  • Enforce network segmentation for all IoT and operational technology.
  • Deploy a dedicated network detection solution to identify scanning and beaconing behavior.
  • Expand asset management to include all IoT devices and enforce a patch management policy for them.
  • Conduct regular penetration tests that include credential brute-forcing and IoT device discovery.

Additional Resources:

• For detailed removal steps: Mirai Removal Guide
• For proactive monitoring: How to Detect Mirai
• For background information: Mirai Malware Overview