Wireshark: Traffic Analysis (TryHackMe write-up)

My write-up of the TryHackMe Wireshark: Traffic Analysis room, part of the Security Analyst path. Originally published in my thm-writeups repo on GitHub.

Objective#

This room focuses on analyzing network traffic captures (PCAPs) using Wireshark to identify network behavior, anomalies, and how common attack patterns appear in packet captures.

Tools#

• Wireshark for network packet analysis
• PCAP files provided by TryHackMe
• Wireshark filters

Environment#

• Provided Linux VM

Methodology#

I approached the room by completing each task in the following order:

1. Read through the theory. Make short notes of things to remember, and look up concepts I was not fully familiar with.
2. Open capture files in Wireshark. Some sections use multiple capture files, so be sure to use the correct one. Examine initial packets to understand traffic context.
3. Apply display filters for specific analysis. Isolate protocols (e.g. arp, dns, http). Remembering every filter is difficult, so I often dragged relevant fields directly into the filter bar to get the correct syntax.
4. Look for anomalies and suspicious behaviour. Multiple MAC addresses associated with a single IP (ARP spoofing), unusually large frame lengths in DNS and ICMP traffic (tunneling), cleartext credential transmissions in HTTP and FTP.
5. Document findings and insights. Note interesting patterns and new concepts, including defensive takeaways where applicable.

Key findings#

Nmap scans#

• Detected patterns of different scan types (TCP Connect, SYN, UDP) using filters.
• Observed handshake sequences in captures corresponding to each scan behavior.
• SYN scan → half-open connections, stealthier.
• UDP scan → ICMP port unreachable responses.

Filters used:

# All TCP connect scans
tcp.flags.syn==1 and tcp.flags.ack==0 and tcp.window_size > 1024

# All TCP port 80 traffic
tcp.port==80

# All UDP closed ports
icmp.type==3 and icmp.code==3

# All UDP traffic in the 55-70 port range
udp.port in {55..70}

ARP poisoning & MITM#

• Found multiple ARP responses for the same IP, a classic ARP poisoning indicator.
• Recognized MITM behavior where traffic was redirected to an unintended MAC address due to spoofed ARP replies.

Filters used:

# Detect duplicated ARP addresses to identify the attacker
arp.duplicate-address-detected or arp.duplicate-address-frame

# Filter ARP requests by the attacker's MAC
arp.opcode == 1 and eth.src == 00:0c:29:e2:18:b4

# All HTTP traffic to the attacker
http and eth.dst == 00:0c:29:e2:18:b4

# POST requests to the attacker containing usernames
eth.dst == 00:0c:29:e2:18:b4 and http.request.method == "POST" and frame contains "uname"
http.request.method == "POST" and frame contains "client986"

Identifying hosts#

• Used DHCP and NetBIOS protocols to identify hosts and services in the local network.
• Kerberos traffic revealed authentication activity patterns.

Tunneling: DNS & ICMP#

• Detected tunneling via unexpected DNS query volumes or non-standard ICMP payloads.
• Unusually large or repetitive payload sizes in DNS and ICMP traffic may indicate tunneling.

# ICMP or DNS packets with frame length greater than 150
(dns || icmp) && frame.len > 150

Cleartext traffic analysis (FTP & HTTP)#

• Found FTP and HTTP sessions with credentials or data in plain text.
• Demonstrated how such cleartext protocols expose sensitive information.

Decrypting HTTPS#

• Used provided TLS keys to decrypt portions of HTTPS traffic and inspect headers and metadata.

Defensive perspective#

• Firewall rules. Wireshark can generate filters for common firewalls: Tools → Firewall ACL Rules.
• Protocol restrictions. Block or monitor legacy cleartext protocols (FTP/HTTP).
• Network segmentation. Limit broadcast domains to minimise ARP poisoning impact.

Screenshots#

ARP poisoning evidence#

Suspicious DNS/ICMP tunneling#

---

Part of my Security Analyst path work, the SAL1 coursework is complete, with the exam and more write-ups to come. The original version of this write-up lives in Nawil53/thm-writeups on GitHub.