Custom packer defeats multiple automation systems

2015-09-02

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.


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.

Checking the foreground window.

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’

Sending IO control code.

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.

Flow chart of the 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.

Flow chart after removing the redundant jump instructions.

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.

ThreatExpert.

Figure 5. ThreatExpert.

(Click here for a larger view of Figure 5.)

Comodo Camas.

Figure 6. Comodo Camas.

(Click here for a larger view of Figure 6.)

Malwr.

Figure 7. Malwr.

(Click here for a larger view of Figure 7.)

Full report from Kingsoft Huoyan (Huoyan’s literal meaning is ‘fire eye').

Figure 8. Full report from Kingsoft Huoyan (Huoyan’s literal meaning is ‘fire eye').

Key behaviours report from Kingsoft Huoyan.

Figure 9. Key behaviours report from Kingsoft Huoyan.

Appendix: MD5 of related samples (all with the identical packer)

 MD5PayloadNotes
A40D19FBA73C6B011814E2C6920E8792FTrojan.Dropper drops samples B, C, and D to %temp% folder and executes them.N/A
BFBDEC6F2A565E5B6844A7DE2F785EC88Galaxy Logger V3Official site: http://galaxysproducts.com
CBA2A65C19C961A51739E28DF238FB0EABackdoor.TrojanC&C server: degreat248.no-ip.org:9003
D9C306303F6656435500A6A3C53793758Instant Password Stealer 1.0Official site: http://www.nuclearwintercrew.com

Table 1. MD5 of related samples (all with the identical packer).

twitter.png
fb.png
linkedin.png
hackernews.png
reddit.png

 

Latest articles:

Cryptojacking on the fly: TeamTNT using NVIDIA drivers to mine cryptocurrency

TeamTNT is known for attacking insecure and vulnerable Kubernetes deployments in order to infiltrate organizations’ dedicated environments and transform them into attack launchpads. In this article Aditya Sood presents a new module introduced by…

Collector-stealer: a Russian origin credential and information extractor

Collector-stealer, a piece of malware of Russian origin, is heavily used on the Internet to exfiltrate sensitive data from end-user systems and store it in its C&C panels. In this article, researchers Aditya K Sood and Rohit Chaturvedi present a 360…

Fighting Fire with Fire

In 1989, Joe Wells encountered his first virus: Jerusalem. He disassembled the virus, and from that moment onward, was intrigued by the properties of these small pieces of self-replicating code. Joe Wells was an expert on computer viruses, was partly…

Run your malicious VBA macros anywhere!

Kurt Natvig wanted to understand whether it’s possible to recompile VBA macros to another language, which could then easily be ‘run’ on any gateway, thus revealing a sample’s true nature in a safe manner. In this article he explains how he recompiled…

Dissecting the design and vulnerabilities in AZORult C&C panels

Aditya K Sood looks at the command-and-control (C&C) design of the AZORult malware, discussing his team's findings related to the C&C design and some security issues they identified during the research.


Bulletin Archive

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.