ThreatFox: Mirai IOCs

Hunt Hypothesis

This hypothesis posits that adversaries are actively scanning internal Azure workloads using known Mirai botnet indicators to identify vulnerable IoT devices and establish initial footholds. Proactive hunting for these specific IOCs within Azure Sentinel is critical to detect early-stage reconnaissance activities before they evolve into large-scale distributed denial-of-service attacks or lateral movement campaigns.

IOC Summary

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

KQL: Ip Hunt

// Hunt for network connections to known malicious IPs
// Source: ThreatFox - Mirai
let malicious_ips = dynamic(["167.99.95.139"]);
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(["167.99.95.139"]);
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(["anakkontolmemek.my.id", "firmwareupdatechecksdoidv2627.buzz"]);
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 specific false positive scenarios for the ThreatFox: Mirai IOCs detection rule, tailored for an enterprise environment:

• Automated IoT Firmware Update Scans

  • Scenario: The network team utilizes Tenable Nessus or Qualys to perform scheduled vulnerability assessments on a fleet of IP cameras and VoIP phones. During these scans, the agents actively probe device ports (specifically TCP/23 for Telnet) against known Mirai IOCs to verify patch levels, generating legitimate traffic that matches the rule’s signature.
  • Filter/Exclusion: Exclude source IPs belonging to the vulnerability management server subnet and destination ports 23 (Telnet) where the traffic direction is outbound from the scanner to the IoT segment.

• Administrative Remote Access via RDP/Telnet

  • Scenario: Network engineers use Microsoft Remote Desktop Protocol (RDP) or legacy PuTTY sessions to manage a specific batch of industrial control systems (ICS) that run on older firmware versions containing Mirai-related signatures. These administrative connections often trigger the rule when accessing devices during maintenance windows.
  • Filter/Exclusion: Create an exclusion for traffic originating from known “Jump Host” or “Bastion Host” IP addresses (e.g., 10.20.50.x) destined for the ICS VLAN, specifically allowing connections to ports 23, 80, and 443.

• Scheduled Backup Jobs on Legacy NAS Devices

  • Scenario: An enterprise backup solution like Veeam Backup & Replication or Commvault initiates nightly synchronization jobs with legacy Network Attached Storage (NAS) units. These devices often communicate using protocols that overlap with Mirai’s IOCs, causing the detection engine to flag the high-volume data transfer as a potential botnet command