Sometimes, malware is just hiding. Analyze the issue of packed malware, including tools, tricks and popular packers.
Introduction
Malware is created with deception in mind. Malware authors want to go undetected in order to steal, alter or delete as much information as possible. Obfuscating malware is a way to keep the files associated with the malware from detection and easy analysis. Packing is a type of obfuscation technique.
Obfuscation
Obfuscation takes code and basically makes it unreadable without destroying its intended functionality. This technique is used to delay detection and/or to make reverse engineering difficult. Obfuscation does have legitimate purpose. It can be used to protect intellectual property or other sensitive code.
An obfuscator is the tool used to make code unreadable. These tools make obfuscation easier to implement, but obfuscation can be also be performed manually.
Slicing is a technique used to help in analyzing obfuscated code. It takes smaller portions of the code which simplifies the analysis.
Packing
Packing is a subset of obfuscation. A packer is a tool that modifies the formatting of code by compressing or encrypting the data. Though often used to delay the detection of malicious code, there is still legitimate use for packing. Some legitimate use includes protecting intellectual property or other sensitive data from being copied.
Stub – a small portion of code that contains the decryption or decompression agent used to decrypt the packed file
The packing process consists of:
- The original code is uploaded into the packer tool and goes through the packer process to compress or encrypt the data
- The Original PE Header and original code are compressed or encrypted and stored in the packed section of the new executable
- The Packed file consists of:
- New PE Header
- Packed Section(s)
- Decompression Stub – used to unpack the code
- During the packing process the original entry point is relocated/obfuscated in the packed section. This is important for anyone trying to analyze the code. This process makes identifying the import address table (IAT) and original entry point difficult.
- The decompression stub is used to unpack the code upon delivery.
Some malware creators use custom packers, but commercial/opensource packers are also used. Some popular packers include:
- UPX
- Themida
- The Enigma Protector
- VMProtect
- Obsidium
- MPRESS
- Exe Packer 2.300
- ExeStealth
Analysis
It is possible to automate the evaluation of packed code. The packing tool embeds the stub into the executable during the packing process. So, if you can determine the tool used to pack the code, you may be able to use the same tool to extract the original file.
The best (and quickest) way to unpack packed malware is to use a tool. Exeinfo PE is one tool that will analyze the code to determine if it has been packed. It can often identify the packer used as well. UPX is one commonly packer tool that includes the unpacking feature. If the malware was packed using UPX it is possible to use the command line within the tool to unpack the malware code and further analyze it with a reverse engineering tool. A command line example is given below based on a file named packed.exe:
upx -d -o unpacked.exe packed.exe
Running that command will unpack the packed.exe file and create a new file named unpacked.exe. You can then place the unpacked malware file into a debugger like Ollydbg to perform further analysis.
There are manual ways to analyze the malware. The manual way to begin the malware analysis process is often to run the strings command to analyze the strings associated with the malware. However, in packed code there are no identifiable strings.
Also, as stated earlier the original entry point is concealed in the packed file. Knowing the original entry point is important to any analyst trying to analyze the code. It is how they will be able to recover the original code. The IAT is used by running programs to reference the functions it needs to use in order to run properly. In packed files, the IAT information is obfuscated which makes disassembly difficult. This is another challenge to malware analysts.
Ollydbg can be used to unpack malware. While in Ollydbg you can manually evaluate the code. If you know assembly, you can scan through the code to look for valid assembly commands versus items that do not appear to resemble assembly.
The order in which the code will be analyzed is:
OllydbgOllyScriptOllyDump or
Ollydbgbp in LibraryOllyDump
You can upload the code into Ollydbg. Upon upload Ollydbg will ask if you want to analyze the code. Do not analyze the code. Packed malware does not show the import information. You can press Ctrl -n to see information.
Press F9 to run the program.
You want to look for tail jump (jumping to a place far away from memory). Compliers don’t normally jump far so a tail jump could be a sign of the packing stub. The end of an unpacking stub could jump to place n memory far away which could be where the unpacked memory resides.
One way to identify a jump is that is could be followed by non-valid assembly language. For example, a bunch of scramble code or repeated numbers proceeded by a JMP <#######> identifier, with a JNE short close above it.
For example it would look something like this:
Hit F2 to create breakpoint then F9 to execute the malware then F8 to take the jump. This should be the unpacked area. You could then use OllyDumEX to reset a new entry point. It will dump this new data. You can then use a tool like Scylla to examine the dumped file. In Scylla, or similar tool, update the Original Entry Point (OEP) – based on the jump point in memory you identified earlier.
This will create a new file that you can upload into Ollydbg again. If successful you will see all of the available API calls and the full IAT. With this file you can proceed to further evaluate the now unpacked malware.
Conclusion
Analyzing Packed malware takes skill as well as the proper tools. The purpose of packed malware is to avoid detection and reverse engineering. There are multiple packing tools available, but many malware authors use custom made tools. Tools such as Exeinfo PE can examine packed code and determine what tool was used to pack the file. Knowing this means an analyst could use that same tool to possibly unpack the code. Debuggers can also be used to manually analyze the malware. Manual analysis takes more time and a higher skill set. Malware is becoming more and more sophisticated, so security professionals need to stay savvy in order to continue fighting these vulnerabilities.
References
https://www.techopedia.com/definition/16375/obfuscation
https://securingtomorrow.mcafee.com/business/malware-packers-use-tricks-avoid-analysis-detection/