SANS Digital Forensics and Incident Response Blog

NetworkMiner follow up

Last week, I posted an entry about pulling binaries from pcap files. In the post, I mentioned that NetworkMiner could be used to extract binary files from pcaps automatically, but that during my testing it had failed to extract at least one file.

Shortly after publishing, I was contacted by Eric Kollmann who has done some great research on using network traffic for OS fingerprinting. Some of Kollmann's techniques have been incorporated into NetworkMiner. Kollmann wrote to tell me that I should mention my issues to Erik Hjelmvik, the primary developer of NetworkMiner.

Hjelmvik was incredibly receptive and helpful. Within a few days, he'd downloaded the same pcap file I'd tried in my testing and reported back to me that it was working for him and suggested that it may be a latent bug cropping up on my system due to differences in OS patch level or that perhaps my AV software was deleting the recovered files that contained known malware.

I tried NetworkMiner again and watched as it extracted files. There should have been 17 extracted, but it only reported 15. I attempted to open the log file for my AV product to see if it had deleted anything, but the log file was locked and wouldn't allow me to open it. I fired up the Event Viewer on my system and there were two warnings about my AV deleting files containing known malware.

There you have it, NetworkMiner was working flawlessly. It's always nice to have great interactions with developers of open source products. Not only did Hjelmvik offer the correct suggestion that my AV may be killing the files, he also pointed out that there's a much easier way to extract binaries from pcaps using Wireshark. I think I'd known his method at one time, but forgot it due to lack of use.

In my post I said you could right-click on the GET request in Wireshark and select "Follow TCP Stream", eliminate half the conversation via the drop down box in the resulting dialog window (see the previous article for full details and screen shots). From there, save the byte stream as raw and use foremost or a hex editor to carve out the binary.

Hjelmvik smartly points out that one can scroll down through the main Wireshark window until packet 117 where Info column contains "(application/octet-stream)", right-click on the "Media Type" entry from the middle pane of Wireshark and select "Export Selected Packet Bytes..." At that point, you will be prompted to save the byte stream somewhere on your file system, the result will be the original binary.

Binary extraction with Wireshark, the easy wayBinary extraction with Wireshark, the easy way

As usual, there's more than one way to do it and someone else is going to have a better way.

Thanks to Kollmann and Hjelmvik both for reading and making such great contributions to the community.

Dave Hull, GCFA Silver #3368, is an aspiring maker and technologist specializing in information security. He can be found on the web at


Posted March 17, 2009 at 5:26 PM | Permalink | Reply


Great post Dave. Very informative. This is something we used to teach in SEC508 that is now being picked up with the new SANS Network Forensics Course.
Hopefully John can answer how much of his course covers this type of material for those that are interested.

Posted March 18, 2009 at 11:18 AM | Permalink | Reply

Jonathan Ham

Actually, there's an even easier way than exporting packet bytes, if it's in an HTTP transaction. First click on any packet in list view from the HTTP transaction you're interested in. Then from the File menu, select Export -> Objects -> HTTP. You'll get a new panel that'll allow you to chose one object for export (by name and type), or to just save them all.
However, this approach only works with HTTP, and Dave's blog only applies to TCP-based streams. In Sec558 we'll be working with extracting files from ICMP payloads and the like as well.

Posted March 19, 2009 at 11:35 AM | Permalink | Reply


John thank you sir, good to know. I'm looking forward to taking your class one day.