ThreatFox: Mirai IOCs

Hunt Hypothesis

This detection identifies network traffic matching known Mirai botnet indicators of compromise to uncover potential IoT device infections and command-and-control communications. Proactive hunting is essential in Azure Sentinel to rapidly isolate compromised endpoints before adversaries leverage them for large-scale DDoS attacks or lateral movement within the cloud infrastructure.

IOC Summary

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

KQL: Ip Hunt

// Hunt for network connections to known malicious IPs
// Source: ThreatFox - Mirai
let malicious_ips = dynamic(["46.8.226.21", "46.8.226.50", "46.8.226.163", "46.8.226.88", "46.8.226.61", "46.8.226.122"]);
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(["46.8.226.21", "46.8.226.50", "46.8.226.163", "46.8.226.88", "46.8.226.61", "46.8.226.122"]);
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(["5748asheve.gooning.st", "iloveboats.st", "gooning.st"]);
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 5 specific false positive scenarios for the ThreatFox: Mirai IOCs detection rule, along with recommended filters or exclusions tailored for an enterprise environment:

• Automated Firmware Updates via IoT Management Platforms

  • Scenario: Enterprise IoT management tools (e.g., Cisco Meraki, Ubiquiti UniFi, or Bosch Building Technologies) automatically push firmware updates to networked devices. These updates often involve downloading binaries from public repositories that share IP addresses or hashes with known Mirai command-and-control (C2) nodes, triggering the rule when a device initiates an outbound connection during the update window.
  • Filter/Exclusion: Create a whitelist exclusion for traffic originating from specific IoT management subnets (e.g., 10.50.x.x) destined for known vendor update servers. Alternatively, exclude connections where the destination port is restricted to standard update ports (e.g., TCP 443 or UDP 80) and the source device type is identified as “IoT/Firmware Update Agent.”

• Scheduled Vulnerability Scanning Jobs

  • Scenario: Security teams run scheduled vulnerability scans using tools like Tenable Nessus, Qualys, or Rapid7 InsightVM. These scanners actively probe external assets and may initiate connections to public IP addresses that overlap with the Mirai IOC list (specifically those used for cloud-based asset discovery or threat intelligence feeds), causing the rule to flag these administrative scans as potential Mirai infections.
  • Filter/Exclusion: Implement a time-based exclusion window during known maintenance hours (e.g., 02:00–04:00 UTC) for traffic generated by specific scanner service accounts or IP ranges. Additionally, filter out alerts where the source process name matches known scanning executables (e.g., nessuscli.exe, `qualyspcagent