9 minlow
How Elasticsearch ES|QL COMPLETION turns noisy curl and wget rules into high-fidelity cloud security alerts
The article describes a detection engineering technique developed by Elastic's internal InfoSec team that uses ES|QL COMPLETION (an LLM-invoking query command) to triage curl and wget process execution alerts (mapped to MITRE ATT&CK T1105, Ingress Tool Transfer) after deterministic allow-list filtering and secret redaction. In a 7-day production test, only three destinations survived filtering, and LLM triage correctly classified all three without generating an analyst-facing false positive, demonstrating a hybrid deterministic+LLM approach to reduce alert fatigue on noisy cloud detection rules.
Conf:high
Showing defanged values
- urlhxxps://github[.]com/elastic/detection-rules/blob/main/rules/cross-platform/command_and_control_curl_activity_auditd_llm_triage[.]tomlPrebuilt Elastic detection rule (curl LLM triage, Auditd source) referenced in the article
- urlhxxps://github[.]com/elastic/detection-rules/blob/main/rules/cross-platform/command_and_control_curl_activity_llm_triage[.]tomlPrebuilt Elastic detection rule (curl LLM triage, Elastic Defend source) referenced in the article, published on GitHub
- urlhxxps://github[.]com/elastic/detection-rules/blob/main/rules/cross-platform/command_and_control_wget_activity_auditd_llm_triage[.]tomlPrebuilt Elastic detection rule (wget LLM triage, Auditd source) referenced in the article
- urlhxxps://github[.]com/elastic/detection-rules/blob/main/rules/cross-platform/command_and_control_wget_activity_llm_triage[.]tomlPrebuilt Elastic detection rule (wget LLM triage, Elastic Defend source) referenced in the article
Detection / HunterAnthropic
What Happened
This article is not about an attack — it's a security team at Elastic sharing a new method for reducing false alarms in their monitoring systems. Cloud computers often use common download tools (curl and wget) for normal tasks like installing software, but attackers use the same tools to download malicious files, so security teams must watch for both. Historically this created too many false alarms for analysts to review effectively. Elastic tested using an AI model to automatically double-check which flagged downloads look suspicious versus routine, and the tool worked well without introducing new false alarms, while also including safeguards so attacker text couldn't manipulate the AI's decision-making. Anyone running cloud security monitoring may find this a useful pattern; there is no active threat or vulnerability to respond to here.
Key Takeaways
- Elastic used ES|QL COMPLETION (an LLM-based query command) to triage curl/wget process execution events after deterministic allow-list filtering, reducing analyst-facing alerts to zero false positives during a 7-day cloud fleet test.
- The recommended pattern anchors allow-list filtering to a parsed destination host (dest_host) rather than matching against the raw command line, reducing brittle substring-match bypasses.
- Secrets (auth headers, bearer tokens, API keys, JWTs, embedded URL credentials) are redacted from command lines before aggregation and before being sent to the LLM inference endpoint.
- The LLM prompt explicitly instructs the model to treat all command/URL text as untrusted data and not to trust context words like 'test', 'dev', 'admin', 'ci' as proof of benign intent — a prompt-injection mitigation for attacker-controlled strings appearing in commands.
- Elastic published four prebuilt detection rules (curl/wget, Elastic Defend and Auditd variants) on GitHub implementing this LLM-triage pattern.
Affected Systems
- Linux cloud hosts and containers running curl or wget
- Kubernetes/CI worker nodes
- Environments using Elastic Security / Elastic Defend or Auditbeat for process execution telemetry
- Elastic Stack 9.1+ (technical preview) and 9.3+ (general availability) for ES|QL COMPLETION
Vulnerabilities (CVEs)
None identified.
Attack Chain
- Ingress Tool Transfer: Attacker (or benign automation) executes curl or wget on a Linux cloud host to retrieve a remote file (T1105)
- Detection Parsing: ES|QL parses the destination host from process arguments/command line
- Deterministic Filtering: Known-good hosts (package mirrors, cloud metadata endpoints, internal ranges) are excluded via allow-list anchored to the parsed destination
- Redaction: Secrets (tokens, auth headers, JWTs, embedded credentials) are stripped from the command line before further processing
- LLM Triage: Surviving events are aggregated and sent to an LLM via ES|QL COMPLETION for a structured TP/FP/SUSPICIOUS verdict with confidence score
- Alerting: Only TP/SUSPICIOUS verdicts above a 0.7 confidence threshold generate an alert for analyst review
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: Yes
- Platforms: Elastic Security detection-rules GitHub repository, Elastic Stack ES|QL COMPLETION prebuilt rules
The article describes and references full ES|QL query logic (not reproduced here per policy) and links to four prebuilt Elastic detection rules covering curl/wget LLM-based triage for both Elastic Defend and Auditd data sources, available in the elastic/detection-rules GitHub repository and installable from the Elastic Security prebuilt rules page on Stack 9.3+.
Detection Engineering Assessment
copy:
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | High | The technique relies directly on process execution telemetry (process.name, process.args, process.command_line, parent process, user context) collected via Elastic Defend or Auditbeat, giving strong endpoint visibility into curl/wget invocations and their full argument/process lineage. |
| Network Visibility | Medium | Destination host is parsed from the command line arguments rather than from network flow logs, so visibility depends on capturing full process command-line data; no independent network telemetry (e.g., NetFlow/proxy logs) is described as part of this pipeline. |
| Detection Difficulty | Moderate | Detecting the underlying ingress tool transfer behavior itself is straightforward (matching on curl/wget process names), but distinguishing malicious use from the very high volume of legitimate automation, CI, and package-management activity in cloud environments is difficult without additional context, which is why the article proposes LLM-assisted triage after deterministic filtering. |
Required Log Sources
- Process execution/creation events (ECS event.category=process)
- Auditbeat auditd events (event.action=executed) with add_session_metadata / eBPF or kprobes session enrichment
- Elastic Defend process events including process.command_line, process.args, process.parent.executable, user.name, host.id/host.name
Hunting Hypotheses
copy:
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Hunt for curl or wget executions whose destination host is not present in a known-good allow-list and whose parent process is not a recognized CI/automation binary, which may indicate ingress tool transfer (T1105). | Process execution logs with parsed destination host, process.parent.executable, user.name | Command and Control / Ingress Tool Transfer | Medium — new or infrequently used legitimate infrastructure (new package mirrors, one-off bootstrap scripts) will also appear as low-prevalence destinations |
| Hunt for curl/wget commands where output is piped directly to a shell or interpreter, which is commonly associated with fetch-and-execute payload delivery. | Full process command line / process.args showing pipe-to-shell patterns | Execution | Low-Medium — some legitimate installer scripts also use pipe-to-shell patterns (e.g., vendor install scripts) |
| Hunt for curl/wget destinations that are raw IP literals rather than resolvable domain names, particularly internal cloud provider IP ranges not matching expected infrastructure. | Parsed dest_host field, CIDR matching against known internal ranges | Command and Control | Medium — internal tooling and health checks sometimes use IP literals legitimately |
Control Gaps
- Deterministic allow-list-only detection rules degrade over time as environments change, requiring constant manual tuning or risk becoming permanently noisy and ignored
- Rules matching on raw command-line substrings rather than a parsed destination field can be bypassed or falsely triggered when the allow-listed string appears in an unrelated parameter or path
- Without redaction controls, sending raw command-line data to third-party or cloud-hosted LLM inference endpoints risks leaking credentials and tokens outside the trust boundary
- LLM triage verdicts are a recommendation, not authoritative; environments relying solely on automated FP suppression without analyst review of TP/SUSPICIOUS verdicts risk missing context needed for full incident response
Key Behavioral Indicators
- curl or wget process executions with a destination host not present in an established allow-list
- curl/wget destination host appearing on very few distinct hosts within the environment (low prevalence) versus high-volume, stable, known-good destinations
- curl/wget process ancestry inconsistent with expected CI/automation parent processes
- Presence of authorization headers, bearer tokens, or embedded URL credentials in curl/wget command-line arguments (a data-handling risk indicator, not itself malicious)
- Destination host resolving to a raw IP literal within cloud provider internal ranges rather than an expected domain
False Positive Assessment
Medium — the article itself is about reducing false positives in curl/wget detection rules; residual false-positive risk remains for low-prevalence but legitimate destinations (new internal services, one-off automation, public DNS-over-HTTPS) that have not yet been added to allow-lists, as illustrated by the SUSPICIOUS verdict on an internal AWS IP in the article's own test.
Recommendations
Immediate Mitigation
defender takeaway
- Verify against your organization's incident response runbook and team escalation paths before acting: consider auditing existing curl/wget detection rules for excessive false-positive rates that may be causing analysts to reflexively dismiss alerts.
- If currently disabling noisy curl/wget rules due to volume, consider re-enabling them with an added deterministic allow-list stage anchored to parsed destination host rather than raw command-line matching.
- Where LLM-based triage capability is available in your SIEM/detection platform, consider piloting it on a low-risk, high-noise rule before broader rollout.
Infrastructure Hardening
- Consider deploying process execution telemetry (e.g., Elastic Defend or Auditbeat with session metadata enrichment) as a DaemonSet across containerized workloads to gain full process lineage visibility.
- Evaluate restricting or monitoring outbound connections from cloud hosts to reduce the pool of destinations an ingress tool transfer could reach undetected.
- If using an LLM inference endpoint for detection triage, ensure it resides within your organization's trust boundary and evaluate redaction logic before command-line data is sent to any external service.
User Protection
- Consider auditing which service accounts or automation identities are permitted to run curl/wget with elevated privileges on production cloud hosts.
- Where feasible, evaluate constraining outbound curl/wget usage on production hosts to a defined allow-list at the host/network policy level as defense-in-depth beyond detection alone.
Security Awareness
- Consider briefing detection engineering and SOC teams on the risks of prompt injection via attacker-controlled command-line or URL text when integrating LLMs into detection pipelines.
- Consider incorporating lessons on redacting secrets from telemetry before sending to any third-party or AI-based analysis service into existing data-handling training.
MITRE ATT&CK Mapping
MITRE ATT&CK Mapping1 technique
Tactic
Command and Control
Additional IOCs
- Urls:
hxxps://github[.]com/elastic/detection-rules/blob/main/rules/cross-platform/command_and_control_curl_activity_llm_triage.toml- Prebuilt Elastic detection rule (curl LLM triage, Elastic Defend source) referenced in the article, published on GitHubhxxps://github[.]com/elastic/detection-rules/blob/main/rules/cross-platform/command_and_control_curl_activity_auditd_llm_triage.toml- Prebuilt Elastic detection rule (curl LLM triage, Auditd source) referenced in the articlehxxps://github[.]com/elastic/detection-rules/blob/main/rules/cross-platform/command_and_control_wget_activity_llm_triage.toml- Prebuilt Elastic detection rule (wget LLM triage, Elastic Defend source) referenced in the articlehxxps://github[.]com/elastic/detection-rules/blob/main/rules/cross-platform/command_and_control_wget_activity_auditd_llm_triage.toml- Prebuilt Elastic detection rule (wget LLM triage, Auditd source) referenced in the article
