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

Discussion in 'Windows Small Business Server' started by Blondie, Oct 13, 2008.

  1. Blondie

    Blondie Guest


    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

    Blondie, Oct 13, 2008
    1. Advertisements

  2. 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.

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

    What Is Computer Browser Service?

    NetBIOS Over TCP/IP

    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:


    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.
    Miles Li [MSFT], Oct 14, 2008
    1. Advertisements

  3. Blondie

    Blondie Guest

    Please see comments below ...
    ----- Original Message -----
    From: "Cliff Galiher" <>
    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

    *** 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

    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.
    Blondie, Oct 15, 2008
  4. Blondie

    Blondie Guest

    Hi Miles!

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

    ----- Original Message -----
    From: "Miles Li [MSFT]" <>
    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

    *** 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
    Blondie, Oct 15, 2008
  5. 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.
    Susan Bradley, Oct 15, 2008
  6. Blondie

    Blondie Guest

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

    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 :(
    Blondie, Oct 15, 2008
  7. Blondie

    Blondie Guest

    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.

    Blondie, Oct 15, 2008
  8. Blondie

    Blondie Guest

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

    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

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


    Blondie, Oct 17, 2008
  9. 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

    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

    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.
    Miles Li [MSFT], Oct 17, 2008
  10. Blondie


    Sep 22, 2011
    Likes Received:
    Although this thread has been dead for some time, I just wanted to add this comment in case others out there were banging their head against the wall like I was thinking they had a server that had been compromised in some way.

    I had a new Windows 2008R2 server with IIS7 and began to see outgoing UDP packets on port 137 being blocked and logged by our firewall. It was intermittently happening when a user would connect to our web server, with no apparent pattern.

    I finally traced it back to the Performance Monitor. For some reason, perfmon is attempting a reverse DNS lookup for every user that connects to our web site. For the reverse DNS lookups that fail, it would attempt a NETBIOS-NS (Windows name) lookup on port 137. When I closed Perfmon, the traffic on port 137 stopped. When I started it back up again, they returned.

    I have no idea why Perfmon would be attempting a reverse DNS lookup for every web user connection - that investigation begins now. But, at least now I know that it is not a virus, worm or some sort of compromised security mechanism.

    I hope this helps!
    jsiwek, Sep 22, 2011
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.