Disclaimer: There are many non-hyper-technical roles in the vast world of cybersecurity. Not everyone in cybersecurity has to do packet capturing and/or analysis. However, if you’re in a more technical area (network or security administration, blue teaming, red teaming, etc), it’s a very useful thing to know how to. This article is geared towards beginner-ish people in that area.

In this article, I describe a very simple scenario in which I encountered some unexpected behaviour in a small lab network, and how I used packet capture and analysis to figure out exactly what was going on.

Analysis does not have to involve super complex and technical methods or tools. Simply looking at the packets in order to be able to answer questions like “What exactly happened?” or “Why did this happen?” is analysis. Obviously, as questions become more complex, the techniques may become more complex, and the questions may not be entirely answerable by packet analysis alone. However the basic principles will still be applicable even in the most complex situations.

The scenario

I was doing some work in snort and was playing with a very simple rule. I wanted to be sure it had the desired effect, so I decided to compare the effects of a certain action (an FTP connection) before the rule was enabled and after. The rule in question was meant to drop any packets attempting to reach port 21 on a server, so I expected the connection to work (at least up to the username prompt) before enabling the rule, and for it to fail after enabling the rule.

When I attempted the FTP connection before enabling the rule, however, I noticed that I got logged in immediately. It looked something like this:

A successful login was completely unexpected because I had not provided any credentials. I didn’t know the credentials for this server, but that was irrelevant because I didn’t even get the chance to get the credentials wrong. I tried to login from another machine and I received something more similar to what I had expected:

This is what my little network looked like:

Client 1: ncftp running on Alpine Linux. Alpine does not come by default with the plain “ftp” client I was used to, so I did a quick search and found ncftp listed as the first ftp client on the Alpine Linux Wiki.

Client 2: ftp running on Kali Linux

Server: metasploitable

I needed to know exactly what was going on in the communication between these clients and the server. Not just because the interaction was unusual for me, but more importantly because of the intrusion prevention rule I was trying to write. If we cannot establish reliable/predictable baselines before enabling these network-level rules, then the outcome after enabling might be even more unpredictable, and not work or secure us the way we intend.

What I did

I decided to run a packet capture tool on the server. Because the server is the common denominator here, I consider it the quicker way of determining what was going on with both FTP connection attempts. It would show me exactly what the clients were saying to the server, and how the server was responding. I believed the answer to my questions would lie in there. I knew that metasploitable is based on Ubuntu, and Ubuntu often comes packaged with tcpdump, which is a pretty popular packet capture tool. I am most familiar with tcpdump and Wireshark/tshark. However, there are very many packet capture tools out there, and most of them will be able to help you get the network level data you need. You will even find free tutorials on how to write your own in Python if you search online just a little bit (more on this later).

I ran tcpdump on the server, copied the pcap back to my main working machine using scp, opened it up in Wireshark, and this is what I saw. Note that 10.10.10.18 is the client, and 10.10.10.16 is the server:

In packets 1 – 3, the TCP connection is set up as expected.

In packet 4, the server sends a 220, which means it is ready for a new user. Normally, the client would start to supply credentials at this point. This is still normal, expected behaviour.

In packet 6, the client sends a username, receives a request for a password in packet 8, and sends a password in packet 10, which is highlighted.

By packet 11, we have established a successful login.

Packets 6 to 11 were surprising to see, because I didn’t remember typing those credentials, and if you look at screenshot 1 above again, you’ll see that that is the case. There was no prompt for username or password, and I didn’t supply them in the initial command either. I doubted my own memory for the tiniest fraction of a second (LOL), then I went to client 1 to retry the login. Again I got the successful login without typing any credentials, so I was sure I wasn’t losing my mind.

My next thought was that the FTP client software I was using (nfctp) was automatically sending credentials to the server. This seemed very unlikely, but it was worth checking out in some way, or I would not be able to reliably eliminate the possibility. I made the assumption that if this were the case, the network packets carrying the login transaction would likely go back and forth very quickly. Thankfully, the pcap file format includes a timestamp per packet record, so I decided to check the timestamps out.

The time format shown above is in the “Seconds Since Beginning of Capture” format in Wireshark. This means that the first packet in the file is at 0.0, and the time shown by each packet is the time interval between that packet and the first one. Knowing this, we look at the time in the packet when the password was set and see that the time is 0.007865. This means that the entire conversation between when I entered the initial ftp command and when the password was sent was less than 8 thousandths of a second. There is simply no way a human being typed credentials that quickly.

It is now safe to conclude that our FTP client (ncftp) is automatically sending credentials to the server, and this is the reason for the difference in behaviour between the two clients. I did a quick internet search to further confirm this. If an application was behaving like this, surely it would be documented somewhere on the internet. And it was. I could now safely continue doing what I was doing, knowing that even though this was unusual, it would not affect the functioning of my snort rule.

While this is a very simple scenario, analysing network traffic will often help you answer important questions about what is happening or what has happened on a network. Sometimes it will not provide the entire answer, but at least a valuable piece of the puzzle.

Apart from a problem-solving tool, packet analysis is also very useful in understanding how a protocol works. For example, there have been a lot of changes in the TLS protocol, and blue teamers and defenders will often have to look at packet capture files (among other materials) to understand how these new protocol developments affect their current defense plans, and to decide whether or not to allow these protocols to be used in their environments. Packet analysis is also useful for finding vulnerabilities and developing exploits.

Here are a few more things to note:

1. Get familiar with something called snaplen in whatever packet capture tool you’re using. It can affect the effectiveness of your packet captures, or how much information you can capture. There’s plenty of information on the internet, and man pages are great too!
2. Get familiar with capture filters in whatever tool you’re using as you learn, grow, and explore. You may not use them every single time you capture packets. However, they help you specify exactly what you want to capture (such as traffic from a specific interface, IP address, port, or even number of packets). If your pcap file is just small enough, you save storage space, and have to wade through much less noise before finding the answers to your questions.
3. There are many packet capture and analysis tools out there. I generally advise that people not get hung up on or stuck to any one tool, but adopt a functional approach to choosing tools. Use what works in your scenario, and don’t instinctively shrink from new tools. What you use will depend on a number of factors such as:
   1. what you’re already familiar with
   2. what’s commonly used or approved for use in your organisation
   3. what’s natively installed in the OS in which you’re working (wink wink post-exploitation pentesters)
   4. whether or not you have the rights to install new software on the OS in which you’re working (again wink wink post-exploitation pentesters)
   5. whether your work would be easier/faster in a GUI or not
   6. what features you need (such as following protocol streams in Wireshark).
4. I generally do not recommend that people go find tutorials to write their own tools when so many free and capable ones exist. It may not be the best use of your time if all you want to do is capture some packets. However, if you want to really look under the hood and dissect how packet capture works, how different operating systems handle it, why you generally need root or root-like privileges to do it etc., then it might be beneficial to your learning to find and follow some of these tutorials.
5. We had the random, unintended benefit of finding credentials for the server without actually trying to get it. This will happen sometimes as you work, learn and explore.

Have fun!