Potential Execution via XZBackdoor
It identifies potential malicious shell executions through remote SSH and detects cases where the sshd service suddenly terminates soon after successful execution, suggesting suspicious behavior similar to the XZ backdoor.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2024/04/01"
3integration = ["endpoint"]
4maturity = "production"
5updated_date = "2025/02/04"
6
7[rule]
8author = ["Elastic"]
9description = """
10It identifies potential malicious shell executions through remote SSH and detects cases where the sshd service suddenly
11terminates soon after successful execution, suggesting suspicious behavior similar to the XZ backdoor.
12"""
13from = "now-9m"
14index = ["logs-endpoint.events.network*", "logs-endpoint.events.process*"]
15language = "eql"
16license = "Elastic License v2"
17name = "Potential Execution via XZBackdoor"
18references = [
19 "https://github.com/amlweems/xzbot",
20 "https://access.redhat.com/security/cve/CVE-2024-3094",
21 "https://www.elastic.co/security-labs/500ms-to-midnight",
22]
23risk_score = 73
24rule_id = "7afc6cc9-8800-4c7f-be6b-b688d2dea248"
25severity = "high"
26tags = [
27 "Domain: Endpoint",
28 "OS: Linux",
29 "Use Case: Threat Detection",
30 "Tactic: Credential Access",
31 "Tactic: Persistence",
32 "Tactic: Lateral Movement",
33 "Data Source: Elastic Defend",
34 "Resources: Investigation Guide",
35]
36timestamp_override = "event.ingested"
37type = "eql"
38
39query = '''
40sequence by host.id, user.id with maxspan=1s
41 [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "sshd" and
42 process.args == "-D" and process.args == "-R"] by process.pid, process.entity_id
43 [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.parent.name == "sshd" and
44 process.executable != null and not (
45 process.executable in ("/usr/sbin/sshd", "/usr/sbin/unix_chkpwd", "/usr/bin/google_authorized_keys", "/usr/bin/fipscheck") or
46 process.args like ("rsync*", "systemctl*", "/usr/sbin/unix_chkpwd", "/usr/bin/google_authorized_keys", "/usr/sbin/aad_certhandler*") or
47 process.command_line like "sh -c /usr/bin/env -i PATH=*"
48 )] by process.parent.pid, process.parent.entity_id
49 [process where host.os.type == "linux" and event.action == "end" and process.name == "sshd" and process.exit_code != 0] by process.pid, process.entity_id
50 [network where host.os.type == "linux" and event.type == "end" and event.action == "disconnect_received" and process.name == "sshd"] by process.pid, process.entity_id
51'''
52note = """## Triage and analysis
53
54> **Disclaimer**:
55> 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.
56
57### Investigating Potential Execution via XZBackdoor
58
59The XZBackdoor leverages SSH, a secure protocol for remote access, to execute malicious commands stealthily. Adversaries exploit SSH by initiating sessions that mimic legitimate activity, then abruptly terminate them post-execution to evade detection. The detection rule identifies anomalies by tracking SSH processes that start and end unexpectedly, especially when non-standard executables are invoked, signaling potential backdoor activity.
60
61### Possible investigation steps
62
63- Review the SSH session logs on the affected host to identify any unusual or unauthorized access attempts, focusing on sessions that match the process.pid and process.entity_id from the alert.
64- Examine the command history and executed commands for the user associated with the user.id in the alert to identify any suspicious or unexpected activities.
65- Investigate the non-standard executables invoked by the SSH session by checking the process.executable field to determine if they are legitimate or potentially malicious.
66- Analyze the network activity associated with the SSH session, particularly any disconnect_received events, to identify any unusual patterns or connections to suspicious IP addresses.
67- Check the exit codes of the SSH processes, especially those with a non-zero process.exit_code, to understand the reason for the abrupt termination and whether it aligns with typical error codes or indicates malicious activity.
68
69### False positive analysis
70
71- Legitimate administrative SSH sessions may trigger the rule if they involve non-standard executables. To manage this, create exceptions for known administrative scripts or tools that are frequently used in your environment.
72- Automated processes or scripts that use SSH for routine tasks might mimic the behavior of the XZBackdoor. Identify these processes and exclude them by specifying their executable paths or command-line patterns in the rule exceptions.
73- Security tools or monitoring solutions that perform SSH-based checks could be mistaken for malicious activity. Review these tools and add their signatures to the exclusion list to prevent false alerts.
74- Custom applications that use SSH for communication might be flagged. Document these applications and adjust the rule to recognize their specific execution patterns as non-threatening.
75- Temporary network issues causing abrupt SSH session terminations could be misinterpreted as suspicious behavior. Monitor network stability and consider excluding known transient disconnections from triggering alerts.
76
77### Response and remediation
78
79- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement.
80- Terminate any suspicious SSH sessions identified by the detection rule to stop ongoing malicious activity.
81- Conduct a thorough review of the affected host's SSH configuration and logs to identify unauthorized changes or access patterns.
82- Reset credentials for any user accounts involved in the suspicious SSH activity to prevent further unauthorized access.
83- Restore the affected system from a known good backup if any unauthorized changes or malware are detected.
84- Implement network segmentation to limit SSH access to critical systems and reduce the attack surface.
85- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are compromised."""
86
87[[rule.threat]]
88framework = "MITRE ATT&CK"
89
90[[rule.threat.technique]]
91id = "T1543"
92name = "Create or Modify System Process"
93reference = "https://attack.mitre.org/techniques/T1543/"
94
95[rule.threat.tactic]
96id = "TA0003"
97name = "Persistence"
98reference = "https://attack.mitre.org/tactics/TA0003/"
99
100[[rule.threat]]
101framework = "MITRE ATT&CK"
102
103[[rule.threat.technique]]
104id = "T1556"
105name = "Modify Authentication Process"
106reference = "https://attack.mitre.org/techniques/T1556/"
107
108[rule.threat.tactic]
109id = "TA0006"
110name = "Credential Access"
111reference = "https://attack.mitre.org/tactics/TA0006/"
112
113[[rule.threat]]
114framework = "MITRE ATT&CK"
115
116[[rule.threat.technique]]
117id = "T1021"
118name = "Remote Services"
119reference = "https://attack.mitre.org/techniques/T1021/"
120
121[[rule.threat.technique.subtechnique]]
122id = "T1021.004"
123name = "SSH"
124reference = "https://attack.mitre.org/techniques/T1021/004/"
125
126[[rule.threat.technique]]
127id = "T1563"
128name = "Remote Service Session Hijacking"
129reference = "https://attack.mitre.org/techniques/T1563/"
130
131[[rule.threat.technique.subtechnique]]
132id = "T1563.001"
133name = "SSH Hijacking"
134reference = "https://attack.mitre.org/techniques/T1563/001/"
135
136[rule.threat.tactic]
137id = "TA0008"
138name = "Lateral Movement"
139reference = "https://attack.mitre.org/tactics/TA0008/"
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 Potential Execution via XZBackdoor
The XZBackdoor leverages SSH, a secure protocol for remote access, to execute malicious commands stealthily. Adversaries exploit SSH by initiating sessions that mimic legitimate activity, then abruptly terminate them post-execution to evade detection. The detection rule identifies anomalies by tracking SSH processes that start and end unexpectedly, especially when non-standard executables are invoked, signaling potential backdoor activity.
Possible investigation steps
- Review the SSH session logs on the affected host to identify any unusual or unauthorized access attempts, focusing on sessions that match the process.pid and process.entity_id from the alert.
- Examine the command history and executed commands for the user associated with the user.id in the alert to identify any suspicious or unexpected activities.
- Investigate the non-standard executables invoked by the SSH session by checking the process.executable field to determine if they are legitimate or potentially malicious.
- Analyze the network activity associated with the SSH session, particularly any disconnect_received events, to identify any unusual patterns or connections to suspicious IP addresses.
- Check the exit codes of the SSH processes, especially those with a non-zero process.exit_code, to understand the reason for the abrupt termination and whether it aligns with typical error codes or indicates malicious activity.
False positive analysis
- Legitimate administrative SSH sessions may trigger the rule if they involve non-standard executables. To manage this, create exceptions for known administrative scripts or tools that are frequently used in your environment.
- Automated processes or scripts that use SSH for routine tasks might mimic the behavior of the XZBackdoor. Identify these processes and exclude them by specifying their executable paths or command-line patterns in the rule exceptions.
- Security tools or monitoring solutions that perform SSH-based checks could be mistaken for malicious activity. Review these tools and add their signatures to the exclusion list to prevent false alerts.
- Custom applications that use SSH for communication might be flagged. Document these applications and adjust the rule to recognize their specific execution patterns as non-threatening.
- Temporary network issues causing abrupt SSH session terminations could be misinterpreted as suspicious behavior. Monitor network stability and consider excluding known transient disconnections from triggering alerts.
Response and remediation
- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement.
- Terminate any suspicious SSH sessions identified by the detection rule to stop ongoing malicious activity.
- Conduct a thorough review of the affected host's SSH configuration and logs to identify unauthorized changes or access patterns.
- Reset credentials for any user accounts involved in the suspicious SSH activity to prevent further unauthorized access.
- Restore the affected system from a known good backup if any unauthorized changes or malware are detected.
- Implement network segmentation to limit SSH access to critical systems and reduce the attack surface.
- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are compromised.
References
Related rules
- Modification of OpenSSH Binaries
- Pluggable Authentication Module (PAM) Version Discovery
- Potential OpenSSH Backdoor Logging Activity
- Polkit Policy Creation
- Creation or Modification of Pluggable Authentication Module or Configuration