SSH Process Launched From Inside A Container
This rule detects an SSH or SSHD process executed from inside a container. This includes both the client ssh binary and server ssh daemon process. SSH usage inside a container should be avoided and monitored closely when necessary. With valid credentials an attacker may move laterally to other containers or to the underlying host through container breakout. They may also use valid SSH credentials as a persistence mechanism.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2023/05/12"
3integration = ["cloud_defend"]
4maturity = "production"
5updated_date = "2025/01/15"
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-6m"
22index = ["logs-cloud_defend*"]
23interval = "5m"
24language = "eql"
25license = "Elastic License v2"
26name = "SSH Process Launched From Inside A Container"
27references = [
28 "https://microsoft.github.io/Threat-Matrix-for-Kubernetes/techniques/SSH%20server%20running%20inside%20container/",
29 "https://www.blackhillsinfosec.com/sshazam-hide-your-c2-inside-of-ssh/",
30]
31risk_score = 73
32rule_id = "03a514d9-500e-443e-b6a9-72718c548f6c"
33severity = "high"
34tags = [
35 "Data Source: Elastic Defend for Containers",
36 "Domain: Container",
37 "OS: Linux",
38 "Use Case: Threat Detection",
39 "Tactic: Lateral Movement",
40 "Tactic: Persistence",
41 "Resources: Investigation Guide",
42]
43timestamp_override = "event.ingested"
44type = "eql"
45
46query = '''
47process where container.id: "*" and event.type== "start" and
48event.action in ("fork", "exec") and event.action != "end" and
49process.name: ("sshd", "ssh", "autossh")
50'''
51note = """## Triage and analysis
52
53> **Disclaimer**:
54> 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.
55
56### Investigating SSH Process Launched From Inside A Container
57
58SSH (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.
59
60### Possible investigation steps
61
62- Review the container identifier (container.id) associated with the SSH process to determine which container initiated the process and assess its intended function.
63- 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.
64- Check for any recent changes or deployments related to the container to identify if the SSH process aligns with expected behavior or recent updates.
65- 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.
66- 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.
67- Correlate the SSH activity with other security events or alerts to identify patterns or additional indicators of compromise within the container environment.
68
69### False positive analysis
70
71- 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.
72- 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.
73- 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.
74- 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.
75- Regularly review and update the exclusion list to ensure it aligns with current operational practices and does not inadvertently allow malicious activity.
76
77### Response and remediation
78
79- 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.
80- 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.
81- 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.
82- 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.
83- Implement network segmentation to limit the ability of containers to communicate with each other and the host system, reducing the risk of lateral movement.
84- 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.
85- Escalate the incident to the security operations team for further investigation and to determine if additional systems or containers have been affected."""
86
87
88[[rule.threat]]
89framework = "MITRE ATT&CK"
90[[rule.threat.technique]]
91id = "T1021"
92name = "Remote Services"
93reference = "https://attack.mitre.org/techniques/T1021/"
94[[rule.threat.technique.subtechnique]]
95id = "T1021.004"
96name = "SSH"
97reference = "https://attack.mitre.org/techniques/T1021/004/"
98
99
100
101[rule.threat.tactic]
102id = "TA0008"
103name = "Lateral Movement"
104reference = "https://attack.mitre.org/tactics/TA0008/"
105[[rule.threat]]
106framework = "MITRE ATT&CK"
107[[rule.threat.technique]]
108id = "T1133"
109name = "External Remote Services"
110reference = "https://attack.mitre.org/techniques/T1133/"
111
112
113[rule.threat.tactic]
114id = "TA0003"
115name = "Persistence"
116reference = "https://attack.mitre.org/tactics/TA0003/"
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 SSH Process Launched From Inside A Container
SSH (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.
Possible investigation steps
- Review the container identifier (container.id) associated with the SSH process to determine which container initiated the process and assess its intended function.
- 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.
- Check for any recent changes or deployments related to the container to identify if the SSH process aligns with expected behavior or recent updates.
- 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.
- 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.
- Correlate the SSH activity with other security events or alerts to identify patterns or additional indicators of compromise within the container environment.
False positive analysis
- 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.
- 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.
- 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.
- 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.
- Regularly review and update the exclusion list to ensure it aligns with current operational practices and does not inadvertently allow malicious activity.
Response and remediation
- 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.
- 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.
- 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.
- 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.
- Implement network segmentation to limit the ability of containers to communicate with each other and the host system, reducing the risk of lateral movement.
- 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.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems or containers have been affected.
References
Related rules
- SSH Authorized Keys File Modified Inside a Container
- SSH Connection Established Inside A Running Container
- AWS Credentials Searched For Inside A Container
- Container Management Utility Run Inside A Container
- File Made Executable via Chmod Inside A Container