Relentless Zbot and Anti-emulations

A couple of months ago, Microsoft took out some Trojan.Zbot servers across the world. The impact was short-lived. Even though for a span of about two weeks, we saw virtually no Trojan.Zbot activity, relentless Trojan.Zbot activity has resumed—with some added new social-engineering techniques as well as some new techniques to help Trojan.Zbot avoid antivirus detection.

The following is an example of a recent Trojan.Zbot variant released on June 14, 2012, that implements a new anti-emulation technique in order to avoid detection.

Figure 1. Anti-emulation technique to avoid detection

Prior to executing its malicious code, the Trojan checks whether it is being executed for analysis in an emulated environment before deciding to execute or to abort its malicious actions. There are several ways of checking for the presence of emulators and this one is a new implementation from a new Trojan.Zbot variant.

The technique consists of checking code that is located in a particular Application Programming Interface (API). For instance, the Trojan may check code inside Kernel32.dll for the ReadFile API.

First it retrieves the opcode (operation code) from the ReadFile. This code specifies the operation to be performed. Then it compares that opcode to what is expected to be in a genuine Kernel32.dll ReadFile.

The expected opcodes that the Trojan looks for are 8B, 6A, and 55.

In most environments, 6A is the most expected opcode that will be found. This is true for Windows 7 and Windows XP where the Kernel32.dll code starts as follows:

Figure 2. Genuine Windows 7 Kernel32.dll ReadFile first opcodes

But a question arises: why also 8B and 55?

Most Microsoft APIs start with a direct prologue beginning with the usual PUSH EBP, which has an opcode of 55. In addition, many APIs also start with MOV EDI, EDI as reserved space for hot patches from Microsoft, and this instruction has the opcode 8BFF. Both of these are now taken into account by the Trojan.Zbot authors to ensure an accurate detection of emulators should all of these checks fail.

The effort that has been made by the Trojan.Zbot malware writers is not limited to one, or even a couple of techniques. In most malware variants there are many simple or complicated techniques to help avoid detection, like the following API or critical file names manipulation:

Figure 3. Manipulated API and library names

In an attempt to avoid detection, the malware authors have deliberately misspelled the stored "Kernel32" and "VirtualAlloc" strings, instead spelling them as "hhernel32" and "hirtualAlloc".

At a later stage, when the string is needed to get the address of the actual VirtualAlloc API from Kernel32.dll, the malware patches these strings in memory before using them correctly. This is illustrated in the following figure:

Figure 4. Correcting the misspelled "kernel32" and "VirtualAlloc" strings by memory patching

So basically, the malware ensures that the "kernel32" and "VirtualAlloc" strings are correctly spelled before using them.

These techniques are part of ever-evolving malware techniques, especially from professional malware writers who invest a large amount of time researching new techniques to evade antivirus detection. Symantec customers, however, can rest assured this malware and its techniques are effectively detected in Symantec products.

We have published the following paper in the "Journal in Computer Virology" for further reading about these anti-emulation techniques:
Anoirel Issa, Journal in computer virology, 2012, 10.1007/s11416-012-0165-0