We just saw a problem statement where we can't figure out the difference between brute force attempts through PCAP analysis. One reason for this failure is that there is an encryption in place, and we can't make out the encrypted content differences. Let's investigate the SSH login logs from the server and see if we can understand what happened.

Let's open the raw access.log file and check whether or not we can get something of interest:

Oops! There are just too many authentication failures. It was a brute force attack. Let's check whether the attacker was able to gain access to the server or not:

A simple text search over the log file to find "Accepted" anywhere in the log file prints out that a password was accepted by the SSH service, suggesting that the authentication took place successfully. Looking at the successful authentication within the auth.log file, we have the following:

We can see that a successful session was opened for the root user, but was disconnected immediately, and the attack continued. The attacker used an automated brute force tool that didn't stop at finding the correct password.

There is one additional thing to notice if you haven't already—there is a time difference between the packets in the PCAP file and the logs. This might have occurred because time on the SSH server and time on the monitoring system (system where the PCAP is being recorded) are different. Let's correct the time of packet arrival using editcap, as follows:

Since the time in the very first screenshot of this chapter and the one present in the logs have a difference of exactly +2:30 hours, we will need to adjust this time. As we can see in the preceding screenshot, we are using editcap to edit the current time by adding 9000 seconds (2:30 hours in seconds). We created a new file with the adjusted time as ssh_adjusted.pcap. Let's open it up in Wireshark, as follows:

We can now see the adjusted time according to the logs and can see exactly what was going on at that particular time. We can see that on the 53100 port, there are plenty of packets communicating over the SSH. By filtering out the stream, we get the following:

The TCP streams 35, 36, and 37 have 25 packets individually, while for the others they have 42. Let's open the conversations, as follows:

We can see that for most of the streams, the relative number of packets was 42, while during the time frame that we got from the SSH logs, the number of packets is different, denoting a change that is a successful attempt.

We can see that by learning the insights of log analysis along with network packet analysis, we can make much more sense of the network evidence that we otherwise wouldn't have. Along with SSH, the use of HTTP proxies such as HaProxy and Squid is quite widespread in the industry, which makes them a great candidate for log analysis as well. Let's see some examples of this in the following sections.