URLhaus: elf Malicious URLs

Hunt Hypothesis

This detection identifies adversary activity involving newly discovered ELF (Executable and Linkable Format) malware distributed via malicious URLs tracked by URLhaus. Proactive hunting is essential in Azure Sentinel to rapidly isolate compromised endpoints before these executable threats can establish persistence or initiate lateral movement within the network.

IOC Summary

Threat: elf Total URLs: 3 Active URLs: 1

KQL: Url Dns Hunt

// Hunt for DNS resolution of URLhaus malicious domains
// Threat: elf
let malicious_domains = dynamic(["68.168.20.218"]);
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(["68.168.20.218"]);
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 exclusion strategies for the URLhaus: elf Malicious URLs detection rule in an enterprise environment:

• Scenario: Automated Antivirus Definition Updates via Cloud Repositories

  • Context: Enterprise Endpoint Protection suites (e.g., CrowdStrike Falcon, Microsoft Defender for Endpoint) frequently pull definition updates from cloud repositories. These update packages often contain embedded ELF binaries or scripts that are fetched over HTTPS, which URLhaus may flag as “elf” due to the file type signature in the payload.
  • Filter/Exclusion: Create a whitelist entry for the specific vendor’s update domain (e.g., *.crowdstrike.com, *.microsoft.com) and exclude traffic originating from known management server IPs or service accounts running the update agent (e.g., svc_defender_update).

• Scenario: Scheduled CI/CD Pipeline Artifact Downloads

  • Context: DevOps teams using tools like Jenkins, GitLab CI, or GitHub Actions regularly download build artifacts, Docker images, or container layers from internal registries (e.g., Harbor, AWS ECR) during scheduled nightly builds. These artifacts often include ELF executables that trigger the rule when accessed by the pipeline runner service.
  • Filter/Exclusion: Implement a time-based exclusion window for known build windows (e.g., 01:00–05:00 UTC) and filter out URLs containing specific CI/CD path patterns (e.g., */api/v1/artifacts/*) or exclude the service account identity used by the pipeline runner.

• Scenario: Internal Software Deployment via Configuration Management

  • Context: System administrators using Ansible, Puppet, or SCCM deploy new applications or patches to endpoints. During these deployments, agents download installation packages (often `.deb