Wireshark Display Filters Lab – Overview and Setup
This lab focused on becoming more familiar with using Wireshark display filters to isolate specific types of traffic.
Exercise 1 – Filtering DNS Queries for a Specific Domain
Task: Find the packet record number(s) where a DNS query name contains the string glenhighland.
There are many ways to solve this. One way is to filter the packets in Wireshark for DNS query name using the filter ‘dns.qry.name’ and then looking for the glenhighland string in the filtered packets using the Edit/Find Packet menu. Packets 101 and 102 contains this string.
Exercise 2 – Finding ARP Request Records
Task: Find all ARP request records. How many are there, and what filter did you use?
To complete this task, I used a Wireshark display filter that isolates ARP request packets specifically. First, I reviewed the structure of an ARP packet by looking at one in the packet list which Wireshark identified as a request under the Address Resolution Protocol section.
I then right clicked on the Opcode line and applied this same filter to the packet list.
The arp.opcode==1 gets applied, and 16 packets get displayed (it is shown at the bottom right corner of the wireshark screen).
Exercise 3 – Identifying ICMP Echo Replies with Undersized IP Payloads
Task: Find the record numbers of any ICMP echo reply (type 0) frames that required zero-padding due to being smaller than the minimum acceptable Ethernet II length.
To solve this, I first recalled that the minimum Ethernet II frame size is 64 bytes, and that the Ethernet header (14 bytes) plus trailer (4 bytes) leave at least 46 bytes required for the IP payload. Therefore, any IP datagram smaller than 46 bytes would be too short and must be padded to meet Ethernet’s minimum.
I used the Wireshark Display Filter Expression dialog to build a compound filter that would identify:
ICMP echo replies (type 0)
IP datagrams with a Total Length < 46
To do this:
I opened Analyze > Display Filter Expression
Selected the field ip.len
Chose the less than (<) relation
Entered the value 46
Added icmp.type == 0 to narrow it to echo replies
We identified 3 packets using these combined filters.
Exercise 4 – Isolating and Exporting DNS over UDP Traffic
Task: Find all records where the UDP protocol is carrying DNS traffic. How many are there? Save those packets to a new file named dns.pcapng.
To complete this, I used this display filter in Wireshark:
This filter shows all packets where DNS communication is occurring over UDP (14 packets are displayed).
Once filtered, I saved the displayed packets to a new capture file:
Went to File > Export Specified Packets.
Entered the filename: dns.pcapng.
Selected All packets and Displayed (to export only the filtered results).
This lab focused on exploring the behavior and structure of IP fragmentation. The exercises require close analysis of fragmented IP packets using either Wireshark or tcpdump.
Exercise 1 – Analyzing the First Two IP Fragments
Look at the first two records. They are related fragments and are the only ones associated with this pair of fragments. What do you think happens when they are sent?
After identifying the first two packets as related IP fragments, I needed to confirm whether the full set of fragments was present. I used the following tcpdump command to examine fragmentation details more closely:
Both packets showed more fragments flag set (flags [+]), but neither was marked as the last fragment (with offset and MF flag = 0). This means that the packet reassembly could not be completed, as at least one fragment was missing from the set.
To see how the system reacts to this failed reassembly, I looked for an ICMP error message that might be triggered by this condition. I ran:
Sure enough, shortly after the two fragment packets, I found an ICMP “Time Exceeded – Fragment Reassembly Time Exceeded” message. This type of ICMP error is sent when the receiver cannot finish reassembling a fragmented IP packet within the allowed time window.
The error response appeared in record 14, indicating the network’s handling of incomplete fragmentation and how it alerts the sender when reassembly fails.
Why didn’t records 3 and 4 (a different pair of related fragments) generate the same type of ICMP error message?
To answer this, I examined the fragmentation details of records 3 and 4. Although they represent another pair of related fragments, neither one has a fragment offset of 0. The packet corresponding to the third record has an offset of 1480. This is important because only the first fragment (offset 0) contains the protocol field, which identifies the embedded protocol (like ICMP, TCP, etc.).
Without that first fragment, the receiving system can’t determine what protocol the original datagram was using. As a result, it doesn’t send an ICMP “Fragment Reassembly Time Exceeded” message, since it lacks the context needed to generate one.
Exercise 2 – Identifying Fragment Overlap and Suspicious Packet Behavior
In this exercise, I analyzed packets 5, 6, and 7, which appeared to be related fragments. At first glance, they looked like they might belong to a single fragmented IP packet, but something unusual stood out.
Fragment Overlap Issue Packets 5 and 6 both have a fragment offset of 0, meaning they are both marked as the first fragment. However, they have different total lengths, which would cause them to overlap if processed together. Packet 7 appears to be the final fragment in this set, but it overlaps with packet 6 based on its offset and length.
This kind of fragment overlap can be interpreted differently depending on the operating system, making it a potential tactic for evasion or exploitation. Some systems may discard the entire packet, while others may accept whichever version arrives first or last.
Suspicious IP Options I also noticed that all three packets contained IP options, which are uncommon in typical traffic and can signal malicious activity. Specifically, the packets include type 131 IP options, which are often used to route packets through specific network paths. This could be an attempt to bypass firewalls, intrusion detection systems, or route traffic through an attacker-controlled device.
Exercise 3 – Spotting Crafted Fragment Sets
What makes you believe that the set of fragments in records 8–13 (IP ID 31026) have been crafted? Identify five abnormal traits.
Upon analyzing these packets, it became clear that these fragments were likely intentionally crafted rather than the result of legitimate fragmentation. I identified several suspicious traits that support this conclusion:
The second packet does not have a More Fragment flag which would indicate that this is the last packet of this fragment train when in fact there are more packets that are part of this train following this packet.
The second to last packet does not have the same payload size a nd total length size as the fragments before him. All fragments should be the exact same size outside of the last fragment.
The 4th and 5th fragments are overlapping (they have the same offset of 24).
All the packets have payloads of size 8 and 16 bytes and total length of 28 and 36 bytes. There should be no MTU that small and causing fragmentation to occur.
There is a fragment missing before the last fragment. We go from offset 24 to offset 48 while the payload size is only of 8 bytes. We should have a fragment with an offset 32 that is missing.
Exercise 4 – Filtering for ICMP Echo Request Fragments
In this exercise, I used a tcpdump filter to try and identify all fragments related to ICMP echo requests (type 8). The command provided was:
Why don’t we see all the fragments associated with the echo requests ?
Only fragments with an offset of 0 include the ICMP header (which contains the type field). Subsequent fragments—those with a non-zero offset—contain only payload data, not the protocol header. As a result, the filter doesn’t match those fragments, because the ICMP type field isn’t present in their portion of the packet.
To capture all fragments of a given ICMP echo request, I would need to filter by IP ID (the identifier field) rather than by protocol fields. That’s because all fragments of a packet share the same IP ID, allowing me to track the complete set regardless of whether they include the ICMP header.
This lab focused on examining network traffic at the IPv4 layer, with an emphasis on identifying abnormal or suspicious behavior within the packet capture.
Lab Setup
For this exercise, I used the capture file called ipv4.pcap.
Once downloaded, I opened the file in Wireshark and began my analysis.
Exercise 1 – Analyzing the First IPv4 Packet
a) What version of IP is the first packet?
We can find this either by looking at the Ethernet header or the IP header. Looking at the IP Header, the IP version is located in the higher-order nibble of the 0 byte offset. We can see there that this is an IPv4 packet.
b) What is the IP Time To Live value, in decimal, in this packet?
To answer this, I examined the IPv4 header of the first packet in the ipv4.pcap file. I specifically looked at the Time To Live (TTL) field, which determines how many hops (routers) the packet can pass through before being discarded.
The TTL field is located 8 bytes into the IP header, but Wireshark conveniently displays this value directly in the decoded packet details. In this case, the TTL value was 64, which is a common default for Linux-based systems.
This value can also give clues about the operating system or network behavior based on how far the packet has traveled.
c) What is the source IP address, in hexadecimal, in the first packet?
To find the source IP address in hexadecimal, I examined the IPv4 header in the first packet of the ipv4.pcap capture. The source IP address is located between bytes 12 and 15 from the start of the IP header.
Wireshark makes this easy by displaying both the decimal and hexadecimal representations. For the first packet, the source IP is 192.168.11.65 in decimal, which corresponds to 0xc0 0xa8 0x0b 0x41 in hexadecimal.
d) What is the destination IP address, in hexadecimal, in the first packet?
To find the destination IP address in hexadecimal, I examined the IPv4 header of the first packet in the ipv4.pcap file. According to the IP header structure, the destination IP is stored between bytes 16 and 19 from the start of the IP header.
Wireshark clearly shows this value in both hexadecimal and decimal. In this case, the destination IP is 192.168.1.1, which corresponds to the hexadecimal representation 0xc0 0xa8 0x01 0x01.
Exercise 2 – Identifying Abnormalities in the IPv4 Header
In this exercise, I examined the second packet in the ipv4.pcap capture and identified two key problems with its IP header.
Problem 1: Invalid IP Version The first issue is that the IP header lists version 8, which is not a valid or supported IP version. Only versions 4 and 6 are in use today. Because of this, Wireshark marks the packet in red and does not attempt to decode it further.
Problem 2: Invalid Header Checksum After inspecting the raw packet bytes, I found another issue in bytes 10 and 11, which represent the IP header checksum. The value was 0x0000, which is invalid and indicates the packet may have been corrupted or crafted improperly.
Impact Both of these abnormalities would cause the packet to be dropped immediately by the first router or system it attempts to pass through. This exercise helped me understand how malformed packets are detected and discarded at the network layer.
Exercise 3 – Hex Analysis Using tcpdump
In this part of the lab, I used the tcpdump command-line tool to inspect raw packet data and answer questions related to the third packet in the ipv4.pcap capture.
To extract the first few packets in hexadecimal format, I ran:
a) What version of IP is this packet?What is the header length if the packet ?
By looking at the raw hexadecimal output of the third packet, I found it starts with the byte 0x45. This first byte breaks down into two nibbles:
4 → IP version
5 → header length
So, the version number of this packet is IPv4, as indicated by the high-order nibble of the first byte.
The header length field is in units of double word so it has to be multiplied by 4 to be converted to a length of 20 bytes.
b) What is the embedded protocol in this packet, according to the IP header?
To determine the embedded protocol, I examined byte offset 9 in the IP header of the third packet. This byte indicates which protocol is encapsulated within the IPv4 packet.
Using the tcpdump output, I located the value at this offset. For this packet, the value was 0x01, which corresponds to ICMP (Internet Control Message Protocol).
Exercise 4 – Calculating ICMP Header and Data Length
In this task, I analyzed the fourth packet in the ipv4.pcap file to determine how many bytes were used by the ICMP header and data, following the IPv4 header.
To do this, I used two values from the IP header:
Total Length: 68 bytes (it is found in the 3rd byte offset of the IP Header // it has a hexadecimal value of 0x44)
Header Length: 20 bytes (which is shown as a value of 5 in the header, multiplied by 4)
By subtracting the IP header length from the total IP datagram size: 68 - 20 = 48 bytes
So, the ICMP header and data together occupy 48 bytes in this packet.
This set of exercises focuses on analyzing network activity at the Link Layer.
Lab Setup
For this lab, I used Wireshark to analyze a file called link.pcap.
Exercise 1 – Analyzing the First Record
1. In the first record, what is 192.168.11.11 trying to find?
To answer this, I examined the first packet in the link.pcap file.
We can see that this an ARP request going from mac address aa:00:04:00:0a:04 (which is the mac address associated with the IP address 192.168.11.11) to the mac address ff:ff:ff:ff:ff:ff (the broadcast address). It is looking for the mac address associated with the IP address 192.168.11.1
2. What is the Ethernet destination address in the ARP request? Why is the request sent to this address?
While examining the ARP request in the packet capture, I checked the Ethernet II header to find the destination MAC address. In an ARP request, this address is typically set to the broadcast addressff:ff:ff:ff:ff:ff.
This is done because the sender doesn’t yet know the MAC address of the target IP and needs to ask all devices on the local network if they are the owner of that IP address. Broadcasting ensures that the request reaches every host on the subnet.
3. What is the hexadecimal Ethernet II Type for an ARP request?
It is 0x0806
4. What is the Target MAC address of the ARP request? Why do you suppose this address is used?
When analyzing the ARP request in Wireshark, I checked the Target MAC address field in the ARP header. This field was set to 00:00:00:00:00:00.
This makes sense because the sender is trying to discover the MAC address of the target IP—they don’t know it yet. The all-zero MAC address is used as a placeholder to indicate that this information is currently unknown and is the whole reason the ARP request is being broadcast.
5. Examine record 2. What type of ARP is this?
In record 2 of the capture, I analyzed the ARP packet details in Wireshark. Based on the fields, I could tell this was an ARP reply. Unlike an ARP request, which is broadcast to ask for a MAC address, the ARP reply is a direct response from the device that owns the IP address, providing its MAC address to the requester.
This completes the ARP resolution process, allowing the devices to communicate at the Ethernet level.
6. What is the Sender MAC address of 192.168.11.1?
To answer this, I looked at the ARP reply packet in the capture where 192.168.11.1 is listed as the sender. In the ARP header, the Sender MAC address field contains the hardware address associated with that IP (00:0c:29:03:23:19). This is the MAC address the device is announcing to the network, and it’s what other hosts will use to communicate at the Ethernet layer.
7. What is the MAC address of the intended recipient of this ARP message?
To determine the intended recipient’s MAC address, I examined the Target MAC address field in the ARP reply. This field shows the hardware address (aa:00:04:00:0a:04) of the device that originally sent the ARP request.
Exercise 2 – Interpreting Linked ARP Activity
Examine records 3, 4, and 5, which are all associated with each other. What do you think is happening?
After examining records 3, 4, and 5, it became clear that something suspicious was occurring with the ARP replies.
In record 3, host 192.168.11.4 sends an ARP request asking for the MAC address of 192.168.11.111. In record 4, a legitimate response comes from 192.168.11.111, returning its correct MAC address. However, in record 5, a second ARP reply is sent—also claiming to be from 192.168.11.111, but with a different MAC address.
This is a red flag. The presence of two conflicting ARP replies suggests that someone is attempting to poison the ARP cache of the original requester (192.168.11.4). The attacker is trying to trick it into associating the IP address 192.168.11.111 with the attacker’s MAC address, effectively redirecting traffic meant for the legitimate host.
This is a classic example of ARP spoofing, a technique used in man-in-the-middle (MITM) attacks to intercept or manipulate traffic. The warning in Wireshark also highlights this as a duplicate IP address issue, which further confirms the attempt to mislead the network.
In this exercise, I reviewed packets 6 through 55, which represent a small sample of many similar records captured during an attack simulation using the macof tool. The focus was on analyzing the Ethernet headers at the link layer.
1. What is the source MAC address of records 6, 7, and 8? I checked each record and found that all three packets had different source MAC addresses:
Record 6: 67:aa:17:2f:ba:02
Record 7: ac:1d:9d:2e:7c:71
Record 8: c6:58:a2:5e:02:49
2. What is the source IP address in records 6–55? All of these packets used the same source IP address: 10.10.10.5.
3. What is wrong with these MAC address-to-IP address associations? What does this indicate? This behavior is highly abnormal. Multiple packets are using different MAC addresses while claiming the same IP address. This inconsistency suggests that the traffic is spoofed, which is a hallmark of a MAC flooding attack. Tools like macof generate thousands of fake MAC/IP combinations to overflow the switch’s MAC address table, potentially forcing it into fail-open mode, where it floods traffic to all ports—opening the door to packet sniffing by an attacker.
The goal of this lab is to familiarize myself with the basic functionalities of Wireshark.
Exercise 1 – Wireshark Profile Setup
To kick off the lab, I started by setting up a custom Wireshark configuration profile. These profiles are really helpful because they let you tailor things like display columns, settings, and layout to match your workflow. You can switch between different profiles depending on what you’re analyzing, and it’s easy to import/export them to share with others.
For this exercise, I used a pre-made profile provided for the class. I opened Wireshark on my system and imported the SEC503.Wireshark.profile.zip file. Once that was in place, I loaded the wireshark.pcap capture file, which set me up to move on to the next part of the lab (Exercise 2).
Exercise 2 – Identifying TCP Protocols in the PCAP
In this part of the lab, I analyzed the provided wireshark.pcap file to identify the different TCP-based protocols present in the capture.
By going to the Statistics menu in Wireshark and selecting Protocol Hierarchy, I was able to quickly identify the three TCP protocols used in the capture file. This feature provides a clear breakdown of all protocols seen in the traffic, making it easy to spot which ones are running over TCP:
-SSH
-MySQL
-Internet Relay Chat
How many different IP addresses were involved in conversations in this pcap?
To answer this, I opened the Conversations window under the Statistics menu in Wireshark. This tool displays all IP-level conversations and allowed me to easily identify how many unique IP addresses were communicating in the capture. It’s a quick way to get an overview of the network activity and see which hosts were involved.
We can see that 4 different IP addresses were involved in 3 conversations in this file.
What is the largest number of Bytes exchanged in any IPv4 conversation?
To determine the largest number of bytes exchanged in any IPv4 conversation, I used the IPv4 Conversations tab under Statistics > Conversations in Wireshark. This view lists the total byte count for each conversation.
From the output, I found that the highest byte exchange between any two hosts was 31k. This gave me a quick insight into which conversation involved the most data transfer within the capture.
Exercise 3 – Counting TCP Conversations
How many different TCP conversations are in this pcap?
For this exercise, I used the Statistics > Conversations feature in Wireshark and navigated to the TCP tab. This tab lists all the unique TCP sessions found in the capture file. Each entry represents a separate conversation between two IP addresses over TCP.
We can see 4 different TCP conversations in this file.
What is the duration of the conversation that lasted the longest?
To answer this, I stayed in the TCP tab under Statistics > Conversations in Wireshark. This view includes a Duration column, which shows how long each TCP conversation lasted. By scanning this column, I identified the conversation with the longest duration (776.1629 seconds)
Exercise 4 – Inspecting Ethernet Type
Before starting this task, I made sure that all three Wireshark panes were visible: the packet list, packet details, and packet bytes. If they weren’t showing, I adjusted the window size by dragging from the bottom-right corner until they appeared.
Navigate to the first packet in the pcap. What is the hexadecimal value of the Ethernet type?
I selected the first packet in the capture and expanded the Ethernet II section in the middle pane. From there, I located the Type field, which shows the Ethernet type in hexadecimal format (0x0800). This value indicates the protocol being used at the next layer (IPv4 here).
What is the IP Time To Live Value?
We can find it by expanding the IPv4 section in the middle pane and find that the value is equal to 64.
What transport layer follows the IP layer?
We can find our answer right under the TTL line under Protocol. Hre we can see that the transport layer is TCP (which corresponds to an Hexadecimal value is 0x06)
What is the last hexadecimal byte value of the TCP header ?
By clicking on the TCP header in the middle pane, the entire TCP header gets highlighted in the lower pane and we can see that the last hexadecimal byte value is 0xef
Exercise 5 – Inspecting MySQL Traffic
As identified earlier using Protocol Hierarchy Statistics, the pcap file contains MySQL traffic. According to the instructions, there is a single MySQL session that begins at packet 372.
Locate the MySQL session that begins in packet 372. Follow the MySQL TCP conversation. What is the version of the MySQL server package for Ubuntu?
To complete this task, I navigated to packet 372 by going to the Go menu and selecting the Go To Packet option:
I then right-clicked on it to select Follow > TCP Stream. This allowed me to view the entire MySQL session in context. By examining the initial handshake and server response, I was able to extract the MySQL version number used in the Ubuntu server package (5.0.51a-3ubuntu5.8). This kind of inspection is useful for identifying software versions and potential vulnerabilities in network traffic.
What is the name of the SQL Table that the user performs an Insert Into command on?
At the bottom of the TCP stream, we can see that the command is performed on a table called “auth_users”.
Exercise 6 – Finding a Specific String in Packet Data
What is the last packet that contains the string “beer”?
To complete this exercise, I used Wireshark’s Find Packet feature by pressing Ctrl + F and switching the search type to String within Packet Bytes. I then searched for the keyword “beer”.
Wireshark highlighted each packet containing this string. I scrolled through the results to locate the last packet in the capture that contained “beer” and recorded its packet number (470). This was a fun way to practice content-based searches within packet data.
