Putting Down an Email Attack

Downloads
23656.zip

As a network administrator, you can't describe the funny feeling you get in your stomach when your pager begins to beep again and again while you simultaneously hear your name called over the public address system and notice that all your users have the same email message on their screen that you're seeing on CNN. Welcome to another email worm outbreak.

Odds are, your antivirus software vendor doesn't have an updated signature file, or if the vendor does, its Web site is so overloaded with requests that the result is the same. Few network problems put the spotlight on you, your preparation, and your problem-solving abilities like a widespread email attack. Depending on how you handle the crisis, you can look as smooth as Sherlock Holmes or as bumbling as Inspector Clouseau. Because 80 percent of email outbreaks are related to Microsoft Exchange Server/Microsoft Outlook combinations, I offer some specific advice for reacting to an email worm outbreak on that platform.

Report the Outbreak to a Leader
No matter how an email outbreak is initially discovered, the first IT team member to hear about it needs to alert the team leader, who in turn alerts the other team members and gathers an eradication team. Make sure you have a communication method in place that an email attack won't affect. Because so many people now have cell phones and pagers that can accept email messages, attacks can often overwhelm mobile devices and networks quickly. When the VBS.LoveLetter email worm first hit the United States, my pager stopped working within minutes and my cell phone wasn't operational for 6 hours. Discuss backup communication methods ahead of time, such as overhead paging, private instant-messaging channels, and prearranged land-based phone numbers. Less technology usually wins in these instances.

Collect Initial Facts
As the eradication team gathers, team members need to begin to share what they know about the email attack. Where did it first appear? How long has it been spreading? Does it modify local files? Begin to collect the facts necessary for an initial understanding.

Minimize the Attack's Spread
After you've collected the initial facts, immediately take steps to minimize the spread. These steps can include disabling the email servers and Internet access. On an Exchange server, you can stop the Internet Mail Service (IMS), Message Transfer Agent (MTA), and any other email connector services. If the email worm uses its own SMTP engine to spread, disable Internet access. If malicious code is actively modifying or destroying files on a file server, disconnect users and disable logons. If the attack is bad enough, consider powering down servers and workstations. Make sure you keep track of which computers and services you're disabling so that you can bring them back up later. To minimize spread, you might also want to block certain firewall ports on internal or demilitarized zone (DMZ) firewalls (e.g., port 80 for HTTP, port 25 for SMTP). Blocking firewall ports is also important for protecting against "reentry" from the Internet.

Notify end users about the threat. Make sure the word gets out to all end-user departments about the email worm or virus outbreak. Contact other team leaders, and use voicemail or the public address system to spread the word. As untechnical as it might sound, posting paper signs on entrance doors and in common work areas detailing the problem and what users need to do is a good way to notify users. In a crisis, simple is always better. Also, don't forget these steps:

• Contact remote offices.
• Be sure to let senior managers know what's going on so that they don't get blindsided.
• If the email attack spread from your company to other companies before you could stop it, communicate with those companies as well.

Be Detailed and Collect More Facts
By now, you should have the email worm or virus contained and have taken steps to prevent further damage. The whole team should have gathered and discussed the problem. Now, you can determine the extent of the damage. How widespread is it? How many PCs did the attack affect? How many departments did the attack hit?

