Research

As we get back into Network-Based Threat Intelligence, let’s briefly revisit our first two posts. We started by highlighting the Kill Chain, which delved into the typical attack process used by advanced malware to achieve the attacker’s mission, which usually entails some kind of data exfiltration. Next we asked the 5 key questions (who, what, where, when, and how) to identify indicators of an advanced malware attack that can be captured by monitoring network traffic. With these indicators we can deploy sensors to monitor network traffic, and hopefully to identify devices exhibiting bad behavior, before real damage and exfiltration occur. That’s the concept behind the Early Warning System. Deployment As described, network-based threat intelligence requires monitoring key network segments for indicators of attack traffic (typically command and control). Many organizations have extensive and sprawling network infrastructure, so you probably cannot monitor everything initially. So it’s about initial prioritization of networks to give yourself the best chance to get the Quick Win and hopefully break the Data Breach Triangle. So where do you start? The first and easiest place to start monitoring the network is your egress pipes to the Internet. Today’s malware systematically uses downloaders to get the latest and greatest attack code, which means the compromised device need to communicate with the outside world at some point. This Internet communication offers your best opportunity to identify devices as compromised, if you monitor your egress networks and can isolate these communications. Besides providing an obvious choke point for identification of command and control traffic, egress connections tend to be lower bandwidth than a internal network segments, making egress monitoring more practical than full internal monitoring. We have long advocated full network packet capture, in order to enable advanced analytics and forensics on network traffic. As part of our React Faster and Better research, we named the Full Packet Capture Sandwich: deploying network capture devices on the perimeter and in front of particularly critical data stores. This approach is totally synergistic with network-based threat intelligence, since you will be capturing the network traffic and can look for command and control indicators that way. Of course, if full packet capture isn’t deployed (perhaps because it’s beyond the sophistication of your operations team), you can just monitor the networks using purpose-built sensors looking specifically for these indicators. Obviously real-time network-based threat intelligence feeds integrated into the system are critical in this scenario, as you only get one chance to identify C&C traffic because you aren’t capturing it. Another place for network traffic monitoring is internal DNS infrastructure. As described previously in the series, DNS request patterns can indicate domain generation algorithms and/or automated (rather than human) connection requests to the C&C network. Unless your organization is a telecom carrier you won’t have access to massive amounts of DNS traffic, but large enterprises running their own DNS can certainly identify trends and patterns within their infrastructure by monitoring DNS. Finally, in terms of deployment, you will always have the push/pull of inline vs. out-of-band approaches to network security. Remember that network-based threat intelligence is a largely reactive approach for identifying and finding command and control traffic which indicates a compromised device. In fact the entire Early Warning System concept is based on shortening the window between compromise and detection, rather than an effort to prevent compromise. Of course it would it even better to be able to identify C&C traffic on the egress pipe and block it, preventing compromised devices from communicating with attackers. But we need to be cautious with the bane of every security practitioner: the false positive. So before you block traffic or kill an IP session, you need to be sure you are right. Of course most organizations want the ability to disrupt attack traffic, but very few actually do. Most “active network controls”, including network-based malware detection devices, are implemented in monitoring/alerting mode, because most practitioners consider impacting a legitimate connection far worse than missing an attack. A jury of (network) peers So you have deployed network monitors – what now? How can we get that elusive Quick Win to show immediate value from network-based threat intelligence? You want to identify compromised devices based on communication patterns. But you don’t want to wrongly convict or disrupt innocent devices, so let’s dust off an analogy dating back to the anti-spam battles: the jury. During the early spam battles, analyzing email to identify unsolicited messages (spam) involved a number of analysis techniques (think 30-40) used to determine intent. None of those techniques is 100% reliable alone, but in combination, using a reasonable algorithm to properly weigh techniques effectiveness, spam could be detected with high reliability. That “spam cocktail” still underlies many of the email security products in use today. You will use the same approach to weigh all network-based malware indicators to determine whether a device is compromised or not, based on what you see from the network. It’s another cocktail approach, where each jury member looks at a different indicator to determine guilt or innocence. The jury foreman – your analysis algorithm – makes the final determination of compromise. By analyzing all the traffic from your key devices, you should be able to identify the clearly compromised ones. This type of detection provides the initial Quick Win. You had a compromised device that you didn’t know was compromised until you monitored the traffic it generated. That’s a win for monitoring & analysis! You should worry about whether you will find anything with this approach. In just about any reasonably-sized enterprise, the network will show a handful to a few dozen compromised devices. Nothing personal, folks, but we have yet to come across an environment of a few thousand machines without any compromised devices. It’s just statistics. Employees click on stuff, and that’s all she wrote. The real question is how well you know which devices are compromised and how severe the issues are – how quickly do you have to take action? Intelligence-driven focus Once you have identified which devices you believe have been compromised, your incident response process kicks in. Given resource constraints, it would likely be impractical to fully investigate every device, analyze each one, isolate

Oh F-Secure, how you amuse me. In a post about the hack of Facebook, F-Secure claims it is likely Macs were targeted, and that this could be related to the recent Twitter hack: And while everybody else is bashing Oracle, we have a more interesting question: what malware on what type of laptop? Why? Because Macs are the type of laptop we almost aways see in Facebook’s employee photos. and Well, interestingly enough, last Friday evening, we received (via a mailing list) new Mac malware samples to analyze. Samples that were uploaded to VirusTotal on January 31st, one day before Twitter’s announcement. Now look, I see where they are coming from, and I know Macs get infected by malware at times (especially when targeted), but the evidence is definitely too thin to speak in absolutes here. But then it gets worse: There are hundreds of thousands if not millions of mobile apps in the world. How many of the apps’ developers do you think have visited a mobile developer website recently? With a Mac… and a very false sense of security? Er… how about we go back to Facebook’s post on the hack (quoted by F-Secure themselves): The laptops were fully-patched and running up-to-date anti-virus software. In other words, Mac or Windows, whatever the platform, it was patched with AV installed. That seems like a safer conclusion to draw, without resorting to pictures of Macs on Facebook’s website. Share: