A Heuristic Approach for Detection of Obfuscated Malware

Scott Treadwell, Mian Zhou

Bank of America, 1201 Main St, Dallas TX 75202 {Scott.treadwell, Mian.zhou}@bankofamerica.com

Abstract. Obfuscated malware has become popular because of pure benefits brought by obfuscation: low cost and readily availability of obfuscation tools accompanied with good result of evading signature based anti-virus detection as well as prevention of reverse engineer from understanding malwares true nature. Regardless obfuscation methods, a malware must deobfuscate its core code back to clear executable machine code so that malicious portion will be executed. Thus, to analyze the obfuscation pattern before unpacking provide a chance for us to prevent malware from further execution. In this paper, we propose a heuristic detection approach that targets obfuscated prior to windows binary files being loaded into memory execution. We perform a series of static check on binary files PE structure for common traces of a packer or obfuscation, and gauge a binarys maliciousness with a simple risk rating mechanism. As a result, a newly created process, if flagged as possibly malicious by the static screening, will be prevented from further execution. This paper explores the foundation of this research, as well as the testing methodology and current results. Key words: Obfuscated, malware, heuristic, detection, PE header.

works by taking an existing application, compressing it, and then wrapping a small unpacking utility around it. Analogous to the Russian nested dolls [1], the outer layer works to unzip the inner executable in memory and transfers execution to it. Figure 1 shows a high-level view of a normal PE file, while Figure 2 shows its packed counterpart. The difference, as seen in Figure 2, is that the packed executable is actually contained within the normal executable. This shell is simply designed to unpack its payload and transfer execution to it.

I.

INTRODUCTION

In todays increasingly interconnected workplace, there is an ever-increasing rate of viruses, malware, and 0-day exploits attacking the frameworks of this interconnectivity. Computer malware, like its biological counterparts, need a host with which to spread. In modern platforms, this requires that the binaries get loaded into memory in order to execute. This can be done in a variety of ways, but the fact remains that the malicious code must be executed thus, it must at some point be loaded into memory. Outside of an application exploit, most modern primary and secondary infection points occur from the execution of some malicious binary file once loaded into memory. In modern threat landscapes, this malware is either packed, encrypted, or both. The purpose of which is to prevent reverse engineering, and to lengthen the time to (if not completely evade) antivirus detection. However, the methods used by packers and cryptors to prevent reverse engineering, also make them stand out as abnormal often containing non-standard PE format such as non-standard section names, unusually large section sizes that usually contain null bytes, an entry point that resides outside of the code section, and limited imported library functions, etc. A. Anatomy of a Packer To better understand normal verses abnormal PE files, we need to understand how a packer works. A packer

Figure 1. PE structure of a normal executable.

As stated above, the general purpose of packing is to prevent easy detection by anti-virus vendors. This works because of the inherent way AV products generate signatures. The AV community looks for a unique series of bytes within a given file (usually within the code section, but doesnt have to be). Those unique bytes become a signature from which the AV product will identify malicious files. The problem lies in the fact that there is nothing inherently malicious about a packer or unpacking code. Generating a signature based on that code could potentially lead to erroneous false-positives, negating the usefulness of the AV product. It would be ideal if we can generate a signature on the packed executable. However, packing an executable (and possibly encrypting it) removes any real ability to determine what is unique that is, what the payload is trying to accomplish. Even when you create a signature for the file, simply changing a flag on the packing can completely change the contents and the signature

978-1-4244-4173-0/09/$25.00 2009 IEEE

291

ISI 2009, June 8-11, 2009, Richardson, TX, USA

becomes invalid. If polymorphism is involved, it is practically impossible to create any kind of useful signature. It is for this reason that it becomes vitally important to develop a method where signatures are not truly needed to catch malware. This paper is to discuss a method that uses the simple characteristics of malware vs. normal files to determine the likelihood that the file is itself malicious.

Mandiant s Red Curtain [6][11] is a recent research product that similar in concept to what we focus on, with a straightforward approach to deal with obfuscation. Red Curtain conducts static analysis on the windows PE structure for the presence of obfuscation. It first calculates the Entropy value against the content from each section: .idata, .text, etc. and then compares the Entropy value with a threshold to determine if this section has been obfuscated since the Entropy value is to measure the randomness, and obfuscated code would appear to be more random than otherwise. Other related static methods [9][10] detect malicious obfuscated code by comparing a list of extracted system calls with those made by known, malicious code under the hypotheses that many malwares are simply twisted versions that share same features of the original one [9]. That method requires obtaining a signature set of identified malicious system calls before further detection. The advantage there is that it can detect the polymorphic or metamorphic malware. In [10], no explicit signatures are generated and a semantic analysis framework is applied to identify malwares behavior. This method is a general approach focusing on program language aspect analysis and not on analysis from windows PE structure aspect. The remainder of this paper is organized as follows: Section 3 describes various packer analysis checkpoints; Section 4 presents the implementation risk score mechanism that used to calculate the final risk score; Section 5 reports the experiment result; and Section 6 provides conclusion as well as some possible future work. III. ANALYSIS ON PACKING TECHNIQUE From the background discussion, we know that the growing trend in malware is to utilize packers/cryptors to hide the true intent of an executable. However, the method of hiding also leaves certain observable characteristics that can help us identify potentially harmful files without the need for signatures or virus definitions. To do this, we employ a risk model on the observable characteristics under static analysis of a given file. In order to provide the static risk analysis of a binary file, we must first identify the characteristics (observable) that are most likely to change with malware. As discussed in section 1, we will look at the section names, import functions count, and entry point location; as well as DLL characteristics, TLS inclusion, import ordinal values and other PE format characteristics for abnormalities. A. Non-Standard Section Names Microsoft has published [2] a set of standards and baselines for use by developers for the creation of PE and COFF file formats under the Windows family of operating systems. These are the default characteristics that are upheld by compilers that create the specified files. A very important thing to note is that not all compilers that create Windows binary files behave the same. While GCC and Visual Studio may use .text to label the code section, Borland may use .code. Regardless, compilers have documented standard names which they use to describe the sections they create (see Figure 1). While compilers do give the developers the ability to create their own section names using special

Figure 2. PE structure of a packed executable.

II.

RELATED WORK

Obfuscation is a common term referring any method that is capable of transforming original program code into an unreadable or misleading form in hope of concealing the true purpose of code from direct interpretation by a human being. The obfuscation can be applied to binary machine code or high-level program language such as java or javascript embedded in web traffic [7]. Based on different objects and different purposes, either legitimate or malicious, obfuscation techniques vary greatly. In our research, we only address the malicious obfuscation that applied to windows binary code. While some researches focus on deobfuscation of actual obfuscated code in order to reveal true intent of that piece of code [8][12], we care about the detection of malicious obfuscation, and we do it by examining the overall suspicious patterns in Windows PE structures rather than deobfuscation. Based on where the detection happens, either before the code gets loaded into the memory or after, the detection approach can be categorized into static vs. dynamic strategies. The dynamic strategies require the code to run first in a virtualized environment or Sandbox in order to be identified by its actual behavior [13][14]. Deobfuscation or unpacking through a debugger is commonly used for manually tracking behaviors of the code [15][16], and the code itself is not necessarily obfuscated. Our research primarily focuses on the static approach of malicious obfuscation detection.

292

flags in their code it is not often enough to deviate from a baseline standard. An exception to this is in the case of malware. Most of todays common packer/cryptor in use creates new section names so that the unpacking code can recognize the pieces to actually unpack. No observed obfuscated malware known to this author uses, in their entirety, standardized section names. We use this fact as a characteristic to flag on. One further note about each section is that the compiler defines characteristics for each defined section. This aids the loader in being able to mark the allocated memory sections and set the behavior that is expected for each section. For example, your code section is marked executable as this is where the actual execution is to take place; but the section that contains the variable information is not. We also check the sections against their documented characteristics. This is to ensure that the malware writers have not modified standardized sections for other purposes. B. Flagged Section Names To further the section analysis, there are also some fairly standardized section names that are used by packers and cryptors. While these can be changed, it has been observed that most are not. We use this observation to further determine the potential for malicious characteristics. Examples of flagged section names are .UPX and .aspack just to name a couple. C. Entry-Point resides outside code section

