Event Analysis Training – Passive Worm Detection

This blog entry describes a basic worm detection that triggers multiple types of correlation rules. All detections were done passively using the Passive Vulnerability Scanner (PVS) and by observing network session traffic using the Log Correlation Engine (LCE). The principals in this blog entry and others in our ‘Event Analysis Training’ blog series can be used with a variety of NBAD, IDS and SIM solutions.

Initial Detection

While reviewing a set of correlated events for the past week at a large university monitored with Tenable products, I noticed a single “Potential Worm Outbreak” event. The correlation rule that generates this event gathers port scanning data from firewalls, NIDS and the PVS. Within this port scan data, the LCE simply looks for a host that has been recently scanned shortly before becoming the source of new outbound scans. The principle behind this is to determine if a host has been infected or compromised and is being used to launch new scans.

Although the algorithm behind this rule is simple, I don’t rely on it or push it as a major correlation rule because of port scan reflection. As a SIM vendor, we get to see logs from a wide variety of products and we often get logs of attacks where the firewall, IDS or “event-a-second” IDS report the same port scan but report it in a different direction. Without going into a full discussion of port scan detection algorithms, depending on how a NIDS is tuned, how a network is configured and what sort of port scan (e.g., full connection, ACK scan, SYN Scan, spoofed source addresses, etc) the responses from a host that is being scanned might be considered as an actual port scan itself.

Click for larger image

Logs that have been normalized by the Log Correlation Engine are very interesting to review. Following is a short list of what these events mean.

·         DNS Blacklist Domain - A host has performed a DNS lookup for a domain name that has been blacklisted. In this case, the DNS lookup was sniffed and logged by the PVS.

·         Long Term Network Scanning – The IP address in question was performing port scanning continuously for at least an hour.

·         New DNS Query – When processing DNS queries, the Log Correlation Engine will keep track of the first time a host resolves a given destination.

·         Potential Worm Outbreak – This correlation event indicates that a host has been port scanned, and is now performing outbound scans.

·         PVS Vulnerability – When the PVS determines that a vulnerability exists on a certain host, it can be logged in real time. As a host browses the Internet, it exposes more client side information to the PVS and new vulnerabilities may be logged.

·         PVS Network Information – Similar to finding vulnerabilities, when the PVS learns about new hosts, new open ports, browsed ports, trust relations, and more, these are logged in real time as well. For example, one of the very first events from the PVS was the “PVS New Host Alert” event.

·         PVS Scan Detections – The PVS can also identify single host port scans as well as large and medium network sweeps of multiple hosts.

·         PVS Forensic Logging – The PVS can also log a wide variety of network activity that is sent to the LCE. In this case, PVS has logged two event types of interest. The first is the “PVS Web GET Request” event. This event occurs on port 80 and PVS extracts the destination URI of the web browsing event for logging. The second event is the “Internal Encrypted Session”. This indicates that the host made a network connection to another host on the internal network that was sufficiently random enough to likely be encrypted.

·         Statistical Anomalies – There were six anomalies logged by the LCE. These were based on logs from PVS, correlated events and the Tenable Network Monitor that is covered below. The statistics engine of the LCE maintains a model of connectivity as well as event rates. In this case, the first few “Statistics Connection Large Anomaly” and “Statistics Connection Medium Anomaly” entries mean that the host in question was involved in network connection rates that were outside of normal behavior. The last few statistical “network” events indicate that there was a count of “network” event types for the LCE that was above the normal statistical average.

·         Statistical Long Term Abuse – This event indicates that there have been continuous statistical events for more than 3 hours. In networks with many anomalies, this correlation rule helps identify hosts that are being driven harder than normal for a longer period of time.

·         TNM Activity – The Tenable Network Monitor is a sniffer used to log network sessions (much like a netflow log) directly to the LCE. The LCE normalizes network sessions by protocol, length of session and amount of bandwidth. For example, a session lasting 30 minutes and transferring 100 MB of data would be logged twice. Most network sessions are short, do not contain much data and are logged only once. For the events from the host in question there were ICMP events, 2542 sessions lasting less than 5 minutes, a few sessions lasting 5 minutes or more and 10 sessions that transferred between 1 MB and 10 MB of traffic.

So what does this all mean?

The event graph indicates a linear time progression from older events on the left to newer events on the right. There are a lot of things this graph tells us that are not in the events:

·         There were no events preceding this host. We have the PVS “New Host Alert” event that means it saw this IP address for the first time. We also don’t have any flows from the Tenable Network Monitor.

·         The grey area is 6AM to 6PM and the red line is midnight. Just after midnight, all activity from the IP address is gone. Perhaps this was a student who turned her laptop off, a virus shut down the computer, the machine  rebooted or a DHCP address was reissued. Since we don’t have logs from the DHCP server and we aren’t doing active scanning we’d have to do some investigation to find this host on a new IP address if that was important to us.

·         We don’t see any large bandwidth traffic directed at the network. Two thousand network sessions and a few MB of network traffic is not a notable event.

Based on all of this, I would conclude this is some sort of infection, but not something that is highly aggressive or at least wasn’t behaving aggressively at the time it was logged. Of course, it should be fixed, but if you are in a university environment and are dealing with hundreds of these situations on a daily basis, it might not be your number one priority. If I saw this same traffic on a corporate laptop, I’d have pulled it and performed a virus scan or figured out why the virus scan didn’t prevent the infection to begin with.

For more Information

The Tenable Blog offers a series of several dozen articles in the ‘Event Analysis Training’ section. Topics covered include blacklisted IP address analysis, crowd surges, detecting anomalies and much more.