Windows Server - WORM? ... server generating NBT-NS (port 137) traffic on WAN interface

Hi!

I think one of the SBS2003 servers that I manage recently became infected
with a WORM.

I would like to find out more about what is happening, how the infection
occurred, and how to prevent in the future.

Can anyone recommend a good source of info to help me figure out how to find
out which program(s) are generating this traffic?

NetMonitor does pick up the outbound (port 137) packets being sent to a lot
of different apparently valid IP addresses of businesses around the world.
The WAN interface does have an external router ... with only ports 25, 443,
4125 allowed for inbound ... all SMB outbound (incl port 137) is blocked.

On Oct 10 I noticed that the syslog data from the router went from an
average of a few hundred entries per day to about 1,000 per hour ... only
rejected packets and errors are logged.  Other than scheduled tasks (incl
weekely reboot using shutdown /r) nobody has logged on to this server for at
least a few days before this unauthorized network activity started.  ???

Nobody had logged on to the server for about 10 days prior to this problem
being noticed in the Syslog files ... and no applications are running on the
server that is generating the NBT - NS traffic.  The WAN NIC has NetBios
over TCP/IP disabled.

I cannot see anything obvious ... and cannot locate the specific program
that is generating this traffic.  There is not even a noticeable difference
in system activity.

Have any of you had any experience trouble shooting this type of problem
with Windows SBS2003 server?  I would like to start out by finding which
program(s) are genverating these UDP packets ... and where the list of
target IP addresses is coming from.

Because the external router is blocking the unwanted packets I think I can
leave it running as is to diagnonse the problem ... at least for a few more
days.

Blondie

Why have you jumped to the worm conclusion?  Not to be blunt, but usually
people who jump to conclusions have knowingly been using less than good
practices so they have a reason to have such a suspicion.  Personally I'd
think of a potentially bad program update/patch or a new install might
legitimately be causing the traffic. Another possibility is that another
computer on the network is channeling through the SBS server since you
mentioned a WAN NIC, so I have to assume you are running 2 nics and SBS is
tunneling LAN traffic.  Jumping to a worm seems like quite a leap.

So first, lets check a few things:

1) Run a good packet logging system BETWEEN your SBS LAN (NOT WAN!) Nic and
the switch/hub to the rest of your network. There is no use chasing down
packets on your SBS box if they aren't originating there. We have to target
monitoring on the LAN interface because your router will be logging the
packets as coming from SBS. Technically it is correct, they are...SBS does
NAT so everything on the WAN side of the link will appear to the router as
originating from the SBS server.  Not very helpful.

2) Once you have determined without question which machine is generating the
unexpected traffic then you can grab TCPview from sysinternals
(www.microsoft.com/sysinternals) and use it to try and find the program
opening the port on the offending machine. From there you will at least be
armed with information about the process and do some google searching. Until
you know *what* is trying to throw packets outside of your network, you
can't go about fixing it, or even assuming you know what the problem is.

Hope that helps,

-Cliff

Hello,

Thank you for posting here.

According to your description, I understand that:

You have a concern about the outbound port 137 traffic in the SBS domain.

If I have misunderstood the problem, please don't hesitate to let me know.

Suggestions:
========================
The UDP 137 is related to the NetBIOS Over TCP/IP name service. Please try
to verify the source program that use this port with the following steps:

1. On the SBS server command prompt, type "netstat -anob"

The -b parameter will help to display the executable involved in creating
each connection or listening port.

2. Find out the program that use the UDP 137. If it is the [System], please
try to check whether the netbios over TCP/IP is disabled on the NIC that is
connected to the Internet (If the SBS server is the 2 NICs scenario).

a) Click Start, point to Settings, and then click Network and Dial-up
Connection.
b) Right-click Local Area Connection, and then click Properties.
c) Click Internet Protocol (TCP/IP), and then click Properties.
d) Click Advanced.
e) Click the WINS tab, and then click Disable NetBIOS over TCP/IP.

204279          Direct hosting of SMB over TCP/IP
http://support.microsoft.com/kb/204279

