ThreatFox: Mirai IOCs

Hunt Hypothesis

This hunt hypothesis targets adversary behavior where compromised IoT devices initiate outbound connections to known Mirai botnet command-and-control infrastructure using specific IP and domain indicators. Proactively hunting for these Indicators of Compromise in Azure Sentinel is critical because early detection allows SOC teams to isolate infected endpoints before they scale into a massive distributed denial-of-service (DDoS) attack or lateral movement vector within the network.

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(["45.150.195.235", "205.237.110.232"]);
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(["45.150.195.235", "205.237.110.232"]);
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 specific false positive scenarios for the ThreatFox: Mirai IOCs detection rule in an enterprise environment, along with targeted exclusion strategies:

• Network Scanning by Vulnerability Assessment Tools

  • Scenario: Scheduled vulnerability scans performed by tools like Tenable Nessus, Qualys, or Microsoft Defender for Endpoint often probe IoT devices and network infrastructure. These scanners may initiate connections to known Mirai-associated IP addresses (often used as reference hosts or test targets) or mimic the specific TCP/UDP handshake patterns of Mirai botnets during discovery phases, triggering alerts on standard ports like 23 (Telnet), 80 (HTTP), and 443 (HTTPS).
  • Filter/Exclusion: Exclude traffic originating from the Vulnerability Management IP Range or specific service accounts (e.g., svc-nessus-scan) where the destination is an internal IoT subnet. Additionally, filter out alerts where the source port is ephemeral and the destination is a known “Safe List” of Mirai reference IPs used for testing.

• Automated Firmware Update Jobs

  • Scenario: Enterprise IoT management platforms (such as Cisco Meraki Dashboard, Ubiquiti UniFi, or Azure IoT Hub) frequently execute scheduled jobs to push firmware updates to cameras, access points, and smart sensors. These devices often communicate with vendor update servers that share IP ranges or ASN blocks with known Mirai IOCs. The high-volume traffic generated during these bulk update windows can be misidentified as the command-and-control (C2) beaconing behavior of an active Mirai infection.
  • Filter/Exclusion: Create a time-based exclusion for alerts occurring during defined maintenance windows (e.g., Sundays 02:00–04:00 UTC). Furthermore, exclude traffic where the destination IP belongs to major IoT vendor CD