The Antivirus Defense-in-Depth Guide

On This Page

	Introduction
	Step 1: Infection Confirmation
	Step 2: Incident Response
	Step 3: Malware Analysis
	Step 4: System Recovery
	Step 5: Post Recovery Steps
	Summary

Introduction

This chapter presents a detailed set of considerations that you can use to identify a malware infection or outbreak, contain it, and then remedy the effects it may have on the infected systems in your environment. The need for a consistent, straightforward approach to incident response and recovery cannot be understated; malware incidents tend to create a sense of urgency that is not conducive to instituting well thought out procedures that will remain effective and successful in the long term.

One additional important point needs to be made. As malware attacks have grown in complexity using many different payloads, no single process for removing it from your systems is any longer universally applicable. Each different malware attack is likely to require its own remediation. However, this does not lessen the value in defining a process for identifying, containing, and recovering from an attack that should remain consistent.

A high-level view of the steps in a malware outbreak recovery process includes:

Top of page

Step 1: Infection Confirmation

The ability to quickly determine whether a system has been infected will prove invaluable in your organization's ability to minimize the impact of infections. By quickly confirming an infection and identifying its suspect characteristics, the spread of the infection and its impact on your users can be reduced.

There are many different types of computer malfunctions that can be mistaken for virus-like behavior. Upon receiving a phone call or e-mail from a user that states "I think my system has a virus," the support staff must first determine if the behavior is likely to be caused by some kind of malicious code. The following list provides some examples of typical symptoms a user may report as "virus-like" behavior:

Observations and feedback from your users is critical, because they will likely be the first to notice unusual activity. As the speed of malware outbreaks continues to increase, the window of time between the initial infection and the availability of an effective defense becomes increasingly important. Since most infections will occur during this period, your organization's ability to quickly identify and confirm an infection is crucial to minimizing both the spread of an outbreak and the damage it can cause.

The following section outlines a series of steps that will enable you to more quickly confirm if unusual behavior is indeed a malware attack or outbreak.

If a new type of malware infects a system, the user of that system may well be the first to notice unusual behavior. As discussed in Chapter 3, "Antivirus Defense in Depth" in this guide, there is generally a delay from the time new malware is released to the point an antivirus scanning application will be updated to detect and counteract it. The best way of providing an early warning system is to educate users to recognize the signs of a possible malware attack, and provide them with a fast communications link to report them as soon as possible.

Infection Reporting

After a call has been received or an alert has been generated about a possible new malware attack, it is usually beneficial for the Helpdesk to have a defined process for determining as quickly as possible whether the alert concerns a new attack. The following flow chart illustrates the major steps in this process:

Figure 4.1 The malware infection reporting process

Unusual Activity Reporting

The following questions should be used to determine if the unusual activity that prompted the alert is likely a new malware attack. This guide makes the assumption that these questions should be directed towards a non-technical user by a member of the IT Helpdesk in your organization.

Gathering the Basic Information

The initial questions should be designed to produce answers that will help determine as quickly as possible the true nature of the alert, and the likelihood of it being a new malware attack. You can use the following sample questions as the starting point for this process; they should be modified to meet the requirements of your organization:

This last question is important, as previous attacks often create vulnerabilities that can lead to subsequent attacks unless they are fixed. If the answer to this question is "Yes," consider asking the following additional questions:

Evaluating the Data

After the answers to these questions have been gathered, the support technician should evaluate the collected data against the following set of questions to help determine if a malware attack is a likely cause of the report:

Finally, a check should be made with external antivirus sources (identified in the "Proactive Internal Communications" section of Chapter 3, "Antivirus Defense in Depth" in this guide) to determine if this report matches some existing virus or worm alert.

Gathering the Details

At this point it may be possible to determine if a new malware attack is the likely cause of the problem. If not, a higher level of technical information may be required and a support technician may need to physically visit (or if possible, gain remote control to) the suspect system. You can use the following sample technical questions to gather more detailed information and determine, categorically, if the system has been attacked by a hacker or malicious code:

Unusual Activity Response

After the initial information has been gathered and used to determine the nature of the alert, it should be possible for the Helpdesk to make a decision about whether a false alarm, hoax, or real malware attack has occurred.

Creating a fake malware report is far easier than developing a virus or worm, which unfortunately assures the creation of many false malware alerts. These hoaxes and the calls and warnings they generate waste considerable time and money. Hoaxes also annoy your users and tend to make them question the value of reporting potential attacks. The following considerations should be made to ensure the alert is correctly handled.

At this point, the role of the Helpdesk is complete. Responsibility for the outbreak will move to the incident response process, and the members of the Computer Security Incident Response Team (CSIRT) will need to be notified.

