Hunting Symantec Worms

If you are performing network monitoring on a large network that is infected with any number of worms or botnets, there are many different techniques you can use with Tenable products to identify infected hosts. This blog entry considers a variety of worms/botnets that attack Symantec anti-virus agents. Many of the techniques identified here can be used to look for other worms that attack other applications and are active on different ports. For this post though, we will focus on port 2967 activity, which has recently dramatically increased, as reported by the SANS Internet Storm Center.

Signature Content Analysis

If you run an NIDS, there are typically rules which identify "known" botnet/worm/virus exploits. Here is a screen shot of Snort IDS events running the Bleeding Threat signature database:

We've highlighted the event by darkening it and also obscured the real IP addresses in questions. The event shows a remote host (69.16.196.189) sending traffic to port 2967 on host X.X.21.147 which matches a signature for an exploit against Symantec anti-virus agents. The other various "TNM" events show sessions starting and stopping on port 2967. These events are being viewed under the Security Center and have been collected and normalized by the Log Correlation Engine (LCE).

If this were a network you were defending, you should be asking yourself what else can be learned about this threat and if there are any other ways to detect compromised hosts. One of the things that would be concerning in the above image is that out target host X.X.21.147 is not only being scanned, it is also actively reaching out to other hosts on port 2967.

Combining Open and Browsed Ports

If you have the Security Center and the Passive Vulnerability Scanner (PVS) monitoring a network, you can query your cumulative vulnerability database for hosts that are listening on port 2967 and also browsing on port 2967. The  PVS records open ports as vulnerability ID #0 and browsed ports as vulnerability ID #2.  Within the Security Center, a query for a list of IP addresses that both browse and serve on port 2967 looks like this:

The IP addresses have been obscured. In the "port" filter, the value 2967 has been entered and in the plugin ID area, both IDs #0 (for open ports) and #2 (for browsed ports) have been entered.  In the chart on the right of the image, the IPs with the most vulnerabilities have been listed. Any of the IPs with two vulnerabilities have both a port open on 2967 and also browse on port 2967. The other IPs with only one vulnerability have either port 2967 open or they browse on it, but not both.

These hosts may not be compromised. Perhaps that do have port 2967 open for the Symantec anti-virus engine and also browse on port 2967 for some P2P, VoIP or other application. On the other hand, the chance of this occurring may be low on your network and hosts which both browse and serve on port 2967 may indeed be infected.

SANS has also recorded an increase in port 2968 traffic. Port 2968 is also associated with the Symantec anti-virus application. Similar queries for these ports can be accomplished with the Security Center.

Using Dynamic Asset Lists to Track Behavior

The Security Center can be used to create an automatic list of IP addresses based on the vulnerabilities and information discovered by Nessus and the PVS. We've blogged about this sort of capability in the past here. In the above example, since we only have three IP address of interest, perhaps a static asset list could be more quickly entered, but if new hosts became infected the list would not be automatically updated.

To create such a list, add a rule to match on port 2967 being opened, and a second rule to perform a regular expression search for vulnerability ID #2 ending in the content " 2967" (the space is on purpose). Examples of a similar dynamic asset rule are covered here. If you wanted to look for a host that browsed on either port 2967 or 2968, you could use a regex rule such as this:

2: 296[78]$

Such a rule searches for PVS vulnerability ID #2 records that end in a space followed by either "2967" or "2968".

On one of Tenable's large test networks which has been having issues with various Symantec worms, we created a Dynamic Asset List that considered systems that browsed and served on port 2967. This list was named "Symantec Worms". We then compared the trends of events and logs on port 2967 with just the events for the "Symantec Worms" systems and got the following results:

"Symantec Worm" hosts	All Port 2967 traffic

In the above graphs, there was a clear spike in traffic from our hosts which is easy to see. However, by just trending for port 2967 traffic, there is so much background noise, these particular hosts didn't register with any sort of spike or anomaly. (In this case, it was because these compromised hosts were performing large port scans on ports other than 2967).

For more analysis of the pure "port 2967" traffic, different queries could have been performed with the Security Center to compare "inbound" vs. "outbound" events.  Also, doing a "top talker" or "top destination" query of IP addresses for port 2967 could identify some problem hosts. And lastly, any "Crowd Surge" events on port 2967 would surely be indicative of many hosts scanning at the same time for this port.

Looking for Backdoors on Potentially Compromised Hosts

Once you have identified a list of hosts which may be part of a worm or botnet, it could be interesting to look for potential backdoors. One of the things both Nessus and the PVS do really well is identify applications, regardless of the port they are on. Consider the following list of vulnerabilities found on our "Symantec Worms" asset list where we are specifically excluding detected port 21 issues:

In the above image, we've highlighted PVS vulnerability ID #3222 which detects FTP servers on any port. This one happens to be on port 50126. Sniffing traffic to the system yields a hit such as this:

Clearly, this is an FTP server set up by someone who exploited the server, perhaps using an exploit for the Symantec anti-virus agent, perhaps with a different exploit. Regardless, we were able to use a combination of information to lead us to this host.

A different analyst may have chosen to look for all "non-port 21" systems running FTP servers on a daily basis an use the LCE or PVS to alert when a new system was added to the list.

Summary and More Information

These examples can be applied to many different types of worms and general log and event analysis. Knowing which vulnerabilities and network browsing activity occurs on your hosts can be used to help focus on specific events and systems. If this blog was of interest to you, the following entires will also likely be interesting:

• The Security Center can be used to push Bleeding Threat signature rules to your Snort sensors, as well as just enable the specific signatures that match existing vulnerabilities and applications on your network.
• The Log Correlation Engine can be used to match all of your network connections against "blacklists" published by SANS and Bleeding Threat . This includes matching traffic to or from known botnets.
• If you are using credentialed scans, the Nessus vulnerability scanner can find compromised Windows hosts that have had their ability to reach out to various anti-virus disabled.
• When the PVS finds a new port being browsed, the alerts can be sent to the Log Correlation Engine and used to find worm outbreaks.