The reason we do this is that some malware, such as file appendors, will modify this address to point to a non code section. Specifically, it will point outside the .text section marked as code. In this example however, we see that the entry point falls within the range between the Virtual Address and Virtual Size, thus resides within the code and executable section (see Figure 4).

Figure 4. The entry point address 0x00002C7B is located within section .text.

This type of check is useful for packed and encrypted files; but is key among pre- and post- file appendors. A check can easily be done in the call and control flow graphs to determine if any execution can pass outside the code and executables sections as well. D. Thread Local Storage (TLS) Section Check Given the above discussion regarding the entry-point of executables, one exception is that of the Thread Local Storage entry point. Since the days of Windows NT, Microsoft has provided a mechanism that allows multithreaded applications the ability to provide functions and separate storage for thread-specific needs. This includes the ability to execute functions for initialization. Before the Windows loader transfers execution to the main entry point, it first looks for a TLS data directory defined in the PE header [3]. If one is defined, it will perform the functions defined within this directory first. This undocumented feature will be executed anytime a thread is created or destroyed. Since running an executable is essentially creating a thread (main thread of execution) to execute the program, the loader interprets this as a thread creation and executes the code in the TLS section assuming the need for thread initialization. Figure 5 shows the TLS entry in the Data Directory.

Earlier, we discussed that one of the main purposes for packers and cryptors is the authors desire to obfuscate what the contents of the file are thus hiding the malwares intent. One way to accomplish this is to obfuscate the entry point of the program. The entry point is the address where the loader passes execution to the application. This address is defined in the header of the PE file as can be seen in Figure 3.

Figure 3. Entry point in the PE header.

This address, given in hexadecimal, is an offset from the Image Base address. From Figure 3, we can get the entry point of this executable by the following: Image Base + Address of Entry Point. In this example the entry point would be at address 0x00402C7B. The next step is to find what section this entry point falls into.

Figure 5. TLS entry in the data directory

293

One thing to note about this directory entry is that the loader will only attempt to execute it if the Virtual Address does not equal to 0. A check of the size is not actually done regardless if the Virtual Address is defined. E. Dynamically-Linked Library (DLL) with no Exports Dynamically-Linked Libraries are, by their definition, a file that contains a library of functions. They provide functions to calling applications to promote the write-onceuse-many philosophy. DLLs typically allow for more than one application to use them at a time. By this very definition, DLL files should be exporting at least one function to be used by applications. DLLs are structured similar to standard EXE files in that they contain a Main function (DLLMain) for initialization purposes. Whenever a DLL gets loaded, this function is called to help initialize the DLL. Microsoft also provides a mechanism that treats DLL files in a similar manner to EXEs; this application is called rundll32.exe. This application will allow someone to execute an exported function from a DLL from the command-line. Attackers can utilize this to simply create a DLL with no exports and the default MAIN entry-point. Using rundll32 and passing it the name of your DLL will cause the DLL to be executed in a similar fashion to an EXE. Knowing this, we look for any DLL files that are being loaded that contain no actual exports. While it is possible to be legitimate, we will flag this as suspicious for further analysis. F. Low Import Function Count It has been well documented that modern malware packs/encrypts itself to help obfuscate its real intention. Part of this behavior includes hiding the actual functions needed by the obfuscated program, or more likely, that the packer simply packs them up as well only requiring the needed functions to perform the unpacking. Most good packers require only 2 functions to successfully unpack a file LoadLibrary and GetProcAddress. This allows them to call any library and function, at will, as they need them. This further helps to obfuscate what the unpacker is doing as well! To give you a better idea take the following simple Hello World! program: int main(int argc, char **argv) { printf(Hello World!\n); return 0; } When this is compiled with MS Visual Studio, it contains over 30 imported functions; and I am only actually calling 1! Utilizing this knowledge, we do a check on the number of imported functions a file has. If it falls at or below a defined threshold, it is flagged as suspicious.

