Win32.Cabanas is a 32-bit virus that works under Windows NT, Windows
95 and Windows 3.x with Win32s sub-system.
Cabanas was found in late 1997. It is not known to be in the wild.
With its compact size (around 3000 bytes) Cabanas functionality is
self-limiting. For example, it sometimes prevents an infected computer
from being booted, so its ability to spread itself is limited.
Cabanas has no other functions besides spreading and occasionally
preventing booting.
The Cabanas virus was apparently created by the author of the common
WordMacro/CAP macro virus. This authors real name and location remain
unknown. The virus contains the following message which is never displayed:
(c) Win32.Cabanas v1.0 by jqwerty/29A
Cabanas has not been discovered in the wild, nor is that likely to happen
as long as the virus remains in its present form. The only known copies of
this virus are test samples spread by its author. Cabanas can not be
considered a large threat.
TECHNICAL INFORMATION:
Before Cabanas, all Windows 95 viruses were a bit different from the
implementation point of view. However none of those viruses worked
under Windows NT, because of certain incompatibilities. Win32.Cabanas
overcome these problems and become the first real Windows NT
compatible virus.
Win32.Cabanas is a per-process memory resident, fast infecting,
anti-debugged, partially packed/encrypted, anti-heuristic and
semi-stealth virus. The "Win32" prefix is not misleading, as the virus
is also able to spread in all Win32 based systems (Windows NT, Windows
95 and Win32s). The author of the virus is a member of the 29A group,
the same young virus writer who wrote the infamous CAP.A macro virus.
When a Win32.Cabanas infected file is executed the execution will
start at the original host entry point. Surprisingly, Cabanas does not
touch the entry point field in the Image File Header. Instead it
patches the host program at its entry point. Five bytes at the entry
point is replaced with a FAR JMP to the address where the original
program ended. This can be considered as an anti-heuristic feature, as
the host entry point value in the PE header keeps pointing inside the
code section, possibly turning off some heuristic flags.
Thus the first JMP points to the real entry point. The first function
in Cabanas unpacks and decrypts a string table which consist of Win32
KERNEL API names. The unpack mechanism is simple but effective enough.
The real problem is that the virus uses Structured Exception
Handling (typically abbreviated to SEH) as an anti-debug trick.
When the unpack/decryptor function is ready the virus calls a routine
to get the original Base Address of KERNEL32.DLL. During infection
time the virus searches for GetModuleHandleA and GetModuleHandleW in
the Import Table respectively. When it finds them its saves a pointer
to the actual DWORD in the .idata list. Since the loader puts the
addresses to this table before it execute the virus, Cabanas gets them
easily.
If the application does not have a GetModuleHandleA or
GetModuleHandleW import the virus uses a third but undocumented way to
get the Base Address of KERNEL32.DLL by getting it from the
ForwarderChain field of KERNEL32 imports. Actually this will not work
under Windows NT, but on Windows 95 only. When the virus has the Base
Address/Module Handle of KERNEL32.DLL it calls its own routine to get
the address of GetProcAddress function. The first method is based on
the search in the Import Table during infection time. The virus saves
a pointer to the .idata section whenever it finds a GetProcAddress
import in the host. In most cases Win32 applications import the
GetProcAddress API, thus the virus should not use a secondary routine
to get the same result. If the first method failed the virus calls a
function which is able to search for GetProcAddress export in KERNEL32
which could be called as GetProcAddress-From-ExportsTable. This
function is able to search in KERNEL32's Exports Table and find the
address of GetProcAddress.
After this the virus gets all the API addresses it wants to use in a
loop. When the addresses are available Cabanas is ready to replicate
and calls its direct action infection routine.
The direct action infection part is surprisingly fast. Even though it
goes through all the files in Windows directory, Windows System
directory and in the current directory receptively, the file infection
is fast enough to go unnoticed in most systems. This is because the
virus works with "memory mapped" files only, a new feature implemented
in Win32 based systems which simplifies file handling and increases
overall system performance.
First the virus gets the name of Windows directory, then it gets the
name of Windows System directory and calls the function which searches
for non-infected executable images.
Files with size dividable by 101 without reminder are assumed to be
infected. Other files which are too huge will not be infected either.
After this the virus checks the file extension, if it matches EXE or
SCR (screen saver files), the virus opens and maps the file. If the
file is considered too short it closes the file. Then it check the
'MZ' marker at the beginning of the image. Next it positions to the
possible 'PE' header area. It checks that the executable was made to
run on 386+ machines and looks for the type of the file. DLL files
are not infected.
After this it calculates a special checksum which uses the checksum
field of PE files Optional Header and the file-stamp field of the
Image File Header. If the file seems to be infected the virus closes
the file. If not, the file is chosen for infection. Cabanas then
closes the file blanks the file attribute of the file saves the
original attributes for later use. This means the virus is not stopped
by the "Read Only" attribute. Then it reopens and maps the possible
host file in write mode.
Next it searches for the GetModuleHandleA, GetModuleHandleW and
GetProcAddress API imports in the host's Import Table and calculates
pointers to the .idata section. Then it calls the routine which
patches the virus image into the file.
This routine first checks that the .idata section has MEM_WRITE
characteristics. If not it sets this flag on the section, but only if
this section is not located in an executable area. This prevents the
virus from turning on suspicious flags on the code section, triggered
by some heuristic scanner.
Then it goes to the entry point of the image and replaces five bytes
with a FAR JMP instruction which will point to the original end of the
host. After that it checks the relocation table. This is because some
relocations may overwrite the FAR JMP at the entry point and calls a
special routine to search for such relocation entries in the .reloc
area. It clears the relocation type on the relocation record if it
points into the FAR JMP area, thus this relocation will not take into
account by the loader. Then it crypts all the information which has to
be encrypted in the virus body. Including the table which holds the
original 5 bytes from the entry point and its location.
Next the virus calculates the special checksum for self check purposes
and saves this to the time stamp field of the header. When everything
is ready the virus calculates the full new size of the file and makes
this value dividable by 101. The real virus code is around 3000 bytes
only but the files will grow with more bytes, because of this. Cabanas
has a very important trick here. The virus does not create a new
section header for its code, but patches the last section header in
the file (usually .reloc) to be longer to take enough space for the
virus code. This makes the infection less risky and less noticeable.
Then the virus changes the SizeOfImage filed in the header to fit in
the file and unmaps and closes the file. Next it truncates the file at
the previously calculated size and resets the original time and date
stamp. Finally Cabanas resets the original attribute of the file.
When all the possible files had been checked by Cabanas, the virus is
ready to rebuild the host, Hook API functions and go memory resident.
The virus uses the GetCurrentProcess and WriteProcessMemory API
functions to write back the 5 original bytes at the entry point. After
this it relocates the code area if needed. Next the virus hoosk API
functions and goes memory.
This is based on the manipulation of the Import Table. Since the host
program holds the addresses of imported functions in its .idata
section, all the virus has to do is to replace those addresses to
point to its own API handlers.
Finally the virus closes and unmaps the host and starts the
application, by jumping into the original entry point in the .text
(CODE) section.
Cabanas is a semi-stealth virus: during FindFirstFileA,
FindFirstFileW, FindNextFileA and FindNextFileW the virus checks for
already infected programs. If the program is not infected the virus
will infect it, otherwise it hides the file size difference by
returning the original size for the host program. Since the CMD.EXE
(standard Command Interpreter of Windows NT) is using the above APIs
during the DIR command, every listed non-infected file will be
infected if the CMD.EXE was infected previously by Win32.Cabanas. The
virus will infect files during every other hooked API request also.
This is a modified variant of the orignal Cabanas virus. It was found
in February 1998.
[Analysis: Peter Szor, F-Secure, 1997]