Network Connection Initiated by SSHD Child Process

This rule identifies an egress internet connection initiated by an SSH Daemon child process. This behavior is indicative of the alteration of a shell configuration file or other mechanism that launches a process when a new SSH login occurs. Attackers can also backdoor the SSH daemon to allow for persistence, call out to a C2 or to steal credentials.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2024/06/06"
  3integration = ["endpoint"]
  4maturity = "production"
  5updated_date = "2025/01/15"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10This rule identifies an egress internet connection initiated by an SSH Daemon child process. This behavior is
 11indicative of the alteration of a shell configuration file or other mechanism that launches a process when a
 12new SSH login occurs. Attackers can also backdoor the SSH daemon to allow for persistence, call out to a C2
 13or to steal credentials.
 14"""
 15from = "now-9m"
 16index = ["logs-endpoint.events.*"]
 17language = "eql"
 18license = "Elastic License v2"
 19name = "Network Connection Initiated by SSHD Child Process"
 20references = ["https://hadess.io/the-art-of-linux-persistence/"]
 21risk_score = 47
 22rule_id = "63431796-f813-43af-820b-492ee2efec8e"
 23severity = "medium"
 24tags = [
 25    "Domain: Endpoint",
 26    "OS: Linux",
 27    "Use Case: Threat Detection",
 28    "Tactic: Persistence",
 29    "Data Source: Elastic Defend",
 30    "Resources: Investigation Guide"
 31]
 32type = "eql"
 33query = '''
 34sequence by host.id with maxspan=1s
 35  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
 36   process.parent.executable == "/usr/sbin/sshd"] by process.entity_id
 37  [network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and not (
 38     destination.ip == null or destination.ip == "0.0.0.0" or cidrmatch(
 39     destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29",
 40     "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24",
 41     "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10",
 42     "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10",
 43     "FF00::/8", "172.31.0.0/16"
 44     )
 45    ) and not (
 46      process.executable in ("/bin/yum", "/usr/bin/yum") or
 47      process.name in ("login_duo", "ssh", "sshd", "sshd-session")
 48    )
 49  ] by process.parent.entity_id
 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 Network Connection Initiated by SSHD Child Process
 57
 58The SSH Daemon (SSHD) facilitates secure remote logins and command execution on Linux systems. Adversaries may exploit SSHD by modifying shell configurations or backdooring the daemon to establish unauthorized connections, often for persistence or data exfiltration. The detection rule identifies suspicious outbound connections initiated by SSHD child processes, excluding benign processes and internal IP ranges, to flag potential malicious activity.
 59
 60### Possible investigation steps
 61
 62- Review the process details of the SSHD child process that initiated the network connection, focusing on the process.entity_id and process.parent.entity_id to understand the process hierarchy and parent-child relationship.
 63- Examine the destination IP address of the network connection attempt to determine if it is associated with known malicious activity or suspicious external entities, especially since it is not within the excluded internal IP ranges.
 64- Investigate the executable path of the process that initiated the connection to ensure it is not a known benign process like "/bin/yum" or "/usr/bin/yum", and verify if the process name is not among the excluded ones such as "login_duo", "ssh", "sshd", or "sshd-session".
 65- Check the timing and frequency of the SSHD child process executions and network connection attempts to identify any patterns or anomalies that could indicate unauthorized or persistent access attempts.
 66- Correlate the alert with other security events or logs from the same host.id to gather additional context and determine if there are other indicators of compromise or related suspicious activities.
 67
 68### False positive analysis
 69
 70- Internal administrative scripts or tools that initiate network connections upon SSH login can trigger false positives. To manage this, identify and whitelist these specific scripts or tools by their process names or executable paths.
 71- Automated software updates or package management processes like yum may occasionally initiate network connections. Exclude these processes by adding them to the exception list using their executable paths.
 72- Security tools such as login_duo or other authentication mechanisms that establish network connections during SSH sessions can be mistaken for malicious activity. Exclude these tools by specifying their process names in the exception list.
 73- Custom monitoring or logging solutions that connect to external servers for data aggregation might be flagged. Identify these processes and exclude them by their executable paths or process names to prevent false alerts.
 74
 75### Response and remediation
 76
 77- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration.
 78- Terminate any suspicious processes identified as child processes of SSHD that are attempting unauthorized network connections.
 79- Conduct a thorough review of SSHD configuration files and shell configuration files for unauthorized modifications or backdoors, and restore them from a known good backup if necessary.
 80- Change all credentials associated with the affected system, especially those that may have been exposed or used during the unauthorized SSH sessions.
 81- Apply security patches and updates to the SSH daemon and related software to mitigate known vulnerabilities that could be exploited for persistence or unauthorized access.
 82- Monitor network traffic for any further suspicious outbound connections from other systems, indicating potential lateral movement or additional compromised hosts.
 83- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the compromise."""
 84
 85[[rule.threat]]
 86framework = "MITRE ATT&CK"
 87
 88[[rule.threat.technique]]
 89id = "T1546"
 90name = "Event Triggered Execution"
 91reference = "https://attack.mitre.org/techniques/T1546/"
 92
 93[[rule.threat.technique.subtechnique]]
 94id = "T1546.004"
 95name = "Unix Shell Configuration Modification"
 96reference = "https://attack.mitre.org/techniques/T1546/004/"
 97
 98[rule.threat.tactic]
 99id = "TA0003"
