ThreatFox: Mirai IOCs

Hunt Hypothesis

This detection rule identifies network traffic matching known Indicators of Compromise (IOCs) from the Mirai botnet to uncover potential IoT device infections and command-and-control communications. Proactively hunting for these signals in Azure Sentinel is critical because Mirai’s ability to rapidly scale into massive DDoS attacks necessitates early identification of compromised endpoints before they can be leveraged for large-scale disruption.

IOC Summary

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

KQL: Ip Hunt

// Hunt for network connections to known malicious IPs
// Source: ThreatFox - Mirai
let malicious_ips = dynamic(["160.250.181.124"]);
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(["160.250.181.124"]);
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(["cc.nhancute.site"]);
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 4 specific false positive scenarios for the ThreatFox: Mirai IOCs detection rule in an enterprise environment, along with suggested filters or exclusions:

• Scenario: Scheduled IoT Firmware Updates via Management Console

  • Context: Enterprise Network Operations teams often use centralized management tools (e.g., Cisco Meraki, Ubiquiti UniFi, or Bosch Building Management Systems) to push firmware updates to a fleet of IP cameras, smart thermostats, and access control panels. These devices frequently initiate outbound connections to vendor update servers that may share IP addresses or ports with known Mirai botnet command-and-control (C2) infrastructure.
  • Filter/Exclusion: Create an exclusion rule for the specific source subnets of the IoT Management VLAN (e.g., 10.50.10.0/24) and whitelist the destination IP ranges associated with the vendor’s update servers identified in the ThreatFox IOC list.

• Scenario: Automated Vulnerability Scanning by Internal Tools

  • Context: Security teams run scheduled vulnerability scans using tools like Tenable Nessus, Qualys, or Rapid7 InsightVM. During a scan, these tools actively probe external IP addresses and ports to verify reachability. If the Mirai IOCs include specific open ports (e.g., UDP 23 for Telnet or TCP 80/443) commonly used by scanning engines, the scanner’s traffic will trigger the rule as it mimics the probing behavior of a Mirai bot.
  • Filter/Exclusion: Exclude traffic originating from the dedicated IP addresses of the vulnerability management appliances (e.g., 192.168.5.10 for Nessus Server) and filter out scan-specific User-Agent strings or destination ports that match the scanning engine’s standard profile.