URLhaus: malware_download Malicious URLs

Hunt Hypothesis

The hypothesis is that the detected malicious URLs are used by adversaries to download malware onto compromised systems, leveraging Azure Sentinel to identify and disrupt initial compromise vectors. SOC teams should proactively hunt for these URLs to prevent lateral movement and data exfiltration in their environment.

IOC Summary

Threat: malware_download Total URLs: 3 Active URLs: 3

KQL: Url Dns Hunt

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

• Scenario: A system administrator is downloading a known malicious URL as part of a security test or penetration testing exercise.
  Filter/Exclusion: Exclude URLs that match known security testing domains (e.g., testmalicious.com, vulnscan.org) or include a tag like security_test in the URL.

• Scenario: A scheduled job runs a script that fetches a legitimate update from a trusted source, but the URL is flagged due to a similarity with a known malicious pattern.
  Filter/Exclusion: Exclude URLs that match known update servers (e.g., updates.microsoft.com, download.mozilla.org) or use a field like http_request_full_uri to filter by known safe domains.

• Scenario: An IT admin is manually testing a new endpoint detection and response (EDR) tool by simulating a malware download to validate detection capabilities.
  Filter/Exclusion: Exclude URLs that contain a specific test identifier (e.g., test-malware-download-2024) or include a tag like test_payload in the request headers.

• Scenario: A user is downloading a legitimate software update from a third-party repository, which is mistakenly flagged due to a similarity with a known malicious URL.
  Filter/Exclusion: Exclude URLs that match known software update repositories (e.g., repo.packagist.org, downloads.sourceforge.net) or use a field like process_name to filter by known legitimate update processes.

• Scenario: A system is configured to periodically fetch logs from a centralized logging server, and the URL used for log retrieval is flagged as malicious.
  Filter/Exclusion: Exclude URLs that match internal logging servers (e.g., logs.internal.corp, syslog.corp) or include a tag like log_retrieval in the request context.