Mastering Wireshark and TShark: The Ultimate Guide

Welcome to BBX! This blog aims to show useful techniques for analyzing network traffic using Wireshark and its command-line version, TShark. Wireshark is a widely used tool for dissecting network traffic, allowing us to examine communication between hosts. It serves various purposes, from troubleshooting connections to detecting security threats.

Before diving into packet analysis, remember a couple of important things:

1. Use the Latest Wireshark Version: This is crucial, especially when dealing with traffic from untrusted sources or the raw internet. Keeping your Wireshark updated is essential for a secure incident response.

2. Despite Occasional Bugs, Wireshark is Reliable: Although Wireshark may have occasional bugs, it remains one of the most popular network analyzers. The community actively addresses issues, ensuring its continued usefulness. For more details, visit: [Wireshark Security Wiki](https://wiki.wireshark.org/Security).

In summary, always keep your tools up-to-date. Consider running Wireshark in a virtual environment when analyzing potentially risky network traffic.

Display Formats and Settings

In this section, I’ll cover some of the common display formats and settings encountered with Wireshark.

Time Display Format

In investigations, time is crucial. Wireshark allows us to handle timestamps in different ways. To adjust how time is displayed:

View -> Time Display Format.

Timestamp Format Preference:

• I prefer using the UTC Date and Time of Day format (1970–01–01 01:02:03.123456).

Important Note about Timestamps:

• Timestamps in packet captures are recorded at the moment of capture, likely based on the system time of the capturing device. This device might be separate from your analysis machine. It’s crucial to ensure proper time synchronization and conduct routine audits throughout your environment.

Useful Resources for Time Management:

• CISA offers guidance on managing time settings in an environment.
• NIST provides a list of Internet Time Servers that can be used for time synchronization via NTP (Network Time Protocol).Name Resolutions

There are three areas where automatic name resolutions can be performed by Wireshark. These settings are accessed from the main toolbar:

View -> Name Resolution

In the most recent install , the only setting enabled by default was Resolve Physical Addresses.

These settings in Wireshark can be useful for an analyst depending on the situation. However, they can also potentially hinder analysis or compromise operational security (OPSEC). Let’s go over what each setting does:

• Resolve Physical Addresses (MAC OUI Resolution):Wireshark converts the first three parts of a MAC address (called OUI or Organizationally Unique Identifier) into the name of the manufacturer.
• Resolve Network Addresses (Reverse DNS Resolution):Wireshark performs reverse DNS lookups on source and destination IP addresses.
• Resolve Transport Addresses (TCP/UDP Port Association):Wireshark links TCP/UDP ports with their corresponding application protocols (e.g., TCP/80 for HTTP, UDP/53 for DNS)

This breakdown makes it clearer to understand the purpose and potential impact of each automatic resolution setting in Wireshark.

Resolve Physical Addresses:

When you choose the ‘Resolve Physical Addresses’ option in Wireshark, it translates the first three parts of a MAC address (known as OUI) into the name of the manufacturer.

For example, in the Packet Details section below, the sequences 00:50:56 and 00:0c:29 were identified as belonging to VMware. This is because I used a virtual host to create packets for testing and captured them from a virtual network adapter.

Resolve Network Addresses:

When you choose ‘Resolve Network Addresses’ in Wireshark, it conducts reverse DNS lookups on all Source and Destination IP addresses in the captured data. While this can be helpful, it’s important to be cautious about potential security risks. This setting might inadvertently reveal sensitive information, especially if your packet capture involves publicly accessible IP addresses.

For demonstration purposes, I activated this setting in a virtual machine with the guest system set to NAT mode. I then captured traffic going in and out of the guest OS while opening a packet capture file. The outcome: I observed reverse DNS lookups being initiated by Wireshark (within the guest OS) for the IP address 137.184.39.243, going out to a public DNS resolver (not shown in the capture).

Resolve Transport Addresses:

When you enable ‘Resolve Transport Addresses’ in Wireshark, it assigns common network protocols to each TCP and UDP port.

For instance, NTP (Network Time Protocol) is typically linked to both TCP/123 and UDP/123.

In the screen capture, Wireshark labeled the Destination Port as ‘ntp’. However, upon examining the conversation using the ‘Follow TCP Stream’ feature, it becomes clear that this is actually HTTP traffic, not NTP.

Resolve Physical Addresses:

In my view, this setting is the least potentially harmful for analysis. It can be useful for investigations involving MAC addresses. The Wireshark community also maintains a website for bulk OUI lookups, which I’ve found handy on occasion.

Resolving Transport Addresses:

This can sometimes be misleading, especially for those new to network analysis. It’s good to treat it as informational. Keep in mind that anyone with full control of a system can use any TCP/UDP port.

Resolve Network Addresses:

Analysts should be cautious with this option. While there might be situations where it’s helpful, I personally don’t think the potential risk is worth the benefit. I don’t recommend using it.Display Windows

Wireshark Packet Windows: Wireshark uses 3 windows to show packets

• Packet List:This is the topmost window where you get a summarized view of each packet. By default, it shows the packet number, timestamp, source/destination addresses, protocol, and a brief description. You can rearrange or sort the columns as needed.
• Packet Details: This window, usually on the bottom-left (or middle in older versions), provides a detailed breakdown of the selected packet. It displays various fields organized hierarchically based on the packet’s TCP/IP layers.
• Packet Bytes: Found on the bottom-right (or lowest in older versions), this window shows the bytes of the selected packet. It presents them in a format with both hex values and corresponding ASCII characters, along with an offset column in hex.

The screen capture below offers an example showcasing each of these windows in action while viewing a packet capture file.

Note: In the screen capture above, the display filter toolbar has the ‘http’ filter applied. I’ll discuss more about display filters in a bit.

Capture Options:

Processing large PCAP files with Wireshark, especially those over 500MB, can be a challenging experience. While Wireshark is a powerful network protocol analyzer, it can struggle with hefty packet captures. This section will provide techniques to ease these challenges.

When using Wireshark to capture network traffic, we can apply different capture options for both input and output. This helps in controlling the size of the collected data, making it easier to analyze the traffic efficiently. To access these options, go to Capture -> Options… in the main toolbar.

Input: Limiting the Capture to a Target Host

To limit the capture to a target host, we can use the following filter syntax:

host <ip_address_of_target_host>

In the example below, I’m filtering on the IP address 192.168.232.130. This tells Wireshark to capture traffic where this IP is either the Source or Destination address.

You can also view some prebuilt capture filters by selecting Capture -> Capture Filters… from the main toolbar. The Filter Expression column contains example syntax for applying each respective filter.

Limiting Capture Output:

If you’re running a capture for a long or undetermined period, it’s a good idea to have Wireshark create new files based on specific conditions. In the Output section/tab, you have several options. You can instruct Wireshark to save a new file after a certain number of packets or bytes have been collected, or at set time intervals. For instance, in the example below, Wireshark is set to generate a new PCAP file every time the captured data reaches 100MB.

Display Filters vs Capture Filters:

- Capture Filters: These are only applied when actively capturing live network traffic.

- Display Filters: They can be used during live capture or when analyzing a saved PCAP file.

- During live capture, Wireshark keeps capturing traffic in the background, regardless of the display filter applied. The filter only limits the packets shown.

- The Display Filter Toolbar is above the Packet List window. It offers a dropdown of filter options as you type. This helps prevent applying an incorrect filter.

- Note: Wireshark highlights the filter toolbar in red if the syntax is incomplete or invalid.

- Many Wireshark display filters use a hierarchical syntax in dot-notation. For example, if you want to apply an HTTP-based filter but want to be specific, you can type “http” followed by “.”, and Wireshark will list supported HTTP filters.

If you’re curious to know all built-in supported display filters, simply navigate to:

View -> Internals -> Supported Protocols

and view the filter column for the desired filter syntax. Shown below is just a portion of supported HTTP display filters.

Wireshark currently supports over 218k display filters from nearly 3k protocols!

Follow the Streams:

Analyzing individual packets is powerful, but it can be challenging to gain context when dealing with a large amount of network traffic. While you can select and view packet details and bytes, this method isn’t very efficient for large-scale analysis.

Thankfully, Wireshark offers a useful feature called “Follow Stream”. It allows us to view an entire flow of network traffic. This feature works with various protocols, but we’ll focus on TCP streams for now. To use it, right-click on a TCP packet in the Packet List display and select

Follow -> TCP Stream

Upon making this selection, Wireshark does two things:

1. Displays the TCP stream in a new window.

• Client data (host that initiated the connection) is color-coded in red.
• Server data (host that responded to the client request) is color-coded in blue.
• Automatically applies a tcp.stream display filter accordingly.
• Wireshark catalogs all streams on initial processing, with the first stream identified as Stream 0. As shown in the below screenshot, the display filter was tcp.stream eq 3 or in other words the 4th TCP stream in the capture file.

Extracting Objects

There’s nothing more satisfying to an incident responder than being able to extract attacker artifacts from network traffic. The specific email used as a phish — containing URLs and/or attachments, malicious file downloads, exfiltrated data, etc., etc.

Fortunately, Wireshark has a built-in capability that allows us to extract objects from network traffic. Unfortunately, Wireshark limits this capability to only a handful of protocols. We can see the supported protocols by navigating to

File -> Export Objects.

If you’re in a scenario where you have captured traffic containing threat activity, there’s an opportunity to extract file artifacts for a deeper dive into the content that was transferred over the network. To demonstrate, I opened a test PCAP file and navigated to

File -> Export Objects -> HTTP…

We can see below where several “objects” have been identified by Wireshark — each one of them can now be extracted (saved to disk) for additional analysis.

Operationalizing from the Command Line:

Now that we’ve covered some basic settings and features of Wireshark, let’s jump into practical use cases for operationalizing your analysis. We’re going to shift to the command line using TShark, where we can perform useful tasks rather than navigating a GUI for packets.

While there’s nothing wrong with analyzing within Wireshark, I often find it beneficial to have both Wireshark and TShark running simultaneously. The challenge with Wireshark arises when we need to extract network data in bulk, for tasks like data aggregation, generating network telemetry for a SIEM, or other automated processes.

With TShark, we can leverage the power of the command line while still having access to the robust protocol analyzers from Wireshark.

To start, TShark requires some command line options. We’ll go over a few useful ones here, but I encourage you to read the man page and explore additional options as you become more comfortable.

For reading a PCAP file, we use the ‘-r’ option. I always pair this with ‘-n’, which instructs TShark not to perform any name resolution.

tshark -nr infile.pcap

To apply a display filter, we use the ‘-Y’ option followed by the display filter.

tshark -nr infile.pcap -Y ‘dns’

To write out a PCAP file, we use the ‘-w’ option. If we have a display filter applied, this will instruct TShark to save a new PCAP file with only the packets matching the display filter.

tshark -nr infile.pcap -Y ‘dns’ -w newfile.pcap

And finally, to capture traffic with TShark, we use the ‘-i’ option to specify the interface to capture from.

tshark -ni eth0

Without specifying any additional parameters, TShark will just print to stdout (standard output); therefore, we specify the ‘-w’ to instruct TShark to write a PCAP file. Additionally, if we want to apply a capture filter, the ‘-f’ option is used.

tshark -ni eth0 -f "host 192.168.20.10" -w test.pcap

Now let’s see what this looks like in real life…

Applying the ‘http’ display filter to a pcap file, we get the following output.

Note the timestamps are in relative seconds from the first observed packet.

We can fix this with the ‘-t’ option and ‘ud’ parameter which tells TShark to output the timestamp in UTC absolute time, in the format: YYYY-MM-DD hh:mm:ss.SSS

Much better!

Now let’s get dangerous and extract data fields from a PCAP file. TShark supports field extractions using the ‘-T fields’ option along with the ‘-e’ option to specify which fields are to be extracted.

Here’s an example command that targets HTTP packets and prints out the timestamp (in epoch time), source IP address, and destination IP address.

tshark -nr infile.pcap -Y 'http' -T fields -e frame.time_epoch -e ip.src -e ip.dst

By default, TShark will print to stdout with extracted field values as tab delimited.

We can customize the output a bit more by adding the ‘-E header’ and ‘-E separator’ options as shown in the following command.

tshark -nr infile.pcap -Y 'http' -T fields -E header=y -E separator='|' -e    frame.time_epoch -e ip.src -e ip.dst

• ‘-E header=y’ instructs TShark to print the field name on the first line of output.
• ‘-E separator=’|’ instructs TShark to use a custom separator value, in this case the pipe character (|).

This is great, but you may be asking yourself, “how do I know the specific field name to target for extraction?” Well, this is where having a running instance of Wireshark comes in extremely handy!

We can utilize the display filter trick in Wireshark and find the specific field(s) we’re after. For example, if we want to extract all HTTP User-Agent values with TShark, open Wireshark and go to the Display Filter Toolbar and start typing “http.” (don’t forget the ‘.’) — then scroll down until you find the User-Agent field name, http.user_agent.

I find it even more convenient to extract field names in the Packet Details section, then have Wireshark just tell me the specific filter syntax. This can be achieved by right-clicking on a field of interest and selecting Apply as Filter -> Selected.

Viola… Wireshark will apply the filter in the Display Filter Toolbar for you!

Although the specific value is also applied to the filter in Wireshark, we can ignore that as we are only interested in the field name, http.user_agent. Now, we can take that to TShark and extract all unique User-Agent strings observed over HTTP.

tshark -nr infile.pcap -Y 'http' -T fields -E header=y -E separator='|' -e ip.src -e http.user_agent

There is, however, a slight “gotcha” in the above command. As shown in the output below, each instance where the Source IP is 137.184.39.243, the User-Agent field is empty.

This is because we instructed TShark to extract fields based on the -Y ‘http’ filter, which returns all HTTP traffic — both client requests and server responses. In the HTTP protocol, User-Agent strings are sent by the client to the server, and since TShark applies filters on a per-packet basis, packets associated with server responses will not contain User-Agent values.

To avoid this, we need to be a bit more tactical with our filter and use http.request rather than just http.

tshark -nr infile.pcap -Y 'http.request' -T fields -E header=y -E separator='|' -e ip.src -e http.user_agent

With the above command applied, we now see that the only Source IP associated with User-Agent values is 192.168.88.55.

Because we’re using the command line, we can send the results to do more things with the data we get.

For instance, I’m using a tool called TShark on Ubuntu, which lets me use other helpful tools available there.

Let’s say we want to find all the different pairs of Source IP addresses and User-Agent values and see how often they show up in a data collection.

We can tweak the previous command a bit by sending the results from TShark to two built-in tools on Ubuntu, ‘sort’ and ‘uniq’.

tshark -nr infile.pcap -Y 'http.request' -T fields -E separator='|' -e ip.src -e http.user_agent | sort | uniq -c | sort -nr

The command results in the following output.

In the captured data, there are two different User-Agent values associated with the IP address 192.168.88.55. The first User-Agent value appears four times, while the second one appears once.

The command sort | uniq -c | sort -nr is a series of commands used to analyze and count unique values in a list:

sort: Arranges the lines in the list in a specific order.

uniq -c: Counts the occurrences of each unique line in the sorted list.

sort -nr: Sorts the counted values in descending order (from highest to lowest).

Conclusion :

This guide gives useful tips for beginners using Wireshark or TShark. It’s normal to feel overwhelmed when analyzing network data. Remember, tools help, but they’re not flawless.

It’s important to understand what you’re analyzing. Begin with common protocols like DNS or HTTP. Learning about them will help you tell apart normal and potentially harmful network activity.