Re: Messenger Spam on 1026 - Bad News Kids in Security http://www.dslreports.com/forum/r7980551 en Tue, 01 Dec 2009 06:28:21 EDT Tue, 01 Dec 2009 06:28:21 EDT Re: Messenger Spam on 1026 - Bad News Kids http://www.dslreports.com/forum/remark,7984324 psloss :
said by Link Logger See Profile:
The question is how far will these spammers go with this as this new method will allow them to really crank up the volumes of spam sent out big time. How much is too much, before someone takes action to limit them or will they have a free license to go as far as they want in terms of bandwidth usage etc?
That's a good question, which I can't answer. I can only speculate. Here's a couple of factors that I always think about:

First, it's easier to block. As you noted earlier, it's going to be hard for ISPs to block ephemeral ports; however, end-users can employ a "firewall" (hardware, software, or a combination). Unsolicited UDP packets should be blocked by default by most "firewalls." If Microsoft follows through with their threat to activate XP's Internet Connection Firewall (ICF), that would go some way in discouraging this as a long-term method for bulk advertisers.

On the other hand, it's easy to spoof and therefore harder to trace. Which unfortunately makes it almost a no-risk deal for a spammer.

As with what we are doing in monitoring the destination ports, we are also watching trends in the advertisements themselves and they still seem to be predominantly advertisements for cheap products -- anything that is not free is a rip-off in my opinion -- to disable the Messenger service.

(Aside: I suggest that anyone considering buying one of these "products" instead go get Steve Gibson's free utility, Shoot The Messenger:
»news.grc.com/stm/shootthemessenger.htm)

In other words, the spam is mostly for products to stop the spam. That suggests (doesn't prove) that advertisers are not jumping on the bandwagon. It also may suggest there isn't a bandwagon.

That's my speculation (or some of it),

Philip Sloss
--
(Thanks, anonymous!) Feedback? e-mail: stuff@lupwa.org ]]> http://www.dslreports.com/forum/remark,7984324 Tue, 16 Sep 2003 18:40:06 EDT Re: Messenger Spam on 1026 - Bad News Kids http://www.dslreports.com/forum/remark,7983973 Link Logger : That strategy makes sense.

The question is how far will these spammers go with this as this new method will allow them to really crank up the volumes of spam sent out big time. How much is too much, before someone takes action to limit them or will they have a free license to go as far as they want in terms of bandwidth usage etc?

Blake]]> http://www.dslreports.com/forum/remark,7983973 Tue, 16 Sep 2003 18:01:59 EDT Re: Messenger Spam on 1026 - Bad News Kids http://www.dslreports.com/forum/remark,7983805 psloss :
said by Link Logger See Profile:
So the point is nothing is carved in stone about UDP port 1026 and it could be a different port on different systems depending on OS version and configuration (ie what services you have running and even what order they startup in).
Agreed...on the subject of what ports we are testing with the WinPopup tester, we added UDP ports 1025-1029 (inclusive). For further additions, we will probably wait until spammers begin widely exploiting ports higher than that existing range. So far, I haven't seen a lot of Messenger service spam activity above UDP port 1027.

Edit: reviewing logs here, I am starting to see some activity from a couple of spammers that send the same packet to UDP 1026, 1027, and 1028 in sequence. That is covered in the current port set we use, but as above, we'll probably monitor the spam activity rather than theoretical possibilities. Put another way: we'll wait for the spammers to send spam on more ports rather than the possible ports that the Messenger service is listening on...

Philip Sloss

[text was edited by author 2003-09-16 17:52:02]
]]> http://www.dslreports.com/forum/remark,7983805 Tue, 16 Sep 2003 17:41:06 EDT Re: Messenger Spam on 1026 - Bad News Kids http://www.dslreports.com/forum/remark,7983613 Link Logger : On XP svchost.exe is a generic host process name for services that run from dynamic-link libraries (DLLs). Typically on a XP system on UDP port 1026 you will see that svchost.exe is running task number 652 (on my system) which using 'tasklist /SVC' (see »support.microsoft.com/default.as···s;314056 for details) you will see that 652 on my XP Pro system contains the Messenger service and some other functionality.

