Rather than saying that Morphex is the name of the malware family, we prefer to think of Morphex as the name of a packer, which is usually used for packing malware and is used only very occasionally for legitimate software.
The Morphex packer has the following characteristics: execution flow interference, encryption and injection. The first and the last characteristics makes it more suspicious than common packers, and it’s also the reason for giving a specific detection name for it. As a lot of Morphex samples have appeared in China recently, we have decided to have a deep look at this malware.
Part 1: Execution flow interference
Last year in the “Floating-point math functions abused” blog post, I described the trick of disturbing the program’s execution flow. This version of Morphex is exactly the same story as using the math error to trigger error handle set by the function “__setusermatherr” to change the execution flow, instead of using math operation “log”. In this version, “sin” and “cos” functions are mostly used. Importing math operation should be a suspicious point when analyzing files from now on. The math error handle is used for code decryption: xor with a random dword.
After decryption, we can find the following string “my name is morphex” in the memory. That’s the reason why we named this packer / malware Morphex.
Part 2: Validation and decode routine
Morphex uses time and date stamp for validation and these are hardcoded into the program. At the beginning of the decode routine, Morphex defines following variables:
[ebp-20h] is the time date stamp. Morphex uses link list PEB_LDR_DATA to get the base addresses of all loaded modules, and then checks if they have any time and date stamps and if so, whether it is the same as the one pre-defined or not. If not, the loop will never end.
We also have to pay attention to the variable [ebp-1ch], as this flag controls the whole execute flow. Different versions of Morphex must have different flags.
The decode routine consists of four steps. They can be simply described by the following diagram: Step one is simple copying and combination, Memory_1 and Memory_2 are in the original pack space. The offset and length of code are specified in the variables pre-defined:[ebp-4],[ebp-8],[ebp-0ch],[ebp-10h].
Step 2 and 3 are decryption routines using bitwise operation together with a defined byte array, no special arithmetic is used. In fact, memory 4 is decrypted once again with a 100 byte memory block. There are 3 decryptions in total for Morphex. Step 4 will reload the unpacked image to the original memory, in this case it’s 0?400000. In order to make the unpacked file executable, Morphex also does a lot of necessary modifications, such as rebuilding the link list of LDR module and fixing the PE image:
After the unpacking is done, Morphex suspends current thread, and then sets the EIP of the context thread to the new entry point to run the payload.
Part 3: Code Injection
It’s not clear, whether the injection part is included as intended behavior in the packer, or if it’s just the part of the payload of the unpacked file. However, we have already seen many Morphex samples and all of them have injection behavior. Also this kind of injection is very similar to the DLL component of Duqu. It creates a process using a normal system file, and then injects a code to that memory and covers the target process’s entry point.
Instead of using function ZwMapViewOfSection to write the code in to the target process, Morphex uses a much more common way: WriteProcessMemory.
The malicious Morphex packages are detected by the latest version of AVG as variants of Luhe.Morphex Trojan family.
Frank Zheng
Leave a reply
