URLhaus: mirai Malicious URLs

Hunt Hypothesis

This hunt targets adversary behavior where IoT devices or internal systems 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 distributed denial-of-service attacks or lateral movement campaigns.

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(["180.245.46.51", "175.43.138.10", "36.70.238.164"]);
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(["180.245.46.51", "175.43.138.10", "36.70.238.164"]);
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, including suggested filters and exclusions tailored for an enterprise environment:

• Automated Firmware Update Scans by Network Management Tools

  • Scenario: Enterprise network appliances (e.g., Cisco Meraki, Fortinet, or Ubiquiti UniFi) automatically query external firmware repositories or vulnerability databases to check for updates. These tools often scan a wide range of IP addresses and URLs associated with IoT device manufacturers, which may include legacy endpoints previously flagged by URLhaus as Mirai-related before being remediated.
  • Filter/Exclusion: Create an exclusion based on the source host identity (e.g., host.name contains “NMS-Server” or specific asset tags like “Network-Mgmt”) and restrict the rule to trigger only if the user agent is not a known management tool (e.g., exclude User-Agents containing “Meraki-Cloud”, “FortiClient”, or “UniFi-Poller”).

• Scheduled Vulnerability Scans by Security Appliances

  • Scenario: Scheduled jobs running on vulnerability scanners like Tenable Nessus, Qualys, or Rapid7 InsightVM perform deep web content analysis. During these scans, the appliance probes thousands of external URLs to verify SSL certificates and check for known malware signatures. If a scanner probes a Mirai-infected IP that has since been cleaned but still retains the URLhaus tag, it generates a false alert.
  • Filter/Exclusion: Exclude traffic originating from specific service accounts or scanner subnets (e.g., source.ip in range 10.20.50.0/24) and filter by process name (e.g., process.name equals “Nessus.exe” or “QualysAgent”). Additionally, add a condition to suppress alerts if the HTTP status code is `20