Finding out who isn't infected is as important as finding out who is infected. If the attack has affected every machine but one in a particular department, find out what's unique about that user or machine (e.g., the user didn't open the infected email, the machine has the latest service patch installed). A particular workstation component might have prevented the email worm from spreading.

If your antivirus tools should have prevented the attack, figure out why and how the bug got by them. Does the subject or file attachment of the infected email remain the same? If not, do the changes show a pattern?

Next, determine what the rogue program did to each PC. Did it drop off other files, rename files, overwrite files, make registry changes, or insert itself in startup areas? If not, then you have to eliminate the email problem only. If the worm or virus modified a PC, then you have a much larger problem. Do the dropped files have the same name every time? Are the system modifications consistent between computers? When you're investigating what the attack modified on a PC, look for newly created or modified files and look in areas that can automatically start programs, services, and daemons. If you're on a Windows PC, be sure to examine at least these areas and files:

• autoexec.bat and config.sys (or equivalents)
• win.ini (Inspect the LOAD= statement.)
• system.ini (Inspect the SHELL= and SCRNSAVE= statements.)
• winstart.bat, dosstart.bat, wininit.ini (if they exist)
• the Startup folder
• registry startup areas:
• HKEY_CLASSES_ROOT\exefile\shell\open\command
• HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\Current Version\Run
• HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
• HKEY_LOCAL_MACHINE\SOFTWARE\Classes\exefile\shell\open\command
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServices
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServicesOnce
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\Shell (Windows 2000 and Windows NT only)
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\Userinit (Win2K and NT only)
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services (registered services and processes)

If you're sending several teams or individuals out on fact-finding missions, make sure they record their results so that you can compare them at a later meeting. You can also use integrity-checking tools such as Tripwire's Tripwire to detect the harm a virus or worm has done to a system. If you install after the fact, however, note this caveat: Some experts wouldn't trust the findings because the infection code could contain subroutines to defeat the integrity checker.

If you have the appropriate programming talent on your team, you can try to read the worm's source code (if it's readable) to see exactly what it's doing. For example, with a Microsoft Visual Basic (VB) script email worm, save the infected file attachment to disk with a .txt extension, making sure not to double-click or execute it. Then, open the code in Microsoft Notepad or Microsoft WordPad. If the code isn't encrypted, even a nonprogrammer can discover some of its logic. Figure 1 shows an example of the VBS.Love-Letter virus that I opened in Notepad.

Collect and log all the evidence. Figure out what you have to fix, delete, and modify to get rid of the email worm completely. Some antivirus tools only get rid of the worm or virus—they don't usually remove any other modifications.

Check Antivirus Sites for Detection and Repair Clues
If the outbreak is global and new, it will be front-page news on your trusted antivirus vendor's Web site. If you don't find complete information there, use the clues that you've discovered to research the attack. The complete facts surrounding tricky new bugs can take a day or two that you don't have to learn, so optimize your research methods. I compare the facts on several Web sites to compile a better list of facts. Two sites that I suggest you check are the Security Discoveries page at the Security Administrator Web site (http://www.secadministrator.com) and the NT-Bugtraq Web site (http://www.ntbug traq.com).

Implement an Initial Eradication Plan
With the information you've gathered, you can now develop and implement a methodical eradication plan. For example, with most email worms, the first step is to delete all infected email messages. In small shops, you can delete those messages individually on each computer or you can use an antivirus scanner. In larger companies, consider a server-side cleanup tool. For Exchange Server 4.0 and later, the Exchange Server Mailbox Merge (exmerge.exe) utility is the premier tool, and it's free.

Exmerge lets you delete massive numbers of infected email messages all at once from public and private information stores on the server. (You can download Exmerge from Microsoft's Web site at http://www.microsoft.com or install it from the Exchange Server Tools on the TechNet CD-ROM.) The Exchange Information Store service must be running to use Exmerge, and with pre­Exchange 2000 Server versions, you must use the Exchange Service account logon name to log on to the Exchange server. The Administrator account won't work unless it's the Exchange Service account, too. (Note that Exchange 2000 comes with a version of Exmerge called Exmerge 2000; however, you can use the earlier version.) For steps that detail how to use Exmerge, see the Web-exclusive sidebar "Using Exmerge as a Virus Cleanup Tool." (To read the sidebar, go to http://www.secaadministrator.com and enter InstantDocID 23687.)

As an alternative to Exmerge, Microsoft suggests using its Findbin (findbin.exe), Profinst (profinst.exe), and Gwclient (gwclient.exe) utilities, which you can download from Microsoft's Web site, to delete infected copies of the message in the IMS and MTA queues. You'll find the steps related to using these utilities numerous and involved: Refer to Microsoft Product Support Services (PSS) for help.

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.