Wireshark: Traffic Analysis Walkthrough — TryHackMe Lab

Task 1: Lab Overview

In this lab, packet-level data will be analyzed to understand the bigger picture of network traffic, including identifying anomalies and potential malicious activity. For a security analyst, it is essential to examine and correlate fragmented information within packets using both technical knowledge and analytical tools. This lab focuses on leveraging Wireshark to investigate packet-level details and detect unusual or suspicious behavior within a given scenario.

Task 2: Nmap Scans

Nmap is an industry-standard tool for mapping networks, identifying live hosts, and discovering the services. As it is one of the most used network scanner tools, a security analyst should identify the network patterns created with it. This section will cover identifying the most common Nmap scan types.

• TCP connect scans
• SYN scans
• UDP scans

It is essential to know how Nmap scans work to spot scan activity on the network. However, it is impossible to understand the scan details without using the correct filters. Below are the base filters to probe Nmap scan behaviour on the network.

TCP flags in a nutshell:

TCP Connect Scans

A TCP Connect Scan relies on completing the full three-way handshake to determine whether a port is open.

Overview

• Uses the full TCP handshake process
• Executed with: nmap -sT
• Commonly used by non-privileged users (no root access required)
• Typically shows a window size larger than 1024 bytes, as the connection expects data exchange

How It Works

Open Port:

• SYN →
• ← SYN, ACK
• ACK → → Connection is successfully established

Closed Port:

• SYN →
• ← RST, ACK → Connection is refused

In some cases, after a successful connection, the client may terminate it:

• RST, ACK →

These patterns reflect how TCP Connect scans fully establish a connection before determining the port state, making them easier to detect compared to stealthier scan types.

The images below illustrate the three-way handshake process for both open and closed TCP ports.

Closed TCP port (Connect):

In large capture files, these patterns are not always easy to identify at first glance. Therefore, analysts should begin with a broader filter to highlight potential anomalies, then narrow down the analysis to specific traffic.

The following Wireshark filter helps identify TCP Connect scan patterns by focusing on initial SYN packets with characteristics typical of this scan type:

tcp.flags.syn == 1 and tcp.flags.ack == 0 and tcp.window_size > 1024

SYN Scans

A TCP SYN Scan (also known as a half-open scan) does not complete the full TCP handshake, making it faster and stealthier than a TCP Connect scan.

Overview

• Does not complete the three-way handshake
• Executed with: nmap -sS
• Requires privileged (root) access
• Typically uses a window size ≤ 1024 bytes, as no full connection is established

How It Works

Open Port:

• SYN →
• ← SYN, ACK
• RST → → Connection is not completed (half-open), but the port is identified as open

Closed Port:

• SYN →
• ← RST, ACK → Port is closed

This technique avoids completing the handshake, which makes it less likely to be logged compared to a full TCP Connect scan.

Open TCP port (SYN):

Closed TCP port (SYN):

The following Wireshark filter can be used to identify TCP SYN scan patterns in a capture file by focusing on initial SYN packets with smaller window sizes typical of half-open scans:

tcp.flags.syn == 1 and tcp.flags.ack == 0 and tcp.window_size <= 1024

UDP Scans

A UDP Scan does not rely on a handshake process, making it different from TCP-based scans. Detection is based on the presence or absence of responses.

Overview

• No handshake required
• Executed with: nmap -sU
• No response typically indicates an open or filtered port
• ICMP error messages indicate closed ports

How It Works

Open Port:

• UDP packet →
• (No response) → Port is considered open or filtered

Closed Port:

• UDP packet →
• ← ICMP Type 3, Code 3 (Destination unreachable, port unreachable) → Port is closed

This behavior makes UDP scans slower and harder to interpret, as the absence of a response does not always guarantee that a port is open.

Example

Closed UDP port (e.g., port 69) responds with an ICMP unreachable message, while an open port (e.g., port 68) typically provides no response.

The image above shows that a closed UDP port returns an ICMP error packet. At first glance, this message does not clearly indicate which request it is related to. To determine this, analysts need to examine the encapsulated data within the ICMP packet.

ICMP error messages include a portion of the original request packet inside their payload. By expanding the ICMP section in the packet details pane in Wireshark, you can view this embedded data and identify the original source and destination of the request. This allows you to correlate the error message with the specific UDP probe that triggered it.

The following Wireshark filter can be used to identify UDP scan patterns by detecting ICMP error responses generated by closed ports:

icmp.type == 3 and icmp.code == 3

