Packer-based malware is malware which is modified in the runtime memory using different and sophisticated compression techniques. Such malware is hard to detect by known malware scanners and anti-virus solutions. In addition, it is a cheap way for hackers to recreate new signatures for the same malware on the fly simply by changing the encryption/packing method. Packers themselves are not malware; attackers use this tactic to obfuscate the code’s real intention.
For security solutions to be effective, they will need to augment their solutions with in-memory capabilities in order to monitor/hook the behavior of the malware after unpacking is completed.
This document describes a sophisticated Andromeda/Gamarue Custom Packer. Andromeda first appeared in 2011 and still remains popular. Since the Andromeda attack chain has been described previously, this analysis instead focuses on the packer and deobfuscation, which happens before the malware downloads or executes its next stage malicious payload. The recent version of the custom packer we obtained (originating June 2016), has noteworthy and innovative functionality.
Does Morphisec stop this attack? Of course, even these new tricks can’t get past Morphisec, which prevents this attack before it can drop its load.
Nowadays most malware employs anti-analysis techniques to make their code harder to analyze by security researchers. Just like legitimate software developers protect their proprietary work, hackers use obfuscation techniques to protect their code from being reverse-engineered or debugged.
The malware sample in our analysis is packed by a custom packer. To be able to get to the actual code, we first need to unpack it.
In forensic analysis, there are different ways to handle the unpacking process. While there are automatic tools for different popular packers, it is more difficult to handle custom packers, which require some manual work and a deeper knowledge of the different anti-debugging obstacles. Moreover, custom packers usually also involve stripping off multiple packing layers.
Looking at Andromeda’s top-layer packer, we start by noticing an interesting, relatively high entropy in one of the sections (e.g. entropy of .rsrc is 7.376) which gives us the first indication that it is a packer.
Determining a point in time for which we know the malicious code was already unpacked, we identify the use of ws2_32.dll (responsible for communication API). This means we can assume that the malicious code will start communication after it is unpacked. This is of high probability for downloaders or C&C based malware.
As shown in the image below, there are two unnamed modules with RWE (read write execute) access rights – those are indicators for the unpacked executable shellcode (the code will write and execute from the same location).
Additionally, we can see now strings which are typical to Andromeda.
It is noticeable that those modules are still not a PE file (do not start with PE header) – those are executable shellcodes.
We also notice that the code starting from the entry point of the executable was modified, which reminds us of Process Hollowing/ RunPE techniques.
RunPE techniques are designed to evade AV mitigation methods.
Here are RunPE characteristics, as described in an Andromeda Bot Analysis by Infosec Institute:
Also in our case, the packer decrypts the executable memory space and replaces previously encrypted memory with the functional code. The packer also updates the entry point to the new functional code start.
Forensic analysts will usually stop at this stage and dump the first layer decrypted code for further static analysis using different tools like IDA.
Based on the resemblance to RunPE methodology, we will execute the malware again, although now we set a breakpoint on VirtualAlloc functions (used to allocate memory). Other similar functions are VirtualAlloc, VirtualAllocEx, or ZwAllocateVirtualMemory – also part of the Process Hollowing/RunPE method) called to reserve some RWX memory.
We get the VirtualAlloc function from PEB->Kernel32.EAT
After identifying the RWE buffer address, we set a memory breakpoint on write to this buffer -> the written code is actually the unpacker/decode function.
After the unpacking function finishes execution, its execution is redirected to the first shellcode:
EAX address shellcode start = 0x003D0000
From inside the shellcode, VirtualAlloc is called again. We set a memory breakpoint on write to the new buffer one more time, get a new PE and are redirected to a second shellcode, the unpacked PE.
From this stage on, we get the regular Andromeda Loader which is described in detail by the Avast Threat Intelligence Team.
This article describes a single custom packer for Andromeda, one of the most popular malware delivery frameworks. Packers are a major concern for current security solutions. Packers allow attackers to penetrate network solutions, file scanning solutions and, in many cases, behavior or AI based solutions.
The use of custom packers will only increase, as will the need for in-memory solutions that can block these types of attacks.
A number of popular sandbox dynamic scanning services have some basic in-memory defenses, however these impose severe performance penalties. Moreover, they frequently are not even effective as many packers, such as in our case, include techniques to identify sandbox environments. Morphisec’s Moving Target Defense based technology wins the malware packer battle without monitoring, hooking or using any other methods that affect endpoint performance.
Hash: 7b45c0141cca16fc14d4c81c653d4f22eb282cbbc4f913c9e830acf6e9d12b86