ThreatFox: Mirai IOCs | SOC Hunt Feed

Hunt Hypothesis

This detection rule identifies network traffic matching known Indicators of Compromise (IOCs) from the Mirai botnet to uncover active IoT device infections or lateral movement attempts within the environment. Proactively hunting for these signatures in Azure Sentinel is critical due to Mirai’s high severity and its proven capability to launch large-scale DDoS attacks that can rapidly compromise cloud-connected infrastructure.

IOC Summary

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

Type	Value	Threat Type	First Seen	Confidence
ip:port	`91[.]199[.]133[.]133:8080`	botnet_cc	2026-07-29	75%
ip:port	`78[.]153[.]149[.]82:80`	botnet_cc	2026-07-29	75%
ip:port	`45[.]90[.]163[.]37:35342`	botnet_cc	2026-07-29	100%

KQL: Ip Hunt

// Hunt for network connections to known malicious IPs
// Source: ThreatFox - Mirai
let malicious_ips = dynamic(["45.90.163.37", "91.199.133.133", "78.153.149.82"]);
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(["45.90.163.37", "91.199.133.133", "78.153.149.82"]);
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, along with targeted filters and exclusions suitable for an enterprise environment:

Scenario: IoT Device Firmware Updates via Vendor Portals
- Context: Enterprise-managed IoT devices (e.g., smart thermostats, conference room cameras) often initiate outbound connections to vendor update servers that share IP ranges or domain patterns with known Mirai command-and-control (C2) infrastructure.
- Filter/Exclusion: Create a whitelist exclusion for the specific source subnets assigned to the IoT VLAN (e.g., 10.50.x.x) and exclude destination IPs belonging to verified vendor domains (e.g., *.samsung.com, *.hikvision.com).
Scenario: Scheduled Network Scanning by Security Tools
- Context: Automated vulnerability scanners like Tenable Nessus, Qualys, or Nmap scripts often probe external IP ranges that overlap with Mirai IOCs during their nightly scheduled jobs, triggering alerts when the scanner mimics a bot’s connection pattern.
- Filter/Exclusion: Exclude traffic originating from known security appliance IPs (e.g., 192.168.10.5 for Nessus) and filter out events where the source process is identified as nessus.exe, qualyspc-agent.exe, or nmap.
Scenario: Cloud Backup Agents Syncing to Public Repositories
- Context: Enterprise backup solutions such as Veeam, Rubrik, or Acronis frequently establish connections to public cloud storage endpoints (AWS S3, Azure Blob) that may utilize IP addresses flagged in the Mirai IOC list due to shared hosting infrastructure.
- Filter/Exclusion: Implement a rule exclusion for