Detecting SSH Lateral Movement on Linux

Linux estates lack the logon event taxonomy of Windows, but sshd logs are rich: the method, the account, the source and, for public key logins, the key fingerprint. Attackers add their own keys, reuse stolen ones and hijack forwarded agents. All of it is searchable if you ship auth logs centrally.

Signals at a Glance

Reading Accepted Logins

A successful public key login logs a line of the form Accepted publickey for <user> from <ip> port <n> ssh2: RSA SHA256:<fingerprint>. Extracting user, source and fingerprint lets you detect fan-out and key reuse, which are the two strongest SSH lateral movement behaviours:

index=linux sourcetype=linux_secure "Accepted "
| rex "Accepted (?<method>\S+) for (?<user>\S+) from (?<src>\S+) port \d+ ssh2(?:: \S+ (?<fp>SHA256:\S+))?"
| where cidrmatch("10.0.0.0/8", src) OR cidrmatch("172.16.0.0/12", src) OR cidrmatch("192.168.0.0/16", src)
| bin _time span=1h
| stats dc(host) as dests values(host) as hosts dc(src) as sources by user, fp, _time
| where dests >= 5 OR sources >= 4
| sort - dests
# tune/validate: replace the RFC1918 ranges with your own; exclude configuration-management and
# bastion sources via a lookup before alerting.

A fingerprint accepted on many hosts from many sources is either a shared automation key or a stolen one. Inventory the former so the latter stands out. Equally, a first-time source for an account is a useful low-cost alert; keep a rolling 30-day baseline per user.

Keys, Agents and Persistence

Adding a public key to authorized_keys is quiet persistence and a favourite for lateral movement because it survives password changes. Audit writes to those files and to the SSH daemon configuration:

# /etc/audit/rules.d/ssh.rules  (starting point; validate paths for your distribution)
-w /root/.ssh/authorized_keys -p wa -k ssh_authkeys
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /etc/ssh/sshd_config.d/ -p wa -k sshd_config
# User home directories: add per-user watches or use file integrity monitoring / osquery,
# since auditd cannot wildcard /home/*/.ssh/authorized_keys.
# tune/validate: confirm rule syntax with auditctl -R on a test host before fleet rollout.

• Query osquery authorized_keys across the fleet on a schedule and diff it; the table is built for this.
• Agent hijacking works by reading another user’s SSH_AUTH_SOCK as root. Alert on a root process connecting to a socket under /tmp/ssh-* that belongs to a different user, and disable agent forwarding except to bastions.
• Set LogLevel VERBOSE so key fingerprints are logged, and consider SSH certificates with short validity so keys cannot be silently reused.
• Route SSH through bastions and block direct host-to-host SSH on the network; once you do, any direct login is an alert.