As reported by Elastic Security Labs, Elastic's internal InfoSec team has demonstrated a compelling real-world application of their ES|QL COMPLETION function — using it to intelligently filter one of the most persistently noisy detection categories in cloud security: curl and wget process executions. The results offer meaningful lessons for detection engineers and SOC leaders wrestling with alert fatigue.
Why curl and wget Rules Have Always Been a Double-Edged Sword
Any seasoned detection engineer knows the frustration. curl and wget are legitimate, ubiquitous tools — used constantly by developers, CI/CD pipelines, container orchestration systems, and package managers. Writing a high-confidence rule around them has historically meant choosing between two bad outcomes: too broad, and you're drowning analysts in false positives; too narrow, and you risk missing real threats like malware staging, C2 beaconing, or unauthorized data exfiltration.
The traditional workarounds — allowlisting known-good parent processes, tuning on specific destination domains, or correlating with other telemetry — help, but they require constant maintenance and domain expertise that many security teams simply don't have bandwidth for. This is precisely the problem Elastic's approach attacks head-on.
The Architecture: Deterministic First, Probabilistic Second
What makes this approach architecturally sound — and worth paying attention to — is that it doesn't abandon deterministic logic in favor of AI. Instead, it layers them deliberately:
- ES|QL handles the structured filtering first — stripping out events that can be confidently explained by business context, known-good process trees, or baseline behavior. This is fast, auditable, and cheap.
- LLM triage is invoked only on the residual ambiguous cases — the events that deterministic rules can't confidently classify. This is where the COMPLETION function earns its place, applying contextual reasoning to edge cases rather than replacing rule logic entirely.
This hybrid model is exactly what mature detection engineering should look like in 2025. AI augmenting human analysts at the triage layer — not replacing the foundational detection logic that security teams have built institutional knowledge around.
Implications for SOC Teams and Detection Engineers
The broader implication here is significant: the bottleneck in most SOCs is no longer data collection — it's signal quality at the analyst queue. High-volume, low-context alerts for commodity tools like curl and wget represent some of the worst offenders for analyst burnout and missed detections buried under noise.
When an LLM can evaluate the surrounding context — the spawning process, the destination, the timing, the user context, the command-line arguments — and render a preliminary triage judgment, it changes the economics of detection. Analysts spend their cognitive capacity on events that genuinely require human judgment, not on clearing queues of package manager update checks.
The real value isn't the AI. It's the architectural discipline of deciding exactly where AI should and shouldn't intervene in your detection pipeline.
Caveats and Risks to Consider
No technology discussion is complete without honest risk assessment. LLM-assisted triage introduces several considerations security leaders must evaluate:
Shield53 Recommendations
For Detection Engineers
- Audit your existing curl/wget detection rules for false positive rates. If your suppression lists are longer than your actual rule logic, it's a signal the current approach isn't scaling.
- Evaluate ES|QL COMPLETION or equivalent LLM-triage patterns as a residual classification layer — not as a replacement for structured logic.
- Build logging into any LLM triage pipeline from day one. Every classification decision should be reviewable.
- Test adversarial inputs against your LLM triage prompts before production deployment — assume threat actors will eventually probe for prompt injection opportunities once this pattern becomes widespread.
For SOC Leaders and CISOs
- Frame LLM-assisted triage as an analyst augmentation investment, not a headcount reduction tool. The efficiency gains should translate into analyst capacity for proactive hunting, not simply fewer staff.
- Establish baseline metrics (alert volume, false positive rate, mean time to triage) before deployment so you can quantify the actual impact.
- Engage your compliance and legal teams early on LLM triage if you operate in regulated industries — understanding what data flows to inference endpoints matters for data residency and privacy obligations.
Elastic's demonstrated application of ES|QL COMPLETION is a meaningful signal of where cloud-native detection engineering is heading. The teams that figure out how to thoughtfully integrate deterministic and probabilistic detection layers will have a material advantage in managing analyst capacity and detection fidelity as cloud telemetry volumes continue to grow.