Detecting suspicious activity in captured traffic is an effective way to practice focusing on important details.

In the VM machine, navigate to the following path to access the PCAP file: ~/Desktop/exercise-pcaps/nmap/Exercise.pcapng

Open the file in Wireshark and use the techniques covered earlier to analyze the traffic and answer the questions provided.

Q1: What is the total number of “TCP Connect” scans?

Answer: 1000

Q2: Which scan type is used to scan the TCP port 80?

Answer: TCP Connect

Q3: How many “UDP close port” messages are there?

Answer: 1083

Q4: Which UDP port in the 55–70 port range is open?

Answer: 68

To answer this question, we can filter all UDP destination ports in the range 55–70 and check which ones do not return an ICMP “destination unreachable” message: udp.dstport in {55 .. 70}

After applying this filter, we see that only three ports appear. Two of them generate destination-unreachable responses, leaving the third port as the one that is open or reachable. That third port is the answer.

Task 3: ARP Poisoning & Man In The Middle Attack

Definition: ARP (Address Resolution Protocol) maps IP addresses to MAC addresses in a local network. ARP Poisoning, or ARP Spoofing, is an MITM attack where forged ARP packets manipulate the IP-to-MAC table to intercept traffic.

ARP Basics: Works on a local network, enables IP-MAC communication, not secure, not routable, no authentication, common packet types: request, response, announcement, gratuitous.

Normal ARP Flow: Device sends broadcast request “Who has this IP?” → Host replies with its MAC.

Attack Behavior: Attacker sends fake ARP responses, maps their MAC to another IP (e.g., gateway), redirects traffic for sniffing/manipulation.

Wireshark Analysis:

• Basic filter: arp
• ARP Requests (Opcode 1): arp.opcode == 1
• ARP Responses (Opcode 2): arp.opcode == 2
• Suspicious Indicators:
• ARP scanning: arp.opcode == 1
• ARP poisoning: arp.duplicate-address-detected or arp.duplicate-address-frame
• ARP flooding: arp.dst.hw_mac == 00:00:00:00:00:00
• Targeted activity: (arp.opcode == 1) && (arp.src.hw_mac == target-mac-address)

Detection Tip: Understand normal ARP flow, spot abnormal request/response patterns, and use Wireshark filters effectively.

ARP Request:

ARP Reply:

Suspicious ARP Behavior: A conflict occurs when two different ARP responses exist for the same IP address. Wireshark’s Expert Info tab flags this, but it highlights only the second occurrence. The challenge for the analyst is to determine which packet is malicious and which is legitimate. This is a common indicator of IP spoofing, as shown in the example below.

Detecting ARP Anomalies: Knowing the network architecture and inspecting traffic within a specific timeframe helps detect suspicious behavior. Analysts should take notes before proceeding to stay organized and correlate findings across multiple captures.

Example Conflict: The MAC ending with b4 crafted an ARP request for 192.168.1.25 and then claimed to have the gateway IP 192.168.1.1.

Next Steps: Continue inspecting traffic across the multiple capture files provided to spot other anomalies.

ARP Anomaly Detection: A flood of ARP requests cannot be ignored. This could indicate malicious activity, scanning, or network issues. The MAC ending with b4 crafted multiple ARP requests for 192.168.1.25. The focus now is on tracing the source and extending the notes.

Summary: The MAC ends with b4 owns 192.168.1.25, sent suspicious ARP requests across multiple IPs, and also claimed the possible gateway IP. Next, inspect other protocols to see how this anomaly reflects in the network during the same timeframe.

HTTP Traffic Analysis: HTTP traffic appears normal at the IP level, showing no immediate link to the ARP anomalies. To investigate further, add MAC address columns in the packet list pane. This helps reveal which devices are actually communicating behind the IP addresses, providing better correlation with previous ARP findings.

HTTP Correlation & MITM Detection: A new anomaly is identified; the MAC ending with b4 appears as the destination for all HTTP packets. This confirms an MITM attack, where the attacker intercepts and forwards traffic. All traffic related to 192.168.1.12 is redirected to the malicious host.

Summary: The host with the MAC ending b4 is the attacker. It performed ARP poisoning, redirected victim traffic, and positioned itself as a MITM between the victim and the gateway.

Analyst Insight: Detecting such activity in large capture files is challenging. Real-world investigations require strong analytical thinking, protocol knowledge, and effective use of tools to filter and correlate anomalies.