What Is Computer Browser Service?
http://technet.microsoft.com/en-us/library/cc787537.aspx

NetBIOS Over TCP/IP
http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/cnet/cnb
c_imp_wcug.mspx?mfr=true

On the virus issue, I would also like to suggest that you call Microsoft PC
Safety telephone number, 1-866-727-2338 (1-866-PCSAFETY). This service
offers no-charge assistance for virus-related issues or questions.

Also, you can check Microsoft Security and Privacy Web site at:

http://www.microsoft.com/security/.

This Web site offers various articles, updates, tips and tricks, and
resources to protect both home and business computers from virus infection
or attacks.

Hope it helps. If you have any questions or concerns, please do not
hesitate to let me know.


Best regards,
Miles Li

Microsoft Online Partner Support
Microsoft Global Technical Support Center

Get Secure! - www.microsoft.com/security
=====================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Please see comments below ...
----- Original Message -----
From: "Cliff Galiher" <cgaliher@gmail.com>
Newsgroups: microsoft.public.windows.server.sbs
Sent: Tuesday, October 14, 2008 5:16 AM
Subject: Re: WORM? ... server generating NBT-NS (port 137) traffic on WAN
interface



*** Well ... I have used the Web Browser to access some speed test sites in
the past (these have advertising embedded) ... and a few others that I
assumed were safe, while looking info to help with a previous networking
issue on the SBS2003 server itself (problem turned out to be IP Packet
blocking and 'traffic management' - denial of access between the server and
it's remote users by the local phone company ... within the DSL link to the
ISP) ... mostly Microsoft websites.  But not for at least 10 days before the
problem was first detected ... seemed like the best way at the time ... I
access the server with RWW and RDP through a VPN ... when I wanted to
cut-n-paste info between sessions I thought it would be "safe" to use the
Server's Web Brower.  A virus could have been embedded in one of the
advertisements ... but if this was the infection source, the payload did not
activate for over a week ... which seems kind of strange, but certainly
possible.

I thought of a WORM because I suspected that the system became infected
directly by something that it received on one of it's NICs and not by
downloading something with the Web Browser ... the LAN does have Trend Micro
SMB version running ... and it detects Spyware on a daily basis,
occaisonally finds viruses and trojans (on the Client PCs using one of the
two LANs ... not the server) ... but it did not detect anything within 2
days before the unwanted traffic was first noticed.

Personally I'd

*** I don't think it is legitimate traffic ... NetBios over TCP/'IP is
disabled on the NIC that is sending the unwanted UDP-Port-137 traffic.  The
unwanted SMB traffic does not show up in the output of a Netstat command ...
but does show up in a NETMON Capture.

Another possibility is that another

*** There are actually 2 LAN (Gbit) NICs and 1 WAN (100MBit) NIC ... the
problem continues even when the LAN NICs are disconnected.

Jumping to a worm seems like quite a leap.

*** I didn't run a Packet sniffer on the LAN for this problem ... but I did
disconnect the LAN interfaces and the problem continued ... the SBS2003
server is not serving as the Gateway on the LAN ... there is another
external router to a different IP for that purpose ... there is lots of SMB
traffic on the LAN ... and some of it is illegitimate, it would be very
difficult and time consuming to attempt to find a match for the unwanted
packets that are leaving the SBS2003 WAN interface ... disconnecting the
interface for a few hours seemed like a better way to eliminate this
potential source of the unwanted packets.


There is no use chasing down

*** A great idea ... I did not think of sysinternals ... I will try to find
out if I can run this tool on the server very soon ... thank you.

Hi Miles!

Thanks for the info ... I did try a few of these already ... please see
embedded comments.

----- Original Message -----
From: "Miles Li [MSFT]" <v-mileli@online.microsoft.com>
Newsgroups: microsoft.public.windows.server.sbs
Sent: Tuesday, October 14, 2008 6:08 AM
Subject: RE: WORM? ... server generating NBT-NS (port 137) traffic on WAN
interface



