• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 13822
  • Last Modified:

netbios-ns/udp traffic

I have noticed a lot of traffic coming from one ip address to external ip addresses on netbios-ns/udp 137.  These happen every few seconds from this paticular pc.  Right now i have disable netbios over tcp/ip but i want to know what is causing this.  Is this malware of some kind?

here is an example of the watchguard traffic monitor logs

2012-04-02 18:17:39 Primary Allow 10.0.0.78 2.94.191.1 netbios-ns/udp 137 137 1-Data LAN 0-External Allowed 78 127 (Outgoing-00)  proc_id="firewall" rc="100" src_ip_nat="66.110.177.50"       Traffic

2012-04-02 18:17:41 Primary Allow 10.0.0.78 2.94.191.1 netbios-ns/udp 137 137 1-Data LAN 0-External Allowed 78 127 (Outgoing-00)  proc_id="firewall" rc="100" src_ip_nat="66.110.177.50"       Traffic

2012-04-02 18:17:44 Primary Allow 10.0.0.78 2.95.54.83 netbios-ns/udp 137 137 1-Data LAN 0-External Allowed 78 127 (Outgoing-00)  proc_id="firewall" rc="100" src_ip_nat="66.110.177.50"       Traffic

2012-04-02 18:17:46 Primary Allow 10.0.0.78 2.95.54.83 netbios-ns/udp 137 137 1-Data LAN 0-External Allowed 78 127 (Outgoing-00)  proc_id="firewall" rc="100" src_ip_nat="66.110.177.50"       Traffic

2012-04-02 18:17:49 Primary Allow 10.0.0.78 2.94.203.216 netbios-ns/udp 137 137 1-Data LAN 0-External Allowed 78 127 (Outgoing-00)  proc_id="firewall" rc="100" src_ip_nat="66.110.177.50"       Traffic

2012-04-02 18:17:50 Primary Allow 10.0.0.78 2.94.203.216 netbios-ns/udp 137 137 1-Data LAN 0-External Allowed 78 127 (Outgoing-00)  proc_id="firewall" rc="100" src_ip_nat="66.110.177.50"       Traffic

2012-04-02 18:17:54 Primary Allow 10.0.0.78 2.93.202.87 netbios-ns/udp 137 137 1-Data LAN 0-External Allowed 78 127 (Outgoing-00)  proc_id="firewall" rc="100" src_ip_nat="66.110.177.50"       Traffic

2012-04-02 18:17:55 Primary Allow 10.0.0.78 2.93.202.87 netbios-ns/udp 137 137 1-Data LAN 0-External Allowed 78 127 (Outgoing-00)  proc_id="firewall" rc="100" src_ip_nat="66.110.177.50"       Traffic

2012-04-02 18:17:58 Primary Allow 10.0.0.78 2.95.93.10 netbios-ns/udp 137 137 1-Data LAN 0-External Allowed 78 127 (Outgoing-00)  proc_id="firewall" rc="100" src_ip_nat="66.110.177.50"       Traffic

2012-04-02 18:18:00 Primary Allow 10.0.0.78 2.95.93.10 netbios-ns/udp 137 137 1-Data LAN 0-External Allowed 78 127 (Outgoing-00)  proc_id="firewall" rc="100" src_ip_nat="66.110.177.50"       Traffic

2012-04-02 18:18:03 Primary Allow 10.0.0.78 89.179.204.209 netbios-ns/udp 137 137 1-Data LAN 0-External Allowed 78 127 (Outgoing-00)  proc_id="firewall" rc="100" src_ip_nat="66.110.177.50"       Traffic

Please help
0
IKtech
Asked:
IKtech
  • 6
  • 5
  • 3
  • +3
1 Solution
 
AnuroopsunddCommented:
137 is used for netbios name resolution for Windows networking / file and
print sharing.
0
 
Adam BrownSr Solutions ArchitectCommented:
That definitely looks like malware. The Destination IP addresses are in Russia, so.

There's absolutely no reason traffic should be leaving your network on port 137, so it's safe to put an explicit Deny into your firewall policy for that port. I would also go through the computer that is sending this traffic with a fine toothed comb looking for malware.
0
 
AnuroopsunddCommented:
Right... this should not be opened at internet side and should only be accessible from internal network.
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
IKtechAuthor Commented:
i am reinstalling the OS on this PC and i will add the deny rule.  Thanks for the advice.
0
 