Note: Multiple analysis approaches may lead to the same conclusion; the method depends on the analyst’s experience and available data. Working with segmented (chunked) capture files helps build focus and detection skills.

Next Step: Proceed with analyzing the file ~/Desktop/exercise-pcaps/arp/Exercise to answer the related questions.

Q1: What is the number of ARP requests crafted by the attacker?

Answer: 284

From the task, we identify two key points: the attacker’s MAC address is 00:0c:29:e2:18:b4, and ARP requests use the opcode 1. By combining these, we can filter all ARP requests sent by the attacker.

Wireshark Filter: arp.opcode == 1 && eth.src == 00:0c:29:e2:18:b4

Q2: What is the number of HTTP packets received by the attacker?

Answer: 90

The question asks for the number of HTTP packets received by the attacker, so we focus on destination traffic.

The attacker’s MAC address is 00:0c:29:e2:18:b4, and since we are interested in packets received, we use eth.dst (destination) instead of eth.src.

Wireshark Filter: http && eth.dst == 00:0c:29:e2:18:b4

Result: This filter shows all HTTP packets where the attacker is the destination, allowing us to count how many packets were received.

Q3: What is the number of sniffed username&password entries?

Answer: 6

This step requires deeper inspection. Using the same filter from the previous task: http && eth.dst == 00:0c:29:e2:18:b4, sort the packets by destination to focus on traffic received by the attacker.

Next, look for traffic related to the spoofed IP 192.168.1.12This represents the victim’s communication being intercepted. By inspecting these HTTP packets, you can identify the website/domain that the attacker is interacting with on behalf of the victim.

Using the previously identified traffic, we craft a filter to focus on HTTP POST requests sent to the target website.

1. Initial Filter: http.host == testphp.vulnweb.com && http.request.method == POST

This returns multiple results, but the count is not correct, so further refinement is needed.

1. Refining by Parameter: Inspecting the packets shows the relevant field is uname. We update the filter:

http.host == testphp.vulnweb.com && http.request.method == POST && urlencoded-form contains "uname"

This narrows the results, but still not the correct count.

1. Final Refinement: Manual inspection reveals that valid requests target /userinfo.php. To be precise, we filter using the full URI:

http.request.full_uri == "<http://testphp.vulnweb.com/userinfo.php>" && http.request.method == POST && urlencoded-form contains "uname"

Result: This final filter returns the correct number of relevant packets.

Insight: When basic filters are not enough, progressively refine them using specific fields (parameters, URIs, methods) and validate findings through manual inspection.

Q4: What is the password of the “Client986”?

Answer: clientnothere! Keep the same filter from the previous step applied. Locate and select packet number 1668, then scroll down to the packet details pane. Expand the “HTML Form URL Encoded” section to view the submitted data, as shown in the screenshot.

Q5: What is the comment provided by the “Client354”?

Answer: Nice work!

Reuse the filter from Question 3: http.host == testphp.vulnweb.com && http.request.method == POST

Scroll through the results until you find a POST request to comment.php. Select that packet, then expand the “HTML Form URL Encoded” section in the packet details pane.

Result: The answer is located in the “Form item: comment” field.

Task 4: Identifying Hosts: DHCP, NetBIOS, and Kerberos

Identifying Hosts

Overview: During an investigation, identifying hosts and users is essential. Relying only on IP-to-MAC mapping is not enough; analysts should also determine which hosts and users are involved in suspicious activity to define a clear starting point.

Naming Conventions: Enterprise networks often follow predefined naming patterns for hosts and users.

• Advantage: Makes identification and inventory management easier.
• Disadvantage: Attackers can mimic these patterns to blend into the network.

Even with security controls in place, analysts must develop strong host and user identification skills.

Useful Protocols for Identification:

• DHCP (Dynamic Host Configuration Protocol): Assigns IP addresses and network parameters automatically.
• NBNS (NetBIOS Name Service): Maps hostnames to IP addresses in local networks.
• Kerberos: Provides authentication and can help identify users and services.

DHCP Analysis

Definition: DHCP is responsible for automatically assigning IP addresses and communication parameters to devices on the network.

Purpose in Analysis: By analyzing DHCP traffic, an analyst can link IP addresses to specific devices and better understand network activity.

DHCP Investigation

Overview: DHCP traffic helps identify hosts by linking IP addresses, MAC addresses, and hostnames. Proper filtering of DHCP packet types and options is key to finding relevant events.

Basic Filter: dhcp or bootp

Packet Types (Option 53):

