"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?
Panda Security specializes in the development of endpoint security products and is part of the WatchGuard portfolio of IT security solutions. Initially focused on the development of antivirus software, the company has since expanded its line of business to advanced cyber-security services with technology for preventing cyber-crime.
9 comments
i have been looking at this for a long time now and it made me thinking about the issue. my personal conclusion to this is that it is ok to detect packagers, but not in the way mostly see today…
pedro you made a wonderful point, yes there should be an separate option to turn off/on the detection of this packagers, and when detected they should be clearly shown to the user that in this case only a packager was detected.
i simple hate the fact what seem to be this days quite common, when an av vendor detect some file and clams them to be highly suspicious or shows as some advance heuristics was used in the detection when in reality if someone look more closers it is more then clear that the detection was based only the packager.
so as long as you have an separate option for detection packager, similar to what it is common to have to run of heuristics, spyware detection,… and as long as the detection is clearly represented to the users that this was only an detection of the packer (to to mix it with other heuristics, generic,…), this would also probably also mean not to have an big alert on it but more just a simple information warning, then i think packager detections could actuality be a great thing.
Today, the answer is, again, a question: As a Network Admin, ¿why should i allow to get into my network an exe file (packed or unpacked) ? If you can, avoid it.
and what about packers such as Themida, currently used for both malware and goodware, are you going to unpack it? 😉
Good comments. What we’re trying to do is to look at the packing issue from a more efficient perspective. At the gateway level by default not only packers should be blocked but probably all type of executable code as well, as mwdie implies in the above comment. Of course users should be able to finetune and turn on/off at will. At the host level its a completely different story however. Here we would need to evaluate other aspects such as the ones mentioned in the post (receiving vector, hdd location, FP exclusions, sensitiveness of the generic detection per type of packer-UPX, Aspack, Themida-, etc.) but without loosing sight of the real issue behind this; malware techniques have evolved to take advantage of packers in order to avoid detection. We need to adapt to this change to correctly protect users. As long as the impact on usability is managed, is it a good idea to detect them generically?
Hi,
How many types of runtime packers unpack panda?
Thanks
Regards
We are continuously evolving generic unpacking routines based on our proprietary algorithms that interpret the compression and decompression code, aimed at processing as many packers as possible generically. Of course we also have static routines for unpacking those packers mostly used by goodware, more than 50 different know exepackers -without counting their multiple versions- and we continue adding static routines constantly and actively.
On the other hand even if a new variant bypasses sig, static unpacking, deep code inspection and generic unpacking routines, it is not a big deal to us as we still have yet another layer of protection with TruPrevent which performs behavioral analysis of executed code in memory and malicious processes are killed before any harm is done to the system independently of whether they are packer or not.
But even with all these measures in place we’re still asking ourselves if it is really necessary as much continuous effort to tackle a problem that could easily we solved at its root with an apparently much simpler approach.
Ehi pedro,thank you for your reply.
Regards
You’re welcome and thank you for the comments. I’m glad we can talk openly about these things.
Hi all
i think the problem of runtime packers is a big problem for the home users,almost every software is compressed with runtime packers therefore flagging the file as infected or suspect only because it is compressed with a specific runtime packers is wrong,
besides the fact that analysts will waste most of their time because they will need to analyze each file to check if it was really infected it would be better to dedicate to the development of a dedicated unpacker engine and release frequent updatings every 4/5 hours and release a generic signature at least every week.
For example panda employs almost 2 days to include that signature from the delivery of the file,it’s too much time, without even considering the fact that other variants of the malware could still be in the wild the truprevent is a good engine but it cannot sustain everything.
Regards
Lucass