ThreatFox: Mirai IOCs

Hunt Hypothesis

This detection rule identifies network traffic matching known Indicators of Compromise (IOCs) from the ThreatFox feed that are specifically linked to Mirai botnet activity. A SOC team should proactively hunt for these signatures in Azure Sentinel to rapidly detect and isolate IoT devices compromised by Mirai, thereby preventing potential large-scale Distributed Denial of Service (DDoS) attacks or lateral movement within the network.

IOC Summary

Malware Family: Mirai Total IOCs: 9 IOC Types: ip:port, domain

KQL: Ip Hunt

// Hunt for network connections to known malicious IPs
// Source: ThreatFox - Mirai
let malicious_ips = dynamic(["178.83.206.213", "176.65.148.145", "45.38.249.148", "155.103.69.225", "45.123.191.90"]);
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(["178.83.206.213", "176.65.148.145", "45.38.249.148", "155.103.69.225", "45.123.191.90"]);
DeviceNetworkEvents
| where RemoteIP in (malicious_ips)
| project Timestamp, DeviceName, RemoteIP, RemotePort, InitiatingProcessFileName, ActionType
| order by Timestamp desc

KQL: Domain Hunt

// Hunt for DNS queries to known malicious domains
// Source: ThreatFox - Mirai
let malicious_domains = dynamic(["poop.garden"]);
DnsEvents
| where Name has_any (malicious_domains)
| project TimeGenerated, Computer, Name, IPAddresses, QueryType
| order by TimeGenerated desc

Required Data Sources

References

• ThreatFox — Mirai

False Positive Guidance

Here are specific false positive scenarios and corresponding exclusion strategies for the ThreatFox: Mirai IOCs detection rule in an enterprise environment:

• Scenario: Scheduled Vulnerability Scans by Internal Security Tools

  • Context: Enterprise vulnerability management tools like Tenable Nessus, Qualys, or Rapid7 InsightVM often perform active network discovery and port scanning. These tools frequently probe IoT device ranges (where Mirai thrives) using specific ports (e.g., 23, 80, 443, 161) that overlap with Mirai’s initial infection vectors. The scanner’s IP addresses may match the “Source IP” or “Destination IP” IOCs defined in the ThreatFox package.
  • Suggested Filter/Exclusion: Create a rule exclusion based on the source_ip field to whitelist the specific subnets of the vulnerability management servers (e.g., 10.50.20.0/24) or explicitly exclude traffic where the process_name matches known scanner executables like nessus.exe, qualyspcd.exe, or rapid7-agent.

• Scenario: Automated Firmware Updates via IoT Management Platforms

  • Context: In environments with large-scale IoT deployments, platforms such as Cisco IoT Cloud, Azure IoT Hub, or Bosch IoT Suite automatically push firmware updates to thousands of devices (cameras, sensors, smart thermostats). These update mechanisms often initiate outbound connections to vendor cloud endpoints that may share IP ranges or specific hash signatures with the Mirai IOCs.
  • Suggested Filter/Exclusion: Implement an exclusion based on destination_domain or destination_ip for known vendor update servers (e.g., *.cisco.com, *.azureedge.net). Additionally, filter events where the process_name