• Request (3): dhcp.option.dhcp == 3 → Contains hostname and requested parameters
• ACK (5): dhcp.option.dhcp == 5 → Server approves and assigns configuration
• NAK (6): dhcp.option.dhcp == 6 → Server denies the request

Since Option 53 has fixed values, start by filtering packet types, then refine using other options.

DHCP Request Analysis:

Focus on identifying the requesting host.

• Option 12: Hostname
• Option 50: Requested IP
• Option 51: Lease time
• Option 61: Client MAC

Example Filter: dhcp.option.hostname contains "keyword"

DHCP ACK Analysis:

Focus on the assigned configuration.

• Option 15: Domain name
• Option 51: Assigned lease time

Example Filter: dhcp.option.domain_name contains "keyword"

DHCP NAK Analysis:

Focus on rejection details.

• Option 56: Message (reason for denial)

Note: Instead of filtering NAK messages, manually inspect them. The message content can vary and provides important context for understanding the situation.

Tip: After filtering, use “Apply as Column” in Wireshark to quickly correlate hostnames, IPs, and MAC addresses for better visibility.

NetBIOS (NBNS) Analysis

Overview: NetBIOS, or Network Basic Input/Output System, is the technology responsible for allowing applications on different hosts to communicate with each other.

NBNS investigation in a nutshell:

Kerberos Analysis

Overview: Kerberos is the default authentication service for Microsoft Windows domains. It is used to securely authenticate service requests between computers over an untrusted network, ensuring secure identity verification.

Kerberos investigation in a nutshell:

Detecting suspicious activities in chunked files is a great way to practice focusing on details. Now we will use the ~/Desktop/exercise-pcaps/dhcp-netbios-kerberos/dhcp-netbios.pcap file to answer questions 1 through 3, and the ~/Desktop/exercise-pcaps/dhcp-netbios-kerberos/kerberos.pcap file to answer questions 4 and 5.

Q1: What is the MAC address of the host “Galaxy A30”?

Answer: 9a:81:41:cb:96:6c

Since the question asks for the host, the following filter is used: dhcp.option.hostname contains "A30"

After applying the filter, scroll through the results and inspect the BOOTP flags section. The MAC address can be found there, linked to the DHCP request.

Q2: How many NetBIOS registration requests does the “LIVALJM” workstation have?

Answer: 16

I used the filter nbns.name contains "LIVALJM" && nbns.flags.opcode == 5 because the question asks for the number of NetBIOS registration requests from the “LIVALJM” workstation. The opcode 5 is used to identify NBNS registration-related packets, which allows us to isolate only registration activity for that specific host and accurately count the requests.

Q3: Which host requested the IP address “172.16.13.85”?

Answer: Galaxy-A12

I used the filter dhcp.option.dhcp == 3 && dhcp.option.requested_ip_address == 172.16.13.85 because the question asks to identify which host requested a specific IP address. The value dhcp.option.dhcp == 3 targets DHCP Request packets, which are used when a device requests an IP address from the DHCP server. Combining it with dhcp.option.requested_ip_address == 172.16.13.85 narrows the results to only the request related to that specific IP, making it possible to identify the exact host responsible.

If the Host Name column is not visible in the Packet List, it can be added by right-clicking the column header and selecting the option to display it. Alternatively, the hostname can also be found directly inside the DHCP packet details pane.

Q4: What is the IP address of the user “u5”? (Enter the address in defanged format.)

Answer: 10[.]1[.]12[.]2

I used the filter kerberos.CNameString contains "u5" because the question asks for the IP address of the user “u5”. The CNameString The field in Kerberos traffic contains the username associated with authentication requests, so filtering by it helps isolate packets where the user “u5” is involved. From these packets, the user’s IP address can be identified.

Since the question requires the IP in defanged format, the extracted address is then processed using a tool like **CyberChef** to safely convert it into a defanged representation.

Q5: What is the hostname of the available host in the Kerberos packets?

Answer: xp1$

I used the filter kerberos.CNameString contains "$" because the question asks for the hostname of the available host in the Kerberos packets. In Kerberos traffic, entries in CNameString that end with a “$” represent machine accounts (hostnames) rather than user accounts. Filtering for “$” helps isolate only host-related entries and removes normal user authentication requests, making it easier to identify the available host in the capture.

Task 5: Tunnelling Traffic: ICMP and DNS

