Unexplained Netbios Traffic

[Jon Ziminsky]

Hello!



I have a server that is spewing UDP packets on port 137. Here is a sample of
the capture:



214 4.762671 <hidden> 65.200.10.34
NBNS Name query NBSTAT
*<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>

217 1.771319 <hidden> 24.64.209.155
NBNS Name query NBSTAT
*<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>



The packets are being sent to random public IPs. They are sent in groups of
3. The packets are identical except the destination IP.



The box is running Server2000, and is a VM running on an Ubuntu host. Both
the host and guest are fully patched. It is running eTrust ITM that is fully
patched an up to date on sigs. All AV scans I have ran come back clean. I
also ran the most recent MS Malicious Software removal tool, and it came
back clean as well.



This is the only server in our domain that is exhibiting this behavior.



So far today it has tried to contact over 100 random hosts. I am
concerned... Help please.







Jon

[Guy Harris]

Post by Jon Ziminsky
I have a server that is spewing UDP packets on port 137. Here is a
214 4.762671 <hidden>
65.200.10.34 NBNS Name query NBSTAT
*<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>

NBSTAT queries are often used to resolve an IP address to a NetBIOS
name. 65.200.10.34 is aquaultraviolet.com; might some software on
your server be trying to look up, or access, that host (which hosts
Aqua Ultraviolet's Web server; they're a company in California that
makes sterilization equipment using ultraviolet light) - either on its
own behalf or on behalf of a client? If so, it might be looking up
the NetBIOS name, because it appears that a DNS reverse lookup doesn't
work:

$ host 65.200.10.34
Host 34.10.200.65.in-addr.arpa. not found: 3(NXDOMAIN)

so Windows' reverse-IP-lookup code might try a reverse NetBIOS lookup
if a reverse DNS lookup fails.

Post by Jon Ziminsky
217 1.771319 <hidden>
24.64.209.155 NBNS Name query NBSTAT
*<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>

A reverse DNS lookup of that failed as well:

$ host 24.64.209.155
Host 155.209.64.24.in-addr.arpa. not found: 3(NXDOMAIN)

Unfortunately, I can't reach that host, so I can't find out what it is
- traceroute says:

$ traceroute 24.64.209.155
traceroute to 24.64.209.155 (24.64.209.155), 64 hops max, 40 byte
packets
1 10.0.1.1 (10.0.1.1) 1.358 ms 1.494 ms 5.885 ms

...

7 rc2wh-pos0-7-2-0.vc.shawcable.net (66.163.76.65) 38.386 ms
27.489 ms 25.912 ms
8 rc1so-pos11-0.cg.shawcable.net (66.163.76.9) 44.012 ms 54.625
ms 38.815 ms
9 rd1so-ge2-0-0.cg.shawcable.net (66.163.71.78) 39.274 ms 38.959
ms 38.849 ms
10 * * *

but "shawcable.net" suggests that it might be the address of a Shaw
Cable subscriber - perhaps that subscriber, and something on
aquaultraviolet.com, is trying to access *your* server, and it is, for
example, trying to log the host name of the client, doing a reverse
lookup, first trying DNS, failing, and then trying NetBIOS?

[Jon Ziminsky]

I understand how NetBIOS works... This server has tried to contact 350 hosts
since this morning... All completely random.

The two I posted were examples of the 1000+ packets it has generated thus
far today.

I have used Arin to lookup about 20 of the IPs and they are all over the
board... From China to Amsterdam to the US...

The server in question is behind the corporate firewall, and has no outward
facing ports. The firewall is blocking these packets before they leave the
network.

Attached is a snippet of the capture files, as i tried to post the entire
file and was told by the bot that my message was too big.

[Guy Harris]

Post by Jon Ziminsky
Attached is a snippet of the capture files, as i tried to post the
entire file and was told by the bot that my message was too big.

Are those the only packets coming from that host, or was that capture
done with a filter that only captured NBNS packets? If there's other
traffic coming from that host, is it trying to do DNS reverse lookups
on those IP addresses as well?

[Jon Ziminsky]

It is a filtered capture. I set the Capture filter to only grab packets from
the source that do not have a destination inside my network.

