F-Secure Virus Descriptions : Navrhar

NAME:

Navrhar

Navrhar infects both VxD driver files and Word DOC files.

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.

[Analysis: Peter Szor, F-Secure, 1999]