On Win2k Services is somewhat similar to svchost in function but also has the responsibility of running the Messenger Service as shown by TList -s (see »support.microsoft.com/default.as···S;250320 for details). So on my Win2k Advanced server you see that on UDP port 1031 Services.exe is running and under it a number of other applications including an instance of svchost.exe (using Process Explorer from sysinternals).

So the point is nothing is carved in stone about UDP port 1026 and it could be a different port on different systems depending on OS version and configuration (ie what services you have running and even what order they startup in).

To send one hit Message to a Win2k system you need to find out what port the Services.exe is listening on and and on XP what svchost process is running the Messenger Service and what port it is listening on. For most systems this is UDP port 1026.

Blake
--
»www.SonicLogger.com - Logging Software for SonicWall and 3Com »www.LinkLogger.com - Logging Software for Linksys, Netgear and Zyxel]]> http://www.dslreports.com/forum/remark,7983613 Tue, 16 Sep 2003 17:16:55 EDT Re: Messenger Spam on 1026 - Bad News Kids http://www.dslreports.com/forum/remark,7983251 psloss :
said by Link Logger See Profile:
I've tested this against Win2k Advanced Server, Win2k Professional, and XP Professional. The key is to find what UDP port Services.exe is listening on (I use Vision from Foundstone).
On XP and Windows Server 2003, though, the Messenger service process is not services.exe, it is one of the svchost.exe processes. When I look at the process to port mappings on my XP Home and Pro setups, the services.exe process does not hold any ports open -- neither TCP nor UDP.

So what I'm suggesting is that on XP Home, XP Pro and the different variations of Win2k3 (Server, Adv. Server, etc.), the services.exe process is irrelevant to the Messenger service.

Philip Sloss
--
(Thanks, anonymous!) Feedback? e-mail: stuff@lupwa.org ]]> http://www.dslreports.com/forum/remark,7983251 Tue, 16 Sep 2003 16:27:35 EDT Re: Messenger Spam on 1026 - Bad News Kids http://www.dslreports.com/forum/remark,7983171 Link Logger : I've tested this against Win2k Advanced Server, Win2k Professional, and XP Professional. The key is to find what UDP port Services.exe is listening on (I use Vision from Foundstone). For my personal system (Win2k Advanced Server) Services.exe is listening on 1031, hence why sending to UDP port 1031 works and 1026 doesn't. All my other systems Services.exe is listening on UDP port 1026. If you use UDP port 1027 nothing will appear unless services.exe is listening on that port instead of 1026 which is possible as ephemeral ports are dynamically assigned.

Blake

If everyone reading this thread were to go and find out what UDP port Services.exe is running on, most people would find it on 1026 and would be susceptible to 1026 spam, some people would find that Services.exe is on a different port and hence would not be susceptible to 1026 spam, but would be susceptible to spam sent to their Services.exe port. If anyone would like to participate in this experiment I could use PortPuker to send you the spam as a test.
[text was edited by author 2003-09-16 16:26:39]
]]> http://www.dslreports.com/forum/remark,7983171 Tue, 16 Sep 2003 16:17:21 EDT Re: Messenger Spam on 1026 - Bad News Kids http://www.dslreports.com/forum/remark,7983057 psloss :
said by Link Logger See Profile:
They selected 1026 as the destination port as that is typically where the Services.exe application is listening on most systems (note this method of sending spam is for Windows NT, 2000, XP, 2003 only).
Right, but the point in that regard was that the single packet method has been used since February on UDP port 135 (the endpoint mapper point) and is now being used for the "direct," ephemeral UDP port.

said by Link Logger See Profile:
If you were to send the spam to port 1026 on my computer the spam wouldn't show up on my screen as Services.exe is on port 1031 (if you sent it to UDP port 1031 then it would appear on my system), this is why you see some traffic on ports surrounding 1026 as they are looking for systems where the Services.exe is listening on different ports.
Services.exe is the shell process used for NT4 and Windows 2000, but the Messenger service is launched in one of the svchost.exe processes in XP and Windows Server 2003. So the process name (and, of course, the functionality) is O/S version dependent...which one or ones are you testing on or just running?

Philip Sloss
--
(Thanks, anonymous!) Feedback? e-mail: stuff@lupwa.org ]]> http://www.dslreports.com/forum/remark,7983057 Tue, 16 Sep 2003 16:02:34 EDT Re: Messenger Spam on 1026 - Bad News Kids http://www.dslreports.com/forum/remark,7982934 Link Logger : They selected 1026 as the destination port as that is typically where the Services.exe application is listening on most systems (note this method of sending spam is for Windows NT, 2000, XP, 2003 only). If you were to send the spam to port 1026 on my computer the spam wouldn't show up on my screen as Services.exe is on port 1031 (if you sent it to UDP port 1031 then it would appear on my system), this is why you see some traffic on ports surrounding 1026 as they are looking for systems where the Services.exe is listening on different ports.

On the myNetWatchman popup tester I hope you are trying ports 1025 to at least 1035 for this method as I mentioned the Services.exe app could be on any port.

Blake
[text was edited by author 2003-09-16 15:48:55]
]]> http://www.dslreports.com/forum/remark,7982934 Tue, 16 Sep 2003 15:48:25 EDT Re: Messenger Spam on 1026 - Bad News Kids http://www.dslreports.com/forum/remark,7982648 psloss :
said by Link Logger See Profile:
So the new process is many orders of magnitude faster then using Net Send (which granted is the slowest method of sending Messenger Service spam but it illustrates the point that we are trying to make, that spammers are and will be switching over to this new method for the performance increase they get from using it. The avoidance of filtered of UDP port 135 is just a small bonus in the grand scheme of their world.
Ah, I think I see what you were saying, but an important point is that the higher performance technique is independent of the change in destination port. In fact, the myNetWatchman popup tester I worked on with Lawrence Baldwin has been using that technique since mid-December of last year.

As I wrote above, the spammers have been using the single packet/"higher performance" sends since February to UDP port 135. More recently, they started targeting a different port or ports with those single packets. So they began switching to single packets in earnest in the spring. The port switch was a little later.

Philip Sloss
--
(Thanks, anonymous!) Feedback? e-mail: stuff@lupwa.org ]]> http://www.dslreports.com/forum/remark,7982648 Tue, 16 Sep 2003 15:16:35 EDT Re: Messenger Spam on 1026 - Bad News Kids http://www.dslreports.com/forum/remark,7982622 whispa2113 : I did a Symantec Security check of that IP and found out the IP is San Jose California.

I'll see if I can get a screen shot.
Click for full size
]]> http://www.dslreports.com/forum/remark,7982622 Tue, 16 Sep 2003 15:12:18 EDT Re: Messenger Spam on 1026 - Bad News Kids http://www.dslreports.com/forum/remark,7982554 Link Logger : A quick sample that I added to the portpuker.htm web page showing the difference between using Net Send and the new method for sending out spam messages.

