How to extract files from HTTP traffic in a PCAP and hash them

When a host downloads something over plain HTTP, the whole file crosses the wire and the capture holds every byte. Rebuilding it lets you hash it, compare it with known-bad lists and hand it to malware analysis, without going back to the server it came from.

1. What can be recovered

Only clear-text transfers can be rebuilt from a capture alone. In practice that means:

• Plain HTTP, on port 80 or any other port. Malware stagers, software updates, scripts and documents still travel this way more often than you might expect.
• Uploads as well as downloads. A form post or file upload carries a body too, and it is where data leaves the network.
• Other clear-text protocols, such as SMB without encryption, TFTP and email. Wireshark can export those too.

Files fetched over HTTPS are encrypted. Without the session keys, recorded at capture time (for example via a browser's SSLKEYLOGFILE), they can't be recovered from the capture, however complete it is.

2. Export objects in Wireshark

Choose File → Export Objects → HTTP. Wireshark reassembles each HTTP conversation and lists every body it found, with the packet, host name, content type, size and file name. Type in the filter box to narrow the list, then Save one object or Save All.

If HTTP runs on an unusual port and nothing is listed, right-click a packet in that conversation and use Decode As to treat the port as HTTP, then export again.

3. Export from the command line

tshark writes every HTTP object into a directory:

tshark -r capture.pcapng -q --export-objects http,objects

File names come from the URL, so expect names built from query strings, and numbered copies where names repeat. Don't trust a file name or its extension to say what a file is; the next step checks that. Swap http for smb, tftp or imf to export those protocols instead.

4. Hash and identify the files

# Linux and macOS (macOS: shasum -a 256)
sha256sum objects/*

# Windows PowerShell
Get-FileHash -Algorithm SHA256 objects\*

To compare against a list of known-bad SHA-256 hashes, one per line:

sha256sum objects/* | grep -i -F -f hashes.txt

Then check what each file really is. On Linux and macOS, file objects/* reads the first bytes rather than the name, so it shows an executable posing as an image. It also shows whether a body was saved still compressed (gzip compressed data). Threat feeds list the hash of the decoded file, so hash the decompressed version of any body that was sent with Content-Encoding: gzip.

5. Check each file is complete

A hash only means something for the whole file. A file is likely incomplete when:

• The capture started after the download began, or stopped before it ended.
• Packets are missing from the capture (look for tcp.analysis.lost_segment in that conversation).
• The response was 206 Partial Content: a range request fetches a file in pieces, and each piece hashes differently.
• The saved size doesn't match the response's Content-Length header.

An incomplete file can still be useful for its type, strings or embedded addresses, but its hash won't match any list. Say so in your notes rather than reporting "hash not found".

6. Handle files safely

• Don't open them on your workstation. A recovered file is exactly as dangerous as the original download.
• Look up the hash, don't upload the file. Searching a malware database for a hash reveals only the hash. Uploading a file can publish a confidential document to everyone with access to that service.
• Analyse in isolation: a disposable virtual machine with no route to your network.
• Share malware in a password-protected archive, so mail filters and colleagues' antivirus don't trip over it; infected is the conventional password.
• Protect recovered documents as carefully as the capture: an upload may be the very data you are investigating the loss of.

Manual method vs PCAPNG Analyzer