Unpacking Malware
Packers & Unpacking
Packers in the context of malware reverse engineering is a piece of software used by threat actors to protect their malicious code through obfuscation, compression, virtualisation and other techniques.
The packed malware is usually encapsulated within a self-extracting archive or executable file, which contains both the packed code and a unpacking routine.
When the packed malware is executed on a victim's computer, the unpacking routine unpacks the original malicious code and then executes it. This technique helps malware authors evade detection and hinder reverse engineering efforts. By compressing or encrypting the malware, packers can change the binary structure of the file, making it harder to identify and analyze using traditional signature-based detection methods.
Types of Packers
Most commonly there are three types of packers:
Free - Created for research or hobby
Malware - Written by threat actors to obfuscate their malware
Commercial - Created to protect legitimate software from being cracked
Detecting Packed Malware
When trying to ascertain whether a piece of malware is packed or not there are certain indicators that can help with the analysis. The main idicators are -
Signatures
Using tools like PEID and YaraScan it's possible to identify packers based on detection rules. These rules could be looking out for common byte patterns or values that are consistent from the packer.
Strings
A lack of strings or abundance of strings that don't make sense could be an indicator that the binary is being encrypted.
Imports
Like strings, a lack of or abundance of unknown imports could identify that a peice of malware is packed.
Section Names
Packers such as UPX Packer commonly add extra sections to the binary. If a binary has extra sections named after the packer or with random names, this could be an indicator that the binary is packed.
Entropy
Entropy refers to a measure of the randomness or complexity present in the packed malware binary. A packed binary can exhibit higher entropy to an unpacked binary. The packing process introduces additional complexity and randomness to the binary code. Higher entropy indicates that the packed malware has a more diverse distribution of byte patterns and lacks easily recognizable structures.
Raw & Virtual Size
The Raw Size identifies the size of the sections when the binary is on disk, while the Virutal Size highlights the size of the sections when being executed in memory. A noticable difference between these two sized could highlight that binary has been packed.
Packing Workflow
In this diagram:
The process starts with the original malware, which represents the malicious code or payload to be packed.
The packer then packs the executable via compression and encryption to make the malware smaller and prevent direct analysis and detection of the malware's content.
A packing algoritihm is then implemented that to encapsulate the compressed and encrypted malware into a self-extracting archive or executable file. This algorithm also includes an Unpacking Stub used by the malware to unpack and execute the original malware when triggered.
The packed malware is then ready for distribution or execution. It can be distributed through various means, such as email attachments, malicious websites, or compromised software. Alternatively, it can be executed directly on a victim's system.
Unpacking Workflow
In this diagram:
The process starts with the packed malware, which represents the compressed and/or encrypted malicious software.
The unpacking algorithm is used to reverse the packing process and extract the original malware from the packed binary. The unpacking algorithm typically includes a decompression routine and decryption if encryption was applied during the packing phase.
The result is the unpacked malware, where the original code and resources of the malicious software are restored.
Analysis and understanding of the unpacked malware can take place at this stage. This involves various techniques such as reverse engineering, behavior analysis, code analysis, and dynamic analysis to examine the functionality, purpose, and potential threats posed by the malware.
Unpacking Malware Practical
In this practical assessment we'll unpack the Dridex malware to showcase an example of the unpacking process.
Static Analysis
First step is to do some static analysis of the binary in pestudio. The entropy value is defined as 7.536 which is a good indicator that this piece of malware is being packed.
We can also see within the sections paramter that there is more than one .text section. The section labelled .text1 has a high entropy of 7.598, another indicator that this malware is packed.
Dynamic Analysis
In order to unpack the malware we'll need to use a debugger. Using x32dbg we can assess the dridex and unpack the obfuscation until we find the original malware that will be executed in memory.
First step in debugging a piece of malware is setting some breakpoints on common Windows APIs that are used in unpacking malware such as VirtualProtect(Ex), VirtualAlloc(Ex), WriteProcessMemory, CreateProcessW, and many others.
Once the breakpoints have been set we can traverse the malware by stepping over (F8) the execution process or running (F9) the program until we hit another breakpoint.
Doing this the first time reveals that VirtualAlloc is hit 3 times, and VirtualProtect is hit 6 times before the original malware is upacked in memory.
With this info we now know that through dumping memory that the dridex original malware is being allocated within the 0x10000000 region.
Using a tool called ProcessHacker it's possible to dump the memory of the dridex executable from where the unpacked code is being self-injected into it's own process.
When dumping a binary from memory it can lead to corruption of section headers and alignment, misconfigured base addresses, and incorrect imports and exports information. Analysing the binary within pebear reveals our dridex dump has some of these errors so the binary needs to be realinged so it can be analysed properly.
Unmapping the sections correctly should solve the sections and imports issue. We can do this by aligning the Raw Addr. values with the Virtual Addr. values in each section name. Then calculating the Raw size by subtracting the sections.
The last thing we need to do is change the base address of the dumped binary from 0x400000 to 0x10000000 which is the point in memory that the binary is actually unpacked and executed from.
Compartng the Exports tab shows that we now have a value in the Name parameter for the loader of dridex called ldr.exe.
Now that dridex has been unpacked it can be further analysed in a dissassembler like IDA or Ghidra.
Conclusion
This is the process of unpacking a malware sample. By no means is my explantion an extensive or comprehensive analysis. However, the process of these posts are to solidfy the knowledge I'm learning. Hope you gained some insights if you're to this process like myself :)
References
Last updated
