Tools · Network tools · 22 / 24
NetworkMiner: a credential row means the channel was cleartext
The credentials tab lists authentication that a parsed protocol carried in the clear, such as HTTP basic or FTP. The row is a defect report. You rotate the lab secret and turn on TLS. You do not reuse the value or paste it into the ticket.
What a row is
NetworkMiner extracts usernames and passwords from protocols it understands when those protocols sent them without encryption. A row names the client, the server, the protocol, and the time. That is enough to find the session in the pcap and in Zeek. The existence of the row is the finding: this hop was not confidential.
No row does not mean no secret moved. TLS, SSH, and a protocol the parser does not know will not show up as a password here. An empty credentials tab on a modern HTTPS lab is the result you want. An empty tab on a legacy FTP server is a reason to look at the Sessions tab and confirm whether anyone authenticated at all.
How the ticket is written
Write the protocol, the two addresses, the timestamp, and the fact that a secret was visible. Redact the secret. The lab rotates that value even if it was only a training account, because the capture is now a copy of it. The durable change is to stop the cleartext protocol or to wrap it in TLS.
Parameters is the nearby tab. It shows HTTP query and form fields. A token in a query string may be there even when Credentials is empty, because not every secret is in a password field. Read Parameters for the lab HTTP capture. Leave the values out of chat.
- Cite protocol, source, destination, and time.
- Rotate the lab secret. Do not test it against other systems.
- Prefer TLS over a note that says the password was complex.
- A credential inside SSH or HTTPS will not be reconstructed here.
A worked defensive case
The lab file server still allows FTP from the status page's network. Credentials shows user lab-backup from 10.8.0.20 to 10.8.0.40 at 10:06, protocol FTP. You record those fields, redact the password, and match the time to an ftp.log or a session row. The owner disables FTP, rotates the backup account, and publishes the status file over the HTTPS path they already run.
You do not log in with the recovered password to prove it works. The tab already proved the channel exposed it. A follow-up capture the next day should show no FTP session and an empty credentials tab for that pair.
Where this is documented
Netresec describes the Credentials tab as extraction from supported protocols, and it lists examples such as HTTP and FTP. Treating the extracted value as a secret to rotate, not as a key to reuse, is the case-handling rule.
Use a host-only lab network, or a capture the owner already handed you. These commands read that file or record a single lab host. They are not a scan of the public internet.
Commands
zeek-cut -m ts uid id.orig_h id.resp_h id.resp_p user < /lab/zeek/ftp.log
Diagram
A credential row is a defect, not a login
What you do with the tab
Row. FTP, lab-backup, 10.8.0.20 to 10.8.0.40.
Action. The value is tried on other lab services to see how far it goes.
Result. The case just spread the secret further.
Row. Same addresses, protocol, and time, secret redacted.
Action. Disable FTP, rotate the account, serve the file over the existing HTTPS path.
Result. The next capture has no credentials row for that pair.
Check yourself
1. Credentials shows an FTP password from 10.8.0.20 to 10.8.0.40. What is the change?
2. The credentials tab is empty on a capture that is entirely HTTPS. How do you read that?
3. Credentials is empty, and Parameters shows token= on an HTTP GET. What did you find?