Overview: Traffic tunnelling (also known as port forwarding) is a technique used to transfer data securely between network segments. It encapsulates data inside legitimate protocols, so it appears normal while actually carrying hidden information. While widely used in enterprise environments for security and privacy, attackers abuse tunnelling (especially via ICMP and DNS) to bypass security controls, exfiltrate data, and establish C2 communication.

ICMP Analysis

Overview: ICMP (Internet Control Message Protocol) is used for network diagnostics and error reporting. Because it is a trusted protocol, attackers can exploit it for DoS attacks, data exfiltration, and C2 tunnelling by embedding data inside ICMP packets.

ICMP investigation in a nutshell:

Key indicators: High traffic volume, unusual packet sizes, or hidden data inside the ICMP payload.

Key Insight: ICMP tunnelling often appears after malware execution or exploitation. Although large payloads are suspicious, attackers may mimic normal packet sizes (e.g., 64 bytes), making detection harder. Analysts must understand normal traffic patterns to identify anomalies effectively.

DNS Analysis

Overview: DNS (Domain Name System) translates domain names into IP addresses and is often called the “phonebook of the internet.” Because it is widely used and trusted, attackers abuse DNS for data exfiltration and C2 communication, often going unnoticed.

DNS investigation in a nutshell:

Key indicators: Long subdomains, unusual query names, high DNS traffic volume.

Key Insight: DNS tunnelling typically appears after malware execution or exploitation. Attackers encode commands into subdomains (e.g., encoded-data.maliciousdomain.com) and send them as DNS queries to a C2 server. Analysts should focus on query length, unusual domain patterns, and traffic volume to detect anomalies.

Detecting suspicious activities in chunked files is a great way to practice focusing on details. Now, use the provided exercise file to apply these techniques and answer the upcoming questions.

Q1: Use the “Desktop/exercise-pcaps/dns-icmp/icmp-tunnel.pcap” file. Investigate the anomalous packets. Which protocol is used in ICMP tunnelling?

Answer: SSH

To investigate this question, start by filtering ICMP traffic using: icmp

Manually inspect packets for unusual or suspicious activity. During this process, a packet stands out as abnormal compared to typical ICMP traffic. A more efficient approach is to use a frame content filter to detect embedded protocols within ICMP payloads: icmp && frame matches "ssh|http|dns|ftp|scp"

This filter reveals hidden or encapsulated data within ICMP packets. By examining the RAW data of these packets, the suspicious content can be identified.

Q2: Use the “Desktop/exercise-pcaps/dns-icmp/dns.pcap” file.Investigate the anomalous packets. What is the suspicious main domain address that receives anomalous DNS queries? (Enter the address in defanged format.)

Answer: dataexfil[.]com

First, apply the task filter: dns.qry.name.len > 15 and !mdns

This returns a very large number of packets (over 33,000), which makes manual analysis difficult. To narrow down the results, increase the query name length to focus on unusually long DNS queries, which are often a sign of tunnelling or encoded data:dns.qry.name.len > 40 and !mdns

This refinement helps isolate more suspicious DNS activity.

Further Refinement: If needed, you can narrow it down even more by targeting a specific top-level domain (e.g., .com):

dns.qry.name.len > 40 and !mdns && dns.qry.name contains ".com"This approach helps focus on potentially malicious domains with long, encoded subdomain names.

After identifying the suspicious domain, copy it and process it using **CyberChef to convert it into a defanged format**. This ensures the domain is safe to share and analyze without the risk of accidental interaction.

Task 6: Clear-text Protocol Analysis: FTP

Overview: Analyzing cleartext protocols may seem simple, but investigating large network captures requires more than just reading visible data. A security analyst must extract meaningful insights, generate statistics, and correlate findings using both network knowledge and tool expertise.

FTP Analysis

Overview: FTP (File Transfer Protocol) is designed for simple file transfers, prioritizing usability over security. As a result, it is vulnerable to several risks: MITM attacks, credential theft, unauthorized access, phishing, malware delivery, and data exfiltration.

FTP investigation in a nutshell:

Key Indicators:

• Multiple failed logins → possible brute-force attack
• Repeated password attempts → possible password spraying
• Clear-text credentials in the USER/PASS commands

Advanced Filters:

• Failed login attempts: ftp.response.code == 530
• Failed attempts for a specific user: (ftp.response.code == 530) and (ftp.response.arg contains "username")
• Password usage tracking: (ftp.request.command == "PASS") and (ftp.request.arg == "password")

Detecting suspicious activities in chunked files is a great way to practice focusing on details. Now, use the file ~/Desktop/exercise-pcaps/ftp/ftp.pcap to analyze the traffic and answer the upcoming questions.

