ThreatFox: Mirai IOCs

Hunt Hypothesis

This hunt hypothesis detects Mirai malware activity by identifying outbound network connections to known command-and-control IPs and ports that indicate IoT devices compromised through default credentials or weak configurations. Proactive hunting is essential in Azure Sentinel to rapidly isolate infected endpoints before they are recruited into a botnet capable of executing large-scale DDoS attacks against the organization’s infrastructure.

IOC Summary

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

KQL: Ip Hunt

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

KQL: Domain Hunt

// Hunt for DNS queries to known malicious domains
// Source: ThreatFox - Mirai
let malicious_domains = dynamic(["servers.opik.net"]);
DnsEvents
| where Name has_any (malicious_domains)
| project TimeGenerated, Computer, Name, IPAddresses, QueryType
| order by TimeGenerated desc

Required Data Sources

References

• ThreatFox — Mirai

False Positive Guidance

Here are 5 specific false positive scenarios for the ThreatFox: Mirai IOCs detection rule, tailored for an enterprise environment, along with suggested filters and exclusions:

• Scenario: Automated Firmware Update Scans from IoT Management Platforms

  • Context: Enterprise IoT management tools (e.g., Cisco Meraki Dashboard, Ubiquiti UniFi Controller, or AWS IoT Core) routinely perform scheduled outbound scans to check device health, verify connectivity, and push firmware updates. These scans often target the same IP:port pairs (e.g., TCP 80/443, UDP 53) that Mirai uses for its initial reconnaissance, triggering alerts when devices contact known update servers or internal management nodes.
  • Suggested Filter: Create an exclusion rule based on Source Host Groups. Add all registered IoT management controllers and their dedicated update server IP ranges to a “Trusted IoT Infrastructure” allow-list. Additionally, exclude traffic where the destination port is strictly 443 (HTTPS) and the User-Agent string contains specific vendor identifiers like Meraki-Update or UniFi-Controller.

• Scenario: Scheduled Cloud Backup Jobs for Edge Devices

  • Context: Many edge devices (such as IP cameras, smart thermostats, or industrial sensors) are configured to run nightly backup jobs using tools like Veeam, Acronis Cyber Protect, or custom scripts. These jobs initiate outbound connections to cloud storage buckets (e.g., AWS S3, Azure Blob Storage) at specific times. If the destination IP belongs to a public cloud provider that overlaps with Mirai’s C2 infrastructure, the rule may flag these routine backups as suspicious bot activity.
  • Suggested Filter: Implement a time-based exclusion window. Configure the detection logic to suppress alerts for known backup source IPs during their scheduled maintenance windows (e.g.,