***  I did try using "netstat -bnop udp 3" earlier ... it does not show
anything at all at the same time as NETMON is capturing the unwanted packets
leaving the WAN NIC.

I did run NETMON on the SBS2003 box, it did find the extraneous packets ...
they are all UDP packets
I  orginally noticed these packets in the log of the external router ... ran
a packet capture tool on that interface first, it showed only UDP - port 137
extraneous packets
It seems as if what ever program is sending these packets, it is not using
the API that Netstat monitors

Do you know of any other Software diagnostic tools or aids that will work
with the production version of SBS2003 R1 ??? .... this almost seems like I
would need to use a checked build version and/or some IDE or ICE tools to
discover what is going on ... I don't think I can use this approach on a
production system though.

Is there another Software diagnostic tool that you know of that I can use
for something like instruction trace logging ... and do you know the module
names of the modules that actually control the NIC ... I think the
misbehaving program is not using the normal API to send packets, but
probably does have to use the Device Driver at least.



*** Netbios over TCP/IP on the WAN NIC is disabled ... but not on either of
the two LAN NICs

I would advise you to call 1-866-pcsafety and ask for a Windows online
forensics analysis from the CSS Security division of Microsoft(called
WOLF).  This can be run on a production system.

Okay, first we need to clear up som inconsistencies, so read inline:



A worm seems unlikely with the timeline you laid out.  Regardless, DON'T
BROWSE FROM THE SERVER!!!!!


SBS doesn't support 3 NICs.  You will have problems with this configuration.
Why do you have 2 LAN NICs?  This seems incredibly inefficient.  Without
knowing *a lot* more about your topology, this alone could be a source of
problems.  Even if you need to segment your LAN, you should do so with a
good managed switch and VLANs.  But if you are trying to get 2 gigs off the
LAN then you are trying to do port aggregation, which again, to my knowledge
SBS does not support.


Okay, here is the first real inconsistency.  If the SBS machine is not
acting as a gateway then there really isn't such a thing as a LAN vs WAN
NIC.  I suspect you have some significant topology issues and may have even
introduced a loopback into your scenario.  This, coupled with what you've
laid out below, would imply that you have THREE LAN NICs??!??  I couldn't
even begin to troubleshoot such an odd configuration remotely without
thorough documentation.


Feel free to reply back once you've done this and have more info.

-Cliff

re: A worm seems unlikely with the timeline you laid out.
Any other suggestions about why these extraneous packets started being
generated?

re:  Regardless, DON'T  BROWSE FROM THE SERVER!!!!!
Yes I agree it is a bad idea ... but, I did ... it seemed like the right
thing at the time (WAN was being `throttled' by the phone company)

re: Okay, here is the first real inconsistency.  If the SBS machine is not
acting as a gateway then there really isn't such a thing as a LAN vs WAN
NIC.  I suspect you have some significant topology issues and may have even
introduced a loopback into your scenario.  This, coupled with what you've
laid out below, would imply that you have THREE LAN NICs??!??  I couldn't
even begin to troubleshoot such an odd configuration remotely without
thorough documentation.

It's really not that unusual, and we don't need to trouble shoot the LAN
configuration.  There really are 2 physical LANs with separate private IP
Range Class C networks that use the SBS2003 server for SMTP services and
file sharing, only 1 of these uses the full range of SBS2003 functions ...
and ONLY 1 WAN interface on the SBS2003 server.

In any case, the LAN/WAN/NIC configuration is not an issue ... with both LAN
NICs disconnected the WAN interface continues to generate NBT/NS queries
using port 137 without any indication of network activity in the Netstat
output ... all of these SMB packets are blocked by the router connected to
the WAN interface.  I am just annoyed that somehow this server was
successfully attacked and I want to find out more about the program that is
generating this extraneous traffic ... and maybe how it got into the system.

I now know of two `dumb things' that were done with this server before this
problem was first noticed:

1) I used the server webbrowser to run several speed tests, and to download
some files ... while diagnosing a WAN IP traffic flow issue ... about 7 to
10 days before the problem was first noticed.

