Messenger spam to UDP 4081 and 2

Discussion in 'Computer Security' started by Mark, Dec 7, 2005.

  1. Mark

    Mark Guest

    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
    Mark, Dec 7, 2005
    #1
    1. Advertising

  2. Mark

    Moe Trin Guest

    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, Dec 7, 2005
    #2
    1. Advertising

  3. Mark

    Mark Guest

    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
    Mark, Dec 7, 2005
    #3
  4. Mark

    Moe Trin Guest

    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, Dec 8, 2005
    #4
  5. Mark

    Mark Guest

    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
    Mark, Dec 9, 2005
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Tom
    Replies:
    2
    Views:
    5,171
  2. Donald Oldag
    Replies:
    0
    Views:
    951
    Donald Oldag
    Mar 7, 2004
  3. C A Preston

    Spam-Spam and more Spam

    C A Preston, Apr 12, 2004, in forum: Computer Support
    Replies:
    2
    Views:
    564
    Hywel
    Apr 12, 2004
  4. anthonyberet
    Replies:
    0
    Views:
    918
    anthonyberet
    Oct 8, 2006
  5. Clwddncr
    Replies:
    6
    Views:
    667
    Dave - Dave.net.nz
    Feb 7, 2005
Loading...

Share This Page