Overblog
Editer l'article Suivre ce blog Administration + Créer mon blog
16 mars 2011 3 16 /03 /mars /2011 23:58

I'm gonna deal here with a few tips to monitor, and even detect, real network intrusion cases.

 

Just for the records, Netbios is not a protocol, it is a network interface. NetBT (Netbios over TCP) is a protocol, for instance. Nowadays, MS networks use SMB shares and protocols.

 

Then, let me say that the Windows culture of a firewall tends to block almost every little packet that comes from the network, but not what goes from the computer to the network! Thus, even some kindda hardened Windows network configurations will just be verbose over the network, as soon as the RJ45 cable is plugged...

And that's just what we need to detect the intrusion!

 

 

First of all: protocols that are not related to pure MS Networks (ie: SMB):

 

- SSDP Enabled by default in Vista and Win 7. Multicast.

It is being sent as HTTP over UDP, port 1900. IP 239.255.255.250.

 

- Bonjour (Apple): Multicast DNS

It comes from Apple system, but also from Windows OS where users installed any of the Apple software: iTunes, QuickTime, Safari, MobileMe... (the service is called "Bonjour")

It is being sent over UDP, port 5353, IP 224.0.0.251.

 

- WPAD (Web Proxy Audto-Discovery): DNS resolution & NetBU/NetBT (resolution) broadcast 

It comes from computers where the option like "auto detect configuration" has been validated as a proxy configuration for the browser.

 

- DHCP (discover): It comes from computers set to automaticaly obtain network configuration through DHC.

It uses UDP, port 68.

 

- IGMP: It comes from many computers running different systems, and very often Apple software.

It is being sent over UDP, port 3702, to IP 239.255.255.250.

 

- WS Discovery: It comes from many computers running Vista/Win7.

It is being sent to IP  224.0.0.22,   and with requests like: "V3 Membership Report / Join group 224.0.0.252 for any sources"

 

 

 

Then, what to watch in a regular MS network environment:

 

- NBNS: computers that are connected to a network, with "MS networks" compliance, will broadcast their name over UDP, and port 138.  You'll see any computer's name within your network broadcast segment 

So, if you use Wireshark, I suggest you to set a filter like:

udp.port==138

 

 

- browser (NetBT): used when a computer wants to announces itself as a "Master browser" of a network. This is certainly not normal when there are WINS servers!

So the wireshark filter becomes:

udp.port==138 || browser

 

 

- LLMNR (RFC 4795): used when no local DNS was found on the network. It tries to convert names to IP (for example, regarding a Brother printer:  LLMNR  Standard query A BRN001BA927E1C9). Also works for WPAD requests. It is send to 224.0.0.252, port 5355 UDP. Multicast UDP

So the wireshark filter becomes:

udp.port==138 || udp.port==5355 || browser

 

 

- NCSI (Network Connectivity Status Indicator): comes vith Vista and Windows Seven systems. Used to detect/check network connectivity, meaning access to one txt file over HTTP, in Microsoft's point of view.
It is bieing sent first as a DNS request: DNS  Standard query AAAA dns.msftncsi.com.

Please note it is an IPV6 one, that could help to distinguish it from others.
Then, it attempts to download http://www.msftncsi.com/ncsi.txt, so that's: 131.107.255.255  over HTTP.

Obviously, on of the best places to monitor such requets is the firewall, not your own computer...
So, if there should be no Vista/W7 machines on your LAN, the wireshark filter could be: dns.qry.name==dns.msftncsi.com

Else, it is best IMHO to watch: ip.addr==131.107.255.255

 

 

 

- my own experience proves that there are a few transactions that use SMB. Therefore, the filter becomes:

udp.port==138 || udp.port==5355 || browser ||  smb

 

 

In a nutshell:

udp.port==138 || udp.port==5355 || browser || smb || udp.port==68 || udp.port==5353 || udp.port==1900 || udp.port==3702

 

 

- you should now exclude your own IP from the network capture (reminder of syntax: !(ip.addr== %your_IP%) )

 

You could say "hey, I don't mind, I use Linux"... well, pretty wrong, since as long as your linux system wants to be compliant with a Windows network, it will broadcast almost the same traffic than Windows boxes...I do detect intrusions concerning linux and Mac systems, with the same idea!

 

 

Now, here are a few requests that you could also watch, depending on what your standard master/configuration is:

 

- Google Desktop:

DNS    Standard query A desktop3.google.com

 

- Vista/Windows 7 money converter gadget (on the desktop)

  DNS    Standard query response CNAME money.service.co1.cb3.glbdns.microsoft.com

Response type A 65.55.17.39

 

 

 

 

To finish with, for this first run, I suggest to the network admin to keep an eye on:

- WINS servers' logs: Active directory unknown domains lookups, host announcements, master browser announcements

- DNS servers logs: (Active directory) unnkown domains lookups, unknown FQDN lookups

DNS watch was already mentioned in a MISC article, I dont remember the date nor the number (detect network intrusion with DNS).

   

 

Looking for some documentation?

http://support.microsoft.com/kb/188001

http://www.wireshark.org/docs/dfref/b/browser.html

http://isc.sans.edu/port.html?port=139

http://isc.sans.edu/port.html?port=138

http://isc.sans.edu/port.html?port=137

http://isc.sans.edu/port.html?port=445

http://www.hsc.fr/ressources/presentations/srv_res_win/srv_res_win.pdf

http://support.apple.com/kb/HT2463

http://www.tcpipguide.com/free/t_DHCPLeaseAllocationProcess-2.ht

http://msdn.microsoft.com/en-us/library/bb736562%28v=vs.85%29.aspx

 

 

 

 

 

 

 

Partager cet article
Repost0

commentaires