URLhaus: mirai Malicious URLs

Hunt Hypothesis

This hunt detects adversary behavior where IoT devices or internal hosts communicate with known Mirai botnet command-and-control infrastructure via specific malicious URLs identified by URLhaus. The SOC team should proactively investigate these connections in Azure Sentinel to identify early-stage infections and prevent the lateral spread of the Mirai worm across the network before it escalates into a large-scale DDoS event.

IOC Summary

Threat: mirai Total URLs: 3 Active URLs: 2

KQL: Url Dns Hunt

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

• IoT Device Firmware Updates via Vendor Portals

  • Scenario: Enterprise-managed IoT devices (e.g., Cisco Meraki cameras, Aruba switches) automatically query vendor update servers to check for firmware patches. These legitimate requests often hit domains that host Mirai-related signatures or share IP ranges with known botnet command-and-control infrastructure, triggering the rule when the device downloads a benign update manifest.
  • Filter/Exclusion: Create an exclusion list based on specific Source Hostnames (e.g., *.meraki.com, *.arubanetworks.com) and restrict alerts to non-standard ports if the traffic is strictly HTTPS (443). Alternatively, whitelist the specific URL paths associated with update manifests (e.g., /api/v1/firmware/check).

• Scheduled Security Scanner Probes (Tenable/Nessus)

  • Scenario: Internal vulnerability management tools like Tenable.io or Nessus run scheduled discovery jobs that probe external endpoints to validate certificate validity and service availability. These scanners often simulate traffic patterns similar to Mirai bots by rapidly scanning a list of known malicious URLs from threat intelligence feeds (including URLhaus) as part of their baseline testing, generating hits without actual infection.
  • Filter/Exclusion: Exclude traffic originating from the Source IP ranges assigned to the security scanner infrastructure. Additionally, filter for specific User-Agent strings unique to these tools (e.g., Tenable-Nessus-10.x, NessusAgent) to distinguish them from standard web browser or IoT device traffic.

• IT Admin Manual Threat Intelligence Research

  • Scenario: Security analysts or network engineers manually investigate recent Mirai outbreaks by visiting