Event Analysis Training -- Working with Emerging Threats events

In the next few weeks, I will be posting a series of blog entries which provide examples of analyzing logs and events in large enterprise networks. We will be using the Security Center, Nessus, Log Correlation Engine and the Passive Vulnerability Scanner in these examples, but the principals can be applied to most SIMs, NBAD and network IDS Consoles. Today's blog considers working backwards from a few interesting alerts from a Snort sensor running the Emerging Threats signature set.

Emerging Threats

Tenable recently began supporting logs from Snort sensors running rules from the Emerging Threats project in both Security Center and the Log Correlation Engine. The Emerging Threats project classifies Snort events with a variety of names such as "ET EXPLOIT", "ET POLICY" and "ET SCAN". At one of our test sites (a large university) a typical "day" of logs looks as follows:

There are many ways to analyze this data such as summarizing by port, time, business asset and so on. Visualizing certain types of discrete activity is also useful. Below is a graph of all "Class A" address space that has had at least one Emerging Threats "P2P" event:

You can see that this university has a wide variety of P2P activity that communicates with a wide variety of address space.

Attacks and Exploit Attempts

A quick filter that can be used in the Security Center is to match all event names based on a unique string or text. To see all Emerging Threat Exploits, we'd type in "ET E*" into the query tool. All Emerging Threat exploit rules start with the name "ET EXPLOIT" such as "ET EXPLOIT WinProxy Host port buffer overflow". Similarly, we'd type in "ET A*" to match all attacks. Below are two screen shots
of the events which occurred under these filters:

Attack Events	Exploit Events

Under the attack filter, the events detected were IRC events that might indicate that a host has been compromised and is now receiving command and control instructions over an IRC channel. We will talk more about analyzing potential botnets in a future blog entry. However, in this case, the events were found to be false positives because:

• there was only one host of interest
• it never attacked nor scanned anyone
• there was a history of IRC usage as well as typical email and web browsing
• the IP address was found to be part of the student network

I say that these were false positives because the intent of the signature was to look for a compromised system logging into IRC in a suspicious manner. The signatures themselves looked fine, it is just that the packets involved that matched did not indicate abuse.

Analyzing The Events

In the Exploit screen, there were several denial of service events, a client side embedded GIF attack, a surge of PHP exploit attempts and a Solaris Telnet attack.

DOS Event Analysis

The DOS events were directed against one MS SQL server for which we had been receiving event logs from the underlying system. These logs indicated no interruption in service around the time of the attack. Vulnerability data from previous Nessus scans and continuous updates from the Passive Vulnerability Scanner did not indicate any major vulnerabilties or potential denial of service issues
either.

The actual packets detected in this case may have been real attacks. If we wanted to do deeper analysis, we could consider the sources of the attacks and see if this indicates some sort of  longer term activity. I generally don't like any type of unencrypted SQL access across a perimeter of a university.

Analyzing a Client Side Attack

The client side embedded GIF attack referenced MS05-036. This targets Internet Explorer browsers. In this case, Nessus was not being used to perform a client side audit and the Passive Vulnerability Scanner does not have a plugin to find this vulnerability since there isn't enough data on the wire to determine if it is present. However, we can do a few things.

First, we can look for evidence of a browser being used other than IE. In this case, it was Firefox. The PVS will report what browser is being used through passive analysis.

Second, we can see if this computer is receiving updates from Microsoft. PVS plugins #1925 and #4433 detect if a host is performing updates from Microsoft. And third, we were performing analysis of this host several days after these events occurred. After this IDS event happened, we did not observe any statistical anomalies, any types of scanning, outbound attacks or correlated events which could indicate a compromised system with Malware or a back door recently installed.

Analyzing the Telnet Attacks

The last attack that I felt was interesting were the Telnet attacks against a Solaris system. First, I thought it would be interesting to see how much Telnet traffic was occurring and to where:

Compared to the P2P traffic in the screen shot above, there is much less port 23 traffic. I am surprised at how much port 23 traffic is occurring and originating from multiple places on the Internet. There are likely scanners looking for open Telnet ports to exploit them with vulnerabilities or attempt brute force password guessing.

Analyzing the specific attack further, I found that the source of the attack originated from outside the United States and had not sent previous attacks. Wanting to see if there was other data on this host besides the IDS events, I turned to the Log Correlation Engine we had deployed there. This included logs from the Tenable Network Monitor to collect all network session data as well as system logs from a few servers and applications. Performing the query for our IP of interest we see this following data:

In this graph, we see that there were 70 normalized Emerging Threats Snort events, and slightly more TCP sessions. However, there was only one network session that completed. All of the other sessions "Timed Out" which is very indicative of a network scan. For the one session that was observed to complete (a full, SYN, data and good close with a FIN), it would be very interesting to see what the target and port were and this is shown below:

In this case, the target was an email server. SPAM logs were not being sent to the LCE, but delivered email was. This could allow us to conclude that the 34k bytes in the session on port 25 was likely some sort of spam email. Correlating this with the fact that the same IP address also tried a Solaris Telnet attack means that the remote host is most likely a SPAM source that also probes for vulnerable services.

The Security Center automatically correlates IDS events to discovered vulnerabilities and would have generated such an alert if the target host was vulnerable to the Telnet attack. To manually make sure, looking at the Nessus and Passive Vulnerability Scanner data that has been detected does not show any issues on port 23:

None of the vulnerabilities listed here seem serious enough to be concerned about.

Conclusions

This is the first in a series of several articles on different examples of event analysis. We've covered some related topics previously in this blog and they are listed below here:

• ShmooCon -- Network Monitoring Notes
• Finding Low Frequency Events
• Good and Bad Uses of Vulnerabiltiy Data for IDS Event Correlation
• Tracking Users Through Logs and Network Activity
  
• Blacklist Event Correlation
• Looking for "Never Before Seen" Events
• Example NBAD with the Log Correlation Engine