Top of page

Step 2: Incident Response

As discussed in Chapter 3, "Antivirus Defense in Depth" in this guide, the CSIRT will need to convene an emergency meeting as soon as possible to help organize the next stage of the organization's incident response process. For more detailed explanations of how to create an incident response team and the processes for security and disaster recovery in general, refer to the same chapter in this guide.

For the purposes of this guide, it is assumed that the CSIRT is in place. The first goal of the team at this point should be to determine the immediate outbreak control mechanism. The following section provides information that will help determine the options for this mechanism and its components.

Emergency Outbreak Control

After the malware attack has been confirmed, the first step in controlling the outbreak is to ensure that the infected computers are isolated from other devices. Ensuring the isolation of infected computers is essential, because it prevents their ability to spread the malicious code. There are a number of different mechanisms for achieving this isolation that will all have an impact on the normal operations of the organization.

Important: If you believe your organization will be pursuing criminal or civil litigation, Microsoft recommends consulting with your organization's legal representatives before taking further steps.

If the outbreak has been detected in the antivirus community, use the guidance provided by your antivirus vendor(s) to help you determine the severity of the outbreak.

If the outbreak is currently unknown in the wider antivirus community, you should report the incident to your antivirus vendor(s) as soon as possible. They may request that you send them examples of the malware in a compressed and password-protected file to allow them to analyze it. The process of finding these examples is not always straightforward and should, ideally, be prepared for in advance. See the section "Step 3: Malware Analysis" of this chapter for guidance in preparing malware examples.

The next course of action that should be followed is to contain the immediate attack. There are three basic options for you to consider:

There are many more detailed technical steps that could be taken, such as monitoring the network to try and identify the network ports and IP addresses involved in the attack. However, if the detailed analysis of the malware has not been completed, the risk of missing an attack vector that could lead to wider infection is significant. The only mechanism available to your organization to help you determine whether this risk is acceptable would be a completed security risk assessment report. This report would enable you to determine the risks involved in failing to stop an attack and potentially infecting or unwittingly being used to launch an attack on customers or partner organizations. If you have not completed this risk analysis prior to an attack, it is recommended that your organization err on the side of caution and minimize the possibility of spreading an attack by selecting the highest level of isolation possible.

The options listed here are guidelines only. Your specific course of action may be different depending on such factors as business needs, locale, impact, severity, and other factors that may apply only to your organization and the circumstances of the outbreak.

Preparing for Recovery

After the outbreak control mechanism has been activated, you should start the process of active recovery. The overall aim of the recovery process is to ensure that the following goals are achieved:

Unfortunately, the first two goals require a "rapid fix" approach while the remaining three require time to be spent in gathering information about the attack to fully understand it. To satisfy both — that is, to quickly resolve the issue and still capture all the relevant data required — consider using the process shown in the following figure. This process is designed to ensure an infected system is released for recovery as quickly as possible while at the same time making sure the required forensics data is not lost. This data is important, because your organization will use it to determine if the recovered systems will be safe from future attack, and it will also serve as evidence if future legal action is pursued.

The processes of system recovery and virus analysis should be run as parallel activities to ensure the fastest possible recovery time.

Figure 4.2 Recovery steps before analysis
See full-sized image

The fastest way to allow all systems to be recovered is to determine if one infected system can be used for analysis. If so, this system should be quarantined and analyzed. (Guidance on this analysis process is provided in the following "Step 3: Malware Analysis" section of this chapter.) If quarantine and analysis are not possible, the next best option is to create a clone of the system using some type of imaging software. If this option is available, you can take an image of the system, release the original computer for recovery, and then create a clone system.

In cases where evidence will be gathered or more detailed analysis can be undertaken, it is especially important that affected computers are imaged as soon as possible (before remediation activities begin) so that the infection can be identified, triaged, and handled in the most expedient and appropriate manner.

Finally, if imaging is not possible a set of minimum forensic data should be gathered before the system is released for recovery. Ideally, your organization's security team should develop and maintain some form of incident response toolkit. You can use such a toolkit to gather both volatile and nonvolatile system data that will be useful for providing system forensic data. This toolkit could be a subset of a more complete malware analysis toolkit that will be used in the next section of this chapter to uncover and document all elements of the malware. However, the key differentiator of an incident response toolkit is that it should capture the minimum level of system information required in the fastest possible time to allow the system to be released for recovery as soon as possible.

Top of page

Step 3: Malware Analysis

