ThreatFox: Mirai IOCs

Hunt Hypothesis

This detection rule identifies network traffic matching known Indicators of Compromise (IOCs) from the ThreatFox platform that are specifically linked to Mirai botnet activity. Proactively hunting for these signals in Azure Sentinel is critical because Mirai’s ability to rapidly compromise IoT devices can lead to large-scale DDoS attacks and lateral movement within the enterprise network before traditional alerts trigger.

IOC Summary

Malware Family: Mirai Total IOCs: 3 IOC Types: domain

KQL: Domain Hunt

// Hunt for DNS queries to known malicious domains
// Source: ThreatFox - Mirai
let malicious_domains = dynamic(["m4ch.ru", "bd.p0p3w4sh3r3.boats", "test.txtensatorxgyt.xyz"]);
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 documented false positive scenarios and corresponding filters for the ThreatFox: Mirai IOCs detection rule:

• Scheduled IoT Firmware Updates via Vendor Portals

  • Scenario: Enterprise-managed smart devices (e.g., Cisco Meraki APs, Ubiquiti UniFi Controllers) automatically initiate outbound connections to vendor update servers (such as cisco.com or ubnt.com) on a daily schedule. These updates often involve downloading firmware binaries that match the specific hash signatures or domain patterns flagged in the Mirai IOC list.
  • Filter/Exclusion: Create an allow-list for known IoT management subnets (e.g., 10.50.20.0/24) and exclude traffic destined for verified vendor update domains (*.cisco.com, *.ubnt.com) during the defined maintenance window (e.g., 02:00–04:00 UTC).

• Internal Network Scanning by Security Tools

  • Scenario: Internal vulnerability scanners like Tenable Nessus, Qualys, or Microsoft Defender for IoT perform periodic active probing of the network. These tools often simulate traffic patterns similar to Mirai botnets by sending specific TCP/UDP probes to discover open ports on IP ranges, triggering the rule’s signature logic.
  • Filter/Exclusion: Exclude source IPs belonging to the security operations center (SOC) management group and the specific scanner appliances. Additionally, filter out connections where the destination port matches common scanning ports (e.g., TCP 23 for Telnet, UDP 1900 for SSDP) initiated by these known scanner agents.

• DevOps CI/CD Pipeline Artifact Deployment

  • Scenario: Automated build pipelines using Jenkins, GitLab CI, or Azure DevOps deploy containerized microservices to