« Linux External IP Address Discovery via Curl Payload Downloaded by Interpreter and Piped to Interpreter »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.27

Suspicious Command Execution via Busybox Proxy

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Suspicious Command Execution via Busybox Proxy

edit

This rule detects the execution of command line arguments capable of spawning shells or establishing network connections through Busybox. This technique can be used to execute commands while attempting to evade detection.

Rule type: eql

Rule indices:

  • logs-endpoint.events.process*
  • logs-sentinel_one_cloud_funnel.*

Severity: low

Risk score: 21

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References: None

Tags:

  • Domain: Endpoint
  • OS: Linux
  • Use Case: Threat Detection
  • Tactic: Execution
  • Tactic: Command and Control
  • Tactic: Defense Evasion
  • Data Source: Elastic Defend
  • Data Source: SentinelOne
  • Resources: Investigation Guide

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit
## Triage and analysis

Disclaimer: 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.

Investigating Suspicious Command Execution via Busybox Proxy

This rule flags Busybox being used as a proxy to launch shells or make outbound connections on Linux, a common way to hide command execution behind a trusted multi-call binary and slip past simple detections. An intruder can drop a script or binary in /tmp or /dev/shm, then run Busybox sh with /dev/tcp, nc, or openssl to establish a reverse shell and execute follow-on commands.

Possible investigation steps

  • Reconstruct the full execution chain around the Busybox invocation to identify the initiating script or binary, the user or service account involved, and whether the parent came from a writable or ephemeral location such as /tmp, /dev/shm, or a hidden working directory.
  • Retrieve and analyze any files or command artifacts referenced in the invocation, including shell scripts, dropped binaries, or inline payloads, and compare their hashes and prevalence against internal baselines and external reputation sources.
  • Review adjacent host activity for follow-on behavior consistent with staging or hands-on-keyboard access, such as additional shell launches, curl or wget downloads, permission changes, archive extraction, credential access attempts, or persistence creation via cron, systemd, or startup scripts.
  • Pivot to network telemetry from the same host and time window to determine whether Busybox or its descendants established outbound sessions, then validate the destination IPs, domains, ports, and protocols against expected business use and known benign infrastructure.
  • Confirm whether the behavior is expected for the asset type, container image, or embedded tooling in use, and if the activity is not readily explained, isolate the host and collect volatile evidence such as active connections, running processes, loaded modules, and recent shell history.

False positive analysis

  • Container or host startup scripts may invoke busybox sh with nc, openssl, or /dev/tcp from a temporary path to wait for a local dependency or perform a health check; verify the parent script is part of the expected image or boot workflow and that the destination is a known internal service.
  • An administrator or automation task may stage a temporary script under /tmp, /var/tmp, or a user home directory that uses busybox sh to test port reachability or TLS negotiation during troubleshooting; confirm the initiating account and script contents against approved maintenance activity and check that no suspicious follow-on processes or outbound connections occurred.

Response and remediation

  • Isolate the affected Linux host from the network, terminate the malicious busybox process and any spawned shells, and block the destination IPs, domains, and ports used by the outbound session or reverse shell.
  • Preserve copies of the parent script or binary from locations such as /tmp, /var/tmp, or /dev/shm, then remove attacker persistence including cron jobs, systemd service files, rc.local changes, startup scripts, and unauthorized authorized_keys entries tied to the same activity.
  • Reset passwords, revoke tokens, and rotate SSH keys or application secrets for any user or service account that launched Busybox or was exposed on the host, especially when shell history, environment files, or config files contained credentials.
  • Reimage the host or restore it from a known-good baseline, verify trusted package integrity for replaced binaries and scripts, and return the system to service only after confirming no unexpected executables remain in writable or temporary directories.
  • Escalate to incident response immediately if the Busybox session ran as root, reached an external address, created persistence beyond a single host, or if other systems show the same dropped script, destination, or follow-on shell activity.
  • Harden the environment by restricting Busybox execution to approved administrative use, mounting temporary directories with noexec where feasible, limiting unnecessary outbound egress, and adding detections for shell-capable Busybox usage launched from temporary, hidden, or user-writable paths.

Setup

edit

Setup

This rule requires data coming in from one of the following integrations: - Elastic Defend

Elastic Defend Integration Setup

Elastic 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.

Prerequisite Requirements:

  • Fleet is required for Elastic Defend.
  • To configure Fleet Server refer to the documentation.

The following steps should be executed in order to add the Elastic Defend integration on a Linux System:

  • Go to the Kibana home page and click "Add integrations".
  • In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
  • Click "Add Elastic Defend".
  • Configure the integration name and optionally add a description.
  • Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
  • 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.
  • We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
  • 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. For more details on Elastic Agent configuration settings, refer to the helper guide.
  • Click "Save and Continue".
  • 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. For more details on Elastic Defend refer to the helper guide.

Rule query

edit
process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and
process.name == "busybox" and (
  process.args in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
  process.command_line like (
    "*nc *", "*netcat*", "*openssl*", "*telnet*", "*exec*", "*import*pty*spawn*", "*import*subprocess*call*", "*socket*",
    "*system*", "*io.popen*", "*os.execute*", "*fsockopen*", "*/inet/tcp/*", "*/dev/tcp/*", "*/dev/udp/*", "*nohup*",
    "*setsid*", "*/dev/shm/*", "*ld-linux*.so*", "*/tmp/*", "*/var/tmp/*", "*rm*-rf*"
  )
) and (
  process.parent.executable like (
      "/tmp/*", "/var/tmp/*", "/dev/shm/*", "./*", "/run/*", "/var/run/*", "/boot/*", "/sys/*", "/lost+found/*",
      "/proc/*", "/var/mail/*", "/var/www/*", "/home/*", "/root/*"
    ) or
    process.parent.name like ".*"
) and not (
  process.parent.command_line in ("runc init", "/usr/local/bin/runc init") or
  process.parent.executable == "./runc" or
  process.parent.executable like ("/run/containerd/io.containerd.runtime.v2.task/k8s.io/*/bin/php", "/tmp/go-build*.test") or
  process.command_line == "sh -c echo EXEC" or
  process.parent.name in ("ninja_test", "ocamlrun", "ocamlopt.opt", "make", "process-wrapper")
)

Framework: MITRE ATT&CKTM

« Linux External IP Address Discovery via Curl Payload Downloaded by Interpreter and Piped to Interpreter »