G.

Import Function Table Check Most packers and cryptors do not need to care about the import table of a PE file because their sole job is to simply unpack the packed file(s). And for this, libraries are not needed. All modern packers are quite poorly written in that they do not create baseline adhered PE headers. The Windows loader only truly needs a few entries of the header file to run properly the import table is one of them. In this case, most packers will mangle the import table of the packed file to save from having to properly align and reconstruct the table itself. For an unpacked PE file, it will have its import table filled with either the import API names or the ordinal value of the APIs within that import DLL. Whether import table array will point to an API name or ordinal value depends on if delayed loading on imported APIs is required. In most cases when a delayed loading is not involved for an API, IMAGE_IMPORT_BY_NAME structure will be used to describe the API. IMAGE_IMPORT_BY_NAME structure contains two fields: Hint and the APIs name. For a packed PE file, it has been observed that it has a higher chance to have zero hint values along with non-empty API names comparing to an unpacked PE file. On the other hand, if a delayed loading is involved for an API, the IMAGE_THUNK_DATA will simply point to an ordinal value instead of IMAGE_IMPORT_BY_NAME structure. Ordinal values are values that are used to find import functions within a DLL. This aids the Windows loader to find the proper function in memory and resolve the address of it to Import function table of an application in the case of delayed loading. It has been observed that packed files rarely have delayed loading for its API.
C

Based on the above observation, we check every function (if they exist) in the import table for their hint values if no delayed loading involved, a 0000 hint value would have a higher probability indicating a suspicious file containing a malformed import table. On the other hand, we check the 0 ordinal value to see if it corresponds with delayed loading. A legitimate file with properly constructed import table should have non-zero ordinal value for its delayed loading API, we flag on zero ordinal value for those files that use delayed loadings. IV. IMPLEMENTATION AND RISK CLASSIFICATION

We have implemented the risk structure outlined above as a DLL file that operates over X86 Microsoft Windows platforms processing each file loaded by certain process calls within the windows loading API mechanism. Our implementation first does the static analysis against a Windows PE file and generates a risk score. If the risk score is below a triggering threshold, this PE file is loaded into the memory silently as usual. If the risk score is above the triggering threshold, a popup window will be prompted to users requiring further actions. We utilized a risk analysis matrix and compiled a riskscore to determine the probability of maliciousness for any file under analysis. The formula to calculate risks starts by using a simple weighted means across the characteristics under observation:

294

R >= 4

(w u r ) w
i i i 1 i 1

Where wi and ri are weight and risk score associated with characteristic i. R is the overall risk score of a binary file. Currently we check totally 8 characteristics for suspiciousness. Each checked characteristic is assigned with a weight and a risk score. The risk score ri indicates how risky the characteristic i is if found in the binary file. We assign a predefined risk score for each of 8 characteristics based on our experience and the comparison between malware and legitimate system files. The characteristics weight is reversely proportional to the frequency of those 8 characteristics shown by normal non-packed system files. Since normal system files are expected to be exempt from all of those above 8 characteristics, the characteristic that has higher frequency/possibility to be contained in normal files has less weight in deciding the final risk score. We use clean windows system files under Windows system folder to check out the presence of above characteristics. The following weight present in tables is the result after running through a typical setting of our windows XP system with 2014 windows systems files. In all, the risk score and weight we used in evaluating the likelihood of obfuscated malware are as shown in Table 1.
TABLE I. RISK SCORE AND WEIGHT ASSIGNED TO EACH CRITERIA.

On the malware side, for the preliminary 144 confirmed malware samples we collected, 65 of them are packed with known packers, and 79 of them are either packed with unknown packers or unpacked. The complete detection rate with different risk score thresholds are shown in Table 3. We use the signature set from PeiD [4] for packer identification. Among all 65 confirmed packed malware samples, we obtain 89.2% or higher detection rate with risk threshold of 3. Among all 144 malware samples, we flagged 84 suspicious files (58.3% detection rate) with threshold of 3, which is a reasonable result for us since our detection tool only targeted obfuscated malwares rather than unobfuscated ones. We have detailed risk score output for all malware in the appendix section. Roughly speaking, if we use a threshold of 1, then we will have 95.3% detection rate, but 3.94% false positive rate. If we use a threshold of 3, then we will have 89% detection rate and 1.6% false positive rate. Other than the test on a relatively small amount of confirmed malware samples, we regularly collect potential malware samples through various means. We track downloads in the real environment, and record the antivirus detection results as well as our detection result, a snapshot of this is shown in Figure 6. Our tool is able to detect obfuscated virus with a much higher accuracy when compared with an AV product such as Symantec. The signature based detection strategy is less efficient whenfacing obfuscated malware files. VI. CONCLUSIONS AND FUTURE WORK Malware obfuscation has cause great difficulty for signature-based anti-virus product. In this paper, we present a heuristic method for detection of windows based obfuscated malwares. Our method scans for suspicious patterns in the Windows PE structure before the binary gets executed. A proof-of-concept detection tool is developed and we tested it on the malwares we collected within the bank, and it shows better detection rate on packed malwares comparing to signature based anti-virus product. The detection system is integrated with window loading mechanism and tested further for desktop validity. The outcome of which is to produce a screen mechanism

Checked Characteristics Abnormal_ordinals Nonstd_name In_code TLSsection DLL_no_export Flagged Section Name Low function Call Other_badPEformat

Risk 10 1 5 10 5 10 10 10

Weight 6 6 12 50 20 100 35 100

V.

EXPERIMENT

With above risk score and weight, we run our test against both malwares and unpacked system files. Among total 2014 normal windows system files, the highest risk score is 3.24, with majority of them scoring lower than 1. We will have 0% false positive rate if we apply the risk score threshold 4, 1.6% with threshold 3 and 2.3% with threshold 2 as showed in table 2.
TABLE II. FALSE POSITIVE RATE ON 2014 WINDOWS SYSTEM FILES AT C:\WINNT\SYSTEM32\ WITH RISK SCORE THRESHOLD 1, 2, 3, 4.

R >= 1 R >= 2 R >= 3

Count 78 46 32

FP rate % 3.872 2.284 1.588

295

TABLE III.

THE DETECTION RATE ON CONFIRMED 144 MALWARE SAMPLES (PACKED OR NOT PACKED) WITH RISK SCORE THRESHOLD 1, 2, 3, 4.

Packer grouped by PEiD signature (count) Various UPX (34) Packed WWPack32 (1) (65) UpackV3.0X (10) TElock (4) PECompact (1) PCShrink (1) NsPack (2) AsPack (8) CodeCrypt (1) ASprotectv1.2 (1) Overall detection rate for packed Overall detection rate in % Unknown Mircrosoft VC (12) N/A (67) and not packed (79) Overall detection rate for both Overall detection rate in %

#Detected R>=4 18 1 1 1 0 0 2 5 0 1 30 46.1% 0 13 43 29.8%

#Detected R>=3 34 1 10 1 0 0 2 8 1 1 58 89.2% 3 23 84 58.3%

#Detected R>=2 34 1 10 1 0 1 2 8 1 1 59 90.7% 4 30 93 64.6%

#Detected R>=1 34 1 10 4 0 1 2 8 1 1 62 95.3% 4 36 102 70.8%

Figure 6. The detection result from Symantec (column 4), virusTotal [5] (column 5) and our tool (column 8). We detected much higher percentage of malwares compare to the detection rate of Symantec.

that will perform the risk analysis of any image that is being loaded into memory for execution. One drawback is that not all legitimate applications completely free of above unusual PE structures. When tested on winnt/system32 files, we had 32 out of 2014 (1.6%) files reported risk score higher than 3, including some from legitimate applications pushed by third parties, and they do not necessarily contain obfuscated code and correspondent code for decryption. Many possible solutions exist for reducing false positives caused by such. As a future work, we will focus on the possibility of

