I recently worked with a customer who asked for advice on
the following “virus” events:
They were seeing “virus” traffic more or less continually. If you run a network IDS, and operate a busy email server, you will likely sniff virus traffic contained in inbound email messages.
The above traffic graph was for normalized virus events. Following
is a copy of the detailed graph of events that occurred during this same time range:
It is apparent that the majority of the virus events came
from the normalized “SnortET-Virus_Activity” event. This is an event from the Emerging
Threats
project used to detect the very latest virus outbreaks. An example of a sanitized
raw log looks like this:
Sep 6 09:13:37 clovis snort[19702]: [1:2003294:5] ET WORM
Allaple ICMP Sweep Ping Inbound [Classification: A Network Trojan was detected]
[Priority: 1]: {ICMP} 24.191.47.129 -> 66.X.Y.Z
When I am looking for virus compromises, I run a simple
query to look for traffic reflection. It is not a 100% guarantee to find
systems compromised with a virus, but it is typically a quick and effective
method. If you have a network IDS that can detect a virus propagating inbound to your network, then you should
be able to see when that same virus has taken control of one of your servers
and is propagating outbound.
This is accomplished in the Security Center by selecting
your query and then filtering it with an asset list for outbound events. Any
asset list can be used. If you want to use your entire network, the terminology
in the Security Center is known as the “Customer Ranges”. However, if you have
created asset lists for various departments, or various physically distinct networks,
the same principal applies. Investigate any outbound virus traffic originating
from one of your hosts.
This particular customer saw the following when they displayed both inbound and outbound traffic for IDS virus alerts:
All traffic was indeed inbound to their network.
Conclusion
This type of manual analysis can be used to quickly see if a
virus has compromised a host and is now using it to attack other hosts. The LCE
includes several other types of correlation rules to specifically alert on
continuous scanning and compromised hosts.
This blog entry was one of many that have been written in our “Event Analysis Training” series of blog entries. If you are running a SIM, an IDS or performing some sort of NBAD monitoring, these blogs offer many tips for working with different types of logs and suspicious activity.