Net Send sample
Type Size Source IP Destination IP sPort dPort Date/Time
----------------------------------------------------------------
UDP 78 192.168.168.5 192.168.168.4 137 137 [2003.09.16 - 12:49:17.000]
ICMP 56 192.168.168.4 192.168.168.5 0 0 [2003.09.16 - 12:49:17.000]
UDP 78 192.168.168.5 192.168.168.4 137 137 [2003.09.16 - 12:49:18.500]
ICMP 56 192.168.168.4 192.168.168.5 0 0 [2003.09.16 - 12:49:18.500]
UDP 78 192.168.168.5 192.168.168.4 137 137 [2003.09.16 - 12:49:20.000]
ICMP 56 192.168.168.4 192.168.168.5 0 0 [2003.09.16 - 12:49:20.000]
UDP 78 192.168.168.5 192.168.168.4 137 137 [2003.09.16 - 12:49:21.500]
ICMP 56 192.168.168.4 192.168.168.5 0 0 [2003.09.16 - 12:49:21.500]
UDP 78 192.168.168.5 192.168.168.4 137 137 [2003.09.16 - 12:49:23.000]
ICMP 56 192.168.168.4 192.168.168.5 0 0 [2003.09.16 - 12:49:23.000]
UDP 78 192.168.168.5 192.168.168.4 137 137 [2003.09.16 - 12:49:24.500]
ICMP 56 192.168.168.4 192.168.168.5 0 0 [2003.09.16 - 12:49:24.500]
UDP 78 192.168.168.5 192.168.168.4 137 137 [2003.09.16 - 12:49:47.156]
ICMP 56 192.168.168.4 192.168.168.5 0 0 [2003.09.16 - 12:49:47.171]
UDP 78 192.168.168.5 192.168.168.4 137 137 [2003.09.16 - 12:49:48.656]
ICMP 56 192.168.168.4 192.168.168.5 0 0 [2003.09.16 - 12:49:48.671]
UDP 78 192.168.168.5 192.168.168.4 137 137 [2003.09.16 - 12:49:50.156]
ICMP 56 192.168.168.4 192.168.168.5 0 0 [2003.09.16 - 12:49:50.171]
UDP 78 192.168.168.5 192.168.168.4 137 137 [2003.09.16 - 12:49:51.656]
ICMP 56 192.168.168.4 192.168.168.5 0 0 [2003.09.16 - 12:49:51.671]
UDP 78 192.168.168.5 192.168.168.4 137 137 [2003.09.16 - 12:49:53.156]
ICMP 56 192.168.168.4 192.168.168.5 0 0 [2003.09.16 - 12:49:53.171]
UDP 78 192.168.168.5 192.168.168.4 137 137 [2003.09.16 - 12:49:54.656]
ICMP 56 192.168.168.4 192.168.168.5 0 0 [2003.09.16 - 12:49:54.671]
UDP 182 192.168.168.5 192.168.168.4 1947 135 [2003.09.16 - 12:49:56.171]
UDP 128 192.168.168.4 192.168.168.5 1394 1947 [2003.09.16 - 12:49:56.171]
UDP 132 192.168.168.5 192.168.168.4 1947 1394 [2003.09.16 - 12:49:56.187]
UDP 108 192.168.168.4 192.168.168.5 1394 1947 [2003.09.16 - 12:49:56.187]
UDP 112 192.168.168.4 192.168.168.5 1026 1947 [2003.09.16 - 12:49:56.203]
UDP 108 192.168.168.5 192.168.168.4 1947 1026 [2003.09.16 - 12:49:56.218]

So you can see that using Net Send is very chatty and slow (also can't spoof source IP using Net Send).

New Method
Type Size Source IP Destination IP sPort dPort Date/Time
----------------------------------------------------------------
UDP 569 192.168.168.5 192.168.168.4 2742 1026 [2003.09.16 - 12:53:58.953] - message sent
UDP 112 192.168.168.4 192.168.168.5 1026 2742 [2003.09.16 - 12:53:58.968] - results returned

So the new process is many orders of magnitude faster then using Net Send (which granted is the slowest method of sending Messenger Service spam but it illustrates the point that we are trying to make, that spammers are and will be switching over to this new method for the performance increase they get from using it. The avoidance of filtered of UDP port 135 is just a small bonus in the grand scheme of their world.

Blake]]> http://www.dslreports.com/forum/remark,7982554 Tue, 16 Sep 2003 15:03:33 EDT Re: Messenger Spam on 1026 - Bad News Kids http://www.dslreports.com/forum/remark,7982397 Link Logger : For an example of performance, to send a spam message via Net Send it might take a couple of seconds to send a message, but by using this new technique you can send several thousands of messages per second given the availability of bandwidth and CPU. So we are talking many orders of magnitude of performance increase by using this new method and hence why this traffic is increasing on suspected Services.exe ports as spammers let lose with a much faster gatling gun, as they are no longer limited by performance factors they do not control as with using Net Send.

