First of all you can immediately notice that this sample is a simple loader: you can have a look at the IDA navigation bar to spot a tiny code section in contrast to a huge resource section.
This tells us that something is hidden somewhere in the resources. The payloads, in fact, are encrypted and stored in the dialog type resources. Here's a quick verification test, that shows that something is wrong in the dialog data:
But let's go back to the curious trick we mentioned, and let's begin by analyzing the code. If we start looking from the entry point we notice... absolutely nothing!
At a first glance nothing suggests that we are analyzing a malware, as we only go through some common APIs.
Of course, a deeper reading reveals the trick: in the middle of some legitimate calls we find a suspicious function. The thing that more captured my attention is that it makes use of the VirtualProtect API different times, apparently without any good reason, as we will see later.
For now let's start from the beginning:
.text:004011F5 push 0 ; lpModuleName
.text:004011F7 call ds:GetModuleHandleW
.text:004011FD mov ebp, eax ; MZ header
.text:004011FF mov eax, [ebp+3Ch] ; MZ.elfanew = PE offset
.text:00401202 mov esi, [eax+ebp+80h] ; import table RVA
.text:00401209 mov eax, [esi+ebp+0Ch] ; import name RVA
This code gets the handle of the application itself and then it reads: the MZ header; the PE offset; the import table RVA; the first import name RVA.
.text:0040120D add esi, ebp ; virtual address of the image import descriptor
.text:00401223 add eax, ebp
.text:00401225 push offset aUser32_dll_0 ; "user32.dll"
.text:0040122A push eax ; char *
.text:0040122B call __stricmp
.text:00401230 add esp, 8
.text:00401237 add esi, 14h
.text:0040123A mov [esp+18h+var_4], esi
.text:0040123E jmp loc_4012E6
.text:004012E6 mov eax, [esi+0Ch]
.text:004012E9 test eax, eax
.text:004012EB jnz loc_401223
Then the malware calculates the virtual addresses of the first image import descriptor, its import name address, and begins a loop over the import names looking for "user32.dll".
.text:00401243 mov edi, [esi]
.text:00401245 mov esi, [esi+10h]
.text:00401248 mov eax, [edi+ebp]
.text:0040124B add edi, ebp
.text:0040124D add esi, ebp
.text:00401257 jmp short loc_401260
.text:00401260 lea ecx, [eax+ebp+2] ; Name
.text:00401264 push offset aRegisterclasse ; "RegisterClassExW"
.text:00401269 push ecx ; char *
.text:0040126A call __stricmp
.text:0040126F add esp, 8
.text:00401272 test eax, eax
.text:00401274 jnz short loc_401297
.text:00401297 mov edx, [edi]
.text:00401299 lea eax, [edx+ebp+2]
.text:0040129D push offset aCreatewindowex ; "CreateWindowExW"
.text:004012A2 push eax ; char *
.text:004012A3 call __stricmp
.text:004012A8 add esp, 8
.text:004012AB test eax, eax
.text:004012AD jnz short loc_4012D0
.text:004012D0 mov eax, [edi+4]
.text:004012D3 add edi, 4
.text:004012D6 add esi, 4
.text:004012D9 test eax, eax
.text:004012DB jnz short loc_401260
Here the code saves the content of the OriginalFirstThunk and the FirstThunk fields of the IMAGE_IMPORT_DESCRIPTOR. Then, it loops over every IMAGE_IMPORT_BY_NAME.Name looking for the RegisterClassExW and the CreateWindowExW APIs.
Once they are found it does the following:
.text:00401276 lea edx, [esp+18h+flOldProtect]
.text:0040127A push edx ; lpflOldProtect
.text:0040127B push 40h ; flNewProtect
.text:0040127D push 4 ; dwSize
.text:0040127F push esi ; lpAddress
.text:00401280 call ebx ; VirtualProtect
.text:00401282 lea eax, [esp+18h+flOldProtect]
.text:00401286 push eax ; lpflOldProtect
.text:00401287 mov dword ptr [esi], offset BadFunc1 ; FirstThunk overwrite
.text:0040128D mov ecx, [esp+1Ch+flOldProtect]
.text:00401291 push ecx ; flNewProtect
.text:00401292 push 4 ; dwSize
.text:00401294 push esi ; lpAddress
.text:00401295 call ebx ; VirtualProtect
.text:004012AF lea ecx, [esp+18h+flOldProtect]
.text:004012B3 push ecx ; lpflOldProtect
.text:004012B4 push 40h ; flNewProtect
.text:004012B6 push 4 ; dwSize
.text:004012B8 push esi ; lpAddress
.text:004012B9 call ebx ; VirtualProtect
.text:004012BB lea edx, [esp+18h+flOldProtect]
.text:004012BF push edx ; lpflOldProtect
.text:004012C0 mov dword ptr [esi], offset BadFunc2 ; FirstThunk overwrite
.text:004012C6 mov eax, [esp+1Ch+flOldProtect]
.text:004012CA push eax ; flNewProtect
.text:004012CB push 4 ; dwSize
.text:004012CD push esi ; lpAddress
.text:004012CE call ebx ; VirtualProtect
Basically, it changes the protection of the memory containing the import addresses, using the VirtualProtect API; then it overwrites the FirstThunk entry, related to the RegisterClassExW and CreateWindowExW APIs, with a malicious offset.
In this way, every time one of these APIs is called it won't be executed and, instead, the code located at the malicious offset will be run. Even debugging the code, if we don't step into the calls, nothing will suggest that the code is being hijacked.
As we can see the ones above seem to be normal, legitimate, calls, but they are really hijacked to the malicious routines. And here is the trick in action in the debugger:
Note that this is not API hooking, but only a simple trick that works in the executable itself: it's not the API code being overwritten, it is the FirstThunk of the malicious executable.
What can I say... It's not a very advanced deception trick, but a curious one at least: come on guys, you can do better!