URLhaus: mirai Malicious URLs

Hunt Hypothesis

This hunt targets adversary behavior where IoT devices or internal hosts communicate with known Mirai botnet command-and-control infrastructure 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: 3 Active URLs: 3

KQL: Url Dns Hunt

// Hunt for DNS resolution of URLhaus malicious domains
// Threat: mirai
let malicious_domains = dynamic(["125.160.131.186", "103.172.186.195", "45.90.163.37"]);
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(["125.160.131.186", "103.172.186.195", "45.90.163.37"]);
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 in an enterprise environment, along with suggested filters or exclusions:

• Automated Firmware Update Scans by Configuration Management Tools

  • Scenario: Enterprise network devices (routers, switches) and IoT gateways often run scheduled background checks against known firmware repositories. Tools like Ansible, Chef, or SolarWinds NPM may query public IP ranges associated with the Mirai botnet’s infrastructure to verify connectivity or fetch patch metadata before deploying updates. Since these queries originate from internal management servers rather than user endpoints, they trigger the rule despite being legitimate administrative maintenance.
  • Suggested Filter: Exclude traffic originating from known Configuration Management Server IPs (e.g., 10.20.50.x range) or specific service accounts (e.g., svc_ansible_admin) when accessing URLs containing keywords like /firmware, /update, or /check.

• Threat Intelligence Feeds and SIEM Enrichment Jobs

  • Scenario: Security Operations Centers frequently ingest external threat intelligence feeds to enrich their own detection capabilities. A scheduled job running on a Splunk Heavy Forwarder or an Azure Sentinel data collector might actively poll the URLhaus API or similar repositories (which host Mirai signatures) to update local blocklists. These internal polling mechanisms generate HTTP/HTTPS requests to the exact malicious URLs defined in the rule, creating a “self-detection” loop where the security infrastructure flags its own verification traffic.
  • Suggested Filter: Create an exclusion for source IPs belonging to the SIEM and Threat Intelligence Platform subnets (e.g., 192.168.100.x) and restrict the rule to only trigger on user-facing workstations, excluding infrastructure servers with OS tags like