System Disinfection
Jong Purisima and Vincent Tiu, TrendLabs
The prevalence of malware that target systems as a whole, rather than the traditional 'files in a system', has risen in the past few years. We have seen numerous methods of exploitation, while some malware programs combine the traditional file infections with system infections that can result in catastrophic problems.
With these changes, additional technology has been implemented to provide better detection for all the components of contemporary malware. As new exploits and techniques are discovered, the ability to support detection of their malicious byproducts is all the more vital.
System Disinfection
As the battle for malware detection continues, a new one has emerged: system disinfection.
For a user, the problem with an infected system does not end with detection of the malware. Detection merely provides a reference point for restoring the system to its accepted functional state and, in general, more time will be invested in disinfecting it.
System disinfection can be defined as 'restoring a system to an acceptable and working state'. Of course, it is possible to carry out a 'full' restoration, however, the diversity of systems and system configurations makes this very difficult. The aim of disinfection is to enable the system to work as it did in its pre-infected state, without having to perform any re-installation.
Since Windows is currently the most commonly attacked system, it will be the focus of this article.
Detection of an Infected System
A very important part of system disinfection is the correct identification of an infected system. When a scanner detects a malware program that is supposedly a system infector, it does not necessarily follow that the system is already infected. Detection of such a program should, however, be used as a basis for carrying out further checks.
The opposite is also true: if a scanner has not detected any system-infecting malware, it does not necessarily mean that the system is not infected.
In order to understand the underlying concepts of disinfection, infection should be defined. Currently there are two types of system infection. The first are Memory-File- Registry infectors. These use any combination of the three (memory, file and Registry) in order to take control of a system. To check for infection of this type, a memory scanner, file scanner and a Registry scanner may be used.
The second type of system infector uses memory only - a good example is CodeRed. This type has no physical trace (in a file or in the Registry) and is a little harder to identify.
In a similar manner to its file counterparts, misidentifying a system as infected can cause problems, since attempting to clean a system that is already clean can lead to further damages - caution is advised.
Once a system has been identified as infected, the disinfection process can begin.
Memory
A critical aspect of system disinfection is removing the malware from memory. This is critical since the operating system will not allow the removal of files if a process or service is still resident in memory. Furthermore, removing the malware from memory removes the malware program's control over the system, thus preventing it, for example, from restoring its physical counterpart or re-infecting.
Memory residence can be classified as either a process or a service. Processes should be killed, while services should be stopped. To kill a process, we can use the KillProcess() APIs, while, to stop a service, we can use the SCManager() APIs.
Memory cleaning should start with a memory scan to identify where the malware resides. Once its location is identified, based on the malware analysis, you can define whether it is a process or a service and kill the process or stop the service accordingly.
It is good practice to re-scan the memory after supposedly removing the malware from memory. This is to make sure that the malicious program has not spawned another process or service before you have killed or stopped it - for example, the Bymer.A worm spawns multiple copies of itself in memory and then executes them one at a time.
Another technique for remaining resident in memory has been seen in Magistr.A, which attaches itself as a thread to the explorer.exe process. Yet another method is to exploit buffer overflow, as in the case of CodeRed which exploited the buffer overflow in IIS to reside in the same process as its victim. In both cases, the thread or the process should be terminated in memory to stop the malicious program and, if necessary, restart the original service. Remember that all processes and services started by the malware should be killed or stopped in order to ensure that the program is no longer resident in memory.
Registry
Another method of taking control of a system is to add or modify Registry entries. Malware programs often use this method together with a file which is run upon system startup as the result of adding a link to it in the AutoRun Registry folders.
Cleaning up the Registry entries should always be malwarespecific. We must perform the exact reverse of the changes the malware has made in the Registry, which should be as simple as removing what was added or restoring what was modified. Removing and restoring Registry entries can be done using the Registry APIs.
Another method that malware programs use to make sure that they will be executed is the modification of entries inside the HKEY_CLASSES_ROOT folder in the Registry. Inside this folder, the malware can select any extension, which it uses to trigger itself when files with this extension are opened. A good example is the worm Yaha.A, which modifies the default Registry entry for .EXE files so that, whenever files with EXE extensions are executed, Yaha.A is executed first. Restoring the original default value in the Registry will clean this.
Some malicious programs try to modify the Registry entries with the intention not only of gaining control over systems, but also of compromising network security and rendering infected systems more vulnerable to Trojan attacks. An example is Nimda.A, which modifies the Registry to share all drives from C to Z as well as adding the user 'guest' to the 'administrators' group on NT systems. Again, restoring the default value on those entries that have been modified should clean up the system.
Other malicious programs attempt to modify the default home page, Office Macro Warnings, Internet browser's security settings and other miscellaneous settings that are contained within the Registry. Since restoring these to their previous value would be difficult, unless the old values have been recorded, restoring them to their default values should be sufficient to allow the system to function in its clean state.
Files
A more prevalent method in system infection is the use of a physical file, paired with a modification to the Registry. This modification results in the file being executed at startup or during any other special event. In either case, the 'dropped file' must be removed as part of the system cleanup.
Most AV scanners should be able to remove a dropped file by selecting 'delete' as the post-detection action. However, if the file is protected by memory residency or other special techniques, it may not be straightforward to accomplish such a task. This is why cleaning the memory and the Registry must be carried out first, removing any links which might prevent the file from being deleted or modified.
Some malware programs try to append themselves to system files in order to gain control of systems. Such is the case for MTX.A, which modifies the system file WSOCK32.DLL in order to utilize its mail routines. Again, most AV scanners should be able to clean the newly-infected file, but may have some problems with sharing violations. In this case, system disinfection would be the same as traditional file cleaning techniques, but must be executed once the link mentioned above has been broken.
The worm Ska.A, on the other hand, renames the existing WSOCK32.DLL to WSOCK32.SKA and then replaces WSOCK32.DLL with itself. In cases like this, deleting the Ska.A detected file (WSOCK32.DLL) is one part of the cleaning process, and restoring the original file's preinfected name completes the process.
Of course, there are other file-related malware modifications. For example, modifying Windows configuration files such as WIN.INI, SYSTEM.INI and Autoexec.bat by adding a link to a malware file. In these cases, the system configuration files should be cleaned after the physical files they link to have been deleted.
Other system modifications, like planting backdoors and security policy compromises introduced by malware programs should be disinfected as well. FunLove, for example, will patch NTOSKRNL.EXE to disable the system's access rights checking and at the same time patches NTLDR, forcing it to skip the integrity checking of NTOSKRNL.EXE. These modifications must be reversed.
As with Registry cleaning, additions or changes to system configuration files should be deleted or restored to their default values (if the original values can no longer be found).
Inoculation
After an infected system has been cleaned, it would be advantageous to introduce some means of preventing reinfection. A good example is the case of FunLove, in which a dummy file or directory named 'FLCSS.EXE' can be added in the Windows System directory. FunLove will cease to infect any system that has this entry in the System folder of Windows. Another good example is to put a dummy file or folder named 'NOTWORM' in the C drive. This renders CodeRed.A dormant - its payload and replication mechanisms will not be triggered.
However, such preventive measures should be considered only during crisis and should not be used as a sole method of combating re-infection: future variants may not use the dummy files or folders that you have positioned.
However, this is a good opportunity to inform the user of exploit patches that can combat the re-infection of their systems. For example, using the patch provided in Microsoft Security Bulletin MS01-033 would block any IIS vulnerability exploited by CodeRed. Remember that the use of security patches to prevent infection in the first place is a much better solution than the workarounds. Security patches should be used whenever possible.
Fix Tools
Standalone fix tools have become accepted solutions for system disinfection during alerts or outbreaks. Advantages of fix tools are that they are small (most would fit on a standard 1.44 MB floppy disk), can be downloaded quickly, and can be executed on their own.
A downside, however, is that the tools are malware-specific, which means that there is one tool for every malware program or family of malware programs.
Another major drawback of using this approach is that it can not be deployed from a central location, which means that if an enterprise of 10,000 infected machines is to be cleaned, you may need to deploy the fix tool on each of those machines individually.
Furthermore, since most of these fix tools do not have their own fully-developed scanners, false positives in identifying infected files or an infected memory may occur. As mentioned previously, cleaning an uninfected file or memory may result in even more catastrophic damages.
Other Problems
One current problem of system disinfection is that sometimes a system reboot is required to remove traces of the malware totally. This should cause little concern on desktop environments but may be a big issue when it comes to servers and production-related machines.
The reliability of disinfection should also be considered. Disinfection methods should be able to work in all Windows flavours, in all language versions and should not affect any other software installed on the system.
Conclusion
It would be safe to say that future system disinfection techniques will depend on the behaviour of future malware. However, improvements to current techniques can be made in the following areas:
Reliability in identifying the infection.
Minimizing server downtime during infection cleanup.
Expandability and manageability of disinfection tools.
Deployment of tools and centralization, within largescale infections.
Vulnerability assessment tools which provide information on possible malware entry points.
Integration of these tools into AV products as an additional solution.
And the battle rages on ...