How to trace malicious software from a firewall

It is a key step to deal with the information security threats faced by the Enterprise daily, which can control the data flowing in and out of the Enterprise network daily. Filtering out data from the enterprise can effectively prevent malicious software from leaking important information or contacting an attacker's server, such as attempts to stop a zombie from contacting the server to download a virus. This article will introduce you to a few free gadgets under Windows to help your network administrator determine if there is a potential security threat to outgoing data blocked by the firewall.

Monitoring potential threats

To control the flow of data that flows out of the enterprise, you must periodically check the log files of the firewall or router, as these logs will display any abnormal data flow or malicious data propagation patterns. An unhealthy output data activity may behave as a special port that periodically attempts to connect to a remote address, or a host periodically attempts to connect to an internal server, and the host's users typically do not need access to that server. Let's take an example to give a specific analysis, assuming that a Windows host in the company always tries to connect an IP address to a host in Russia via UDP port 12000.

Once you have identified the location of the host within the company (and have a full scan of the host by killing the software), we can use the netstat command to check the network connectivity status of the host. Using Netstat plus-? parameter to view all of the functional parameters that the command can use and the corresponding description. The following are the relevant functional parameters of netstat, which may be used in your survey work:

-A	Show port numbers for all connections and listeners
-B	Display executable files that involve each connection or listening port
-N	Arranges existing connection addresses and port numbers in numerical order
-O	Displays the process ID number involved in each connection
-P Protocol	Shows connections using some protocol: TCP, UDP, TCPv6, or UDPV6.

Note that while the-B parameter can be used to list the executable name of the initiating connection, this parameter also lowers the speed at which the netstat command is executed, and may cause you to miss a connection that you are looking for. A number of sequential ways can help you better read the feedback results of command execution.

In our case, I just need to show the connection using the UDP protocol, so we use the-p UDP parameter plus the-A, the-O and-n parameters. The command execution results are shown in the following illustration (I have modified the real IP address):

Figure A

With feedback PID, we can determine the process of initiating the connection and the related programs in the Windows Process Manager.

Figure B

Sometimes running netstat directly is sufficient to determine the process and associated executables that raised the connection. But sometimes the results of Netstat can mislead us. In this case, the executable program we see for the suspicious connection traced through the PID is Explorer.exe, which is the Windows shell file. Upload the file to VirusTotal (http://www.virustotal.com) for analysis, showing that the file is clean and not infected or damaged by the virus. So there's definitely a stealth program in this case.

Go to Process Monitor

Process Monitor (ProcMon can be downloaded at the following address: http://technet.microsoft.com/en-us/sysinternals/bb896645) is a Windows tool developed by Sysinternals that allows administrators to view the active file system, registry, and process/thread activity in real time. The tool uses a graphical interface, but it also supports command-line mode.

When Procmon.exe is started, the software understands the start of capturing events. You can save the captured results to a log file for later analysis. Note that on some hosts, a large number of events may be generated in a short period of time, and a large number of event records are accumulated in a few minutes of the capture event, while the log files saved are oversized:

Figure C