How to capture ftp packets in wireshark?

Before anything else, know this: Wireshark is an extremely powerful tool! It allows one to see what’s happening in a network, and it does this by showing all the traffic on an interface. It literally just dumps each and every packet going across the network. Well, not just dump them but also:

… and much more!

As a competent penetration tester, network security engineer or a network adminitrator, you should be well-versed with Wireshark (or any packet sniffer in general).

There are two ways to use Wireshark: Using the GUI or the CLI. And we are going to learn the GUI version as it is easier to learn and understand.

There is one major requirement before getting started with any packet sniffer, which it to have a solid understanding of the TCP/IP Model, which should be pretty obvious as to why? It is because Wireshark shows packets carrying data from all the various layers from one system onto another system, which you, as an expert (or an enthusiast) are going to analyze.

When you open Wireshark, the main screen will be divided into two broad section: “Open” and “Capture”

The “Open” section lets you open the previously saved captures (which will be blank if you opened wireshark the first time) and the “Capture” section lets you capture the traffic from a particular interface. You can notice that these are the same interfaces you see when you run the command ip addr

The most common interfaces woulb be ‘wlan0’ for wireless connection and ‘eth0’ for ethernet connection. And if you don’t know what you are doing and just open ‘any’ interface, you’ll be overwhelmed by the amount of “noise” in the network (See the video below). In order to facilitate the analysis, we should apply capture filters and display filters

As the name suggests, filters are a collection of strings used to filter out data (that’s the best explanation I can come up with in as little as possible)

Capture filter are filters used to reduce the number of packets captured. As shown in the video above, Wireshark (by default) captures each and every packet flowing in the network. This might not be ideal in some situations, so we can reduce the number of packets captured by applying capture filters. You can see the capture filter box in the interface section in the first photo.

Some of the most simple but useful capture filters are:

With this filter, only http packets will be captured to and from the network.

This filter helps us to capture packets originating from a whole subnet given by the CIDR notation. This could be useful when you know the malicious activity is being performed from a system in a particular subnet and you need to filter out the rest of the packets.

This is also useful if you have a server which only has a website hosted and a FTP share. So if any other port is accessed, you know something’s wrong.

Display Filters are those filters which work on pre-captured packets. That is to say that they dont ‘capture’ packets based on some criteria, but rather just ‘display’ those specific packets filtered by the argument. Consider this example for a better understanding: Say that a total of 1000 packets are gonna flow for a particular activity on the network, out of which 400 packets are from IP 10.0.0.1 and the rest 600 are from IP 10.0.0.2

So the equivalent display filters for the above capture filters would be:

Now that the basics of Wireshark is done, let’s start with the hands-on. We will be examining a Wireshark capture between my system and a remote system with FTP service enabled. (You can download this packet capture if you want to).

Note

The FTP session conversation was this:

And the packet log is shown below

So let’s go over each and every command and see what’s happening. The client IP in this case was 10.10.15.211 and the FTP server was hosted on the machine with IP 10.10.10.187

When we type in the command ftp 10.10.10.187 we are immediately shown the following output:

It shows “connected”, but before any TCP connection is established, a 3-way handshake was performed as it can be seen with the captured packets.

The first three packets of the capture is the 3-way handhshake, highlighted with grey in Wireshark, which can be seen with the tshark output above. The fourth packet is the FTP banner sent by the remote server and the fifth is the acknowledgment of the previous packet. This can be summarized with the following sequence diagram.

and this is the output in the terminal when the connection has been established

When the connection has been established, The FTP asks for username and password:

And the corresponding packets for this interaction were…

From the above output we can formulate the given sequence diagram for the packet flow.

And once authorized, our system issued a SYST command to ask the system type of the remote server.

We couldn’t have known this if we didn’t see the packets being transferred, and the packets that gave this output were:

To represent it in a sequence diagram…

After being authorized, I performed the simplest command, that is ls which gave the following output:

Surprisingly, behind such a simple command, a series of packets are transferred:

So let’s go over the packets one by one:

So, to understand it better, we’ll be dividing it into two different diagrams. One, the formalities that need to be done to initiate the transfer and second, the data transfer itself.

First, the formalities:

And its corresponding sequence diagram

Then, the data transfer:

and its corresponding sequence diagram

All this was happening just to display the contents of a folder!

Note

After listing the directory contents, I downloaded the file named dump.sql using the command mget (I know I could have used get but it’s a habit now to use mget all the time):

And the corresponding packets for this were:

mget command too invokes series of different commands to download a file, which are:

Let’s look at each one of them, starting from outermost:

1. The Invoking of Requests

Which could be easily understood by:

After all this, all that is left is to quit the FTP session

And the packets this command generated were:

Which should be fairly easy to understand now, after looking at all these sequence diagrams.

As the name implies, FTP is used to transfer files.

FTP uses plain text passwords, so take care.

XXX - add a brief description of FTP history

XXX - Add example traffic here (as plain text or Wireshark screenshot).

The FTP dissector is fully functional.

There are no FTP specific preference settings.

XXX - Add a simple example capture file to the SampleCaptures page and link from here. Keep it short, it's also a good idea to gzip it to make it even smaller, as Wireshark can open gzipped files automatically.

A complete list of FTP display filter fields can be found in the display filter reference

Show only the FTP based traffic:

You cannot directly filter FTP protocols while capturing. However, if you know the TCP port used (see above), you can filter on that one.

One of the issues with FTP is that it is a completely plaintext protocol and can be configured to allow anonymous authentication to the service. Since the protocol is designed to allow files to be added to or removed from the FTP server, this can be a significant security concern.

A couple of different protocols exist for securing FTP. FTPS is the use of FTP traffic wrapped in Transport Layer Security (TLS). SFTP is a protocol related to secure shell (SSH) that is also designed to provide encrypted file transfer.

FTP is a plaintext protocol that operates over port 20 and 21. It can be identified in Wireshark using the ftp filter.

The image above shows a sample of FTP traffic collected by following a TCP stream in Wireshark. As shown, FTP is a request-response protocol. Each request is a command, potentially followed by a set of arguments. Responses include a response code followed by the data requested by the command.

An FTP packet simply contains the text data that is shown from the earlier session. This makes it very easy to read in a network capture. Since FTP operates as a plaintext protocol by default, this also makes it easy for an eavesdropper with access to an organization’s network traffic to extract sensitive data.

While the packets above show examples of anonymous authentication to an FTP server (which should be disabled for security reasons), FTP traffic could also leak a user’s actual network login credentials. For this reason, it is advisable to use one of the many alternatives to FTP for file transfer (SFTP, SCP, FTPS and so on).

FTP is a protocol that was designed with a focus on simplicity and functionality rather than security. As a result, it can be abused by an attacker in a variety of different ways if they can gain access to it.

FTP is designed to transfer files between a single server and (potentially) multiple different clients. A common use is to create file servers where official copies of files shared across an organization can be stored in a central and easily accessible location.

If an attacker can gain access to an account that is authorized to use an FTP server (and assuming that the server is configured to require authentication), it can create a significant risk for data exfiltration. Since FTP is designed to move files on and off of servers, an attacker could take a copy of any data already stored on an FTP server. Alternatively, the FTP server could be used as a stepping stone for data exfiltration since it is common usage to add/remove files from it, and firewall access control lists (ACLs) may allow FTP traffic to/from it across network boundaries. Monitoring for unusual usage of FTP in network traffic is important to protecting against data exfiltration.

One of the biggest challenges that a cybercriminal faces during a cyberattack is installing and executing their malware on the target machine. The threat of .exe and other executable files has resulted in many organizations focusing on them in anti-phishing training, making it harder to get a user to download and run an application from an email.

However, FTP is designed to allow files to be added to a server within an organization’s network perimeter. If an attacker has access to the internal FTP server and that server allows execution of files in the FTP directory, then the attacker could drop and run the malware on an internal machine themselves. If not, combining the use of FTP with phishing or another exploit may allow them to install and run malware on a target system (since an end user may trust a file that is on the company file server). It is important to lock down access to the FTP server, disallow applications stored there to execute and monitor for attempts to add and execute applications on the FTP server.

As the number of online accounts that people have increases, the more difficult it is to keep them secure. As a result, many people use weak and common passwords. In fact, an estimated 10% of people use one of the 25 most common passwords, and 62% use the same password for personal and work accounts. Simply trying weak and common passwords across multiple accounts gives an attacker a high probability of gaining access to a user’s professional account.

This type of attack, called credential stuffing, requires access to either password hashes or an online service that requires authentication. A well-configured FTP service meets this second criterion, since it will require users to authenticate using their work credentials in order to use the service.

An attacker can take advantage of this to test potential options for a user’s password. If the service is not configured with limits on the number of incorrect logins, they may manage to gain access (allowing them to use the account for the other purposes described above). Regardless, monitoring for large numbers of failed authentications, including across multiple accounts, is necessary to protect against this type of attack.

An FTP bounce attack takes advantage of the PORT command in FTP, which is designed to forward FTP traffic to another server. An attacker can take advantage of this to bypass firewall restrictions, allowing them to access systems that are blocked by firewall ACLs. Any use of the PORT command in FTP traffic should be investigated to determine if it is malicious.

The FTP protocol can be useful for businesses but also can be used by an attacker in a variety of different ways. When possible, it’s a good idea to move to a more secure protocol; however, if this isn’t an option, FTP should require authenticated access and be monitored for unauthorized use.

• Type QUOTE DBUG to start the trace.
• Perform the FTP operation that you want to trace.
• Type QUOTE DBUG again to end the trace.
• Type QUIT to end the FTP session.
• Enter the following command to find the output queue.
• Record the name of the printer device.