100name = "Persistence"
101reference = "https://attack.mitre.org/tactics/TA0003/"
102
103[[rule.threat]]
104framework = "MITRE ATT&CK"
105
106[[rule.threat.technique]]
107id = "T1021"
108name = "Remote Services"
109reference = "https://attack.mitre.org/techniques/T1021/"
110
111[[rule.threat.technique.subtechnique]]
112id = "T1021.004"
113name = "SSH"
114reference = "https://attack.mitre.org/techniques/T1021/004/"
115
116[[rule.threat.technique]]
117id = "T1563"
118name = "Remote Service Session Hijacking"
119reference = "https://attack.mitre.org/techniques/T1563/"
120
121[[rule.threat.technique.subtechnique]]
122id = "T1563.001"
123name = "SSH Hijacking"
124reference = "https://attack.mitre.org/techniques/T1563/001/"
125
126[rule.threat.tactic]
127id = "TA0008"
128name = "Lateral Movement"
129reference = "https://attack.mitre.org/tactics/TA0008/"
130
131[[rule.threat]]
132framework = "MITRE ATT&CK"
133
134[rule.threat.tactic]
135id = "TA0011"
136name = "Command and Control"
137reference = "https://attack.mitre.org/tactics/TA0011/"

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 Network Connection Initiated by SSHD Child Process

The SSH Daemon (SSHD) facilitates secure remote logins and command execution on Linux systems. Adversaries may exploit SSHD by modifying shell configurations or backdooring the daemon to establish unauthorized connections, often for persistence or data exfiltration. The detection rule identifies suspicious outbound connections initiated by SSHD child processes, excluding benign processes and internal IP ranges, to flag potential malicious activity.

Possible investigation steps

  • Review the process details of the SSHD child process that initiated the network connection, focusing on the process.entity_id and process.parent.entity_id to understand the process hierarchy and parent-child relationship.
  • Examine the destination IP address of the network connection attempt to determine if it is associated with known malicious activity or suspicious external entities, especially since it is not within the excluded internal IP ranges.
  • Investigate the executable path of the process that initiated the connection to ensure it is not a known benign process like "/bin/yum" or "/usr/bin/yum", and verify if the process name is not among the excluded ones such as "login_duo", "ssh", "sshd", or "sshd-session".
  • Check the timing and frequency of the SSHD child process executions and network connection attempts to identify any patterns or anomalies that could indicate unauthorized or persistent access attempts.
  • Correlate the alert with other security events or logs from the same host.id to gather additional context and determine if there are other indicators of compromise or related suspicious activities.

False positive analysis

  • Internal administrative scripts or tools that initiate network connections upon SSH login can trigger false positives. To manage this, identify and whitelist these specific scripts or tools by their process names or executable paths.
  • Automated software updates or package management processes like yum may occasionally initiate network connections. Exclude these processes by adding them to the exception list using their executable paths.
  • Security tools such as login_duo or other authentication mechanisms that establish network connections during SSH sessions can be mistaken for malicious activity. Exclude these tools by specifying their process names in the exception list.
  • Custom monitoring or logging solutions that connect to external servers for data aggregation might be flagged. Identify these processes and exclude them by their executable paths or process names to prevent false alerts.

Response and remediation

  • Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration.
  • Terminate any suspicious processes identified as child processes of SSHD that are attempting unauthorized network connections.
  • Conduct a thorough review of SSHD configuration files and shell configuration files for unauthorized modifications or backdoors, and restore them from a known good backup if necessary.
  • Change all credentials associated with the affected system, especially those that may have been exposed or used during the unauthorized SSH sessions.
  • Apply security patches and updates to the SSH daemon and related software to mitigate known vulnerabilities that could be exploited for persistence or unauthorized access.
  • Monitor network traffic for any further suspicious outbound connections from other systems, indicating potential lateral movement or additional compromised hosts.
  • Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the compromise.

References

Related rules

to-top