URLhaus: arm Malicious URLs

Hunt Hypothesis

This rule detects adversary behavior involving the exploitation of ARM-based endpoints through interactions with known malicious URLs identified by URLhaus. A SOC team should proactively hunt for this activity in Azure Sentinel to rapidly identify and isolate compromised devices before attackers can establish persistence or exfiltrate sensitive data from mobile or embedded systems.

IOC Summary

Threat: arm Total URLs: 13 Active URLs: 9

KQL: Url Dns Hunt

// Hunt for DNS resolution of URLhaus malicious domains
// Threat: arm
let malicious_domains = dynamic(["94.154.43.238", "193.233.82.82", "31.77.227.111"]);
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(["94.154.43.238", "193.233.82.82", "31.77.227.111"]);
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 4 specific false positive scenarios for the URLhaus: arm Malicious URLs detection rule in an enterprise environment, along with targeted filters or exclusions:

• Endpoint Protection Scanner Updates

  • Scenario: The organization’s endpoint protection suite (e.g., CrowdStrike Falcon, Microsoft Defender for Endpoint, or Symantec) automatically downloads definition updates and threat intelligence feeds from the vendor’s update servers. These URLs often contain dynamic parameters or hash values that match the “arm” signature pattern used by URLhaus.
  • Filter/Exclusion: Create an exclusion rule based on the specific destination IP ranges of the EDR vendor (e.g., 13.107.42.16 for Microsoft) or whitelist the exact update domain suffix (e.g., *.update.microsoft.com, *.crowdstrike.com).

• Automated Patch Management Deployments

  • Scenario: Scheduled jobs running via tools like SCCM, Ansible, or WSUS initiate background downloads of patch manifests and installation packages from public repositories. These processes frequently access URLs tagged with “arm” architecture identifiers during the pre-download verification phase, triggering the rule even though the content is benign.
  • Filter/Exclusion: Exclude traffic originating from specific Service Accounts (e.g., svc-patch-deploy) or filter by the User-Agent string containing known patch management tool identifiers (e.g., WSUSClient, SCCM-Client).

• Cloud Backup and Synchronization Services

  • Scenario: Enterprise backup agents (such as Veeam, Rubrik, or Azure Backup) perform scheduled synchronization tasks with cloud storage endpoints. The URLs generated during the handshake and metadata exchange often utilize ARM-based API endpoints that align with the detection logic’s signature for malicious “arm” traffic.
  • Filter/Exclusion: Implement a filter