Gaining Lateral Movement with SSH Password Sniffing

Sometimes the best way to gain lateral movement during a penetration test is to steal a password. Here’s how to sniff passwords from a running SSH server.

Image for post
Image for post
Photo by Clint McKoy on Unsplash

If you’ve managed to gain a remote shell onto a Linux server and elevated your privileges to root (congrats!), the next step is to maintain your access and gain lateral movement around the network. If you’ve been unable to find anything on the compromised server that would indicate a password for any system, including the compromised server, you can always try to sniff SSH passwords straight out of OpenSSH. You can even be doing this while attacking password hashes offline. I always prefer multiple options that race each other to the correct answer.

The Reality of SSH Passwords

Lateral movement through OpenSSH password sniffing is a very viable concept because:

  • People use the same username and password combinations on multiple systems
  • Passwords often follow a common pattern which can be used to predict other passwords on the estate
  • People type valid passwords into the wrong servers.
  • Given enough time, someone will always login

There are exceptions to the above but unfortunately, most organisations are not that mature.

3 Ways to Sniff SSH Passwords on a Compromised Server

The easiest way to sniff SSH passwords is to replace the OpenSSH application with a honeypot. Which honeypot you choose will depend on what you’re trying to achieve. To help you decide, these are the three different categories of SSH honeypots.

  • Low Interaction. A low interaction SSH honeypot will present a user with a login prompt when connecting, may allow a user to ‘log in’ with any username and password, and will allow users to type commands into a terminal session that don’t actually do anything but log. Limited or no feedback is given. After a few seconds of using one of these, it is obvious that you’re not actually using a real shell.
  • Medium Interaction. A medium interaction SSH honeypot will allow a user to ‘log in’ and use a limited set of commands. Executing these commands will change the imagined state inside the rest of the ‘server’. All other commands will do nothing but log.
  • High Interaction. These are very complex honeypots that behave just like the real thing. In reality, this is usually just an intercepting proxy to a real SSH daemon on the server. It will use the host's certificates and signatures and log and relay any keystrokes given. The aim is that the server can be restored whenever required.

There are a lot of SSH honeypots available. Some examples you could use are:

  • Kippo — medium interaction, inspired by Kojoney2
  • Cowrie — medium interaction in normal mode, high interaction when proxying to a real OpenSSH port
  • Kojoney2 — medium interaction
  • SSH Honeypot — low interaction
  • Dockpot — medium interaction
  • HonSSH — high interaction as a proxy to a real OpenSSH port
  • sshesame — low interaction
  • sshipot — high interaction as a proxy to a real OpenSSH port

Stealth is really important. If the owners of the system detect your presence they’re going to shut you off very quickly. For this reason, replacing OpenSSH with a low or medium interaction honeypot isn’t going to work very well. A better option is to:

  1. Move OpenSSH from the existing port (usually 22) to another unused port (such as 2222)
  2. Configure OpenSSH to listen only on the loopback network interface ( or localhost) so that it can’t be discovered remotely.
  3. Install your high interaction honeypot (intercepting proxy) onto port 22 and proxy traffic to the original OpenSSH now on
  4. Configure your honeypot to present the original certificates used by OpenSSH to ensure that the server signature stays the same

With a high interaction/proxy honeypot, you’ll be able to capture all usernames, passwords, and commands used by the systems administrators over an extended period of time. Or at least until they spot the compromise. Anytime anyone logs in or executes are remote script, everything they type or send will be logged into the honeypot logs. Make sure the logs are hard to detect, don’t get too big, and are regularly shipped offsite and truncated.

The benefit of this method is that anything the user does after logging in is also logged. This means we get to see any other passwords they enter, commands they run, servers they talk to, and the context within which they’re working. Even if their shell doesn’t log to a .bash_history file, we still get the history of what they’ve done.

If you’re unable to move OpenSSH to another port and install an intercepting proxy honeypot, you can instead extend OpenSSH with a custom PAM module. The basic steps required are:

  1. Install the prerequisite packages
  2. Install the custom PAM module
  3. Restart sshd to pick up the new module

On an ubuntu based system the PAM Python prerequisites can be installed with:

I’ve updated a PAM module I found at the defunct (via The module now logs all usernames and passwords, regardless of whether or not the username or password was valid. The output is written to a custom file instead of using Syslog as we don’t want to log to the local auth.log file and any connected SIEM tools. That would be a bit obvious.

To install this module, save it to a file in /lib/security/ such as /lib/security/ and update the file /etc/pam.d/sshd to comment out the @include common-auth line and add our new script instead:

Restart sshd and you should start to see login attempts, both failed and successful, appearing in your custom output file /tmp/auth. Don’t forget to check the true /var/log/auth.log file for any errors which would give away what you’re doing. If anything appears, get them fixed before moving on.

Instead of proxying traffic to OpenSSH or extending it with a custom PAM module, you can simply replace the /usr/sbin/sshd binary with a modified version that writes passwords out to a predefined location. The process for this would be:

  1. Identify the version of sshd installed and running on the server
  2. Download the source code for that version of sshd (offline)
  3. Patch the source code to write the output to file of your choice (offline)
  4. Compile sshd (offline)
  5. Copy the modified sshd binary to the compromised server and replace the existing binary with the new one. You’ll need to backup the existing binary so that you can restore it after the engagement ends.

You can find the version of sshd that is running by simply executing the command:

This will generate a usage error but it contains the version number which is what we’re looking for!

The source code for each release of OpenSSH can be found in the branches section of the official OpenSSH GitHub repository. Clone it to your local machine and apply the patch to auth-passwd.c you can find in Brad Tilley’s sshlog and then compile as normal. The output will include an sshd binary we can upload back to the compromised server, hot-swap with the existing binary, and then restart the service.

Once SSH is listening with the new binary, usernames and passwords should be logged in your custom log file.

How to Protect Against SSH Password Sniffing

If you’re still using SSH passwords you’re at risk. Key-based authentication is the way to go. Even if a single session authentication is sniffed, you can’t capture the key that generated the authentication response, only the response itself. The user’s private key remains protected.

Originally published at on February 19, 2020.

Aspiring writer, Cybersecurity Architect, Bug Bounty Hunter, Musician, Movie Producer, Failed Skydiver.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store