Proxy Shell Execution via Busybox

Detects the execution of a shell through Busybox. Attackers may use this technique to execute shells while attempting to evade detection.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2025/11/20"
  3integration = ["endpoint"]
  4maturity = "production"
  5updated_date = "2025/11/24"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects the execution of a shell through Busybox. Attackers may use this technique to execute shells while attempting to
 11evade detection.
 12"""
 13from = "now-9m"
 14index = ["logs-endpoint.events.process*"]
 15language = "eql"
 16license = "Elastic License v2"
 17name = "Proxy Shell Execution via Busybox"
 18note = """ ## Triage and analysis
 19
 20> **Disclaimer**:
 21> 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.
 22
 23### Investigating Proxy Shell Execution via Busybox
 24
 25This rule identifies Linux shells started via Busybox, indicating proxy execution to sidestep controls that focus on direct shell binaries. Adversaries leverage Busybox’s ubiquity and static build to blend in, obscure parentage, and run commands in constrained or minimal environments. A common pattern is copying a standalone busybox into /tmp on a container or embedded host, making it executable, then invoking busybox sh to run one-liners, pull payloads, and stage persistence.
 26
 27### Possible investigation steps
 28
 29- Correlate the event to a user session or container exec by pivoting to TTY/session ID, SSH auth logs, and Kubernetes/Docker exec audits to verify whether it was an authorized action.
 30- Determine Busybox provenance by checking its path and file metadata (non-standard location, recent write, unusual owner/capabilities or symlink), confirming package ownership, and hashing against trusted repositories and threat intelligence.
 31- Expand the process tree 10–15 minutes around the event to find staging steps (curl/wget/tftp, chmod, mv) and post-shell behavior (reverse shells, crypto miners, persistence writes).
 32- Collect live context for the shell (current working directory, environment, open sockets, controlling TTY, effective user) to quickly decide if it is interactive misuse or command staging.
 33- Hunt across hosts for similar Busybox-to-shell chains and review persistence artifacts and new files in writable dirs (crontab, systemd units, rc files, authorized_keys, /tmp, /dev/shm) to catch follow-on activity.
 34
 35### False positive analysis
 36
 37- An administrator performing recovery on a minimal host may copy a static busybox and start an interactive sh with no arguments for troubleshooting, producing a busybox-to-shell chain that is expected.
 38- Legitimate privilege-switch or login workflows using Busybox applets (e.g., su or login) can spawn a bare sh without -c for an authenticated session, so confirm a controlling TTY, expected user, and standard paths before treating it as malicious.
 39
 40### Response and remediation
 41
 42- Immediately isolate the impacted host or container at the network level, terminate any shells whose parent is busybox, and block outbound traffic initiated by those shells (e.g., nc, curl/wget, ssh to unknown IPs).
 43- Identify and remove rogue busybox copies or symlinks in writable locations such as /tmp, /var/tmp, and /dev/shm by revoking execute permissions or deleting them, and capture file hashes, paths, and mtimes for evidence.
 44- Remove persistence and droppers created by the busybox-spawned shell by cleaning newly added cron entries under /etc/cron.*, systemd units in /etc/systemd/system, rc.local edits, and suspicious authorized_keys or ~/.bashrc/.profile changes, then reboot if kernel modules or LD_PRELOAD were modified.
 45- Reset passwords, rotate SSH keys and tokens used in the session, rebuild affected containers from clean images or reimage hosts if system binaries were changed, and restore services only after verifying no busybox-to-shell chains launch at startup.
 46- Escalate to incident response if the busybox-launched shell ran as root, established a reverse connection (e.g., bash -i >& /dev/tcp/<IP>/<port>), created SUID files, or dropped payloads in /tmp, /var/tmp, or /dev/shm, or if a new busybox binary was downloaded or touched minutes before execution.
 47- Harden by enforcing noexec,nosuid,nodev mounts on /tmp and /var/tmp, constraining busybox with AppArmor/SELinux to block spawning interactive shells or execution from world-writable paths, locking down container runtime exec and capabilities (e.g., disable kubectl/docker exec for non-admins, remove CAP_SYS_ADMIN), and implementing file integrity monitoring on busybox and standard shells.
 48"""
 49references = ["https://gtfobins.github.io/gtfobins/busybox/"]
 50risk_score = 21
 51rule_id = "5134be90-42c1-4ac7-859c-4d82caaddbec"
 52setup = """## Setup
 53
 54This rule requires data coming in from Elastic Defend.
 55
 56### Elastic Defend Integration Setup
 57Elastic 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.
 58
 59#### Prerequisite Requirements:
 60- Fleet is required for Elastic Defend.
 61- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 62
 63#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 64- Go to the Kibana home page and click "Add integrations".
 65- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 66- Click "Add Elastic Defend".
 67- Configure the integration name and optionally add a description.
 68- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 69- 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).
 70- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 71- 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.
 72For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 73- Click "Save and Continue".
 74- 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.
 75For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 76"""
 77severity = "low"
 78tags = [
 79    "Domain: Endpoint",
 80    "OS: Linux",
 81    "Use Case: Threat Detection",
 82    "Tactic: Defense Evasion",
 83    "Tactic: Execution",
 84    "Data Source: Elastic Defend",
 85    "Resources: Investigation Guide",
 86]
 87timestamp_override = "event.ingested"
 88type = "eql"
 89query = '''
 90process where host.os.type == "linux" and  event.type == "start" and event.action == "exec" and process.parent.name == "busybox" and
 91process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
 92process.command_line in ("bash", "bash-", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
 93not (
 94  process.args == "-c" or
 95  process.parent.args : (
 96    "crond", "/usr/sbin/crond", "/local-registrator.sh", "/var/atlassian/application-data/bamboo-agent*"
 97  ) or
 98  process.parent.command_line in (
 99    "sh /readonly-config/fix-split-brain.sh",
100    "/bin/sh -c /health-check.sh || bash -c 'kill -s 15 $(pidof siridb-server) && (sleep 10; kill -s 9 $(pidof siridb-server))'"
101  ) or
102  process.command_line == "bash /etc/kafka/docker/run" or
103  process.parent.command_line like (
104    "/bin/sh -c apk add*", "/bin/sh -c crm-cron-enabled*", "udhcpc -n -p /run/udhcpc.*", "flock -x*"
105  ) or
106  process.working_directory == "/usr/share/grafana"
107)
108'''
109
110[[rule.threat]]
111framework = "MITRE ATT&CK"
112
113  [rule.threat.tactic]
114  name = "Defense Evasion"
115  id = "TA0005"
116  reference = "https://attack.mitre.org/tactics/TA0005/"
117
118    [[rule.threat.technique]]
119    id = "T1218"
120    name = "System Binary Proxy Execution"
121    reference = "https://attack.mitre.org/techniques/T1218/"
122
123[[rule.threat]]
124framework = "MITRE ATT&CK"
125
126  [rule.threat.tactic]
127  name = "Execution"
128  id = "TA0002"
129  reference = "https://attack.mitre.org/tactics/TA0002/"
130
131  [[rule.threat.technique]]
132  id = "T1059"
133  name = "Command and Scripting Interpreter"
134  reference = "https://attack.mitre.org/techniques/T1059/"
135
136    [[rule.threat.technique.subtechnique]]
137    name = "Unix Shell"
138    id = "T1059.004"
139    reference = "https://attack.mitre.org/techniques/T1059/004/"

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 Proxy Shell Execution via Busybox

This rule identifies Linux shells started via Busybox, indicating proxy execution to sidestep controls that focus on direct shell binaries. Adversaries leverage Busybox’s ubiquity and static build to blend in, obscure parentage, and run commands in constrained or minimal environments. A common pattern is copying a standalone busybox into /tmp on a container or embedded host, making it executable, then invoking busybox sh to run one-liners, pull payloads, and stage persistence.

Possible investigation steps

  • Correlate the event to a user session or container exec by pivoting to TTY/session ID, SSH auth logs, and Kubernetes/Docker exec audits to verify whether it was an authorized action.
  • Determine Busybox provenance by checking its path and file metadata (non-standard location, recent write, unusual owner/capabilities or symlink), confirming package ownership, and hashing against trusted repositories and threat intelligence.
  • Expand the process tree 10–15 minutes around the event to find staging steps (curl/wget/tftp, chmod, mv) and post-shell behavior (reverse shells, crypto miners, persistence writes).
  • Collect live context for the shell (current working directory, environment, open sockets, controlling TTY, effective user) to quickly decide if it is interactive misuse or command staging.
  • Hunt across hosts for similar Busybox-to-shell chains and review persistence artifacts and new files in writable dirs (crontab, systemd units, rc files, authorized_keys, /tmp, /dev/shm) to catch follow-on activity.

False positive analysis

  • An administrator performing recovery on a minimal host may copy a static busybox and start an interactive sh with no arguments for troubleshooting, producing a busybox-to-shell chain that is expected.
  • Legitimate privilege-switch or login workflows using Busybox applets (e.g., su or login) can spawn a bare sh without -c for an authenticated session, so confirm a controlling TTY, expected user, and standard paths before treating it as malicious.

Response and remediation

  • Immediately isolate the impacted host or container at the network level, terminate any shells whose parent is busybox, and block outbound traffic initiated by those shells (e.g., nc, curl/wget, ssh to unknown IPs).
  • Identify and remove rogue busybox copies or symlinks in writable locations such as /tmp, /var/tmp, and /dev/shm by revoking execute permissions or deleting them, and capture file hashes, paths, and mtimes for evidence.
  • Remove persistence and droppers created by the busybox-spawned shell by cleaning newly added cron entries under /etc/cron.*, systemd units in /etc/systemd/system, rc.local edits, and suspicious authorized_keys or ~/.bashrc/.profile changes, then reboot if kernel modules or LD_PRELOAD were modified.
  • Reset passwords, rotate SSH keys and tokens used in the session, rebuild affected containers from clean images or reimage hosts if system binaries were changed, and restore services only after verifying no busybox-to-shell chains launch at startup.
  • Escalate to incident response if the busybox-launched shell ran as root, established a reverse connection (e.g., bash -i >& /dev/tcp//), created SUID files, or dropped payloads in /tmp, /var/tmp, or /dev/shm, or if a new busybox binary was downloaded or touched minutes before execution.
  • Harden by enforcing noexec,nosuid,nodev mounts on /tmp and /var/tmp, constraining busybox with AppArmor/SELinux to block spawning interactive shells or execution from world-writable paths, locking down container runtime exec and capabilities (e.g., disable kubectl/docker exec for non-admins, remove CAP_SYS_ADMIN), and implementing file integrity monitoring on busybox and standard shells.

References

Related rules

to-top