ThreatFox: Mirai IOCs

Hunt Hypothesis

This detection identifies network traffic matching known Mirai botnet indicators to uncover active IoT device infections that could serve as entry points for lateral movement or DDoS amplification attacks. Proactively hunting for these IOCs in Azure Sentinel is critical because Mirai variants frequently compromise unpatched IoT infrastructure, allowing adversaries to establish persistent footholds before triggering large-scale network disruptions.

IOC Summary

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

KQL: Ip Hunt

// Hunt for network connections to known malicious IPs
// Source: ThreatFox - Mirai
let malicious_ips = dynamic(["154.222.16.141", "154.222.16.250", "154.222.16.226"]);
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(["154.222.16.141", "154.222.16.250", "154.222.16.226"]);
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, along with targeted filters and exclusions suitable for an enterprise environment:

• Scenario: Scheduled IoT Firmware Update Scans

  • Context: Enterprise network administrators often deploy automated firmware updates for legacy IoT devices (e.g., IP cameras, smart thermostats) using tools like SolarWinds NPM or ManageEngine Device Insight. These agents periodically scan device ports and send traffic to known update servers that match Mirai’s hash signatures.
  • Filter/Exclusion: Create a rule exclusion for the specific source IPs of the patch management server (e.g., 10.20.5.15) and destination ports associated with the firmware repository (e.g., port 8080 or 443) during the defined maintenance window (e.g., Sundays, 02:00–04:00 UTC).

• Scenario: Network Inventory Discovery by Asset Management Tools

  • Context: Automated asset discovery tools like ** Lansweeper** or ServiceNow Discovery actively probe network segments to identify connected devices. These probes often send specific HTTP GET requests or SNMP queries that mimic the traffic patterns of Mirai botnet command-and-control (C2) communications, triggering a match on the 3 IOCs.
  • Filter/Exclusion: Exclude traffic originating from the dedicated discovery service account (e.g., svc_lansweeper) and restrict the rule to only trigger when the destination is an external public IP, excluding internal asset management subnets (e.g., 192.168.50.0/24).

• Scenario: Cloud-Based Security Scanner Traffic

  • Context: External security vendors such as Tenable Nessus, Qualys,