ThreatFox: Mirai IOCs

Hunt Hypothesis

This hypothesis posits that adversaries are actively scanning Azure workloads using known Mirai botnet indicators to identify vulnerable IoT devices and establish initial footholds within the network. Proactive hunting for these specific IOCs in Azure Sentinel is critical because early detection of Mirai traffic patterns allows the SOC team to isolate compromised assets before they can be recruited into a larger botnet capable of launching distributed denial-of-service attacks or lateral movement campaigns.

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.90.163.37"]);
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.90.163.37"]);
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, along with suggested filters and exclusions tailored for a legitimate enterprise environment:

• Scheduled Firmware Updates via IoT Management Platforms

  • Scenario: Enterprise IoT management solutions (e.g., Cisco DNA Spaces, Bosch IoT Suite, or Azure IoT Hub) often perform scheduled firmware updates on networked cameras, smart thermostats, and access control panels. These devices may initiate outbound connections to the vendor’s update servers, which share IP addresses with known Mirai command-and-control (C2) infrastructure due to shared hosting providers.
  • Filter/Exclusion: Create an exclusion rule for traffic originating from specific IoT VLANs or subnets destined for verified vendor update domains (e.g., *.firmware-update.cisco.com or specific ASN ranges associated with the vendor). Additionally, whitelist the specific destination IPs if they are confirmed as legitimate update servers by checking against the organization’s asset inventory.

• Security Scanner and Vulnerability Assessment Jobs

  • Scenario: Automated vulnerability scanners (e.g., Tenable Nessus, Qualys, or Rapid7 InsightVM) frequently probe external IP ranges to identify open ports and services on internal assets. During these scans, the scanner may initiate connections to known Mirai-associated IPs as part of a “threat intelligence feed” validation task, mimicking the behavior of an infected device attempting to reach a C2 server.
  • Filter/Exclusion: Exclude traffic where the source IP belongs to the dedicated management subnet for security tools (e.g., 10.x.y.z/24 containing the scanner appliances). Furthermore, filter out alerts where the destination port is standard HTTP/HTTPS (80/443) and the user agent string matches known enterprise scanning software signatures.

• **Cloud-Managed Device