SSH Connection Established Inside A Running Container

This rule detects an incoming SSH connection established inside a running container. Running an ssh daemon inside a container should be avoided and monitored closely if necessary. If an attacker gains valid credentials they can use it to gain initial access or establish persistence within a compromised environment.

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 incoming SSH connection established inside a running container. Running an ssh daemon inside a
 11container should be avoided and monitored closely if necessary. If an attacker gains valid credentials they can use it
 12to gain initial access or establish persistence within a compromised environment.
 13"""
 14false_positives = [
 15    """
 16    SSH usage may be legitimate depending on the environment. Access patterns and follow-on activity should be analyzed
 17    to distinguish between authorized and potentially malicious behavior.
 18    """,
 19]
 20from = "now-6m"
 21index = ["logs-cloud_defend*"]
 22interval = "5m"
 23language = "eql"
 24license = "Elastic License v2"
 25name = "SSH Connection Established Inside A Running Container"
 26references = [
 27    "https://microsoft.github.io/Threat-Matrix-for-Kubernetes/techniques/SSH%20server%20running%20inside%20container/",
 28]
 29risk_score = 73
 30rule_id = "f5488ac1-099e-4008-a6cb-fb638a0f0828"
 31severity = "high"
 32tags = [
 33    "Data Source: Elastic Defend for Containers",
 34    "Domain: Container",
 35    "OS: Linux",
 36    "Use Case: Threat Detection",
 37    "Tactic: Initial Access",
 38    "Tactic: Lateral Movement",
 39    "Resources: Investigation Guide",
 40]
 41timestamp_override = "event.ingested"
 42type = "eql"
 43
 44query = '''
 45process where container.id: "*" and event.type == "start" and
 46
 47/* use of sshd to enter a container*/
 48process.entry_leader.entry_meta.type: "sshd"  and
 49
 50/* process is the initial process run in a container or start of a new session*/
 51(process.entry_leader.same_as_process== true or process.session_leader.same_as_process== true) and
 52
 53/* interactive process*/
 54process.interactive== true
 55'''
 56note = """## Triage and analysis
 57
 58> **Disclaimer**:
 59> 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.
 60
 61### Investigating SSH Connection Established Inside A Running Container
 62
 63SSH (Secure Shell) is a protocol used to securely access and manage systems remotely. In containerized environments, running an SSH daemon is generally discouraged due to security risks. Adversaries may exploit SSH to gain unauthorized access or maintain persistence within a compromised container. The detection rule identifies SSH connections initiated within containers by monitoring for SSH daemon processes that start new sessions, indicating potential unauthorized access attempts. This rule is crucial for identifying and mitigating threats related to initial access and lateral movement within containerized environments.
 64
 65### Possible investigation steps
 66
 67- Review the container ID associated with the alert to identify the specific container where the SSH connection was established.
 68- Examine the process details, particularly focusing on the entry leader and session leader fields, to determine if the SSH daemon process is the initial process or part of a new session within the container.
 69- Check for any interactive sessions initiated by the SSH daemon to confirm if the connection was actively used for interaction.
 70- Investigate the source of the SSH connection by analyzing network logs or connection details to identify the originating IP address and assess if it is known or suspicious.
 71- Correlate the event with user activity logs to determine if the SSH connection aligns with expected user behavior or if it indicates potential unauthorized access.
 72- Assess the container's configuration and security posture to understand why an SSH daemon is running and evaluate if it is necessary or a security oversight.
 73- Review any recent changes or deployments related to the container to identify potential vulnerabilities or misconfigurations that could have been exploited.
 74
 75### False positive analysis
 76
 77- Legitimate administrative access to containers via SSH may trigger the rule. To manage this, create exceptions for known administrative IP addresses or user accounts that regularly access containers for maintenance.
 78- Automated scripts or tools that use SSH for legitimate purposes, such as configuration management or deployment, can cause false positives. Identify these tools and exclude their specific process signatures or user accounts from the rule.
 79- Development or testing environments where SSH is used for debugging or monitoring may also trigger alerts. Consider excluding these environments by tagging them appropriately and adjusting the rule to ignore these tags.
 80- Containers running legacy applications that require SSH for functionality might be flagged. Document these applications and create exceptions based on their specific container IDs or hostnames.
 81
 82### Response and remediation
 83
 84- Immediately isolate the affected container to prevent further unauthorized access or lateral movement within the environment.
 85- Terminate the SSH daemon process running inside the container to cut off any active unauthorized sessions.
 86- Conduct a thorough review of access logs and container activity to identify any unauthorized access attempts or suspicious behavior.
 87- Revoke any compromised credentials and enforce a password reset for affected accounts to prevent further unauthorized access.
 88- Deploy updated container images without SSH daemons and ensure that future container deployments adhere to security best practices.
 89- Implement network segmentation to limit access to containerized environments and reduce the attack surface for similar threats.
 90- Escalate the incident to the security operations team for further investigation and to assess the potential impact on the broader environment."""
 91
 92
 93[[rule.threat]]
 94framework = "MITRE ATT&CK"
 95[[rule.threat.technique]]
 96id = "T1133"
 97name = "External Remote Services"
 98reference = "https://attack.mitre.org/techniques/T1133/"
 99
100
101[rule.threat.tactic]
102id = "TA0001"
103name = "Initial Access"
104reference = "https://attack.mitre.org/tactics/TA0001/"
105[[rule.threat]]
106framework = "MITRE ATT&CK"
107[[rule.threat.technique]]
108id = "T1021"
109name = "Remote Services"
110reference = "https://attack.mitre.org/techniques/T1021/"
111[[rule.threat.technique.subtechnique]]
112id = "T1021.004"
113name = "SSH"
114reference = "https://attack.mitre.org/techniques/T1021/004/"
115
116
117
118[rule.threat.tactic]
119id = "TA0008"
120name = "Lateral Movement"
121reference = "https://attack.mitre.org/tactics/TA0008/"
...
toml

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.

SSH (Secure Shell) is a protocol used to securely access and manage systems remotely. In containerized environments, running an SSH daemon is generally discouraged due to security risks. Adversaries may exploit SSH to gain unauthorized access or maintain persistence within a compromised container. The detection rule identifies SSH connections initiated within containers by monitoring for SSH daemon processes that start new sessions, indicating potential unauthorized access attempts. This rule is crucial for identifying and mitigating threats related to initial access and lateral movement within containerized environments.

  • Review the container ID associated with the alert to identify the specific container where the SSH connection was established.
  • Examine the process details, particularly focusing on the entry leader and session leader fields, to determine if the SSH daemon process is the initial process or part of a new session within the container.
  • Check for any interactive sessions initiated by the SSH daemon to confirm if the connection was actively used for interaction.
  • Investigate the source of the SSH connection by analyzing network logs or connection details to identify the originating IP address and assess if it is known or suspicious.
  • Correlate the event with user activity logs to determine if the SSH connection aligns with expected user behavior or if it indicates potential unauthorized access.
  • Assess the container's configuration and security posture to understand why an SSH daemon is running and evaluate if it is necessary or a security oversight.
  • Review any recent changes or deployments related to the container to identify potential vulnerabilities or misconfigurations that could have been exploited.
  • Legitimate administrative access to containers via SSH may trigger the rule. To manage this, create exceptions for known administrative IP addresses or user accounts that regularly access containers for maintenance.
  • Automated scripts or tools that use SSH for legitimate purposes, such as configuration management or deployment, can cause false positives. Identify these tools and exclude their specific process signatures or user accounts from the rule.
  • Development or testing environments where SSH is used for debugging or monitoring may also trigger alerts. Consider excluding these environments by tagging them appropriately and adjusting the rule to ignore these tags.
  • Containers running legacy applications that require SSH for functionality might be flagged. Document these applications and create exceptions based on their specific container IDs or hostnames.
  • Immediately isolate the affected container to prevent further unauthorized access or lateral movement within the environment.
  • Terminate the SSH daemon process running inside the container to cut off any active unauthorized sessions.
  • Conduct a thorough review of access logs and container activity to identify any unauthorized access attempts or suspicious behavior.
  • Revoke any compromised credentials and enforce a password reset for affected accounts to prevent further unauthorized access.
  • Deploy updated container images without SSH daemons and ensure that future container deployments adhere to security best practices.
  • Implement network segmentation to limit access to containerized environments and reduce the attack surface for similar threats.
  • Escalate the incident to the security operations team for further investigation and to assess the potential impact on the broader environment.

References

Related rules

to-top