Cabanas

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.

Variant:Cabanas.B

This is a modified variant of the orignal Cabanas virus. It was found in February 1998.