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 DDoS attacks or lateral movement campaigns across the network.

IOC Summary

Threat: mirai Total URLs: 10 Active URLs: 10

KQL: Url Dns Hunt

// Hunt for DNS resolution of URLhaus malicious domains
// Threat: mirai
let malicious_domains = dynamic(["196.188.135.20", "117.57.51.29", "85.11.167.201", "91.92.42.232", "45.194.50.3", "143.20.185.89"]);
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(["196.188.135.20", "117.57.51.29", "85.11.167.201", "91.92.42.232", "45.194.50.3", "143.20.185.89"]);
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 appliances (e.g., Cisco Meraki, FortiGate) or endpoint management tools (e.g., Microsoft SCCM/Intune) periodically scan known vendor repositories to check for firmware updates. These scans often hit URLs hosted on the same infrastructure as Mirai botnets (common in IoT device manufacturers like TP-Link or Ubiquiti), triggering a match even though the traffic is initiated by trusted management servers.
  • Filter/Exclusion: Create an exclusion rule based on the Source IP of known network management appliances and the Destination URL containing specific vendor domains (e.g., *.cisco.com, *.ubnt.com). Additionally, filter for HTTP status codes 200 or 304 to ensure only successful, expected polling traffic is ignored.

• Scheduled Vulnerability Assessment Scans

  • Scenario: Security teams run weekly vulnerability scans using tools like Tenable Nessus, Qualys, or Rapid7 InsightVM. These scanners actively probe external URLs of IoT devices and third-party APIs to verify certificate validity and service availability. If the scanner probes a URL that has been recently flagged by URLhaus as Mirai-related (perhaps due to a transient issue), it generates an alert despite being a legitimate, scheduled administrative task.
  • Filter/Exclusion: Implement a time-based exclusion for the specific Source IP ranges assigned to vulnerability scanners during their defined maintenance windows (e.g., 02:00 - 04:00 UTC). Alternatively, add an exception for traffic where the User-Agent string contains identifiers like Tenable.Nessus,