URLhaus: mirai Malicious URLs

Hunt Hypothesis

This hunt detects adversary behavior where internal Azure resources attempt to communicate with known Mirai botnet command-and-control servers via specific malicious URLs identified by URLhaus. Proactively hunting for these connections in Azure Sentinel is critical because early identification of Mirai traffic allows the SOC team to isolate compromised IoT or edge devices before they are leveraged for large-scale DDoS attacks or lateral movement within the network.

IOC Summary

Threat: mirai Total URLs: 3 Active URLs: 3

KQL: Url Dns Hunt

// Hunt for DNS resolution of URLhaus malicious domains
// Threat: mirai
let malicious_domains = dynamic(["60.215.23.95", "45.207.196.86", "123.148.225.193"]);
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(["60.215.23.95", "45.207.196.86", "123.148.225.193"]);
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 for the URLhaus: Mirai Malicious URLs detection rule in an enterprise environment, along with suggested filters or exclusions:

• Automated Firmware Update Scans by Network Management Tools

  • Scenario: Enterprise network management platforms like SolarWinds NPM, ManageEngine OpManager, or Cisco DNA Center periodically scan IoT devices (IP cameras, VoIP phones) to check for firmware updates. These tools often query known Mirai-infected public IP ranges or specific vendor update servers that have been previously flagged by URLhaus due to historical botnet activity, even though the current traffic is benign administrative polling.
  • Filter/Exclusion: Create an exclusion rule based on the Source Host (e.g., host.name containing “NMS-Server” or specific IP ranges of management appliances) and restrict the alert to only trigger if the destination port is not standard HTTP/HTTPS (80/443) used for firmware downloads.

• Scheduled Vulnerability Scans by Security Appliances

  • Scenario: Scheduled vulnerability assessments performed by tools like Tenable Nessus, Qualys, or Rapid7 InsightVM often probe external endpoints to verify patch levels. During these scans, the scanner may attempt to resolve and connect to public URLs associated with Mirai botnet command-and-control (C2) infrastructure to validate SSL certificates or check for open ports, generating traffic that matches the “3 malicious URLs” logic despite being a controlled security operation.
  • Filter/Exclusion: Exclude traffic originating from known scanner IP addresses (e.g., source.ip in [10.50.2.0/24]) during defined maintenance windows (e.g., time between 02:00 and 06:00). Additionally, filter out events where the