As soon as the spread of the malware attack has been contained, it is important to take some time to understand the nature of the outbreak and to perform a more detailed analysis of the malware. Failure to carry out this step can increase the likelihood of re-infection; failure to understand how the malware works will make it impossible to ensure that systems are cleaned and secured against further attacks.

Ideally, the malware analysis would be carried out by a member of the security team with a dedicated set of applications and utilities that can be used to gather the required information in as automated a fashion as possible. The following steps will help understand the nature of the attack.

Examine the Operating System Elements

Try to determine which operating system files were introduced or modified by the attack. As part of this analysis, look for changes in the following areas:

Techniques that you can use for checking these operating system elements will be explained in the following sections.

Checking for Active Processes and Services

Infected systems are likely to have had new processes introduced into their memory.

The use of specialized process listing tools, such as PsTools and the Process Explorer freeware program is recommended to provide a more user friendly interface. These tools are available from the Sysinternals Web site at http://www.sysinternals.com/, and make it possible to see not only the path to the image file but also the process tree.

To help minimize the number of entries in the process list and therefore help in the identification of any rogue processes, you should close all valid applications and any valid background applications such as Instant Messenger, e-mail monitors, or third-party utilities that stay memory resident.

If a specialized tool is not available, the Windows Task Manager tool in all Microsoft Windows systems can be used as a quick check for active processes running on the system. However, because Task Manager does not show the path to the image that launched the process, it would be impossible to determine whether a malware attack launched as "svrhost" would be a legitimate process or not.

Complete the following steps to analyze the active processes using Task Manager:

To analyze active processes on a computer running Windows

You can sort the order of the columns by clicking any column title. Use this sorting method for each of the listed columns and determine which processes are using which resources.

Note: To obtain a printout of this list for future reference, make Process Explorer or the Windows Task Manager the active window and press ALT+PRT SCRN on the keyboard. A screen shot of the list will be created in the computer's clipboard, which can be pasted into the Windows Paint application or Microsoft Word and printed.

The following figure shows the process details of the Blaster worm as an active process in the Microsoft Windows 2000 Server Task Manager.

Figure 4.3 The Windows 2000 Task Manager showing the active Blaster worm process
See full-sized image

Note: Some malware may try and block Task Manager from starting as a form of defense. If this is the case, the Tasklist command line utility can be used on Microsoft Windows XP and Windows Server™ 2003 computers (or the TList command line utility on Windows 2000 computers) to generate a simple text file list that can be copied to removable media for further analysis. Use the following command line syntax to generate a text file containing a list of all active processes:

tasklist /v >TaskList.txt

This command line will create a file called TaskList.txt in the current working directory.

Use the following tips to check processes on a computer that is suspected of running some form of malware:

In addition to the msblast.exe process displayed in the previous figure, examples of other possibly suspicious processes include:

Note:  This list is provided to illustrate examples of the type of file names that have been used in the past. Almost every attack will use a different name so it is important to be able to spot the unusual entries in the task list and to understand the naming techniques used by the malware writers.

Checking the Startup Folders

It is possible that the malware has attempted to launch itself by modifying the startup folders of the system.

Note: The precise path for these folders will change depending on the operating system being analyzed. The following information is for operating systems running Windows XP, Windows Server 2003, or Windows 2000.

There are two areas of the startup folder that you should check. The first is the All Users folder, which can be found at the following default location:

C:\Documents and Settings\All Users\Start Menu

The second area is the user profile path for the currently logged on account, although it is important to check all profiles that have been created on the system and not just the account that is currently logged on. You will find this information at C:\Documents and Settings\<UserName>\Start Menu, where <UserName> is the logon ID of the defined users on the system being inspected.

Note: On Microsoft Windows 95 and Windows 98 systems it is possible for malware to rename the startup folder. For more information about this topic, see Microsoft Knowledge Base article "141900: Folder Other Than StartUp Launches Programs" on Microsoft.com at: http://support.microsoft.com/?kbid=141900

Check each of the entries in each startup folder to ensure no malware is attempting to start during a system startup.

Checking for Scheduled Applications

It is also possible (although rarer) that malware may try and use the Windows scheduler service to launch an unauthorized application. To confirm that this is not the case, a simple check of the scheduler queue should be performed by completing the following steps:

To check the scheduler queue

Executing this command will create a text file in the root of the C: drive, which should be moved to a removable disk for future analysis. Review the text file to determine if any unauthorized applications are scheduled in the queue.

Once a complete analysis of the active and scheduled processes has been completed, it may be possible to identify the process or processes that were introduced by the attack. Once these have been documented, a system reboot should be performed and the analysis repeated to determine if the attack managed to compromise other areas of the system and allowed the rogue processes to be launched at startup. If so, analysis of the system's boot files and registry will have to be completed to find the mechanism used to maintain the rogue process or processes.

