Potential Reverse Shell Activity via Terminal

Identifies the execution of a shell process with suspicious arguments which may be indicative of reverse shell activity.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2020/01/07"
  3integration = ["endpoint"]
  4maturity = "production"
  5updated_date = "2024/09/23"
  6
  7[rule]
  8author = ["Elastic"]
  9description = "Identifies the execution of a shell process with suspicious arguments which may be indicative of reverse shell activity."
 10from = "now-9m"
 11index = ["auditbeat-*", "logs-endpoint.events.*"]
 12language = "eql"
 13license = "Elastic License v2"
 14name = "Potential Reverse Shell Activity via Terminal"
 15note = """## Triage and analysis
 16
 17### Investigating Potential Reverse Shell Activity via Terminal
 18
 19A reverse shell is a mechanism that's abused to connect back to an attacker-controlled system. It effectively redirects the system's input and output and delivers a fully functional remote shell to the attacker. Even private systems are vulnerable since the connection is outgoing. This activity is typically the result of vulnerability exploitation, malware infection, or penetration testing.
 20
 21This rule identifies commands that are potentially related to reverse shell activities using shell applications.
 22
 23#### Possible investigation steps
 24
 25- Examine the command line and extract the target domain or IP address information.
 26  - Check if the domain is newly registered or unexpected.
 27  - Check the reputation of the domain or IP address.
 28  - Scope other potentially compromised hosts in your environment by mapping hosts that also communicated with the domain or IP address.
 29- Investigate other alerts associated with the user/host during the past 48 hours.
 30- Investigate any abnormal account behavior, such as command executions, file creations or modifications, and network connections.
 31- Investigate any abnormal behavior by the subject process such as network connections, file modifications, and any spawned child processes.
 32
 33### False positive analysis
 34
 35- This activity is unlikely to happen legitimately. Any activity that triggered the alert and is not inherently malicious must be monitored by the security team.
 36
 37### Response and remediation
 38
 39- Initiate the incident response process based on the outcome of the triage.
 40- Isolate the involved host to prevent further post-compromise behavior.
 41- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
 42- Take actions to terminate processes and connections used by the attacker.
 43- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
 44- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
 45- 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).
 46"""
 47references = [
 48    "https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md",
 49    "https://github.com/WangYihang/Reverse-Shell-Manager",
 50    "https://www.netsparker.com/blog/web-security/understanding-reverse-shells/",
 51    "https://www.elastic.co/security-labs/detecting-log4j2-with-elastic-security",
 52]
 53risk_score = 73
 54rule_id = "a1a0375f-22c2-48c0-81a4-7c2d11cc6856"
 55setup = """## Setup
 56
 57If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2,
 58events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2.
 59Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate
 60`event.ingested` to @timestamp.
 61For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html
 62"""
 63severity = "high"
 64tags = [
 65    "Domain: Endpoint",
 66    "OS: Linux",
 67    "OS: macOS",
 68    "Use Case: Threat Detection",
 69    "Tactic: Execution",
 70    "Resources: Investigation Guide",
 71    "Data Source: Elastic Defend",
 72]
 73timestamp_override = "event.ingested"
 74type = "eql"
 75
 76query = '''
 77process where event.type in ("start", "process_started") and
 78  process.name in ("sh", "bash", "zsh", "dash", "zmodload") and
 79  process.args : ("*/dev/tcp/*", "*/dev/udp/*", "*zsh/net/tcp*", "*zsh/net/udp*") and
 80
 81  /* noisy FPs */
 82  not (process.parent.name : "timeout" and process.executable : "/var/lib/docker/overlay*") and
 83  not process.command_line : (
 84    "*/dev/tcp/sirh_db/*", "*/dev/tcp/remoteiot.com/*", "*dev/tcp/elk.stag.one/*", "*dev/tcp/kafka/*",
 85    "*/dev/tcp/$0/$1*", "*/dev/tcp/127.*", "*/dev/udp/127.*", "*/dev/tcp/localhost/*", "*/dev/tcp/itom-vault/*") and
 86  not process.parent.command_line : "runc init"
 87'''
 88
 89
 90[[rule.threat]]
 91framework = "MITRE ATT&CK"
 92[[rule.threat.technique]]
 93id = "T1059"
 94name = "Command and Scripting Interpreter"
 95reference = "https://attack.mitre.org/techniques/T1059/"
 96
 97
 98[rule.threat.tactic]
 99id = "TA0002"
100name = "Execution"
101reference = "https://attack.mitre.org/tactics/TA0002/"

Triage and analysis

Investigating Potential Reverse Shell Activity via Terminal

A reverse shell is a mechanism that's abused to connect back to an attacker-controlled system. It effectively redirects the system's input and output and delivers a fully functional remote shell to the attacker. Even private systems are vulnerable since the connection is outgoing. This activity is typically the result of vulnerability exploitation, malware infection, or penetration testing.

This rule identifies commands that are potentially related to reverse shell activities using shell applications.

Possible investigation steps

  • Examine the command line and extract the target domain or IP address information.
    • Check if the domain is newly registered or unexpected.
    • Check the reputation of the domain or IP address.
    • Scope other potentially compromised hosts in your environment by mapping hosts that also communicated with the domain or IP address.
  • Investigate other alerts associated with the user/host during the past 48 hours.
  • Investigate any abnormal account behavior, such as command executions, file creations or modifications, and network connections.
  • Investigate any abnormal behavior by the subject process such as network connections, file modifications, and any spawned child processes.

False positive analysis

  • This activity is unlikely to happen legitimately. Any activity that triggered the alert and is not inherently malicious must be monitored by the security team.

Response and remediation

  • Initiate the incident response process based on the outcome of the triage.
  • Isolate the involved host to prevent further post-compromise behavior.
  • Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
  • Take actions to terminate processes and connections used by the attacker.
  • Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
  • 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