ThreatFox: Mirai IOCs

Hunt Hypothesis

This rule detects active network traffic matching five specific Indicators of Compromise (IOCs) linked to the Mirai botnet, which is known for launching large-scale DDoS attacks and compromising IoT devices. A SOC team should proactively hunt for these signatures in Azure Sentinel to identify early-stage infections within their infrastructure before adversaries can establish persistence or initiate disruptive denial-of-service events.

IOC Summary

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

KQL: Ip Hunt

// Hunt for network connections to known malicious IPs
// Source: ThreatFox - Mirai
let malicious_ips = dynamic(["180.93.116.41", "46.151.182.200"]);
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(["180.93.116.41", "46.151.182.200"]);
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(["meow.schoolprojectxyz.lol", "mail.cope.st", "smtp.cope.st"]);
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 3-5 specific false positive scenarios for the ThreatFox: Mirai IOCs detection rule in an enterprise environment, along with suggested filters or exclusions:

• IoT Device Firmware Updates via Scheduled Tasks

  • Scenario: Enterprise-managed IoT devices (e.g., smart thermostats, IP cameras) running on a dedicated VLAN perform nightly firmware updates. These devices often initiate outbound connections to vendor update servers that share the same IP addresses or domain names as Mirai botnet Command & Control (C2) nodes.
  • Filter/Exclusion: Create an exclusion rule for traffic originating from the IoT-DMZ subnet (e.g., 10.50.x.x) destined for known vendor update domains (e.g., *.aruba.com, *.hikvision.com). Alternatively, whitelist specific destination IPs identified in the “Allowed Vendor List” within the ThreatFox dashboard.

• Internal Network Scanning by Security Tools

  • Scenario: Automated vulnerability scanners like Tenable Nessus, Qualys, or Microsoft Defender for IoT perform periodic active probing of network assets. These tools may generate traffic patterns (specifically UDP/TCP handshake sequences) that mimic the initial infection behavior of Mirai bots, triggering alerts when they scan internal endpoints against known Mirai IOCs.
  • Filter/Exclusion: Exclude source IPs belonging to security tool management groups (e.g., Nessus-Scanner-Pool, Defender-Sensor-Group). Implement a logic filter where if the source port is a high ephemeral range (>49152) and the destination is an internal asset, suppress the alert unless the connection persists for >60 seconds.

• Cloud Backup and Replication Jobs

  • Scenario: Scheduled backup jobs using tools like Veeam, **Rubrik