Detecting Malware is Only One Step of Many

Dealing with the malware threat isn’t a Boolean problem anymore. By that I mean being able to detect (and block) a malicious binary isn’t the conclusion to the threat, but rather it’s a perspective on the status of the threat – a piece of evidence tied to the lifecycle of a breach.

Following on from yesterday’s blog covering the Antivirus Uncertainty Principle, I believe it’s important to differentiate between the ability to detect the malware binary from the actions and status of the malware in operation. Antivirus technologies are effective tools for detecting malicious binaries – either at the network layer, or through host-based file inspection – but their presence is just one indicator of a bigger problem.

For example, let’s consider the scenario of the discovery of a used syringe lying on the pavement outside your office entryway. It is relatively easy to identify a syringe from several yards away, and closer you get to it, the easier it is to determine if it has been used before – but it’ll take some effort and a degree of specialization to determine whether the syringe harbors an infectious disease.

That’s basically the role of commercial antivirus products – detecting and classifying malware samples. However, what you’re not going to be able to determine is whether anyone was accidentally stuck by the needle, or whether anyone is showing symptoms of the infectious disease it may have harbored. To answer those questions you’ll need a different, complementary, approach.

In the complex ballet of defense-in-depth protection deployment, it is critical that organizations be able to qualify and prioritize actions in the face of the barrage of alerts they receive daily. When it comes to the lifecycle of a breach and construction of an incident response plan, how do you differentiate between threats? Surely a malware detection is a malware detection, is a malware detection?

First off the bat, the detection of malware isn’t the same as the detection of an infection. The significance of a malware detection alert coming from your signature-based SMTP gateway is different from one coming from your proxy ICAP-driven malware dynamic analysis appliance, which is different again from the alert coming from the desktop antivirus solution. The ability to qualify whether the malware sample made it to the target is significant. If the malware was detected at the network-level and never made it to the host, then that’s a “gold star” for you. If you detected it at the network-level and it still made it to host, but the host-based antivirus product detected it, that’s a “bronze star”. Meanwhile, if you detected it at the network-level and didn’t get an alert from the host-based antivirus, that’s a… well, it’s not going to be a star I guess.

Regardless of what detection alerts you may have received, it’s even more important to differentiate between observing a malware binary and the identification of a subsequent infection. If the malware was unable to infect the host device, how much of a threat does it represent?

In the real world where alerts are plentiful, correlation between vendor alerts is difficult, and incident response teams are stretched to the breaking point, malware detections are merely a statistical device for executives to justify the continued spend on a particular protection technology. What really matters is how you differentiate and prioritize between all the different alerts – and move from malware detection to infection response.

Take for example a large organization that receives alerts that 100 devices within their network have encountered Zeus malware in a single day. First of all, “Zeus” is a name for several divergent families of botnet malware used by hundreds of different criminal operators around the world – and comes in a whole bunch of different flavors and capabilities, and are used by criminals in all sorts of ways. “Zeus” is a malware label – not a threat qualification. But I digress…

Let’s say that your network-based antivirus appliance detected and blocked 40 of those alertable instances (statistically signature-based antivirus solutions would probably have caught 2 of the 40, while dynamic malware analysis solutions would catch 38 of the 40). From an incident responder’s perspective there was no threat and no call to action from these 40 alerts.

That leaves 60 Zeus malware that made it to the end device. Now let’s say that 5 of those were detected by the local-host antivirus product and “removed”. Again, from an incident responder’s perspective, no harm – no foul.

Now the interesting part – what if you could differentiate between the other 55 Zeus malware installations? How does that affect things?

If we assume you’ve deployed an advanced threat detection system that manages to combine the features of malware binary detection and real-time network traffic analysis with counterintelligence on the criminals behind the threat, you could also identify the following communications:

1. 5 of the infected devices are attempting to locate the command and control (C&C) infrastructure of a botnet that was shut down ten months ago. While the Zeus malware may be caching stolen credentials and data on the victim’s device, it cannot ever pass them to the criminals.
2. 20 of the infected devices are attempting to reach old and well known criminal C&C infrastructure; however your content filtering and IPS technologies operate with blacklists that are now blocking these particular domains.
3. 8 of the Zeus installations are old and not “proxy-aware”, and are incapable of reaching the bad guys C&C while those devices are within your network.
4. 6 of the Zeus infected devices are communicating with an external C&C that has been “sinkholed” and is under the control of a security vendor somewhere. While the original criminal operators no longer have control of the botnet, the infected devices are still managing to navigate your network defenses and upload stolen data somewhere – and there’s no guarantee that the remote security vendor isn’t selling that intelligence on to someone else.
5. Of the remaining 16 Zeus infected devices that are successfully navigating your network defenses and are engaging with the remote criminals, 3 belong to a botnet operated by a criminal organization specializing in banking Trojans based in the Ukraine, 6 belong to a botnet operated by criminals that focus upon click-fraud and DNS manipulation based in the Netherlands, and 7 belong to a botnet operator that targets US-based financial sector organizations based in China.

Armed with that kind of insight, any incident responder worth his (or her) salt can easily figure out how to prioritize the next call of actions. While detecting malware is necessary, detecting infections is more important. Moreover, being able to rapidly enumerate the risk posed by an infection and prioritize a response is critical with today’s diverse and agile threat landscape.

Spotting a used syringe is one thing. It’s quite another to identify and support someone who’s been infected with the disease it contained.