SSH Process Launched From Inside A Container

  1[metadata]
  2creation_date = "2025/03/12"
  3integration = ["endpoint"]
  4maturity = "production"
  5updated_date = "2025/03/12"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10This rule detects an SSH or SSHD process executed from inside a container. This includes both the client ssh binary and
 11server ssh daemon process. SSH usage inside a container should be avoided and monitored closely when necessary. With
 12valid credentials an attacker may move laterally to other containers or to the underlying host through container
 13breakout. They may also use valid SSH credentials as a persistence mechanism.
 14"""
 15false_positives = [
 16    """
 17    SSH usage may be legitimate depending on the environment. Access patterns and follow-on activity should be analyzed
 18    to distinguish between authorized and potentially malicious behavior.
 19    """,
 20]
 21from = "now-9m"
 22index = ["logs-endpoint.events.process*"]
 23language = "eql"
 24license = "Elastic License v2"
 25name = "SSH Process Launched From Inside A Container"
 26references = [
 27    "https://microsoft.github.io/Threat-Matrix-for-Kubernetes/techniques/SSH%20server%20running%20inside%20container/",
 28    "https://www.blackhillsinfosec.com/sshazam-hide-your-c2-inside-of-ssh/",
 29]
 30risk_score = 47
 31rule_id = "5c50ffa6-07f4-4cce-a1b7-c16928a2ed52"
 32setup = """## Setup
 33
 34This rule requires data coming in from Elastic Defend.
 35
 36### Elastic Defend Integration Setup
 37Elastic 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.
 38
 39#### Prerequisite Requirements:
 40- Fleet is required for Elastic Defend.
 41- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 42
 43#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 44- Go to the Kibana home page and click "Add integrations".
 45- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 46- Click "Add Elastic Defend".
 47- Configure the integration name and optionally add a description.
 48- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 49- 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).
 50- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 51- 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.
 52
 53For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 54- Click "Save and Continue".
 55- 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.
 56For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 57"""
 58severity = "medium"
 59tags = [
 60    "Domain: Container",
 61    "OS: Linux",
 62    "Use Case: Threat Detection",
 63    "Tactic: Lateral Movement",
 64    "Tactic: Persistence",
 65    "Data Source: Elastic Defend",
 66    "Resources: Investigation Guide",
 67]
 68timestamp_override = "event.ingested"
 69type = "eql"
 70query = '''
 71process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
 72process.entry_leader.entry_meta.type == "container" and process.name in ("sshd", "ssh", "autossh")
 73'''
 74note = """## Triage and analysis
 75
 76> **Disclaimer**:
 77> 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.
 78
 79### Investigating SSH Process Launched From Inside A Container
 80
 81SSH (Secure Shell) is a protocol used for secure remote access and management of systems. Within container environments, SSH usage is atypical and can signal potential security risks. Adversaries may exploit SSH to move laterally between containers or escape to the host system. The detection rule identifies SSH processes initiated within containers, flagging potential unauthorized access or persistence attempts by monitoring process events and container identifiers.
 82
 83### Possible investigation steps
 84
 85- Examine the process start event details, including the process name (sshd, ssh, autossh) and event actions (fork, exec), to understand the context and nature of the SSH activity.
 86- Check for any recent changes or deployments related to the container to identify if the SSH process aligns with expected behavior or recent updates.
 87- Investigate the source and destination of the SSH connection to determine if it involves unauthorized or suspicious endpoints, potentially indicating lateral movement or an attempt to access the host system.
 88- Analyze user accounts and credentials used in the SSH session to verify if they are legitimate and authorized for container access, looking for signs of compromised credentials.
 89- Correlate the SSH activity with other security events or alerts to identify patterns or additional indicators of compromise within the container environment.
 90
 91### False positive analysis
 92
 93- Development and testing environments may intentionally use SSH for debugging or administrative tasks. Users can create exceptions for specific container IDs or hostnames associated with these environments to reduce noise.
 94- Automated scripts or orchestration tools might use SSH to manage containers. Identify these tools and exclude their process IDs or user accounts from triggering the rule.
 95- Some legacy applications might rely on SSH for internal communication. Review these applications and whitelist their specific process names or container images to prevent false alerts.
 96- Containers running SSH for legitimate remote access purposes, such as maintenance, should be documented. Exclude these containers by their unique identifiers or labels to avoid unnecessary alerts.
 97- Regularly review and update the exclusion list to ensure it aligns with current operational practices and does not inadvertently allow malicious activity.
 98
 99### Response and remediation
100
101- Immediately isolate the affected container to prevent potential lateral movement or further unauthorized access. This can be done by stopping the container or disconnecting it from the network.
102- Conduct a thorough review of the container's logs and environment to identify any unauthorized access or changes. Pay special attention to SSH-related logs and any anomalies in user activity.
103- Revoke any SSH keys or credentials that may have been compromised. Ensure that all SSH keys used within the container environment are rotated and that access is restricted to only necessary personnel.
104- Assess the container image and configuration for vulnerabilities or misconfigurations that may have allowed the SSH process to be initiated. Patch any identified vulnerabilities and update the container image accordingly.
105- Implement network segmentation to limit the ability of containers to communicate with each other and the host system, reducing the risk of lateral movement.
106- Enhance monitoring and alerting for SSH activity within container environments to ensure rapid detection of similar threats in the future. This includes setting up alerts for any SSH process initiation within containers.
107- Escalate the incident to the security operations team for further investigation and to determine if additional systems or containers have been affected."""
108
109[[rule.threat]]
110framework = "MITRE ATT&CK"
111
112[[rule.threat.technique]]
113id = "T1021"
114name = "Remote Services"
115reference = "https://attack.mitre.org/techniques/T1021/"
116
117[[rule.threat.technique.subtechnique]]
118id = "T1021.004"
119name = "SSH"
120reference = "https://attack.mitre.org/techniques/T1021/004/"
121
122[rule.threat.tactic]
123id = "TA0008"
124name = "Lateral Movement"
125reference = "https://attack.mitre.org/tactics/TA0008/"
126
127[[rule.threat]]
128framework = "MITRE ATT&CK"
129
130[[rule.threat.technique]]
131id = "T1133"
132name = "External Remote Services"
133reference = "https://attack.mitre.org/techniques/T1133/"
134
135[rule.threat.tactic]
136id = "TA0003"
137name = "Persistence"
138reference = "https://attack.mitre.org/tactics/TA0003/"