ThreatFox: Mirai IOCs | SOC Hunt Feed

Hunt Hypothesis

This detection rule identifies network traffic patterns matching known Mirai botnet indicators of compromise to prevent potential IoT device infections and subsequent DDoS amplification attacks. A proactive hunt in Azure Sentinel is critical because Mirai variants frequently target unpatched IoT infrastructure, allowing adversaries to establish a persistent foothold that can rapidly scale into large-scale service disruptions if left undetected.

IOC Summary

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

Type	Value	Threat Type	First Seen	Confidence
ip:port	`185[.]42[.]163[.]55:80`	botnet_cc	2026-08-22	75%
ip:port	`77[.]239[.]124[.]108:1995`	botnet_cc	2026-08-22	100%

KQL: Ip Hunt

// Hunt for network connections to known malicious IPs
// Source: ThreatFox - Mirai
let malicious_ips = dynamic(["77.239.124.108", "185.42.163.55"]);
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(["77.239.124.108", "185.42.163.55"]);
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 5 specific false positive scenarios for the ThreatFox: Mirai IOCs detection rule, including targeted filters and exclusions suitable for an enterprise environment:

Scenario: IoT Device Firmware Updates via Scheduled Tasks
- Context: Enterprise-managed IoT devices (e.g., Cisco IP Cameras, Ubiquiti Access Points) often perform automatic firmware checks or updates during off-hours. These devices may initiate outbound connections to vendor update servers that share the same IP ranges or domain patterns as known Mirai IOCs.
- Filter/Exclusion: Create a whitelist for specific IoT subnets (e.g., 10.50.20.0/24) and exclude traffic originating from these subnets to known vendor update domains (e.g., *.cisco.com, *.ubnt.com). Additionally, filter alerts occurring during the defined maintenance window (e.g., 02:00–04:00 UTC).
Scenario: Security Scanner and Vulnerability Management Tools
- Context: Internal vulnerability scanners like Tenable Nessus, Qualys, or Rapid7 InsightVM actively probe external IPs to assess threat intelligence feeds. These tools frequently query public IP addresses that are currently flagged in ThreatFox as Mirai-associated, triggering the detection logic when the scanner itself initiates the connection.
- Filter/Exclusion: Exclude source IPs belonging to security management appliances (e.g., 192.168.50.10-15 for Nessus servers). Implement a rule that suppresses alerts if the initiating process name matches known scanner executables such as nessuscli.exe, qualyspcd.exe, or insightvm-agent.
Scenario: Automated Cloud Backup and Synchronization Jobs
- Context: Scheduled backup jobs using