combining our current work with additional components to improve the accuracy of detection.
References
[1] Craig, Paul. Unpacking Malware, Trojans, and Worms: PE Packers Used in Malicious Software. Ruxcon 2006. http://www.slideshare.net/amiable_indian/pe-packers-used-inmalicious-software-part-1/ (2006) Microsoft Corporation. Microsoft Portable Executable and Common Object File Format Specification. http://www.microsoft.com/whdc/system/platform/firmware/PECO FF.mspx Szor, Peter. The Art of Computer Virus Research and Defense. Addison Wesley, (2005)

[2]

[3]

296

[4] [5] [6] [7]

PeiD packer signature, http://peid.has.it/ Virus Total online suspicious

file
H

analysis,

http://www.virustotal.com/
H H H

Red Curtain. http://www.mandiant.com Q. Zhang, D. S. Reeves, P, Ning, S. P. Lyer, Analyzing network traffic to detect self-decryting exploit code ASIACCS, ACM (2007) [8] S.K. Udupa, S.K Debray, M. Madou, Deobfuscation reverse engineer obfuscated code . Proceedingof the 12th WCRE (2005) [9] A. H. Sung, J. Xu, P. Chavez, S. mukkamala, Static Analyzer of vicious Executabless(SAVE). Proceeding of 20th ACSAC (2004) [10] M. D. Preda, M. Christodorescu, S. Jha, S. Debray, A Semanticsbased Approach to Malware detection. Proceeding of the 34th ACM SIGPLAN-SIGACT symposium on POPL (2007)

[11] R. Lyda, J. H. Mcdonald, Using Entropy Analysis to Find Encrypted and Packed Malware, IEEE Security and Privacy, (2007) [12] A. Lakhotia, E. U. Kumar, M. Vennable, A Method for Detecting Obfuscated Calls in Malicious Binaries, IEEE transactions on Software Engineering, Vol 31, No 11, November (2006) [13] Norman, Hhttp://www.norman.comH [14] VMWare, Hhttp://www.vmware.comH [15] Ollydbg, Hhttp://www.ollydbg.deH [16] Windbg, http://www.microsoft.com

Appendix: Risk Score for a list of Malwares

Malware junk-w32-Pretty.exe ae471b5e22d6e151e7d4519e0075d4da.ex_ Troj-y3kRat-1.6.exe diag2.dll lgn1216a.dll Net-Worm.Win32.Dabber.a.exe e4796f5f399bfe9a4614a9395a37dc83.ex_ 90ad28a731325f87702c881930b488ce.ex_ W32-Netsky-B.exe W32-MyDoom-A.exe W32-Mimail-M.exe W32-Dumaru-A.exe W32-Bugbear-B.exe Net-Worm.Win32.Raleka.h.exe Net-Worm.Win32.Opasoft.p.exe Net-Worm.Win32.Mofeir.a.exe Net-Worm.Win32.Doomjuice.b.exe Net-Worm.Win32.Dedler.c.exe abms.exe 9b4ebf50e477e3af917c4d7839eedf60.ex_ 864f0293624bd22d678e7b14d090071e.ex_ 44aa2edbaa5c921f37b84c831b3d90c3.ex_ w32-Yaha-E.exe w32-Sobig-C.exe W32-Sobig-B.exe w32-Sober-C.exe W32-Sober-A.exe W32-Bugbear-A.exe W32-Badtrans-B.exe w32-badtrans-A.exe Net-Worm.Win32.Welchia.l.exe Net-Worm.Win32.Welchia.h.exe Net-Worm.Win32.Welchia.g.exe Net-Worm.Win32.Welchia.e.exe Net-Worm.Win32.Welchia.a.exe Net-Worm.Win32.Opasoft.a.pac.exe a2924b440271b1702bf0eb43a0f07a85.ex_ ffd01bd440127cf67c5aa381d642d537.ex_ ed79016770dc82addc58391004f6b9d7.ex_ 9fa9ca94275a0f27d69575d881ad6ca9.ex_ 863bb61eb8e1ed385fb88a604613708c.ex_ 853ee21ff50fe83c98af15575875114c.ex_ 7f9ff479c0948a21154f173adc3ebb64.ex_ 73971e717b8b8cfc1caf77a7bef3b98d.ex_ 257fd9cfb6fbc189e797aaeabc59903f.ex_ 1e230c628a3760e18f9a09f95b11a44a.ex_ Net-Worm.Win32.Vesser.b.exe Net-Worm.Win32.Vesser.a.exe w32-Sobig-E.exe w32-Sobig-F.exe Score 5.07 0 8.11 6.1 3.06 3.26 8.11 8.11 6.49 6.49 6.49 6.49 6.49 6.49 6.49 6.49 6.49 6.49 6.49 6.49 6.49 6.49 3.26 3.26 3.26 3.26 3.26 3.26 3.26 3.26 3.26 3.26 3.26 3.26 3.26 3.26 5.07 3.45 3.45 3.45 3.45 3.45 3.45 3.45 3.45 3.45 1.99 1.99 6.78 1.99 Packerinfo WWPack32v1.x Wise installer stub UPXv0.89.6 UPXv0.89.6 UPXv0.89.6 UPX-ScramblerRCV1.x UPX2.9 UPX2.9 UPX2.9 UPX2.9 UPX2.9 UPX2.9 UPX2.9 UPX2.9 UPX2.9 UPX2.9 UPX2.9 UPX2.9 UPX2.9 UPX2.9 UPX2.9 UPX2.9 UPX2.9 UPX2.9 UPX2.9 UPX2.9 UPX2.9 UPX2.9 UPX2.9 UPX2.9 UPX2.9 UPX2.9 UPX2.9 UPX2.9 UPX2.9 UPX2.9 UpackV0.3X UpackV0.3X UpackV0.3X UpackV0.3X UpackV0.3X UpackV0.3X UpackV0.3X UpackV0.3X UpackV0.3X UpackV0.3X tElockv0.90 tElockv0.90 tElock0.99 tElock0.99