Blake
--
»www.SonicLogger.com - Logging Software for SonicWall and 3Com »www.LinkLogger.com - Logging Software for Linksys, Netgear and Zyxel]]> http://www.dslreports.com/forum/remark,7982397 Tue, 16 Sep 2003 14:42:27 EDT Re: Messenger Spam on 1026 - Bad News Kids http://www.dslreports.com/forum/remark,7982280 psloss :
said by Link Logger See Profile:
I would be willing to bet that filtering of UDP port 135 (how many ISP are filtering UDP port 135, as compared to TCP port 135) was just a small factor in spammers switching to this new method, as the real motivator is out and out performance. As you mentioned yourself we have seen this traffic before MSBlast came out so spammers were switching before UDP port 135 filtering started. ISP's will be unable to filter UDP port 1026 traffic so once again the bad guys ultimately win out in the end, because they are free to adapt.
Good point about the filtering, although I'm not sure what you mean by "performance"...the mechanics of sending the packet to one port versus another (or multiple ports) seems fairly similar...what do you mean by "performance?"

Thanks,

Philip Sloss
--
(Thanks, anonymous!) Feedback? e-mail: stuff@lupwa.org ]]> http://www.dslreports.com/forum/remark,7982280 Tue, 16 Sep 2003 14:24:59 EDT Re: Messenger Spam on 1026 - Bad News Kids http://www.dslreports.com/forum/remark,7982201 Link Logger : Given that single packet UDP traffic is typically fire and forget, IP Spoofing is very possible given the spammer doesn't need a reply (Net Send couldn't use a spoofed IP addresses as the process required information be sent back to the spammer in order to complete the message process, ie if Netbios was enabled for messages and where the services.exe was sitting). Imagine if SQL Slammer used a spoofed source IP address, that would have been very, very bad and I wonder why the author didn't (unless the spoof generator would have increased the packet size too much).

I agree that this traffic isn't new and has bothered me for a while however as I was interested in the spammer's reasons behind the switch to this method. I would be willing to bet that filtering of UDP port 135 (how many ISP are filtering UDP port 135, as compared to TCP port 135) was just a small factor in spammers switching to this new method, as the real motivator is out and out performance. As you mentioned yourself we have seen this traffic before MSBlast came out so spammers were switching before UDP port 135 filtering started. ISP's will be unable to filter UDP port 1026 traffic so once again the bad guys ultimately win out in the end, because they are free to adapt.

Blake]]> http://www.dslreports.com/forum/remark,7982201 Tue, 16 Sep 2003 14:15:53 EDT Re: Messenger Spam on 1026 - Bad News Kids http://www.dslreports.com/forum/remark,7981940 psloss :
said by Link Logger See Profile:
The point here is that by using this new technique of sending a single UDP packet to whatever port has Services.exe listen on it (usually 1026, but I bet we will see an increase in UDP traffic to ports 1024 - 1035 as Services.exe can run on any one of them as the port is dynamically assigned on startup of the system), the delivery rate of spammers has gone up by several orders of magnitude.
That's true, however single packet Messenger service spam isn't particularly "new" -- it has been the "rule" for several months. It goes back in my logs as early as February 2nd of this year when it was being introduced. By May, if not earlier, it was being used as much as the "built-in" Windows NetMessageBufferSend functionality. Now, most spammers are setting the idempotent bit which enables single packet sends, although other bits could be substituted (or combined).

What is relatively new (the LURHQ advisory) is that the packet is being sent to multiple ports to circumvent the port 135 filtering that is being applied by more ISPs. Going back through my logs, I found that sending to UDP ports 1026, 1027, and even 1028 goes back as far as March. It looks like the method was used in "one-off" cases through May and that higher rates of use began in mid-June, as the LURHQ advisory notes.

