ThreatFox: Mirai IOCs

Hunt Hypothesis

This detection identifies Mirai botnet activity by monitoring for network scans targeting IoT devices with default credentials or weak security configurations that often lead to DDoS attacks. Proactively hunting for these indicators in Azure Sentinel is critical to rapidly identify and isolate compromised IoT assets before they are recruited into a large-scale botnet capable of overwhelming enterprise networks.

IOC Summary

Malware Family: Mirai Total IOCs: 2 IOC Types: ip:port

KQL: Ip Hunt

// Hunt for network connections to known malicious IPs
// Source: ThreatFox - Mirai
let malicious_ips = dynamic(["94.154.43.12", "217.60.195.187"]);
CommonSecurityLog
| where DestinationIP in (malicious_ips) or SourceIP in (malicious_ips)
| project TimeGenerated, SourceIP, DestinationIP, DestinationPort, DeviceAction, Activity
| order by TimeGenerated desc

KQL: Ip Hunt Device

// Hunt in Defender for Endpoint network events
let malicious_ips = dynamic(["94.154.43.12", "217.60.195.187"]);
DeviceNetworkEvents
| where RemoteIP in (malicious_ips)
| project Timestamp, DeviceName, RemoteIP, RemotePort, InitiatingProcessFileName, ActionType
| order by Timestamp desc

Required Data Sources

References

• ThreatFox — Mirai

False Positive Guidance

Here are 5 specific false positive scenarios for the ThreatFox: Mirai IOCs detection rule, including suggested filters or exclusions tailored for a legitimate enterprise environment:

• Scenario: Automated IoT Firmware Update Scans

  • Context: Enterprise network administrators often deploy automated firmware update tools (e.g., Cisco Meraki Dashboard, Ubiquiti UniFi Controller, or SolarWinds NPM) that periodically scan all connected IoT devices to check for vulnerabilities and push updates. These tools generate high-volume outbound traffic to vendor update servers, mimicking the Mirai botnet’s scanning behavior on ports 23 (Telnet), 80 (HTTP), and 443 (HTTPS).
  • Filter/Exclusion: Create an exclusion rule based on Source IP ranges assigned to the management subnets of these specific controllers. Additionally, filter traffic where the destination port is restricted to known vendor update endpoints (e.g., cisco.com, ubnt.com) and the user agent string contains “Firmware-Update-Agent”.

• Scenario: Scheduled Network Discovery Jobs via Nmap/Zabbix

  • Context: Security teams run scheduled jobs using tools like Nmap, Zabbix, or ** Lansweeper** to perform active network discovery. These jobs systematically probe IoT devices (smart cameras, HVAC controllers) for open ports and service versions. The detection logic may misinterpret these systematic probes as Mirai’s initial infection scanning phase, especially when the job targets default credentials on legacy devices.
  • Filter/Exclusion: Exclude traffic originating from specific Service Accounts or Jump Hosts (e.g., svc-nmap-discovery, zabbix-proxy-01) during defined maintenance windows (e.g., 02:00–04:00 UTC). Implement a filter that ignores alerts if the source