My view is that we already have pushbutton forensics: the bulk of the workload is being performed by EnCase and FTK analysts pointing and clicking. We simply don’t have enough deep forensic skill in the industry to satisfy the demand.

This is not necessarily a bad thing, if folks like yourself and Erik continue to develop your free tools to solve more and more problems that we face, enabling more and more analysts to do pushbutton forensics in a correct and accurate way.

Not everyone needs to know how cars work to drive one, so long as the car is well built and can get you from point A to point B reliably, consistently and predictably. We just need engineers to build them well and make them easy to use.

All I was saying is that for a challenge like this, I don’t think that the goal is to show that you can point-and-click on a GUI to find out the answer (unless you are the one that is developing the point-and-click GUI). The goal in my opinion is to show that you understand the network traffic and you are capable of interpreting it yourself, not to let tools do all the work for you, and then of course since scripting is encouraged it doesn’t hurt to actually script some of the work to make future work easier

And thanks for the link Eric

http://chatteronthewire.blogspot.com/2009/11/network-forensic-challenge-2-update.html

I actually implemented the SMTP parser and “Message” tab in NetworkMiner specifically for this puzzle.

@Kristinn: NetworkMiner is primarily not designed to solve simple puzzles like the ones on this site; the tool is crafted with the intention of being used in real forensic cases. I also don’t see why running a tool without GUI would be more helpful, I usually find it very rewarding (and time saving) to be able to look at the extracted data in a GUI to quickly identify the relevant communication. I do, however, agree that doing pre-filtering with other tools (like tshark) is useful when large files (>1GB) need to be analyzed… but I would say that it is not often that you know exactly what to look for, which is why being able to visually see a representation of the traffic in a GUI crucial.

But I’m biased of course

This competition is more about understanding the network capture by yourself, so you need to dig deeper and understand how this works, and in a competition like this where scripting is really encouraged… to write a script that automates the process for future uses.

Although tools like Network Miner are incredibly useful and can find answers to a challenge like this quite easily I think that in the real world, scripts like those that are developed for this challenge can be more useful in some cases, such as when you have a real life capture that is immensely larger than this one, and where we are only looking for some rogue SMTP traffic. There a simple script that does the trick can be much more powerful, especially since it might not need to be run on your workstation with a GUI, but instead could be run on a server without the need of a GUI. You could script around it to make it automatically search through a was amount of information instead of manually inspecting the results in network miner…. but this is just my two cents…

And in the spirit of sharing solutions, here is mine: http://blog.kiddaland.net/2009/11/second-network-forensics-contest/

(note i did the work and found this precious tool after)

http://sourceforge.net/projects/networkminer/

Yours is really nice! I debated pcap input handling, but found that pcapcat (from tgefirst challenge) did a great job, so I decided against it. It’s interesting to see your approach, thanks for sharing!

Sec558. Respek. LOL.