URLhaus: d52f85 Malicious URLs

Hunt Hypothesis

This detection identifies adversary activity involving web traffic to specific malicious URLs flagged by URLhaus with the tag d52f85, which often indicates active phishing campaigns or command-and-control communications. A SOC team should proactively hunt for these indicators in Azure Sentinel to rapidly isolate compromised endpoints and prevent lateral movement before attackers can exfiltrate sensitive data or establish persistent access.

IOC Summary

Threat: d52f85 Total URLs: 2 Active URLs: 0

KQL: Url Dns Hunt

// Hunt for DNS resolution of URLhaus malicious domains
// Threat: d52f85
let malicious_domains = dynamic(["62.60.226.140"]);
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(["62.60.226.140"]);
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 and corresponding filters for the URLhaus: d52f85 Malicious URLs detection rule:

• Scenario: Enterprise Endpoint Protection agents (e.g., CrowdStrike Falcon or Microsoft Defender for Endpoint) automatically query the URLhaus API to update their local threat intelligence feeds during nightly maintenance windows.

  • Filter/Exclusion: Create an exclusion based on the source process name (FalconService.exe or MsMpEng.exe) and restrict the rule trigger to only apply when the user context is a system account (e.g., NT AUTHORITY\SYSTEM) rather than interactive users.

• Scenario: IT administrators run scheduled PowerShell scripts using Invoke-WebRequest to validate new software deployment URLs against the URLhaus database before pushing updates to the fleet via SCCM or Intune.

  • Filter/Exclusion: Exclude network traffic originating from specific “Management Workstations” (identified by hostname pattern, e.g., ADM-*) and filter out requests where the HTTP User-Agent string contains keywords like “PowerShell” or “SCCM”.

• Scenario: The corporate SIEM or EDR platform performs a daily automated health check by pinging known URLhaus endpoints to verify connectivity and API latency.

  • Filter/Exclusion: Add an exclusion for the specific IP address of the internal SIEM collector node (e.g., 10.20.30.45) or whitelist the destination domain urlhaus.abuse.ch if the rule is flagging the query to the API itself rather than a malicious external link.

• Scenario: A third-party vulnerability scanner (such as Qualys or Tenable) executes a scheduled scan that includes an external reputation check module, which queries URLhaus for every discovered asset’s entry point.

  • Filter/Exclusion: Filter out alerts where the source process is