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 and prevent lateral movement before the compromised assets are leveraged for large-scale DDoS attacks.

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(["105.224.50.234", "177.86.229.12", "113.233.224.20", "105.186.198.55", "105.225.111.196", "101.21.20.154", "codeinspector.ddns.net"]);
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(["105.224.50.234", "177.86.229.12", "113.233.224.20", "105.186.198.55", "105.225.111.196", "101.21.20.154", "codeinspector.ddns.net"]);
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, tailored for an enterprise environment:

• IoT Device Firmware Updates via Cloud Repositories

  • Scenario: Managed IoT devices (e.g., Cisco Meraki cameras or Honeywell thermostats) automatically contact public firmware update servers. These repositories often host files with signatures that overlap with Mirai botnet command-and-control patterns, triggering alerts when the device downloads a standard patch during business hours.
  • Filter/Exclusion: Create an allowlist for specific destination IP ranges associated with vendor cloud services (e.g., *.meraki.com, *.honeywell.com) and restrict the rule to exclude traffic originating from the dedicated IoT VLAN subnet (10.x.x.0/24).

• Scheduled Vulnerability Scans by Security Appliances

  • Scenario: Enterprise vulnerability scanners like Tenable Nessus or Qualys perform scheduled external asset discovery jobs. During these scans, the scanner probes known public URLs to verify SSL certificates and service availability. If a target URL is flagged in the URLhaus database as “Mirai” but is actually a legitimate third-party API endpoint used by the organization’s internal applications, the scan generates a high-volume false positive.
  • Filter/Exclusion: Exclude traffic originating from the specific IP addresses of security scanning appliances (e.g., 192.168.50.10 for Nessus) and filter out HTTP GET requests where the User-Agent string contains “Tenable” or “Qualys”.

• Automated Backup Jobs to Cloud Storage Gateways

  • Scenario: Automated backup agents (such as Veeam Backup & Replication or Commvault) initiate scheduled jobs to synchronize data with cloud storage gateways. These gateways often utilize URL endpoints for metadata