Custom packer defeats multiple automation systems

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.

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.

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.

HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus 0\Target Id 0\LogicIdentifier

HARDWARE\Description\System\SystemBiosVersion\SystemBiosVersion

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.)

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.

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.