This paper describes the significant increase in malware written in Visual Basic (VB) and why malware creators use VB as a platform for new Trojans. According to statistics in September 2012’s Security Bulletin, the most popular languages used to write malicious code were C++, Object Pascal (Delphi), JavaScript and HTML for web threats. Since then we have seen an increase of VB samples arriving in our malware repositories. 

We analyzed samples collected by the Lab during September and October 2012 (only PE samples) and observed numbers that demonstrate the growth of VB samples in our collection during the last two months from 3% in September to 7% in October 2012.

Figure 1 - VB samples detected by Lavasoft Sep-Oct 2012

If we look at the most widespread VB families according to AV companies’ detection rates, we notice the following statistics:

Figure 2 - VB samples detected by others antiviruses Sep-Oct 2012*

*The detection statistics are comprised of the most popular verdicts (only PE) in our collection (Sep-Oct 2012):

Avast: Win32:VB
Vipre: Worm.Win32.Vobfus
Microsoft: Worm:Win32/Vobfus, TrojanDownloader:Win32/Beebone, VirTool:Win32/VBInject
Ikarus/Emsisoft: Trojan.VB, Trojan.Win32.Vobfus
Trend Micro: WORM_VOBFUS
DrWeb: Trojan.VbCrypt
Kaspersky: Trojan.Win32.Jorik.VBNA

We can see that, according to Avast detections of our collection, the amount of samples flagged as being written in VB increased from 6% in September to 8% in October 2012.

First of all, let us mention a detection problem. We can see on Figure 2 that in most cases AV companies create a generic signature to detect VB samples because there is no bare payload data in the compiled code which can be used to apply specific AV signature.

Then, let us try to understand why malware developers choose to write malware in VB by examining the recently detected polymorphic VB family Trojan.Win32.Diacam (Trojan.Win32.VB.qms).

VB code can be analyzed using a combination of static and dynamic analysis. If we open the VB code in a disassembler it will not yield too much information, only obfuscated strings, a tactic frequently employed to make it more difficult to analyze the file:

Figure 3 - Trojan.Win32.Diacam (Trojan.Win32.VB.qms) in IDA disassembler

Evasive code is a peculiarity of Native VB executables which makes it an attractive language to code malware in. For example, the Entry Point of all Native VB applications looks like the following:

Figure 4 – Entry point of VB application

It points to a call to the function “ThunRTMain” with only one argument, which represents a special structure with execution information.

In fact, the real code starts from 0xE9E9E9E9 data. By default, it is not recognized as a code:

Figure 5 – Standard code section of VB application starts from 0xE9E9E9E9

Using a VB decompiler is a more convenient way to inspect the file:

Figure 6 – Trojan’s code in VB decompiler

But this still doesn’t reveal the main payload, which is still hidden in forms and obfuscated methods, further hindering analysis. Decompiling (as opposed to debugging) VB is more effective when working with P-Code VB applications which are represented as a byte code for the VB interpreter.

This particular Trojan extracts hidden encrypted data into the memory and executes as a PE code - the VB code in this case is only a wrapper for another executable VB file encrypted inside the wrapper’s body. It is not useful to analyze the VB code further.

When static analysis methods fail to yield useful results, we can turn to dynamic analysis by running malware on a sandbox and making a memory dump of the malicious process while observing its behavior in an isolated environment.

Figure 7 – The extracted file in a sandbox

We can see that the file contained within the VB wrapper is packed with a standard UPX 3.07 packer to reduce a file size. Armed with this new information, it is now possible to easily extract de-obfuscated and unpacked strings. Alternatively, by running the file and taking a memory dump, we can extract useful information from the dump as shown below:

Figure 8 – Extracted strings from the process dump

Strings in the dump reveals malicious activity related to setting registry values instructing the malware to run when Windows boots up. The more detailed report of the Trojan we can be obtained after behavioral analysis.

So, now we understand, why the most antiviruses detect VB malware with generic signatures, such as: Trojan,VBCrypted, Worm.Win32.Vobfus, VirTool:Win32/VBInject, Trojan.Win32.VB. A signature scanner cannot find a unique data sequence which would be particular to all samples within a family. This explains why they can detect only suspicious obfuscated or/and encrypted VB applications. A security analyst faces the same problem when carrying out static analysis of tricky VB code. In such cases the next step is to carry out dynamic analysis of an application.

Native compiled VB code is an ideal platform for creating malware, making analysis more complicated and avoiding precise detection by the most antiviruses. Moreover this does not exclude using additional obfuscation and encryption algorithms by malware authors. Altogether this allows developers to hide malicious intentions and increase the time between discovering the malware and publishing detection routines.