URLhaus: mirai Malicious URLs

Hunt Hypothesis

This hunt targets adversary behavior where IoT devices or internal workstations 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 to detect early-stage botnet infections before they escalate into large-scale DDoS attacks or lateral movement campaigns within the network.

IOC Summary

Threat: mirai Total URLs: 4 Active URLs: 4

KQL: Url Dns Hunt

// Hunt for DNS resolution of URLhaus malicious domains
// Threat: mirai
let malicious_domains = dynamic(["110.138.10.48", "123.11.176.76", "182.126.116.115"]);
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(["110.138.10.48", "123.11.176.76", "182.126.116.115"]);
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 IT Management Tools

  • Scenario: Enterprise Network Attached Storage (NAS) devices or Unified Threat Management (UTM) appliances (e.g., Synology, Fortinet, or Cisco Meraki) periodically contact the vendor’s update servers to check for firmware patches. The Mirai botnet often targets IoT and network infrastructure; consequently, legitimate traffic from these management tools to vendor repositories may contain URL patterns flagged as “Mirai” by URLhaus due to shared IP ranges or similar domain structures used in firmware distribution.
  • Suggested Filter: Create an exclusion for outbound traffic originating from specific internal subnets dedicated to Network Operations (e.g., 10.20.50.0/24) destined for known vendor update domains (e.g., *.synology.com, *.fortinet.net). Alternatively, whitelist the specific destination IPs associated with these vendors in the SIEM correlation rule.

• Scheduled Vulnerability Assessment Scans

  • Scenario: Scheduled vulnerability scanners such as Tenable Nessus or Qualys run nightly jobs to probe internal and external assets for known CVEs. During a scan of IoT devices (which are prime Mirai targets), the scanner may actively resolve and request URLs from public threat intelligence feeds or benchmark servers that URLhaus has tagged with the “Mirai” signature. These requests are part of the scanning logic rather than an actual compromise of the endpoint initiating the connection.
  • Suggested Filter: Implement a filter to exclude traffic where the source process name matches known scanner executables (e.g., nessus.exe, qualysagent.service) and the destination URL contains keywords related to threat intelligence feeds or benchmarking services.