297

Net-Worm.Win32.Opasoft.l.exe Net-Worm.Win32.Nimda.b.exe 84f933cf77cfd95cb9a0cad17b1efe97.ex_ fd0c6ccead2af284d30dfdf7ba77a697.ex_ Net-Worm.Win32.Opasoft.e.exe 7d5a632eed2d99abda06ff11d5b00c67.ex_ 0305cf9d0258ea652f658d0438afadae.ex_ w32-Sircam-A.exe Net-Worm.Win32.Randon.t.exe Net-Worm.Win32.Randon.exe joke-Cokegift.exe greeno.exe fb3ca93927af944f816d7fcd7b965076.ex_ 0080b8d81cc0849df2c50a2c78b5069b.ex_ 7d5a632eed2d99abda06ff11d5b00c67 0305cf9d0258ea652f658d0438afadae fb3ca93927af944f816d7fcd7b965076 lierenwow.exe 96d5d80fc28a385b35032b8017c536ec 4ba220bcf9e6d8025dd0eb3efe118748.ex_ w32-parite-B.exe Uswow.exe NEWS_DOC.DOC.29532DEFANGED-scr gezi.exe efc8d9e780845519b3105bed1216db24.ex_ agobot_f.exe 0080b8d81cc0849df2c50a2c78b5069b svvhostc.exe svvhost.exe Net-Worm.Win32.SdBoter.a.exe Net-Worm.Win32.Sasser.c.exe Net-Worm.Win32.Sasser.a.exe g4.exe g1.exe w32-Apology-B.exe 7b0f05d171f72d0ac94b44adf444ffe0.ex_ efc8d9e780845519b3105bed1216db24 w32-hybris-C.exe w32-hybris-B.exe Net-Worm.Win32.Dedler.exe 953d455356278ad59a2ff35e54187dc0.ex_ 7ab45c880707eeff5624071c3af364ff.ex_ 7a1b1118e050ad2ce8c9a1fc4c92eda4.ex_ 55ee45c90292fd60d7ea630be3b5de86.ex_ 03816f44ed2a7f2997677a7acfee4a85 Net-Worm.Win32.IISWorm.exe mm77lgn.sys do_not_run.exe d2fcbbf0fea810301e28689ecacbf68c.ex_ 9b435eb137f35d5dc87acc7315f95d81.ex_ 975430f50448f6b74a6845b058d21445.ex_ 8e4a239e757ece58ad8f68bd3d24c32f.ex_ 5b11f7e3cb24f9c3250ebbf182b3708a.ex_ 3f70c96015ee8daf85f3a6cef122ff7a.ex_ 177bddb7703118127849d162635bb329.ex_ 03816f44ed2a7f2997677a7acfee4a85.ex_ 41bc19900eef8f0a3f9010732ebfc3cb.ex_ WC9921564.exe w32-Magistr-B.exe w32-Magistr-A.exe Net-Worm.Win32.Opasoft.j.exe Net-Worm.Win32.Opasoft.d.exe Net-Worm.Win32.Opasoft.c.exe Net-Worm.Win32.Opasoft.b.exe Net-Worm.Win32.Opasoft.a.exe fc286e203ae0da8775f53b789fb04de4.ex_ fc286e203ae0da8775f53b789fb04de4 ee8c8ee8f749b7927fe69ad23f563669 order_37679041.exe

