URLhaus: mirai Malicious URLs

Hunt Hypothesis

This hunt targets the exploitation of known Mirai malware URLs to identify compromised IoT devices that may be serving as entry points for botnet recruitment or DDoS attack orchestration. Proactively hunting for these indicators in Azure Sentinel is critical because Mirai infections often operate silently on unmanaged edge devices, allowing adversaries to build distributed attack infrastructure before a major disruption event occurs.

IOC Summary

Threat: mirai Total URLs: 5 Active URLs: 3

KQL: Url Dns Hunt

// Hunt for DNS resolution of URLhaus malicious domains
// Threat: mirai
let malicious_domains = dynamic(["42.242.42.226", "112.198.186.190"]);
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(["42.242.42.226", "112.198.186.190"]);
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

• IoT Device Firmware Updates via Internal Mirror

  • Scenario: In a large enterprise, IoT devices (such as IP cameras or smart thermostats) are configured to pull firmware updates from an internal HTTP mirror server (e.g., http://10.20.1.5/firmware/) to avoid external bandwidth costs. If the URLhaus feed includes a generic path or a specific vendor URL that matches the internal mirror’s structure or if the device resolves the internal hostname to a public IP due to DNS misconfiguration, legitimate update traffic may match the malicious URL pattern.
  • Filter/Exclusion: Exclude traffic where the source IP belongs to the IoT VLAN range (e.g., 10.20.0.0/16) and the destination port is 80/8080, specifically filtering out known internal mirror hostnames or IP ranges (e.g., src_ip in [10.20.0.0/16] and dst_port in [80, 8080]).

• Legacy Application Health Checks

  • Scenario: A legacy Java-based application server uses a hardcoded health check URL (e.g., http://status.mirai-internal.com/health) that was chosen by the original developer without checking for name collisions with known malware domains. The application runs a scheduled cron job every 5 minutes to ping this URL to verify service availability. If the domain status.mirai-internal.com is registered or appears in the URLhaus feed due to a typo-squatting or historical association, the periodic health check triggers the alert.
  • Filter/Exclusion: Create an exclusion for the specific user-agent string associated with the legacy app (e.g., User-Agent: "LegacyApp-HealthCheck/1.0") or exclude the specific URL path /health