|Detected||Mar 03 2000 20:00 GMT|
|Released||Mar 03 2000 20:00 GMT|
|Published||Mar 06 2000 07:53 GMT|
This text was written with the help of Adrian Marinescu, GeCAD Software.
This is a very dangerous memory resident parasitic polymorphic Win32 virus about 20K in length. It infects KERNEL32.DLL and PE EXE files: it writes its code to the end of the file and modifies necessary fields in the PE header to gain control when an infected file is run. The virus also adds its "droppers" to archives of different types (ACE, RAR, ZIP, CAB, ARJ) and to some types of self-extracting packages (SFX ACE and RAR files).
The virus uses a polymorphic engine while infecting PE EXE files and archives only, and leaves the virus image non-encrypted in the KERNEL32.DLL file.
The virus uses anti-debugging tricks, disables anti-virus on-access scanners (Avast, AVP, AVG and Amon), deletes anti-virus data files (AVP.CRC, IVP.NTZ, ANTI-VIR.DAT, CHKLIST.MS, CHKLIST.CPS, SMARTCHK.MS, SMARTCHK.CPS, AGUARD.DAT, AVGQT.DAT), patches the LGUARD.VPS file (anti-virus database?), and avoids infection of many anti-virus programs: TB, F-, AW, AV, NAV, PAV, RAV, NVC, FPR, DSS, IBM, INOC, ANTI, SCN, VSAF, VSWP, PANDA, DRWEB, FSAV, SPIDER, ADINF, SONIQUE, SQSTART.
One of the most important virus features is the fact that it encrypts/decrypts "on-the-fly" Windows libraries (DLL files) when they are loaded - upon loading a library, the virus decrypts it, an upon unloading, the virus encrypts the file body. To encrypt DLL files, the virus uses strong cryptographic algorithms (provided by Crypt API included in Windows). As a result, once infected system keeps working only in the case the virus code is present in the memory and realizes this encryption/decryption. In case the system is disinfected, the DLL libraries stay encrypted, and the system cannot load them. The first virus to use such technology was Onehalf multipartite virus that was "well known" in the second half of the 1990s.
The virus is incompatible with several Win32 versions, such as Win95 and Win98 standard editions. Under these conditions, the virus does not install itself into the system (does not infect KERNEL32.DLL) and/or does not PE EXE infect files.
When an infected file is executed for the first time on a clean system, the polymorphic decryptor loop gains control, restores the original file code in clean form and passes control to there. The installation routine gains control, and after performing several anti-debugging and anti-anti-virus procedures, installs the virus copy into the system.
While installing, the virus infects the KERNEL32.DLL file so, that upon the next start-up, Windows loads the virus code as a part of the KERNEL32 library. While infecting, the virus patches KERNEL32 export tables so that upon the next loading, the virus intercepts and filters several file access functions that are exported from KERNEL32.DLL (CreateFile, OpenFile, __lopen, CopyFile, MoveFile, MoveFileEx, LoadLibrary, LoadLibraryEx, FreeLibrary - in both ANSI and UNICODE forms).
To infect KERNEL32.DLL (this library is loaded into the memory when the virus is run, so it is protected by Windows for writing), the virus copies the KERNEL32.DLL file to the Windows folder, infects this copy and then forces Windows to switch the old file with the infected one upon the next boot. As a result, upon the next restart, Windows will be loaded with the infected KERNEL32.DLL - the virus filters file-access events, and runs PE EXE and archive-infection routines.
After infecting KERNEL32.DLL, the virus erases its code from the memory and returns control to the host program.
When Windows is loaded with an infected KERNEL32.DLL, the virus stays in the memory as a component of KERNEL32.DLL, and hooks several KERNEL32 exported functions. Upon a first call to these functions, the virus activates its infection routine that searches for victim files (PE EXE) in the background and infects them. The virus searches files on all drives from C to Z.
To make the scanning process less conspicuous, the virus will first wait for three seconds before each drive scan.
While infecting a file, the virus enlarges the last file section and reserves space for its code, then writes the encrypted code along with the polymorphic decryptor in there and sets the program entry-point to the decryption routine.
The virus is able to add droppers to the archives of several types: ACE and RAR (including SFX self-extracting files), as well as ZIP, CAB, ARJ. The virus droppers in archives get a name randomly selected from variants:
INSTALL, SETUP, RUN, SOUND, CONFIG, HELP, GRATIS, CRACK, UPDATE, README
beginning or/and ending with '!' char. The file name extension is .EXE.
To add its dropper to an archive, the virus creates a dropper as a disk file and executes the external program needed to process the respective archive type. Using this method, the virus is able to append the dropper compressed with a randomly selected method, depending on the archiver program.
The virus creates cryptographic keys in the installation part of the virus (by using Crypt API included in Windows). If the keys are created successfully, the virus is able to encrypt the code of the DLL files that are used by applications (they loaded by Windows in case of need). To do this, the virus uses LoadLibrary and FreeLibrary hooks, intercepts library loading and encrypts/decrypt them on the fly.
Any DLL with the name starting with one of the following patterns are excepted: SFC, MPR, OLE32, NTDLL, GDI32, RPCRT4, USER32, RSASIG, SHELL32, CRYPT32, RSABASE, PSTOREC, KERNEL32, ADVAPI32, RUNDLL32, SFCFILES. Also, DLLs that are listed in the following lists are not encrypted:
The most important aspect is that the encryption key and the encryption algorithm are unique for each infected system. WinCrypt supports custom encryption algorithms making disinfection from other systems than Windows impossible. The encryption of the DLLs will consume many time/CPU resources - the virus will read each time the needed keys from registry.
To be able to use the Crypt API included in Windows, the virus needs to create a new key, with the container name set to "Prizzy/29A". First, the virus checks for its existence, and if the key is not present, the dedicated API is called in order to create a new one. Then, the virus will need to store the generated key - for that, the virus will use the system registry. At this point, the virus contains a limitation - it will assume that the key SOFTWARE\Microsoft\Cryptography\UserKeys\Prizzy/29A will be created after the CryptAquireContext API call. The virus will set the value 'Kiss Of Death' to the newly generated key.
Viruses replicate on the resources of the local machine.
Unlike worms, viruses do not use network services to propagate or penetrate other computers. A copy of a virus will reach remote computers only if the infected object is, for some reason unrelated to the virus function, activated on another computer. For example: