Packer (r)evolution

We know for sure that cyber-criminals use private tools to check AV detection prior to releasing new malware in the wild, making sure it goes undetected by AV signatures at the time of release. As AV companies identify new packers and are able to inspect inside them (or simply identify the malicious packer itself), the bad guys are releasing those which are not detected by most AV.

 

This has transformed the packer world significantly. The "big name packers" are decreasingly being used by malware. By contrast new packers types are surging which have two main characteristics: (a) they are not widely used in order to stay below the radar and (b) they use obfuscation or anti-debugging techniques.


What we're seeing is that:

  • Increasingly, malware families use their own 'customized' or ‘private’ packers, which are not recognized by most AV engines.
  • There's a large variety of packers, each with its own little variations, being used by a reduced number of malware variants.


The strategy these criminals are following is to quickly develop customized variants of packers and use them in very few samples. By the time the AV companies identify the samples and add the unpacking routine to their engines, they already have a new batch of packing variations in store which is being applied to the next batch of samples.


As an exercise we’ve analyzed all the samples Panda has seen in-the-wild (actively infecting two or more different sites) since August 2007 to March 2008 and looked at the ‘big name packers’ used by these:

 

It’s interesting to see how the ‘big name packers’ such as UPX, PECompact, Themida, PEtite and NSPack are dropping in use, while smaller packers such as nPack, PolyEnE and EXECryptor have increased in a significant way.

 

But what’s most interesting is what is not seen in the above summary chart, and that is the ‘customized’ or ‘private’ packers. We know for a fact that approximately 90% of malware uses some sort of packing or obfuscation technique, yet the proportion of private, non ‘big name packers’ is increasing rapidly.

Could this be the start of the long-tail of packers?

But when we try to analyze the true reasons behind this evolution in packer use that’s when it starts getting really interesting. Other than the obvious reason which is that bad guys are trying to make our jobs harder at the lab, how come they started creating customized and private packer versions on a very regular basis?

As this is a cat and mouse game, the mice’s next move is directly determined by the cat’s strategy for catching the mice. If we apply this example to the packer/malware world, there are two main events in the AV industry which I believe have driven malware authors to go into ‘packer-craze’:

  1. The addition of many unpacking routines in AV engines as new packers emerged.
  2. Starting to detect malware based on its packing properties without unpacking it (multi-packed files, packers used exclusively for malicious purposes, etc.).

Now I’m not saying the above actions are wrong. They were necessary at the time in order to correctly protect customers and continue being necessary today if we want to keep the pace.


I remember a conversation with my colleague Mark from Symantec last year where we talked about precisely this issue. If we start detecting all packers proactively, what will the bad guys do next? I guess we’re about to see as the packer problematic has completely blown out of proportion.

Category: ,

Comments

Excuse me.

Then how Panda sloves this kind of problem?

   Posted by KEIKA at 20 March 08 5:20 PM

keika panda have a "malicious/packer" signature this signature detect the packer use by specific family of malware, for example Wsnpoem and detect the exotic packer use by malwares, sorry i don't know other trick use by panda.

Cheers

   Posted by lucass at 21 March 08 4:24 PM

Without going into much detail, as lucass says we have packer signatures for the most obviously malicious packers. Also we use the packer information as heuristic flags. In addition we also continiously add unpacking algorithms for new packers found so that we can inspect inside them.

   Posted by Pedro Bustamante at 23 March 08 10:38 AM

Consider a bot net, sending a firstly packed and then EXECryptor'ed version of a trojan horse only a few times before generating a new version. Are there efficient ways to detect these, without having the scanner to emulate the program until it reaches signaturable code? Can Panda stand against such a scenario?

   Posted by Moritz Kroll at 23 March 08 3:03 PM

We've been giving some thought on how to answer your question Moritz. The short answer is yes, but we won't disclose how.

   Posted by Pedro Bustamante at 27 March 08 12:26 PM

Well, that's quite a disappointing answer for a "research blog".

I threw this in, because I think this would be the current horror scenario of AV researchers. And I've been thinking about ways, how to get through the EXECryptor "shield" to recognize what's inside.

My basic idea is to simulate the code until some point (e.g. until the main code has been unpacked and the imports have been restored) and from there on build up some kind of intermediate language for the executed code in a simplified form (meaning constant folding etc.). Using graph transformations one could try to simplify the code even more (counteract the "hundreds of unique code transformation patterns") and try to convert it into a somewhat "normalized" form which may possibly be usable for signature generation. Of course this still yields the problem, that at the begining of the program there could be "good" code whereas the "bad" code hides much deeper in the crypted cavern.

The reason I asked you was, that I wanted to know, if this problem can be solved in a much easier way (without considering behavioural blocking). Saying "The short answer is yes, but we won't disclose how" might imply, that you found a weakness in EXECryptor which suffices for AVs. But this will probably be "fixed" after some time (either by StrongBit or by VX groups) and then you'll have to dig deeper.

I'd be very happy to hear something about my idea, as it is going through my head for several months already. If you want to take this to a less public place, feel free to send me a mail.

Btw, do you think packed or crypted programs which have been crypted again should be generally flagged as "probably malicious"? I don't think such programs would make sense for normal commercial products trying to avoid being cracked.

   Posted by Moritz Kroll at 29 March 08 1:05 AM

To answer your first question, we won't disclose it publicly because we do not want to give clues to malware writers or creators of these packers. Feel free to contact me privately and we can discuss this further.

Regarding the flagging of multi-packed/crypted files, the answer is yes. We started doing that already a few months ago, but it depends on the levels of packing. I know some AV engines are flagging double-packed files, which still generates too many False Positives for comfort, as these have to be dealt with manually and creates a lot of work at the lab.

We're also flagging obviously malicious packers, ie. packers which are exclusively used for malware distribution and not found in goodware.

   Posted by Pedro Bustamante at 31 March 08 10:54 AM

Post a comment

 
 

Share it: Print