Another thing that we have yet to see used quite as much is spoofing the source IP address, but I believe this will occur eventually (I'm surprised it hasn't occurred as much by now).

Philip Sloss
--
(Thanks, anonymous!) Feedback? e-mail: stuff@lupwa.org ]]> http://www.dslreports.com/forum/remark,7981940 Tue, 16 Sep 2003 13:41:35 EDT Re: Messenger Spam on 1026 - Bad News Kids http://www.dslreports.com/forum/remark,7981858 Link Logger : There is no handshaking required in UDP traffic, which is one reason why UDP traffic is faster then TCP traffic.

PortPeeker is basically a listener; PortPuker is the data transmitter and given it sends out 'custom' traffic we are hesitant to release it as it definitely has a black hat side (custom packet content crafter and sender for TCP/UDP/ICMP and captures the response, sound like a potential hacker test tool) that we wouldn't want to see it used by someone with less then honourable intentions.

Blake]]> http://www.dslreports.com/forum/remark,7981858 Tue, 16 Sep 2003 13:31:23 EDT Re: Messenger Spam on 1026 - Bad News Kids http://www.dslreports.com/forum/remark,7981696 Link Logger : The point here is that by using this new technique of sending a single UDP packet to whatever port has Services.exe listen on it (usually 1026, but I bet we will see an increase in UDP traffic to ports 1024 - 1035 as Services.exe can run on any one of them as the port is dynamically assigned on startup of the system), the delivery rate of spammers has gone up by several orders of magnitude. For example sending a Messenger Service message via Net Send involves quite a bit of traffic over several ports (135, 137, 1026 etc), and is actually very slow as the process works its way through to delivery of the message. The new technique of sending a single UDP packet to UDP port 1026 is instant by comparison and in effect is using the same concepts that made SQL Slammer the fastest worm ever. So now Messenger Services spam can move at the same speed as SQL Slammer, frightening thought.

Blake]]> http://www.dslreports.com/forum/remark,7981696 Tue, 16 Sep 2003 13:07:34 EDT Re: Messenger Spam on 1026 - Bad News Kids http://www.dslreports.com/forum/remark,7980623 psloss :
said by Link Logger See Profile:
Today my interest in the recent flood of UDP port 1026 drove me to write PortPuker, which allows me to take captures from PortPeeker and bring them into the lab where I can conduct some experiments on the traffic in question.
This has been discussed a lot recently and someone pointed out a LURHQ advisory from the June timeframe:
»www.lurhq.com/popup_spam.html

Also, spammers are also beginning to send messages to UDP port 1027. I have also seen stray packets to UDP port 1028.

Lawrence Baldwin and I recently modified the myNetWatchman WinPopup tester to send messages to both the endpoint mapper UDP port, 135, and also to UDP ports 1025-1029, inclusive:
»Update: Windows Messenger Spam

Hopefully, this is a more realistic test of what is happening now.

Philip Sloss
--
(Thanks, anonymous!) Feedback? e-mail: stuff@lupwa.org ]]> http://www.dslreports.com/forum/remark,7980623 Tue, 16 Sep 2003 10:25:55 EDT Re: Messenger Spam on 1026 - Bad News Kids http://www.dslreports.com/forum/remark,7980551 Plasticman : Blake

I have had the same issue from the same person at
64.156.39.12 : 666

I have caught this in my firewall logs. I have reported this person to his isp multiple times, including firewall logs and called them. They refuse to do anything about it.

Plasticman
--
Life is Like Your ISP.... You Never Know If You will get any Help]]> http://www.dslreports.com/forum/remark,7980551 Tue, 16 Sep 2003 10:14:04 EDT Re: Messenger Spam on 1026 - Bad News Kids http://www.dslreports.com/forum/remark,7979984 kpatz : Also, from what I've heard is the spammer doesn't have to "listen" for the response either, unless they want to confirm that the spam was received. By setting certain flags in the RPC data the spam will pop up with no handshake required, thus allowing mass "mailing" of messenger spam Slammer style, and the source IPs can even be spoofed.