capture filter:
src 192.168.1.23 and not dst net 192.168.0.0 mask 255.255.0.0


Thanks for your help Guy!



Jon

[Guy Harris]

Post by Jon Ziminsky
It is a filtered capture. I set the Capture filter to only grab
packets from the source that do not have a destination inside my
network.
src 192.168.1.23 and not dst net 192.168.0.0 mask 255.255.0.0

So the only ones were NBNS NBSTAT packets? I don't know how DNS is
configured on the machine, but if it were trying to do reverse DNS
lookups, I'd expect to see packets going to a server for the .arpa
domain, which isn't likely to be inside your network. :-)

There might be tools that work on Windows Server 2000 (Network Monitor
3.2 apparently won't) that can identify the process from which
particular packets came; I don't know what tools would do that.

[Jon Ziminsky]

The packets are coming from the "System" process.

[Mirsepassi, Armin]

You can use Port reporter to log traffic

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

and sysinternals process explorer/tcpview for real time view of what is
doing what.

http://technet.microsoft.com/en-us/sysinternals/default.aspx



________________________________

From: wireshark-users-bounces-IZ8446WsY0/***@public.gmane.org
[mailto:wireshark-users-bounces-IZ8446WsY0/***@public.gmane.org] On Behalf Of Jon Ziminsky
Sent: Wednesday, October 01, 2008 4:10 PM
To: Community support list for Wireshark
Subject: Re: [Wireshark-users] Unexplained Netbios Traffic



The packets are coming from the "System" process.

[Frank Bulk]

TDIMon is worth trying.

Frnak

-----Original Message-----
From: wireshark-users-bounces-IZ8446WsY0/***@public.gmane.org
[mailto:wireshark-users-bounces-IZ8446WsY0/***@public.gmane.org] On Behalf Of Guy Harris
Sent: Wednesday, October 01, 2008 2:55 PM
To: Community support list for Wireshark
Subject: Re: [Wireshark-users] Unexplained Netbios Traffic

<snip>

There might be tools that work on Windows Server 2000 (Network Monitor
3.2 apparently won't) that can identify the process from which
particular packets came; I don't know what tools would do that.

[John Martin]

Try running tcpview
(http://technet.microsoft.com/en-us/sysinternals/bb897437.aspx). It's a
better version of netstat that will show attempted as well as
established TCP/UDP sessions. I've used it myself recently to find a
process responsible for mystery traffic.



________________________________

From: wireshark-users-bounces-IZ8446WsY0/***@public.gmane.org
[mailto:wireshark-users-bounces-IZ8446WsY0/***@public.gmane.org] On Behalf Of Jon Ziminsky
Sent: Wednesday, October 01, 2008 3:13 PM
To: Community support list for Wireshark
Subject: Re: [Wireshark-users] Unexplained Netbios Traffic



I understand how NetBIOS works... This server has tried to contact 350
hosts since this morning... All completely random.

The two I posted were examples of the 1000+ packets it has generated
thus far today.

I have used Arin to lookup about 20 of the IPs and they are all over the
board... From China to Amsterdam to the US...

The server in question is behind the corporate firewall, and has no
outward facing ports. The firewall is blocking these packets before they
leave the network.

Attached is a snippet of the capture files, as i tried to post the
entire file and was told by the bot that my message was too big.

[Andrew Hood]

Post by Jon Ziminsky
I understand how NetBIOS works... This server has tried to contact 350
hosts since this morning... All completely random.
The two I posted were examples of the 1000+ packets it has generated
thus far today.
I have used Arin to lookup about 20 of the IPs and they are all over the
board... From China to Amsterdam to the US...
The server in question is behind the corporate firewall, and has no
outward facing ports. The firewall is blocking these packets before they
leave the network.
Attached is a snippet of the capture files, as i tried to post the
entire file and was told by the bot that my message was too big.

Virus? Trojan?

I can duplicate that trace with:

nmblookup -A 89.202.193.168

Because your firewall is dropping the traffic you don't see the ICMP
responses:

1 0.000000 <hidden> -> 89.202.193.168 NBNS Name query NBSTAT
*<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>
2 0.346796 89.202.193.168 -> <hidden> ICMP Destination unreachable
(Port unreachable)
3 2.062918 <hidden> -> 89.202.193.168 NBNS Name query NBSTAT
*<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>
4 2.408237 89.202.193.168 -> <hidden> ICMP Destination unreachable
(Port unreachable)

You could try the following suggestion from
http://technet.microsoft.com/en-au/library/bb726981.aspx which will shut
it up completely

UseDnsOnlyForNameResolutions

Key: Netbt\Parameters

Value Type: REG_DWORD—Boolean

Valid Range: 0, 1 (false, true)

Default: 0 (false)

Description: This parameter is used to disable all NetBIOS name queries.
NetBIOS name registrations and refreshes are still used, and NetBIOS
sessions are still allowed. To completely disable NetBIOS on an
interface, see the NetbiosOptions parameter.

[Jon Ziminsky]

Thanks for the reg key... But i want to try and find out what is causing the
problem instead of simply covering it up.

I have a little more information on what is going on, but i am still in the
dark as to what is causing it.

The traffic is being generated by services.exe and is actually going out
over random ports, yet Wireshark as well as TCPDump are seeing it as port
137... Here is what PortReporter is showing:

08/10/2,9:10:11,UDP,2155,0.0.0.0,*,*,252,services.exe,<NT AUTHORITY\SYSTEM>
08/10/2,9:10:18,UDP,2159,0.0.0.0,*,*,252,services.exe,<NT AUTHORITY\SYSTEM>
08/10/2,9:10:50,UDP,2168,0.0.0.0,*,*,252,services.exe,<NT AUTHORITY\SYSTEM>
08/10/2,9:11:20,UDP,2173,0.0.0.0,*,*,252,services.exe,<NT AUTHORITY\SYSTEM>
08/10/2,9:11:47,UDP,2178,0.0.0.0,*,*,252,services.exe,<NT AUTHORITY\SYSTEM>
08/10/2,9:11:52,UDP,2180,0.0.0.0,*,*,252,services.exe,<NT AUTHORITY\SYSTEM>
08/10/2,9:12:11,UDP,2188,0.0.0.0,*,*,252,services.exe,<NT AUTHORITY\SYSTEM>
08/10/2,9:12:17,UDP,2190,0.0.0.0,*,*,252,services.exe,<NT AUTHORITY\SYSTEM>
08/10/2,9:12:37,UDP,2191,0.0.0.0,*,*,252,services.exe,<NT AUTHORITY\SYSTEM>
08/10/2,9:12:42,UDP,2192,0.0.0.0,*,*,252,services.exe,<NT AUTHORITY\SYSTEM>

The 0.0.0.0 address is not obfuscated, that is what is showing in the log...

TCPView shows the port open and close very rapidly.

ProcExplorer doesn't reveal anything deeper than the PID 252 belonging to
services.exe.

I tried running rootkitrevealer, and get an error when installing it. I ran
Spybot(1.6) with the newest sigs, and it came back clean.

I am at a complete loss at this point. I think i will need to wipe and
reload to make myself feel better.

[Jon Ziminsky]

So... I think i found the culprit to this situation.

The traffic is being created by Watchguard's "Log Collector Service." As
soon as the service is stopped, the NetBios traffic halts. I have opened an
issue with them to try and find out why there software is doing this. As
well as why there software is making it so hard to determine the origin of
the traffic. Being a piece of security software, it should be a little more
transparent.



Jon

[Jon Ziminsky]

Hello!



I have a server that is spewing UDP packets on port 137. Here is a
sample of the capture:



214 4.762671 <hidden> 65.200.10.34
NBNS Name query NBSTAT
*<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>



217 1.771319 <hidden> 24.64.209.155
NBNS Name query NBSTAT
*<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>





The packets are being sent to random public IPs. They are sent in groups
of 3. The packets are identical except the destination IP.



The box is running Server2000, and is a VM running on an Ubuntu host.
Both the host and guest are fully patched. It is running eTrust ITM that
is fully patched an up to date on sigs. All AV scans I have ran come
back clean. I also ran the most recent MS Malicious Software removal
tool, and it came back clean as well.



This is the only server in our domain that is exhibiting this behavior.



So far today it has tried to contact over 100 random hosts. I am
concerned... Help please.







Jon