W32/Stepar

http://www.virusbtn.com/index.xml

---------------------------------

W32/Stepar

Analysis by: Adrian Marinescu

GeCAD Software, Romania

Type: Direct action Entry Point Obscuring polymorphic infector

Payload: None

Removal: Delete infected files and restore them from backup

Infects: Windows PE executable files

Aliases: Word prank macro

A few weeks ago I received a package from a fellow anti-virus researcher

containing some supposedly new Windows viruses. Intrigued by the suggested

virus name - which was the last name of one of my fellow researchers - I got

my hands on some interesting pieces of code.

Having seen so many high-level language worms in the past year, it was a

strange feeling when I started to dig inside a polymorphic encrypted EPO file

infector. Usually, within the first few minutes you get a pretty good idea of

the piece of code you're looking at - with Stepar, however, things were

slightly different. I was in for several surprises during my analysis -

surprises that many of us expected (but did not want to see).

Over the last few weeks I have received nine different variants of this virus

- some of them appear to be debug versions (even having a debug console),

others contain minor bug fixes. This description will refer to the initial

variant I received, Win32/Stepar.15349.

Infection process

When running an infected file, the first thing Stepar does is to find the base

of the Windows kernel - this address will be used to import the APIs the worm

requires in order to replicate. The method Stepar uses is not very common - it

assumes that the kernel is loaded at the same address as the exception handler

- this works for known Windows systems.

Next, Stepar retrieves a large number of 'KERNEL32.DLL' APIs (69) by using a

checksum on the API name and the API name length. To make emulation and

debugging more difficult, the replication code is launched on a separate

thread, while the main thread restores the code from the original entry point

and calls the restored code.

20 more APIs from 'USER32.DLL' will be imported, as well as one from

'PSAPI.DLL' (if available). If a mutex named 'ZMX' is present in the system,

Stepar assumes that another copy of itself is running - if this is the case,

it waits until the mutex is no longer present and then continues the

replication thread.

To make the infection process less suspicious, Stepar uses a technique that

has been used by several Windows viruses before - it tries to find the

'EXPLORER' process in memory and to inject itself into that process -

therefore, the viral code will not be listed as a separate process and the

replication will pass unnoticed. Copying its body inside the 'EXPLORER' memory

space and installing a custom hook that points to the viral code does the job.

When the hook receives control, it spawns a thread that executes the virus

body and it unregisters the hook installed previously.

After the mutex 'ZMX' has been created to signify that the infection process

is in progress, the current locale is checked - if the country is US (or any

other country with country ID equal to one e.g. Dominican Republic, Jamaica,

Puerto Rico, Trinidad & Tobago), and the current day plus the current month

modulo 16 equals 4, Stepar's infection routine will target every file instead

of only those matching '*.exe'. Interestingly, in this case the 'MZ' sign is

not checked - this might result in damaged PE files (without that sign) that

can be infected by Stepar.

Next, the current thread priority is set to idle and several tables used by

the infection routine are initialized. This was the first surprise I found -

Stepar uses a disassembler engine written by the infamous Russian virus writer

nicknamed Zombie, the author of the notorious 'Win32/Zmist' virus.

Another thread is spawned - this one will be responsible for the local network

infection, and will be discussed later. The current thread searches for files

in the current directory and attempts to infect them.

Next, Stepar selects root drives randomly from C to Z and searches for files

to infect. Probably to avoid infecting itself when running the virus, the

author included a way to deactivate the infection routine for a drive - if a

directory named 'l0x' is present in the root of the drive, Stepar attempts to

infect another drive. The maximum number of attempts is three - after that

count is reached, the current thread will wait for 20 minutes and loop to the

infection routine. A maximum number of 2000 files per search will be infected

for each drive. Another interesting fact is that the infection routine loops

forever - even though there is code present that should release the resources

used by the viral routine, it is never called.

Files matching the following list of known security utilities will be skipped

when infecting a file: 'avpcc.exe', 'avp32.exe', 'avpexec.exe', 'avpinst.exe',

'drweb32w.exe', 'spider.exe', 'spidernt.exe', 'avltmain.exe', 'apvxdwin.exe'

and 'pavproxy.exe'.

The network infection routine imports three APIs from 'MPR.DLL' for the

spreading process. Next, it enumerates network resources in an attempt to

locate shares with writable files - Stepar will try to infect them in the same

way it infects local files.

The little debugger that does it

The most interesting part of the virus is the file infection routine - it is

by far the most complex routine from this virus. EPO viruses have tried to

find a suitable place to insert a call to the decryptor/virus code or the

decryptor itself in many ways. The most remarkable is probably Win32/Zmist

which is able to disassemble and reassemble the host file, in between being

able to insert its body, split into multiple pieces, into the host code. That

complex approach requires huge memory resources - but probably the strongest

advantage of the method is that the virus can get control via code branches

that are not called directly - this is quite important from the point of view

of detection, because scanning the execution flow is not sufficient to detect

the virus in those samples.

Stepar uses a method that is not so complex but is very interesting. Instead

of having to analyse the host file itself, why not use the debug API that

Windows has to offer? This is done by creating the process as a 'debugged'

process, while being invisible to the user. On Windows 9x systems the

'debugged' process will also be invisible in the process list, by calling the

undocumented Windows API RegisterServiceProcess. After that, the newly created

process will be traced in single-step mode - the disassembled engine will tell

the tracer where to set the next breakpoint after the current instruction and

