Intrusion Detection FAQ: Finding Listening Applications on Windows

Itís a common problem, you perform a "netstat -a" on your Windows based machine and see a number of service ports listed as "LISTENING". This means that some application is running in the background and holding these ports open in order to accept inbound connections. The problem is "How do you tell which applications are holding open each service port?". Without this knowledge you may very have a Trojan or some other insidious application running on your system and never even know its there.

Unfortunately, there are no included Win95, Win98 or NT tools which allow you to associate running applications with the service ports they are opening. This type of tool is not even available on any of the resource kits. You will need to do a bit of investigation work in order to see what is listening on your system.

Using Inzider

Inzider is a cool utility that allows you to see applications running on your system along with the listening ports they are using. Inzider is not infallible. It is possible for an application which is holding open a listening port to hide from Inzider probes. Still, Inzider provides a quick health check which may help in identifying some of the less advanced Trojans that are floating around. Inzider will run on Win95, Win98 and NT based systems.

Simply download the self extracting executable Inzider.exe. You may also wish to download inzider_faq.html as it contains many caveats and known bugs with running the program.

To install Inzider, simply launch the archive file and follow the prompts. Inzider does not perform any registry or INI file changes which makes it extremely easy to remove once you are finished. It also allows you to save it to floppy (the program is less than 100K) so you can test multiple systems on the fly.

Letís go through an example so you can see how it works. Assume you ran the following on your local system:

C:\WINDOWS> netstat -a 


Active Connections

Proto    Local Address    Foreign Address    State
TCP    gwen:137    GWEN:0    LISTENING
TCP    gwen:138    GWEN:0    LISTENING
TCP    gwen:nbsession    GWEN:0    LISTENING
UDP    gwen:tftp    GWEN:0    LISTENING
UDP    gwen:nbname    *:*     
UDP    gwen:nbdatagram    *:*     

In the above output we see that NetBIOS/IP sharing has been enabled (ports 137, 138 nbsession, nbname and nbdatagram). This means that this system is acting as a server allowing network clients to connect to either files or attached printer shares.

We also see a TFTP (port UDP/69) open which is a bit odd. The Trivial File Transfer Protocol (TFTP) allows files to sent or received to this system without requiring authentication.

To find out why TFTP is being held open, we can launch Inzider and have it analyze our system. The output we receive would be similar to the following:

Checked C:\WINDOWS\EXPLORER.EXE (PID=4294965459).
Checked C:\WINDOWS\TASKMON.EXE (PID=4294841743).
Checked C:\PROGRAM FILES\CISCO SYSTEMS\CISCO TFTP SERVER\TFTPSERVER.EXE (PID=4294857879).
Found UDP port 69 bound at 0.0.0.0 by C:\PROGRAM FILES\CISCO SYSTEMS\CISCO TFTP SERVER\TFTPSERVER.EXE
(PID=4294857879) [UDP client]
Checked C:\WINDOWS\SYSTEM\MPREXE.EXE (PID=4294953443).
Checked C:\WINDOWS\SYSTEM\KERNEL32.DLL (PID=4294916979).
Checked C:\WINDOWS\SYSTEM\SYSTRAY.EXE (PID=4294845915).
Checked C:\MCAFEE\VIRUSSCAN\VSHWIN32.EXE (PID=4294944083).
Checked C:\WINDOWS\STARTER.EXE (PID=4294869135).

Note that Inzider has found a number of running applications. The "PID" is the Process ID" used by the system to identify this running program from others that are running at the same time. In this listing there is only one executable which is holding open a service port. This is TFTPSERVER.EXE which is located in the by C:\PROGRAM FILES\CISCO SYSTEMS\CISCO TFTP SERVER\ directory. Note that Inzider has verified that it is this program holding open the listening port UDP/69 which is our TFTP port.

So in this case Inzider found our culprit application. Unfortunately Inzider is not 100% effective. For example it can not catch applications that are running as a service under NT and may even miss applications that are actively running on the desktop. While Inzider is useful for making a first pass at checking your system, some additional checks are in order to insure that your system is secured.

Checking Windows NT

NT has three places you need to look in order to identify what is running on the system:
  • Task Manager - View active application
  • Services - View active services
  • Devices - View loaded device drivers
Note that none of these views will show you what listening ports are being used. In order to check which applications are opening listening ports, you must disable them one at a time until the listening port in question is closed.

A useful command line tool is "net start". This will show you all of the currently active services running on the system. Simply launch the command from a console window. Note that net start will not show you devices or active application. It will only show services on the local machine.

If you have a copy of the NT server resource kit, you can also use "netsvc". Netsvc has a number of benefits over the net start command:
  • Displays both the driver name and the display name
  • Shows both services and devices
  • Can be run across the network
An example of using the netsvc would be:
netsvc \\SERVER /list > services.txt


This command would query the server name "SERVER" over the network. Provided you have administrator privileges to the machine, this command would create a file named "Services.txt" which lists all the services and devices running on "SERVER".

Again, because there is no 100% accurate method of mapping applications to their listening ports, you may need to disable applications one at a time in order to determine which applications are opening which ports. Netsvc does include the ability to stop services and devices over the network.

Checking Windows 95 and 98

The Win95 and Win98 Task Manager does a fair job of showing all applications running on the local system. This does not include device drivers however so you still have only a partial view of what is active in memory. Like NT, there is no mapping of applications to their listening ports.

Win98 does include a good tool for figuring out what applications are being started on your system. In fact the tools is backwards compatible with Windows 95 (although it was not included with the operating system). The tool is called the System Configuration Utility (MSConfig.exe) and is located in the C:\Windows\System directory of a Win98 system.

Figure 1 shows the some sample output from the System Configuration Utility. Note that the Startup tab shows all applications that are started during system initialization. To stop a program from loading, simply remove the checkmark from the box. The next time the system is restarted the application will not be launched. To again have the program load at startup, simply replace the checkmark.

Figure 1
Figure 1

Additionally, the System Configuration Utility provides a single interface for viewing your config.sys, autoexec.bat, system.ini and win.ini files. You can even disable entries in these files in a similar fashion (by removing or replacing the checkmark). The General tab allows you to make backup copies of all of the indicated files.

Another useful utility is the Microsoft System Information Tool (Msinfo32.exe ). When you install a Microsoft Office product, it can be selectively installed to the "C:\Program Files\Common Files\Microsoft Shared\MSINFO\" directory.

The Microsoft System Information Tool is shown in Figure 2. Note that it will also report application that are started at boot time except that the Microsoft System Information Tool will also report which part of the initialization process loaded it (registry, startup group, autoexec.bat, etc.). Additional, the Microsoft System Information Tool will also show you what modules have been loaded on the system. This is information that is not available though the System Configuration Utility.

Figure 1
Figure 2

Summary

Unfortunately there is no one shot method for identifying running services on a Windows based machine. Using a number of different tools however the savvy admin can identify what