«

I'm puzzled by this one so I thought I'd send it out to the list to
see if you all could provide me some clues. I regularly get UDP
connection attempts that are simply messenger spam. We all do. But,
some of them start out trying to send to the regular messenger ports,
(1024 - 1031...). And, then, it appears, when that doesn't work it
sends exactly two packets to UDP ports 4081 and 2.

I did some searching on dshield's database, and I'm far from being the
only one that is being probed on those ports from those China based hosts.

So, my question is, what would the purpose be to send to those ports?

As far as I know, Windows messenger wouldn't normally be listening on
those ports, so why bother sending to them?

As far as I can tell the payload is identical between the port 4081 and
port 2 packets but I haven't had the time to dissect the header
information to see if there is anything interesting in there. (If no
one else does, I will try to after tomorrow)

Here are the two packets if someone that has more time than myself is
interested in dissecting the header:

07:16:59.639510 IP (tos 0x0, ttl 48, id 0, offset 0, flags [DF], proto
17, length: 381) 202.111.173.85.42022 > 1.1.1.1.4081: [udp sum ok] UDP,
length 353
0x0000: 4500 017d 0000 4000 3011 4355 ca6f ad55 E..}..@.0.CU.o.U
0x0010: 0101 0101 a426 0ff1 0169 7e86 0400 2800 ...}.&...i~...(.
0x0020: 1000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 f891 7b5a 00ff d011 a9b2 00c0 ......{Z........
0x0040: 4fb6 e6fc 0000 0000 0000 0000 0000 0000 O...............
0x0050: 0000 0000 0000 0000 0100 0000 0000 0000 ................
0x0060: 0000 ffff ffff 1101 0000 0000 1000 0000 ................
0x0070: 0000 0000 1000 0000 5359 5354 454d 0000 ........SYSTEM..
0x0080: 0000 0000 0000 0000 1000 0000 0000 0000 ................
0x0090: 1000 0000 414c 4552 5400 0000 0000 0000 ....ALERT.......
0x00a0: 0000 0000 cd00 0000 0000 0000 cd00 0000 ................
0x00b0: 5354 4f50 2120 5379 7374 656d 2068 6173 STOP!.System.has
0x00c0: 2065 6e63 6f75 6e74 6572 6564 2061 6e20 .encountered.an.
0x00d0: 496e 7465 726e 616c 2045 7272 6f72 0a59 Internal.Error.Y
0x00e0: 6f75 7220 7265 6769 7374 7279 2069 7320 our.registry.is.
0x00f0: 636f 7272 7570 7465 642e 0a0a 5765 2072 corrupted...We.r
0x0100: 6563 6f6d 6d65 6e64 2061 2063 6f6d 706c ecommend.a.compl
0x0110: 6574 6520 7379 7374 656d 2073 6361 6e2e ete.system.scan.
0x0120: 0a0a 5669 7369 740a 0a77 7777 2e54 6865 ..Visit..www.The
0x0130: 5265 6746 6978 6572 2e63 6f6d 0a0a 546f RegFixer.com..To
0x0140: 2072 6570 6169 7220 6e6f 770a 0a0a 4641 .repair.now...FA
0x0150: 494c 5552 4520 544f 2041 4354 204e 4f57 ILURE.TO.ACT.NOW
0x0160: 204d 4159 204c 4541 4420 544f 2053 5953 .MAY.LEAD.TO.SYS
0x0170: 5445 4d20 4641 494c 5552 4521 00 TEM.FAILURE!.

07:16:59.642424 IP (tos 0x0, ttl 48, id 0, offset 0, flags [DF], proto
17, length: 381) 202.111.173.85.42022 > 1.1.1.1.2: [udp sum ok] UDP,
length 353
0x0000: 4500 017d 0000 4000 3011 4355 ca6f ad55 E..}..@.0.CU.o.U
0x0010: 0101 0101 a426 0002 0169 8e75 0400 2800 ...}.&...i.u..(.
0x0020: 1000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 f891 7b5a 00ff d011 a9b2 00c0 ......{Z........
0x0040: 4fb6 e6fc 0000 0000 0000 0000 0000 0000 O...............
0x0050: 0000 0000 0000 0000 0100 0000 0000 0000 ................
0x0060: 0000 ffff ffff 1101 0000 0000 1000 0000 ................
0x0070: 0000 0000 1000 0000 5359 5354 454d 0000 ........SYSTEM..
0x0080: 0000 0000 0000 0000 1000 0000 0000 0000 ................
0x0090: 1000 0000 414c 4552 5400 0000 0000 0000 ....ALERT.......
0x00a0: 0000 0000 cd00 0000 0000 0000 cd00 0000 ................
0x00b0: 5354 4f50 2120 5379 7374 656d 2068 6173 STOP!.System.has
0x00c0: 2065 6e63 6f75 6e74 6572 6564 2061 6e20 .encountered.an.
0x00d0: 496e 7465 726e 616c 2045 7272 6f72 0a59 Internal.Error.Y
0x00e0: 6f75 7220 7265 6769 7374 7279 2069 7320 our.registry.is.
0x00f0: 636f 7272 7570 7465 642e 0a0a 5765 2072 corrupted...We.r
0x0100: 6563 6f6d 6d65 6e64 2061 2063 6f6d 706c ecommend.a.compl
0x0110: 6574 6520 7379 7374 656d 2073 6361 6e2e ete.system.scan.
0x0120: 0a0a 5669 7369 740a 0a77 7777 2e54 6865 ..Visit..www.The
0x0130: 5265 6746 6978 6572 2e63 6f6d 0a0a 546f RegFixer.com..To
0x0140: 2072 6570 6169 7220 6e6f 770a 0a0a 4641 .repair.now...FA
0x0150: 494c 5552 4520 544f 2041 4354 204e 4f57 ILURE.TO.ACT.NOW
0x0160: 204d 4159 204c 4541 4420 544f 2053 5953 .MAY.LEAD.TO.SYS
0x0170: 5445 4d20 4641 494c 5552 4521 00 TEM.FAILURE!.

--
Mark

On Wed, 07 Dec 2005, in the Usenet newsgroup alt.computer.security, in article
<MUtlf.625320$xm3.411342@attbi_s21>, Mark wrote:

>But, some of them start out trying to send to the regular messenger ports,
>(1024 - 1031...). And, then, it appears, when that doesn't work it
>sends exactly two packets to UDP ports 4081 and 2.

Curious why you think that the "doesn't work" is needed before sending to
these other ports. Are you sending ICMP3/1 (or indeed anything) in response
to any of the UDP?

>I did some searching on dshield's database, and I'm far from being the
>only one that is being probed on those ports from those China based hosts.

Don't forget UDP is connectionless - meaning that the source address could
be faked. Last month, I did stats on messenger spam on the firewall (mostly
on 1025 - 1035), and noted that roughly 3 percent had source addresses that
IANA hasn't even assigned, much less an RIR assigning it. Examples were
seen in the 1.x.x.x, 94.x,x,x, and 112.x.x.x blocks.

> 0x0120: 0a0a 5669 7369 740a 0a77 7777 2e54 6865 ..Visit..www.The
> 0x0130: 5265 6746 6978 6572 2e63 6f6d 0a0a 546f RegFixer.com..To

Domain name: theRegFixer.com

Registrant Contact:
RegFixer
Tony Klass ()
+1.85288282881
Fax: +1.85288282881
24 Cleser st
HunHum, KA 01991
HK

Creation date: 21 Oct 2005 17:43:15

Another throw-away registration - surprised it's still in use.

[compton ~]$ host www.theRegFixer.com
www.theRegFixer.com has address 69.25.142.3
[compton ~]$ host 69.25.142.3
Host not found.
[compton ~]$ whois 69.25.142.3
[whois.arin.net]
Internap Network Services PNAP-12-2002 (NET-69-25-0-0-1)
69.25.0.0 - 69.25.255.255
eNom INAP-SEF-ENOM-1761 (NET-69-25-142-0-1)
69.25.142.0 - 69.25.142.63

# ARIN WHOIS database, last updated 2005-12-06 19:10

CustName: eNom
Address: 2002 156th Ave NE
City: Bellevue
StateProv: WA
PostalCode: 98008
Country: US

Figures. Much of the messenger spam I've looked at was pointing at one of
those hosts. And if you look in n.a.n-a.blocklisting, that IP space isn't
exactly unknown for spam problems.

Old guy

Moe Trin wrote:
> On Wed, 07 Dec 2005, in the Usenet newsgroup alt.computer.security, in article
> <MUtlf.625320$xm3.411342@attbi_s21>, Mark wrote:
>
>
>>But, some of them start out trying to send to the regular messenger ports,
>>(1024 - 1031...). And, then, it appears, when that doesn't work it
>>sends exactly two packets to UDP ports 4081 and 2.
>
>
> Curious why you think that the "doesn't work" is needed before sending to
> these other ports. Are you sending ICMP3/1 (or indeed anything) in response
> to any of the UDP?
>
Yeah, that was kind of a strange way to word things on my part. Now
that I re-read that it kind of implies that I'm saying they know the
spam attempt didn't work. In this case, they wouldn't know (or care)
that they "didn't work" because the firewall they are hitting is just
dropping the packets on the floor. No response at all.

I guess my point really was, why would they even bother sending to those
ports? I've never heard of windows messenger listening on those ports
so why waste the packets? (I know, packets are cheap but...) Unless
they are looking for the presence of some other process (malware?)
listening on those ports. Is anyone aware of anything, I sure can't
find anything.

Thanks,

Mark

On Wed, 07 Dec 2005, in the Usenet newsgroup alt.computer.security, in article
<g7Klf.609584$_o.81228@attbi_s71>, Mark wrote:

>I guess my point really was, why would they even bother sending to those
>ports? I've never heard of windows messenger listening on those ports
>so why waste the packets? (I know, packets are cheap but...) Unless
>they are looking for the presence of some other process (malware?)
>listening on those ports.

I have no idea either. My first guess would be that someone fumble-fingered
the script. An even wilder guess would be that someone was looking for
live systems. Many people seem to run their "personal firewalls" on a
"block this port" mode, rather than "accept this and that, and default
reject/drop everything else", so sending packets to an unexpected port
might provoke a reply. But then, while costs are very low, adding two more
ports to the list of six to ten is going to increase the cost by a
significant percentage. Last month, I was seeing about 1000 messenger
spams a day, averaging around 470 octets. If you project that across a
/16, that's 30 gigabytes a day, or about 360 kilobytes/second. That's an
significant chunk of someone's bandwidth.

>Is anyone aware of anything, I sure can't find anything.

Same here.

Old guy

Moe Trin wrote:
> On Wed, 07 Dec 2005, in the Usenet newsgroup alt.computer.security, in article
> <g7Klf.609584$_o.81228@attbi_s71>, Mark wrote:
>
>
>>I guess my point really was, why would they even bother sending to those
>>ports? I've never heard of windows messenger listening on those ports
>>so why waste the packets? (I know, packets are cheap but...) Unless
>>they are looking for the presence of some other process (malware?)
>>listening on those ports.
>
>
> I have no idea either. My first guess would be that someone fumble-fingered
> the script. An even wilder guess would be that someone was looking for
> live systems. Many people seem to run their "personal firewalls" on a
> "block this port" mode, rather than "accept this and that, and default
> reject/drop everything else", so sending packets to an unexpected port
> might provoke a reply.

Given that I couldn't find any known malware that would listen on those
ports; I was actually leaning towards your second, wilder guess. I
have in practice seen quite a few firewalls set to quietly drop what is
considered 'junk' but send an ICMP type 3 code 'something' in response
to everything else.

No matter how I look at it, I don't see how anyone could have just
accidentally put those ports in a script/program/etc... When I was
considering this, I was assuming the data the script uses to decide what
ports to probe is either decimal, hexadecimal or binary. Also, I
assumed the typo would be only one of the characters.

Look at the numbers:

Decimal Hex Binary
4081 FF1 111111110001
2 2 10
1024 400 10000000000
/\
|
\/
1035 40B 10000001011

That looks like it would be hard to typo. I think they are looking for
something. What they are looking for, I not sure of.

> But then, while costs are very low, adding two more
> ports to the list of six to ten is going to increase the cost by a
> significant percentage.

That's a good point. That's around 20%-30% overhead. Which again
implies to me that probes are looking for something. But, if they are
looking for something (either the presence of their software, or just
any live system) then the source address of the packets probably isn't
spoofed. Otherwise, how would they know they had a 'live' one? (Since
UDP is a connectionless protocol.) Unless of course, the payload of the
message tells the 'zombie' (for lack of a better word) who to report
back to.

Thanks for letting me bounce my thoughts off of you.

Mark