URLhaus: mirai Malicious URLs

Hunt Hypothesis

This hunt detects adversary behavior where IoT devices or compromised hosts initiate outbound connections to known Mirai botnet command-and-control infrastructure via specific malicious URLs. Proactively hunting for these indicators in Azure Sentinel is critical because early identification of Mirai activity allows the SOC team to isolate infected assets before they are leveraged for large-scale DDoS attacks or lateral movement within the network.

IOC Summary

Threat: mirai Total URLs: 5 Active URLs: 5

KQL: Url Dns Hunt

// Hunt for DNS resolution of URLhaus malicious domains
// Threat: mirai
let malicious_domains = dynamic(["105.186.160.136", "217.60.195.187", "205.237.110.232", "41.216.189.236", "124.135.10.58"]);
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(["105.186.160.136", "217.60.195.187", "205.237.110.232", "41.216.189.236", "124.135.10.58"]);
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 4 specific false positive scenarios for the URLhaus: Mirai Malicious URLs detection rule, tailored for an enterprise environment:

• Automated Firmware Update Scans by Network Management Tools

  • Scenario: Enterprise network management platforms like SolarWinds NPM or ManageEngine OpManager periodically scan connected IoT devices (IP cameras, printers) to check for firmware updates. These tools often query the same public repositories used by Mirai botnets to verify device signatures, triggering hits on URLs associated with mirai even though the traffic is authorized administrative scanning.
  • Filter/Exclusion: Create an exclusion rule that whitelists source IP ranges belonging to the Network Operations Center (NOC) or specific management subnets (e.g., 10.20.50.0/24) when accessing known update vendor domains, regardless of the URLhaus tag.

• Scheduled Vulnerability Assessment Jobs

  • Scenario: Security teams run weekly vulnerability scans using tools like Tenable Nessus or Qualys. During these scheduled jobs, the scanner probes external endpoints to identify open ports and services common in IoT devices. The scanner’s HTTP requests to public intelligence feeds (which Mirai also utilizes) may match the specific URL patterns flagged by the rule, generating alerts for legitimate scanning activity rather than actual malware communication.
  • Filter/Exclusion: Implement a time-based exclusion that suppresses this alert during known maintenance windows (e.g., Sundays 02:00–06:00 UTC) or filter out traffic originating from specific vulnerability scanner appliances identified by their MAC address OUI.

• Cloud-Based Threat Intelligence Feeds Integration

  • Scenario: Internal Security Information and Event Management (SIEM) systems, such as Splunk or Microsoft Sentinel, are configured to pull threat intelligence