Repair the Damage
After you've deleted the infected email messages, remove or replace any damaged or infected files. Move suspect files to a quarantine area for later analysis. Clean the registry entries that require it.
I often use registry editor files (regedit files) to speed up this process. Regedit files are specially written text files that you can use to add or overwrite registry values. When you use a regedit file from within a registry editor, from the command line, from within a batch file, or simply by double-clicking the file in Windows Explorer, the strings that the file contains are applied against (i.e., written to) the registry. To create a regedit file, you need a file editor or word processor that will write plain ASCII text files without embedded printing or formatting codes. Next, you need to research what registry subkey and values you'll be adding or modifying and construct the appropriate regedit file. Listing 1 shows sample content from a regedit file that repairs damage that the Pretty Park worm causes. Unfortunately, you can't use regedit files to delete registry values. Thus, I often use the files to overwrite a malicious value with a blank space, which stops the malicious program but can leave a rogue (but usually harmless) registry subkey in your registry.
Large shops should use a centralized logon script or automation tool that searches for the existence of the rogue program, deletes it from computers, and repairs the damage. I often use Novell Application Launcher and Microsoft Systems Management Server (SMS). When networks aren't set up for centralized modifications, I send a simple batch file to users through email. With the appropriate security, users can click the attached batch file, and it will clean up their PCs. For example, you can use the batch file that Web Listing 1 shows to eradicate the VBS.Freelink worm.
When you use a batch file for cleanup tasks, be sure to test the code on a few machines before releasing it to your entire network. If you have Win2K or NT machines, be sure to test for the appropriate folders in your batch file and make sure security rights don't prevent the batch file from deleting malicious files. On Windows XP, Win2K, and Windows Me machines, deleting wscript.exe and cscript.exe won't work because file-protection mechanisms will simply restore the originals. Fortunately, you can find ways around this behavior.
For example, on XP and Win2K machines, notepad.exe is a protected executable. Because of a bug in Windows File Protection (WFP), you can copy protected files over each other. Thus, you can rename notepad.exe to any other listed executable, then copy it over the potentially dangerous file, which effectively deletes the original file and replaces it with harmless Notepad. A side effect of this trick is that you can open some malicious code innocuously in Notepad and view the source code.
Verify That Eradication Steps Are Working
Send out members of your operational team to verify that end-user machines are being cleaned appropriately and monitor communication channels for problems. Sometimes, you'll find that the team missed something during the initial analysis stage. If so, you can modify the cleanup program and redistribute it to all affected users. Communicate cleanup status to operational staff and end users.
Bring Disabled Systems Back Online
As disabled systems are cleaned, bring them back online. Communicate to end users that they can use their computers as usual. Let them know whether any systems remain offline. In my experience, as soon as a system is enabled, users will begin logging on to it. Use your checklist of the systems and services you disabled to help you remember to enable everything. Remove paper signs that warned users.
Prepare for a Recurrence
Be prepared for the rogue program to recur, and tell your end users the same thing. Although your office might be clean, the rest of the world is probably still fighting the bug. So you can bet that the bug will reappear when your systems are operational again. Usually, the longer it takes to notice the initial attack, the more likely it is that the problem will be back because the malicious code is likely to be lurking in more locations.
Perform a Thorough Analysis
Now that the crisis is over, perform a more thorough analysis. By this point, you should have a full understanding of what the rogue program did. Either your team disassembled it, or the antivirus vendor was able to tell you. Use a more thorough analysis to repair remaining damage. Determine whether your defense plan or tools had any flaws that let the rogue program spread; if so, fix the flaws.
If you follow the procedures I've outlined, communicating well both with IT team members and with end users, you can significantly minimize any email outbreak. I've seen IT teams that follow these steps go from days of downtime to 15 minutes from attack beginning to complete eradication. And that's the difference between Sherlock Holmes and Inspector Clouseau.
End of Article
Prev. page
1
2
[3]
next page -->
