Spot Malware on Your Windows Hosts with netstat
February 11, 2008
netstat gives you some of the tools you need to spot and eliminate any malicious software listening for network connections on your Windows hosts.
Is there a bot or Trojan horse listening for incoming connections on your Windows domain controller right now? Having the skills necessary to answer that question is essential for any Windows server administrator. After reading this article you will be better able to answer that question as well as detect and analyze the legitimate programs that are listening and communicating on any of your Windows hosts.
The key to understanding what programs are listening for incoming connections and actively communicating on your Windows machines is the netstat.exe utility. After a brief introduction to TCP/IP ports we'll look at netstat.exe and some of its practical uses.
Very Brief Introduction to Ports
When using netstat.exe to diagnose problems or troubleshoot a firewall issue, it is important to have a basic understanding of ports. To send information across a TCP/IP network you must, of course, have a source and a destination IP address, but you must also have a source and a destination port. The destination port lets the operating system know which program on the destination computer should receive the information, and the source port lets the receiving program know which port to specify on its reply. If you sent a letter to an apartment building without specifying the apartment number, the mailman would not know where to deliver the letter. The same is true when sending information across a TCP/IP-based network such as the Internet. Each networked program running on your computer needs an "apartment number," or port.
You're going to have to drop to the command line to use netstat.exe so the first step to using netstat.exe is opening up a command prompt. You can get to a command prompt in XP/Server2003 from the Start menu under All Programs -> Accessories -> Command Prompt or via Start -> Run -> "cmd" -> Enter.
A good way to start getting comfortable with netstat.exe is by reading the help text:
Figure 1 reveals a variety of command line switches available to you with netstat.exe. If you run netstat.exe without any switches you will see a list of active connections. Running netstat.exe on a machine that has no active connections will look like the screenshot in figure 2.
This will probably be the last time you see netstat.exe running with no output. Typically there are all sorts of active connections, but I'm cheating with a bare bones virtual installation of XP. After opening a connection to Microsoft Update the output looks like that in figure 2.
There are four netstat.exe switches that will be most useful to you:
- -a will cause all connections and listening ports to be displayed. What we are really after here are the listening ports.
Note: Previous to WinXP/WindowsServer2003 the netstat.exe command does not have the ability to display listening ports.
- -b comes in handy when you are trying to find out what port a particular program is listening on. "-b" causes netstat.exe to display the name of the executable that opened each connection or listening port.
- -n is useful because by default netstat.exe will hide the actual port number from you for protocols that it "knows" about. For example, one of the ports that Windows XP listens on by default is 445. If you run netstat.exe without the -n switch it will display "microsoft-ds" instead of the port number. In some cases this may be useful and in others it might be a hindrance.
- -o causes netstat.exe to display the process identifier (PID) of each program in the connection list. The PID can be used to trace a connection back to a process listed in the Windows Task Manager.
Figure 4 shows what "netstat -ano" looks like on a bare bones install of Windows XP (leaving out the -o for brevity).
This is the good stuff right here. With this information you can see what processes are currently listening for incoming connections. If there were active connections you would also see those listed. There are various uses for this information including investigating a system for malware and tracking down firewall exceptions.
If you are trying to punch a hole in your firewall for a web server there is plenty of documentation out there that would lead you to ports 80 (http) and 443 (https). But what if you need to allow incoming connections to your Windows machine for a more obscure program like backup software? This is a cinch with netstat.exe. Simply run "netstat -abno" while your backup software is running and look for the backup software executables. Plug the associated ports into your firewall exception list and you should be good to go. With the Windows firewall you can also just add the executable itself to the exception list.
So what about that domain controller we mentioned at the beginning of this article? It's not a simple task to determine if malware is running on your domain controller, especially if it has already subverted your anti-virus software, but netstat.exe can help. By comparing the listening ports and active connections to a known good domain controller you can look for differences and odd behavior. You could also compare the list of established connections to a black list provided by organizations like Spamhaus.
Finally, let's look at how to link a connection displayed by netstat.exe with a process listed in Windows Task Manager. Often times you can just run a "netstat -abno" and find the appropriate process name listed in Windows Task Manager, but what if there are two or more processes with the same name? In figure 5 you'll notice that svchost.exe is listed several times by "netstat -abno" and Windows Task Manager. The PID can be used to find an exact match, but first you'll need to display the PID in Task Manger. Ctrl-Alt-Del -> Task Manager -> Processes Tab -> View -> Select Columns -> Check the box for PID -> OK. Now you can definitively link a connection listed by netstat.exe with a process in Windows Task Manger.
As promised, you should now be able to see if there are any naughty programs listening for incoming connections on your domain controllers as well as any other Windows machine. You can also trace that process to the Windows Task Manager and cancel the process. Happy hunting.