Potential SSH Password Grabbing via strace

  1[metadata]
  2creation_date = "2025/11/10"
  3integration = ["endpoint"]
  4maturity = "production"
  5updated_date = "2025/11/24"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects potential SSH password grabbing via the use of strace on sshd processes. Attackers may use strace to capture
 11sensitive information, such as passwords, by tracing system calls made by the sshd process. This rule looks for a sequence
 12of events where an sshd process ends followed closely by the start of a strace process. This may be indicative of an attacker
 13attempting to capture SSH credentials.
 14"""
 15from = "now-9m"
 16index = ["logs-endpoint.events.process-*"]
 17language = "eql"
 18license = "Elastic License v2"
 19name = "Potential SSH Password Grabbing via strace"
 20note = """
 21## Triage and analysis
 22
 23> **Disclaimer**:
 24> 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.
 25
 26### Investigating Potential SSH Password Grabbing via strace
 27
 28This detection flags a suspicious sequence where an sshd process stops and a strace process starts seconds later, indicating attempted snooping of SSH authentication. Capturing syscall activity around login exposes passwords and session secrets, enabling credential theft and lateral movement. Attackers kill sshd, then relaunch or attach with strace, logging read/write and open calls from PAM or keyboard-interactive flows to a file such as /tmp/sshd.trace.
 29
 30### Possible investigation steps
 31
 32- Pull the strace command-line, full path, parent chain, invoking user, and working directory to confirm whether it attached to sshd and whether output was directed to a file.
 33- Correlate systemd/journald and audit logs around the same seconds for sshd stop/start, kill signals, coredumps, or admin actions to distinguish debugging from credential capture.
 34- Identify and preserve any strace output or redirected logs (common in /tmp or home directories) and scan for PAM interactions or TTY reads containing password prompts.
 35- Check ptrace feasibility by verifying UID relationships, CAP_SYS_PTRACE, SELinux/AppArmor policies, and ptrace_scope to assess whether sshd could be traced.
 36- Pivot on the same user and host for adjacent activity such as restarting sshd, running ltrace/gdb/perf, modifying PAM or sshd_config, and creating trace files to gauge intent.
 37
 38### False positive analysis
 39
 40- An administrator intentionally stops sshd and immediately launches strace to troubleshoot a configuration change or startup problem, tracing a controlled test run rather than attempting to capture credentials.
 41- A normal sshd session process ends while strace is started to debug an unrelated application, producing a near-simultaneous end/start sequence even though strace is not attached to sshd or capturing authentication input.
 42
 43### Response and remediation
 44
 45- Immediately kill active strace processes targeting sshd (e.g., strace -p PID or strace -f /usr/sbin/sshd with -o /tmp/sshd.trace), isolate the host from the network, and restart the sshd service to restore a clean state.
 46- Preserve forensic copies, then remove artifacts such as trace outputs like /tmp/sshd.trace or ~/sshd.strace.log, purge unauthorized strace wrappers or cron entries, and revert changes in /etc/ssh/sshd_config and /etc/pam.d/*.
 47- Force credential hygiene by expiring passwords for users who logged in during the suspected window, rotating SSH host keys in /etc/ssh/ (ssh_host_*), revoking recently added ~/.ssh/authorized_keys entries, and terminating lingering sshd child sessions and SSH agents in /tmp or /run.
 48- Escalate to incident response if strace was executed as root or via sudo against /usr/sbin/sshd, if CAP_SYS_PTRACE or ptrace_scope=0 was present, if trace files contain password strings or PAM conversation data, or if similar behavior appears on more than one host.
 49- Harden by setting /proc/sys/kernel/yama/ptrace_scope to 1 or 2, enforcing SELinux/AppArmor policies that block ptrace to sshd, disabling PasswordAuthentication or requiring MFA in /etc/ssh/sshd_config, and adding auditd rules to alert on ptrace attaches to /usr/sbin/sshd.
 50
 51"""
 52references = [
 53    "https://github.com/braindead-sec/ssh-grabber",
 54    "https://dfir.ch/posts/strace/",
 55]
 56risk_score = 47
 57rule_id = "9eaa3fb1-3f70-48ed-bb0e-d7ae4d3c8f28"
 58severity = "medium"
 59tags = [
 60    "Domain: Endpoint",
 61    "OS: Linux",
 62    "Use Case: Threat Detection",
 63    "Tactic: Persistence",
 64    "Tactic: Credential Access",
 65    "Data Source: Elastic Defend",
 66    "Resources: Investigation Guide",
 67]
 68timestamp_override = "event.ingested"
 69type = "eql"
 70query = '''
 71sequence by host.id with maxspan=3s
 72  [process where host.os.type == "linux" and event.type == "end" and process.name == "sshd"]
 73  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "strace"]
 74'''
 75
 76[[rule.threat]]
 77framework = "MITRE ATT&CK"
 78
 79[[rule.threat.technique]]
 80id = "T1556"
 81name = "Modify Authentication Process"
 82reference = "https://attack.mitre.org/techniques/T1556/"
 83
 84[rule.threat.tactic]
 85id = "TA0006"
 86name = "Credential Access"
 87reference = "https://attack.mitre.org/tactics/TA0006/"
 88
 89[[rule.threat]]
 90framework = "MITRE ATT&CK"
 91
 92[[rule.threat.technique]]
 93id = "T1554"
 94name = "Compromise Host Software Binary"
 95reference = "https://attack.mitre.org/techniques/T1554/"
 96
 97[rule.threat.tactic]
 98id = "TA0003"
 99name = "Persistence"
100reference = "https://attack.mitre.org/tactics/TA0003/"