While catching up on an old but excellent post by jason geffner on reconstructing import tables I remembered that I've been wanting to study the real impact of packers on the latest malware received at our labs. Many of us AV companies are now more proactively detecting packers as malicious. Although this issue was discussed at length at the International Antivirus Testing Workshop 2007 in Iceland earlier this month, no real conclusion was reached as there is still a major unknown which is the use of packers in goodware and the negative impact on false positives this approach might have.
When it comes to the use of packers in malware here are some stats on the new unique sample submissions we received during the last month (samples seen in previous months were discarded for the study). Using PEid with a customized database of packing signatures (available here), a purpose built emulator and some generic unpacking routines, we found that 79% of new malware is using some type of packing technique or other.
For the study I've grouped together different versions and modified routines of packers, as its common for malware writers to slightly modify known packing algorithms to evade detection. So for example all different versions of UPX plus all modified (or private) UPX routines are grouped under the common "UPX" term. The same applies to the rest of the detected routines.
7 comments
More and more av vendors are only detect the pack of the malware instead of unpacking them.
I think pandasoft should try to report the blacklist packers,so that will improve your detection a lot.
Yes, we’re doing this already for the more obvious “malicious packers” out there. Some of the more current problems lie in unpacking the modified/private versions of known packers. For this we’re really advancing our generic unpacking algorithms.
Another problem is the developer of runtime packers don’t release a method to unpack it
(only for av companies),
in most case, don’t exist a universal procedure for unpacking a specific packer/protector.
Cheers
Exactly lucass. Cooperation between legitimate packer and cryptor and AV manufacturers would ease things quite a bit as well.
This is a big problem, since I am developing a packer called RLPack which often gets detected as a virus. RLPack should not be a problem for any AV company since it comes with a full source. Panda itself is not having this problem with RLPack and I am thank full for that.
On the other topic, I am also working on a commercial depacking and detection project sponsored by a security company which at the moment supports accurate detection of 200 pack formats (it uses far more check then peid) and has support for unpacking of 50 most common ones (including known modifications). And the list is growing every day. So hopefully by the end of the year problems with commercial and free packers/protectors/crypters will be history.
Using PEiD is not reliable for creating such statistics. Some of the signatures have “false positives” and you actually don’t cover multi-layered packed files correctly with PEiD.
Handling the known packers is not really the main problem anymore. Tibs/Zhelatin anyone?
Agreed on both counts SK, that’s why I did not rely on PEiD alone and also used a couple of purpose made tools (emulator and generic unpacking algorithms) to cross-reference the 3 outputs together and manually inspect the ones that didn’t match. These tools of course are able to inspect multiple layers.
Handling known packers has not been an issue for some years now. It’s the purpose-made packers, private or modified versions and the intendedly malicious packers which are the latest fad. One does not have to look very far to find more and more of these being used by malware.