2) Someone else (I just found out today) attempted to install a USB 56K
MODEM (purchased from eBay - Hong Kong) ... installed the device drivers
intended for WinXP because there were no Win2003 drivers, but the MODEM
didn't work ... device drivers were not `un-installed' ... not sure of the
timing of this event but it was closer to the date of the first reported
instance of the appearance of the extraneous NBT/NS packets.

... I think I will more closely inspect the CD that these drivers came from
... as soon as I get my hands on it :(

Thanks for the suggestion, Susan!

I think that I will spend a bit more time myself though ... the server does
not seem to present any danger to anyone else, and it appears to be working
normally in all other aspects.

Have you used this 'WOLF' service yourself ... can you give me a URL to find
out more about what it is?

I will probably wind up restoring an older image of the system before this
problem was noticed to fix the problem in a few more days ... but if the
'WOLF' service can help me figure out how the system got messed up in the
first place I am interested in trying it.

Yes Susan has had Microsoft look at one of her "fun" servers. One not
involved with her business.

http://msmvps.com/blogs/bernard/archive/2005/01/27/33938.aspx

On Wed, 15 Oct 2008 17:15:57 -0400, "Blondie" <nobody@nowhere.net>

See what SBS support is working on
http://blogs.technet.com/sbs/default.aspx
Check your SBS with the SBS Best Practices Analyzer
http://blogs.technet.com/sbs/archive/tags/BPA/default.aspx

Hi Miles!  Can you help me with a couple of questions?

Is the version of the module dns.exe a valid version from Microsoft?

Is there a chance that the server's DNS.EXE module has been compromised?

Info about dns.exe on the misbehaving system:
5.2.3790.4318 (srv03_sp2_gdr.080620-1216)
date modified = 2008-06-20 9:38AM
date created = 2008-07-08 10:31PM
found in folder = C:\WINDOWS\system32
HASH results:
MD5 = f48f7b44a7ab649c25d28ada071d615f
SHA1 = f8019cfbe2abd7b3910a72b0eea66dc9bad4fa3f

I ran (sysinternals) TCPView for a few hours ... never saw any open
connections to port 137 ... while the firewall blocked hundreds of outbound
packets.
I did see some things that look strange to me ... I would appreciate some
feedback to let me know what 'normal' should be.

If I turn off 'unconnected endpoints' within TCPView ... there are about 105
+/- 5% most of the time.

If I turn on 'unconnected endpoints' ... there are always > 2700 total,
including the 100 or so valid connections ... about 2500 of these are from
dns.exe with a wide variety of high port numbers ... and few are from
svchost.exe always using ports 1170, 1171, 1215 ... these never seem to
connect.

I also turned on 'audit logging' for the firewall ... there turns out to be
hundreds of DNS queries leaving the SBS2003 server WAN interface ... almost
all of these are valid and do return successful lookups ... yet there are no
processes running on the server that are likely to be generating these DNS
queries.

How many 'unconnected endpoints' would be considered normal?

How many 'unconnected endpoints' would you expect to be associated with
DNS.EXE ( I suspect it would be very few).

Thanks!

Hello,

The DNS.exe is from the security update MS08-037. It seems that DNS.exe is
all right.

953230	MS08-037: Vulnerabilities in DNS could allow spoofing
http://support.microsoft.com/kb/953230

File name 		File version 		File size 	Date 			Time 		Platform 	SP
requirement 	Service branch
Dns.exe 		5.2.3790.4318 	447,488 	20-Jun-2008 	13:38 	x86 		SP2 			SP2GDR

To narrow down the issue to the KB 951746 (DNS server side), you may
uninstall the KB 951746 to have a try.

951746	MS08-037: Description of the security update for DNS in Windows
Server 2008, in Windows Server 2003, and in Windows 2000 Server (DNS
server-side): July 8, 2008
http://support.microsoft.com/kb/951746

Hope it helps.


Best regards,
Miles Li

Microsoft Online Partner Support
Microsoft Global Technical Support Center

Get Secure! - www.microsoft.com/security
=====================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.