Edited by Alon Slotky

Dyre had become one of the most dangerous financial Trojans, targeting login credentials for banks accounts and other online services via Man-in-the-Browser exploits.
In this post we will look into the mechanism of Dyre unpacking its own code.

Dyre executes an obfuscated shellcode from its own .text section. In the flow of unpacking, it changes its protection in quite a sophisticated way, including symbol resolving and some more interesting obfuscation techniques.

First, a simple XOR with a 5 bytes key reveals the strings VirtualProtect and VirtualAlloc in the .data section.

Bytes from .data section after deobfuscation:

Second, Dyre implements a mechanism similar to GetProcAddress.

It finds the MZ magic in the PE header of kernel32.dll. It starts from the address of GetStartInfoA (which is in its own PE Imports functions table) and decreases a fixed offset until it’s found. It’s worth noting that in order to obscure the comparison with this indicative string, Dyre makes manipulations on the MZ hex value before comparing.

Once the header of kernel32.dll was found, the unpacker finds the exported functions names list. Then it looks for VirtualProtect in this list – first by comparing the strings lengths, then by using its own implementation of strcmp.

Third, Dyre changes the protection of a very small part in its .text section (124 bytes) using VirtualProtect to allow memory write. Now it can deobfuscate it, uncovering the first stage shellcode and executing it.

The shellcode searches for the address of VirtualAlloc in the same way that VirtualProtect was found, using the same code. It allocates executable memory via VirtualAlloc and calls it.

The second shellcode contains more strings as can be seen below:

In this stage the addresses of LoadLibraryA and GetProcAddress are retrieved in the same way described earlier. From now on, any other symbols required by Dyre are retrieved using these two functions (including VirtualProtect & VirtualAlloc).

The first stages of the Dyre unpacker went through a lot of trouble in order to hide the usage of VirtualProtect and other suspicious APIs. The fact that Dyre eventually uses these same functions openly (using the standard GetProcAddress) proves that it is more concerned with evading static analysis than any kind of dynamic/behavioral analysis.

In the next part we’ll describe the injection of the unpacked code into a new process.

References
1. http://blogs.cisco.com/security/talos/threat-spotlight- dyre

SHA256
7e54dceecd3d3a23a896e971ae4bb9e71a64a5c1c3b77ac1c64241c55c1b95bb