Tools · Network tools · 21 / 24
NetworkMiner: the files view without running anything
The files view reconstructs objects from cleartext protocols the parser understands. You hash them, you record which host sent them, and you do not execute them. A file that rode inside TLS will not be sitting there as a document.
What can appear
NetworkMiner rebuilds files from protocols it parses, including HTTP, FTP, SMB, TFTP, and mail protocols, depending on the version. Each row should be read with its source host, destination, protocol, and time. The bytes came from the pcap. If the pcap was the wrong case, the files are the wrong case too.
Reconstruction can be incomplete. A missing segment in the capture becomes a broken object. Say that the file was carved from the capture, and keep the hash. If the hash matters to the owner, they compare it to the copy on the server. You do not repair a carved file by fetching a fresh one from a host the scope did not name.
How you handle the bytes
Carved files are untrusted, even in a lab. NetworkMiner's own guidance warns that opening a recovered executable can infect the machine you are analyzing on. Hash the file, record the hash, and open it only in a lab VM you can revert, if the ticket actually needs the contents. A CSV of lab status does not need to be executed to be identified. file(1) and the hash are enough for the note.
TLS changes the picture. Current builds can show some TLS artifacts, such as certificates and server names. They cannot turn application data back into the document that was transferred. If Files has no row for a download you watched as a large port 443 session, the capture is telling you the object was encrypted. The server's own copy, taken by the owner, is the document.
- Hash before you open. sha256sum is enough.
- Record source, destination, protocol, timestamp, and hash.
- Do not run a carved executable on the analysis host.
- An empty Files tab on a TLS-only transfer is expected.
A worked defensive case
The cleartext lab status capture carves report.csv from HTTP, source 10.8.0.40, destination 10.8.0.20, at 10:05. You copy it into /lab/case/assembled, run sha256sum and file, and write the hash next to the uid from http.log. The contents are a one-line lab table. Nobody double-clicks it.
The 10:00 port 443 transfer to 10.8.0.27 has no matching document in Files. You do not keep re-parsing in the hope that TLS will become a spreadsheet. The ticket for that transfer stays a metadata ticket: who, when, how many bytes. The owner checks the workstation and the service log.
Where this is documented
Netresec documents file extraction by protocol and warns about opening recovered executables. sha256sum and file(1) are the read-only checks. Zeek's files.log is the parallel record when you also ran Zeek on the same pcap.
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
file --brief --mime-type /lab/case/assembled/report.csv && sha256sum /lab/case/assembled/report.csv
Diagram
Three things the files view can tell you
Read the row before you touch the bytes
- A cleartext object
HTTP or another parsed protocol carried a file. Hash it, name the hosts, and do not execute it.
- A broken object
The capture missed segments. Keep the hash and say the carve is incomplete.
- No object on a TLS flow
The transfer stayed encrypted. Certificates and names may still be listed. The document is not.
Check yourself
1. Files shows report.csv carved from HTTP between two lab hosts. What is the first action?
2. A large TLS session has no row in Files. What is the likely reason?
3. The carved CSV is missing its last rows, and tcpdump showed a gap. How do you describe it?