Analyzing the Local Registry

Because the completed system registry is a large and complex data store, it may be beneficial to create a copy of the entire system registry for a detailed analysis after the attack recovery process has been completed.

The Backup utility that is included with all versions of Windows can be used to back up and restore the entire registry. If you already use Backup to regularly back up your hard disk, you can easily include the registry in these backups. To back up the registry with the Backup application, select SystemState when you select the drives, files, and folders that you want to include in a backup set.

As the System State includes other system-specific information as well as the registry, these backup files can be hundreds of megabytes in size. Another option is to use the registry editor utilities that also come with all versions of Windows. These utilities are ideally suited to make copies of the registry. Windows XP and Windows Server 2003 have two registry editor tools, Regedit.exe and the command line tool Reg.exe.

Note: The Windows 2000 and Windows NT operating systems use Regedt32.exe and require the RegBack.exeand RegRest.exe Resource Kit tools to provide the same functionality as Regedit.exe and Reg.exe. For more information about these tools, see the Backing up and Restoring the Windows 2000 Registry page of the Windows 2000 Resource Kit on Microsoft.com at:
http://www.microsoft.com/windows2000/techinfo/reskit/en-us/regentry/RegistryBackup.asp.

To make a backup copy of the registry using Regedit

Detailed information on how to use Regedit.exe and Reg.exe can be found at the Registry Reference for Windows Server 2003 page of the Windows Server 2003 deployment guide at:
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/depkit/7CF151B7-03F3-45E9-9EDB-ECE32BA6A75F.mspx.

Important: Because this disk will be exposed to the malware, take great care to ensure that it is not exposed to other systems until an effective method of control has been established.

Once a successful backup has been taken of the registry, check the following areas for any unusual file references:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs 
  HKEY_LOCAL_MACHINE\System\ControlSet001\Control\Session Manager\KnownDLLs 
  HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Current Version\Run 
  HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Current Version\RunOnce 
  HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Current Version\RunOnceEx 
  HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices 
  HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows ("run=" 
    line) 
  HKEY_CURRENT_USER\Software\Microsoft\Windows\Current Version\Run 
  HKEY_CURRENT_USER\Software\Microsoft\Windows\Current Version\RunOnce 
  HKEY_CURRENT_USER\Software\Microsoft\Windows\Current Version\RunOnceEx 
  HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServices 
  HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows ("run=" 
    value)

These areas of the registry are often targeted by malicious code because they allow the malware to launch itself at system startup. For example, the W32@.Mydoom.G@mm worm added the following value:

"(Default)" = "%System%\<random_filename>"

to the following registry keys:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run 
  HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run

Another area that has recently been targeted is the following key:

HKEY_CLASSES_ROOT\CLSID\{E6FB5E20-DE35-11CF-9C87-00AA005127ED}\InProcServer32

This key controls the .dll files that Microsoft Internet Explorer (Explorer.exe) loads. For example, the Mydoom worm and its variants would add an entry here to load a .dll file that would open a vulnerability and allow a backdoor attack.

The W32.Netsky.D@mm worm would delete this key and the following keys altogether:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\PINF 
  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WksPatch

Another tool that can be extremely useful for analyzing Windows XP and Windows Server 2003 based systems is the System Configuration Utility. Using this tool it is possible to view and modify a variety of startup and configuration information as well as review the current services list. More information on using this tool can be found in the Windows XP Professional Resource Kit. This information is also available online on the System Configuration Utility page on Microsoft.com at:
http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/prmb_tol_dxth.asp

Note:  You must be logged on as an administrator or a member of the Administrators group in order to use System Configuration Utility.

Checking for Malware and Corrupted Files

Most malware will modify one or more files on a computer's hard disk, and finding which ones have been affected may be a difficult process. If the system was created from an image, you may be able to compare the infected system directly with a fresh system created from this image.

If this option is not available, another method to determine which files have been changed is to use a system-wide search of all files that have changed since the malware was first introduced to the system. Such a search can be achieved using the Windows Search tool; the following screen shot shows how to narrow the search for infected files using the Search Results pane's advanced options.

Figure 4.4 The Search Results advanced options dialog
See full-sized image

With the options set as they are in this figure, all files that were created on the day the malware was introduced onto the host (in this example, April 27, 2004) will be listed.

It is also possible to create a text file containing a list of all files in the current directory and its subdirectories, although you should be aware that this could be a long list.

To create a listing of all files in a directory and its subdirectories

Executing this command will create a text file called FileList.txt in the current directory, which should be copied to a removable media for further analysis.

