Controlling the traffic heading in and out your organization’s network has long been considered a very good way of providing protection against many types of threats. Filtering outgoing traffic prevents malicious activity from leaving your network, such as a botnet member attempting to call home for instructions. Here we will use a few free tools for Windows that can help in the identification of possible threats caught in your network’s outgoing filters.

Detecting a possible threat

When controlling your outgoing traffic, you should regularly check the logs of your firewall or router, as these logs can alert you of any unusual traffic or malicious patterns. Unusual activity could appear as repeated attempts to connect to external addresses via non-standard ports or connection attempts to servers in locations where your users normally should have no reason to access. Let’s take for example a Windows machine attempting to connect to an IP address in Russia via UDP port 12000.

Once you’ve identified the source machine (and assuming a full scan with a fully updated antivirus does not reveal anything), we will then use the netstat command to see the status of the network connections for the computer. Using netstat with the -? parameter gives you all the available options for the command. Here are some of the commands that can be useful for our investigation:

-a Displays all connections and listening ports.
-b Displays the executable(s) involved in creating each connection or listening port.
-n Displays addresses and port numbers in numerical form.
-o Displays the owning process ID associated with each connection.
-p protocol Shows connections for the protocol specified: TCP, UDP, TCPv6, or UDPv6.

Note that although using the -b parameter lists the executable responsible for a connection, it can slow down execution of the command and you may miss the specific connection you are looking for. Displaying the addresses and ports in numerical form helps with the readability of the results.

In our example, we would like to see only connections using the UDP protocol, so we would use the -p UDP parameter in combination with the -a, -o and -n parameters. The result should look like this (the real IP addresses have been redacted):

Figure A

Using the resulting PID, we can identify the process and the associated programs using Windows’ own Task Manager:

Figure B

In some cases, running netstat is enough to identify the process and the executable responsible for the connection. Sometimes, the results of netstat can be misleading: in our example, the process responsible for the connection turns out to be explorer.exe, the executable of the Windows shell. Running the executable through VirusTotal (http://www.virustotal.com) indicates that the file is clean and comparing it with a clean machine, it appears that it has not been compromised. Something else is at play in this example.

Enter Process monitor

Process monitor (procmon -found here: http://technet.microsoft.com/en-us/sysinternals/bb896645) is a tool for Windows from Sysinternals that allows you to see in real-time all the activities of the file system, registry, and process/thread for a machine. It has a graphical interface — but it can also be run from the command line.

Once you start procmon.exe, it will immediately start capturing events. You can save those results to a log file for later examination if you wish. Just be aware that in some machines, a lot of events might be happening simultaneously and the resulting log could be very large after just a few minutes of capturing data:

Figure C

To stop capturing events, from the menu, select File, Capture Events. We know from the results of netstat that explorer.exe is behind the connection attempts. Using process monitor, a filter can be established to show only activity for explorer.exe. Right-clicking over explorer.exe for any of the events registered allows you to “include” it. This ignores all the other executables recorded:

Figure D

You can also exclude it, hiding it from the current view. These filters can be applied over pretty much every piece of data captured. Returning to our example, we can quickly see that the connection attempt was captured:

Figure E

Click to enlarge

Reviewing the operations explorer.exe performed just before attempting the connection, an unusual entry shows up:

Figure F

Click to enlarge

It appears that explorer.exe is trying to read information in the registry that leads to a file in the recycle bin. It’s not unusual for malware to attempt to hide its presence on a system, so we may have found a new suspect. Running the file over to VirusTotal, a few of the scan engines used confirm that it is a variant of an older Trojan, yet different enough to escape detection from the current signatures of the installed antivirus software.

Although this was a quick example, hopefully the tools and steps described here can be helpful in detecting threats that otherwise might go unnoticed.