Cracking the Capture —
My First Wireshark CTF.

CTF stands for Capture the Flag. It's a cybersecurity competition format where you solve puzzles to find hidden strings called "flags" — typically formatted as CTF{some_string_here}. Submit the flag, get the points.

Challenges are grouped by category: web exploitation, binary exploitation, cryptography, steganography, reverse engineering, and — the one we're doing today — network forensics.

Network forensics challenges give you a .pcap file: a raw recording of network traffic captured from a live interface. Your job is to dig through it and find what's hidden. The tool everyone uses for this is Wireshark — a free, open-source packet analyzer that lets you open a capture and inspect every single byte that went over the wire.

The challenge was called "Listen Closely". The full description read:

No category hints. No protocol hints. Just the file. I opened it in Wireshark and stared at the wall of packets.

Raw packet view is overwhelming — colour-coded rows of TCP, HTTP, DNS, ARP packets with no obvious structure. The first thing a good network analyst does is not look at individual packets. They look at the big picture.

In Wireshark: Statistics → Protocol Hierarchy. This gives you a tree breakdown of every protocol in the capture, sorted by percentage of traffic.

FTP. That was my signal. FTP — File Transfer Protocol — is a legacy protocol from the 1970s that was never designed with security in mind. It transmits everything in plaintext: usernames, passwords, and the files themselves. No encryption. None.

The presence of FTP in a capture described as "compromised internal network" is exactly the kind of thing a CTF challenge would use. I filtered for it immediately.

Wireshark display filters are the core skill in packet analysis. They don't delete packets — they temporarily hide anything that doesn't match, letting you focus on what you care about. Think of them as SQL WHERE clauses for network traffic.

I typed ftp into the filter bar and hit enter. Instantly the view collapsed to just the FTP control channel — the command conversation between client and server. Three things stood out immediately:

There was the username, the password, and the filename — all readable without any decryption. But I still needed the contents of secret.txt.

FTP is interesting because it splits traffic across two channels: port 21 for commands (the control channel — what we just saw), and a dynamically assigned port for file data (the data channel). The ftp filter only shows commands. To see file contents, I needed:

ftp-data

Three packets appeared — the actual bytes of secret.txt being transferred over the wire. Small file. Now I needed to read it.

"Follow TCP Stream" is Wireshark's best feature for CTF work. It reassembles all packets belonging to one TCP connection and shows you the complete conversation — both directions, in order, as readable text.

Right-click any of the ftp-data packets → Follow → TCP Stream.

The stream window opens. Client data is shown in one colour, server data in another. For an FTP file download, the server's output is the file.

To: CTF Admin
Subject: Vault Access Credentials

Here are the credentials you requested for the restricted vault.

Username: vaultkeeper
Password: CTF{ftp_cleartext_is_a_crime_0xdeadbeef}

Rotate after first use. Do not forward this message.

There it is. The flag, sitting in a plaintext file, transferred over an unencrypted protocol, visible to anyone who could see the network. No cracking. No decryption. Just read.

Submitting CTF{ftp_cleartext_is_a_crime_0xdeadbeef} gave me the points. But the more interesting thing was understanding why this worked.

The challenge had three layers of knowledge being tested:

1. FTP is plaintext — most people don't know this. They assume anything with a login screen is encrypted.
2. FTP has two channels — the ftp filter shows commands; ftp-data shows actual file contents. You need both.
3. Follow TCP Stream reconstructs files — you don't need to export packets manually; Wireshark assembles the file for you.

Each layer filtered out people who didn't know the next piece. That's good challenge design: multiple small insights rather than one big one.

I also checked the HTTP traffic out of curiosity. Nothing interesting there — just some GET requests to an internal wiki. But the technique is the same: filter http.request.method == "POST" to find form submissions, then follow the stream to see what was submitted. Credentials in login forms over plain HTTP are just as exposed as FTP passwords.

Here's every Wireshark filter I've used repeatedly across network forensics challenges. Bookmark this — it covers 95% of what comes up in beginner and intermediate CTFs.

And the menu shortcuts worth knowing:

What I took away from this challenge wasn't just the flag — it was a mental model for reading network traffic.

Network traffic is a story. Every SYN is a conversation starting. Every FIN is a goodbye. The Protocol Hierarchy is the table of contents. Filters are your ctrl+F. Follow TCP Stream is "read this chapter end-to-end." Once you see it that way, Wireshark stops being a wall of data and becomes a narrative tool.

The security lesson is more sobering: plaintext protocols are a complete security failure. FTP, Telnet, basic HTTP — they weren't built with adversaries in mind. Anything that traverses these protocols is an open book to anyone on the network path. In a CTF, that's a fun puzzle. In production, it's a breach waiting to happen.