Q1: How many incorrect login attempts are there?

Answer: 737

I used the filter ftp.response.code == 530 Because the question asks for incorrect login attempts. The response code 530 In FTP, “No login, invalid password” indicates that the authentication attempt failed. Using this filter isolates only failed login attempts, making it easy to count the number of incorrect logins in the capture.

Q2: What is the size of the file accessed by the “ftp” account?

Answer: 39424

I used the filter ftp.response.code == 213 because the question asks for the size of the file. In FTP, the response code 213 represents file status information, which includes details such as the file size. Using this filter helps isolate the specific response where the server returns file-related information, allowing us to extract the required size from the packet details.

Q3: The adversary uploaded a document to the FTP server. What is the filename?

Answer: resume.doc

I first did some research to identify the correct FTP command used for file transfers, and found that RETR is used for retrieving (downloading) files from the FTP server. Based on this, I used the filter ftp.request.command == "RETR" because the question asks for the uploaded/downloaded document. This filter helps isolate file transfer activity and identify the specific document involved in the session.

Q4: The adversary tried to assign special flags to change the executing permissions of the uploaded file. What is the command used by the adversary?

Answer: CHMOD 777

I used the filter ftp contains "CHMOD" because it allows me to quickly search for any FTP traffic related to permission changes. After checking the available FTP commands, I found that CHMOD is used to modify file permissions using numeric or symbolic values. Using this filter helps isolate any activity where file permissions were being changed on the FTP server.

Task 7: Clear-text Protocol Analysis: FTP

Overview: HTTP (Hypertext Transfer Protocol) is a clear-text, request-response protocol used for web communication. Since it is unencrypted and widely allowed across networks, it is a key protocol in traffic analysis. It can reveal phishing activity, web attacks, data exfiltration, and C2 communication.

HTTP Investigation in a Nutshell:

HTTP Response Codes:

HTTP Parameters:

User-Agent Analysis:

Key Insight: Attackers often try to blend into normal traffic by modifying the user-agent field, but inconsistencies such as unusual tools, spelling variations, or multiple user-agents from the same host can indicate suspicious activity. User-agent analysis should always be used as a supporting detection method, not a standalone indicator.

Note: To display the User-Agent field as a column in Wireshark, right-click on the User-Agent field inside the HTTP packet details and select “Apply as Column”. This helps make it easier to compare user-agents across multiple packets during analysis.

Log4j Analysis

Overview: Log4j is a widely used logging library that was exploited through a critical vulnerability, allowing attackers to execute remote code via specially crafted log messages. In network traffic, this attack often appears in HTTP POST requests containing malicious payloads such as jndi:ldap or references to Exploit.class.

Log4j Investigation in a Nutshell:

Key Insight: Log4j attacks typically begin with a POST request carrying a malicious payload. Analysts should focus on detecting strings like jndi:ldap and Exploit.class, which indicate potential exploitation attempts hidden within HTTP traffic.

Now we will use the file ~/Desktop/exercise-pcaps/http/user-agent.pcap to answer questions 1–2 and ~/Desktop/exercise-pcaps/http/http.pcapng to answer questions 3–4.

Q1: Investigate the user agents. What is the number of anomalous “user-agent” types?

Answer: 6

Filtering HTTP User-Agent Traffic: Start by filtering packets containing HTTP user-agent information using http.user_agent. Then select one of the packets and apply the User-Agent field as a column by right-clicking it and choosing “Apply as Column”.

After that, review the User-Agent column values across all packets to identify both legitimate and suspicious (illegitimate) entries.

The hint provided helps identify the first legitimate user-agent, which can be used as a reference to compare and spot anomalies in the remaining traffic.

Q2: What is the packet number with a subtle spelling difference in the user agent field?

Answer: 52

In this question, I scrolled through the User-Agent column looking for inconsistencies or subtle anomalies in spelling. During the inspection, I found packet number 52 containing a misspelled browser name, where “Mozilla” was written as “Mozlila”. This slight variation indicates a malicious or non-standard user-agent, making it an illegitimate entry compared to the legitimate traffic.

Q3: Locate the “Log4j” attack starting phase. What is the packet number?

Answer: 444

In this question, I used the filter (http.user_agent contains "$") or (http.user_agent contains "==") because Log4j attacks often involve malicious or encoded payloads inside the User-Agent field, especially patterns like $ and == which are commonly used in injection and encoded exploitation attempts. This filter helps isolate suspicious HTTP requests that may indicate the starting phase of the Log4j attack, and it also supports identifying related packets needed for the following question.

