skip to content
Pocket Change

Malware Analysis: UnPacking Malware

/ 4 min read

malwareanalysis

Unpacking Malware

Lately, I’ve been analyzing malware, and the first step in the process, especially with sophisticated malware, is unpacking. But what is unpacking?

Modern malware is usually packed, meaning it is transformed in a way that hides its true signatures, adds layers of protection, and compresses its contents. Packing is essentially a method used by malware authors to conceal the malicious payload. This obfuscation can serve multiple purposes, such as:

  • Evading detection by antivirus software by disguising its behavior.
  • Making the analysis process more challenging, thereby hiding its true intent.

Malware authors might use customized packers or well-known ones like UPX to achieve this level of concealment.

“Is It Packed?”

The first question when analyzing malware is often: Is it packed? Determining this isn’t easy, but there are several ways to find out. Let’s take a look at a real example to better understand.

The sample we’re analyzing is from the IceID banking malware family, with the following SHA-256 hash: 76CD290B236B11BD18D81E75E41682208E4C0A5701CE7834A9E289EA9E06EB7E.

image
  • Entropy Value:
    • Entropy is a measure of the randomness of data in a file. A higher entropy value suggests that the file might be packed, as packed malware typically has encrypted or obfuscated data.
image
  • Comparing Virtual Size vs. Raw Size:
    • The virtual size (242,023 bytes) is significantly larger than the raw size (144,896 bytes). However, this is not necessarily an indicator that the executable is packed.
image
  • Import Analysis:

    • Certain imported functions can indicate that malware is packed. Examples include VirtualProtectEx, HeapAlloc, and HeapFree, which are often used to allocate and modify memory.

    • The function IsDebuggerPresent is particularly interesting, as it is commonly used by malware to detect whether it is being run in a debugger or sandbox environment.

image
  • String Analysis:
    • The strings found in the malware appear somewhat random, which might indicate the presence of obfuscation or encryption, further suggesting that the malware is packed.

“Unpacking Malware”

  • After examining some of the malware properties through Pestudio, we determined that it is most likely packed.

  • Using x64dbg, we can begin the unpacking process by setting breakpoints at the following points:

    • VirtualAlloc:

      • This Windows API function is used to allocate memory in a process’s address space. Malware often uses VirtualAlloc to allocate memory to unpack or decrypt itself before executing the payload. Setting a breakpoint here allows us to observe the unpacking process.

    • VirtualProtect:

      • This API function is used to change the protection on a committed memory region. By setting a breakpoint here, we can track any changes in memory sections, such as changing from read-only to read-write-execute. Such behavior is often an indicator that the malware is unpacking or modifying its own code.

    • IsDebuggerPresent:

      • This function is used to check if the current process is being debugged. Setting a breakpoint here helps us identify anti-debugging techniques employed by the malware. If it detects a debugger, the malware may try to alter its behavior to avoid analysis.
image
  • Observing the Breakpoint (bp) tab, we can see the API breakpoints that have been set.

x64dbg Breakpoints Walkthrough

image
  • Run the malware using Run (F9), which hits the first breakpoint at VirtualAlloc.
image
  • Right-click on EAX and select “Follow in Dump” -> “Dump 1” to inspect the memory allocated by VirtualAlloc.
image
  • Run (F9) again to hit the second VirtualAlloc breakpoint. Dump 1 now contains some unknown code. The second and third hits on VirtualAlloc reveal similar results, which are then added to Dump 2 and Dump 3—still, no executable code is found yet
image
  • After the third hit, VirtualProtect is triggered. In Dump 3, we can see a compressed executable that was added during the third VirtualAlloc. The malware is attempting to map it to memory, but we still need to locate the decompressed executable.
image
  • Follow the return from VirtualProtect and step over it to try and locate the uncompressed executable. Look for a pointer to a memory offset that may contain the decompressed version.
image
  • By following address 7014C2 in the dump, we eventually find an executable, which is likely the decompressed malware.
image
  • Select the entire executable in the memory dump, from start to end, and then right-click -> Binary -> Save to a file. This allows us to extract the unpacked executable.
image
  • Use PE-Bear to check if the saved file is mapped correctly and follows the standard PE file format. If everything appears in order, it means we have successfully unpacked the malware.