Note: There are many other ways to create such a list using other tools and scripts. However, the aim of this section is to help gather information quickly using tools that are known to be available on the computer. If you have had time to prepare an emergency response toolkit that contains a more advanced script, use it instead of the procedure shown here.

After this search is completed, the search results can be sorted by type to help identify the executable files, which are generally the target for malware. The following list provides examples of some of the more common file types that can contain executable code:

*.exe        *.html        *.cmd        *.htm

*.bat        *.cpl        *.pif        *.pot

*.vbs        *.vbe        *.js        *.jse

*.scr        *.jpg        *.doc        *.xls

*.mdb        *.com        *.ocx

Note: The search list may contain a large number of entries, and you may not have the time to review all modifications at this stage in the process. However, it is important to save or print a copy of this list for when you have sufficient time to review the likely target files.

The following files may indicate the presence of malware on the system:

These files have been used historically by malware attacks, and are provided here to illustrate the naming techniques that have been used to attempt to hide malware files. If you are unsure of a particular file name, an Internet search can sometimes indicate the nature of a file and whether it has been linked to malware. However, it is important that such a search be performed on a system that is not infected, because Internet browsing behavior can be modified by a malware attack.

It is also important to be aware that a number of malware attacks have used valid system file names, but have placed the file in a different folder to avoid detection by the Windows File Protection service. For example, one file that has been used in the past by malware is Svchost.exe, which is normally installed and protected in the %WINDIR%\System32 folder. However, examples of malware creating a file of the same name directly in the %WINDIR% folder have been seen. It is important to check the full path as well as the file names.

Some of the common target areas for malware attacks to place and modify files include:

If your analysis of the files on the system uncovers any infected files, you should copy the files to removable media for future analysis. Obviously, because these files are infected, steps should be taken to ensure they are not available for anything other than the intended process. Some of the steps you might consider to help protect these copies include:

Checking Users and Groups

Some malware attacks will try to elevate the privileges of existing users on the system or add new accounts in groups that have administrator privileges. Check for the following unusual settings:

Use the Local Users and Groups Microsoft Management Console (MMC) snap-in to check for any unusual additions to the local administrators group. Also check the security log of the local computer for any unusual entries. For example, "Account Management" category entries such as event 636 indicate a new member has been added to a local group. These logs will also provide you with the date and time that the change took place.

If the system being examined is a Windows server, use the Active Directory Users and Groups MMC snap-in to examine the domain group memberships as well. For more information about default users and groups for Windows 2000, see the Default User Accounts and Groups page on Microsoft TechNet at:
http://www.microsoft.com/technet/prodtechnol/windows2000serv/evaluate/featfunc/07w2kadb.mspx. And the Knowledge Base article "243330: Well Known Security Identifiers in Windows Server Operating Systems" that provides information on well-known security identifier (SID)s and their associated user and group information, on Microsoft.com at:
http://support.microsoft.com/?kbid=243330.

Note: Although the articles describe Windows 2000, it is also relevant to Windows 2003 because the same basic default groups have not changed. However, additional default groups have been introduced by Windows Server 2003, such as the Network Service and Local Service special groups. Check your default system configuration for details.

Checking Shared Folders

Another common symptom of malware is the use of shared folders to spread infection. Check the state of the shared folders on the infected system using the Computer Management MMC snap-in or via the command line using the NetSharecommand. The following tables illustrate the default shares on Windows clients and servers.

Note: By default, Windows 9x computers do not share files or folders unless file sharing has been enabled. Also, Windows 9x clients do not have "admin$" or equivalent hidden shares; only those folders or volumes that are specifically shared are available via the network (barring the system being compromised some way or some remote-control software being installed on it).

Table 4.1: Windows XP Default Folder Shares

Table 4.2: Windows Server 2003 and Windows 2000 Server Default Folder Shares

You can also examine the permissions on these shares with the SrvCheck command line tool from the Microsoft Windows Server 2003 Resource Kit Tools page online Microsoft.com at http://go.microsoft.com/fwlink/?LinkId=4544.

Other third-party utilities such as Dumpsec, which you can obtain from the SystemTools.com Web site at: http://www.somarsoft.com/, can also be used for generating these reports.

Checking for Opened Network Ports

Many malware attacks attempt to weaken a compromised system to make it easier to attack in the future. One technique that is often used is to open network ports on the host that will then be used by the malware attacker to gain an additional route to the host.

There are a number of tools that can be used to export a list of the current network port settings, including PortQRY from the Microsoft Windows Server 2003 Support Tools. For more information about this tool, see Knowledge Base article "832919: New features and functionality in PortQry version 2.0" on Microsoft.com at: http://support.microsoft.com/?kbid=832919.

