Protocol Hierarchy – traffic map
Menu Statistics → Protocol Hierarchy – the first window after downloading PCAP. Here you can see the percentage distribution of protocols by the number of packages and the volume of data.
What to look for: Unencrypted protocols among the TLS array. In a typical CTF dump, 80-90% of traffic is TLS, and it is useless without a decryption key. But 0.3% HTTP, 5% DNS or sudden FTP - that's where the evidence lies. A specific example: in the analysis of evidence.pcap from one CTF task Protocol Hierarchy immediately showed 88.4% of TCP, inside - TLS dominates (91.1% by volume), and unencrypted HTTP is 0.3%. It was in that 0.3% that key data was. Without Protocol Hierarchy I would dig into the encrypted traffic for hours.
What to look for in the hierarchy: - HTTP, FTP, Telnet, SMTP — protocols that drive data (including passwords) in plain text. Priority number one. - DNS — if the share of DNS is abnormally high, exfiltration through subdomains is possible. - IRC, TFTP, non-standard protocols — rare beasts in the dump almost always deserve attention.
Conversations and Endpoints
Statistics → Conversations (TCP tab, volume sorting) shows all pairs of interacting hosts. Instantly separates background noise from targeted traffic.
Key Anomalies: - One connection to an abnormally large amount of data is probable exfiltration or file transfer. - Dozens of short TCP sessions to one port — brute-force or scanning. - Connection to port 4444, 1337, 31337, 9001 — classic shell ports. They meet constantly on CTF. - HTTP connection (port 80) when dominating TLS — an anomaly worth exploring first.
Statistics → Endpoints complements the picture: one external IP, initiating hundreds of connections to the internal host, is an anomaly. On the CTF of the middle level, this pattern indicates the attacker.
Protocol Hierarchy and Conversations show only statistics. This is the answer to the question “where to dig” rather than “where the flag.” After exploration, we turn to filtration.
Wireshark filters for network networks CTF
Display filters are the main tool for navigating the traffic dump. Without them, the analysis of a file with tens of thousands of packages is a lottery.
Basic display filters
A set of filters to know by heart: - http – all HTTP traffic - dns – DNS requests and answers - ftp – FTP sessions - smtp – e-mail - telnet – Telnet sessions - tcp.port == 4444 – traffic on a particular port - ip.addr == 10.0.2.15 – packages from/to a certain IP - http.request.method == "POST" – POST requests (forms, file downloads, send passwords)
Filters are combined by operators: && (logical and) || (logical OR), ! (Negation). Example: !dns && !arp will remove the background noise of DNS-resolving and ARP requests - immediately it will become cleaner. Oh http && ip.src == 10.0.2.15 show HTTP traffic only from a particular host.
How to find the flag in PCAP: frame cere
When the flag format is known (and on the CTF it is indicated in the task description almost always) - search for the contents the fastest way: - frame contains "flag" – line “flag” in the entire frame, including payload - frame contains "CTF{" – specific flag format - tcp contains "password" – passwords in TCP-stream - http contains "secret" – secret data in HTTP
On the entry-level CTF, the flag is transmitted in the open in about half of the tasks. Not joking — frame contains plus the flag format solves the problem in 30 seconds. Check the dumbest way first before diving into in-depth protocol analysis.
If the format is unknown, try the series: frame contains "flag", then frame contains "key", then frame contains "secret", then frame contains "pass". At least one of these lines gives a lead in most cases.
Regular expressions: matches
Operator matches supports regex and solves tasks that contains will not pull: - http.request.uri matches ".*\\.php" – all requests to PHP scripts - dns.qry.name matches "^[a-f0-9]{10,}\." – DNS queries with long hex lines in subdomains (typical DNS exfiltration trait) - http.user_agent matches "(?i)sqlmap|nikto|nmap" – scanners in User-Agent
For hunting for creeds - a separate group of filters: - http.authorization HTTP Basic/Digest authentication (Base64-coded creeds) - ftp.request.command == "PASS" – FTP passwords in plain text - smtp.auth.password – SMTP passwords
Display filter restriction: If traffic is encrypted by TLS and there is no decryption key, filters by content will show debris. This is the section on TLS decryption below.
Wireshark Follow TCP Stream: pull passwords out of traffic
Follow TCP Stream collects all packages of a single TCP session into a single readable stream. In fact, an intercepted dialog between the client and the server, glued from the fragments. Red text - data from the client, blue - from the server.
Access: right click on any package of the session of interest → Follow → TCP Stream. At the bottom of the window is the switch between the streams: Stream 0, Stream 1, Stream 2. On the entry-level CTF, there’s usually a little bit – it’s worth looking at each.
Typical Finds in TCP Stream on CTF: - FTP session: teams USER and PASS open text. Password is often the flag or contains part of it. - Telnet session: The symbols are entered one at a time, but Wireshark collects them into the readable text. Look for input commands and server responses. - HTTP-exchange: query and response headlines in its entirety — User-Agent, Cookie, Set-Cookie, Authorization. - Reverse shell: if commands are visible in the stream whoami, id, cat /etc/passwd – you have a reverse shell session. The flag is usually in the conclusion of one of the teams.
220 FTP Server Ready
USER admin
331 Password required for admin
PASS CTF{ftp_cr3ds_1n_pl41n}
230 User admin logged in
All that after PASS, the flag. On a mid-level CTF, the password can be coded (Base64, hex), but the principle is the same.
Export of Wireshark objects: files from PCAP
The files transmitted over the network are recovered from PCAP entirely. Frequent CTF scenario: The flag is hidden inside an image, PDF, archive, or executable transmitted over HTTP.
The Way File → Export Objects → HTTP opens a list of all files transferred over HTTP during capture: images, scripts, documents, binary. Similar menus are available for SMB (Export Objects → SMB), TFTP (Export Objects → TFTP) and email investments (Export Objects → IMF).
After extracting each file, check: - file имя_файла – determines the real type by magic bytes. Expansion can lie — file not lying. - strings имя_файла | grep -i flag – looking for text strings in binary files. The flag is often sewn with a string constant inside an ELF binary or PDF. - binwalk имя_файла – finds nested files. Steganography (T1027.003): PNG sews a ZIP archive inside which is a text file with a flag. binwalk -e will extract the attachments automatically.
When Export Objects Doesn't Work
If the file is transferred via a non-standard protocol or fragmented, use Follow TCP Stream. At the bottom of the flow window, switch Show data as on Raw and press Save as.... This will keep the raw flow of bytes, which is then disassembled through file and binwalk.
On one of the CyberDefenders shuttles, I tried to get a file through Export Objects for half an hour until I guessed to save the raw stream manually — binwalk found in it an ELF-binary with a sewn flag. Such things are not written in any manual, you put your hand in practice.
DNS Exfiltration: When the flag is hidden in subdomains
DNS-exfiltration (DNS, T1071.004) is one of the most sly techniques in the CTF of medium and advanced level. The data is encoded and transmitted as subdomins of DNS requests: 68656c6c6f.evil.com, where 68656c6c6f – hex-line of the word “hello”.
Signs of DNS Tunneling in Wireshark: - Abnormally long DNS requests (subdoms longer than 30 characters) - Many TXT-type queries to a single domain - Subdomins from hex symbols (0-9a-f) or Base64 symbols - Large number of DNS requests to one non-standard domain in a short period
Filter for detection: dns.qry.name matches "^[a-f0-9]{10,}\." show requests where the subdomain consists of long hex strings. If there are dozens of such requests, exfiltration is in front of you.
For the extraction of tshark data, GUI is more convenient:
tshark -r challenge.pcap -Y "dns.qry.type == 1" \
-T fields -e dns.qry.name | sort -u
The result is a list of all DNS A-requests. If you see a pattern like 4354467b.evil.com, 646e735f.evil.com, 337866316c.evil.com, 7d.evil.com – glue the subdomains (without .evil.com) and decode from hex. CyberChef, recipe From Hex: 4354467b646e735f337866316c7d → CTF{dns_3xf1l} (an example to demonstrate the concept).
For TXT records, replace the query type with dns.qry.type == 16 and add the response field -e dns.txt. TXT records hold more data and are used more frequently in complex tasks.
TLS-decryption in CTF tasks
If Protocol Hierarchy shows 90%+ TLS and none of the previous methods have yielded a result, re-read the task condition carefully. Sometimes together with PCAP give a key file: server RSA-key (.pem) or pre-master secret log. The file may lie in the task archive or be mentioned in the description. I lost 40 minutes on it a couple of times - the key was lying in the archive, and I didn't notice it.
Connect pre-master secret log: Edit → Preferences → Protocols → TLS → (Pre)-Master-Secret log filename. Format of records in file: CLIENT_RANDOM <hex> <hex>. After connecting, Wireshark will decrypt the TLS sessions, and you will see HTTP inside – then work with standard filters.
Server RSA key connection: in the same TLS section, field RSA keys list. Specify IP servers, port (usually 443), protocol (http) and .pem file path.
And now the trap that many people fall for. A server RSA key only works if the key exchange uses RSA without Perfect Forward Secrecy and the protocol version is TLS 1.2 or lower. In TLS 1.3 RSA key exchange is completely excluded (RFC 8446), therefore, decryption with a server key is impossible in principle. If you see TLS-handshake ECDHE or DHE – need pre-master secret log, server key will not help. On CTF it is a frequent trap: give .pem, and handshake - ECDHE or TLS 1.3. Check the TLS version and field Cipher Suite in Client Hello / Server Hello.
Automation with tshark: single-installers for disassembling network traffic
tshark is a console version of Wireshark from the same distribution. Indispensable in two scenarios on CTF: processing large dumps (GUI brakes on files >100 MB) and quick search for patterns without running a graphical interface.
tshark -r file.pcap -Y "http.request" \
-T fields -e http.request.method -e http.host -e http.request.uri
tshark -r file.pcap -Y 'frame contains "flag"' -x
tshark -r file.pcap -Y 'ftp.request.command == "PASS"' \
-T fields -e ftp.request.arg
tshark -r file.pcap -q -z io,phs
Flag -T fields -e поле extracts specific values – convenient for scripting and pipes. The result can be transmitted to grep, sort -u, awk for further processing. Flag -x shows the hex-dump of each package — useful for manual viewing of one or two found packages. With a large number of matches, the conclusion becomes redundant; then better -T fields -e frame.number.
Decode As: non-standard protocols in the traffic dump
Sometimes traffic goes on a non-standard port, and Wireshark does not recognize the protocol automatically. An HTTP server on port 8080, an RTP stream disguised as an unknown UDP is a typical mid-level CTF task.
Solution: right click on package → Decode As... → choice of protocol. After that, Wireshark reassembles the dissection and shows the data in a structured manner. CTF organizers specially remove standard ports to Export Objects and automatic filters did not work out of the box.
Characteristic scenario: UDP traffic with uniform frequency and small packages. Try it Decode As → RTP. If they guessed - Telephony → RTP → RTP Streams show an audio stream that can be played directly in Wireshark. The flag can be uttered by voice or encoded in an audio signal (DTMF). It sounds crazy, but I'm caught up twice.
Another scenario: TCP on a non-standard port. Decode As → HTTP - and Export Objects → HTTP show files that were invisible before that.
Step-by-step algorithm for solving PCAP problems on CTF
All of the above is collected in an algorithm that works on most forensic tasks:
Quick check. frame contains "flag" or the format of the flag from the task. Closes 30-40% of entry-level tasks.
Protocol Hierarchy. Statistics → Protocol Hierarchy. What unencrypted protocols are there?
Conversations. Statistics → Conversations. Anomalies by volume, ports, number of sessions.
Filtering by protocol. All right: http → ftp → dns → smtp → telnet.
Follow TCP Stream. For every suspicious stream. Passwords, flags, encoded lines.
Export Objects. File → Export Objects → HTTP/SMB/TFTP. Extracted files → file, strings, binwalk.
DNS analysis. If Protocol Hierarchy shows a lot of DNS – check on exfiltration through subdomains.
TLS decryption. If there is a key in the task, connect and repeat steps 4-6.
Decode As. Unrecognized streams → manual decoding.
Menu Statistics → Protocol Hierarchy – the first window after downloading PCAP. Here you can see the percentage distribution of protocols by the number of packages and the volume of data.
What to look for: Unencrypted protocols among the TLS array. In a typical CTF dump, 80-90% of traffic is TLS, and it is useless without a decryption key. But 0.3% HTTP, 5% DNS or sudden FTP - that's where the evidence lies. A specific example: in the analysis of evidence.pcap from one CTF task Protocol Hierarchy immediately showed 88.4% of TCP, inside - TLS dominates (91.1% by volume), and unencrypted HTTP is 0.3%. It was in that 0.3% that key data was. Without Protocol Hierarchy I would dig into the encrypted traffic for hours.
What to look for in the hierarchy: - HTTP, FTP, Telnet, SMTP — protocols that drive data (including passwords) in plain text. Priority number one. - DNS — if the share of DNS is abnormally high, exfiltration through subdomains is possible. - IRC, TFTP, non-standard protocols — rare beasts in the dump almost always deserve attention.
Conversations and Endpoints
Statistics → Conversations (TCP tab, volume sorting) shows all pairs of interacting hosts. Instantly separates background noise from targeted traffic.
Key Anomalies: - One connection to an abnormally large amount of data is probable exfiltration or file transfer. - Dozens of short TCP sessions to one port — brute-force or scanning. - Connection to port 4444, 1337, 31337, 9001 — classic shell ports. They meet constantly on CTF. - HTTP connection (port 80) when dominating TLS — an anomaly worth exploring first.
Statistics → Endpoints complements the picture: one external IP, initiating hundreds of connections to the internal host, is an anomaly. On the CTF of the middle level, this pattern indicates the attacker.
Protocol Hierarchy and Conversations show only statistics. This is the answer to the question “where to dig” rather than “where the flag.” After exploration, we turn to filtration.
Wireshark filters for network networks CTF
Display filters are the main tool for navigating the traffic dump. Without them, the analysis of a file with tens of thousands of packages is a lottery.
Basic display filters
A set of filters to know by heart: - http – all HTTP traffic - dns – DNS requests and answers - ftp – FTP sessions - smtp – e-mail - telnet – Telnet sessions - tcp.port == 4444 – traffic on a particular port - ip.addr == 10.0.2.15 – packages from/to a certain IP - http.request.method == "POST" – POST requests (forms, file downloads, send passwords)
Filters are combined by operators: && (logical and) || (logical OR), ! (Negation). Example: !dns && !arp will remove the background noise of DNS-resolving and ARP requests - immediately it will become cleaner. Oh http && ip.src == 10.0.2.15 show HTTP traffic only from a particular host.
How to find the flag in PCAP: frame cere
When the flag format is known (and on the CTF it is indicated in the task description almost always) - search for the contents the fastest way: - frame contains "flag" – line “flag” in the entire frame, including payload - frame contains "CTF{" – specific flag format - tcp contains "password" – passwords in TCP-stream - http contains "secret" – secret data in HTTP
On the entry-level CTF, the flag is transmitted in the open in about half of the tasks. Not joking — frame contains plus the flag format solves the problem in 30 seconds. Check the dumbest way first before diving into in-depth protocol analysis.
If the format is unknown, try the series: frame contains "flag", then frame contains "key", then frame contains "secret", then frame contains "pass". At least one of these lines gives a lead in most cases.
Regular expressions: matches
Operator matches supports regex and solves tasks that contains will not pull: - http.request.uri matches ".*\\.php" – all requests to PHP scripts - dns.qry.name matches "^[a-f0-9]{10,}\." – DNS queries with long hex lines in subdomains (typical DNS exfiltration trait) - http.user_agent matches "(?i)sqlmap|nikto|nmap" – scanners in User-Agent
For hunting for creeds - a separate group of filters: - http.authorization HTTP Basic/Digest authentication (Base64-coded creeds) - ftp.request.command == "PASS" – FTP passwords in plain text - smtp.auth.password – SMTP passwords
Display filter restriction: If traffic is encrypted by TLS and there is no decryption key, filters by content will show debris. This is the section on TLS decryption below.
Wireshark Follow TCP Stream: pull passwords out of traffic
Follow TCP Stream collects all packages of a single TCP session into a single readable stream. In fact, an intercepted dialog between the client and the server, glued from the fragments. Red text - data from the client, blue - from the server.
Access: right click on any package of the session of interest → Follow → TCP Stream. At the bottom of the window is the switch between the streams: Stream 0, Stream 1, Stream 2. On the entry-level CTF, there’s usually a little bit – it’s worth looking at each.
Typical Finds in TCP Stream on CTF: - FTP session: teams USER and PASS open text. Password is often the flag or contains part of it. - Telnet session: The symbols are entered one at a time, but Wireshark collects them into the readable text. Look for input commands and server responses. - HTTP-exchange: query and response headlines in its entirety — User-Agent, Cookie, Set-Cookie, Authorization. - Reverse shell: if commands are visible in the stream whoami, id, cat /etc/passwd – you have a reverse shell session. The flag is usually in the conclusion of one of the teams.
220 FTP Server Ready
USER admin
331 Password required for admin
PASS CTF{ftp_cr3ds_1n_pl41n}
230 User admin logged in
All that after PASS, the flag. On a mid-level CTF, the password can be coded (Base64, hex), but the principle is the same.
Export of Wireshark objects: files from PCAP
The files transmitted over the network are recovered from PCAP entirely. Frequent CTF scenario: The flag is hidden inside an image, PDF, archive, or executable transmitted over HTTP.
The Way File → Export Objects → HTTP opens a list of all files transferred over HTTP during capture: images, scripts, documents, binary. Similar menus are available for SMB (Export Objects → SMB), TFTP (Export Objects → TFTP) and email investments (Export Objects → IMF).
After extracting each file, check: - file имя_файла – determines the real type by magic bytes. Expansion can lie — file not lying. - strings имя_файла | grep -i flag – looking for text strings in binary files. The flag is often sewn with a string constant inside an ELF binary or PDF. - binwalk имя_файла – finds nested files. Steganography (T1027.003): PNG sews a ZIP archive inside which is a text file with a flag. binwalk -e will extract the attachments automatically.
When Export Objects Doesn't Work
If the file is transferred via a non-standard protocol or fragmented, use Follow TCP Stream. At the bottom of the flow window, switch Show data as on Raw and press Save as.... This will keep the raw flow of bytes, which is then disassembled through file and binwalk.
On one of the CyberDefenders shuttles, I tried to get a file through Export Objects for half an hour until I guessed to save the raw stream manually — binwalk found in it an ELF-binary with a sewn flag. Such things are not written in any manual, you put your hand in practice.
DNS Exfiltration: When the flag is hidden in subdomains
DNS-exfiltration (DNS, T1071.004) is one of the most sly techniques in the CTF of medium and advanced level. The data is encoded and transmitted as subdomins of DNS requests: 68656c6c6f.evil.com, where 68656c6c6f – hex-line of the word “hello”.
Signs of DNS Tunneling in Wireshark: - Abnormally long DNS requests (subdoms longer than 30 characters) - Many TXT-type queries to a single domain - Subdomins from hex symbols (0-9a-f) or Base64 symbols - Large number of DNS requests to one non-standard domain in a short period
Filter for detection: dns.qry.name matches "^[a-f0-9]{10,}\." show requests where the subdomain consists of long hex strings. If there are dozens of such requests, exfiltration is in front of you.
For the extraction of tshark data, GUI is more convenient:
tshark -r challenge.pcap -Y "dns.qry.type == 1" \
-T fields -e dns.qry.name | sort -u
The result is a list of all DNS A-requests. If you see a pattern like 4354467b.evil.com, 646e735f.evil.com, 337866316c.evil.com, 7d.evil.com – glue the subdomains (without .evil.com) and decode from hex. CyberChef, recipe From Hex: 4354467b646e735f337866316c7d → CTF{dns_3xf1l} (an example to demonstrate the concept).
For TXT records, replace the query type with dns.qry.type == 16 and add the response field -e dns.txt. TXT records hold more data and are used more frequently in complex tasks.
TLS-decryption in CTF tasks
If Protocol Hierarchy shows 90%+ TLS and none of the previous methods have yielded a result, re-read the task condition carefully. Sometimes together with PCAP give a key file: server RSA-key (.pem) or pre-master secret log. The file may lie in the task archive or be mentioned in the description. I lost 40 minutes on it a couple of times - the key was lying in the archive, and I didn't notice it.
Connect pre-master secret log: Edit → Preferences → Protocols → TLS → (Pre)-Master-Secret log filename. Format of records in file: CLIENT_RANDOM <hex> <hex>. After connecting, Wireshark will decrypt the TLS sessions, and you will see HTTP inside – then work with standard filters.
Server RSA key connection: in the same TLS section, field RSA keys list. Specify IP servers, port (usually 443), protocol (http) and .pem file path.
And now the trap that many people fall for. A server RSA key only works if the key exchange uses RSA without Perfect Forward Secrecy and the protocol version is TLS 1.2 or lower. In TLS 1.3 RSA key exchange is completely excluded (RFC 8446), therefore, decryption with a server key is impossible in principle. If you see TLS-handshake ECDHE or DHE – need pre-master secret log, server key will not help. On CTF it is a frequent trap: give .pem, and handshake - ECDHE or TLS 1.3. Check the TLS version and field Cipher Suite in Client Hello / Server Hello.
Automation with tshark: single-installers for disassembling network traffic
tshark is a console version of Wireshark from the same distribution. Indispensable in two scenarios on CTF: processing large dumps (GUI brakes on files >100 MB) and quick search for patterns without running a graphical interface.
tshark -r file.pcap -Y "http.request" \
-T fields -e http.request.method -e http.host -e http.request.uri
tshark -r file.pcap -Y 'frame contains "flag"' -x
tshark -r file.pcap -Y 'ftp.request.command == "PASS"' \
-T fields -e ftp.request.arg
tshark -r file.pcap -q -z io,phs
Flag -T fields -e поле extracts specific values – convenient for scripting and pipes. The result can be transmitted to grep, sort -u, awk for further processing. Flag -x shows the hex-dump of each package — useful for manual viewing of one or two found packages. With a large number of matches, the conclusion becomes redundant; then better -T fields -e frame.number.
Decode As: non-standard protocols in the traffic dump
Sometimes traffic goes on a non-standard port, and Wireshark does not recognize the protocol automatically. An HTTP server on port 8080, an RTP stream disguised as an unknown UDP is a typical mid-level CTF task.
Solution: right click on package → Decode As... → choice of protocol. After that, Wireshark reassembles the dissection and shows the data in a structured manner. CTF organizers specially remove standard ports to Export Objects and automatic filters did not work out of the box.
Characteristic scenario: UDP traffic with uniform frequency and small packages. Try it Decode As → RTP. If they guessed - Telephony → RTP → RTP Streams show an audio stream that can be played directly in Wireshark. The flag can be uttered by voice or encoded in an audio signal (DTMF). It sounds crazy, but I'm caught up twice.
Another scenario: TCP on a non-standard port. Decode As → HTTP - and Export Objects → HTTP show files that were invisible before that.
Step-by-step algorithm for solving PCAP problems on CTF
All of the above is collected in an algorithm that works on most forensic tasks:
Quick check. frame contains "flag" or the format of the flag from the task. Closes 30-40% of entry-level tasks.
Protocol Hierarchy. Statistics → Protocol Hierarchy. What unencrypted protocols are there?
Conversations. Statistics → Conversations. Anomalies by volume, ports, number of sessions.
Filtering by protocol. All right: http → ftp → dns → smtp → telnet.
Follow TCP Stream. For every suspicious stream. Passwords, flags, encoded lines.
Export Objects. File → Export Objects → HTTP/SMB/TFTP. Extracted files → file, strings, binwalk.
DNS analysis. If Protocol Hierarchy shows a lot of DNS – check on exfiltration through subdomains.
TLS decryption. If there is a key in the task, connect and repeat steps 4-6.
Decode As. Unrecognized streams → manual decoding.
