Detecting and Mitigating SSH Lateral Movement (T1021.004)

SSH is the front door to a large share of the servers on any network. That is exactly why it shows up in MITRE ATT&CK as SSH, technique T1021.004, under Lateral Movement. It applies to ESXi, Linux, macOS and Windows.

The technique is simple to describe. An adversary uses a valid account to log into a remote machine over SSH, then acts as that user.

How attackers use it

SSH opens remote shells on other computers. Many Linux and macOS versions include it, typically switched off until someone turns it on. Modern Windows includes a built-in SSH server and client. On ESXi, MITRE notes SSH can be enabled on the host itself, for example with vim-cmd hostsvc/enable_ssh, or through vCenter.

The server can accept passwords, key pairs or both. With key pairs, the user's public key sits in a file on the server that lists which keys may log in as that user. That file is where SSH Authorized Keys, a separate MITRE technique, comes in. A stolen private key and a listed public key are all it takes.

So the attack pattern is a login that looks legitimate, because it is: valid account, valid key, normal protocol. What gives it away is context and what happens next.

How to detect it

MITRE's strategy (DET0596) is a behavioral chain with one analytic per platform family:

• Linux and similar systems. An SSH login from a remote system through sshd, followed by execution of suspicious binaries or privilege escalation behavior by that user.
• macOS. An SSH login visible in the Unified Logs, followed by unusual process execution, especially outside the user's normal pattern.
• ESXi. A login recorded by hostd or in /var/log/auth.log, followed by command line access to the host shell or file changes in restricted areas.

Useful questions to ask of that data:

• Is this source host one that normally connects here? Servers talking to servers over SSH may be routine for a deployment tool and unusual for a database host.
• Did a user who always works from a laptop suddenly log in from a server?
• Is SSH enabled on an ESXi host that nobody has touched in months?
• Did a successful login arrive at an odd hour, followed by a new shell and a privilege change?

How to reduce the risk

MITRE lists three mitigations.

1. Disable the SSH daemon where it is not needed, especially on ESXi servers. On macOS, make sure Remote Login is off in Sharing preferences.
2. Require multi-factor authentication for SSH wherever possible. MITRE gives password-protected SSH keys as one example of a second factor.
3. Limit which accounts can log in over SSH.

Each step closes a different gap: exposure, stolen credentials and over-broad access.

Check your own environment

Read-only checks. Run the Linux ones on a Linux host, and expect to need sudo for some.

# Linux: show the effective sshd settings that matter most
sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin|allowusers|allowgroups|pubkeyauthentication'

# Linux: list recent successful SSH logins (Debian and Ubuntu path)
sudo grep 'Accepted' /var/log/auth.log | tail -n 50

# Linux: is anything listening on the SSH port?
ss -tlnp | grep ':22'

# macOS: is Remote Login (SSH) enabled?
sudo systemsetup -getremotelogin

# Windows: is the OpenSSH server service present and running?
Get-Service sshd

Then check these:

• Which accounts are allowed to log in over SSH, and does the list match the people who need it?
• Do any authorized key files contain keys nobody can account for?
• Is password login still accepted on internet-facing or sensitive hosts?
• Are private keys stored in source repositories? The Secrets Scanning demo below shows how that class of leak is found.

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Sources

• MITRE ATT&CK, SSH (T1021.004)