the debugger thread will receive notification for each breakpoint that is

encountered. This way, Stepar is able to walk through the host program

instruction by instruction, without having any code that deals with specific

Intel operation codes (besides the disassembler itself) and specific Windows

PE file format.

A maximum of 21,760 instructions are analysed in trying to find a suitable

isle of 450 bytes into which to insert the decryptor. If such a space is

found, the original code is saved inside the virus body and the main infection

routine is called. The process is very simple from that point - Stepar

generates a decryptor, encrypts its virus body and appends it to the last

section as the last 8192 bytes from the physical file. However, when I started

to analyse the decryptor I had another surprise - the engine used is written

by the same author as the disassembler engine. This engine, labelled 'RPME' by

the author, is able to generate polymorphic code based on plain Intel code

which is disassembled, morphed, permuted and then reassembled, in a similar

way to that used by Win32/Simile.

Teaching an old dog new tricks

Metamorphic viruses have unusually high memory demands. Win32/Zmist required

32 Mb of memory, Win32/Simile required 'just' 3.4 Mb - Stepar needs as

'little' as half a megabyte in order to generate a new decryptor. That memory

usage is basically limited by the fact that only the decryptor is metamorphic,

and the size of the morphed decryptor is limited to 450 bytes.

The engine itself is able to carry out the following operations on the

decryptor: change conditional jumps (by inverting the condition), change

register mov operations by using the stack, find opcodes with the same

functionality and use them, expand short jump instructions to the longer

equivalents, expand loop instructions and add trash instructions. Also, the

decryptor might be split into pieces and those pieces can be permuted inside

the virtual buffer of 450 bytes.

Detection issues

EPO viruses are a problem for conventional scanning - in order to find the

virus you need to locate the start of the viral code, which is sometimes far

from trivial. Usually the main payback of detection is the scanning speed,

which suffers because of the extensive investigation needed by the scanner to

locate the virus code.

Stepar's detection is not trivial, but fortunately, there are a number of weak

points of the infection process upon which anti-virus scanners might speculate

- starting with the fact that the virus body is always placed at the end of

the file and breaking its weak encryption will solve the problem for now.

However, an approach that searches for the decryptor inside the host code is

not so difficult to implement and would be more generic should the author

release improved versions of the virus.

Conclusion

After analysing very advanced computer viruses, many of us fear that parts of

the code we have just looked at will be used by other malicious code writers.

Even though there are not so many examples, we must consider that techniques

that are used in simple direct-action viruses can be used in more complex

creations which might get into the wild.

When the number of polymorphic viruses started to grow, approaches such as

code emulation were seen as unsuitable for scanning because of the lower speed

and higher demand on resources. Since the number of EPO and metamorphic

viruses is increasing, now is the time to improve generic techniques to handle

such complex viruses. After looking at the VB2003 conference programme I look

forward to seeing Frederic Perriot's presentation 'Defeating polymorphism

through code optimization', which may offer some hints about ways to fight

metamorphism in the future.

mailto: redarc@trojan.ru 

sample decryption loop

1>

CPU Disasm

Address   Hex dump            Command                                  Comments

0055C3A0  /> \29C9            SUB ECX,ECX

0055C3A2  |.  81E9 E1DCFFFF   SUB ECX,-231F

0055C3A8  |.  BF 00B06300     MOV EDI,OFFSET 0063B000

0055C3AD  |.  BB 00D05700     MOV EBX,OFFSET 0057D000

0055C3B2  |.  53              PUSH EBX

0055C3B3  |>  8A07            /MOV AL,BYTE PTR DS:[EDI]

0055C3B5  |.  83EF FF         |SUB EDI,-1

0055C3B8  |.  C0C0 04         |ROL AL,4

0055C3BB  |.  34 29           |XOR AL,29

0055C3BD  |.  2C B4           |SUB AL,0B4

0055C3BF  |.  34 22           |XOR AL,22

0055C3C1  |.  2C D3           |SUB AL,0D3

0055C3C3  |.  04 BB           |ADD AL,0BB

0055C3C5  |.  C0C0 06         |ROL AL,6

0055C3C8  |.  00C8            |ADD AL,CL

0055C3CA  |.  8803            |MOV BYTE PTR DS:[EBX],AL

0055C3CC  |.  43              |INC EBX

0055C3CD  |.^ E2 E4           \LOOP SHORT 0055C3B3

0055C3CF  \.  C3              RETN

2>

CPU Disasm

Address   Hex dump                   Command                                  Comments

00433EAE  /.  29D2                   SUB EDX,EDX

00433EB0  |.  81EA E1DCFFFF          SUB EDX,-231F

00433EB6  |.  BE 00164500            MOV ESI,OFFSET 00451600

00433EBB  |.  BF 00104400            MOV EDI,OFFSET 00441000                  ; ASCII "DyC"

00433EC0  |.  57                     PUSH EDI

00433EC1  |>  AC                     /LODS BYTE PTR DS:[ESI]

00433EC2  |.  C0C0 05                |ROL AL,5

00433EC5  |.  34 5B                  |XOR AL,5B

00433EC7  |.  2C 28                  |SUB AL,28

00433EC9  |.  00D0                   |ADD AL,DL

00433ECB  |.  AA                     |STOS BYTE PTR ES:[EDI]

00433ECC  |.  4A                     |DEC EDX

00433ECD  |.^ 75 F2                  \JNE SHORT 00433EC1

00433ECF  \.  C3                     RETN