Q4: Locate the “Log4j” attack starting phase and decode the base64 command. What is the IP address contacted by the adversary? (Enter the address in defanged format and exclude “{}”.)

Answer: 62[.]210[.]130[.]250

For this step, I copied the User-Agent value from the packet identified in the previous question.

Since the value is Base64 encoded, I used **CyberChef to decode it. After pasting the string into CyberChef and applying the “From Base64”** operation, the decoded output reveals the hidden content inside the User-Agent field, which is part of the Log4j attack payload.

Task 8: Encrypted Protocol Analysis: Decrypting HTTPS

Overview: HTTPS (HTTP Secure) uses TLS encryption to protect web traffic from interception, sniffing, and spoofing attacks. While this improves security, it also makes traffic analysis more challenging since packet contents (like URLs and data) are hidden without encryption keys. However, analysts can decrypt HTTPS traffic if they have access to the appropriate key files, allowing full inspection of web activity.

HTTPS / TLS Analysis in a Nutshell:

Key Insight

• HTTPS packets appear encrypted and may show limited information in Wireshark.
• Actual URLs, request data, and responses are hidden without decryption keys.
• TLS handshake packets can still reveal metadata (like certificates and session setup).
• Analysts must rely on key-based decryption or metadata analysis to investigate securely encrypted traffic.

Similar to the TCP three-way handshake, TLS establishes a secure connection using a handshake process before encrypted communication begins. The first steps of this process include the Client Hello and Server Hello messages, which help initiate and negotiate encryption settings between the client and server.

• Client Hello: (http.request or tls.handshake.type == 1) and !(ssdp)
• Server Hello: (http.request or tls.handshake.type == 2) and !(ssdp)

Note: To display the SNI (Server Name Indication) field as a column in Wireshark, follow these steps:

1. Edit → Preferences → Columns → click “+”
2. Set Type to: Custom
3. Set Fields to: tls.handshake.extensions_server_name
4. Name it: SNI → click OK

Result: This adds a new column showing the domain names requested during the TLS handshake, helping identify which servers are being accessed over HTTPS traffic.

A TLS key log file is a text file that stores session-based encryption keys used to decrypt HTTPS traffic. These keys are generated automatically when a browser (such as Chrome or Firefox) establishes a TLS connection and are written to a file if properly configured.

How It Works

• Each TLS session generates unique encryption key pairs.
• Browsers can export these keys if the SSLKEYLOGFILE environment variable is set.
• The key file must be created during the traffic capture, otherwise decryption is not possible.
• Without these keys, HTTPS traffic cannot be decrypted in Wireshark.

Wireshark Configuration

Key Insight

• Keys are session-specific and time-sensitive.
• If the browser session is not captured while logging is enabled, the traffic cannot be decrypted later.
• Proper setup is essential for successful HTTPS traffic analysis.

Adding key log files with the “right-click” menu:

GIF Source: TryHackMe

Adding key log files with the “Edit → Preferences → Protocols → TLS.”

GIF Source: TryHackMe

Viewing the traffic with/without the key log files:

GIF Source: TryHackMe

The above image shows that the traffic details become visible after using the key log file. The packet details and byte panes now display data in different formats for investigation. After decrypting the traffic, we can also see decompressed header information and HTTP/2 packet details.

Depending on the packet, the data may appear in different formats such as Frame, Decrypted TLS, Decompressed Header, Reassembled TCP, and Reassembled SSL.

Detecting suspicious activities in chunked files is a great way to learn how to focus on the details.

Now we will use the Desktop/exercise-pcaps/https/Exercise.pcap file to answer the questions below.

Q1: What is the frame number of the “Client Hello” message sent to “accounts.google.com”?

Answer: 16

I used the filter tls.handshake.type == 1 because the question asks for the Client Hello message, and handshake type 1 represents Client Hello in TLS. After applying the filter, I searched for the entry where the Server Name (SNI) is accounts.google.com to identify the correct packet and obtain its frame number.

Q2: Decrypt the traffic with the “KeysLogFile.txt” file. What is the number of HTTP2 packets?

Answer: 115

To decrypt the traffic, go to Edit → Preferences → Protocols → TLS and add the provided KeysLogFile.txt file. This enables Wireshark to decrypt the HTTPS traffic.

After decryption, apply the http2 filter to display all HTTP/2 packets. The total number of packets shown is the answer.

