ThreatFox: Mirai IOCs

Hunt Hypothesis

This detection rule identifies network traffic matching known Indicators of Compromise (IOCs) from the Mirai botnet, which adversaries leverage to establish command-and-control channels and launch large-scale DDoS attacks against IoT infrastructure. A SOC team should proactively hunt for these signatures in Azure Sentinel to rapidly isolate compromised devices before they are recruited into a broader botnet capable of disrupting critical services or exfiltrating sensitive data.

IOC Summary

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

KQL: Ip Hunt

// Hunt for network connections to known malicious IPs
// Source: ThreatFox - Mirai
let malicious_ips = dynamic(["217.60.195.187", "72.56.52.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(["217.60.195.187", "72.56.52.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(["cmd.5gf7jtfk0y.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 the false positive scenarios and corresponding filters for the ThreatFox: Mirai IOCs detection rule:

• Scenario: Scheduled Vulnerability Scans from Internal Security Appliances

  • Context: Enterprise vulnerability scanners (e.g., Tenable Nessus, Qualys, or Rapid7 InsightVM) regularly probe internal IoT gateways and network devices. These scans often trigger connections to known Mirai-related ports (UDP 23, TCP 80/443) from the scanner’s IP range, which may match the rule’s IOCs if the scanner uses a public IP or specific port patterns associated with Mirai variants.
  • Filter/Exclusion: Exclude traffic originating from the defined CIDR blocks of internal security appliances (e.g., 10.50.20.0/24) and filter out source ports greater than 1024 where the destination is an IoT management VLAN, specifically for protocols UDP/TCP on ports 23, 80, and 443 during business hours (09:00–17:00).

• Scenario: Firmware Update Jobs via Cloud Management Platforms

  • Context: Automated firmware update mechanisms for IoT devices managed by platforms like Cisco Meraki, Ubiquiti UniFi, or AWS IoT Core. These scheduled jobs (often running nightly at 02:00) initiate outbound connections to vendor update servers. If the vendor’s update server IP or specific TLS fingerprint overlaps with Mirai IOCs, legitimate update traffic will trigger alerts.
  • Filter/Exclusion: Create an exclusion for destination IPs belonging to known vendor update endpoints (e.g., *.meraki.com, *.ubnt.com) and whitelist the specific scheduled job name “Firmware_Upgrade_Task” in the SIEM correlation logic, ensuring alerts only