Incident response

Network traffic analysis for IR: SSH protocol with Wireshark

 SSH protocol

The Secure Shell (SSH) is designed to allow confidential and authenticated remote access to a computer. Like the Telnet protocol, it enables a user to remotely access a command shell on a machine, run commands and access the results. However, unlike Telnet, SSH traffic is fully encrypted, making it the correct choice for remotely interacting with a machine.

SSH is assigned port 22 in both TCP and UDP. However, the protocol primarily runs over TCP due to its need for reliable communications, proper packet ordering and so on. A number of different SSH implementations exist, but the primary ones are OpenSSH (on *nix systems) and PuTTY and WinSCP on Windows Systems.

Learn Incident Response

Get hands-on experience with incident response tools and techniques as you progress through nine courses.

Get Started

The SSH protocol in Wireshark

The main difference between SSH and Telnet is that SSH provides a fully encrypted and authenticated session. The way that SSH accomplishes this is very similar to SSL/TLS, which is used for encryption of web traffic (HTTPS) and other protocols without built-in encryption.

The screenshot above shows a sample SSH session in Wireshark. As shown, packets associated with the session are filtered using the built-in ssh filter.

To accomplish its goals, SSH uses two different types of cryptography. Symmetric cryptography, like the Advanced Encryption Standard (AES), is faster and more efficient for bulk encryption, but it requires a shared secret key. Asymmetric encryption, on the other hand, doesn’t require a shared secret key but is less efficient.

SSH uses asymmetric cryptography to establish a shared secret key and then symmetric cryptography for bulk encryption with that key. The use of asymmetric cryptography is shown in the screenshot above as Diffie-Hellman is a protocol for secure key generation.

Diving into packet 21, as shown above, we see the use of symmetric cryptography as well. This SSH session will be using AES-128 in Counter mode for encryption with an HMAC based upon MD5 to ensure message integrity. While this dates the capture (MD5 is deprecated), it shows how SSH works and looks in Wireshark.

SSH protocol analysis for incident response

SSH is an extremely powerful protocol. It enables remote, encrypted access to any system running an SSH server. As a result, it can be used for a variety of different purposes, including credential-stuffing attacks, scanning for machines running vulnerable SSH servers and establishing reverse shells.

Credential stuffing

SSH requires user authentication. This means that if an attacker has access to a computer running an SSH server, they can perform a credential-stuffing attack against it.

Credential stuffing involves trying a list of breached or guessed user credentials to try to gain access to a user’s account. While SSH can be configured to lock a user’s account after a certain number of incorrect login attempts, the fact that many people use the same credentials for multiple accounts can mean that only one or two tries are enough.

Since SSH traffic is encrypted, it is not easy to differentiate successful versus failed login attempts in Wireshark. However, some features of the traffic can help to reveal whether or not an attempted authentication is successful:

1. Flow length: A successful authentication attempt will result in a longer session than a failed
2. Packet size: SSH servers have set responses for successful and failed authentications. Observing the length of the SSH packets can show whether authentication succeeded or failed. In Zeek, a server is assumed to send a 5 kB response to a login request if the authentication was successful
3. Packet timing: Packets that require user interaction will take longer than automated ones, making them easier to detect

Using this information, comparing traffic capture statistics can help to detect successful versus unsuccessful SSH sessions.

Looking at the two screenshots above, the top one shows a successful SSH session, while the lower one shows an SSH brute-force guessing attack. They can be differentiated based off of the bytes being sent from the server (B) to the client (A), where a successful authentication attempt results in much more data being sent than an unsuccessful one.

A credential-stuffing attack could try to breach a single user or many at once. Look in Wireshark for unusual numbers of SSH login attempts, whether or not they are successful. Credential stuffers may also try to fly under the radar by distributing their efforts over many accounts so as to never hit the failed login threshold.

Remote access scanning

Best practice is to block all SSH traffic at the network firewall or to implement whitelists to limit remote access to authenticated users. However, the explosion of Internet of Things devices and other systems that have SSH enabled by default means that this practice is not always followed. To make things worse, these systems often use default or hardcoded credentials, meaning that anyone who knows or can guess the credentials in use on a system can leverage them to gain remote access to these devices.

Attempts to take advantage of unsecured SSH servers on an internal network are fairly straightforward to spot. Since legitimate SSH requests should either originate from inside the network or from known, trusted IP addresses, filtering in Wireshark using the ssh filter and filtering the results for external IP addresses can detect external connection requests. These can then be evaluated to determine their legitimacy.

However, not all malicious use of SSH comes from outside the organization’s network. Once an attacker has gained a foothold on an internal machine, SSH is an ideal protocol for using stolen credentials to expand this foothold to other machines. This can be detected based upon unusual SSH access patterns, like a high amount of traffic originating from a single machine or requests from a machine to other systems that it does not usually contact.

Reverse shell

Another common use of SSH is for reverse shells. If an organization’s firewall is properly configured, inbound SSH should be blocked at the network perimeter, making it difficult for an external attacker to take advantage of SSH to gain access to an organization’s network.

However, the opposite may not be true. Most organizations use a “default allow” policy for outbound traffic, meaning that SSH connections from internal machines to external ones will be permitted. If a cybercriminal is able to install malware on an internal machine, they can get it to “call out” to an external computer under their control with an SSH session.

Detecting these sessions may require more than just looking for outbound traffic on port 22. Since the attacker controls both ends of the session, they can run it on any port that they choose. Looking for outbound, encrypted traffic on unusual ports that could be SSH or a similar protocol is a good idea in this case. In these cases, traffic on a non-standard SSH port (i.e., not port 22) will contain the SSH setup handshake. Wireshark can be forced to decode any traffic as SSH by selecting Analyze → Decode As and setting the appropriate port type, port number and protocol.

Learn Network Traffic Analysis for Incident Response

Get hands-on experience with nine courses covering how to collect, identify, extract and analyze network traffic.

Start Learning

Conclusion: monitoring SSH in Wireshark

The power of the SSH protocol, and its usefulness to hackers, mean that it needs to be closely monitored and controlled within an organization’s network. Strictly controlling (or even blocking) SSH traffic at the network border is a good idea, and internal communications should be monitored for any abnormalities that may indicate attempts at lateral movement within the network.

Sources

1. Port 22 Details, SpeedGuide
2. SSH (Secure Shell), SSH (Secure Shell) Home Page
3. CS Personal, cloudshark.org
4. Secure Shell (SSH), Wireshark
5. Detecting SSH brute forcing with Zeek, HoldMyBeer