Another tool is the FPort command line utility from Foundstone available at: http://www.foundstone.com/. Additionally if the computer is using a personal firewall, such as Windows Firewall or Zone Labs ZoneAlarm, you should check with the documentation that came with the firewall, as many of them can also show listening ports and the applications that are listening on them.

Finally you can use the NetStat command line utility that comes with Windows to document the state of current network connections and network ports that are listening. This tool can be used to obtain a complete printout of the network connections and port status.

To create a NETSTAT report

A text file called netstat_report.txt (you may also wish to add the date to the file name) will be created in the root of the C: drive. This file should be saved to a removable media for future analysis.

Using a Network Protocol Analyzer

A network protocol analyzer tool can be used to create a network traffic log of data being transmitted to and from the infected host. The network trace file should be saved as part of the set of information files for future analysis.

Examples of network protocol analyzers that could be used for creating these network trace files include the Network Monitor component of Microsoft Systems Management Server (SMS), or other third party tools such as the Ethereal analyzer that is available from the Ethereal Web site at: http://www.ethereal.com/.

Checking and Exporting System Event Logs

It may be possible to use the Windows system event logs to spot a wide range of unusual behavior that could be used to identify both the changes malware has made and when they were made. Use the Event Viewer management console to save each type of event log file (Application, Security, and System) to removable media for further analysis. By default, these files are stored in the C:\Winnt\System32\Config\ directory and are called AppEvent.evt, SecEvent.evt, and SysEvent.evt. However, while the system is active these files are locked and should be exported using the Event Viewer management tool.

The following tips provide information on how these logs can be used to help determine the effects of a malware attack:

At the end of the malware analysis process it may be possible to consider reconnecting the isolated networks, depending on the nature of the malware. For example, if the analysis determines the malware spreads only via a particular peer-to-peer (P2P) application, changing the perimeter firewall filters to block the network ports used by this application would allow the networks and other services to be restored. Such a remedy would allow the organization to return to some level of normal communications while the system recovery process was undertaken.

Top of page

Step 4: System Recovery

After you have collected the required information about the attack and understand its full nature, you can start the process of removing the malware and recovering any corrupted data from the infected computers.

Important: Even if you have an antivirus application that can recognize and clean a malware attack from a computer, Microsoft recommends spending some effort to determine the date and time of the infection as well as how the infection occurred. Without this information it is difficult to determine which other systems, backup media, or removable media were possibly exposed to the attack.

How you complete this process will largely depend on the nature of the particular malware attack. However, you can use the following high-level process to ensure a complete recovery of both data and your computer systems:

Confirming the system is free of malware is a crucial step that should not be overlooked. Many malware threats are designed to remain undetected for extended periods. In addition, backup images or system restore points could contain infected system files, which would cause another infection if an infected backup image is your recovery source. For these reasons, it is vital to ascertain the date and time of the first instance of the malware attack if at all possible. Once you have a time stamp as a benchmark, you can determine through the dates of your backup images as to whether any of them are likely to contain the same malware corruption.

Clean or Rebuild?

Two choices are available to you when considering how to recover your system. The first option is to clean your system, which relies on the known characteristics of the attack to systematically undo the damage inflicted by each. The second choice is frequently referred to as rebuilding or flattening a system. However, deciding which option to use is not a simple choice.

You should only choose to clean your system if you are extremely confident that all elements of the attack have been well documented, and that the cleaning procedure will remedy every element of the attack successfully. An antivirus vendor will usually provide the documentation you need, but it may take the vendor several days to fully understand the nature of the attack. Cleaning the system is often preferred because it returns the system to its clean state with applications and data intact. This approach typically results in a faster return to normal operations than rebuilding the system. However, without a detailed analysis of the malware code, cleaning the system may not entirely remove the malware.

The fundamental risk of cleaning a system is the possibility that either an undocumented element of the initial infection — or potentially a secondary infection or attack — may not have been discovered or documented, leaving your system still infected or susceptible to some malware mechanism. Because of this risk, many organizations choose to simply rebuild their infected systems to absolutely ensure that they are free of malware.

In general, whenever a system has suffered an attack where a backdoor or rootkit was installed, Microsoft recommends rebuilding the system. For more information about these kinds of attacks, see Chapter 2, "Malware Threats" in this guide. The various components of these types of attacks are difficult to detect reliably, and will frequently recur after attempts to eradicate them. These attacks are often used to open unauthorized access to a compromised system, which may enable them to initiate additional attacks on the system to escalate their privileges or install their own software. For these reasons, the only way to be absolutely sure that your computer systems are free of these malware attacks is to rebuild them from trusted media and configure them to remediate the weakness that allowed the attack in the first place, such as a missing security update or weak user password.

