ThreatFox: Mirai IOCs

Hunt Hypothesis

This hypothesis posits that adversaries are leveraging known Mirai malware indicators to establish botnet infrastructure within our network by initiating specific outbound connections and DNS queries. Proactive hunting in Azure Sentinel is critical to identify these early-stage infections before they scale into large-scale distributed denial-of-service attacks or pivot laterally across cloud assets.

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(["94.154.43.12", "103.253.212.175"]);
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(["94.154.43.12", "103.253.212.175"]);
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 suggested filters and exclusions:

• IoT Device Firmware Updates via Management Console

  • Scenario: Enterprise-managed IoT devices (e.g., Cisco Meraki cameras or Aruba access points) initiate outbound HTTPS connections to vendor update servers. These updates often contain embedded signatures or IP ranges that overlap with known Mirai command-and-control (C2) infrastructure, triggering the rule when the device downloads a patch during off-hours.
  • Filter/Exclusion: Exclude traffic originating from the specific VLANs assigned to IoT devices (e.g., VLAN-IoT-Prod) and destination IPs belonging to verified vendor update servers (e.g., *.cisco.com, *.arubanetworks.com). Additionally, filter for traffic occurring only during scheduled maintenance windows defined in the ITSM tool.

• Network Scanning by Vulnerability Assessment Tools

  • Scenario: Scheduled vulnerability scans performed by tools like Tenable Nessus or Qualys actively probe internal and external assets. During these scans, the scanner may attempt to connect to known Mirai-associated IP addresses as part of a “threat intelligence enrichment” module or while testing firewall rules against public threat feeds, generating legitimate connection logs that match the Mirai IOC list.
  • Filter/Exclusion: Create an exclusion rule for source IPs belonging to the vulnerability management infrastructure (e.g., 10.20.30.50 for Nessus) and restrict the detection logic to exclude traffic where the destination port is 80 or 443 during known scan execution times (e.g., Sundays between 02:00–06:00 UTC).

• Security Information and Event Management (SIEM) Threat Intelligence Feeds