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:

Decompiling Excel Formula (XF) 4.0 malware

Office malware has been around for a long time, but until recently Excel Formula (XF) 4.0 was not something researcher Kurt Natvig was very familiar with. In this article Kurt allows us to learn with him as he takes a deeper look at XF 4.0.

APT vs Internet service providers – a threat hunter's perspective

Organizations in the telecommunications sector are faced with a multitude of threats, ranging from targeted attacks to malicious actions attributable to the criminal or activist world. Telsy researcher Emanuele De Lucia reports what he observed in…

VB2019 paper: APT cases exploiting vulnerabilities in region‑specific software

Some APT attacks are carried out by exploiting vulnerabilities in region-specific software. Government agencies frequently use such localized software, and this tends to be the target of attackers. In Japan, there have been many cases where attacks…

Detection of vulnerabilities in web applications by validating parameter integrity and data flow graphs

Web application vulnerabilities are an important entry vector for threat actors. In this paper researchers Abhishek Singh and Ramesh Mani detail algorithms that can be used to detect SQL injection in stored procedures, persistent cross-site scripting…

VB2019 paper: Cyber espionage in the Middle East: Unravelling OSX.WindTail

It’s no secret that many nation states possess offensive macOS cyber capabilities, though such capabilities are rarely publicly uncovered. However, when such tools are detected, they provide unparalleled insight into the operations and techniques…


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.