This process also requires carefully capturing and measuring all the necessary user data from the infected system, fixing anything corrupted, scanning it to ensure the data does not contain any malware, and finally restoring the clean data back to the newly rebuilt system.

Rebuilding a system also requires reinstalling all of the applications previously available on the system, and then configuring each one appropriately. Therefore, rebuilding provides the highest degree of assurance of eliminating the infection or attack, but generally is a much larger task than cleaning.

The primary consideration in choosing which option to use on your system should depend on your level of confidence in the one you select to completely eliminate and resolve the infection or attack. The down time required during the repair should be a secondary consideration compared to ensuring the integrity and stability of the system.

Table 4.3: Advantages and Disadvantages of System Cleaning and Rebuilding

Note: If you choose to clean an infected system, your organization's management and legal teams should perform a risk analysis to determine if they are willing to accept the increased risk of a future attack if the cleaning process misses part of the malicious code.

System Cleaning

You should only consider system cleaning as a viable option if the attacks and behavior of the malware are well documented and the cleaning procedures have been tested and proven. Thoroughly documented steps administrators can follow or automated tools that clean the infection from your system may be available from either Microsoft or antivirus vendors. Both options are intended to carefully undo each of the actions performed during the infection and return your system to its original operational state. These procedures generally only become available to address major viruses or worms, and typically only several days after the initial malware infection.

Note: Since many malware attacks are released in waves, for example MyDoom@A, MyDoom@B, and so on, it is very important to only use cleaning procedures or tools to clean the specific version of the malware from your system.

If an automated tool is not available to address the malware you are dealing with, the basic steps to consider if you opt to manually clean it from your system include the following:

If you decide to manually undertake these steps, you should only rely on them as a remedy for the infection if you can later compare them with published cleaning procedures to ensure that you have performed all of the necessary steps. Or, if your organization has an antivirus support team, it will also need to ensure that the inspection and remediation procedures it uses to identify and mitigate all possible attack vectors are adequate. Failure to ensure your procedures are adequate could lead to a rapid re-infection.

Restore or Reinstall?

If you determine the best approach is to rebuild your system, you can either restore it using a previous image or system backup you are certain is clean or reinstall the system from original media.

If you choose to restore the system from a previous image, consider attempting to salvage the latest user data on the infected system to avoid losing changes created or updated between the time of the backup and the present. If you rebuild the system from original media rather than a backup, your only option to prevent data loss is to preserve the data from the infected system before backing it up.

Recovering Data from the Infected System

The most valuable asset of your system is most likely the data that resides on it. For this reason, it is crucial to carefully consider how to save, restore or repair the data, back it up, and then restore it on the system after it has been rebuilt.

Be sure to capture all of the following types of data appropriately to completely restore your system:

Back up all of the data to a safe medium or location where it cannot be executed or accessed by unauthorized users or systems. If necessary, use whatever tools or other means are available to restore the data, and then safely store it until you can restore it on the system after it has been rebuilt.

Restoring From an Image or Backup

To restore data from an image or backup, you must have previously captured it using a recovery tool before the infection compromised your system. A wide variety of tools are available that may dramatically simplify the task of backing up and recovering data from your systems. These tools provide a high level of insurance to protect your systems against not only malware infections, but also hardware failures and other potential threats to your system. Configuring a complete disaster recovery infrastructure is not within the scope of this guide. However, a few key technologies in this area that you can use to address antivirus-related issues are discussed in the following sections.

Windows System Restore

Windows System Restore (WSR) protects critical system and application files by monitoring, recording, and in some cases backing up these files before they are modified. It is important to know if your antivirus application supports WSR, because WSR can create a restore point that could become infected with malware if you used it to clean a system any time after the initial malware attack. If this is the case, it is possible that the malware could be re-introduced to the system from the infected restore point. Fortunately, a WSR-aware antivirus application will detect the malware during a restore process. If any infected files are detected, the antivirus solution will attempt to modify, move, or delete them. If the files are successfully cleaned, WSR will restore the files in question. However, if a file cannot be cleaned and is deleted or quarantined, the restoration process will fail because isolating a file results in an inconsistent restore state. If this is the case, WSR will revert the system back to its previous state (before the restore operation began).

For more information about how antivirus applications can work with this service, see the Knowledge Base article "831829: How antivirus software and System Restore work together," on Microsoft.com at: http://support.microsoft.com/?kbid=831829.

