Event Analysis Training – Worm Outbreak

On Friday April 10, the Conficker worm was supposed to wake up and start network scanning. I grabbed the following screen shot from one of Tenable’s research sites:

The graph shows a combination of network sessions, Snort events and correlated events gathered and integrated by Tenable’s Log Correlation Engine. Clearly on April 10 (marked in red), something started scanning. This graph was of a single host that I selected to see if it indeed was infected with Conficker.

Without diving into the actual content of the logs, or figuring out which ports and hosts are involved, what can this graph tell us?

• This host was alive and generating traffic prior to April 10.
• The host was performing some sort of web browsing because we have a few “Snort HTTP Inspect” events that often result from heavy web browsing. This is corroborated with many “Long TCP Session 5 Minutes” events throughout the same time-frame.
• On April 10, we have a simultaneous spike of TCP sessions, Snort P2P events, Snort HTTP events and our first port scanning events. However, the P2P probing events immediately stop.
• The only type of port scanning events is port sweeps. This is when one host attempts to connect to multiple ports on another host. There are no “port scanning” events which are alerts based on one host connecting to one port on many other hosts.
• There were 1405 TCP sessions that “timed out”. Although this event is very common when a host is port scanning, P2P protocols also attempt to discover other nodes that are on the network. In addition, a port scan of thousands of ports on thousands of hosts would generate much more traffic unless it was a very slow scan.

Based on this information, I concluded that this host is a typical web browser that is engaging in some P2P activity. Of course this might be against the policy of your organization, but it is most likely not a worm. I would also discard the single UDP scan as being part of a typical profile of a P2P agent attempting to discover what ports it has open to and from the Internet. Similarly, I would also disregard the ICMP Snort events. They may be ping attempts from the local network or ICMP error message.

It’s great to have an opinion about a graph, but what could we do next if we really wanted to remove all doubt about this host?

• Dive deeper into these events and read the actual logs. I’m curious if the web sites that had the Snort HTTP events were potentially hostile. We want to rule out any malware being delivered to the web browser of the host in question.
• Verify that the ports being logged for the network traffic from this host were also common P2P ports and not common exploit and probe ports such as 22 (Secure Shell), 445 (Windows), 53 (DNS) and so on. If a port is being used heavily and you are not familiar with it, try searching for it at the SANS Internet Storm Center.
• Determine the vulnerability state of the host in question. If you have access to a recent vulnerability scan, it would be good to see if there were any open ports. A more useful set of data would come from a credentialed scan or a passive scan (such as with the Passive Vulnerability Scanner) that could identify the web browser, if it were patched and perhaps if there were any questionable toolbars or add-ons installed.
• Use Nessus to conduct a vulnerability scan for MS08-68 or the actual Conficker worm.
• Use an asset classification or asset tracking system (if available), to see where in your network these events have come from. Is this host a student on a shared network? Is this host a server?

For More Information

Tenable has written several Event Analysis Training articles that cover many different aspects of event analysis such as blacklisted IP address correlation, different types of worm traffic patterns and botnets. These articles are located here.