Anti-debugging, Anti-evasion and Anti-vm tricks used by malware

[abhaythehero]

Starting this thread to discuss Anti-debugging, Anti-evasion and Anti-vm tricks used by malware and malcode.

Starting with this nice usage of rdtsc instruction, I found on the malware sample I was working on recently. (still not clear whether it is the packer/protector or the malware sample itself, though I reckon it is the packer/protector)

00401> 0F31              RDTSC
00401> 52                PUSH EDX
00401> 0F31              RDTSC
00401> 58                POP EAX
00401> 33C2              XOR EAX,EDX
00401> 6A 04             PUSH 4
00401> 68 00100000       PUSH 1000
00401> 68 00100000       PUSH 1000
00401> 50                PUSH EAX
00401> FF55 E4           CALL DWORD PTR SS:[EBP-1C]                    ; kernel32.VirtualAlloc

The use of RDTSC instruction loads the current value of the processor's time-stamp counter into the EDX:EAX registers. The time-stamp counter is contained in a 64-bit MSR. The high-order 32 bits of the MSR are loaded into the EDX register, and the low-order 32 bits are loaded into the EAX register. http://x86.renejeschke.de/html/file_...86_id_278.html

The assembly uses the high-order 32 bits in EDX from the 1st RDTSC instruction and pushes it to stack. Then it pops it into EAX for XORing it to high-order 32 bits in EDX from the 2nd RDTSC instruction (XOR EAX,EDX)

Now comes the trick. The result of this XOR operation stored in EAX, is used as lpAddress argument in VirtualAlloc https://msdn.microsoft.com/en-us/lib...=vs.85%29.aspx

lpAddress [in, optional]
The starting address of the region to allocate. If the memory is being reserved, the specified address is rounded down to the nearest multiple of the allocation granularity. If the memory is already reserved and is being committed, the address is rounded down to the next page boundary. To determine the size of a page and the allocation granularity on the host computer, use the GetSystemInfo function. If this parameter is NULL, the system determines where to allocate the region

Now if someone is single stepping the assembly code in debugger slowly, there would be considerable change in high-order 32 bits returned by RDTSC each time. Hence the XOR operation would not amount to Zero(as both values are different and not same). Hence the lpAddress argument would be something like 00000003 (or greater value)



Which would just fail the VirtualAlloc address and it will return NULL instead of some base address.

Return value

If the function succeeds, the return value is the base address of the allocated region of pages.
If the function fails, the return value is NULL. To get extended error information, call GetLastError.

This return value is tested and execution is diverted to exit.

00401> FF55 E4           CALL DWORD PTR SS:[EBP-1C]
00401> 8945 90           MOV DWORD PTR SS:[EBP-70],EAX
00401> 85C0              TEST EAX,EAX
00401> 0F84 88030000     JE my.0040182C ; exit function

[b0nd]

Good one Abhay, keep them coming!

[abhaythehero]

Good one Abhay, keep them coming!

Thanks ! And yep, more posts coming in this section

[c0dist]

Just came across this post on Twitter - http://www.seculert.com/blog/2015/04...sandboxes.html

The post outlines a technique used by Dyre banking malware, by detecting processor cores. If processor cores count == 1, it exits.

This version of the Dyre malware is able to evade analysis by sandboxing solutions by checking how many processor cores the machine has. If the machine has only one core it immediately terminates. While this is not the only way to avoid sandboxes, the attackers behind Dyre decided to pick this specific known and openly available technique. As many sandboxes are configured with only one processor with one core as a way to save resources, the check (Figure 1) performed by Dyre is a good and effective way to avoid being analyzed. On the other hand, most of the machines (PCs) in use today have more than one core.

Nothing very 1337, but looks like it evaded most of the online sandboxes.

Cheers.

Regards,
c0dist

[abhaythehero]

Ohh yeah. I was going to post that today but you beat me to it c0dist. Also note this excellent paper https://www.exploit-db.com/docs/34591.pdf by Sudeep Singh referenced in that article which discusses many such anti-vm, anti-debugging, etc tricks.

[abhaythehero]

Nice cheat sheet of anti-debugging and anti-vm techniques (often used by malware)

https://code.google.com/p/corkami/do...m.pdf&can=2&q=
[Mirror] http://www.gironsec.com/blog/wp-cont...2013/12/cm.pdf