Q3: Go to Frame 322. What is the authority header of the HTTP2 packet? (Enter the address in defanged format.)

Answer: safebrowsing[.]googleapis[.]com

In this question, press CTRL+G, then enter frame number 322 to jump directly to the packet. Then expand the Hypertext Transfer Protocol section in the packet details pane and scroll down to locate the required value. Copy the value and use **CyberChef to apply the defang** operation, which converts it into a safe, shareable format.

Q4: Investigate the decrypted packets and find the flag! What is the flag?

Answer: FLAG{THM-PACKETMASTER}

Access the “Export Objects” feature by navigating to: File → Export Objects → HTTP

This will open the Wireshark Export HTTP Objects window. From the list, locate the entry related to packet number 1644 (the first packet), then click “Save” to export it. Once you open the saved file, the flag will be inside.

Task 9: Bonus: Hunt Cleartext Credentials!

Up to this point, we focused on analyzing packets and identifying anomalies. However, detecting cleartext credentials can be challenging because such activity may look similar to normal user behavior (e.g., multiple login attempts). Since everything is shown at the packet level, spotting repeated username/password entries is not always straightforward. To make this easier, Wireshark provides a feature that helps list detected credentials instead of manually searching through packets. Some protocol dissectors in Wireshark (such as FTP, HTTP, IMAP, POP, and SMTP) can automatically extract cleartext credentials from captured traffic. This can be accessed through: Tools → Credentials

This feature is available in Wireshark version 3.1 and later. It displays detected credentials in a separate window, including:

• Packet number
• Protocol
• Username
• Additional details

The window is interactive:

• Clicking the packet number takes you to the packet containing the password
• Clicking the username takes you to the packet containing the username

Note: This feature only works with specific protocols, so it should not be fully relied on. Manual analysis is still important to confirm whether cleartext credentials exist in the traffic.

Image Source: TryHackMe

Q1: Use the “Desktop/exercise-pcaps/bonus/Bonus-exercise.pcap” file. What is the packet number of the credentials using “HTTP Basic Auth”?

Answer: 237

Go to Tools → Credentials, and Wireshark will display a list of detected credentials along with their packet numbers. From there, you can directly identify which packets contain the credential information.

Q2: What is the packet number where “empty password” was submitted?

Answer: 170

In this question, I opened Tools → Credentials to view all detected credential entries. Then, I manually reviewed the listed packets and found that packet number 170 is the one where an empty password was submitted.

Task 10: Bonus: Actionable Results!

After completing the investigation and identifying the anomalies, the next step is to take action. In some cases, analysts are responsible not only for detection but also for responding to the threat.

Wireshark can assist with this by allowing you to generate firewall rules directly from the captured traffic. This can be done through: Tools → Firewall ACL Rules

When you open this feature, Wireshark provides a set of suggested rules based on the selected traffic. These rules can be generated using:

• IP addresses
• Ports
• MAC addresses

The rules are intended to be applied on an external firewall interface to block or control malicious activity.

Wireshark supports generating rules for multiple platforms, including:

• Netfilter (iptables)
• Cisco IOS (standard and extended)
• IPFilter (ipfilter)
• IPFirewall (ipfw)
• Packet Filter (pf)
• Windows Firewall (netsh formats)

Image Source: TryHackMe

Q1: Use the “Desktop/exercise-pcaps/bonus/Bonus-exercise.pcap” file. Select packet number 99. Create a rule for “IPFirewall (ipfw)”. What is the rule for “denying source IPv4 address”?

Answer: add deny ip from 10.121.70.151 to any in

Press CTRL+G and enter packet number 99 to jump directly to it. Then navigate to Tools → Firewall ACL Rules.

In the “Create rules for” dropdown, select IPFirewall (ipfw). The generated rules will appear, and the first rule shown contains the answer.

Q2: Select packet number 231. Create “IPFirewall” rules. What is the rule for “allowing destination MAC address”?

Answer: add allow MAC 00:d0:59:aa:af:80 any in

In this question, we follow the same steps as the previous one, but this time we focus on the destination MAC address. After opening the relevant packet, we use Tools → Firewall ACL Rules and generate the rules. From the output, we identify the required value by checking the rule that corresponds to the destination MAC field.

Walkthrough Complete 🥳🎉

Thank you for following this walkthrough! I hope you found it clear and helpful in completing the challenge.

If you enjoyed this guide, please consider sharing it with others who might be working on the same task!