pand0ra_usaCommented:
UDP 137 (which is probably encapsulated in TCP/IP) is the netbios name service port (sort of a DNS lookup), this is what your computer uses to find and tell others about workgroups. This activity you are seeing is due to the behavior of Windows servers that use NetBIOS (as well as DNS) to resolve IP addresses to names using the "gethostbyaddr()" function. As users behind the firewalls surf Windows-based web sites, those servers will frequently respond with NetBIOS lookups. Within Microsoft's Windows file sharing, these lookups are similar to DNS in that they resolve an IP to a computer name and back. While many of these lookups are harmless and may be performed automatically if DNS or reverse DNS fails, they are also a first step to enumerate and maybe exploit open file shares.

For future reference, you should block all outgoing communications except for ports you plan on using (80, 443, etc). Not sure it was malware, need more info before coming to that conclusion. Having a proxy in place can further mitigate issues like this as well, depending on how it is configured.
0
 
Adam BrownSr Solutions ArchitectCommented:
As users behind the firewalls surf Windows-based web sites, those servers will frequently respond with NetBIOS lookups

Not really. NetBIOS lookups don't often cross broadcast boundaries (NetBIOS is a broadcast based protocol, after all). As such, you should never really see NetBIOS traffic crossing from one network into another unless you are utilizing WINS. Particularly not from the Internet. Further, Windows web servers don't do any kind of communication over NetBIOS for web traffic. Ever. At all. They use port 80/443 by default or whatever port is specified. That's it. I'm pretty well convinced that this is malware for two reasons: 1. NetBIOS going out of the network is unnecessary and unlikely to occur in normal operations. Even SMB doesn't *require* NetBIOS unless you're browsing for shares on a local network. 2. The destination of these packets: 2.94.203.216, or one of the IPs listed as a destination from the original post, is an IP in Russia. Russia's a very common source for Malware. You can check that by using an IP Lookup tool. End conclusion, there's no way this is legitimate traffic.

It should also be noted that most Windows Firewall configurations allow port 137, so it makes sense that it would be a good port to use for Malware communications and callhomes.
0
 
pand0ra_usaCommented:
"NetBIOS lookups don't often cross broadcast boundaries"
When _not_ encapsulated in TCP/IP that is true (which it often is encapsulated).

The default setting for TCP/IP (v4) in Windows is:
Default: Use NetBIOS setting from the DHCP server. If static IP address is used or the DHCP server does not provide NetBIOS setting, ***ENABLE*** NetBIOS over TCP/IP.

"Windows web servers don't do any kind of communication over NetBIOS for web traffic."
I can authenticate against a Windows web server using my Windows credentials, look at Windows shares, etc (if the ports are open). IKtech had those ports open.

"Further, Windows web servers don't do any kind of communication over NetBIOS for web traffic."
I understand you are confused about the issue I am referring to.

"Even SMB doesn't *require* NetBIOS unless you're browsing for shares on a local network"
Netbios is easily encapsulated in TCP/IP which can allow you to access Windows shares over the Internet. I've done it before on penetration tests (authorized) against US government sites.

"NetBIOS going out of the network is unnecessary and unlikely to occur in normal operations."
I agree, this is bad BUT this does not conclusively point to malware (and yes it could be malware). It could easily be a hacker trying to do things like a Null session.

"The destination of these packets: 2.94.203.216"
Yep, I agree, this is bad. Russia is ALSO known for having a lot of hackers not just malware. I think you are jumping to a easy conclusion that may or may not be correct (but easily possible). It could just as easy be someone trying to navigate IKtech's share(s) as a recon, probe, or attack.
0
 
Adam BrownSr Solutions ArchitectCommented:
I can authenticate against a Windows web server using my Windows credentials

This does not use NetBIOS unless it's a *really* old web application. Windows Credentials are not passed with NetBIOS any longer and have not been since Windows NT. The credentials are typically tunneled through SSH or handled with NTLM/NTLMv2 encryption and the authentication hashing and comparison is handled entirely on the server. This does not use any additional ports and you will never ever see Web Authentication traffic in communication with a Windows Web Server go over any port other than the one used for the web site itself.

look at Windows shares, etc (if the ports are open)

This is not web traffic.  If anyone has access to a file share over the Internet, those ports should be closed post-haste. There are *much* better ways to allow access to file shares without exposing them to the world.

Netbios is easily encapsulated in TCP/IP which can allow you to access Windows shares over the Internet. I've done it before on penetration tests (authorized) against US government sites.

It *can* but it's outright stupid to do so when you can do the same using SMB directly without NetBIOS.

Netbios is easily encapsulated in TCP/IP which can allow you to access Windows shares over the Internet. I've done it before on penetration tests (authorized) against US government sites.