0.6 2.28 5.07 5.07 6.49 5.07 5.07 4.87 4.87 4.87 4.87 4.87 4.87 4.87 4.55 4.55 4.4 3.45 3.45 3.45 3.26 3.26 3.26 3.26 3.26 3.26 3.11 2.28 2.28 2.28 2.28 2.28 2.28 2.28 1.99 1.99 1.82 1.7 1.7 1.7 0.55 0.55 0.55 0.55 0.53 0.32 0.32 0.32 0.32 0.32 0.32 0.32 0.32 0.32 0.32 0.32 0.29 0.03 0.03 0.03 0.03 0.03 0.03 0.03 0.03 0.03 0.02 0.02 0

PECompactv1.4x+ PCShrinkv0.40b NsPacKV3.7 NsPacKV3.4-V3.5 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A

298

Net-Worm.Win32.Zan.exe Net-Worm.Win32.CodeGreen.a.exe 6ed6d26c48cfe55762e058c2dfedab7d.ex_ 816225e7475292a457344fbb72c32c6d.ex_ Net-Worm.Win32.Sasser.b.exe Net-Worm.Win32.Nimda.exe w32-Klez-H.exe troj-hooker-h.exe Troj-Webber-C.exe b3546097ac8962b2ebc419709257ecff ab9e2d852c897f0cf8abe82430759597.ex_ a.exe Net-Worm.Win32.Muma.c.exe Net-Worm.Win32.Mofeir.b.exe e1bd83dd41f03ce253403264ef50b507.ex_ Net-Worm.Win32.Opasoft.q.exe down.exe 4b8559b9f535868d8a87c6efabf75d32.ex_ 150247621b3d11e5eb39181725381ec9.ex_ software.exe b4e63101f8767d0de6a906a3e9091700.ex_ 58bec89de93006001ff05b467b7b0158.ex_ Net-Worm.Win32.Opasoft.o.exe Net-Worm.Win32.Opasoft.i.exe Net-Worm.Win32.Opasoft.h.exe

0 0 0 0.29 3.45 3.24 0 0 0.32 1.97 0 0 0.32 3.24 0 3.26 4.87 8.11 8.11 6.49 6.49 6.49 3.26 3.26 3.26

N/A N/A N/A MicrosoftVisualC++ MicrosoftVC5.0/6.0 MicrosoftVC5.0/6.0 MicrosoftVC++6.0 MicrosoftVC++5.0 MicrosoftVC++3.0 MicrosoftVC++, Armadillov1.71 MicrosoftVC++, Armadillov1.71 MicrosoftVC++, Armadillov1.71 MicrosoftVC++ MicorsoftVC++ MicorsoftVC++ CodeCryptv0.16b ASProtectv1.2x ASPackv2.12 ASPackv2.12 ASPackv2.12 ASPackv2.12 ASPackv2.12 ASPackv2.11 ASPackv2.11 ASPackv2.11

299