Linux Restricted Shell Breakout via Linux Binary(s)

Identifies the abuse of a Linux binary to break out of a restricted shell or environment by spawning an interactive system shell. The activity of spawning a shell from a binary is not common behavior for a user or system administrator, and may indicate an attempt to evade detection, increase capabilities or enhance the stability of an adversary.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2022/05/06"
  3integration = ["endpoint"]
  4maturity = "production"
  5min_stack_comments = "New fields added: required_fields, related_integrations, setup"
  6min_stack_version = "8.3.0"
  7updated_date = "2023/11/02"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12Identifies the abuse of a Linux binary to break out of a restricted shell or environment by spawning an interactive 
 13system shell. The activity of spawning a shell from a binary is not common behavior for a user or system administrator, 
 14and may indicate an attempt to evade detection, increase capabilities or enhance the stability of an adversary.
 15"""
 16from = "now-9m"
 17index = ["logs-endpoint.events.*"]
 18language = "eql"
 19license = "Elastic License v2"
 20name = "Linux Restricted Shell Breakout via Linux Binary(s)"
 21note = """## Triage and analysis
 22
 23### Investigating Shell Evasion via Linux Utilities
 24Detection alerts from this rule indicate that a Linux utility has been abused to breakout of restricted shells or
 25environments by spawning an interactive system shell.
 26Here are some possible avenues of investigation:
 27- Examine the entry point to the host and user in action via the Analyse View.
 28  - Identify the session entry leader and session user
 29- Examine the contents of session leading to the abuse via the Session View.
 30  - Examine the command execution pattern in the session, which may lead to suspricous activities
 31- Examine the execution of commands in the spawned shell.
 32  - Identify imment threat to the system from the executed commands
 33  - Take necessary incident response actions to contain any malicious behviour caused via this execution.
 34
 35### Related rules
 36
 37- A malicious spawned shell can execute any of the possible MITTRE ATT&CK vectors mainly to impair defences.
 38- Hence its adviced to enable defence evasion and privilige escalation rules accordingly in your environment
 39
 40### Response and remediation
 41
 42Initiate the incident response process based on the outcome of the triage.
 43
 44- If the triage releaved suspicious netwrok activity from the malicious spawned shell,
 45  - Isolate the involved host to prevent further post-compromise behavior.
 46- If the triage identified malware execution via the maliciously spawned shell,
 47  - Search the environment for additional compromised hosts.
 48  - Implement temporary network rules, procedures, and segmentation to contain the malware.
 49  - Stop suspicious processes.
 50  - Immediately block the identified indicators of compromise (IoCs).
 51  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.
 52- If the triage revelaed defence evasion for imparing defenses
 53  - Isolate the involved host to prevent further post-compromise behavior.
 54  - Identified the disabled security guard components on the host and take necessary steps in renebaling the same.
 55  - If any tools have been disbaled / uninstalled or config tampered work towards reenabling the same.
 56- If the triage revelaed addition of persistence mechanism exploit like auto start scripts
 57  - Isolate further login to the systems that can initae auto start scripts.
 58  - Identify the auto start scripts and disable and remove the same from the systems
 59- If the triage revealed data crawling or data export via remote copy
 60  - Investigate credential exposure on systems compromised / used / decoded by the attacker during the data crawling
 61  - Intiate compromised credential deactivation and credential rotation process for all exposed crednetials.
 62  - Investiagte if any IPR data was accessed during the data crawling and take appropriate actions.
 63- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
 64- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
 65"""
 66references = [
 67    "https://gtfobins.github.io/gtfobins/apt/",
 68    "https://gtfobins.github.io/gtfobins/apt-get/",
 69    "https://gtfobins.github.io/gtfobins/nawk/",
 70    "https://gtfobins.github.io/gtfobins/mawk/",
 71    "https://gtfobins.github.io/gtfobins/awk/",
 72    "https://gtfobins.github.io/gtfobins/gawk/",
 73    "https://gtfobins.github.io/gtfobins/busybox/",
 74    "https://gtfobins.github.io/gtfobins/c89/",
 75    "https://gtfobins.github.io/gtfobins/c99/",
 76    "https://gtfobins.github.io/gtfobins/cpulimit/",
 77    "https://gtfobins.github.io/gtfobins/crash/",
 78    "https://gtfobins.github.io/gtfobins/env/",
 79    "https://gtfobins.github.io/gtfobins/expect/",
 80    "https://gtfobins.github.io/gtfobins/find/",
 81    "https://gtfobins.github.io/gtfobins/flock/",
 82    "https://gtfobins.github.io/gtfobins/gcc/",
 83    "https://gtfobins.github.io/gtfobins/mysql/",
 84    "https://gtfobins.github.io/gtfobins/nice/",
 85    "https://gtfobins.github.io/gtfobins/ssh/",
 86    "https://gtfobins.github.io/gtfobins/vi/",
 87    "https://gtfobins.github.io/gtfobins/vim/",
 88    "https://gtfobins.github.io/gtfobins/capsh/",
 89    "https://gtfobins.github.io/gtfobins/byebug/",
 90    "https://gtfobins.github.io/gtfobins/git/",
 91    "https://gtfobins.github.io/gtfobins/ftp/",
 92]
 93risk_score = 47
 94rule_id = "52376a86-ee86-4967-97ae-1a05f55816f0"
 95setup = """## Setup
 96
 97This rule requires data coming in from Elastic Defend.
 98
 99### Elastic Defend Integration Setup
