URLhaus: mirai Malicious URLs

Hunt Hypothesis

This detection rule identifies network traffic connecting to known Mirai botnet command-and-control URLs, signaling potential IoT device compromise or lateral movement by adversaries leveraging this malware family. Proactive hunting for these indicators within Azure Sentinel is critical to rapidly isolate infected endpoints and prevent the propagation of large-scale distributed denial-of-service (DDoS) attacks before they impact broader infrastructure.

IOC Summary

Threat: mirai Total URLs: 9 Active URLs: 8

KQL: Url Dns Hunt

// Hunt for DNS resolution of URLhaus malicious domains
// Threat: mirai
let malicious_domains = dynamic(["129.121.110.105", "77.247.88.82", "105.184.183.213", "31.56.209.70"]);
DnsEvents
| where Name has_any (malicious_domains)
| project TimeGenerated, Computer, Name, IPAddresses
| order by TimeGenerated desc

KQL: Url Proxy Hunt

// Hunt for web traffic to URLhaus malicious domains
let malicious_domains = dynamic(["129.121.110.105", "77.247.88.82", "105.184.183.213", "31.56.209.70"]);
CommonSecurityLog
| where RequestURL has_any (malicious_domains) or DestinationHostName has_any (malicious_domains)
| project TimeGenerated, SourceIP, RequestURL, DestinationHostName, DeviceAction
| order by TimeGenerated desc

Required Data Sources

References

• URLhaus

False Positive Guidance

Here are specific false positive scenarios and corresponding filters for the URLhaus: mirai Malicious URLs detection rule in an enterprise environment:

• Scenario: IoT Device Firmware Updates via Vendor Portals

  • Context: Enterprise-managed IoT devices (e.g., Cisco IP cameras, Ubiquiti access points) frequently connect to vendor update servers to check for or download firmware patches. These URLs often share the same domain patterns and hash signatures as Mirai-infected devices because they originate from similar embedded Linux environments.
  • Filter/Exclusion: Create an allowlist based on specific FQDNs of known IoT vendors (e.g., firmware.cisco.com, update.ui.com) or exclude traffic originating from the dedicated “IoT VLAN” subnet (e.g., 10.50.20.0/24) where these devices reside, provided they are managed by the asset inventory team.

• Scenario: Scheduled Security Scanning and Vulnerability Assessment

  • Context: Automated vulnerability scanners like Tenable Nessus, Qualys, or Rapid7 InsightVM regularly probe internal network segments to identify open ports (specifically port 23 for Telnet, which Mirai targets) and active services. These tools often generate outbound traffic to their own cloud management consoles that may be flagged as Mirai-related due to similar URL structures.
  • Filter/Exclusion: Exclude source IP addresses belonging to the security operations team’s scanning appliances (e.g., 192.168.10.5 for Nessus) and filter out traffic occurring during defined maintenance windows (e.g., 02:00–04:00 UTC daily) when these scheduled jobs run.

• Scenario: Cloud Backup and Synchronization Agents

  • Context: Endpoint backup agents such as **