First off, I wanted to say thanks to all the folks willing to throw their hat in the ring on this one.  Analysis is fun and you will always find unique ways to look at things!  Right up front you have to know that sometimes you will never know what caused the traffic.  There are lots of lessons that you learn from doing analysis.  

First (which was the reason for this diary orginally) is not become complacent when looking at traffic.  That is one that will bite you in the end (no pun intended:>).  For example, remember in the diary that I initially wrote for this challenge I said "It has often been said that if you want to hide something, hide it in plain sight."  Well, that is so true and if you have read that diary entry called Malware: When "comments" become commands  it reinforces the same concept.  The malware is going to a specific website repeatedly.  However if you looked at the site, you would see nothing out of the ordinary.  Many folks don't even look at normal web traffic.  This is one that would fly under the radar, even with seasoned analysist as the malware spaced out the visits since it was on a timer.  However if you did an analysis of all your web traffic, this site might show up and might cause red flags.  The whole point is the author of this malware, hid everything in plain site and made it look like normal web traffic.

Second is to always try to detemine if there is a logical reason for the traffic before you don your tin foil hat and procede to think that there are folks everywhere who are after you.  A happy medium is required.  You need to determine for your organization and its security needs what is the best fit.  However, I hope this has made you think twice about just hearing a port and saying "oh it has to be ....." and never looking at it.  Or just seeing traffic and assuming that it is something without investigating it.

Let me start off by saying that alot of folks did alot of good work on this.  Even if your analysis was not on target, that's ok.  There were several things about this that led me down the same path that many of you took.  My analysis proved wrong later when we finally got captures of what it actually was.  However, kudos goes to fellow handler Don Smith, who nailed it right off the bat.  

So, without any more ado.....the results of the analysis.  As a refresher you can read the diary that started this all: 
Spam, Recon or ??: You make the call!!

The packets turned out to be what some folks (to include Don) thought it was and that was pop-up spam rejects where the spammer was spoofing the IP range of our submitter, which is why he got the ICMP responses back.  Here is a capture of the payload of some of the traffic:  Payload of ICMP Packets

There were several things that many of you caught that made you wonder if this was indeed pop-up spam.  Some made me wonder too such as three types of ICMP messages (can expect this if you are probing the security of the network), source port of 0, DF (Don't Fragment) flag set on a few of the packets (seemed strange when you are doing UDP and such a small payload on it), TTL timeouts on some (why would you set it so low if you want to get spam through and ensure it doesn't timeout), ICMP Type 11 (Time Exceeded) had IPs getting two packets each while the ICMP Type 3, Code 13 (Communication Administratively Prohibited) did not duplicate IPs.

Yeah, many things caught my eye on this traffic the same as it did yours.  From all indications though, its just pop-up spam.  Here are some of your thoughts and analysis on the traffic.  Some of these do not have a name associated out of honoring the submitter's request.  Other requests were submitted, but folks asked not to be included.  To everyone who submitted an analysis, I thank you!  If I accidently skipped someone, please let me know and I'll be happy to include you in here.  It was fun and I hope everyone learns from it.  We'll have to play again sometime!