DOS
Viruses on Windows Platforms DOS
Viruses on Windows Platforms Windows
Viruses on Windows Platforms Signs
and Symptoms of Windows NT Virus Infections
Optional
Reading:
Evolution of
32-bit Windows Viruses
DOS
Viruses on Windows PlatformsIn a PC world where Windows is king, there is still a significant population of functioning DOS viruses. They do not understand how to manipulate Windows executables and the newer file storage types, so their overall ability to spread on a Windows system is decreased in most cases. Still, some do work, and the ones that don't, can still cause bootup and runtime errors. Under a DOS Virtual Machine (DVM) session, DOS is emulated well enough to allow most DOS viruses lots of opportunity to do damage.
This section will summarize the overall effects DOS viruses have on Windows, followed by specifics for each platform.
After the POST routine of a PC is finished, the first boot drive is checked, and the Master Boot Record (MBR) is located. The MBR then tells the PC where to locate the primary boot sector of the default operating system. This process is identical for every PC regardless of the operating system. Thus, a boot virus located on a booted floppy will be able to successfully infect the boot area of all hard drives. When an infected PC boots, the infected boot sector is given control. During this stage of the booting process, the virus can execute its payload damage regardless of the operating system. In many cases, boot viruses check for particular dates or events to initiate damage routines or display messages. These damage routines are usually accomplished using ROM BIOS interrupts (e.g., 13h) and they will be successful.
If the newly infecting boot virus declines to initiate a payload routine during the first stage of the bootup, usually its next priority is to locate the default boot sector and replace it with viral code. Most boot viruses will be successful here, too. Next, a boot virus must turn over control to the original boot sector, start the default operating system, and place itself in memory (so it can infect accessed diskettes). Depending on the boot virus mechanism and the operating system, it may or may not be successful. The virus might not understand how to correctly infect the new type of boot sector, or it won't understand the new file subsystem, or the operating system in control may prevent its future actions. In any case, the boot virus may not be successful in its later attempts. And if it isn't, the boot virus will not spread far. However, its misguided attempts can easily disable a PC from booting properly and cause data loss.
DOS programs infected in Windows by a DOS virus usually exhibit the same signs and symptoms as if they were infected without Windows (i.e. file growth, missing free memory, program sluggishness, etc.). DOS viruses infecting Windows programs is a different story. Because DOS viruses do not know how to correctly infect Windows platforms, the most common sign of infection is program corruption. Infected program files error out and are unable to execute. If a DOS virus corrupts a key operating system file, Windows either will not load, or it will load with boot errors, or in a diminished state.
Both boot and DOS file viruses can cause problems to the Windows 3.x platform.
Because Windows 3.x has a DOS boot sector underneath, boot viruses can easily infect and replicate. With versions 3.1x and above, an error message indicating that 32-bit disk support has been disabled might be presented, but that is about all you will notice. Boot viruses can infect the boot sectors of accessed floppy diskettes without causing noticeable disruption. Multipartite viruses, which can infect executables and boot sectors, will have little problem spreading as a boot virus, but will probably encounter problems when infecting executables.
Windows 3.x is started with DOS firmly in control. Viruses infecting DOS programs can infect files started in a DVM without many problems. File-overwriting viruses will be able to spread under Windows 3.x as they normally would in DOS. Overwriting viruses always destroy the victim's executable, and hence, understanding the new NE file format is not a prerequisite. DOS parasitic viruses will usually fail to properly infect Windows executables, instead causing immediate file corruption and subsequent error messages. There are a few DOS viruses, for example the Termite virus, which, either through luck or a brief understanding of Windows file structures, will be able to successfully use Windows executables as hosts.
Many viruses are known as prependers. They can be written in a variety of languages and infect many types of hosts because they attach themselves at the beginning of a mostly unmodified host file. As long as the prepending virus can execute, it will run, and then (hopefully) execute the underlying saved host file. Using this method, many DOS prepending viruses will be able to successfully function under different Windows platforms.
By the time Windows 95 came around, Microsoft was starting to build in limited antivirus features, but not enough to stop the spread of DOS viruses.
Although Windows 9x does not have a built-in antivirus scanner, it does include several features that can thwart DOS computer viruses. First, it blocks malicious programs trying to directly access the hard drive using interrupts 25h or 26h (absolute disk read/write). If a program attempts to use those interrupts, Windows 9x will attempt to intercept the call, lock the system, and display the following message: "Windows has disabled direct disk access to protect your long file-names...The system has been halted. Press CTRL+ALT+DELETE to restart your computer." Not elegant, and it doesn't always work, but it prevents a lot of viruses from spreading.
Second, Windows 9x monitors interrupt 13h (disk services) and maintains a list of programs that are currently hooking it. With each reboot, Windows 9x compares the list of programs currently hooking interrupt 13h with the previously recorded list. If Windows 9x notes any differences, it then compares it to a list of known safe programs and device drivers that hook interrupt 13h. The safe list is maintained in a file called IOS.INI located in the Windows directory. If the new program is not on the safe list, Windows generates the following warning message: "WARNING: Your computer may have a virus. The Master Boot Record on your computer has been modified. Would you like more information?" If you click Yes, the System Performance tab is shown for further details. You can then view the IOS.LOG file for more details. It's important to note that the warning message only appears on the first reboot after the initial infection. If ignored and the PC is booted again, the virus could be successful and the warning message will not be shown again.
|
As noted previously, if Windows 9x has been forced into MS-DOS Compatibility mode, then the I/O Supervisor (IOS) writes an IOS.LOG file that can be read to locate the file-hooking interrupt 13h or force Windows out of 32-bit file system mode. These Window 9x features are good for users and bad for DOS virus writers.
Boot viruses are able to infect and spread in Windows 9x environments, although again, bootup errors can occur. Windows 9x hard drive file systems are controlled by new interrupt calls and device drivers. Most DOS virus droppers will not be able to infect a hard drive while Windows 9x is running, although a few, like the multipartite virus Tequila can. However, removable disks (i.e. floppy diskettes) are a little better protected. The 32-bit Windows driver, HSFLOP.PDR, does not let most viruses write to the boot sector of floppy diskettes. Some viruses will delete the driver in order to force 9x machines to use 16-bit disk drivers and be able to replicate under Windows.
Like, Windows 3.x, every DOS program or DVM window contains a copy of the real-mode devices loaded from the CONFIG.SYS and the AUTOEXEC.BAT. If a virus has infected a program initialized in real-mode startup session, the virus will automatically be in control of each DVM started, and subsequently, any DOS programs started. Since Windows 9x has no file-level security, viruses are free to roam the file system and infect other hosts. If a user starts an infected program in one DOS window, the virus can infect COMMAND.COM or some other common file in memory and automatically infect files started in another DOS window. DOS viruses infecting the new NE or PE executable types will usually result in file corruption.
Windows NT does a great job of preventing the spread of boot viruses, and can limit the damage file infectors cause.
Since NT is not in control of the PC until the second half of the boot process, boot viruses can readily infect an NT PC. An infected diskette that is accidentally booted will be able to infect the boot sector or MBR of any hard drives using its normal methods. And any payload damage the virus has that runs before NT has control can cause harm. Because of this, boot viruses can and do cause damage to NT systems.
Two questions remain. First, will Windows NT boot its normal way without you noticing the boot virus infection? Second, if Windows NT does boot without error can boot infectors infect accessed floppy diskettes to spread even further? If Windows NT boots with an infected FAT partition and the virus doesn't modify the partition table, chances are the boot will be successful without Windows NT noticing any changes. The virus will be activated upon reboot, and eventually start the original FAT boot record of Windows NT. However, once Windows NT has loaded and removed real-mode drive access, boot viruses will be unable to spread further (and are unable to cause more damage during the current session). Even stealth routines, which in DOS would hide the virus, are nullified.
|
Viruses that implement an encrypting or stealth routine during the initial stages of the boot, and again later after NT is booted, will have their latter actions stopped. And this isn't always good. For instance, the Monkey MBR virus modifies the partition table to point to its own viral code, but uses stealth routines to point partition-table inspectors to the original table. After NT is in control, it queries the partition table to set up the logical disk volumes. The Monkey's stealth routines, which would have otherwise pointed NT to the original table, are blocked by NT. So, NT isn't able to find the original partition table and fails to boot properly. Other viruses, like One-Half, which use complex encryption or stealth routines, can cause more damage under NT, since NT prevents them from trying to hide their damage when the data is retrieved by the user.
NT with NTFS partitions will usually be unable to start after a boot virus infection. This is because NT with a NTFS boot partition will read the boot sector twice: once during bootup, and once just after NT gets control. NT will look to the boot sector a second time to recognize the logical disk volumes, fail to find the appropriate NT boot code, and crash. Surprisingly, some stealth boot viruses have a better chance, depending on their coding, to allow NT with NTFS to load without crashing. However, once NT is loaded all stealth routines are prevented, and the same rules for FAT partitions apply.
|
In a Virtual DOS Machine (VDM), DOS is thoroughly emulated and viruses can easily infect other DOS files accessed within the VDM (limited only by NTFS security). File infectors will be able to infect any DOS file executed with the VDM and search the hard drive for more victims. A file virus could infect COMMAND.COM, which is kept in NT for backward compatibility, and thus be available (and potentially active) in any future VDM opened. Viruses that attempt to call ROM BIOS interrupt routine services to trash the hard drive will be prevented from working.
Windows program files infected by a DOS virus will usually be corrupted and unable to start, thus limiting the spread of the virus. If any of these files are crucial to NT's booting or operational capacity, NT could be prevented from functioning. Luckily, Windows 2000 and ME have Windows File Protection (WFP) and System File Protection (SFP) and can implement self-repair.
Further, DOS file viruses are limited by the file access rights of the logged on user. A strictly protected Windows NT system with NTFS partitions prevents normal users from modifying executable and system files, and will prevent file viruses from causing any harm. However, floppy diskettes are always formatted with FAT, and DOS viruses can potentially infect files located there.
Windows
Viruses on Windows PlatformsTo date there is no such thing as a Windows boot virus, although theoretically NT/2000 is ripe for such an exploit. Windows executable viruses, however, are able to spread on different Windows versions depending on how they were written and the platform they land on.
Microsoft's newest operating systems, ME, 2000 and XP, have introduced dozens of new features, and many of these will be exploited in the coming years. Particularly, File Protection, Offline folders and files, the Run As feature, and IntelliMirror are potential new targets for viruses. All of these technologies have the capability to introduce untrusted code into a secure system. For instance, what if a virus is able to make itself part of the file protection mechanisms and become a protected file? No matter how hard a virus scanner might try to remove it, Windows will replace it. No matter how future exploits occur, most security experts agree they will not be any easier to combat.
The first native Windows virus, WinVir, didn't appear until April 1992, a full two years after Windows 3.0 was released. Although it infected Windows .EXE files, it contained no Windows API calls and instead resorted to DOS interrupts, which showed even two years later that virus writers didn't really understand the Windows environment. When WinVir was run, it would infect every Windows .EXE in the current subdirectory, and at the same time disinfect the program it was initially launched from. Virus writers didn't wait as long to develop a 9x virus, although Windows NT proved a tougher nut to crack.
Released in Internet newsgroups in February 1996 by the Australian VLAD virus writing group, Boza was the first Windows 95 virus. When run, the direct infection (nonresident) virus would look for three 32-bit executables to infect in the current directory. If it couldn't locate three hosts, it kept moving up a directory level until it found three files to infect. Eventually, it would stop at the root directory. On the 30th of every month, Boza will display a message box announcing its presence and list other viruses programmed by the VLAD group.
Released in late 1997, Win32.Cabanas was the first virus to work under Windows NT. Complex enough to be buggy in its first release, it is a memory-resident, stealth, armored, encrypted virus. When run, it will immediately infect all Windows EXEs (checking for the MZ signature) and SCR (screensaver files) in the %Windir% and %Windir%\System folders. Using some unique NT file handling routines, it infects all of these files in a few seconds. It hooks interrupts and APIs, and can infect files listed from a DIR command. It will try to hide increases in host file size. It works in Windows 9x and Windows 3.x with the Win32s API. A great article about it can be found at http://www.peterszor.com.
Today, viruses targeted at a particular version are being written and released while the latest Windows version is in beta testing. Windows virus writing mimics, on a smaller scale, the Windows development process. Virus writers have virus beta testers, release candidates, disclaimers, product launches, and press releases. Obviously, the virus-writing groups have grown more sophisticated, but so have the tools.
Windows viruses no longer have to be written in assembly language, as several high-level Windows programming languages make the job easier. Plus, the Windows file structures have been documented more thoroughly and Microsoft has been more forthcoming with programming details. Early on it was hard for even legitimate programmers to get access to Microsoft's programming constructs and file formats. Now, free tutorials are available all over the Web. Programming tools are coming with GUIs so that it is possible to write complete programs without ever writing the first line of code. Today, we have over 600 different 32-bit Windows viruses, and on a whole, they are more sophisticated than their DOS counterparts.
Windows viruses come in three forms: 16-bit, 32-bit, and platform-specific. 16-bit viruses infect Windows 3.x platforms and new executables, but are often able to infect Microsoft's 32-bit platforms. Many Windows viruses still contain a fair amount of 8- and 16-bit code, and as such, can easily interact with the DVM environment running under Windows 3.x, Windows 9x, and Windows ME.
Viruses that can operate on more than one 32-bit platform are known as Win32 viruses. If a virus has platform-specific coding, it might be known as a Win95, WinNT, or W2K virus. Half of all known 32-bit Windows viruses are known as Win32. About 75 percent of those will work on Windows 2000. The other 50 percent of 32-bit viruses are known as Win95 viruses, which means they only work completely on Windows 9x platforms. Most Win95 viruses use the virtual device driver (VxD) method to spread, and NT and 2000 platforms do not use or allow VxD files. In a strange twist, Windows 2000 contains APIs that were available in Windows 9x, but not NT. This means some viruses might be able to run on Windows 2000 and 9x, but not Windows NT.
|
Viruses written correctly to infect a particular platform will be able to spread readily and invisibly, for the most part, although the new file protection (xFP) mechanisms of Windows ME and Windows 2000 will prevent many viruses, worms, and Trojans from spreading. For instance, many viruses and Trojans modify KERNEL32.DLL. With file protection enabled, a default state, the KERNEL32.DLL will be corrupted, and then immediately replaced by a clean copy before further harm can be done. A growing number of new viruses, including W2K.Installer and Win32.CTX intentionally do not infect xFP-protected files. It is expected that future viruses and worms will be successful in bypassing xFP, either by disabling it or by exposing weaknesses in its implementations. After all, xFP was not explicitly designed to prevent MMC.
How a computer virus presents itself is dependent on the type of virus and the Windows platform infected. Typically, the older and more widespread the virus, the less likely it will be able to spread and cause harm. In this section, we will cover the signs and symptoms of computer virus infection in Windows.
Some signs of virus infection are:
· The normal signs and symptoms of successful computer virus infection apply. Hacker-sounding taunts, such as "Gotcha" or "You're infected," should be a major clue. Randomly appearing graphics, sounds, file disappearance -- all of these should be taken as possible signs of virus infection.
· Sudden, unexpected executable file growth and/or date changes. This is one of the quickest ways of spotting a computer virus, but you have to know what to look for. Windows will frequently update executables (i.e., EXEs, DLLs) as a normal part of business. The trick is to look for widespread executable updates at the same time as other suspicious symptoms started occurring.
· Unexpected modification of startup areas (AUTOEXEC.BAT) registry, Startup group.
· Sudden slowness with file execution might be a sign.
· Sudden, unexpected long-term hard drive accessing after your program or data is loaded could be suspect.
Windows 16-bit and 32-bit program files infected with a DOS virus will usually fail to run. DOS viruses infecting newer versions of COMMAND.COM may result in "Bad or missing command interpreter" messages and the system is halted. When an infected program is started, Windows immediately produces a fatal error message, or in some instances, Windows locks up or displays blue screens. An error message may state that an "Invalid Page Fault" occurred, a program attempted to write to an illegal memory location, or the file you are attempting to execute could not be located. The last error message is confusing because many times you are double-clicking on the same executable file Windows is saying it could not locate (don't be fooled by a misdirected shortcut). Be especially suspicious if Windows executables will not start, but DOS programs work fine; or vice versa. Another virus-created error message stating "This version of Windows does not run on DOS 7.0 or earlier" when you haven't installed new programs should clearly lead you to suspect a DOS virus.
With Windows 3.1, viruses frequently caused the following Windows warnings, "The Microsoft Windows 32-bit disk driver (WDCTRL) cannot be loaded. There is an unrecognizable disk software installed on this computer" or "This application has tried to access the hard disk in a way that is incompatible with the Windows 32-bit disk access feature (WDCTRL). This may cause the system to become unstable." Inability to create a temporary or permanent swap file can be caused by a boot virus. Later versions of Windows 3.x produce error messages suggesting that computer viruses could be responsible when presenting these types of errors.
Windows 9x systems may boot without an error message, but reveal that the file or virtual memory system is in MS-DOS Compatibility mode. You can check this by choosing Start ->Control Panel ->System ->Performance. On most systems you should see the file and virtual memory system in 32-bit mode. Systems running real-mode processes could be the result of Windows detecting a program that hooks the disk's write-interrupt routine. Although there can be several legitimate causes (i.e. third-party driver, antivirus program, etc.) for this type of symptom, computer viruses are a likely cause. If the driver name listed as causing MS-DOS Compatibility mode is MBRINT13.SYS, definitely suspect a boot virus. You can edit IOS.LOG to determine what file might be causing the conflict.
|
If you've been around Windows NT any decent amount of time, you are probably already familiar with the infamous Blue Screen of Death (BSOD) errors. The blue screen refers to the color of the background displayed during Fatal System Stop Errors (Windows 2000 BSOD is actually black). They have been around since the days of Windows 3.0, and are present in Windows 9x, but are more common in Windows NT. When Windows encounters a serious error, it will immediately halt the system and display a debugging screen. If you are not used to BSODs, they can be a little intimidating -- lots of numbers and filenames. What is displayed on the screen is different for each platform. Windows NT gives the most information. Windows 2000 has dropped a lot of the information that was displayed in the NT version, but all versions give you the error message text and an error number, and are followed by the drivers and programs associated with the error. A good troubleshooter can use this information to identify the offending device driver or program, or use it to research Microsoft's Knowledge-Base articles for a remedy.
If a boot virus is successful in writing itself to an NTFS boot disk, NT will almost always show blue screen with a STOP error. In the case of boot viruses, STOP messages will most often begin with error codes 0x0000007A, 0x0000007B, or in the case of Windows 2000, 0x00000077. All of these STOP errors are the result of NT not being able to correctly read the boot drive or paging memory.
|
Many computer viruses are discovered during the Windows installation process. When Windows 95 first came out, thousands of users complained to Microsoft that the Windows 95 Setup Disk 2 was infected with a virus. Users would start installing Windows, but when they came to Disk 2, Windows indicated the disk was bad. Many users did a virus scan and detected a boot virus on the new disks and incorrectly blamed the Redmond, Washington company. Microsoft wasn't distributing infected diskettes, the users' systems already contained a boot virus, which infected the new diskette while Windows was saving setup information. An "Invalid system disk" message can appear after the first reboot on an infected Windows 9x system, as Windows goes to load itself for the first time. A "Packed file corrupt" error message can occur during the initial install stages on an infected machine.
Boot viruses can cause Windows NT to state, "The hard disk containing the partition or free space you chose is not accessible to your computer's startup program." An infected Windows NT PC with a NTFS boot partition may say "A kernel file is missing from the disk. Insert a system disk and restart the system." A common sign you can see when installing Windows NT on an infected system is that NT begins to load, goes black, and then reboots, and continues repeating the cycle. Again, an infected boot sector can be suspected. Occasionally, Windows NT will be quite direct with some of its error messages, like "MBR checksum error: a virus may be present. Verify Master Boot Record integrity".
Microsoft programmers are getting better at detecting virus-like situations and the error messages they cause. Of course, the virus writers are fighting back. Some boot sector viruses, like Gold-Bug, will detect the Windows startup process, disinfect the boot sector on the fly, and then reinfect after Windows is through checking.
Windows is very careful about what hard disk areas it uses when creating permanent swap files during the initial install. If, while creating a new swap file, Windows detects an incorrectly modified disk or disk subsystem, it will refuse to create a swap file. In Windows 3.x, the message might be, "The partitioning scheme used on your hard drive prevents the creation of a permanent swap file." Viruses, trying to intercept the file-write interrupts, can cause swap file problems and error messages.
In summary, as we all know, Windows has enough problems and errors without a computer virus being involved, but an active PC with any of these symptoms should be checked for computer viruses. Suspect a nonvirus problem first, if you know the PC hasn't been exposed to any new programs, files, diskettes, new emails, or Internet accesses.Windows viruses are as varying as their DOS predecessors, although because of the challenges of programming in a Windows environment, there are less of them currently. Windows environments afford virus writers who are willing to learn 32-bit programming a plethora of new ways to be malicious. Often, Windows viruses are part virus and part Trojan. Here are a few examples.
Discovered on December 17, 1998, Remote Explorer was the first virus to load itself as a Windows NT service and the first to steal an administrator's security rights to spread. Believed to have been released by a disgruntled employee, the Remote Explorer attacked MCI WorldCom's global network. The virus is written in Microsoft Visual C++ and is quite large for a virus at 125KB and 50,000+ lines of code. Some experts estimated that it took a knowledgeable individual(s) over 200 hours to write.
When an infected executable is started on an NT machine and the current user has Administrator privileges, the virus installs itself in the \WinNT\SYSTEM32\DRIVERS folder as IE403R.SYS and runs itself as a NT system service. Running as a service, the virus gets loaded each time NT loads. Once installed, the EXE portion of the virus releases control (behaving more as a Trojan dropper). The registry will have a new key, HKLM\System\CurrentControlSet\Services\Remote Explorer, added to reflect the new service. If the current user is not an Administrator member, the service install will not work, but the virus will still be loaded into memory.
It will check the security privileges of the logged-on user every 10 minutes while waiting for a Domain Administrator. When an administrator does log on, it then uses the administrator's security credentials to install itself as a service, and steals the new credentials to infect other trusted networks. The virus uses an impressive routine to steal the Domain Administrator's security clearance: it opens another process (using the OpenProcessToken Windows API), usually EXPLORER.EXE, duplicates the security token assigned to that process, and then uses the stolen token to run a copy of itself under the administrator's credentials using the CreateProcessAsUser API.
The virus is visible as IE403R.SYS in the Task Manager's process list and in Control Panel Services as Remote Explorer. The infection routine is set to run in low-priority mode during peak business hours. Authorities think this was so the virus would be less noticeable. The infection routine randomly scans local and shared drives and infects EXE files, but intentionally skips the \WinNT\SYSTEM, \TEMP, and \Program Files folders. The virus stores the host file's code at the end of itself. When the infected file gets run, it copies the original file out to a .TMP file to allow it to be executed after the virus runs. Although it is a PE infector, the virus fails to verify executable type, and will corrupt non-PE EXE files. It will not infect or corrupt files with .OBJ, .TMP, or .DLL extensions. Non-NT machines can host infected files, but are not subject to further virus infection. The virus compresses, and indirectly corrupts certain files, including .HTML and .TXT files. If it can't infect a file that it finds, it encrypts and corrupts it. The infection process uses a file, called PSAPI.DLL to do its dirty work. If deleted, the virus will recreate the file.
Remote Explorer contains a hiding and cleaning routine designed to cover up its tracks. It looks for windows with the "TASKMGR.SYS -- Application Error" and "Dr. Watson for Windows NT" titles and closes them. It also deletes the Dr. Watson log file (DRWTSN32.LOG). This routine attempts to hide error messages resulting from its activities. All and all, Remote Explorer is a sophisticated virus. We are lucky that MCI WorldCom responded quickly enough so that the virus did not spread much beyond its own networks. Remote Explorer was not designed to spread over the Internet.
|
However, since then, there have been many viruses and Trojans that improve on the tricks learned from Remote Explorer. RemoteExplorer could only infect files the user had permission to modify (working in User mode). WinNT.Infis is a memory-resident virus that arrived 10 months later in the form of an infected executable. It loads itself as a kernel mode driver called INF.SYS. This means it gets loaded every time Windows is started and has higher than normal file security permissions. Using this new method of infection, it can access files even if the logged-on user doesn't have rights to manipulate the code. Other executable files are infected when opened. Using several undocumented NT/2000 API's, Infis bypasses the Win32 subsystem to work under Windows NT 4.0 and Windows 2000 exclusively. What is important about Infis is that it accesses NT's kernel mode, and thus has direct access to ports and hardware outside of Windows NT's control. Luckily, written as a proof-of-concept virus, it has no damage payload. It could, if it wanted to, format the hard drive, delete files, or interact with the computer hardware.
Written by a Taiwanese college student as a protest against antivirus companies, CIH (named after the virus author's initials) was the first virus that could cause computer damage so bad that it often required hardware replacement. Millions of PCs have been hit by it. South Korea alone had 240,000 PCs hit in one month. It infects PE files and places itself in unused file areas within the host. Since the virus infects PE files, it can be present on Windows NT machines, but since it uses pure Windows 95 calls, it will refuse to run. CIH will detect that it is located on a Windows NT PC, and exit quickly before letting the host file regain control.
On the 26th of any month, CIH will implement its dangerous payload. On Windows 9x machines, it will first attempt to overwrite the flash-BIOS firmware code. If successful, this will cause the PC to be unable to boot. In the past, all BIOS firmware code used to be written to the BIOS chip using a special EPROM chip device. Today, most BIOS firmware can be written and upgraded using a DOS-executed program or bootable floppy distributed by the BIOS chip maker or PC vendor. In theory the solution to corrupted firmware is easy. Rewrite the BIOS firmware code and deal with the virus's second payload routine.
If you are lucky, you can download a new firmware installer from the PC vendor or BIOS manufacturer and write a new image. Unfortunately, many times, the motherboard manufacturer and BIOS chip maker will point fingers at each other and you will be unable to get the firmware software. If that is the case, you need replacement BIOS chips or a new motherboard. Assuming your BIOS chips are able to be removed, you have to research and find out what BIOS chips the motherboard will take. BIOS chips can easily cost $70-$90. With new motherboards starting around $100, most people end up buying a new motherboard. Hence, CIH has the distinction of being the first virus to cause hardware replacement. Although it didn't really damage hardware physically, its consequences were the same.
|
Regardless of whether the CIH virus was not able to successfully overwrite the BIOS code (which is often), it then overwrites the first 1 MB of all hard drives in the system. Since it overwrites the partition table, boot sector, root directory, and FAT tables, this effectively destroys all data unless you have a data recovery tool especially written to recover from CIH damage. Steve Gibson, author of the famous SpinRite disk recovery software, wrote a program called FIX-CIH utility (you can download it from http://www.grc.com). It can often recover all data from a CIH-damaged hard drive. The partition table and boot sector can easily be reconstructed by looking at hard drive parameters and operating system types. The FAT table's erasure wasn't as permanently destructive as the virus's author had hoped, as today's large hard drives most often push the backup copy of the FAT past the first megabyte of damage. Steve's program finds the backup copy of the FAT and restores it.
The Taiwanese virus writer, Chen Ing-Hau, was caught, and in our mixed-up world, became a mini-celebrity. Serving in Taiwan's army at the time of his arrest, he eventually received an official reprimand and never earned a fine or jail time. Recently, after businesses suffered another year of damages due to CIH, Chinese courts are refiling charges and he may yet spend time in jail.
The Kriz virus infects PE files and attempts to implement a CIH-like payload on December 25, namely damaging the BIOS. Because it uses the Win32 subsystem, and not NT's native APIs, it can only be successful on 9x platforms. When first run, it copies itself to a file called KRIZED.TT6 and then modifies or creates a WININIT.INI file so that this file gets copied over KERNEL32.DLL on the next reboot. Once active, it infects various other Windows executables when certain Windows API calls are made. Whether or not it is successful in corrupting the BIOS, it will begin overwriting files on all mapped drives, floppy drives, and RAM disks. Only the better antivirus programs can repair infected PE files.
Babylonia is worth mentioning because of its unique features and the sheer number of them. Originally posted to an Internet group on Dec.3, 1999 as a Windows Help file called SERIALZ.HLP, it was supposed to be a list of valid serial numbers that could be used to install illegally copied software. Instead, it was a virus that uses the Windows Help file structure to spread. It will try to infect any .HLP or .EXE files accessed on the system by hooking the file system. Infected .HLP files activate the virus when clicked on or opened through Window's traditional help file processes. The virus modifies the entry point of .HLP files to point to a new script routine. This routine hands control over to the regular virus code (binary) that is placed at the end of the same .HLP file. The virus gets control, hooks the file system, and creates a file called BABYLONIA.EXE and executes it. The virus then copies itself as KERNEL32.EXE to the Windows system directory and registers the virus file to run at every Windows startup. KERNEL32.EXE is registered as a service and cannot be seen in the task list.
When on the Internet, the virus will attempt to connect to the virus writer's website in Japan and update the virus. The virus writer has created at least four other virus modules that the original virus downloads and executes. Using this method, the virus writer could continually update and add functionality to the virus. The AUTOEXEC.BAT file is modified and the following text added, "Win95/Babylonia by Vecna (c) 1999". The virus downloads and runs a file called IRCWORM.DAT, which, if the user is an IRC user, will then try to upload infected copies of itself to active chat channels. A module called VIRUS.TXT sends email messages to the virus author notifying him of each new infection. Lastly, the virus modifies the WSOCK32.DLL file to allow it send a copy of itself as an attachment every time the user sends an email message. All of this, and more, in 11KB of code.
Purportedly written by the same author as the Babylonia, Fono is a memory-resident virus. Originally meant to be multipartite, it has bugs in its floppy to hard drive routines. If executed on a hard drive it will install itself as a virtual device driver (FONO98.VXD), hook the file opening processes, and then write itself to the end of any PE file executed. The virus hooks interrupt 13h and successful writes to the boot sector of floppy disks. The virus disables logging to the BOOTLOG.TXT file, and then deletes the Windows floppy drive device driver (HSFLOP.PDR). The boot virus routine will load the main, larger body of the virus from its nonboot disk location, and then attempt to load the virus VxD as usual.
The virus creates .COM virus droppers and inserts them into archive file types (e.g., PKZIP, LHA, PAK, LZH, ARJ, etc.). The virus writes itself to EXE and SCR (screensaver) files. The virus also looks for Messaging Internet Relay Chat (MIRC) users (covered in Chapter 7), and attempts to use MIRC to spread itself to active channels. It creates a Trojan, which will randomly change the user's BIOS password or attempt to erase the BIOS's firmware. On top of everything else, the virus is polymorphic. Clearly, the author of these two viruses is an overachiever and one of the top virus writers today. It is not something to be proud of.
A Czech virus writer, called Prizzy, has been one of the few to push the limits of Windows virus writing. His Win95.Prizzy virus was the first to use coprocessor instructions. Coprocessor chips were used in early computers to offload complex mathematical calculations from the main processor. Most CPUs since the 486-chip have the coprocessor built-in. Intel's Pentium chips introduced another coprocessor chip, the multimedia extension (MMX) to speed up complex graphics. Polymorphic viruses found using coprocessing instructions in their calculations resulted in harder to detect viruses. While Win95.Prizzy was a very buggy virus, even unable to run on its own native Czech version of Windows 95, a new approach had been developed. Soon several working coprocessing viruses arrived, including Win32.Thorin and Win32.Legacy . Many antivirus scanners did not look for or know how to handle coprocessing instructions and their engines had to be upgraded.
Crypto is a very devious, Prizzy-created virus spread as a Trojan horse program called NOTEPAD.EXE or PBRUSH.EXE (a trick used with Win95.Prizzy). Using Microsoft's own Crypto APIs, the virus encrypts accessed .DLL files and decrypts them again when needed. The encryption key is stored in the registry at HKLM\Software\Cryptography\UserKeys\Prizzy/29A. If the virus is not in memory, the very strongly encrypted files will not be decrypted and Windows will fail. There are a few other viruses, including the One-Half DOS virus, that use a similar damage/protection routine. They make it difficult to remove the virus because doing so causes even more damage.
When executed for the first time, Crypto attaches itself to KERNEL32.DLL, loads itself from within the WIN.INI file. At boot up, it will attempt to infect 20 executables. By attaching to KERNEL32.DLL, Crypto can monitor files accessed for any reason and choose what to encrypt and decrypt. Crypto even adds itself into preexisting file archives (such as, PKZIP and ARJ). It contains anti-antivirus routines, and will look for and delete many common antivirus files. Fortunately, the Crypto virus is very buggy and crashes in most environments. Other data encrypting viruses, which do not, are likely to follow.
Infecting Windows 9x and NT machines, Bolzano, infects PE applications with .EXE or .SCR extensions. When it executes, it runs its own thread in the background while running the host program as a foreground task that produces no noticeable delay. On an NT machine, its most serious consequence is that it patches NTOSKRNL.EXE and NTLDR in such a way that all users have all rights to all files and folders. In order for the modification to take effect, an administrative user must log on to the machine, but after that everyone has full rights. The idea that a single malicious mobile code infection could easily invalidate all security permissions should scare NT administrators. Win32.FunLove copied Bolzano's techniques, but it also infects .OCX files and will actively seek to infect other computers over the network.
Unless you are seeing specific, recognizable symptoms that can only be a computer virus, always suspect a regular software or hardware issue first. However, here are the steps you should follow if you suspect a machine under your supervision has a Windows virus.
If you suspect a PC is infected with a computer virus, or any type of malicious mobile code, the first thing you want to do is unplug the PC from the network and/or Internet. This will minimize the chances that the PC will be used to spread the virus beyond its own local drives. Alternatively, in Windows 2000 you can temporarily disable network connections by right-clicking My Network Places, and then choosing Properties ->right-click Local Area Connections -> Disable. Then you can repeat the process and enable access after the threat is gone.
An antivirus scanner is an excellent tool to do a preliminary positive identification of the virus. If the antivirus scanner recognizes the virus, follow its directions, and allow it to clean the file(s) or boot area. Today's Windows scanners are designed to be installed before a virus hits. They start a preliminary scan during bootup by looking at the core files, but the main program is made to be run after Windows has fully loaded.
|
Of course, some computer viruses can hide from scanners if they are loaded into memory before the scanner. If the scanner does not recognize a computer virus infection, but you still have a strong suspicion that a virus exists, follow these steps.
Windows 2000 has a new feature called AVBOOT, or Computer Associates' InoculateIT Antivirus AVBoot Version 1.1. It is a command-line utility created by running MAKEDISK.BAT from the \VALUEADD\3RDPARTY\CA_ANTIV folder. Running MAKEDISK.BAT creates a bootable floppy diskette that will search memory and scan all local hard drives looking for MBR and boot sector viruses. Like any antivirus scanner, you must keep the signature up to date in order for it to be effective. The boot diskette includes instructions on how to update the virus signature database.
The most important thing to note with a PC having bootup problems is where the problem occurs in the boot process. Earlier, we described the different boot sequences for the different Windows platforms. If the problem or error message occurs before the Windows executable or kernel begins to load, that means the problem is related to the BIOS, hard drive boot sector, or partition table. If Windows begins to load, but then bombs quickly, the problem is with the boot sector, a kernel executable, or device driver. Lastly, if the problem occurs after Windows has booted up, but just before or after you are able to log on, you should suspect a corruption problem with one of the programs Windows automatically starts up.
For instance, if you restart a Windows NT PC and the system freezes immediately on a blank, black screen, then one of the following is corrupted: BIOS, MBR, boot record, partition table, or NTLDR. If Windows NT gets to the blue screen text mode, and begins to have problems, suspect a bad or corrupted device driver. If an NT PC gets loaded to the logon screen or desktop and then freezes, suspect a startup service or application.
If your PC won't even boot into Windows, troubleshoot the boot problem as if were not a virus-related problem (although it cannot hurt if you run a boot diskette virus scan against the hard drive at this point). Try using a boot disk and seeing if you can get to the hard drive. If you can get to the hard drive with a boot disk, it means the hard drive might have a corrupted boot sector or partition table. Run the normal recovery processes to fix those problems (most of the hard disk boot sector recovery techniques introduced in Chapter 2 should work for Windows 3.x and 9x). If any version of Windows indicates that it has a problem with 32-bit disk access, suspect a boot sector virus.
If Windows NT has a boot problem, it will usually tell you what file in the boot process is corrupted or missing, or give you a blue screen error. Record the first few lines of information on the blue screen and research the specific error message on Microsoft's Internet Knowledge Base (http://support.microsoft.com/directory/). Windows 2000's STOP errors are getting easier to read than their counterparts with lots of plain text and advice.
Running SCANDISK.EXE will check the computer for physical and logical hard drive problems. Whether or not SCANDISK finds an error doesn't rule out a virus infection. However, if the problem is simply a disk corruption problem without a virus involved, the subsequent fix can minimize the problem. If prompted to fix a problem, always create an undo disk. The CHKDSK.EXE command line program can perform some limited disk analysis to scan and repair hard drive problems in Windows 3.x, NT, and 2000. It works on both FAT and NTFS volumes in NT and 2000. Run CHKDSK with the /? parameter to get a list of all available parameters. CHKDSK /F is the same process Windows NT and 2000 goes through during every bootup to determine that the disk logical partitions are functional. The CHKDSK /F routine, on FAT volumes, will analyze the FAT tables and replace them with the FAT copy if corruption is detected.
Windows 9x will not allow CHKDSK to check the hard drive or fix disk problems. Windows NT will not allow CHKDSK to run while the disk volumes are in use, but will schedule a CHKDSK run at the next startup. Windows 2000's CHKDSK will allow you to dismount the volume, causing all open files not to be saved, and then run (without rebooting).
|
If you have Windows 9x or Windows 2000, boot to Safe mode to minimize the number of programs and processes in memory. Safe mode can be accessed by choosing F8 during the Windows boot process. Among other things, Safe mode bypasses programs loaded from the run areas of the registry; a place where viruses and Trojans love to load. Unfortunately, neither Windows 3.x or earlier versions of NT have this functionality.
Search for EXE and DLL files with new file creation or modification dates. On Windows 9x and NT, use Start ->Find ->Files or Folders, in Windows ME or 2000 it is Start ->Search ->For Files or Folders. I tell Windows to look for all *.EXE or *.DLL files and I use the Date tab to narrow the files found to those modified recently.
If you have Windows ME, look at xFP's history log file, SPLOG.TXT, to see if there is a recent history of protected system files that were modified or deleted. Windows 2000 records xFP activities in the System log.
While xFP may have protected particular files, a large number of unsuccessful attempts may mean a virus has been successful with nonprotected files. In Windows NT or 2000, you might consider auditing file object accesses. In User Manager (for Domains), choose Policies ->Audit ->Audit These Events and enable Success and Failure for File and Object Access. All file and object accesses will begin being tracked and reported in the Security log of the Event Viewer. This is not my favorite troubleshooting tool, because what you'll see in the log is tough to understand even when you're an expert (it reads a bit better in Windows 2000). It takes awhile to get accustomed to Microsoft's security auditing, but if you study the detail enough, you will get a sense if an unknown program is modifying your system.
It is not unusual to see recently modified EXE or DLL files, even on a clean system, if new programs or downloads have been installed. And different Windows programs, unfortunately, store and update information within their own programming files. You should look for blatant signs of virus modification, such as many modified EXE files within the same folder, or dozens of newly modified program files located in different directories, but all modified on the same date. And, of course, your core Windows executables such as KERNEL32.DLL and GDI.EXE should not be newly modified.
If I find newly modified EXE files that are not being detected by the scanner as infected, I might run a few of them to get them in memory (if they will start). Then, I will start other programs without newly modified dates as bait, use them, close them, and then look to see if even more modified files turn up. If you find more files with new modification dates, you can quickly assume that you have a virus.
If you find any suspicious newly modified files, you should open them with an ACSII editor and take a quick look. Although viruses are frequently encrypted, often virus writers leave clues within the coding that are clearly visible as text. Seeing dubious words and phrases (such as FileFind, FileDelete, *.EXE, Gotcha, Virus Lab 1.1,or Kill) should be a quick indication that the file is malicious.
You can see text references to finding files and a command used to save the file's modification time and date. The file also contains references to NTLDR and NTOSKRNL.EXE (not shown), both of which have little reason to be named in a legitimate file. Also, early on in the file there are text references to .EXE and .SCR files, deleting files, creating files, and the name Bolzano. Even if I didn't know the file was a virus, I would be somewhat suspicious now. It is not unusual to find some legitimate files that search for particular types of files, as they can appear in any program that needs to create and manipulate files. But if I see enough text to indicate that a suspicious executable is looking for or deleting files, I'll look for other text strings that would not be present. For example, when examining a client's PC and finding suspicious executables, I saw the same sorts of text strings that are displayed in Figure 4-1. I began looking even closer at the files and found a text string that said V5I%R#U@3S!!. Maybe it was just luck, but I was able to pick up the word VIRUS embedded in the string, and then I knew that, the file was infected with a newly encrypted version of the Win95.Marburg virus.
Using SYSEDIT, REGEDIT, MSCONFIG, MSINFO32 or DRWATSON, look for untrusted programs in the startup regions of the boot process. This means checking AUTOEXEC.BAT, CONFIG.SYS, WINSTART.BAT, DOSSTART.BAT, Startup Group, Registry, Win.INI, and SYSTEM.INI for autostarting programs. MSINFO32.EXE is a great troubleshooting utility. Not only will it list all the hooked interrupts, drives, devices, and programs loaded, but it displays all startup programs (Software Environment ->Startup Programs). MSINFO32 gives you a wealth of information about your system. Of course, this means you have to be familiar with what your machine is normally running in the first place. The Tools menu option in MSINFO32 is full of shortcuts to other troubleshooting utilities, like Version Conflict Manager, Registry Checker, Signature Verification Tool, System File Checker, Dr. Watson, and Scandisk. The use of Dr. Watson is covered in more detail in Chapter 6.
In the Windows 9x environment, computer viruses often load as VxD drivers. You can start Windows 9x and press F8 during the startup and choose to create a BOOTLOG.TXT file. This file can be examined after Windows has booted and reveal something similar to example below. It contains a list of the device drivers and processes, and whether they were successful or failed.
[0007FF34] Loading Device = C:\WinDOWS\HIMEM.SYS
(Logo disabled)
[0007FF37] LoadSuccess = C:\WinDOWS\HIMEM.SYS
[0007FF48] Loading Device = C:\WinDOWS\DBLBUFF.SYS
[0007FF4A] LoadSuccess = C:\WinDOWS\DBLBUFF.SYS
[0007FF57] Loading Device = C:\WinDOWS\IFSHLP.SYS
[0007FF58] LoadSuccess = C:\WinDOWS\IFSHLP.SYS
[0007FF82] C:\PROGRA~1\NORTON~1\NAVDX.EXE[0007FF82] starting
[00080170] Loading Vxd = VMM
[00080170] LoadSuccess = VMM
[00080170] Loading Vxd = C:\WinDOWS\SMARTDRV.EXE
[00080172] LoadSuccess = C:\WinDOWS\SMARTDRV.EXE
[000801A2] Loading Vxd = vnetsup.vxd
[000801A2] LoadSuccess = vnetsup.vxd
[000801A7] Loading Vxd = ndis.vxd
[000801A9] LoadSuccess = ndis.vxd
[000801AA] Loading Vxd = ndis2sup.vxd
[000801AA] LoadFailed = ndis2sup.vxd
[000801AE] Loading Vxd = JAVASUP.VXD
[000801AF] LoadSuccess = JAVASUP.VXD
[000801AF] Loading Vxd = CONFIGMG
[000801AF] LoadSuccess = CONFIGMG
[000801AF] Loading Vxd = NTKERN
[000801AF] LoadSuccess = NTKERN
Although the file will list hundreds of names, look for ones that were listed with new modification dates from Step 6, or for the ones that failed to load. Do a quick search for the word Fail to locate all instances of failure. Do research on the Internet for new VxDs or ones that have failed. If you can't identify it, temporarily rename it, and reboot. See if the suspicious behavior goes away.
Viruses can load in Windows NT as SYS drivers. You can start Windows NT in a special diagnostic mode that shows the different device drivers loading. To do so, edit the BOOT.INI to add the /SOS switch at the end of the line which starts NTOSKRNL.EXE. In Windows 98, choose F8 while it boots and choose Single Step mode. You can see the individual kernel and device drivers as they load (or don't load). Although you don't necessarily have to memorize what are the correct drivers to be loading at boot time (in fact it is nearly impossible), you should keep an eye out for strange-sounding names or names that are misspelled by one letter (a common virus trick).
As we discussed before, many computer viruses inadvertently disable the 32-bit disk and memory management processes in Windows. In Windows 9x, choose Start ->Settings ->Control Panel ->System ->Performance. Note any performance degradations and suspect virus activity for any downgrades.
Certainly, if you receive unexpected notification messages from Windows ME's System File Protection or Windows 2000's Windows File Protection, consider the possibility of malicious mobile code. Especially, if it happens after running an unexpected executable sent to you in email.
At this point, if you don't see anything suspicious, consider treating the problem as a nonmalicious code event. You can, of course, call a malicious code expert to verify or send suspect files to an antivirus company via the Internet. They will usually look at individual files for free and let you know if it contains malicious mobile code.The first step is the same for any computer virus, no matter what the type. After the first step, the type of virus determines subsequent steps.
Always try using a commercial antivirus scanner to remove any virus. In some cases, like NTFS volumes, you may need to boot to the volume first, and then run the antivirus scanner. In Windows 2000, AVBOOT, is a good, no frills boot virus remover if kept up to date. Steps after this point assume you don't have an antivirus scanner or it did not recognize and remove the virus.
Removing most boot and MBR viruses involves many of the same steps as presented in Chapter 2. The hardest part in a Windows world is to determine what type of boot floppy you have to use to clean the virus and to restore the boot areas to their clean state. Each of the different Windows file systems, FAT, VFAT, FAT32, and NTFS, have their own boot files.
First, you need to boot with a known, clean, write-protected diskette that will recognize the disk partition. This means you can't use a FAT32 boot disk on a FAT volume, or a FAT disk on a NTFS partition, and vice versa.
|
Making a 3.x or 9x boot
floppy
For Windows 3.x and Windows 9x systems with FAT and VFAT, you can create a boot disk by using the SYS A: or FORMAT A: /S at the command-line prompt. You can also use My Computer ->right-click Floppy A: ->Format and choose Copy System files, in Windows 9x to accomplish the same thing. I then copy SYS.COM, FORMAT.EXE, and FDISK.EXE to the disk to use in troubleshooting.
Making a Windows 98 Fat32
emergency boot floppy
The Windows 98 install CD-ROM contains a folder called \TOOLS\MTSUTIL\FAT32EBD. It contains a file, FAT32EBD.EXE, that will create a FAT32 Emergency Boot Floppy diskette. You can also make a more comprehensive boot floppy in Windows 9x by making a Startup Diskette during the install process. You can make one at anytime by choosing Start ->Settings ->Control Panel ->Add/Remove Programs ->Startup. Like the other boot disk options talked about in this section, make sure to write-protect the diskette to prevent computer virus infection.
Making a Windows NT boot
floppy
Format a floppy disk on a Windows NT computer. Copy NTLDR, BOOT.INI, NTDETECT.COM, and NTBOOTDD.SYS (for BIOS-disabled SCSI adapter) to floppy. If needed, modify BOOT.INI so that ARC path (disk controller, disk drive, partition) points to system partition on NT computer. After it is created, you can use the floppy to start Windows NT or 2000, and bypass the initially corrupted boot files. Only the boot files necessary to reach the NT partition are loaded off the boot floppy. The emergency boot process loads other files directly off the hard drive. If NTOSKRNL.EXE or other boot files on the hard drive are corrupt, you will need to run NT's repair option to fix.
Using SYS and FDISK
With Windows 3.x and 9x you can use SYS C: off a clean boot floppy to restore the boot sector, or FDISK /MBR to restore the master boot record. The same rules of when and when not to run this command that were presented in Chapter 2 apply. Don't run FDISK /MBR unless you know doing so will not harm the disk.
|
Using ERD in Windows NT
Oftentimes using an Emergency Repair Disk (ERD) is the only way to recover a corrupted NT boot or system files. An ERD must have been created before the infection occurred (using RDISK.EXE /S in NT 4.0). Put your NT installation CD-ROM in the drive and boot up using the installation setup diskettes. Select R to repair the NT installation. Choose Inspect boot sector and Restore Startup Environment. NT's repair option will prompt you for your ERD disk when appropriate. If you have a boot or MBR virus, one of these cleaning techniques should remove the malicious code.
|
Using Windows 2000 Recovery
Console
You can replace a corrupted MBR or boot sector using 2000's new Recovery Console. Start the computer from the Windows 2000 Setup CD-ROM or floppy diskettes. Press Enter at the Setup Notification screen, then R to repair, then C to access the Recovery Console. It will ask you to select the current valid 2000 installation, and prompt you for the local administrator's password. You will then be able to type in commands in the console window. Type FIXMBR to overwrite the master boot code with a new copy or type FIXBOOT to replace the boot sector of the hard drive.
DiskProbe and DiskSave