On the last CyberDefenders-shuttle on the network networks of 200 participants only 38 found the second flag. It was hidden in the ICMP packet data field — by-bited by echo-requests between the two hosts. The other 162 people stopped after strings evidence.pcap | grep flag and decided that the task was broken. Wireshark stood at all. The problem is not tools – the problem is the methodology: without a systematic approach to the analysis of PCAP files in Wireshark, even experienced CTF players pass flags lying at a distance of two clicks.
Next is the step-by-step methodology of PCAP analysis on CTF forensics, from the first file opening to the extraction of the flag from non-standard channels. Each reception is with specific filters, commands and an indication of where it works and where it is useless.
Requirements for the environment
Before you get into the analysis of network traffic on the CTF, check the minimum stack:
Wireshark 4.0+ (versions 3.x do not support a number of modern dissectors)
tshark – put together with Wireshark, checked through tshark -v
OS: Linux (Kali/Parrot – everything is pre-installed), macOS or Windows 10+
RAM: minimum 4 GB of free memory — Wireshark loads the entire PCAP into the RAM. The 500MB file will eat ~1.5 GB RAM
Additionally: binwalk to find embedded files, xxd or hex editor for manual carving, CyberChef (web or local version) for decoding chains of encoding
If PCAP contains TLS traffic without session keys (SSLKEYLOGFILE) or RSA private key - it is impossible to decrypt payload with Wireshark. On CTF, this is a frequent situation: look for keys in the dump itself or on the condition of the task.
Methodology of primary analysis of PCAP on CTF-tasks by forensics
A typical beginner’s mistake is to open PCAP and start leafing through the packets from top to bottom. In a dump of 50 000 packages, this is a guaranteed loss of time. You need to start with a macro-analysis: understand what happens in the capture before you dig into the details.
Protocol Hierarchy — protocol map
First action after opening a file: Statistics → Protocol Hierarchy. The table will show the percentage distribution of protocols by number of packages and data volume.
What to look at:
HTTP when dominating TLS - if 95% of traffic is encrypted, but there is 0.3% HTTP, it was there that the author of the task hid something interesting. Unprotected protocols against the background of encrypted traffic are the first priority
DNS with an abnormally high percentage – normal DNS takes 1-3% of traffic. See 10%+ — high probability of DNS exfiltration (T107.004 by MITRE ATT&CK)
ICMP of a noticeable volume – ping packages are usually minimal. If ICMP takes a substantial share of bytes, the data can be hidden in payload (T1027.003, Steganography)
Non-standard protocols – Wireshark shows “Data” for unrecognized protocols. These can be custom C2 channels or services on non-standard ports (T1571, Non-Standard Port)
Works if: PCAP is not damaged, contains complete packets (snaplen is sufficient). Does not work if: traffic is captured with trimming (tcpdump -s 96) — Protocol Hierarchy will show protocols, but payload will be incomplete.
Conversations and Endpoints – find suspicious nodes
Next step: Statistics → Conversations, TCP tab. Here you can see all the pairs of hosts and the amount of data transmitted between them.
Look for anomalies:
One host communicates with everyone – probable attack or C2 server
A large amount of data on an atypical port - 5 MB on the port 4444 (standard Metasploit handler) or 8080
Short sessions to a multitude of hosts — scan or exploration
In parallel, open Statistics → I/O Graphs – the timeline will show when there was peak activity. On the CTF, the authors often pack an “interesting” one in a short time in the middle of background noise.
Wireshark filters for forensics: from basic to advanced
Display filters are the main tool for navigating the dump. Unlike capture filters (BPF-syntax), display filters work ex post facto and allow flexible combination of conditions.
Protocol and field-based filters
Basic filters that are worth entering first on any CTF:
http – all HTTP traffic, including requests and responses
dns – DNS requests and answers
ftp || ftp-data – FTP management and file threads
smtp || pop || imap – postal protocols
tcp.port == 4444 – specific port (set up suspicious from Conversations)
ip.addr == 10.0.2.15 – filter for a specific IP
Combining through logical operators: http && ip.src == 192.168.1.100 show only HTTP requests from a particular host. Operator ! to exclude: !arp && !dns – remove the background noise of ARP and DNS.
Field-based filters for point search:
http.request.method == "POST" – only POST requests (login forms, file uploads)
http.response.code == 200 – successful answers
dns.qry.name contains "evil" – DNS requests to domains with substring
tcp.flags.syn == 1 && tcp.flags.ack == 0 – SYN without ACK (the beginning of connections, useful for scanning detection)
Search by content: effect and matches
When the flag format is known (e.g. CTF{...} or flag{...}), direct search by payload saves hours:
frame contains "flag" – search for the “flag” line anywhere in any package
tcp contains "CTF{" – search in TCP segments
http contains "password" – passwords in HTTP traffic
For regular expressions – matches: filter frame matches "flag\{[a-zA-Z0-9_]+\}" find the lines of view flag{any_content} in any protocol.
contains and matches work on raw bytes of the package. If the flag is encoded in Base64 or XOR, the filter will not find it. We'll have to do this decode with hands (about this below).
Works if: data is transmitted in the open – HTTP, FTP, Telnet, SMTP without STARTTLS. Does not work if: payload encrypted (TLS, SSH) or coded (Base64, hex, custom XOR).
Follow TCP Stream in Wireshark — Sessions recovery
Follow TCP Stream is one of the most useful features of Wireshark for CTF. It collects all the packages of a single TCP connection and shows the data in the form of a readable dialog. Right click on the package → Follow → TCP Stream (or UDP Stream for UDP).
Plaintext Protocols: FTP, HTTP, SMTP
In CTF-tasses on forensics, the authors often lay flags in the sessions of plaintext-protocols:
FTP – Follow TCP Stream on port 21 will show the login/password in the open (teams USER and PASS). But files are transmitted over a separate data connection (port 20 or passive port). You need to track both streams: the control (port 21) will tell which file was requested, and the data flow (look through Conversations for a couple of hosts on a non-standard port) contains the file itself.
HTTP – POST requests with login forms, downloading files through multipart/form-data, responses from cookies. Filter http.request.method == "POST" → Follow TCP Stream will show the sent data, including passwords and tokens.
SMTP is an open email. Follow TCP Stream will show the titles From/To/Subject and the body of the letter. Attachments are transferred to Base64 – Wireshark decodes them when exporting objects, but in Follow Stream they are visible in coded form.
Decoding data in stream
At the bottom of the Follow TCP Stream window there is a drop-down list of the display format: ASCII, EBCDIC, Hex Dump, C Arrays, Raw, UTF-8. Switching to Hex Dump is useful when an ASCII view shows “junk”—it could be a binary file or coded data.
If the ASCII stream shows a string of type Q1RGe3cxcjNzaDRya19tNHN0M3J9 This is Base64. Decoded directly in the terminal:
echo "Q1RGe3cxcjNzaDRya19tNHN0M3J9" | base64 -d
Standard coding (T1132.001 by MITRE ATT&CK) is one of the most frequent techniques on CTF forensics.
A more complex case is non-standard coding (T1132.002): hex-lines, ROT13, XOR with a single-byte key. CyberChef with Magic function automatically detects the type of encoding and offers a chain of decoding. In practice, Magic copes with 3-4 nested layers without problems, further - already with hands.
Extracting files from PCAP to Wireshark
Transferring files over the network is a standard CTF-task script. Wireshark is able to extract files from multiple protocols automatically.
Export Objects for HTTP, SMB, TFTP
File → Export Objects → HTTP — will show all files transferred via HTTP: images, documents, scripts, archives. Each object can be saved separately or all immediately through Save All.
Similarly, exports for SMB (files on Windows balls), TFTP (often found in network equipment) and IMF (Internet Message Format – attachments from email) work.
Works if: the file is transferred entirely within the capture, the protocol is supported by the Wireshark dissector. Does not work if: the transfer is interrupted (incomplete capture), the file is transmitted through a non-standard protocol or is broken into fragments in a custom format.
Manual extraction through raw data
When Export Objects does not find anything, switch to manual carving:
Find a suspicious stream through Follow TCP Stream
Switch the format to Raw and save to the file (button "Save as...")
Check through file extracted_data – utility will determine the type by magic bytes
If file shows "data" - launch binwalk extracted_data to search for nested files (ZIP archives, images, ELF-binary inside the stream)
Typical CTF scenario: HTTP response transmits a PNG image inside which through binwalk detected a ZIP archive with a text file containing the flag. The doll is a characteristic reception of the authors of the tasks.
DNS Exfiltration Analysis in CTF Network Traffic
DNS-exfiltration (T1071.004, T1041 by MITRE ATT & CK) is one of the most popular hidden channels in CTF-tasks. The data is encoded in DNS query subdomains, and the responses may contain a payload in TXT records.
Suspicious DNS requests
Filter dns in Wireshark will show all requests. Signs of Exfiltration:
Long subdomains – requests of the species 6162636465666768.evil.com, where the subdomain is hex-coded data
High frequency – dozens of requests to a single domain in seconds
TXT records – TXT-type queries are atypical for regular web surfing. Filter: dns.qry.type == 16
Unusual domains are random lines in names
For a quick review of all requested domains – Statistics → DNS. The table will show all the unique names and number of requests to each.
Decoding data from subdomains
When suspicious requests are found, the data must be collected and decoded. Here tshark is indispensable - will extract all the names of queries by one team:
tshark -r evidence.pcap -Y "dns.qry.name contains evil.com" \
-T fields -e dns.qry.name | \
cut -d'.' -f1 | tr -d '\n' | xxd -r -p
The chain extracts subdomains, trims the underlying domain, glues parts and decodes hex into ASCII. If the data is encoded in Base64 instead of hex, replace xxd -r -p on base64 -d.
If DNS requests go through DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT), Wireshark will show them as regular HTTPS/TLS traffic. Without session keys, the content of the requests is not available. On CTF it is still rare, but in tasks of increased complexity already meets.
Steganography in protocols: ICMP, HTTP headers, non-standard ports
In addition to DNS, the authors of CTF-TASKs hide data in the protocol fields, which usually do not carry user information.
ICMP data field – standard ping (echo-request/echo-reply) contains a data field where arbitrary bytes can be written over RFC. In Wireshark: filter icmp, then in the part panel expand Internet Control Message Protocol → Data. If instead of a standard pattern (alphabet or zero) you see meaningful ASCII symbols or Base64, the data is hidden by the paper in consecutive packages. Something similar does, by the way, ordinary PING - it takes customers with its ICMP echo requests, only here payload with a surprise.
Extraction via tshark: tshark -r file.pcap -Y "icmp.type == 8" -T fields -e data.data output hex-content data-field all echo-request. Glue and decode through xxd -r -p.
HTTP Headers – custom headlines like X-Flag, X-Secret or data hidden in Cookie, User-Agent, Referer. Filter http.request → view the titles of each query in the details panel. Untypically long User-Agent with random symbols – a reason to check.
Non-standard ports - service on port 31337, 1337 or any other "elite" port. Wireshark may not recognize the protocol and will show “TCP” or “Data.” Follow TCP Stream on such a stream often reveals a custom plaintext protocol with commands and answers where the flag is hidden.
Works if: the authors did not apply additional encryption on top of the steganography. It does not work if: the data in the ICMP/headers is encrypted with an XOR with a key that needs to be found elsewhere in the dump – these are multi-stage tasks that require a complete analysis of all traffic.
Automation with tshark to analyze network traffic on CTF
GUI Wireshark is handy for manual analysis, but on CTF time is limited. tshark allows you to automate routine and handle large dumps in seconds. I came to the fact that without tshark and scripting at the competition with limited time you will lose to the one who automated.
Quick search for a line in the entire dump (analog strings | grep, but with the context of the package):
tshark -r evidence.pcap -Y 'frame contains "flag"' \
-T fields -e frame.number -e ip.src -e ip.dst -e tcp.port
Show the package number, source, destination and port for each package with the line "flag". Next, open this package in Wireshark by number: Go → Go to Packet.
Extract all URLs from HTTP traffic: tshark -r file.pcap -Y "http.request" -T fields -e http.host -e http.request.uri. Suspicious ways (/upload, /admin, /shell.php) immediately catch the eye.
Extraction from FTP: credentials tshark -r file.pcap -Y "ftp.request.command == USER || ftp.request.command == PASS" -T fields -e ftp.request.arg. All logins and passwords from FTP sessions are one line.
tshark uses the same dissectors as Wireshark. If the protocol is non-standard and not recognized, tshark will not be able to extract the fields. Then work with raw data: tshark -r file.pcap -Y "tcp.port == 31337" -T fields -e tcp.payload output hex-payload, which is further decoded through xxd -r -p.
Typical traps in CTF-drags by network financials
For several hundred disassembled CTF-tasks on the network, the patterns, which even experienced players fall for:
Red herrings – the authors deliberately leave “obvious” findings to distract from the real flag. Classic: in HTTP traffic lies a file flag.txt with the text “Not so easy!” and the real flag in DNS TXT records. If the flag was found too quickly on a medium or high difficulty task - do not relax, continue to dig.
Multiple Coding Layers – The flag is coded by Base64, the result is coded in hex, the result is inserted into the UTX Cookie Header. CyberChef with Magic mode opens up to 10 nested levels automatically. Hands — decode layer by layer, checking the result of each step on readability.
Fragmented data – the flag is divided into parts, each part in a separate package (often ICMP) or in a separate DNS request. Without tshark automation, collect 50 fragments manually – painfully.
The encryption keys inside the dump – if a significant part of the traffic is encrypted by TLS, check whether there is no file with an extension in HTTP traffic .key, .pem or sslkeylog.txt. The authors of CTF assignments sometimes “accidentally” leave the keys in an unencrypted session. Import the found key through Edit → Preferences → Protocols → TLS → (Pre)-Master-Secret log filename – and the encrypted traffic will be readable.
False attribution of protocols is an HTTP server on port 53 (standard DNS) or DNS tunnel on port 80. Wireshark links the dissector to the default port and may misinterpret traffic. If the content looks incorrect for the stated protocol, the right click → Decode As... → select the correct dissector manually.
The methodology, which works steadily on forensics CTFs of any level, fits into four stages: macro-analysis (Protocol Hierarchy, Conversations, I/O Graphs) → filtering suspicious (display filters by protocols and contents) → deep analysis of streams (Follow TCP/UDP Stream, Export Objects) → decoding and building. Passing any stage is the loss of flags.
Next is the step-by-step methodology of PCAP analysis on CTF forensics, from the first file opening to the extraction of the flag from non-standard channels. Each reception is with specific filters, commands and an indication of where it works and where it is useless.
Requirements for the environment
Before you get into the analysis of network traffic on the CTF, check the minimum stack:
Wireshark 4.0+ (versions 3.x do not support a number of modern dissectors)
tshark – put together with Wireshark, checked through tshark -v
OS: Linux (Kali/Parrot – everything is pre-installed), macOS or Windows 10+
RAM: minimum 4 GB of free memory — Wireshark loads the entire PCAP into the RAM. The 500MB file will eat ~1.5 GB RAM
Additionally: binwalk to find embedded files, xxd or hex editor for manual carving, CyberChef (web or local version) for decoding chains of encoding
If PCAP contains TLS traffic without session keys (SSLKEYLOGFILE) or RSA private key - it is impossible to decrypt payload with Wireshark. On CTF, this is a frequent situation: look for keys in the dump itself or on the condition of the task.
Methodology of primary analysis of PCAP on CTF-tasks by forensics
A typical beginner’s mistake is to open PCAP and start leafing through the packets from top to bottom. In a dump of 50 000 packages, this is a guaranteed loss of time. You need to start with a macro-analysis: understand what happens in the capture before you dig into the details.
Protocol Hierarchy — protocol map
First action after opening a file: Statistics → Protocol Hierarchy. The table will show the percentage distribution of protocols by number of packages and data volume.
What to look at:
HTTP when dominating TLS - if 95% of traffic is encrypted, but there is 0.3% HTTP, it was there that the author of the task hid something interesting. Unprotected protocols against the background of encrypted traffic are the first priority
DNS with an abnormally high percentage – normal DNS takes 1-3% of traffic. See 10%+ — high probability of DNS exfiltration (T107.004 by MITRE ATT&CK)
ICMP of a noticeable volume – ping packages are usually minimal. If ICMP takes a substantial share of bytes, the data can be hidden in payload (T1027.003, Steganography)
Non-standard protocols – Wireshark shows “Data” for unrecognized protocols. These can be custom C2 channels or services on non-standard ports (T1571, Non-Standard Port)
Works if: PCAP is not damaged, contains complete packets (snaplen is sufficient). Does not work if: traffic is captured with trimming (tcpdump -s 96) — Protocol Hierarchy will show protocols, but payload will be incomplete.
Conversations and Endpoints – find suspicious nodes
Next step: Statistics → Conversations, TCP tab. Here you can see all the pairs of hosts and the amount of data transmitted between them.
Look for anomalies:
One host communicates with everyone – probable attack or C2 server
A large amount of data on an atypical port - 5 MB on the port 4444 (standard Metasploit handler) or 8080
Short sessions to a multitude of hosts — scan or exploration
In parallel, open Statistics → I/O Graphs – the timeline will show when there was peak activity. On the CTF, the authors often pack an “interesting” one in a short time in the middle of background noise.
Wireshark filters for forensics: from basic to advanced
Display filters are the main tool for navigating the dump. Unlike capture filters (BPF-syntax), display filters work ex post facto and allow flexible combination of conditions.
Protocol and field-based filters
Basic filters that are worth entering first on any CTF:
http – all HTTP traffic, including requests and responses
dns – DNS requests and answers
ftp || ftp-data – FTP management and file threads
smtp || pop || imap – postal protocols
tcp.port == 4444 – specific port (set up suspicious from Conversations)
ip.addr == 10.0.2.15 – filter for a specific IP
Combining through logical operators: http && ip.src == 192.168.1.100 show only HTTP requests from a particular host. Operator ! to exclude: !arp && !dns – remove the background noise of ARP and DNS.
Field-based filters for point search:
http.request.method == "POST" – only POST requests (login forms, file uploads)
http.response.code == 200 – successful answers
dns.qry.name contains "evil" – DNS requests to domains with substring
tcp.flags.syn == 1 && tcp.flags.ack == 0 – SYN without ACK (the beginning of connections, useful for scanning detection)
Search by content: effect and matches
When the flag format is known (e.g. CTF{...} or flag{...}), direct search by payload saves hours:
frame contains "flag" – search for the “flag” line anywhere in any package
tcp contains "CTF{" – search in TCP segments
http contains "password" – passwords in HTTP traffic
For regular expressions – matches: filter frame matches "flag\{[a-zA-Z0-9_]+\}" find the lines of view flag{any_content} in any protocol.
contains and matches work on raw bytes of the package. If the flag is encoded in Base64 or XOR, the filter will not find it. We'll have to do this decode with hands (about this below).
Works if: data is transmitted in the open – HTTP, FTP, Telnet, SMTP without STARTTLS. Does not work if: payload encrypted (TLS, SSH) or coded (Base64, hex, custom XOR).
Follow TCP Stream in Wireshark — Sessions recovery
Follow TCP Stream is one of the most useful features of Wireshark for CTF. It collects all the packages of a single TCP connection and shows the data in the form of a readable dialog. Right click on the package → Follow → TCP Stream (or UDP Stream for UDP).
Plaintext Protocols: FTP, HTTP, SMTP
In CTF-tasses on forensics, the authors often lay flags in the sessions of plaintext-protocols:
FTP – Follow TCP Stream on port 21 will show the login/password in the open (teams USER and PASS). But files are transmitted over a separate data connection (port 20 or passive port). You need to track both streams: the control (port 21) will tell which file was requested, and the data flow (look through Conversations for a couple of hosts on a non-standard port) contains the file itself.
HTTP – POST requests with login forms, downloading files through multipart/form-data, responses from cookies. Filter http.request.method == "POST" → Follow TCP Stream will show the sent data, including passwords and tokens.
SMTP is an open email. Follow TCP Stream will show the titles From/To/Subject and the body of the letter. Attachments are transferred to Base64 – Wireshark decodes them when exporting objects, but in Follow Stream they are visible in coded form.
Decoding data in stream
At the bottom of the Follow TCP Stream window there is a drop-down list of the display format: ASCII, EBCDIC, Hex Dump, C Arrays, Raw, UTF-8. Switching to Hex Dump is useful when an ASCII view shows “junk”—it could be a binary file or coded data.
If the ASCII stream shows a string of type Q1RGe3cxcjNzaDRya19tNHN0M3J9 This is Base64. Decoded directly in the terminal:
echo "Q1RGe3cxcjNzaDRya19tNHN0M3J9" | base64 -d
Standard coding (T1132.001 by MITRE ATT&CK) is one of the most frequent techniques on CTF forensics.
A more complex case is non-standard coding (T1132.002): hex-lines, ROT13, XOR with a single-byte key. CyberChef with Magic function automatically detects the type of encoding and offers a chain of decoding. In practice, Magic copes with 3-4 nested layers without problems, further - already with hands.
Extracting files from PCAP to Wireshark
Transferring files over the network is a standard CTF-task script. Wireshark is able to extract files from multiple protocols automatically.
Export Objects for HTTP, SMB, TFTP
File → Export Objects → HTTP — will show all files transferred via HTTP: images, documents, scripts, archives. Each object can be saved separately or all immediately through Save All.
Similarly, exports for SMB (files on Windows balls), TFTP (often found in network equipment) and IMF (Internet Message Format – attachments from email) work.
Works if: the file is transferred entirely within the capture, the protocol is supported by the Wireshark dissector. Does not work if: the transfer is interrupted (incomplete capture), the file is transmitted through a non-standard protocol or is broken into fragments in a custom format.
Manual extraction through raw data
When Export Objects does not find anything, switch to manual carving:
Find a suspicious stream through Follow TCP Stream
Switch the format to Raw and save to the file (button "Save as...")
Check through file extracted_data – utility will determine the type by magic bytes
If file shows "data" - launch binwalk extracted_data to search for nested files (ZIP archives, images, ELF-binary inside the stream)
Typical CTF scenario: HTTP response transmits a PNG image inside which through binwalk detected a ZIP archive with a text file containing the flag. The doll is a characteristic reception of the authors of the tasks.
DNS Exfiltration Analysis in CTF Network Traffic
DNS-exfiltration (T1071.004, T1041 by MITRE ATT & CK) is one of the most popular hidden channels in CTF-tasks. The data is encoded in DNS query subdomains, and the responses may contain a payload in TXT records.
Suspicious DNS requests
Filter dns in Wireshark will show all requests. Signs of Exfiltration:
Long subdomains – requests of the species 6162636465666768.evil.com, where the subdomain is hex-coded data
High frequency – dozens of requests to a single domain in seconds
TXT records – TXT-type queries are atypical for regular web surfing. Filter: dns.qry.type == 16
Unusual domains are random lines in names
For a quick review of all requested domains – Statistics → DNS. The table will show all the unique names and number of requests to each.
Decoding data from subdomains
When suspicious requests are found, the data must be collected and decoded. Here tshark is indispensable - will extract all the names of queries by one team:
tshark -r evidence.pcap -Y "dns.qry.name contains evil.com" \
-T fields -e dns.qry.name | \
cut -d'.' -f1 | tr -d '\n' | xxd -r -p
The chain extracts subdomains, trims the underlying domain, glues parts and decodes hex into ASCII. If the data is encoded in Base64 instead of hex, replace xxd -r -p on base64 -d.
If DNS requests go through DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT), Wireshark will show them as regular HTTPS/TLS traffic. Without session keys, the content of the requests is not available. On CTF it is still rare, but in tasks of increased complexity already meets.
Steganography in protocols: ICMP, HTTP headers, non-standard ports
In addition to DNS, the authors of CTF-TASKs hide data in the protocol fields, which usually do not carry user information.
ICMP data field – standard ping (echo-request/echo-reply) contains a data field where arbitrary bytes can be written over RFC. In Wireshark: filter icmp, then in the part panel expand Internet Control Message Protocol → Data. If instead of a standard pattern (alphabet or zero) you see meaningful ASCII symbols or Base64, the data is hidden by the paper in consecutive packages. Something similar does, by the way, ordinary PING - it takes customers with its ICMP echo requests, only here payload with a surprise.
Extraction via tshark: tshark -r file.pcap -Y "icmp.type == 8" -T fields -e data.data output hex-content data-field all echo-request. Glue and decode through xxd -r -p.
HTTP Headers – custom headlines like X-Flag, X-Secret or data hidden in Cookie, User-Agent, Referer. Filter http.request → view the titles of each query in the details panel. Untypically long User-Agent with random symbols – a reason to check.
Non-standard ports - service on port 31337, 1337 or any other "elite" port. Wireshark may not recognize the protocol and will show “TCP” or “Data.” Follow TCP Stream on such a stream often reveals a custom plaintext protocol with commands and answers where the flag is hidden.
Works if: the authors did not apply additional encryption on top of the steganography. It does not work if: the data in the ICMP/headers is encrypted with an XOR with a key that needs to be found elsewhere in the dump – these are multi-stage tasks that require a complete analysis of all traffic.
Automation with tshark to analyze network traffic on CTF
GUI Wireshark is handy for manual analysis, but on CTF time is limited. tshark allows you to automate routine and handle large dumps in seconds. I came to the fact that without tshark and scripting at the competition with limited time you will lose to the one who automated.
Quick search for a line in the entire dump (analog strings | grep, but with the context of the package):
tshark -r evidence.pcap -Y 'frame contains "flag"' \
-T fields -e frame.number -e ip.src -e ip.dst -e tcp.port
Show the package number, source, destination and port for each package with the line "flag". Next, open this package in Wireshark by number: Go → Go to Packet.
Extract all URLs from HTTP traffic: tshark -r file.pcap -Y "http.request" -T fields -e http.host -e http.request.uri. Suspicious ways (/upload, /admin, /shell.php) immediately catch the eye.
Extraction from FTP: credentials tshark -r file.pcap -Y "ftp.request.command == USER || ftp.request.command == PASS" -T fields -e ftp.request.arg. All logins and passwords from FTP sessions are one line.
tshark uses the same dissectors as Wireshark. If the protocol is non-standard and not recognized, tshark will not be able to extract the fields. Then work with raw data: tshark -r file.pcap -Y "tcp.port == 31337" -T fields -e tcp.payload output hex-payload, which is further decoded through xxd -r -p.
Typical traps in CTF-drags by network financials
For several hundred disassembled CTF-tasks on the network, the patterns, which even experienced players fall for:
Red herrings – the authors deliberately leave “obvious” findings to distract from the real flag. Classic: in HTTP traffic lies a file flag.txt with the text “Not so easy!” and the real flag in DNS TXT records. If the flag was found too quickly on a medium or high difficulty task - do not relax, continue to dig.
Multiple Coding Layers – The flag is coded by Base64, the result is coded in hex, the result is inserted into the UTX Cookie Header. CyberChef with Magic mode opens up to 10 nested levels automatically. Hands — decode layer by layer, checking the result of each step on readability.
Fragmented data – the flag is divided into parts, each part in a separate package (often ICMP) or in a separate DNS request. Without tshark automation, collect 50 fragments manually – painfully.
The encryption keys inside the dump – if a significant part of the traffic is encrypted by TLS, check whether there is no file with an extension in HTTP traffic .key, .pem or sslkeylog.txt. The authors of CTF assignments sometimes “accidentally” leave the keys in an unencrypted session. Import the found key through Edit → Preferences → Protocols → TLS → (Pre)-Master-Secret log filename – and the encrypted traffic will be readable.
False attribution of protocols is an HTTP server on port 53 (standard DNS) or DNS tunnel on port 80. Wireshark links the dissector to the default port and may misinterpret traffic. If the content looks incorrect for the stated protocol, the right click → Decode As... → select the correct dissector manually.
The methodology, which works steadily on forensics CTFs of any level, fits into four stages: macro-analysis (Protocol Hierarchy, Conversations, I/O Graphs) → filtering suspicious (display filters by protocols and contents) → deep analysis of streams (Follow TCP/UDP Stream, Export Objects) → decoding and building. Passing any stage is the loss of flags.
CC
CC
CC
CC
CC
CC
