How to find a password in Wireshark: parsing the traffic dump by steps
Finding passwords is a classic CTF foresee. In real-world conditions, the interception of credentials from network traffic is Network Sniffing (T1040, Credential Access) according to the MITRE ATT&CK classification. On CTF, it is reproduced in educational conditions: the organizers create a PCAP file in which someone has logged in to an unsafe protocol, and the task is to find these credentials.
Why are passwords in the traffic open? HTTP protocols (without S), FTP, Telnet, POP3, IMAP without TLS drive data in plain-text. Everything that the user sends - login, password, contents of letters - flies over the network in what the mother gave birth. According to the OWASP classification, this is A02:2021 — Cryptographic Failures : no encryption when transmitting sensitive data. The scale of the problem shows the 2012 LinkedIn leak: 164 million password accounts were compromised – according to Have I Been Pwned. A significant portion of these passwords were transmitted via HTTP at the time of the leak.
HTTP: logins and passwords in the open
HTTP is the most frequent protocol in CTF-weights for beginners. Password Search Algorithm:
Apply filter http.request.method == "POST".
In the list of packages, you are looking for a URL query similar to the login form: /login, /auth, /signin, /wp-login.php.
Click on the package. In the Packet Details panel, you reveal the "HTML Form URL Encoded" level - here are the form fields in the format username=admin&password=s3cret.
If this level is not available, open "Line-based text data" or look at the Packet Bytes panel - the form data is visible in the ASCII view on the right.
Another option is HTTP Basic Authentication. Look for a headline Authorization: Basic through the filter http.authorization. The value is encoded in Base64 – it is coded, not encrypted (for those in the tank – this means that anyone can decode back in a second). Wireshark automatically decodes Base64 in the Packet Details panel and shows a pair user
assword in the Credentials field. If the decoding didn't work, copy the Base64 string and run through echo "dXNlcjpwYXNz" | base64 -d in the terminal.
There is a less obvious case on the CTF: credentials are transmitted through cookies or a custom HTTP header. Filter http.cookie contains "session" or http.request with the subsequent viewing of the titles in Packet Details will help to detect such situations.
FTP and Telnet: A network foreseeing classic for beginner
FTP is the gold standard of CTF tasks for password interception. The protocol transmits the login and password by individual commands: USER admin, PASS secret123. Filter ftp.request.command == "USER" shows the login, ftp.request.command == "PASS" - password. In practice, it is easier to introduce simply ftp and scroll through five to ten packages — USER and PASS teams always go after each other at the beginning of the session.
In addition to credentials, FTP traffic contains information about the transmitted files. Team RETR filename.txt means downloading the file, STOR - sending. If the task is asked to find not a password, but the contents of the file transmitted over FTP, use Follow TCP Stream on a package with the RETR command.
With Telnet is more cunning: the protocol transmits data by shame. Each entered password symbol is a separate TCP package. Filter tcp.port == 23 selects Telnet traffic, but read the password for one symbol from different packages - torment. Solution: Follow TCP Stream. He will collect all the symbols into a single text, where you will see the invitation login:, and the introduced login, and password:, and password. In the context of MITRE ATT&CK, the collection of such credentials from files and sessions is described as Credentials In Files (T1552.001, Credential Access).
Wireshark Follow TCP Stream: key to analyzing CCT pcap files
Follow TCP Stream is a function that collects all TCP fragments and displays them as a single readable dialog. According to Cyber Forensic Academy, the function “reassembles the fragmented packets of a TCP conversation into a readable format” allows you to see client and server correspondence as a script. This is the main tool for analyzing pcap files on CTF.
Order of work:
Find the package of interest – FTP, HTTP, Telnet or any other.
Right click on package → Follow → TCP Stream.
A window with the full connection text opens. Red color - customer data (requests, logins, passwords). Blue – server responses (HTML pages, file lists, error messages).
At the bottom of the window there is a "Stream" field with a number. By switching it with arrows, you move between different TCP sessions in the dump.
On CTF Follow TCP Stream solves several tasks at once: reading the FTP session in its entirety (login, password, file list, transmitted data), assembling the symbolic Telnet-input into the whole text, viewing HTTP requests with headers and answer bodies. Sometimes the flag is visible directly in the text stream – among HTML comments, cookie headers, or the body of the answer.
A typical beginner’s mistake: Opens the Follow TCP Stream on the first package that comes in and sees the trash. Not all threads are interesting — DNS queries, TCP-handshake, SSL-handshakes look like a set of unreadable characters. - Go over streams: Switch the number to the “Stream” field and view each. On CTF-task usually 5-20 meaningful flows, among which one or two contain the answer.
Receive: After your find in Follow Stream, use the filter tcp.stream eq N (where N is the flow number) to return to the source packets in the main window. This helps when you need to pull a specific field out of the title or check the time tags.
Another useful thing from the same menu is Follow HTTP Stream. Works similarly, but automatically uncompresses gzip content and shows the body of the HTTP response in the readable form. For web tasks, this is more convenient than the usual TCP Stream.
Extracting files from pcap via Wireshark Export Objects
Sometimes the CTF task is not to find a password, but to pull the file out of traffic: a picture with a flag, a PDF with a hint, an archive with a key. Organizers put the file inside the PCAP dump and need to extract it.
Wireshark is able to export files transferred through several protocols:
Open File → Export Objects → HTTP.
There will be a list of all files transferred to HTTP: pictures, scripts, HTML pages, downloaded documents.
Each line contains the file name, host, content type and size.
Select the file you want and click Save. Or Save All to pull everything together and figure it out later.
In addition to HTTP, Export Objects supports SMB (Windows file balls), TFTP, IMF (email attachments). On CTF HTTP is most common, but if the task is related to the transfer of files within the local network, check the SMB.
What if the file is transmitted over a protocol that Export Objects does not support? Use Follow TCP Stream: open the desired stream, switch the display format from "ASCII" to "Raw" (the drop-down menu at the bottom of the window) and save the data through "Save as". You will get a raw binary stream - in simple cases, the file will be working immediately, in the complex you will have to manually remove the headers of the protocol.
As an auxiliary tool for extracting files from pcap, it is worth keeping NetworkMiner at hand - it automatically disassembles PCAP and puts the found files, pictures and accounts on folders. Convenient as an addition to Wireshark, when you need to quickly pull all the files out of the dump without manually overdue the threads.
Search for secrets in network traffic: DNS and ICMP
More advanced CTF assignments hide data not in HTTP or FTP, but in protocols that beginners usually miss. DNS and ICMP are two of the most popular channels for steganography and exfiltration at competitions. In real-world attacks, attackers use these protocols to output data from a compromised network, bypassing firewalls: most firewalls pass DNS and ICMP without deep inspection. Logic is simple – who will block DNS? Without him, the network will stand up.
DNS queries as a data exfiltration channel
DNS tunneling works like this: data is encoded and placed in a subdomain of a DNS query. Instead of normal mail.google.com in the dump appear requests of the species aGVsbG8gd29ybGQ=.evil.com – coded data instead of subdomain.
Search algorithm on CTF:
Apply filter dns.
Look at the Info column – pay attention to unusually long DNS requests. In normal traffic, the query contains 10-30 characters. Requests longer than 50 characters – a reason to stop.
If you see subdomains similar to Base64 or hex lines, collect them in order and decode them.
For quick evaluation, use Statistics → Protocol Hierarchy. If DNS traffic takes a disproportionate share of the dump, this is a tunneling indicator.
According to the Cyber Forensic Academy, “malware is a frequent use of Domain Generation Algorithms (DGA) to active find C2 servers.” On the CTF, this is simplified: there is usually one “malicious” domain where data is sent through a series of DNS requests.
ICMP: secrets inside the pings
The ICMP Echo Request contains a payload field where you can put arbitrary data. In normal traffic there is a standard padding line or zero. On the CTF, the organizers place the flag or its fragments in the payload.
Filter: icmp. In Packet Details, open the Internet Control Message Protocol → Data. If instead of a standard pattern (repeated abcdefghijklmnop on Windows or zero bytes) you see meaningful text or Base64 is the purpose of the task.
Often the flag is distributed over several ICMP packets - one or two characters in each. It is inconvenient to collect them manually (I tried - on the tenth package you start to confuse order), and here tshark comes to the rescue: automatic data extraction from payload of all ICMP packets for one command.
Automation of Wireshark traffic dump disassembly with tshark
tshark is a console version of Wireshark with the same analysis capabilities. For CTF tshark, it is indispensable when you need to process a large dump or extract a specific field from hundreds of packages automatically.
tshark -r dump.pcap -Y "http.request.method == POST" -T fields -e http.host -e http.request.uri
tshark -r dump.pcap -Y "dns.qry.name" -T fields -e dns.qry.name > dns_queries.txt
tshark -r dump.pcap -Y "icmp.type == 8" -T fields -e data.data
Key parameters: -r Specifies the input PCAP file, -Y – display filter (the same syntax as in GUI), -T fields – tabular conclusion, -e – a specific field for extraction. The result can be directed to grep, awk, sort -u or base64 -d for post-processing.
Practical reception for DNS-tasks: tshark -r dump.pcap -Y "dns.qry.name" -T fields -e dns.qry.name | sort -u outputs all unique DNS requests. Abnormal domains are visible at once - long lines Base64 or hex among normal google.com and cloudflare.com.
For tasks with ICMP-exfiltration output data.data - hex lines. Conversion to text: tshark -r dump.pcap -Y "icmp.type == 8" -T fields -e data.data | xxd -r -p. If each package contains a pair of flag characters, you will get them all in one line.
Typical errors in analyzing pcap files on CTF
For a few dozen forensic CTFs, I’ve collected a list of the mistakes that the most time is spent.
Do not use filters. Open PCAP and start leafing through packages one by one. In a dump for 10 000 packages it is useless. The first action is always filter: http, ftp, dns. Then narrow it.
Forget Follow TCP Stream. Look at individual packages without collecting them in the session. One HTTP request package rarely contains a complete picture. Follow Stream shows the entire dialog — query and response together, with all the titles.
Export Objects are not checked. The file may lie in a dump ready to be extracted with a single click through File → Export Objects → HTTP, and the beginner is trying to decode the hex manually from Packet Bytes. Why, if you can press Save?
Ignore DNS and ICMP. HTTP and FTP check, the rest is missed. And DNS requests and ICMP payloads are a frequent channel for mid-level CTF flags.
Confused types of filters. Introduce the syntax capture filter (port 80) in the display filter line and get a red background. In display filter correct syntax: tcp.port == 80.
Not using Statistics. Wireshark has a Statistics menu with tools that save time. Protocol Hierarchy shows the distribution of traffic by protocols - if 60% of the dump is DNS when asking about HTTP, the data is hidden in DNS. Conversations and Endpoints show who communicated with whom and how much data transmitted. An abnormally large amount of traffic from one host is a lead.
Stop on the first found. Found admin:admin and consider the task solved. But the flag can lie in another session, in another stream, in the extracted file. Check out a few threads and always do Export Objects.
Minimum algorithm for any CTF-task with PCAP: (1) Statistics → Protocol Hierarchy for the overall picture, (2) filters by main protocols, (3) Follow TCP Stream for suspicious sessions, (4) Export Objects for files, (5) frame contains for direct search of the flag. This is enough for the eyes on the percentage of eighty tasks of the level of easy-medium.
Finding passwords is a classic CTF foresee. In real-world conditions, the interception of credentials from network traffic is Network Sniffing (T1040, Credential Access) according to the MITRE ATT&CK classification. On CTF, it is reproduced in educational conditions: the organizers create a PCAP file in which someone has logged in to an unsafe protocol, and the task is to find these credentials.
Why are passwords in the traffic open? HTTP protocols (without S), FTP, Telnet, POP3, IMAP without TLS drive data in plain-text. Everything that the user sends - login, password, contents of letters - flies over the network in what the mother gave birth. According to the OWASP classification, this is A02:2021 — Cryptographic Failures : no encryption when transmitting sensitive data. The scale of the problem shows the 2012 LinkedIn leak: 164 million password accounts were compromised – according to Have I Been Pwned. A significant portion of these passwords were transmitted via HTTP at the time of the leak.
HTTP: logins and passwords in the open
HTTP is the most frequent protocol in CTF-weights for beginners. Password Search Algorithm:
Apply filter http.request.method == "POST".
In the list of packages, you are looking for a URL query similar to the login form: /login, /auth, /signin, /wp-login.php.
Click on the package. In the Packet Details panel, you reveal the "HTML Form URL Encoded" level - here are the form fields in the format username=admin&password=s3cret.
If this level is not available, open "Line-based text data" or look at the Packet Bytes panel - the form data is visible in the ASCII view on the right.
Another option is HTTP Basic Authentication. Look for a headline Authorization: Basic through the filter http.authorization. The value is encoded in Base64 – it is coded, not encrypted (for those in the tank – this means that anyone can decode back in a second). Wireshark automatically decodes Base64 in the Packet Details panel and shows a pair user
assword in the Credentials field. If the decoding didn't work, copy the Base64 string and run through echo "dXNlcjpwYXNz" | base64 -d in the terminal.There is a less obvious case on the CTF: credentials are transmitted through cookies or a custom HTTP header. Filter http.cookie contains "session" or http.request with the subsequent viewing of the titles in Packet Details will help to detect such situations.
FTP and Telnet: A network foreseeing classic for beginner
FTP is the gold standard of CTF tasks for password interception. The protocol transmits the login and password by individual commands: USER admin, PASS secret123. Filter ftp.request.command == "USER" shows the login, ftp.request.command == "PASS" - password. In practice, it is easier to introduce simply ftp and scroll through five to ten packages — USER and PASS teams always go after each other at the beginning of the session.
In addition to credentials, FTP traffic contains information about the transmitted files. Team RETR filename.txt means downloading the file, STOR - sending. If the task is asked to find not a password, but the contents of the file transmitted over FTP, use Follow TCP Stream on a package with the RETR command.
With Telnet is more cunning: the protocol transmits data by shame. Each entered password symbol is a separate TCP package. Filter tcp.port == 23 selects Telnet traffic, but read the password for one symbol from different packages - torment. Solution: Follow TCP Stream. He will collect all the symbols into a single text, where you will see the invitation login:, and the introduced login, and password:, and password. In the context of MITRE ATT&CK, the collection of such credentials from files and sessions is described as Credentials In Files (T1552.001, Credential Access).
Wireshark Follow TCP Stream: key to analyzing CCT pcap files
Follow TCP Stream is a function that collects all TCP fragments and displays them as a single readable dialog. According to Cyber Forensic Academy, the function “reassembles the fragmented packets of a TCP conversation into a readable format” allows you to see client and server correspondence as a script. This is the main tool for analyzing pcap files on CTF.
Order of work:
Find the package of interest – FTP, HTTP, Telnet or any other.
Right click on package → Follow → TCP Stream.
A window with the full connection text opens. Red color - customer data (requests, logins, passwords). Blue – server responses (HTML pages, file lists, error messages).
At the bottom of the window there is a "Stream" field with a number. By switching it with arrows, you move between different TCP sessions in the dump.
On CTF Follow TCP Stream solves several tasks at once: reading the FTP session in its entirety (login, password, file list, transmitted data), assembling the symbolic Telnet-input into the whole text, viewing HTTP requests with headers and answer bodies. Sometimes the flag is visible directly in the text stream – among HTML comments, cookie headers, or the body of the answer.
A typical beginner’s mistake: Opens the Follow TCP Stream on the first package that comes in and sees the trash. Not all threads are interesting — DNS queries, TCP-handshake, SSL-handshakes look like a set of unreadable characters. - Go over streams: Switch the number to the “Stream” field and view each. On CTF-task usually 5-20 meaningful flows, among which one or two contain the answer.
Receive: After your find in Follow Stream, use the filter tcp.stream eq N (where N is the flow number) to return to the source packets in the main window. This helps when you need to pull a specific field out of the title or check the time tags.
Another useful thing from the same menu is Follow HTTP Stream. Works similarly, but automatically uncompresses gzip content and shows the body of the HTTP response in the readable form. For web tasks, this is more convenient than the usual TCP Stream.
Extracting files from pcap via Wireshark Export Objects
Sometimes the CTF task is not to find a password, but to pull the file out of traffic: a picture with a flag, a PDF with a hint, an archive with a key. Organizers put the file inside the PCAP dump and need to extract it.
Wireshark is able to export files transferred through several protocols:
Open File → Export Objects → HTTP.
There will be a list of all files transferred to HTTP: pictures, scripts, HTML pages, downloaded documents.
Each line contains the file name, host, content type and size.
Select the file you want and click Save. Or Save All to pull everything together and figure it out later.
In addition to HTTP, Export Objects supports SMB (Windows file balls), TFTP, IMF (email attachments). On CTF HTTP is most common, but if the task is related to the transfer of files within the local network, check the SMB.
What if the file is transmitted over a protocol that Export Objects does not support? Use Follow TCP Stream: open the desired stream, switch the display format from "ASCII" to "Raw" (the drop-down menu at the bottom of the window) and save the data through "Save as". You will get a raw binary stream - in simple cases, the file will be working immediately, in the complex you will have to manually remove the headers of the protocol.
As an auxiliary tool for extracting files from pcap, it is worth keeping NetworkMiner at hand - it automatically disassembles PCAP and puts the found files, pictures and accounts on folders. Convenient as an addition to Wireshark, when you need to quickly pull all the files out of the dump without manually overdue the threads.
Search for secrets in network traffic: DNS and ICMP
More advanced CTF assignments hide data not in HTTP or FTP, but in protocols that beginners usually miss. DNS and ICMP are two of the most popular channels for steganography and exfiltration at competitions. In real-world attacks, attackers use these protocols to output data from a compromised network, bypassing firewalls: most firewalls pass DNS and ICMP without deep inspection. Logic is simple – who will block DNS? Without him, the network will stand up.
DNS queries as a data exfiltration channel
DNS tunneling works like this: data is encoded and placed in a subdomain of a DNS query. Instead of normal mail.google.com in the dump appear requests of the species aGVsbG8gd29ybGQ=.evil.com – coded data instead of subdomain.
Search algorithm on CTF:
Apply filter dns.
Look at the Info column – pay attention to unusually long DNS requests. In normal traffic, the query contains 10-30 characters. Requests longer than 50 characters – a reason to stop.
If you see subdomains similar to Base64 or hex lines, collect them in order and decode them.
For quick evaluation, use Statistics → Protocol Hierarchy. If DNS traffic takes a disproportionate share of the dump, this is a tunneling indicator.
According to the Cyber Forensic Academy, “malware is a frequent use of Domain Generation Algorithms (DGA) to active find C2 servers.” On the CTF, this is simplified: there is usually one “malicious” domain where data is sent through a series of DNS requests.
ICMP: secrets inside the pings
The ICMP Echo Request contains a payload field where you can put arbitrary data. In normal traffic there is a standard padding line or zero. On the CTF, the organizers place the flag or its fragments in the payload.
Filter: icmp. In Packet Details, open the Internet Control Message Protocol → Data. If instead of a standard pattern (repeated abcdefghijklmnop on Windows or zero bytes) you see meaningful text or Base64 is the purpose of the task.
Often the flag is distributed over several ICMP packets - one or two characters in each. It is inconvenient to collect them manually (I tried - on the tenth package you start to confuse order), and here tshark comes to the rescue: automatic data extraction from payload of all ICMP packets for one command.
Automation of Wireshark traffic dump disassembly with tshark
tshark is a console version of Wireshark with the same analysis capabilities. For CTF tshark, it is indispensable when you need to process a large dump or extract a specific field from hundreds of packages automatically.
tshark -r dump.pcap -Y "http.request.method == POST" -T fields -e http.host -e http.request.uri
tshark -r dump.pcap -Y "dns.qry.name" -T fields -e dns.qry.name > dns_queries.txt
tshark -r dump.pcap -Y "icmp.type == 8" -T fields -e data.data
Key parameters: -r Specifies the input PCAP file, -Y – display filter (the same syntax as in GUI), -T fields – tabular conclusion, -e – a specific field for extraction. The result can be directed to grep, awk, sort -u or base64 -d for post-processing.
Practical reception for DNS-tasks: tshark -r dump.pcap -Y "dns.qry.name" -T fields -e dns.qry.name | sort -u outputs all unique DNS requests. Abnormal domains are visible at once - long lines Base64 or hex among normal google.com and cloudflare.com.
For tasks with ICMP-exfiltration output data.data - hex lines. Conversion to text: tshark -r dump.pcap -Y "icmp.type == 8" -T fields -e data.data | xxd -r -p. If each package contains a pair of flag characters, you will get them all in one line.
Typical errors in analyzing pcap files on CTF
For a few dozen forensic CTFs, I’ve collected a list of the mistakes that the most time is spent.
Do not use filters. Open PCAP and start leafing through packages one by one. In a dump for 10 000 packages it is useless. The first action is always filter: http, ftp, dns. Then narrow it.
Forget Follow TCP Stream. Look at individual packages without collecting them in the session. One HTTP request package rarely contains a complete picture. Follow Stream shows the entire dialog — query and response together, with all the titles.
Export Objects are not checked. The file may lie in a dump ready to be extracted with a single click through File → Export Objects → HTTP, and the beginner is trying to decode the hex manually from Packet Bytes. Why, if you can press Save?
Ignore DNS and ICMP. HTTP and FTP check, the rest is missed. And DNS requests and ICMP payloads are a frequent channel for mid-level CTF flags.
Confused types of filters. Introduce the syntax capture filter (port 80) in the display filter line and get a red background. In display filter correct syntax: tcp.port == 80.
Not using Statistics. Wireshark has a Statistics menu with tools that save time. Protocol Hierarchy shows the distribution of traffic by protocols - if 60% of the dump is DNS when asking about HTTP, the data is hidden in DNS. Conversations and Endpoints show who communicated with whom and how much data transmitted. An abnormally large amount of traffic from one host is a lead.
Stop on the first found. Found admin:admin and consider the task solved. But the flag can lie in another session, in another stream, in the extracted file. Check out a few threads and always do Export Objects.
Minimum algorithm for any CTF-task with PCAP: (1) Statistics → Protocol Hierarchy for the overall picture, (2) filters by main protocols, (3) Follow TCP Stream for suspicious sessions, (4) Export Objects for files, (5) frame contains for direct search of the flag. This is enough for the eyes on the percentage of eighty tasks of the level of easy-medium.
