ThreatFox: Mirai IOCs

Hunt Hypothesis

This detection rule identifies Mirai botnet activity by monitoring network traffic for scans targeting IoT devices that utilize default credentials, which adversaries exploit to establish a distributed command-and-control infrastructure. Proactively hunting for these indicators in Azure Sentinel is critical to prevent the rapid recruitment of compromised IoT nodes into a large-scale botnet capable of executing devastating DDoS attacks or lateral movement across the enterprise network.

IOC Summary

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

KQL: Ip Hunt

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

KQL: Url Hunt

// Hunt for access to known malicious URLs
// Source: ThreatFox - Mirai
let malicious_urls = dynamic(["http://111.185.147.232:59432/Mozi.m"]);
UrlClickEvents
| where Url has_any (malicious_urls)
| project Timestamp, AccountUpn, Url, ActionType, IsClickedThrough
| order by Timestamp desc

Required Data Sources

References

• ThreatFox — Mirai

False Positive Guidance

Here are 4 specific false positive scenarios for the ThreatFox: Mirai IOCs rule, along with suggested filters or exclusions tailored to an enterprise environment:

• Scenario: Automated IoT Firmware Update Scans

  • Context: Enterprise network management tools (e.g., Cisco Meraki Dashboard, Ubiquiti UniFi Controller, or SolarWinds NMS) regularly perform automated discovery scans across the IoT subnet. These tools actively probe devices for open ports and service banners, mimicking the Mirai scanning behavior which looks for vulnerable SSH/Telnet services.
  • Filter/Exclusion: Create an exclusion rule that suppresses alerts where the source IP belongs to the “Network Management” security group or specific management VLANs (e.g., 10.20.50.x). Additionally, filter out traffic originating from known NMS tools like SolarWinds or PRTG.

• Scenario: Scheduled Vulnerability Assessment Jobs

  • Context: Security teams utilize vulnerability scanners such as Tenable Nessus, Qualys Guard, or Rapid7 InsightVM to run nightly scheduled jobs. These agents systematically enumerate IoT devices (cameras, smart thermostats, access control panels) to check for default credentials and open ports (23, 80, 443), generating traffic patterns identical to Mirai’s initial reconnaissance phase.
  • Filter/Exclusion: Implement a time-based exclusion window (e.g., 01:00 - 05:00 UTC) for the specific source IPs of the vulnerability scanner appliances. Alternatively, add a filter that ignores alerts where the destination port is part of a known “Vulnerability Scan” service list defined in the SIEM taxonomy.

• Scenario: Legitimate Cloud-Based IoT Device Provisioning

  • **Context