"UDP packets are, of course, easy to spoof and Winpop spammers take advantage of that. These ICMP messages are coming to what they think is home but was really a spoofed IP. This Winpop spammer didn't get the memo about sourcing the packets from unallocated IP space which seems to be popular these days." Mark Senior: "This is the result of some computer out there sending Windows messenger popup spam - this typically uses UDP 1026 to about 1030; in this case we see it's using 1026.Whoever is sending the messages out is spoofing their source address, to make it harder to track them down. They have no need to send from a source address at which they can be reached, as this is a 'fire and forget' kind of thing.Occasionally they run across IP ranges that have a circular route (which generates ICMP type 11 messages) or where there are numbers of non-firewalled, non-Windows hosts (since they're not firewalled, and not listening on port 1026, this generates the ICMP type 3 messages)." Dr. Neal Krawetz: I can't post all his analysis work here as it went through several interations (just like a good Dr and yes it was fun:>) However he took the same approach as many of us and that it was not pop-up spam, but traffic generated for other endevors. Here is some of his analysis: "At first glance, it looks like a packet flood. A ton of ICMP packets per second. Could be to flood a network (DoS), poison a switches' ARP cache, or just a VERY misconfigured router. They are targeting 1025/udp and 1026/udp, so it really looks like a Windows exploit. Is there are recent overflow due to packet volume? Or maybe the attacker is just trying to consume CPU cycles (this will raise the load on a Windows box...) At a closer glance, it looks like a blind UDP attack aimed to disconnect an established connection. This works if the blind attacker can guess the right source/destination/protocol/ID combination. (I've seen these with TCP, but not UDP.) There should be more IDs for a blind attack... (And looking at the log numbers, there is a big jump at the end, so this is possible.) For a more detailed look: http://isc.sans.org/diaryimages/icmpType11.log - First 2 packets show an incoming packet fail to be delivered. Traceroute or similar scan? Could be unrelated to the rest of the traffic. - The next group of packets occur a month later, in a large flood. This Looks like a blind UDP hijack attack, but could be a router echo problem where there is a loop between router interfaces. Are the Source and Destination on the same subnet? Is this the entire flood, or are there many more that are not included in this log sample? ICMP type 11 is a timeout exceeded, so this could definitely disconnect anything established. - The final 7 packets occur weeks later. They are likely regular noise (unrelated). icmpType3.log looks similar, but it uses Destination Unreachable. This makes me think it is more likely a blind UDP attack than a router error. (The the admin/user piss anyone off lately?)" Jonathan Strine: "The host generating the log files is assigned a dynamic IP address. This is represented by the vastly varying destination IPs over different dates. Though it appears that at least on 11/22 and 1/23 the host may have had the same address assigned. The traffic outside of these dates may be "background" as there are only a few packets and they have some different parameters (original payload sizes, for exmaple). Most of the packets have a source port of 0 which should not be (except for perhaps the output of a special attack tool and/or a misbehaving TCP/IP stack). The icmpType3.log shows ICMP messages coming from multiple sources to primarily xxx.xxx.18.51. These messages reflect a "Communication Administratively Prohibited" error. Presumably a filtering device is denying these initial packets (to UDP ports 1025 and 1026 from varying IPs) and politely informing the sender (perhaps spoofed). Spoofing may be further suspected since the protocol is UDP and thus connectionless. The original connect attempts may be Microsoft Messenger "spam". Some places also suggest possible MS RPC and MS DTC exploits. Oddly, only a few ICMP error messages have a source IP different than the original destination IP. The icmpType11.log shows ICMP messages coming from primarily xxx.xxx.92.129 and xxx.xxx.93.129 to primarily xxx.xxx.18.51. These messages are "Time Exceeded" error messages. This is supported by the original messages having a TTL of 1 by the time they reached the xxx.xxx.92/93.129 host. Unlike in the icmpType3.log each original destination host appears to have two packets sent to it (one to UDP/1025 and another to UDP/1026). In addition, the ID increments for each packet per host. Beyond this I cannot yet explain why the packets have a TTL=1 and are all very similar to each other." Brandon: "I believe that it is some sort of recon and possible spam/exploit attempt that is using the xxx.xxx.18.51 as a decoy. The log file that occurs on Nov 22, 2005 contains mainly ICMP type:11/ code:0 or TTL exceed in transit. It’s possible that someone is using a tool to look for boxes that have udp:1026 open within a specified hop count or possibly looking to use IDS evasion techniques. The traffic that occurred on Jan. 23, 2006 is possibly the result of someone taking the results of the first scan and using those results to send out either some SPAM or other RPC-DCOM exploit traffic. The logs tell us that the length on the initial packet is 518 bytes as opposed to the 377 bytes of the scan that occurred in November so something is different here. Also in looking at this log, the traffic is being denied because it is administratively prohibited (ICMP type:3/code:13) and the TTL is 57 which I can only assume came from a box with a TTL of 64 so it is possibly a Linux (or variant) box and not a Cisco ACL which would have been 255. I believe that this box that prohibited the traffic is probably a firewall sitting in front of the xxx.xxx.187.0/24 segment The xxx.xxx.18.51 is probably a spoofed box that could be a part of some tools decoy list or a box that someone can monitor the return traffic."