For the last two years, I've been collecting pcap assignments for CTFs and on each parse, I observe one picture: participants open the file and leaf the packets from top to bottom. On a dump of 50 thousand packages, it takes half an hour and gives zero result. And after all Statistics → Protocol Hierarchy in ten seconds will show that 90% of the traffic is TLS, and the flag is hidden in the remaining two to three percent of open HTTP or DNS. The whole difference between zero points and a solved daching is in order of action. Below is a step-by-step algorithm for analyzing a pcap file in Wireshark that runs on PicoCTF, CyberDefenders, HackTheBox, and any other site.
Environment requirements and tools
Before disassembling the pcap, make sure the workplace is assembled.
Minimum set:
Wireshark 4.x – the latest stable version with GUI, downloaded from wireshark.org. Windows, Linux, macOS. On Ubuntu/Debian is put by the team sudo apt install wireshark.
tshark is a console analyzer from the same distribution, placed automatically together with GUI. On a file of 500 MB, GUI will be suffocating, tshark will work in the stream - for large dumps and automation, it is indispensable.
CyberChef is a web-based decoding application (Base64, hex, ROT13, XOR and another fifty operations). Works right in the browser, you do not need to put anything. Required on every second CTF assignment.
File, strings, grep Standard Linux utilities. For Windows – WSL or Cygwin. file determines the type of file extracted by magic bytes (even if the extension lies), strings pulls text strings out of the binary, grep filters the result.
Optional:
NetworkMiner – automatically reconstructs files and credentials from the pcap. But on traffic with loopback-interface works crooked – keep in mind.
tcpdump – interception and rough filtering in the console. For CTF you need rarely (the file is already recorded), but sometimes tasks require you to remove your own dump.
RAM: for files up to 100 MB will suffice 4 GB. For dumps 500 MB+ you need 8-16 GB - Wireshark loads pcap entirely in memory. On a 4 GB machine, switch to tshark, it works streaming.
Primary exploration of pcap: Protocol Hierarchy and Conversations
Opened the file - do not touch the list of packages. Give the first five minutes to the intelligence. The goal: to understand what protocols were used, who communicated with whom and where to look for anomalies.
Protocol Hierarchy – traffic map in 10 seconds
Menu Statistics → Protocol Hierarchy shows the percentage distribution of protocols by number of packets and data volume. This is the first thing to open – it determines where to spend time and what to attribute to background noise.
What to look at:
Share of TLS/SSL. If more than 80-90% - the bulk of the content is not available without a decryption key. You need to dig in the remaining unencrypted traffic.
presence of HTTP. Even 0.3% HTTP in the dump can contain a flag. The authors of the CTF love to hide the data in the only HTTP request among the tons of TLS. In the real analysis of evidence.pcap with CyberDefenders-shuttle EscapeRoom exactly 0.3% HTTP contained everything interesting: User-Agent, POST parameters, downloaded files.
DNS. If the share of DNS packets is abnormally large (15-20% and above) is a bell: DNS exfiltration, C2 channel technique (T1071.004), which in practice is also used for data output (T1048, Exfiltration Overration Alternative Protocol). This vector is constantly operated on the CTF.
Non-standard protocols. FTP, SMTP, Telnet — credentials fly in the open. The classic case of OWASP A02:2021 (Cryptographic Failures): no encryption — credentials are compromised.
Data or Unknown. Traffic that Wireshark could not identify. Often behind this are cluster protocols or data on non-standard ports - to disassemble hands through Decode As.
Conversations and Endpoints – Who Talks To Anyone
Statistics → Conversations (TCP tab, sort bytes) shows all pairs of interacting hosts. The second step of intelligence.
What to look for:
Abnormally “thick” sessions. One TCP session transmitted an order of magnitude more data than the rest – take it first.
Non-standard ports. 4444 (Metasploit reverse shell), 8080 (proxy/debug server), 666, 1337 - classic CTF-markers. In the analysis of THM Wireshark CTF one of the flags hid in the TCP-stream on the port 666.
A lot of short sessions from one IP. A sign of brute-force or port scanning. In the EscapeRoom-disassembly of 52 short TCP sessions with a small amount of data from the server were unsuccessful attempts of SSH authentication (category #22 SSH on AbuseIPDB), and two “thick” sessions – successful.
One external IP that initiates hundreds of connections inside. An anomaly worth disassembling.
Statistics → Endpoints complements the picture: the volume of traffic immediately allocates the “central” host, around which the task scenario is built.
Still useful thing: Statistics → I/O Graphs visualizes traffic intensity on the timeline. A burst of activity at a particular moment is often the point of the beginning of an attack or data transfer. On CTF, it helps to narrow down the time window for manual analysis.
Limitation: Protocol Hierarchy and Conversations show only statistics, not the content of packets. It is a tool for answering “where to dig” rather than to search for the flag directly. After exploration, we turn to filtration.
Wireshark filters for CTF: cheat sheet with examples
Display filters are the main tool for navigating the dump when analyzing CTF network traffic. Without them, the pcap with thousands of packages turns into a lottery. Filters are entered into the line at the top of the window and applied to Enter.
Protocol and Address Filters
Filters are combined by operators: && (And) || (OR) ! (NOT). Example: http && ip.src == 10.0.2.15 show HTTP traffic from a particular host. Combination tcp.flags.syn == 1 && tcp.flags.ack == 0 filters out only initiating SYN packets – convenient to see all connection installation attempts and quickly find an interesting flow. In the review of see-through.pcapng, the fourth SYN package led to the flow with the flag.
Search for flag by content of packages
When the flag format is known (e.g. CTF{...} or flag{...}), the search for content is the fastest way:
frame contains "flag" – looking for a line in the entire frame, including payload and titles
http contains "CTF{" – searches only in HTTP packages
tcp contains "password" – passwords in TCP-stream
dns.qry.name contains "suspicious" – substring in DNS requests
For regular expressions, the operator matches: filter http.request.uri matches ".*\\.php" will show all requests to PHP scripts, and dns.qry.name matches "^[a-f0-9]{10,}\\." will identify DNS queries with long hex lines in subdomains – a typical sign of DNS exfiltration.
If the flag format is unknown – sort over: frame contains "flag", then frame contains "key", frame contains "secret", frame contains "pass". On the entry-level CTF, the flag is in the open – in about half of the tasks.
Restriction: Content filters only work with unencrypted traffic. If HTTP is wrapped in TLS, frame contains will show unreadable trash. You need a decryption key, that's below.
Follow Stream: Restore the dialog between hosts
Follow TCP Stream is a thing without which there is nothing to do on the CTF. It collects all the packages of one TCP session into a single readable stream: red text is data from the client, blue is from the server.
Right click on any package of the session of interest → Follow → TCP Stream. At the bottom of the navigation button window: Stream 0, Stream 1, Stream 2 and beyond. On the CTF of the initial-average level of flows is usually a little - it is worth to view each.
Typical Finds in TCP Stream:
FTP Sessions – teams USER and PASS are in plain text. In terms of MITRE ATT&CK – Network Sniffing (T1040, Credential Access): Interception of credentials from unencrypted traffic. According to IBM X-Force (2025), every day more than 6 000 new accounts appear in the dark web - and sniffing unencrypted protocols like FTP here is one of the sources.
HTTP POST – contents of forms, credentials, downloaded files.
Plaintext commands – if the attacker used the reverse shell without encryption, all commands are visible in the stream. Like in the palm.
Coded strings — Base64-sequences, hex, URL-encoding.
About UDP — the moment that beginners consistently miss. Follow → UDP Stream mandatory step. The authors of the CTF use this: the flag or audio data is transmitted by UDP on non-standard ports. In the analysis of THM Wireshark CTF, the RTP audio stream was disguised as an unknown UDP protocol on port 1313. Solution: right click on package → Decode As → selection of the RTP protocol – after which Telephony → RTP → RTP Streams allowed to lose the audio and hear the flag.
Decode As It is worth keeping in mind as a lifeline: if Wireshark does not recognize the protocol on a non-standard port, try to force the appointment of HTTP, FTP, RTP or other expected protocol. Without this reception, some of the data will remain invisible.
The authors of the CTF like to combine coding: Base64 on top of the ROT13 on top of Caesar with a shift 3. CyberChef decides this elegantly - dragging the operations sequentially into the recipe chain, the result will be updated automatically.
Example from THM Wireshark CTF. In the first task, Follow TCP Stream shows a Python triple-encoding script (ROT13, Base64, Caesar cipher with shift 3). Variable cnt in code installed in ? – replace with 50. To get the flag, you need to reverse the coding functions: b64encode replace by b64decode, in Caesar-function change the shift with 3 on -3, ROT13 leave as is (it is symmetrical). Without understanding the order of operations, the task looks unsolved – with CyberChef and understanding the structure of the script is solved in five minutes.
Extracting files from pcap through Export Objects
One of the most frequent CTF scenarios: the flag is hidden inside the image, PDF, archive or executable file transmitted over the network. According to ATT&CK, this is the intersection of Data from Local System (T1005) and Exfiltration Over C2 Channel (T1041) – the attacker collected data and transferred them over the network, and we need to restore them.
The Way File → Export Objects → HTTP opens a list of all files transferred by HTTP: images, scripts, documents, binary. Similar menus are available for SMB, TFTP and email attachments (IMFs).
Algorithm after extraction:
Determine file type: file <filename>. The command reads magic bytes – even if the extension is incorrect or missing, the real type will be determined. In the EscapeRoom analysis, three files were extracted through Export Objects → HTTP - two ELF-binary and shell-script identified by magic bytes.
Search for text lines: strings <filename> | grep -i flag. Often the flag is lied inside the binary file as a normal string.
If the file is an image, check the metadata through exiftool and steganography through steghide (for JPEG) or zsteg (for PNG). The password for steganography can be found in another stream of the same pcap.
If the file is an archive, try to unpack. Password to the archive is often a separate CTF task element hidden in an HTTP header, a DNS request, or an FTP session.
When Export Objects is not working. If the file is transmitted over a non-standard protocol or fragmented atypical, use Follow TCP Stream, switch the display to Raw, save the stream to the file and trim the protocol headers manually. The method is rough, but on the CTF is sometimes the only worker.
DNS exfiltration: how to find the flag in DNS queries
DNS exfiltration is a technique in which data is encoded in DNS query subdomains. Instead of the usual google.com request looks like 4354467b646e735f.evil.com, where the hex line in the subdomain is the coded payload. According to MITRE ATT&CK, it is a DNS C2 channel (T1071.004) with exfiltration through it (T1041), or – if DNS is used as a separate output channel – Exfiltration Over Alternative Protocol (T1048). The authors of the CTF exploit this vector constantly: DNS traffic is rarely blocked and almost never encrypted in training scenarios.
Signs of DNS exfiltration in pcap:
Abnormally high share of DNS packets in Protocol Hierarchy (15-20% and above in the absence of other explanations)
DNS queries with long subdomains containing hex or Base64 symbols
Many TXT records – the TXT type is often used to transfer data back to the client
Requests to the same domain with constantly changing subdomains
Filters for detection:
dns.qry.name matches "^[a-f0-9]{10,}\\." – DNS queries with long hex strings in subdomains
dns.qry.type == 16 – only TXT records
dns.flags.response == 0 – only requests, no answers
After detecting suspicious DNS requests, you need to remove the subdomains and glue. Here tshark is more effective than GUI:
tshark -r evidence.pcap -Y "dns.qry.name contains evil.com" \
-T fields -e frame.number -e dns.qry.name | \
sort -n | cut -f2 | awk -F. '{print $1}' | tr -d '\n'
awk -F. '{for(i=1;i<NF-1;i++) printf $i}'
The team extracts all DNS requests to the domain, cuts the first subdomain from each and glues the result. The resulting line is in CyberChef: From Hex or From Base64 depending on the encoding.
Preconditions: the detection technique only works if the DNS traffic is not encrypted (no DoH/DoT). On the CTF, almost always so. In real-world incidents, DNS over HTTPS will render this approach useless – an interception at the DNS level will be required.
Decryption of TLS traffic in Wireshark
If 90% of the traffic is TLS, and the flag is transferred over HTTPS, you can not do without a decryption key. On the CTF, the authors sometimes give the key a separate file.
Two key formats:
Pre-master secret log – file with records CLIENT_RANDOM <hex> <hex>. Connected through Edit → Preferences → Protocols → TLS → (Pre)-Master-Secret log filename. Works with any type of key exchange.
Server Private Key – RSA private key in PEM. Connected through Edit → Preferences → Protocols → TLS → RSA keys list. Works only with RSA key exchange – not with ECDHE. This is an important moment.
After downloading the key, Wireshark decrypts the TLS sessions automatically. In Protocol Hierarchy appear HTTP/2 or HTTP/1.1 inside the former TLS — further standard parsing through filters and Follow Stream.
Where to look for the key in the task:
Separate file .key or .log in the archive with pcap
Inside the pcap itself, the key is transferred via SMTP or FTP (in THM Wireshark CTF CLIENT_RANDOM, the key lay in the email on port 25)
In the description of the task — CLIENT_RANDOM line is inserted directly into the text of the condition
Environment requirements and tools
Before disassembling the pcap, make sure the workplace is assembled.
Minimum set:
Wireshark 4.x – the latest stable version with GUI, downloaded from wireshark.org. Windows, Linux, macOS. On Ubuntu/Debian is put by the team sudo apt install wireshark.
tshark is a console analyzer from the same distribution, placed automatically together with GUI. On a file of 500 MB, GUI will be suffocating, tshark will work in the stream - for large dumps and automation, it is indispensable.
CyberChef is a web-based decoding application (Base64, hex, ROT13, XOR and another fifty operations). Works right in the browser, you do not need to put anything. Required on every second CTF assignment.
File, strings, grep Standard Linux utilities. For Windows – WSL or Cygwin. file determines the type of file extracted by magic bytes (even if the extension lies), strings pulls text strings out of the binary, grep filters the result.
Optional:
NetworkMiner – automatically reconstructs files and credentials from the pcap. But on traffic with loopback-interface works crooked – keep in mind.
tcpdump – interception and rough filtering in the console. For CTF you need rarely (the file is already recorded), but sometimes tasks require you to remove your own dump.
RAM: for files up to 100 MB will suffice 4 GB. For dumps 500 MB+ you need 8-16 GB - Wireshark loads pcap entirely in memory. On a 4 GB machine, switch to tshark, it works streaming.
Primary exploration of pcap: Protocol Hierarchy and Conversations
Opened the file - do not touch the list of packages. Give the first five minutes to the intelligence. The goal: to understand what protocols were used, who communicated with whom and where to look for anomalies.
Protocol Hierarchy – traffic map in 10 seconds
Menu Statistics → Protocol Hierarchy shows the percentage distribution of protocols by number of packets and data volume. This is the first thing to open – it determines where to spend time and what to attribute to background noise.
What to look at:
Share of TLS/SSL. If more than 80-90% - the bulk of the content is not available without a decryption key. You need to dig in the remaining unencrypted traffic.
presence of HTTP. Even 0.3% HTTP in the dump can contain a flag. The authors of the CTF love to hide the data in the only HTTP request among the tons of TLS. In the real analysis of evidence.pcap with CyberDefenders-shuttle EscapeRoom exactly 0.3% HTTP contained everything interesting: User-Agent, POST parameters, downloaded files.
DNS. If the share of DNS packets is abnormally large (15-20% and above) is a bell: DNS exfiltration, C2 channel technique (T1071.004), which in practice is also used for data output (T1048, Exfiltration Overration Alternative Protocol). This vector is constantly operated on the CTF.
Non-standard protocols. FTP, SMTP, Telnet — credentials fly in the open. The classic case of OWASP A02:2021 (Cryptographic Failures): no encryption — credentials are compromised.
Data or Unknown. Traffic that Wireshark could not identify. Often behind this are cluster protocols or data on non-standard ports - to disassemble hands through Decode As.
Conversations and Endpoints – Who Talks To Anyone
Statistics → Conversations (TCP tab, sort bytes) shows all pairs of interacting hosts. The second step of intelligence.
What to look for:
Abnormally “thick” sessions. One TCP session transmitted an order of magnitude more data than the rest – take it first.
Non-standard ports. 4444 (Metasploit reverse shell), 8080 (proxy/debug server), 666, 1337 - classic CTF-markers. In the analysis of THM Wireshark CTF one of the flags hid in the TCP-stream on the port 666.
A lot of short sessions from one IP. A sign of brute-force or port scanning. In the EscapeRoom-disassembly of 52 short TCP sessions with a small amount of data from the server were unsuccessful attempts of SSH authentication (category #22 SSH on AbuseIPDB), and two “thick” sessions – successful.
One external IP that initiates hundreds of connections inside. An anomaly worth disassembling.
Statistics → Endpoints complements the picture: the volume of traffic immediately allocates the “central” host, around which the task scenario is built.
Still useful thing: Statistics → I/O Graphs visualizes traffic intensity on the timeline. A burst of activity at a particular moment is often the point of the beginning of an attack or data transfer. On CTF, it helps to narrow down the time window for manual analysis.
Limitation: Protocol Hierarchy and Conversations show only statistics, not the content of packets. It is a tool for answering “where to dig” rather than to search for the flag directly. After exploration, we turn to filtration.
Wireshark filters for CTF: cheat sheet with examples
Display filters are the main tool for navigating the dump when analyzing CTF network traffic. Without them, the pcap with thousands of packages turns into a lottery. Filters are entered into the line at the top of the window and applied to Enter.
Protocol and Address Filters
Filters are combined by operators: && (And) || (OR) ! (NOT). Example: http && ip.src == 10.0.2.15 show HTTP traffic from a particular host. Combination tcp.flags.syn == 1 && tcp.flags.ack == 0 filters out only initiating SYN packets – convenient to see all connection installation attempts and quickly find an interesting flow. In the review of see-through.pcapng, the fourth SYN package led to the flow with the flag.
Search for flag by content of packages
When the flag format is known (e.g. CTF{...} or flag{...}), the search for content is the fastest way:
frame contains "flag" – looking for a line in the entire frame, including payload and titles
http contains "CTF{" – searches only in HTTP packages
tcp contains "password" – passwords in TCP-stream
dns.qry.name contains "suspicious" – substring in DNS requests
For regular expressions, the operator matches: filter http.request.uri matches ".*\\.php" will show all requests to PHP scripts, and dns.qry.name matches "^[a-f0-9]{10,}\\." will identify DNS queries with long hex lines in subdomains – a typical sign of DNS exfiltration.
If the flag format is unknown – sort over: frame contains "flag", then frame contains "key", frame contains "secret", frame contains "pass". On the entry-level CTF, the flag is in the open – in about half of the tasks.
Restriction: Content filters only work with unencrypted traffic. If HTTP is wrapped in TLS, frame contains will show unreadable trash. You need a decryption key, that's below.
Follow Stream: Restore the dialog between hosts
Follow TCP Stream is a thing without which there is nothing to do on the CTF. It collects all the packages of one TCP session into a single readable stream: red text is data from the client, blue is from the server.
Right click on any package of the session of interest → Follow → TCP Stream. At the bottom of the navigation button window: Stream 0, Stream 1, Stream 2 and beyond. On the CTF of the initial-average level of flows is usually a little - it is worth to view each.
Typical Finds in TCP Stream:
FTP Sessions – teams USER and PASS are in plain text. In terms of MITRE ATT&CK – Network Sniffing (T1040, Credential Access): Interception of credentials from unencrypted traffic. According to IBM X-Force (2025), every day more than 6 000 new accounts appear in the dark web - and sniffing unencrypted protocols like FTP here is one of the sources.
HTTP POST – contents of forms, credentials, downloaded files.
Plaintext commands – if the attacker used the reverse shell without encryption, all commands are visible in the stream. Like in the palm.
Coded strings — Base64-sequences, hex, URL-encoding.
About UDP — the moment that beginners consistently miss. Follow → UDP Stream mandatory step. The authors of the CTF use this: the flag or audio data is transmitted by UDP on non-standard ports. In the analysis of THM Wireshark CTF, the RTP audio stream was disguised as an unknown UDP protocol on port 1313. Solution: right click on package → Decode As → selection of the RTP protocol – after which Telephony → RTP → RTP Streams allowed to lose the audio and hear the flag.
Decode As It is worth keeping in mind as a lifeline: if Wireshark does not recognize the protocol on a non-standard port, try to force the appointment of HTTP, FTP, RTP or other expected protocol. Without this reception, some of the data will remain invisible.
The authors of the CTF like to combine coding: Base64 on top of the ROT13 on top of Caesar with a shift 3. CyberChef decides this elegantly - dragging the operations sequentially into the recipe chain, the result will be updated automatically.
Example from THM Wireshark CTF. In the first task, Follow TCP Stream shows a Python triple-encoding script (ROT13, Base64, Caesar cipher with shift 3). Variable cnt in code installed in ? – replace with 50. To get the flag, you need to reverse the coding functions: b64encode replace by b64decode, in Caesar-function change the shift with 3 on -3, ROT13 leave as is (it is symmetrical). Without understanding the order of operations, the task looks unsolved – with CyberChef and understanding the structure of the script is solved in five minutes.
Extracting files from pcap through Export Objects
One of the most frequent CTF scenarios: the flag is hidden inside the image, PDF, archive or executable file transmitted over the network. According to ATT&CK, this is the intersection of Data from Local System (T1005) and Exfiltration Over C2 Channel (T1041) – the attacker collected data and transferred them over the network, and we need to restore them.
The Way File → Export Objects → HTTP opens a list of all files transferred by HTTP: images, scripts, documents, binary. Similar menus are available for SMB, TFTP and email attachments (IMFs).
Algorithm after extraction:
Determine file type: file <filename>. The command reads magic bytes – even if the extension is incorrect or missing, the real type will be determined. In the EscapeRoom analysis, three files were extracted through Export Objects → HTTP - two ELF-binary and shell-script identified by magic bytes.
Search for text lines: strings <filename> | grep -i flag. Often the flag is lied inside the binary file as a normal string.
If the file is an image, check the metadata through exiftool and steganography through steghide (for JPEG) or zsteg (for PNG). The password for steganography can be found in another stream of the same pcap.
If the file is an archive, try to unpack. Password to the archive is often a separate CTF task element hidden in an HTTP header, a DNS request, or an FTP session.
When Export Objects is not working. If the file is transmitted over a non-standard protocol or fragmented atypical, use Follow TCP Stream, switch the display to Raw, save the stream to the file and trim the protocol headers manually. The method is rough, but on the CTF is sometimes the only worker.
DNS exfiltration: how to find the flag in DNS queries
DNS exfiltration is a technique in which data is encoded in DNS query subdomains. Instead of the usual google.com request looks like 4354467b646e735f.evil.com, where the hex line in the subdomain is the coded payload. According to MITRE ATT&CK, it is a DNS C2 channel (T1071.004) with exfiltration through it (T1041), or – if DNS is used as a separate output channel – Exfiltration Over Alternative Protocol (T1048). The authors of the CTF exploit this vector constantly: DNS traffic is rarely blocked and almost never encrypted in training scenarios.
Signs of DNS exfiltration in pcap:
Abnormally high share of DNS packets in Protocol Hierarchy (15-20% and above in the absence of other explanations)
DNS queries with long subdomains containing hex or Base64 symbols
Many TXT records – the TXT type is often used to transfer data back to the client
Requests to the same domain with constantly changing subdomains
Filters for detection:
dns.qry.name matches "^[a-f0-9]{10,}\\." – DNS queries with long hex strings in subdomains
dns.qry.type == 16 – only TXT records
dns.flags.response == 0 – only requests, no answers
After detecting suspicious DNS requests, you need to remove the subdomains and glue. Here tshark is more effective than GUI:
tshark -r evidence.pcap -Y "dns.qry.name contains evil.com" \
-T fields -e frame.number -e dns.qry.name | \
sort -n | cut -f2 | awk -F. '{print $1}' | tr -d '\n'
awk -F. '{for(i=1;i<NF-1;i++) printf $i}'
The team extracts all DNS requests to the domain, cuts the first subdomain from each and glues the result. The resulting line is in CyberChef: From Hex or From Base64 depending on the encoding.
Preconditions: the detection technique only works if the DNS traffic is not encrypted (no DoH/DoT). On the CTF, almost always so. In real-world incidents, DNS over HTTPS will render this approach useless – an interception at the DNS level will be required.
Decryption of TLS traffic in Wireshark
If 90% of the traffic is TLS, and the flag is transferred over HTTPS, you can not do without a decryption key. On the CTF, the authors sometimes give the key a separate file.
Two key formats:
Pre-master secret log – file with records CLIENT_RANDOM <hex> <hex>. Connected through Edit → Preferences → Protocols → TLS → (Pre)-Master-Secret log filename. Works with any type of key exchange.
Server Private Key – RSA private key in PEM. Connected through Edit → Preferences → Protocols → TLS → RSA keys list. Works only with RSA key exchange – not with ECDHE. This is an important moment.
After downloading the key, Wireshark decrypts the TLS sessions automatically. In Protocol Hierarchy appear HTTP/2 or HTTP/1.1 inside the former TLS — further standard parsing through filters and Follow Stream.
Where to look for the key in the task:
Separate file .key or .log in the archive with pcap
Inside the pcap itself, the key is transferred via SMTP or FTP (in THM Wireshark CTF CLIENT_RANDOM, the key lay in the email on port 25)
In the description of the task — CLIENT_RANDOM line is inserted directly into the text of the condition
