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

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 :-)

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.

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.

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

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.

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.

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

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.

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.

In certain cases when a windows machine isn't able to get an answer using DNS (port 53), it will attempt to use port 137 and/or port 139 to get at least some sort of name to associate with that IP address. I've seen it happen live on my work network so there's really no way you can tell me it doesn't happen.

I'm not sure exactly what versions of windows do it, and I'm not sure weird and twisted configuration has to be in place. The system I saw this behavior on was a Windows NT box which was dual homed (against policy). The box was using netbios on both 137 and 139 to try to resolve an IP address it saw on its second network. The lookups threw up a flag which is how we came to know about his dual homed box.

The "CKAAAAAA" is the netbios name query wildcard. (More proof of a samba box??)


Take a look here: ( look at sample number 6)

http://216.239.53.100/search?q=cache...n&ie=UTF-8</a>


More info here:

http://www.sans.org/y2k/061500.htm

Possible pre attack scan??? Info here: ( notice the high source port )

http://archives.neohapsis.com/archiv...0-01/0222.html


edit str34m3r I thought I just said the same thing!!! :)

I not trying to tell you it DOESN'T do it only why the packets are not the same but perform the same function. :) (notice the use of the WILDCARD "CKAAAAA" sent to the target's port of 137. This type of packet should only been seen going to port 137 , if someone has info on these packets beening sent to 139 PLEASE provide info as I would be very interested in looking into that.) In other word this is NOT a name query (IE: name to IP resolution) but a NAMES query (IE: A query for a listing of netbios names at that host)

HEHEHHE...you've been on this board too long talkng to too many kiddies :D I'm not trying to attack you or prove you wrong. Frankly, I don't care enough for that. But if we ALL take a moment to listen to others we might ALL learn a new thing or two. So if you disagree please explain why and I'll be willing to listen and learn.

Like I said to don the other day..I not interested in "teaching" anyone anything but I would love to share information with other pros.

end of long rant!!!

That ladies and germs is the crux of the matter. Once should only see this type of traffic on
port 137. Anything else and one should start digging.