Custom packer defeats multiple automation systems Ke Zhang Symantec , Japan Editor: Martijn Grooten Abstract Malware authors are constantly working on new ways to defeat automation systems, for example by packing their samples in order to increase the length of time it takes for their malware to be detected. Ke Zhang recently came across a custom packer that aims to defeat automation systems by combining anti-automation, anti-VM and anti-reverse engineering abilities. Although he was not able to determine the name under which it is being sold on the underground market, he did manage to study it in some depth. Copyright © 2015 Virus Bulletin

Automation systems are an enormous help to malware analysts, enabling them both to identify malicious files and determine their functionalities quickly. However, malware authors are constantly working on new ways to defeat automation systems, in order to increase the length of time it takes for the malware to be detected. In my recent work, I came across a custom packer combining anti-automation, anti-VM and anti-reverse-engineering abilities. I studied the packer in some depth, although I was not able to determine the name under which it is being sold.

Anti-automation In a normal system, the foreground window changes when the user switches between different tasks. In an automation system, however, there is usually only a single task: running a potentially malicious sample and monitoring its behaviour. The custom packer makes clever use of this difference between the two types of system. First, it calls GetForegroundWindow() and saves the window handle, then it continuously calls the same function and checks whether the foreground window has changed (see Figure 1). The rest of the code won’t be executed until the window has changed. Figure 1. Checking the foreground window. (Click here for a larger view of Figure 1.) It also calls GetModuleFileNameW() and GetUserNameExW() to examine whether the file and user name contain the keywords ‘sample’, ‘sandbox’ or ‘virus’, which are all likely to appear in automation systems.

Anti-VM The packer detects whether it is being run inside a virtual machine by checking registry values, checking for the existence of certain files, a certain process module, and IO control code. 1. Registry value The packer reads the following registry value and checks whether it contains the substrings ‘vmware’, ‘qemu’ or ‘vbox’, which are all used by popular virtual machines: HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus 0\Target Id 0\LogicIdentifier It then reads another registry value (shown below) and checks whether it contains the substrings ‘qemu’ or ‘vbox’ – again, the presence of either of these indicates that the machine is running inside a virtual machine. HARDWARE\Description\System\SystemBiosVersion\SystemBiosVersion 2. File existence The packer checks for the existence of the following files. %system32%\drivers\vmmouse.sys

%system32%\drivers\vmhgfs.sys

%system32%\drivers\VBoxMouse.sys

%system32%\drivers\VBoxGuest.sys The first two are used by VMware; the latter two are used by VirtualBox. 3. Process module The packer checks whether the process module ‘sbiedll.dll’ is loaded. This DLL is used by the Sandboxie sandbox. 4. IO control code 0x2D1400 The packer opens hard drive ‘\\.\PhysicalDrive0’ and sends control code 0x2D1400 to it (see Figure 2). It then checks whether the output buffer contains any of the following strings: ‘vbox’

‘qemu’

‘vmware’

‘virtual’

‘qm00001’

‘array’

‘00000000000000000001’ Figure 2. Sending IO control code. (Click here for a larger view of Figure 2.)

Anti-reverse-engineering The packer uses a lot of forward and backward unconditional jump instructions to split the sequential code. This makes it difficult for an analyst to get the whole picture, especially when following the code flow in a debugger. Figure 3 demonstrates the packer’s obfuscated strstr() function. Figure 3. Flow chart of the obfuscated strstr() function. As shown in Figure 4, after all the redundant jumps have been removed, the number of blocks decreases by more than half (from 23 to 10) and the logic looks much simpler. Figure 4. Flow chart after removing the redundant jump instructions.

Performance of public automation systems The techniques discussed here make things difficult for both human and machine analysis. I have tested several well known automation systems against one of the packed samples (sample ‘A’ in the Appendix) and none of them produced any information about its payload (dropping files to the %temp% folder and then running these), as shown in Figure 5, Figure 6, Figure 7, Figure 8 and Figure 9. However, with the relentless contribution from malware analysts, we expect to see ongoing improvements in those systems. Figure 5. ThreatExpert. (Click here for a larger view of Figure 5.) Figure 6. Comodo Camas. (Click here for a larger view of Figure 6.) Figure 7. Malwr. (Click here for a larger view of Figure 7.) Figure 8. Full report from Kingsoft Huoyan (Huoyan’s literal meaning is ‘fire eye'). Figure 9. Key behaviours report from Kingsoft Huoyan.