I've been running a listener program, similar to your PortPuker (initially on 135, but now I run it on 1026-1028) on my Linux box and have captured over 2,300 messenger spams so far. The majority of them, ironically, are advertising ways to stop messenger spam.

Of course the good news is this garbage is easy to block, preferably with a firewall, or by turning off the Messenger service. Still, how much bandwidth is being wasted on this garbage.

I like that name PortPuker. :) I've made utilities with cool names in the past, my favorite is when I write data import utilities and call them DataSuckers. :)

KJP
[text was edited by author 2003-09-16 08:32:47]
]]> http://www.dslreports.com/forum/remark,7979984 Tue, 16 Sep 2003 08:32:13 EDT Re: Messenger Spam on 1026 - Bad News Kids http://www.dslreports.com/forum/remark,7979713 BlitzenZeus : Link fix:
»www.linklogger.com/portpuker.htm]]> http://www.dslreports.com/forum/remark,7979713 Tue, 16 Sep 2003 07:26:00 EDT Messenger Spam on 1026 - Bad News Kids http://www.dslreports.com/forum/remark,7979685 Link Logger : Today my interest in the recent flood of UDP port 1026 drove me to write PortPuker, which allows me to take captures from PortPeeker and bring them into the lab where I can conduct some experiments on the traffic in question.

What I was interested in was:
1. Is it possible to show Messenger Service spam without an initial hit to UDP port 135 (like how Net Send works).
2. What if any thing is returned to the spammer for a successful display of their spam.
3. What are the implications of this new delivery technique.

First I captured and put the following UDP port 1026 capture of a suspicious spam message into PortPuker:

