The world of computer antivirus research has changed drastically since the introduction of Windows 95. One reason for this change is that certain DOS-based viruses that used stealth techniques and undocumented DOS features became incompatible with Win95. As a result, virus writers took on the challenge of investigating the new OS and began creating new Win95-compatible DOS-executable viruses and boot viruses.
In March 1999, only 100 or so 32-bit Windows virus variants existed. Today, this number has grown to more than 600. Most of these variants are known as zoo viruses because they're contained in virus collections only and generally don't cause problems for end users. Most of the older 32-bit Windows viruses attacked only Win95. A year ago, fewer than 20 percent of all 32-bit Windows viruses were capable of replicating on Windows NT. Today, however, half of all 32-bit Windows viruses are true Win32 viruses, meaning they can replicate on NT and Windows 9x systems. Some of these viruses are already compatible with Windows 2000. Only about 25 percent of old Win32 viruses (i.e., written before Win2K) do not replicate on the release version of Win2K because of some slight incompatibility issues.
To protect yourself from viruses, it helps to understand where they came from, what forms they take, and how they can damage your systems. Armed with this information, you will stand a better chance of protecting yourself.
Win32/Cabanas.A is compatible with Win2K, NT, Win9x, and Win32s (an extension for 16-bit Windows to run 32-bit applications). As a result, Win32/Cabanas.A turned Microsoft's Win32-compatibility dream into a nightmare. With the shift away from DOS, Win32 viruses will eventually replace DOS-based viruses almost completely, and the DOS-based viruses will slowly die out.
The first major outbreak of a 32-bit virus began with the Win95/Anxiety family in late 1997. The virus patched its short code (i.e., modifying the Virtual Machine Manager’s—VMM’s—code in memory, not in the actual files) directly into Win95's VMM. On Win9x systems, the memory area where the system kernel and other Virtual Device Drivers (VxDs) load remains unprotected against memory writes, which makes these systems very vulnerable to attack. As a result, a user-mode application that runs in Ring3 can easily modify system-level code that runs in Ring0. Because Win2K and NT don't support VxDs, the Win95/Anxiety virus could not spread to systems running these OSs. Regardless, Win95/Anxiety caused major problems on home user and business desktop systems.
For emerging viruses, the major hurdle with Win32 platforms has been the common binary file format, or Portable Executable (PE) format. On Win2K, NT, Win9x, and Windows CE, most system executable files (e.g., .exe, .src, .dll, .ocx) and third-party applications share the same 32-bit file format—one that is very similar to the UNIX COFF format. This common file format makes creating viruses that are compatible with all Win32 systems relatively easy for virus writers.
Win95/Boza had other problems that caused the virus to fail, even on systems running different releases of Win9x. These problems occurred because the virus writers were using hard-coded addresses to APIs to more easily reach a particular system function. However, API addresses often vary from one OS system release to the next.
Win95/Marburg, like Win32/Cabanas.A, used a trick that has become today’s new standard in virus development. These viruses have a function that locates the address of each API they need to call under all Win32 systems. Viruses that append themselves to PE files can't call APIs easily because the viruses don't typically have their own imports, and the system DLLs export all system functions. Programmers use the API by static linking, which builds a proper import address table, or by calling the GetProcAddress() API to dynamically obtain the address of a particular API. An application that uses GetProcAddress() API typically needs to have a static import to call this API. The static import for the GetProcAddress() API is located in the application’s import address table, so the application is safe to call any APIs that are exported by name.
Virus writers had to implement a function that is similar in its implementation to GetProcAddress(). With this function a virus can easily append its own code to the host programs. Development of this function increased the chances that new viruses would be much more compatible with Win2K and NT. Taken a step further, 32-bit viruses that use standard Win32 APIs, implement the above functionality, and infect the PE file properly are Win2K and NT compatible.
These viruses can easily be per-process resident (i.e., the viruses run actively as part of a process or several processes). As a result, each process that uses kernel32.dll, which is any process that uses the basic Win32 file functions and directory functions, links to the virus code. The infected DLL attaches to every program that has kernel32.dll imports. Whenever the application calls the API with the attached virus code, the virus code gets control in the address spaces of the infected application.
Every system DLL contains a precalculated checksum that the linker places in the DLL's PE header. Unlike Win95, NT recalculates this checksum before it loads DLLs and drivers. If the calculated checksum doesn't match the checksum in the DLL's header, the system loader stops with an error message at the blue screen during system boot. However, this extra step doesn't mean that a virus writer can't implement such a virus for NT.
The Win32/Heretic virus was the first of its kind to implement proper kernel32.dll infection. As a result, the virus ran on NT. The Win32/Kriz virus also used this method to make its way into the wild. Win32/Kriz uses the CIH damage routine, but the damage routine doesn't work under NT because the virus runs in Ring3 (user mode).
Infected DLLs can be problematic to clean from the system because applications map these files from the disk to memory, and you can't modify these files once they load. Whereas you can boot an infected Win9x machine from a clean system diskette, it's much more complicated when you're using Win2K and NT with NTFS. In these situations, you need to use utilities such as NTFSDOS that can boot the system for write access. (Win2K's Recovery Console provides similar benefits, but only NTFSDOS supports NT. In addition, the NTFSDOS software can help you recover data from important system areas or files corrupted as a result of virus infection.) Fortunately, Windows’ System File Checker (SFC) feature will fix the modified system components automatically. To use SFC, type
sfc.exe
from the command prompt. SFC is not a virus security feature, but it helps reduce the risk of spreading viruses under Win2K.
The thousands of Win32/SKA.A reports that hailed from around the globe speak to the power of this threat. The worm disguises itself as an email attachment called happy99.exe. This file is the actual worm code, and it propagates by locating valid email addresses. The French virus writer known as Spanska came up with a simple solution. The worm modifies wsock32.dll and patches itself into this file so that two APIs—Connect() and Send()—can hook into the worm’s code. Thus, Win32/SKA.A can see all the network activities on the current machine. So, when someone posts an email message to another user or to a news server, the worm sends a copy of its email message with an attachment of its code.
Although the worm appeared more than a year ago, it continues to spread. These types of chain-letter worms are very successful because people usually trust messages they receive from their friends and associates. Although Win32/SKA.A came out long before the Melissa macro virus, many corporations didn't understand the worm's message in time and didn't institute strict policies that could have minimized the chance of other worm-related outbreaks later on.
Keep in mind that 32-bit worms are much more successful than viruses that spread relatively slowly. A worm can infect 1000s of machines around the globe in 1 day. Win32/SKA.A spreads more slowly than the more recent Melissa or LoveLetter because the worm sends itself only whenever a user sends an email message from the infected system. Newer viruses query the address book to get thousands of email addresses and spam themselves to as many locations as possible.
Win32/ExploreZip.A, which hit large American and Japanese companies, contained a very dangerous payload that truncated documents such as .doc and .xls files. Without proper backups, many companies lost thousands of files. PrettyPark let the virus writer use it as a back door to the infected system via remote commands.
Fortunately, Win2K’s SFC feature will take care of the ntoskrnl.exe modifications. Systems administrators need to check the system logs for SFC messages. SFC will not display any error messages as long as an original clean copy of a system file or application is available in the SFC cache directories. If SFC does not find the original system file on the hard disk, it will display an error message and request that the original Win2K CD-ROM replace the files. Even then, SFC won’t display the changed application name. However, the system log will contain information about the changes and replacements.
An alternative approach to polymorphic viruses is writing metamorphic viruses. These viruses consist of small modules that viruses can place in a virtually endless order using various sets of instruction sequences that differ in code but have the same result when executed.
Another element adding to the complexity of Win32 viruses is that several of these viruses consist of 10, 20, or even 100KB-long assembly code that is often encrypted multiple times. This approach provides a daily headache to antivirus researchers. Although antivirus researchers can analyze and fix macro viruses relatively quickly, most Win32 viruses are very complex, and finding a solution for a complex Win32 virus is more difficult.