Navrhar

Classification

Malware

Virus

W32

Navrhar

Summary

Navrhar infects both VxD driver files and Word DOC files.

Removal

Automatic action

Based on the settings of your F-Secure security product, it will either move the file to the quarantine where it cannot spread or cause harm, or remove it.

Find out more

Knowledge Base

Find the latest advice in our Community Knowledge Base.

User Guide

See the user guide for your product on the Help Center.

Contact Support

Chat with or call an expert for help.

Submit a sample

Submit a file or URL for further analysis.

Technical Details

Infected documents contain a single AutoOpen macro which does not contain any macro copying or creation operations. When this macro receives control, it does a seek (using KERNEL32 APIs) to a particular position near the end of the document, reads 16,208 bytes from there, and saves them in a file named C:\RUNME.EXE. (All this is done using KERNEL32 APIs.) Then it executes this file via a Shell command.

The RUNME file is in PE (Portable Executable) format. Thus the virus uses Kernel32 API calls from this application to infect Windows 95 VxDs.

When RUNME is executed the virus first checks the operating system version and terminates if it is not Windows 95. This is because PE files could be started on Windows NT and on Win32s also, but the virus wants to work on 95. (Could not work on NT at all, because of the VxD part.).

Then it allocates enough memory for a copy of its VxD infection part. Then it opens itself, seeks to that location in RUNME and reads the VxD image area to this allocated buffer.

(This is a normal mechanism in case of viruses which are multi-partite and have a VxD part. They have to convert their body to different formats and they use some redundancy in different images for correct execution.).

Then the virus gets the Windows directory, (and manually adds "\SYSTEM" to that strings instead of using GetSystemDirectory API). Then it goes to the infection loop.

The infection loop gets pointers to VxD names. These are standard VxD names part of the Windows 95 installation:

eisa.vxd
 filesec.vxd
 isapnp.vxd
 logger.vxd
 lpt.vxd
 lptenum.vxd
 msmouse.vxd
 mssp.vxd
 nwserver.vxd
 nwsp.vxd
 paralink.vxd
 pci.vxd
 serenum.vxd
 serial.vxd
 spap.vxd
 splitter.vxd
 unimodem.vxd
 vfd.vxd
 vgateway.vxd
 wsipx.vxd
 wsock.vxd

(The file stamp field is used to check existing infection the virus set the file stamp to the same.).

Then the virus checks for the LE (Linar Executable) header and looks for the VxD's DDB in the executable.

It does this to find the offset of control procedure. The Control procedure is basically the entry point of a VxD.

VxDs are loaded by Windows 95 but not executed. Their Control procedure have to handle the messages coming from Windows 95.

The virus modifies the Offset of control procedure to point at the end of the original control procedure and patches an additional procedure there. Usually there is a space to patch additional code here since the control procedure is a kind of section itself with short code and the virus adds only a few bytes there (which fits in the aligment area).

Finally the virus adds itself to the end of the VxD also and marks the infected file, by changing its time stamp field.

When Windows 95 starts, it will load at least one of the infected VxDs. The new control procedure waits for INIT_COMPLETE and in this case it calls the virus installation routine. Finally it jumps to the host's control procedure.

The new control procedure has to overcome on a big problem. The virus body is located in a different section in the file, thus the virus has to load it from there to be able to execute. It allcotes memory with _HeapAllocate then with IFSMgr_Ring0_FileIO it loads this area from the end of the infected VxD and executes the loaded area by calling it. Finally it jumps to the original Control procedure from here, too. (The original path of the VxD is saved into the infected VxD during infection time. The virus uses this later on to load its code from the end of the VxD. That means that copied VxDs will not infect a different environment, if they new location is not exactly the same as the original was. For instance the Windows directory is located on the D: drive. However people are not exchanging VxDs.).

The istallation then hooks the file system. The new hook procedure checks for file open and the extension of the file by compering it to .DOC. Then it checks the size of the DOC file. If it to short or to big, it does not infect it. After this the OLE2 infection routine comes which is able to patch the prepared AutoOpen macro to the document.

To able to do this the virus calculates a pointer which points to its binary body at the end of the document, saves this to the prepared macro body code. (This line is used by the seek API to position to the beginning of the binary image later on.) Then it puts the AutoOpen macro into the document and the virus body to the end of the file.

It seems that the virus is of Slovakian origin, as it contains this text:

 HZDS virus (the world 1st direct VxD infector and the 2nd Word 6/7

infector) (c) Navrhar (DESIGNeR in english), Slovakia, 21-oct-97 Diz

virus haz been written in Banska Bystrica city, Slovakia."

Since the virus infects documents during file open only there are some additional infection problems. Navrhar does not check for the existance of the binary area at the end of the file during its infection check routine. Since the binary area of the virus is added at the end of the document, this part of the virus can get lost when an infected fast saved document is saved by FileSaveAs (which will save the file in normal format and eventualy optimizes the OLE2 file by removing the attached part from the end of the document completely.) However the virus will be able to spread fast enough regardless of this.

Date Created: -

Date Last Modified: -