Writing good antivirus software is hard. Just ask the developer at a major antivirus company who was infected with the Coreflood trojan on his personal computer for over a year. Perhaps he was just testing their product, but it seems odd to have allowed the trojan to capture some of his personal information. Fortunately the antivirus developer was not a domain administrator on the company's network, so Coreflood didn't spread to every other system in the Windows domain like it did at several other businesses, hospitals and government organizations.
One might assume that by now, that the antivirus company, employing the developer, would detect the specific version of Coreflood that he was infected with on February 23, 2007. Sadly, they still do not. The reason probably stems from the overarching problem that all antivirus companies face, and Coreflood is as good an example as any. There have been dozens upon dozens of Coreflood variants over the last six years. Virus and trojan authors these days are in it for the money, and more infections equals more money. And less detections equals more infections. So constantly rebuilding the Coreflood trojan to evade detection is part of the bad guys' business model. And it's easy programs that scramble a trojan's code to avoid anti-virus detection are available everywhere and most of them are free. The antivirus industry is really fighting a losing battle they have to invest as much effort in reverse-engineering executable packers as the whole of the criminal underground spends in writing them, and this translates into a lot of time spent (and profits lost), since it always takes longer to reverse-engineer something than it did to engineer it. Therefore it's not surprising that AV detection rates for new variants of most malware are simply abysmal.
But while the packed Coreflood code might change weekly, it is interesting to note that the network traffic pattern that Coreflood uses when checking in with the controller has not changed substantially in the last two years! The intrusion (really extrusion) signatures we wrote for our clients back in 2006 are still effective at locating Coreflood infections today. It goes to show that fighting malware requires a multi-faceted approach: defenses against the infection vectors (exploits and social engineering), system-level protection, and extrusion detection to fill the gaps. Increasingly we are using our iSensor(?) intrusion prevention platform to do just this. Every day our malware research department analyses a large number of malware samples in order to improve our clients' security posture and prevent information leakage by botnets like Coreflood.
Of course, we're not alone in recognizing extrusion detection as a key part of defense-in-depth. For example, the Emerging Threats project maintains sets of extrusion-detection rules for the open-source Snort IDS platform. Since Snort operates in detection (instead of prevention) mode, using it won't stop data leakage or malicious commands from being downloaded by infected systems, but it can at least alert network administrators of infected workstations so that they can respond, and hopefully re-evaluate their defenses based on the frequency and types of infections occurring on their network.
At its core, the determination of malware versus non-malware with 100% certainty can only be accomplished by knowing the intent of the author, something that can't always be divined by scanning the bits and bytes of the code. Thus, no product can ever provide a 100% solution against past, present and future malware infection. However, extrusion detection and prevention continue to be invaluable tools in today's world, where botnets lurk in the shadows and siphon data from every corner of the network.