Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: Packet decode required

  1. #1

    Packet decode required

    Hi all,

    A system Administrator looking after a network in a remote office of mine detected traffic being sent into his network that was targeted a router on his network. He is naturally suspicious of this and has asked me for help. He captured the suspect traffic using IRIS traffic Analyser. his statement (I havent been onsite to view the traffic myself - I'm in the UK and he's in Central america) is that all packets look the same. Hmmm. anyway, the packet he forwarded to me is as follows

    212.x.x.x->200.x.x.x
    Time 9:10:35:689
    0000: 00 07 50 F6 0F 60 00 30 65 2E B5 C0 08 00 45 00 ..P..`.0e.....E.
    0010: 00 4E EC 68 00 00 65 11 25 BE 44 A2 0B 22 C8 3E .N.h..e.%.D.."..
    0020: 2B 76 04 04 00 89 00 3A 78 2B 01 00 00 10 00 01 +v.....:x+......
    0030: 00 00 00 00 00 00 20 43 4B 41 41 41 41 41 41 41 ...... CKAAAAAAA
    0040: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
    0050: 41 41 41 41 41 41 41 00 00 21 00 01 AAAAAAA..!..

    200.x.x.x.is our router. 212.x.x.x is the external address.

    Apparently, IRIS reports this as UDP.

    Can anyone help me decode this packet to get a handle on whats going on?

    What can I feed this information into to get the hex decoded into a more reasonable format, or is there an online reference somewhere that will tell me how to interpret this data?

    Many thanks for your help on this people.

    Alan Mott

  2. #2
    Junior Member
    Join Date
    Feb 2003
    Posts
    15
    It's netbios traffic (a name query), notice ......

    212.x.x.x->200.x.x.x
    Time 9:10:35:689
    0000: 00 07 50 F6 0F 60 00 30 65 2E B5 C0 08 00 45 00 ..P..`.0e.....E.
    0010: 00 4E EC 68 00 00 65 11 25 BE 44 A2 0B 22 C8 3E .N.h..e.%.D.."..
    0020: 2B 76 04 04 00 89 00 3A 78 2B 01 00 00 10 00 01 +v.....:x+......
    0030: 00 00 00 00 00 00 20 43 4B 41 41 41 41 41 41 41 ...... CKAAAAAAA
    0040: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
    0050: 41 41 41 41 41 41 41 00 00 21 00 01 AAAAAAA..!..



    which is a normal signiture of netbios traffic. Someone else may come along can give you a more detailed look at the packet or you can do a Google lookup on Netbios name query packets to port 137.


    EDIT I belive this is SAMBA (Linux) netbios traffic rather than Windows nebios traffic because the source port is 1028 instead of 137.


    DON Port 139 is used for netbios file sharing (session) not name queries.

    http://www.iss.net/security_center/a...39/default.htm

    http://www.iss.net/security_center/a...37/default.htm



    Hope this helps :-)
    Ferengi Rules of Acquisition:

    Rule 59 Free advice is seldom cheap.

  3. #3
    Senior Member
    Join Date
    Dec 2002
    Posts
    110
    This looks like "normal" netbios interrogation traffic. This should be on port 139. As for decoding it use a calculator such as the one supplied in windows. Click on view then click
    on scientific. Input the value into hex and then press decimal for a decimal version. Or just d/l ethereal and input the file into it. This option is probably your best bet. I assume you sanitized
    the ip addresses in the field starting with 08 00 45 00 This should be your src addy. It does not match up with what you wrote though.

  4. #4
    ok, here is my amatuer take on it. I agree with Don and the info he posted. It looks like its coming from someone on a verizon network. It is a udp packet that is fragmented, ttl is 101. The destination ip was odd, I couldnt find anything on it with a nslookup but I had a 200.62.xxx.xxx but would probably go with the router ip you said at the beginning. It is coming from port 1024 on the source computer to port 137 on the destination computer. It did have a fin bit set though for whatever its worth. As for the rest, I have to bow to the more knowledgeable and say its netbios traffic. I dont have enough experience to say otherwise.
    Bolt actions speak louder than words.

  5. #5

    Cool

    Thanks very much for your help, everyone. I decoded the packet by using text2pcap and then importing the result into ethereal. This has allowed me to make some sense of what is going on. Thanks for the tip Don

    Best regards, everyone,

    Alan Mott

  6. #6
    str34m3r
    Guest
    Hey don, I was wondering about that too, but then I went and read the text around where he said it wasn't tcpdump output. I've never worked with iris before, but if you glance through the hex dump, you see the 45 at the end of the first line, which indicates the beginning of the IP header, so the source IP address is '44 A2 0B 22' which still doesn't match up with what he said, but the destinastion address is 'C8 3E 2B 76' which does match up with his story. The odd thing is that the source IP comes from a block of IP addresses which is unassigned according to iana (http://ws.arin.net/cgi-bin/whois.pl?...=100.162.11.34). I'm guessing that the hex before the IP header is the ethernet header, so by using the MAC addresses in the ethernet header, you can tell that the NIC on the router is made by Cisco (00:07:50). No surprises there, but the vendor associated with the source is Apple Computers (00:30:65). Uh oh. So that means they (or someone else) has a Mac sitting just outside their router with a reserved IP address broadcasting Netbios traffic. Doesn't that sound like a secure scenario?

    Edit: Obake, while you are correct that 139 is usually used for file sharing, some versions/configurations of windows do attempt to do the equivalent of a DNS lookup on port both 137 and 139. Why? No one knows. If Microsoft knew the answer to that, maybe their OS's network stack wouldn't suck. But since this is port 137, it's neither here nor there.

  7. #7
    Sounds as secure as the US being gaurded by girl scouts. I guess experience plays alot on decoding packets and garnering a general scenario of how things played out. This is has been interesting. I learned alot.
    Bolt actions speak louder than words.

  8. #8
    Thanks for the info str34mer on the NIC vendors. The source IP address in the packet doesn't match up with what the SA who reported this claims Iris reportred. not sure why at the moment but will llook into it. The packet sources from someone on the internet sending Netbios name queries into our router. Hence why we looked further into it.

    My problem now is trying to make sense of the Netbios fields. The RFC is hard work. Anyone know of a good netbios protocol primer?

    Cheers,

    Alan Mott

  9. #9
    str34m3r
    Guest
    The 1 is awful close to the 2, so it's very easy to mistype a 200 instead of a 100. I wasn't trying to sound confrontational, it's just that normally when I deal with this kind of stuff, it's because there's a user who might be in a bit of trouble. So of course since they don't want to be in trouble, they only give me part of the story or modify parts of the story to get themselves out of trouble. So I guess I've learned to always test their statements against the facts that are in front of me to find out if everything matches up.

  10. #10
    Junior Member
    Join Date
    Feb 2003
    Posts
    15
    str34m3r


    A DNS lookup isn't a netbios name lookup and this is a netbios name query NOT a dns "name query". (which I belive is the point your trying to make??)

    If I remember correctly Windows netbios name queries have a destination and source port of 137 UDP.


    The netbios service enumeration you refer to does take place over port 139 TCP.
    Ferengi Rules of Acquisition:

    Rule 59 Free advice is seldom cheap.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •