Virus.Win32.Crypto

Class Virus
Platform Win32
Description

Technical Details

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.

Installing into the system

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.

Virus spreading

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.

Archive infection

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.

Encrypting libraries

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:

 SystemCurrentControlSetControlSessionManagerKnownDLLs 
 SystemCurrentControlSetControlSessionManagerKnown16DLLs 

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
SOFTWAREMicrosoftCryptographyUserKeysPrizzy/29A will be created after
the CryptAquireContext API call. The virus will set the value ‘Kiss Of
Death’ to the newly generated key.