ThreatFox: Mirai IOCs | SOC Hunt Feed

Hunt Hypothesis

This detection identifies network traffic matching five specific Indicators of Compromise (IOCs) linked to the Mirai botnet, signaling potential IoT device compromise and command-and-control communication. Proactively hunting for these signatures in Azure Sentinel is critical to rapidly isolate infected endpoints before they are leveraged as part of a larger distributed denial-of-service (DDoS) attack or lateral movement campaign.

IOC Summary

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

Type	Value	Threat Type	First Seen	Confidence
ip:port	`80[.]225[.]83[.]93:4444`	botnet_cc	2026-08-06	75%
ip:port	`110[.]42[.]64[.]35:80`	botnet_cc	2026-08-06	100%
ip:port	`216[.]9[.]226[.]211:23`	botnet_cc	2026-08-06	100%
ip:port	`216[.]9[.]226[.]211:123`	botnet_cc	2026-08-06	100%
ip:port	`156[.]246[.]90[.]214:23`	botnet_cc	2026-08-06	100%

KQL: Ip Hunt

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

Required Data Sources

Sentinel Table	Notes
`CommonSecurityLog`	Ensure this data connector is enabled
`DeviceNetworkEvents`	Ensure this data connector is enabled

References

ThreatFox — Mirai

False Positive Guidance

Here are 4 specific false positive scenarios for the ThreatFox: Mirai IOCs detection rule, along with targeted filtering strategies:

Scenario: Automated Firmware Updates via IoT Management Platform
- Context: Enterprise IoT management tools (e.g., Cisco Meraki, Ubiquiti UniFi, or Bosch Building Technologies) often perform scheduled firmware updates on networked devices. These updates may trigger outbound connections to vendor update servers that share IP addresses or domain hashes with known Mirai botnet command-and-control (C2) infrastructure.
- Filter/Exclusion: Create a whitelist exclusion for the specific source IPs of the IoT management server and the destination domains used by the firmware repository. Additionally, filter alerts where the process name matches meraki-firmware-updater or unifi-cloud-key.
Scenario: Scheduled Vulnerability Scans on Network Infrastructure
- Context: Security teams utilize tools like Tenable Nessus, Qualys, or Rapid7 InsightVM to run nightly vulnerability scans against the internal network. These scanners often probe IoT devices and may initiate connections that mimic Mirai’s port scanning behavior (e.g., probing UDP ports 23, 80, 443) which are part of the rule’s IOC set.
- Filter/Exclusion: Exclude traffic originating from the dedicated vulnerability scanner subnets or specific service accounts (e.g., svc-nessus-scan). Implement a time-based filter to suppress alerts during known maintenance windows (e.g., 02:00–04:00 UTC) when these scans are active.
Scenario: Cloud Backup Agents Communicating with Vendor Endpoints
- Context: Data backup agents deployed on file servers or edge devices (such as Veeam, Rubrik, or **