Note: As virus signature files are updated to cover a malware attack, a restore that failed days before may now succeed (after the antivirus application is updated). Conversely, if you restore to a point that succeeded before but a new signature file enables the detection of an attack on a backed up file that cannot be cleaned, the restore process could possibly fail.

For more information about Windows System Restore, see the How to Restore Windows XP to a Previous State page on Microsoft.com at:
http://www.microsoft.com/technet/prodtechnol/winxppro/support/restore.mspx.

Automated System Recovery

Automated System Recovery (ASR) provides a simple means to quickly back up both the boot volumes and system volumes on your computer, which will enable you to more rapidly restore your system in the event of an infection or failure. However, just like other backup media, it is possible that the ASR backup files could become infected by the malware. For more information about ASR and how you can use it in your organization, see the "How ASR Works" white paper on Microsoft.com at: http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/depkit/7B4F0436-CC90-4B52-B6AB-064F9DB8D272.mspx.

The Windows Backup Solution

The backup solution that is supplied as part of the Windows family of operating systems provides a simple backup solution for departmental or small- to medium-sized business environments. However, just like WSR and ASR, the backup files themselves can contain infected malware. For this reason, ensure that you do not restore the malware to your system and restart the malware attack if you use this solution. All backup files should be checked and scanned with an updated antivirus application that is capable of detecting and removing the malware before you use the backup image to restore your system. You will find detailed documentation on disaster recovery, including backup and restore operations, in the Planning for Disaster Recovery section of the Windows Server 2003 Deployment Kit on Microsoft.com at: http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/depkit/59F4CC08-61C5-4A34-9039-19B395EC745D.mspx.

Reinstalling the System

Once you know the backup data for your system is trustworthy, you can start the process of rebuilding your system. This point in the process is the best time to reformat drives, change partition sizes, and perform other system maintenance as required to ensure the optimal performance of your system after it is restored. If possible, rebuild your servers using a fully updated slipstreamed share. More information on creating slipstreamed installs of Windows can be found in:

If you cannot rebuild from a slipstreamed source, the risk is that the system will get infected from network-based malware before you can connect to the Windows Update Web site to download critical service packs and security updates. If this is the case, use the following steps to reinstall:

After you have rebuilt the system and scanned it to confirm there are no longer any infected files on it, it is safe to restore the user data.

Top of page

Step 5: Post Recovery Steps

This section provides guidance on specific steps you should take after controlling and recovering from the initial malware attack. It is important to complete this stage to help strengthen your organization's overall policies for people, processes, and technologies.

Post Attack Review Meeting

This meeting should include all affected parties and call for a free exchange of lessons learned for the benefit of all. Specifically, participants should seek to:

Post Attack Updates

Review and evaluate whatever recommendations result from the meeting, and then ensure that they are implemented as soon as possible across your organization. Once a particular vulnerability has been exposed, there are often a number of approaches you can use simultaneously to mitigate it.

It is important to understand that these changes are likely to affect the people, processes, and technologies of your organization. Reviewing the estimated cost of the attack to the organization should serve to underscore the future cost benefit your organization can realize by proactively working to prevent a reoccurrence of the attack.

At this point, if your organization has not already implemented an antivirus defense in depth approach, see Chapter 3, "Antivirus Defense in Depth" in this guide to review which elements of this approach will benefit your organization the most.

Top of page

Summary

This chapter provided guidelines and recommendations that you can use to recover from a malware attack in a considered and consistent manner. It is important to follow the suggested steps consistently, as failure to do so may leave your organization open to further attack from malware. Failure to do so may also make it difficult or impossible for your organization to take legal action against the perpetrator of the attack.

If your organization has implemented an antivirus defense-in-depth solution, the number of times you will need to mitigate attacks with it will likely be kept to a minimum. However, failure to plan on how to address worst-case scenarios in advance will leave your organization open to making serious errors if an attack succeeds in breaching your antivirus defenses.

You should prepare for this in advance by training security staff to understand common malware techniques, such as those covered in this chapter. Also consider creating a malware analysis toolkit that contains some of the tools described in this chapter, as well as any scripts or other utilities that can be used to quickly capture and document vital information from infected systems. This preparation will help reduce the impact on your business operations if systems become subject to a malware attack.

Each new attack may introduce different methods to compromise or corrupt your systems. Therefore, Microsoft strongly recommends monitoring the Microsoft Security Antivirus Information Web site at: http://www.microsoft.com/security/antivirus/default.mspx. This site will provide you with up-to-date antivirus information and guidance on how to address the latest malware attacks. Using the resources in this chapter will help you to effectively control the impact a malware outbreak may have on your organization, and to recover from it in an efficient and reliable way.

Top of page

5 of 6