64.156.39.12 : 666 Length = 541 bytes : MD5 = A7936DEB322AE7C73F3886C1134CC078
--- 9/14/03 02:00:35.060
0000 04 00 28 00 10 00 00 00 00 00 00 00 00 00 00 00 ..(.............
0010 00 00 00 00 00 00 00 00 F8 91 7B 5A 00 FF D0 11 ..........{Z....
0020 A9 B2 00 C0 4F B6 E6 FC 31 31 30 31 30 30 31 30 ....O...11010010
0030 30 30 31 31 31 30 31 30 00 00 00 00 01 00 00 00 00111010........
0040 00 00 00 00 00 00 FF FF FF FF CD 01 00 00 00 00 ................
0050 08 00 00 00 00 00 00 00 08 00 00 00 57 61 72 6E ............Warn
0060 69 6E 67 00 04 00 00 00 00 00 00 00 04 00 00 00 ing.............
0070 59 6F 75 00 9D 01 00 00 00 00 00 00 9D 01 00 00 You.............
0080 7E 2D 7E 2D 7E 2D 7E 2D 7E 2D 7E 7E 2D 7E 2D 7E ~-~-~-~-~-~~-~-~
0090 2D 7E 2D 20 48 6F 77 20 54 6F 20 44 69 73 61 62 -~- How To Disab
00A0 6C 65 20 54 68 65 73 65 20 50 6F 70 75 70 73 20 le These Popups
00B0 2D 7E 2D 7E 2D 7E 2D 7E 2D 7E 2D 7E 7E 2D 7E 2D -~-~-~-~-~-~~-~-
00C0 0D 0D 41 20 6E 65 77 20 77 61 76 65 20 69 6E 20 ..A new wave in
00D0 49 6E 74 65 72 6E 65 74 20 61 64 76 65 72 74 69 Internet adverti
00E0 73 69 6E 67 20 69 73 20 63 6F 6D 69 6E 67 2E 20 sing is coming.
00F0 49 74 73 20 63 61 6C 6C 65 64 20 74 68 65 20 4D Its called the M
0100 65 73 73 65 6E 67 65 72 0D 73 65 72 76 69 63 65 essenger.service
0110 20 61 6E 64 20 69 74 73 20 62 75 69 6C 74 20 64 and its built d
0120 69 72 65 63 74 6C 79 20 69 6E 74 6F 20 79 6F 75 irectly into you
0130 72 20 57 69 6E 64 6F 77 73 20 6F 70 65 72 61 74 r Windows operat
0140 69 6E 67 20 73 79 73 74 65 6D 2E 0D 49 74 20 69 ing system..It i
0150 73 20 6F 6E 6C 79 20 61 20 6D 61 74 74 65 72 20 s only a matter
0160 6F 66 20 74 69 6D 65 20 62 65 66 6F 72 65 20 74 of time before t
0170 68 65 20 65 6D 61 69 6C 20 73 70 61 6D 6D 65 72 he email spammer
0180 73 20 74 68 61 74 20 66 69 6C 6C 20 79 6F 75 72 s that fill your
0190 20 69 6E 62 6F 78 0D 6C 65 61 72 6E 20 61 62 6F inbox.learn abo
01A0 75 74 20 74 68 69 73 20 61 6E 64 20 66 6C 6F 6F ut this and floo
01B0 64 20 79 6F 75 20 77 69 74 68 20 70 6F 72 6E 20 d you with porn
01C0 61 6E 64 20 70 79 72 61 6D 69 64 20 73 63 61 6D and pyramid scam
01D0 20 70 6F 70 75 70 73 20 74 68 61 74 0D 6D 6F 6E popups that.mon
01E0 6F 70 6F 6C 69 7A 65 20 79 6F 75 72 20 73 63 72 opolize your scr
01F0 65 65 6E 2E 20 46 69 78 20 74 68 69 73 20 74 6F een. Fix this to
0200 64 61 79 21 0D 0D 56 49 53 49 54 20 3A 20 77 77 day!..VISIT : ww
0210 77 2E 53 74 6F 70 49 74 2E 62 69 7A 00 w.StopIt.biz.

I then aimed this packet at a Win2k system where Services.exe was exposed on UDP port 1031 (note this port is assigned dynamically, but for most systems appears on UDP port 1026, hence the spam traffic to port 1026). A Spam popup appeared on the targeted system and the following data would have been returned to the spammer:

127.0.0.1 : 1031 Length = 84 bytes : MD5 = E041C9F73508BC5DAE56C55C01F110C5
--- 16/09/2003 04:34:03.109
0000 04 02 08 00 10 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 00 00 00 00 00 00 DE EF A6 02 00 00 00 80 ................
0020 E4 EF A6 02 00 00 00 00 31 31 30 31 30 30 31 30 ........11010010
0030 30 30 31 31 31 30 31 30 B8 42 5E 3F 00 00 00 00 00111010.B^?....
0040 00 00 00 00 00 00 FF FF 01 00 04 00 00 00 00 00 ................
0050 00 00 00 00 ....

Which would indicates that the message was successfully displayed on the targeted system so the Spammer can chalk up another successful delivery of his ad (if they were to care).

Final Conclusions

Given the Spammer no longer has to hit a sequence of ports required for a Net Send delivery of Spam, but now only have to hit a single UDP port, they can dramatically increase their spamming rates. SQL Slammer for example hit one UDP port with a single packet and was the fastest propagating worm of all time (note UDP ports do not have any handshaking overhead like TCP ports), so now Spammers are using the same concept to rapidly distribute their spam, with single packet spam messages sent to a single UDP port. This increase in speed would explain the sudden increase in UDP port 1026 traffic. The best defense is to use a firewall to hide all ports from the internet, but at some time perhaps more will have to be done as spammers continue to increased their spamming rates and bandwidth usage to all time new highs.

Screenshots and such are available at »www.LinkLogger.com/portpuker.htm

Blake
--
»www.SonicLogger.com - Logging Software for SonicWall and 3Com
»www.LinkLogger.com - Logging Software for Linksys, Netgear and Zyxel
[Fixed link-RST]
[text was edited by moderator]]]> http://www.dslreports.com/forum/remark,7979685 Tue, 16 Sep 2003 07:18:14 EDT