Elastic Details LLM Triage for Noisy curl and wget Security Alerts

Summary

Elastic details ES|QL COMPLETION triage for noisy cloud curl/wget detections: parse destinations, filter known-good hosts, redact secrets, then use an LLM. A seven-day test had three survivors; the article's alert outcome claims conflict.

Key points

The proposed rules parse destination hosts, filter known-good destinations, redact command-line secrets, aggregate remaining events, then send selected context to an LLM for triage.
Elastic recommends allow-listing parsed destination hosts rather than matching raw command lines, which can create brittle exceptions.
The guidance covers redacting credentials, tokens and signed-URL secrets before inference, limiting rows sent to COMPLETION, and alerting on TP or SUSPICIOUS verdicts above 0.7 confidence.
The workflow depends on process-execution telemetry, such as Elastic Defend or Auditbeat. The article says COMPLETION is generally available in Elastic Cloud Serverless and Elastic Stack 9.3 and later.
In a seven-day QA test, three destinations survived deterministic filtering: two were judged false positives and one suspicious. The detailed results say the suspicious result would create a low-severity alert, conflicting with the article's opening claim that none required analyst review.
The authors recommend using deterministic filters first and reserving LLM triage for ambiguous events, with analysts verifying the model's recommendation before closing or escalating.

Article Details

Defense Focus: Keep noisy curl and wget file-transfer detections enabled in cloud environments by filtering known-benign activity deterministically and using LLM triage for remaining ambiguous events.
Detection Methods: Parse destination hosts from curl and wget process arguments or command lines, then apply allow-lists to the parsed host rather than raw command text.
Redact credentials, tokens, API keys, signed-URL secrets, and JWTs before aggregating events or sending them to the LLM.
Aggregate surviving events by host and destination, include command samples and process context, and cap the rows sent for triage.
Request a structured TP, FP, or SUSPICIOUS verdict and alert only on TP or SUSPICIOUS results with confidence above 0.7.
Suppress duplicate alerts for six hours per host and destination; have analysts verify the destination, commands, parent processes, user context, and process tree.
Data Sources: Process execution events from cloud hosts and containers.
ECS process events, including event.category and process fields such as process.name, process.args, process.command_line, and process.parent.executable.
Auditbeat execution events, including event.action and process.title.
Host, user, and process-lineage context; Auditbeat session metadata may use eBPF or kprobes to enrich lineage.
Rule Types: ES|QL queries and curl/wget detection rules using COMPLETION for structured LLM triage.
Prebuilt curl and wget rule variants using Elastic Defend and Auditd data sources.
Platforms: Linux
macOS
Cloud hosts and workloads
Kubernetes and containerized workloads
Defensive Actions: Retain deterministic detection rules and use LLM triage as an additive filter rather than a replacement.
Build allow-lists from stable, known-good destinations in the local environment and anchor exceptions to parsed destination hosts.
Configure an inference endpoint within the appropriate trust boundary, redact sensitive command-line data before inference, and limit rows sent to control cost.
Treat model output as a triage recommendation, not a final incident decision; review supporting process and destination context before closing or escalating.
For containerized workloads using Auditbeat, deploy it as a DaemonSet.

MITRE ATT&CK

T1105 · Ingress Tool TransferThe article maps attacker use of curl or wget to transfer tools or payloads onto a compromised host to this technique; it is the rationale for the detections, not an activity observed in the seven-day test.

Vendors

ElasticElastic tested ES|QL COMPLETION on noisy curl and wget detection rules in cloud environments to filter benign activity before alerts reached analysts.

Products

Auditbeat#ESQL_COMPLETION Elastic Cloud ServerlessThis work happened in June 2026, while we were tuning two Elastic Security detection rules on Elastic Cloud Serverless.Elastic DefendYou can collect this data with Elastic Defend or with Auditbeat.Elastic SecurityThat is, we run the newest versions of Elastic Security in our production environment, often before they’re released publicly.Elastic StackES|QL COMPLETION is generally available on Elastic Cloud Serverless and in Elastic Stack 9.3 and later.ElasticsearchThree destinations survived deterministic filtering, Elasticsearch Query Language (ES|QL) COMPLETION triaged all three, and none of them created an alert that an analyst had to open.