I hope you failed whoever you were running that test against. NetBIOS over TCP/IP ports should never be allowed through a perimeter firewall. Period.

To clarify how NetBIOS over TCP/IP works, it allows the use of NetBIOS over ports 137,138, and 139. It doesn't *enforce* it. File shares *can* use NetBIOS for access, but doing so is very outdated and unnecessary since the introduction of the SMB protocol, which allows access to file shares over port 445 without the need to open NetBIOS ports. If you want to access the file shares with really old computers (I'm talking NT4, here) you need NetBIOS over TCP/IP. Otherwise it serves no real purpose other than opening a hole. The only thing that NetBIOS *has* to be used for is for populating the Network Browsing feature in Windows XP and previous and, if you really push it, adding computers to a domain using its NetBIOS name. Windows Vista and 7 don't utilize it for anything. So, in short, IKTech, if you have NetBIOS ports open on your firewall (As pand0ra_usa suggests you do), close them and implement a VPN to allow remote users to access your shares.
0
 
Russell_VenableCommented:
Not having specific details of your network make it hard to diagnose the exact issue. You could have a client that is connecting remotely or a intruder. Either way its definitely someone outside of your network and if your asking questions about it. You did the right thing by blocking the port.

Usually as stated above a lot of suspicious traffic comes from Russia as they do not have the same laws we have in place that restrict and control attacks like these.Though, coming from that range it might be part of one there anonymous traffic services.

2.94.191.1(corbina) specific is blacklisted on 5 public black lists and known for other then honorable content. Mostly known for spam. In fact they have been known to do business with the RBN ( Russian Business Network ). Other wise known as the Russian Syndicate. Do you have a good size mail system? Are you also having trouble with spam?

 I would thoroughly check your logs, re-evaluate currently installed software for vulnerabilities, check other user traffic as well. In most cases you will find more suspicious traffic in the internal portions of your network by the logs and find out what they where doing and looking for(Assuming you log internal as well).

Can you give any specifics on work environment and installed software? Might be able to give you some advice if there is anything found from your information given. I have already patched quite a few personnel's computers this week. If your seeing this kind of traffic I would assume your not utilizing RDP outside your network as well? If so good on you. One of the main attacks deployed are targeted at allowing a attacker to upload, store, and possibly run from the platform expanding there "network" of compromised machines. I would assume your company has something to offer if it is indeed a intrusion.

Again its worth its weight in gold to find out where it came from, but you already know this.
0
 
IKtechAuthor Commented:
This ended up being generated by my watchguard log server.  When i stop the service for the log server the traffic stops.  I have put in a ticket to watchguard to find out why this is happening but it made me feel a little better to know that it wasn't some sort of malware.  Thanks Experts!  I'll post when i know more.
0
 
pand0ra_usaCommented:
IKtech, how does that explain the requests going to Russia? Or is that a separate issue?
0
 
IKtechAuthor Commented:
pand0ra_usa, I don't know.  That's what i'm hoping to find out.  After reinstalling the OS on this PC and reinstalling the watchguard log server all the same ip addresses started showing up in the traffic monitor.  If i stop the service for the the log server the traffic stops.  Some of the other ip addresses that i found in the logs originated in korea, japan, and a few in the states.  I'm hoping watchguard support can answer that question.
0
 
pand0ra_usaCommented:
Ah, ok. Good luck.
0
 
Russell_VenableCommented:
Sounds fishy and not normal to me. Would really like to know why a firewall is conducting this kind of traffic as well. Looking for to your update.
0
 
ChiefITCommented:
Let's get an better idea of your network. Most likely, you DON'T NEED the WINS/NETBIOS port open for any reason. It's a great security feature to block all TCP/UDP traffic over port 137. In fact, many ISPs block this port as well as the traditional Netbios ports of 138, and 139.


Does your company have remote sites, or VPN clients?
0
 
IKtechAuthor Commented:
I give up with watchguard support.  They don't have an explanation for why just giving me suggestions listed above.  Disable netbios on the network adapter and block the traffic at the firewall.  Sorry gents but i still don't know why this was happening.
0
 
pand0ra_usaCommented:
Another thing you could try is install "process hacker". That may be able to tell you what process is pulling this off.

http://processhacker.sourceforge.net/
0
 
IKtechAuthor Commented:
I already know it is the watchguard logging service that is doing this.  Disabling netbios on the net adapter has taken care of the problem.  Thanks!
0
 
IKtechAuthor Commented:
disable netbios on net adapter
0

Featured Post

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

  • 6
  • 5
  • 3
  • +3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now