LLM-Based Triage of Wget Activity on Linux Hosts

Elastic has released an LLM-powered detection rule designed to identify potentially malicious wget activity on Linux systems. This rule, updated in July 2026, integrates with Auditd Manager or Auditbeat to collect process execution events, specifically targeting wget invocations. It normalizes command-line arguments, redacts sensitive information like credentials, and then uses Elastic's General Purpose LLM v2 to assess whether the activity indicates ingress tool transfer (T1105), command and control (TA0011), or data exfiltration (T1048, T1005). The rule is configured to filter out known benign wget destinations, such as local loopbacks, cloud platform services (Azure, GCP), and common vendor repositories (Microsoft, GitHub, Elastic), to reduce false positives. Alerts are generated only for high-confidence (above 0.7) positive or suspicious verdicts from the LLM, providing security teams with intelligent triage for wget usage.

Attack Chain

This brief describes a detection mechanism rather than an observed attack campaign. Therefore, a specific attack chain is not provided, as the rule monitors for general malicious wget activity, which can occur at various stages of an attack.

Impact

Successful malicious wget activity on a Linux host can lead to severe consequences, including remote code execution if an attacker downloads and executes a malicious payload, establishment of persistent command and control (C2) channels for ongoing access, or unauthorized data exfiltration using wget's upload functionalities (--post-file, --post-data, --body-file). The exposure of credentials or tokens via command-line arguments, even if redacted in logs, could facilitate further compromise or lateral movement. The detection rule aims to mitigate these impacts by identifying and triaging such activities promptly, preventing adversaries from achieving their objectives undetected.

Recommendation

• Configure Auditd Manager or Auditbeat on all Linux endpoints to collect process execution events, including process.name, process.args, and process.title, as required by the detection rule.
• Deploy the Sigma rule provided in this brief to your SIEM to detect suspicious wget activity, which can then be further triaged.
• Review the iocs list of explicitly excluded benign destinations and add any additional routine, verified benign wget destinations specific to your environment to your allow-lists to reduce false positives.
• Investigate high-confidence alerts generated by the rule by examining Esql.verdict, Esql.confidence, Esql.summary, Esql.dest_host, and Esql.command_line_values within your Elastic Stack.
• If payload execution, command-and-control, or data exfiltration is confirmed, isolate the affected host immediately.
• Rotate any credentials or tokens that may have been exposed in wget command lines, even if redacted in logs.