Lateral movement is a nearly ubiquitous attack tactic, as adversaries hardly ever gain initial access to the exact system that holds their objective. We’ve written a ton about this topic over the years, covering PsExec and other tools that enable adversaries to move laterally between systems. Scores of other blogs discuss Server Message Block (SMB) and Remote Desktop Protocol (RDP) lateral movement at great length. This time, I want to discuss a lesser publicized lateral movement technique: malicious use of Secure Shell (SSH) services.
What is SSH?
SSH is an encrypted network protocol that facilitates remote management of systems that are usually Unix-like. It’s best known for its association with the OpenSSH project and the
ssh command that administrators use for text-based administration similar to Telnet. The OpenSSH project also contains
scp (Secure Copy) to replace an older unencrypted copy utility and
sftp to replace older unencrypted uses of
SSH is versatile as a network protocol and can encapsulate other protocols to help secure them with encryption. It’s a de facto standard of modern administration of Unix-like systems.
SSH in everyday administration
When using SSH, administrators usually start out using the
ssh command with a username and password combination. The usernames and passwords are the same ones used for logging on to a system at the keyboard, and it quickly becomes problematic when the SSH daemon’s port (22) is exposed on a network. Especially on the internet, attackers attempt to brute force access to systems via SSH. If administrators have chosen a non-complex password for well-known user accounts, brute-force attacks will likely succeed.
To mitigate this, SSH sessions are often authenticated using public key cryptography. To do this, administrators may use
ssh-keygen to generate a key-pair before using
ssh-copy-id to deploy the generated public key as appropriate to the
authorized_keys file of a remote system’s user. After changing a few lines in the SSH daemon configuration file, the service is hardened to prevent simple brute-force intrusion. That said, if an adversary gains access to the private key associated with this key-based authentication relationship, they can authenticate to a system via SSH without knowing any additional passwords.
Once an administrator begins a SSH session to a remote system for the first time, they’ll notice that an entry is added to the
known_hosts file of the current user. This file captures IP address and host public key information to ensure authentication happens properly at the system level before a user logs on via SSH. If another IP address shows up with the public key of a known host, the user logging on is alerted.
There are loads of additional complications to SSH administration, but these few concepts lay the groundwork for understanding how adversaries abuse the protocol.
Malicious uses of SSH
Now that we have a good understanding of SSH basics, we can look at how adversaries abuse SSH.
SSH tunneling is the act of encapsulating another networking protocol within SSH to protect it from inspection. FireEye published awesome documentation about adversaries using tunneling earlier this year, focusing on tunneling RDP traffic over SSH.
In these cases, adversaries usually use tools such as
plink.exe to forward RDP traffic over SSH with a command line containing
127.0.0.1:3389. You can spot this quickly in the command line arguments and flag it if it’s not normal in your environment. This helps adversaries bypass firewalls restricting port 3389 and prevent traffic inspection while being able to use RDP. This can also work with numerous additional protocols. In at least one environment, we’ve seen administrators send MySQL network traffic over SSH to encrypt it.
Cryptocurrency miner scripts
Next, let’s look at opportunistic cryptocurrency miner scripts that adversaries deploy to Linux servers. Once exploiting a service and deploying a miner, adversaries want to perform lateral movement to other Linux systems on the same network to deploy more instances of malware. This is done in a few steps. First, an adversary will enumerate the contents of the SSH
known_hosts file to find other Linux hosts that may be available. If any are found, the adversary will check that key-based authentication is in place and use SSH to send the desired commands to remote systems. This sort of lateral movement usually looks something like this: