Anybody recognize these packets?

Published: 2009-09-08
Last Updated: 2009-09-08 15:49:40 UTC
by Rick Wanner (Version: 1)
3 comment(s)

I have been looking at a packet trace sent in by a reader, and have reached a dead end. He has been receiving the packets on his network for better than a month.  The volume is not high enough to be a DOS.  The sources are all over the world, although mostly high-speed customers. I was hoping one of you may have seen these packets before...

The packets are all UDP. The source ports vary, but the destination port in this case is always 49261.  The data portion of the packets is either 35 or 31 bytes.  Although the data changes from source address to source address, for any given source the source port and the data is always the same.

There does not appear to be any return traffic.

The data portion of a typical 35 byte packet will look similar to the following (colon delimited):

 8d:da:d1:17:5d:5c:68:96:cb:45:e7:a7:03:dc:9b:00:00:01:00:0c:00:00:00:c3:02:49:50:40:83:53:43:50:41:02:00

The final portion 49:50:40:83:53:43:50:41:02:00 is identical for every 35 byte data packet.

The data portion of a typical 31 byte packet will look similar to the following:

70:d4:30:05:70:5b:42:43:3a:7b:07:51:ce:f7:49:00:00:01:00:08:00:00:00:c3:83:53:43:50:41:02:00

The final portion 43:50:41:02:00 is identical for every 31 byte data packet.

Anybody seen these before?  Can anybody shed light on what they might be?

 

UPDATE: 

I have a couple of Universities who contacted me indicating that this is related to Limewire.  One sent me packets that were very similar to the ones I received originally.

There also appears to be a Emerging Threats signature to detect this traffic.

Thanks for the help!

-- Rick Wanner - rwanner at isc dot sans dot org

Keywords:
3 comment(s)

Comments

Short answer: no idea.

However, 49261 expressed in hex is C06D, where C0 in decimal is 192 (as often found in 192.168.n.n addresses maybe?). Perhaps the packet was incorrectly decoded OR the sending code has a bug in it.

At the end of the day, it will require tracking down the process and seeing what it's up to, assuming the packet source is not spoofed, it's not inconceivable.

If there has been a programmer error (eg. in cases of packet replay where the IP structure was wrong) then it may take much longer to track down. I have a hunch - ask the person if they run any packet replays on their network at all.

Pity we can't see the entire packet for all packets to see if these kinds of things are happening. Data portion isn't enough.

Other than that, no idea.
Glad you got the answer. I could have sworn I googled that subset of hexes. :)
You'll see that port listed in the Vuze documentation.

Diary Archives