URLhaus: xworm Malicious URLs

Hunt Hypothesis

This hunt targets adversaries leveraging the xworm malware family to establish initial footholds via phishing emails and subsequently propagate laterally across network shares using exploit-driven mechanisms. Proactively hunting for these specific URLhaus indicators in Azure Sentinel is critical to detect early-stage lateral movement before the worm can fully compromise internal assets and expand its reach within the enterprise environment.

IOC Summary

Threat: xworm Total URLs: 2 Active URLs: 2

KQL: Url Dns Hunt

// Hunt for DNS resolution of URLhaus malicious domains
// Threat: xworm
let malicious_domains = dynamic(["misty-cherry-cea3.uploadsimg.workers.dev", "sesaddf.kesug.com"]);
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(["misty-cherry-cea3.uploadsimg.workers.dev", "sesaddf.kesug.com"]);
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: xworm Malicious URLs detection rule in an enterprise environment, along with suggested filters or exclusions:

• Legacy File Server Synchronization via SMB Shares

  • Scenario: The xworm rule triggers on internal traffic where legacy file servers (e.g., Windows Server 2016/2019) are synchronizing large datasets across network shares using SMB or HTTP protocols. Since xworm spreads via network shares, the detection logic may flag legitimate internal IP-to-IP communication patterns that mimic the worm’s lateral movement behavior, especially if the traffic originates from known file server subnets accessing standard ports (80/443) for metadata updates.
  • Filter/Exclusion: Create an exclusion rule to whitelist traffic where both the Source and Destination IPs belong to the internal File-Services subnet range (e.g., 10.20.50.0/24) and the User-Agent string contains specific legacy application identifiers like Microsoft-WebDAV-MiniRedir or SMBClient.

• Automated Patch Management and Software Distribution

  • Scenario: Enterprise patch management tools such as SCCM (System Center Configuration Manager) or Ivanti frequently download update manifests, software installers, and security definitions from internal distribution points. These downloads often traverse URLs that contain query parameters or path structures similar to the phishing payloads xworm exploits, causing the rule to flag these routine administrative updates as potential worm infection vectors.
  • Filter/Exclusion: Exclude traffic originating from specific service accounts (e.g., svc_sccm_agent, svc_ivanti_dist) and destination URLs containing known internal repository domains (e.g., .internal.corp.local or specific CDN paths like /updates/microsoft/). Additionally, filter