100Elastic 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.
101
102#### Prerequisite Requirements:
103- Fleet is required for Elastic Defend.
104- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
105
106#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
107- Go to the Kibana home page and click "Add integrations".
108- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
109- Click "Add Elastic Defend".
110- Configure the integration name and optionally add a description.
111- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
112- 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).
113- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
114- 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.
115For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
116- Click "Save and Continue".
117- 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.
118For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
119
120Session View uses process data collected by the Elastic Defend integration, but this data is not always collected by default. Session View is available on enterprise subscription for versions 8.3 and above.
121#### To confirm that Session View data is enabled:
122- Go to “Manage → Policies”, and edit one or more of your Elastic Defend integration policies.
123- Select the” Policy settings” tab, then scroll down to the “Linux event collection” section near the bottom.
124- Check the box for “Process events”, and turn on the “Include session data” toggle.
125- If you want to include file and network alerts in Session View, check the boxes for “Network and File events”.
126- If you want to enable terminal output capture, turn on the “Capture terminal output” toggle.
127For more information about the additional fields collected when this setting is enabled and the usage of Session View for Analysis refer to the [helper guide](https://www.elastic.co/guide/en/security/current/session-view.html).
128"""
129severity = "medium"
130tags = ["Domain: Endpoint", "OS: Linux", "Use Case: Threat Detection", "Tactic: Execution", "Data Source: Elastic Endgame", "Data Source: Elastic Defend"]
131timestamp_override = "event.ingested"
132type = "eql"
133query = '''
134process where host.os.type == "linux" and event.type == "start" and
135(
136  /* launching shell from capsh */
137  (process.name == "capsh" and process.args == "--") or
138  
139  /* launching shells from unusual parents or parent+arg combos */
140  (process.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and (
141    (process.parent.name : "*awk" and process.parent.args : "BEGIN {system(*)}") or
142    (process.parent.name == "git" and process.parent.args : ("*PAGER*", "!*sh", "exec *sh") or 
143     process.args : ("*PAGER*", "!*sh", "exec *sh") and not process.name == "ssh" ) or
144    (process.parent.name : ("byebug", "ftp", "strace", "zip", "tar") and 
145    (
146      process.parent.args : "BEGIN {system(*)}" or
147      (process.parent.args : ("*PAGER*", "!*sh", "exec *sh") or process.args : ("*PAGER*", "!*sh", "exec *sh")) or
148      (
149        (process.parent.args : "exec=*sh" or (process.parent.args : "-I" and process.parent.args : "*sh")) or
150        (process.args : "exec=*sh" or (process.args : "-I" and process.args : "*sh"))
151        )
152      )
153    ) or
154    
155    /* shells specified in parent args */
156    /* nice rule is broken in 8.2 */
157    (process.parent.args : "*sh" and
158      (
159        (process.parent.name == "nice") or
160        (process.parent.name == "cpulimit" and process.parent.args == "-f") or
161        (process.parent.name == "find" and process.parent.args == "." and process.parent.args == "-exec" and 
162         process.parent.args == ";" and process.parent.args : "/bin/*sh") or
163        (process.parent.name == "flock" and process.parent.args == "-u" and process.parent.args == "/")
164      )
165    )
166  )) or
167
168  /* shells specified in args */
169  (process.args : "*sh" and (
170    (process.parent.name == "crash" and process.parent.args == "-h") or
171    (process.name == "sensible-pager" and process.parent.name in ("apt", "apt-get") and process.parent.args == "changelog")
172    /* scope to include more sensible-pager invoked shells with different parent process to reduce noise and remove false positives */
173    
174  )) or
175  (process.name == "busybox" and event.action == "exec" and process.args_count == 2 and process.args : "*sh" and not 
176   process.executable : "/var/lib/docker/overlay2/*/merged/bin/busybox" and not (process.parent.args == "init" and
177   process.parent.args == "runc") and not process.parent.args in ("ls-remote", "push", "fetch") and not process.parent.name == "mkinitramfs") or
178  (process.name == "env" and process.args_count == 2 and process.args : "*sh") or
179  (process.parent.name in ("vi", "vim") and process.parent.args == "-c" and process.parent.args : ":!*sh") or
180  (process.parent.name in ("c89", "c99", "gcc") and process.parent.args : "*sh,-s" and process.parent.args == "-wrapper") or
181  (process.parent.name == "expect" and process.parent.args == "-c" and process.parent.args : "spawn *sh;interact") or
182  (process.parent.name == "mysql" and process.parent.args == "-e" and process.parent.args : "\\!*sh") or
183  (process.parent.name == "ssh" and process.parent.args == "-o" and process.parent.args : "ProxyCommand=;*sh 0<&2 1>&2")
184)
185'''
186
187[[rule.threat]]
188framework = "MITRE ATT&CK"
189
190[[rule.threat.technique]]
191id = "T1059"
192name = "Command and Scripting Interpreter"
193reference = "https://attack.mitre.org/techniques/T1059/"
194
195[[rule.threat.technique.subtechnique]]
196id = "T1059.004"
197name = "Unix Shell"
198reference = "https://attack.mitre.org/techniques/T1059/004/"
199
200[rule.threat.tactic]
201id = "TA0002"
202name = "Execution"
203reference = "https://attack.mitre.org/tactics/TA0002/"

Triage and analysis

Investigating Shell Evasion via Linux Utilities

Detection alerts from this rule indicate that a Linux utility has been abused to breakout of restricted shells or environments by spawning an interactive system shell. Here are some possible avenues of investigation:

  • Examine the entry point to the host and user in action via the Analyse View.
    • Identify the session entry leader and session user
  • Examine the contents of session leading to the abuse via the Session View.
    • Examine the command execution pattern in the session, which may lead to suspricous activities
  • Examine the execution of commands in the spawned shell.
    • Identify imment threat to the system from the executed commands
    • Take necessary incident response actions to contain any malicious behviour caused via this execution.
  • A malicious spawned shell can execute any of the possible MITTRE ATT&CK vectors mainly to impair defences.
  • Hence its adviced to enable defence evasion and privilige escalation rules accordingly in your environment

Response and remediation

Initiate the incident response process based on the outcome of the triage.

  • If the triage releaved suspicious netwrok activity from the malicious spawned shell,
    • Isolate the involved host to prevent further post-compromise behavior.
  • If the triage identified malware execution via the maliciously spawned shell,
    • Search the environment for additional compromised hosts.
    • Implement temporary network rules, procedures, and segmentation to contain the malware.
    • Stop suspicious processes.
    • Immediately block the identified indicators of compromise (IoCs).
    • Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.
  • If the triage revelaed defence evasion for imparing defenses
    • Isolate the involved host to prevent further post-compromise behavior.
    • Identified the disabled security guard components on the host and take necessary steps in renebaling the same.
    • If any tools have been disbaled / uninstalled or config tampered work towards reenabling the same.
  • If the triage revelaed addition of persistence mechanism exploit like auto start scripts
    • Isolate further login to the systems that can initae auto start scripts.
    • Identify the auto start scripts and disable and remove the same from the systems
  • If the triage revealed data crawling or data export via remote copy
    • Investigate credential exposure on systems compromised / used / decoded by the attacker during the data crawling
    • Intiate compromised credential deactivation and credential rotation process for all exposed crednetials.
    • Investiagte if any IPR data was accessed during the data crawling and take appropriate actions.
  • Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
  • Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).

References

Related rules

to-top