Seeing The Big Picture With Global Correlation
In a previous post I provided an overview of the Cisco Global Correlation (GC) capability that was recently added to Cisco Intrusion Prevention Systems (IPS). The information sent to SensorBase includes signatures that generated alerts and other relevant data.
I thought it would be interesting to highlight what we can learn from this growing data set. I intend to focus my analysis around FTP-related signatures. Because FTP security issues are relatively well understood, I will be able to highlight the correlation capability we have at our disposal and focus less on the specific threat that is driving my analysis.
Tom Schoellhammer of Cisco Security Intelligence Operations’ (SIO) Analysis and Applied Research team noticed that a spike in alert volume for the FTP Privileged Login signatures (3171/0, 3171/1) accompanies a spike in the alert volume for the FTP Authorization Failure signature (6250/0). This correlation can be illustrated in the following graphs. The red line shows raw alert volume for signatures 3171/0,1 and the blue line for signature 6250/0. The lower graph scales the alert volume so that the correlation is more obvious (click for a larger version).
These are very straightforward signatures and they have been part of our signature set for several years. The FTP Privileged Login signatures detect login attempts from the
users and the FTP Authorization Failure detects failed FTP login attempts. Given that there was a correlation in these signatures’ alert volume we thought it would be interesting to see what we would find if we combined the detection capability of these signatures. This is easily accomplished using the Meta engine. The Meta engine processes signature events that occur within a sliding time interval. Using this engine, I created the Administrative FTP User Failed To Authenticate (18920/0) signature, which looks for at least four failed login attempts from the
users where each attempt takes place within thirty seconds of at least one of the other attempts.
SensorBase immediately started receiving Network Participation (NP) data for signature 18920/0. However, the fact that this signature generates alerts isn’t always an indication that there is an attacker trying to do something malicious. For example, a script that contains invalid passwords and attempts to log in to an FTP server could cause this signature to alert. It’s highly unlikely condition – because the script would have to attempt to log in at least twice a minute – but it is possible. Using Reputation, which is another component GC, I can focus my research on hosts that have a history of malicious activity on the Internet. In a little over two and a half months, certain IP addresses with a bad reputation generated well over twenty thousand alerts, while one attacker generated almost one hundred thousand alerts! (Note: I sanitize all IP addresses because they are Internet facing. The hostnames are randomly selected three-letter words from CrackLib’s dictionary and I use .eg domain names. My fictitious FQDNs are consistent across this post)
I decided to dig deeper into what tty.network2.eg, the host that generated almost one hundred thousand alerts, was up to. Remember that each alert results from at least four attempts to log in as a privileged user. That’s at least four hundred thousand login attempts. That’s statistically insignificant on an Internet scale but should still raise an eyebrow. Not surprisingly, I saw that this host also triggered alerts for the TCP SYN Host Sweep signature (3030/0). What was somewhat interesting to note was that many unique IPS sensors saw traffic from this attacker IP and that traffic resulted in signature 18920/0 generating an alert. Even more interesting is that we also see the FTP Privileged Login signatures generate alerts. tty.network2.eg is clearly up to no good. This host performs TCP SYN Host Sweeps and then attempts to log in to FTP servers as privileged users, occasionally succeeding. It appears as if the software running on the attacker host tries to sneak under the radar to an extent. Specifically, a given sensor generates alerts almost exactly ten minutes apart. Here’s a timestamp sample for signature 18920/0 alerts:
09:13:04 AM09:23:13 AM09:33:24 AM09:43:35 AM09:53:45 AM10:13:01 AM10:23:12 AM10:33:22 AM10:43:33 AM10:53:43 AM11:02:52 AM
vex.network3.eg was another active attacker IP. What was different about this attacker IP address was that it generated traffic that caused the Multiple Rapid SSH Connections signature (3653/0) to generate alerts in addition to 18920/0. However, it did share some uncanny similarities with tty.network2.eg. It too attempted to log in to a given host every ten minutes. One IPS sensor saw traffic going to multiple hosts on the same network, where each host was running an FTP server. Here’s the alert pattern I noticed:
+-------------------+-----------+| Victim IP Address | Timestamp |+-------------------+-----------+| paz.network1.eg | 07:32:41 || bid.network1.eg | 07:32:41 || foe.network1.eg | 07:42:37 || and.network1.eg | 07:42:37 || sal.network1.eg | 07:42:37 || lad.network1.eg | 07:42:37 || paz.network1.eg | 07:42:37 || and.network1.eg | 07:52:39 || lad.network1.eg | 07:52:39 || met.network1.eg | 07:52:39 || foe.network1.eg | 07:52:39 || foe.network1.eg | 08:02:38 || was.network1.eg | 08:02:38 || and.network1.eg | 08:02:38 || lad.network1.eg | 08:02:38 || met.network1.eg | 08:02:38 || phi.network1.eg | 08:12:39 || lad.network1.eg | 08:12:39 || met.network1.eg | 08:12:39 || was.network1.eg | 08:12:39 |+-------------------+-----------+
If you look closely, you see that this attacker IP attempts to log in to about 5 hosts in under one second, waits ten minutes and then tries to log in to those same hosts again. This pattern is easier to notice when the data is sorted as follows:
+-------------------+-----------+| Victim IP Address | Timestamp |+-------------------+-----------+| ala.network1.eg | 15:02:36 || ala.network1.eg | 15:12:36 || ala.network1.eg | 15:22:34 || ala.network1.eg | 15:32:35 || ala.network1.eg | 15:42:35 || old.network1.eg | 15:22:34 || old.network1.eg | 15:32:35 || old.network1.eg | 15:42:35 || old.network1.eg | 15:52:36 |+-------------------+-----------+
It seems safe to assume that both tty.network2.eg and vex.network3.eg are using the same tool to brute force FTP passwords due to the common attack pattern we see. However, I’ll stay away from that assumption because I prefer to have more supporting data, but it is tempting. If you happen to know what tools these hosts could be running, please let me know.
Well, we saw a correlation between two existing signatures and produced a meta signature to detect more interesting traffic. Then, using NP data from numerous sensors in diverse environments, we were able to analyze attack patterns. While I focused on FTP signatures, what I’m really excited about is analyzing this data to find more sophisticated patterns about emerging threats and then using the result of that analysis to write more focused signatures.