"80% of new malware defeats antivirus" according to AusCERT. Runtime packers and cryptors are some of the main tools in a malware writers' toolbox. By slightly modifying and exepacking their creations they manage to rapidly create new and undetectable variants of their malicious code. There's even specific packers created exclusively to be used by malware, with anti-debugging and anti-virtualization functionality to further hide from being detected. Malware authors have found a cheap and easy way to camouflage their code.
In a quick study of the new and unique malware (new as not previously recorded at PandaLabs) seen by ActiveScan during January 2007, we found that 77% is runtime-packed. By contrast only an insignificant number of our catalogued “goodware” (non malicious software) uses packing techniques. Why do people compress executable files anyway? To save HDD space? It's absurd as there are only a few thousand executable files in today's average 60 to 80GB hard drives. To obfuscate code or as an anti-debugging technique? There are other better suited methods for that. The fact remains that only a minority of non-malicious software uses these techniques.
Some security companies have recently started detecting runtime-packed files generically in their products. Although we mostly only see this in perimeter products for now (Gateways, MTAs, UTMs, etc.) it seems like a good approach as it prevents new malware rather effectively and potential false positives are manageable and non-disruptive.
Now given that there's already real-life companies who have implemented a "no runtime-packed file" policy within their networks, there is an interesting question being raised here; does it make sense to generically detect runtime-packed code at the host level as well as the perimeter?
Of course bringing this security policy down from the perimeter to the host opens up a whole lot of new questions that need to be dealt with, such as:
- The most commonly used packers (UPX, ASPack, …) would have to still be unpacked and analyzed.
- Certain packers which are used almost exclusively by malware writers could be detected generically without a problem.
- The false positive rate would increase slightly with greyware (keygens, shady freeware, cracks, etc.). Dealing with these would generate more manual work for us at the labs but would not significantly impact end users.
- We'd have to be more sensitive in certain locations storing runtime-packed code. For example detecting packed code in the System32 folder would be a clear giveaway.
- Other locations such as non system paths would be less sensitive to a generic detection routine.
- Security products could have a new default setting to detect packers generically which could be turned off by users and administrators at will.
Is it worth using this opportunity and preventing a significant large portion of the new malware generically? We have been giving this issue some thought and it really simply boils down to the old usability vs. security balance. Comments?