Malware contribute to global warming

I faced an interesting piece of malware those days. In fact, this is the antivm trick used by the packer that took me some time to figure it out.

It started by a normal day, running malware in sandboxes trying to determine IOCs.
This dropper was detected by 29 AV on VT, and Microsoft named it "Trojan:Win32/Miuref" (MD5: 69ac30eb812d907eda632e870eaa4427).
Usual stuff, the dropper copy a file in %user%\Application Data\tmp and run it (MD5: 7e28e56cfd649cdf3c4382f0f3a0e0e7). This file is also quite well detected by AV vendors and Microsoft also detect it as "Trojan:Win32/Miuref" (should have almost the most functionality).

The interesting part comes here. Running through different sandboxes shows that the process stops at "EnumWindows". At first, I thought that it was standard antivm detecting specific window that I've never heard about when you run the binary in sandboxes. So I traced the binary (VB) and found a more interesting stuff.

Let's start from the beginning. This a VB packer so you need to follow the specific VB process to unpack it. Don't trace the VB VM, it doesn't give you any insight.
I started by putting a breakpoint on "EnumWindows". It is triggered, by surprisingly enough if I go over the call function of "EnumWindows" it runs 50% of my CPU and seems to loop forever. Strange....

By chance, I let it run for more than 10 minutes and pop ! the CPU is lower again and it seems to go to some interesting functions. How could this happen ?
In fact I discovered (maybe it's me and it's well known), that this packer is using the callback function of EnumWindows to trigger the antivm function.

Let's dig deeper in the callback function. One of the parameter of the EnumWindows function is a pointer to the callback. See below:

And if you jump to this address, you will find interesting code.

Standard antidebug code (IsDebuggerPresent, ...), some patching in memory and finally this CPU intensive process.
Standard antidebug stuff:

0016DA4C   64:A1 18000000   MOV EAX,DWORD PTR FS:[18]
0016DA52   8B40 30          MOV EAX,DWORD PTR DS:[EAX+30]
0016DA55   8078 02 01       CMP BYTE PTR DS:[EAX+2],1  ; FS:30 --> Check being debugged flag
0016DA59   0F84 E4060000    JE 0016E143
0016DA5F   64:A1 30000000   MOV EAX,DWORD PTR FS:[30]
0016DA65   8A40 68          MOV AL,BYTE PTR DS:[EAX+68]
0016DA68   24 70            AND AL,70

0016DA6A   3C 70            CMP AL,70  ; PEB 0x68 --> Check PEB!NtGlobalFlags

Yes, the guys let the packer running in a loop taking a looooong time (10 minutes in my VM but close to 20 minutes on my Cuckoo machines):

0016DADD   90               NOP ; --> Loop to waste time and CPU (ECX = 0D55ABBF)
0016DADE   31C0             XOR EAX,EAX
0016DAE0   31D2             XOR EDX,EDX
0016DAE2   0F31             RDTSC
0016DAE4   90               NOP
0016DAE5   0F6EC8           MOVD MM1,EAX
0016DAE8   0F6EC2           MOVD MM0,EDX
0016DAEB  ^E2 F0            LOOPD SHORT 0016DADD ; --> End of loop to waste time

And yes, if you define manually the timeout of your cuckoo to 20 minutes, you will see the next step, "CreateProcessA". In fact, you don't see more than the new process as cuckoo is loosing connection to the VM after the CreateProcessA and I didn't have time to look at it now. If you have any idea don't hesitate to comment.

The rest is interesting also as the new spawned child from "CreateProcess" is installing an extension in Firefox or Chrome but that could be a subject for an other post.

Happy hunting.