Joe Security's Blog
Generic Unpacking Detection
Published on: 27.11.2018
Malware authors use a wide range of techniques to avoid detection by security tools. One of the most used techniques is packing. This powerful procedure allows attackers to bypass static signature detection, an important defense line of Antivirus products.
Unpacking is the process of restoring the original malware code and is considered a hot topic for academic research due to its complexity.
Joe Sandbox includes a generic unpacking engine since 2014. While unpacking is one problem, generic unpacking detection is another.
In this blog post, we are going to outline how packing works and how the recently added unpacking detection of Joe Sandbox works.
The Art of Packing and Unpacking
It is hard to describe packing in words, therefore please have a look at the visualization below:
Packing is usually applied to executable files such as the Windows Portable Executable (PE) or the Linux Executable and Linkable Format (ELF). The tool which performs the packing process is called "Packer".
The starting point is a PE file. The workflow of packing, unpacking and execution is as follows:
1) Original File
If you look at your PE file it contains a header, a code section (.text) and some additional sections (.data, .rsrc etc). Very important, all the code is available for static analysis. It is relatively simple to find unique code patterns in the code segment to detect the file as malicious.
2) Packing Process
The packing process will generate a totally new PE file and will contain a new header. Next, the original file will be transformed. The transformation is often a compression algorithm, a cryptographic operation (XOR) or a mix of both. Often a random key is used for the transformation. As a result, each packed sample is unique. The transformed original file is copied to the new file. Finally, a small Stub code is added to the new PE file. Its goal is to reverse the transformation during execution. Since the original file is compressed and encrypted, static analysis and detection is hard.
3) Loading the Packed File Phase 1
When the packed file is started it is mapped to virtual memory. Next, the unpacking stub is called to reverse the compression and/or cryptographic operation. As a result, the original file is "restored" in memory. There are two possibilities where the file is restored. Either the complete packed PE file is replaced with the original, or it is restored on a different memory address.
4) Loading the Packed File Phase 2
As soon as the original file is "restored", the stub will transfer execution to the "restored" file. The restored file will then execute as normal.
Packers
Packers are available in a large variety. You can buy them in the DarkNet or also from legit software vendors. Below you can see a nice map from Ange Albertini which shows some of the most famous packers:
Generic Unpacking Detection
Since most malware is packed, it not only makes sense to do generic unpacking but also to detect the unpacking process itself. This generic unpacking detection has been recently added to Joe Sandbox. In order to demonstrate its power, we will look at two different samples.
PE Header Overwriting
The first sample is called XgkKQZc74T.exe. During execution, the image is mapped to address 0x400000:
Joe Sandbox's unpacking engine generates several "restored" files:
The first file with the name 1.0.XgkKQZc74T.exe.400000.0.unpack was captured before any code has been executed. The second file which starts with the name 1.2.XgkKQZc74T.exe.400000.0.unpack was stored when the analysis finished. Please note that both files have been restored from the same address 0x400000.
Let us have a look at the import address table for each restored file. The import address table shows what functions are imported by the PE file. The first file (1.0.XgkKQZc74T.exe.400000.0.unpack) has many imports:
In contrast, the second file has fewer imports and most of them are not in the previous files. For instance, the sample can connect via HTTP to the Internet. The previous sample does not have an import for such a function:
This change of the PE file header proves that the sample is packed. The PE header at address 0x400000 has been overwritten with the unpacked file. As a result, the import address table changed and we see above the table from the unpacked/malicious file. With a new behavior signature Joe Sandbox detects this anomaly:
If we look at the unpacked file we can also find the command and control IP / domain:
Dynamic Code Loading
The second sample is named WBKDqSfWLj.exe. It is loaded at address 0xdb0000:
If we browse some of the behavior we detect that some calls originate from 0xdb0000:
However, there are also calls coming from 0x400000:
Could this be an unpacked file? If we browse to the memory activities we indeed see that there is some allocation of memory at the address 0x400000:
As for the previous sample, we can compare the import address table of the corresponding unpacked files. This times the base address of the images is different:
For file 1.0.WBKDqSfWLj.exe.db0000.0.unpack the import address table is:
And for file 1.2.WBKDqSfWLj.exe.400000.1.unpack the import address table is:
Again, we see different tables which outlines that a new PE file has been loaded. This time the PE header of the original file is not overwritten. Rather, the original file is unpacked/decompressed to a new memory section which was allocated by the stub. Of course, there is also a behavior signature in Joe Sandbox to detect this:
Final Words
Packing is widely used by many malware samples to bypass static signature detection. Joe Sandbox includes an unpacking engine which will restore the original file. The restored files can be downloaded by analysts:
While unpacking itself is helpful, unpacking detection is even more important. With the upgrade, Joe Sandbox detects unpacking via PE header overwriting and dynamic code loading:
Want to try Joe Sandbox? Register for Free at Joe Sandbox Cloud Basic or contact us for an in-depth technical demo!