Counterattacking the packers
Gaith Taha McAfee Avert Labs, Aylesbury, UK Email gaith_taha @ avertlabs.com
Abstract Despite the fact that run-time PE packers have demonstrated some usefulness in a number of applications, the sins of their main users have outweighed any goodness the packers might have had. This paper proposes a multi-dimensional attempt to be carried by the anti-virus industry in order to stop the spread of bespoke packers written specifically to conceal malware. Introduction Contrary to ordinary compilers that generate uncompressed Portable Executable (PE) [1][2] files, runtime-packers [3] come with an objective to condense executables and shadow any algorithms or data the original files had contained. Those packers try to accomplish different tasks like reducing the size of the files or protecting the host from being easily reverse-engineered. Some of those packers are polymorphic and aim to generate different variants of a single file every time the file gets repacked. Packers were first written in order to provide a mechanism to shrink executables so they take less space to store and less time to transfer over slow channels. Later on, their usage started taking another scope when malware authors used them to conceal their parasites. There are few reasons behind this intimate relationship between malware authors and packers. 1) Packers always offered a safe haven for malware authors where they managed to disguise the code and data their malware contained. Likewise, in some cases, packers provided them with different looking binaries each time they repacked their code. A technique commonly used against checksumming. 2) Releasing a repacked malware sample means that the author does not have to do any substantial work on his code-base aside from minor changes – which are not needed when polymorphic packers are being used. 3) They also depended on the fact that AV vendors rarely detected packed code, just because it was packed (morphine packed samples would be a good example of packer-detection). Consequently, malware authors regularly used packers that are both used for innocent purposes and non-trivial to unpack. Magnitude of the problem Undoubtedly, the single most challenging problem AV vendors currently face is the problem of packed malware. Traditionally, AV vendors dealt with packers by providing their engines with unpacking routines to normalise the executables and generate the unpacked version of the file. This was achieved through two different ways. By either releasing updated engines, or releasing new signatures that contained the unpacking routines which will be interpreted by the engines at the users' end. AV vendors who have followed the former method suffered from the slow cycles in which their engines had to go through before being fully tested and ready to be released. While the latter method gave some AV vendors an edge by providing faster updates, they still had to invest more resources into analysing the different packers that got released restlessly.
Packed vs. Non-packed malware (Jan 2000 – Sept 2007)
With different degrees of success, both solutions have not been bulletproof as some packers proved their resistance to unpackers. Another dimension of the problem will be revealed when we look at the graph that spans seven years' worth of published of malware. Clearly, we can observe the trend in which packed malware is growing versus non-packed malware. A further extension for the problem is the fact that some software vendors and for no obvious reasons decide to publish their software packed with rather very suspicious packers. It is an evident problem of education. In one example we have seen, a computer games' vendor decided to pack their software with a modified version of UPX which has been released in some underground websites and was solely used by malware authors. Those games were later distributed to endusers by another personal computers manufacturer! In 2007, we in Avert Labs started experiencing the birth of at least one packer or a variant of a packer on a daily basis. With such an alarming rate, the AV industry needs to make some radical changes to the way it has been dealing with packed malware. By checking the graph below we can clearly see that during Q3 of 2007 the rules of the game have changed and it is no longer a few packers that dominated the scene. Instead, a lot of different variants of unknown or patched packers that reserved the top position in terms of quantity.
This relationship is projected to worsen simply because mass producing those packers is much less costly than coding their unpackers. Proposal Before going any further on the proposed solutions, I will have to make it clear that there is no magic wand that AV researchers can use against packed malware. Nonetheless, “anti-malware” products can implement a set of countermeasures which would minimise the impact of packed malware to some large extent. AV vendors will have to start detecting new suspiciously-looking packers as they emerge. This approach would force malware authors to write new packers rather than just making little modifications to the code-base of their malware or packers. Evidently, it is a more complex task to write a new packer. On the other side, early detection of new packers that are being solely used for malicious purposes will prevent any "innocent" future use. Hence, AV vendors will not have to live the anxiety of generating false positives. This paper lists a number of suggestions to fight the spread of packers. 1)Blacklisting specific packers. This method is already in use by AV vendors, but only against very limited number of packers. 2)Blacklisting all packers and only allow known innocent applications. 3)Blacklisting all packers and allow for user-configurable exceptions. Traditionally, this option has been discarded by AV vendors as they had to make all decisions on the users' behalf. 4)Blacklisting all packers while only allowing digitally signed executables [4]. 5)Blacklisting packed files that match certain criteria 1. Size: This is a strong criteria as most malicious files have small size, while useful applications tend to be bigger. 2. Level of obfuscation: Packed files that contain detectable anti-debugging, anti-emulation, or other AV-evading techniques. 3. Deployment environment. AV engines can have different levels of tolerance against packed samples depending on the environment they were found in (e.g. corporate users, home users, or network appliances) 6)Blacklisting packers outside areas of innocent usage by utilising locales or other indicators of users' geographical location. An example of these packers is NSpack. NSpack is a packer of an east Asian origin. We often find innocent samples that are packed with yet more patched versions of NSpack which are only expected to be seen in malicious samples. With no surprises, we tend to find the software vendors who have used those variants of NSpack coming from the same region.
Conclusion In order for this initiative to succeed, anti-virus vendors need to come to an agreement around detection of new packers. Spending a lot of time and effort on developing and integrating unpackers into AV engines might not be needed where mere detection suffices. By blocking packers on the user-end, AV products can immediately increase their efficiency by approximately 60%. Obviously, this number will decline once we allow certain packers – like UPX et al - to bypass.
References [1] Microsoft Portable Executable and Common Object File Format Specification. URL: http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx . Last seen: October 5, 2007. [2] Portable Executable. URL: http://en.wikipedia.org/wiki/Portable_Executable . Last seen: October 5, 2007. [3] Executable compression. URL: http://en.wikipedia.org/wiki/Executable_compression . Last seen: October 5, 2007. [4] Muttik, Igor. Personal conversations. This option has been discussed in Reykjavik's AV meeting. May 2007.