Version 3.0 of the Passive Vulnerability Scanner (PVS) dynamical alerts when it finds "new" pieces of information about the network. Potential information includes open ports, browsed ports, OS fingerprints, client applications and network services. This blog entry discusses how the occurrence of "new browsed port" events can be used to look for various types of malicious behavior.
Browsed vs. Open Ports
Obviously, both Nessus and the PVS can tell you which systems have ports that are open for services such as http, smtp, ftp and so on. What is unique about the PVS though, is that it can tell you which systems on your network have been known to browse on a certain port at least once. It uses ID #00002 and is labeled "Client Side Port Usage" by the Security Center. Consider this screen shot for a single IP address of 192.168.20.16:
|
This server has only browsed on ports 5900 (vnc), 80 (http) and 443 (ssl). It may have used the VNC client one time, 50 times or more. From this report, we don't know how many time this host was active on a certain port, but could if we had configured a Log Correlation Engine (LCE) to grab netflow or network sessions.
Consider this host which performs "heavy" network browsing, P2P file downloads and uses the Skype chat tool:
|
This host has reached out to 32 unique ports at least once while the Passive Vulnerability Scanner was monitoring it.
Real-time Notification of New Port Browsing
The PVS has the ability to alert when something "new" has been added to it's model of the network. This includes alerting when a host begins browsing on a certain network port. Under the Log Correlation Engine, these events look like this:
|
For this particular demo network, the PVS has generated 42 "PVS-New_Port_Browsing" events in the last 24 hours. These events are used by many LCE TASL scripts to look for network change, and even look for events from various NIDS which may be followed by a host performing "new" types of network activity.
Looking for Worms and Trojans in "Live Data"
When systems are compromised by some sort of rootkit, botnet agent, maleware or some other type of malicious software, they tend to use their own network channels to communicate for command and control. Obviously, some bots are more stealthy than others, but the large bulk of them open up network connections to someplace else to report home and receive commands. If these connections are on ports not normally visited by a system, they "stick out" in the traffic.
Consider the following list of "new browsed ports" for all systems on a large network being monitored by the Passive Vulnerability Scanner for the past 5 days:
|
Many of the ports involved (7000, 7777, 22, 6667, 8008, .etc) are very common server ports to host maleware and control botnets with. This information needs to be analyzed. Just because a server connects to port 6667 (irc) for the first time, doesn't mean it is not used for IRC chatting and is a bot.
Someone who wished to analyze this data further could use the Security Center and simply query for the number of "browsed ports" that the PVS has detected for a specific network. Such a query could look like this:
 |
These are all of the ports that the network has reached out on at least once. Port 80 is web traffic and many of the other ports are chat or P2P specific.
Those listed ports in the above image are just the top ports. If we wanted to get a listing of all systems that had browsed on port 7000 or some other port, we'd just select plugin ID #00002 and the port or ports of interest, and then perform a "Summary by IP" or "Summary by Class C" report. This is also an excellent way to figure out if your outbound firewall or proxy configurations are being effective.
For worm and trojan analysis, it can be more interesting to track the "new" port events in the Log Correlation Engine. For example, considering port 7000 "new port browsing" events over the past 25 days produces a graph like this:
|
These spikes indicate that large numbers of hosts all began browsing the network at the same time on port 7000. This can correspond to worm outbreaks, use of P2P and chat applications and also initial botnet infections.
It's important to understand that there are legitimate reasons for spikes in everyday network activity and to consider other environmental factors. For example, consider your DHCP lease times. If you have a large user population that gets brand-new IP addresses every few days, then their normal traffic will show up as a spike of new port browsing events.
For More Information
Tenable has posted several items in this blog which discuss virus and worm analysis with Nessus scanning and passive network monitoring. They are listed below:
