Posted by & filed under Exchange Server, Internet Information Server, Windows / Server.

As most of you know, Windows is a hotbed of viruses (not virii), worms, and malware. I’ve had the pleasure of finding a new worm that attacks the TCP/IP service: tcpsrv.exe in the C:\Windows\System32\ folder. This file is needed for Active Directory and the Workstation Driver (ie. Client for Microsoft Networks). With this file removed, you cannot remote into your server, run active directory and as a result Exchange Server. You can, however, serve web pages just fine with IIS.

I have three Antivirus “managers” on my internal and external network. Panda Enterprise, Trend Micro ServerProtect and Avast Antivirus for Server 2003. My favorite is Avast because it is easy to use and “cheap.” The TCP/IP worm was not detected by Panda or Trend Micro. Avast only knew it was malicious and recommended to quarantine or delete it upon restart. If you delete it upon restart or even quarantine, your server will no doubt be crippled. You will not be able to log into your server through RDP (Remote Desktop).

When you try to login through RDP (Remote Desktop) you type your username and password and an error pops up: “Cannot log on. The Workstation driver is not installed.” “Workstation Driver” is the common name for Client for Microsoft Networks found in your network adapter properties. So how do you fix your server if you cannot log into it? Well, it takes some telnet and some creative FTP in the Windows directory, which I will explain in a different post. For now, you’ll need physical access to your server or someone with physical access that can follow instructions.

You can login to your server at the physical workstation no problem because only the RDP login utilizes the TCP/IP Service, unlike the regular workstation login. Because the TCP/IP service is missing or corrupted, the following services (all found in services.msc at the run command) will not work:

  1. Workstation (or client for Microsoft networks)
  2. Server
  3. TCP/IP Service
  4. RPC Locator
  5. Netlogon

The RPC Locator and Net Logon depend on the Workstation service. All of these services should be set to Startup Type: Automatic and should be started on any machine. The Server service is what controls the domain controller or lets your computer know WHAT it is. If you try to access Active Directory an error saying “the domain could not be found” or “the computer is not part of a domain.” This is important for active directory and Exchange Server. Server requires TCP/IP service to run. Steps:

1. Locate a fresh copy of tcpsrv.exe in a backup or i386 folder of the install disc. For Windows 2003 SP2 the latest revision is 2006. Put it into the System32 directory and manually restart all the above services. If this works, fantastic, it was easy contained worm. If not, read on.

2. If the above did not work you’ll need to go into the network adapter properties and delete “Client for Microsoft Networks.” You will need to restart after you have done this. Once restarted, re-install Client for Microsoft Networks. You will need your Windows 2003 CD. Restart again.

3. Verify that the startup type for the RPC Locator service is set to Automatic and start the service. Do the same for the Net Logon service but do not start it yet. Start Registry Editor (Regedt32.exe) and then click the DependOnService value under the key in the registry:


4. On the Edit menu, click Multi String, type LanmanServer on a line by itself, and then click OK. In the Services tool, start the Netlogon service. If you cannot start it, continue with the steps below. If it does start, then start the Server service and verify Active Directory Users and Computers opens and you can see the available users/computers.

5. If the above still didn’t work, you may also have a corrupt TCP/IP stack and corrupt Winsock2. You’ll need to restart your computer in “Directory Services Restore Mode” by pressing F8 after the BIOS information has displayed. Once you have logged in, open regedit32.exe and find and delete the following registry keys:


6. Locate the Nettcpip.inf file in your Windows\inf directory and open it in notepad. Find [MS_TCPIP.PrimaryInstall] and edit Characteristics = 0xa0 to 0x80.

7. Go into the properties of your network adapter and click “Install,” select “Protocol,” “Add” and “Have Disk.” In the “Copy Manufacturer’s Files From” box select C:\Windows\inf and click OK. Select “Internet Protocol (TCP/IP)” and click OK.

8. This allows you to remove the TCP/IP service from a domain controller (which was not possible before). Now in the properties box of the network adapter select “Internet Protocol (TCP/IP)” and click Uninstall. Once it has uninstalled. Restart the computer in Directory Services Mode again. Reinstall the Internet Protocol (TCP/IP) by going into the properties of your network adapter and clicking “Install,” select “Protocol,” “Add” and “Have Disk.” In the “Copy Manufacturer’s Files From” box select C:\Windows\inf and click OK. Select “Internet Protocol (TCP/IP)” and click OK.

9. Restart your computer in normal mode. All services should have started. If not, verify the above services are set to automatic and try to start them manually.

(5.00 out of 5)

5 Responses to “Windows TCP/IP Service Worm and Uninstalling TCP/IP on a Domain Controller”

  1. the_angry_angel

    Thanks for the heads up and how you resolved the issue!

    With regards to needing physical access, if you have enabled the Special Administration Console (SAC), and got some kit to secure and serve the redirected console, then you can negate the need of having someone on site :)

    Sadly this is out of the price range or just not considered by many small companies :( I apologise if you were aware of this or I’m teaching you to suck eggs.

  2. Chris Stinson

    Thanks. I was aware of it. *Most* servers I have come across do not have any remote access board like IBM’s Remote Supervisor or HP’s Lights Out to do a remote console. I have a few IBM x335 servers with it, and am able to remote into any one of them from a single board, which is cost effective, however it only works for that particular set of servers. I cannot get a session to a non-IBM server from it.



  1.  Error 8063 MSExchangeAL iedere vijf minuten | hilpers

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>