| Downloads |
|---|
| 45149.zip |
I'm trying to eradicate a particularly nasty piece of adware on a computer running Windows XP. The software randomly displays browser advertisements to the user. I interrogated the system and found that the software adds a registry entry to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run subkey. When I delete the entry, the malicious software immediately adds it again and renames the calling program specified in the registry value. Renaming the Run key doesn't help either because the program creates a new Run key and adds an entry to the new location. Thus, there's more than one process in memory, ensuring this program's resiliency. I ran several spyware and adware eradication programs and scanned the system with an antivirus program, but nothing eradicates this program's system. I conducted searches on the Internet for information about this specific malicious behavior and how to stop it. All the advice suggests I have to reformat the OS partition and reinstall the OS. Can you help me take a less drastic approach to eradication?
It sounds like the computer might have been infected with PurityScan, n-CASE, Gator, or another one of the many adware programs proliferating on the Internet. You can read more about these unwanted programs in the Security UPDATE article "Security Trends and Highlights of 2004," http://www.windowsitpro.com, InstantDoc ID 44827.
Although you couldn't identify the actual program to eradicate, you've done a good job describing the malicious software's behavior. This step is important when you're trying to remove the program from the computer. The solution for clearing the computer of this adware is to stop anything from starting from the Run keys in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run or HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run subkey.
Beyond this one attack, it's equally important to identify other autorun locations and how to most easily disable program startup from these places. This approach to answering your question should empower you to stop programs that exploit other automatic startup features in Windows. I suggest you start by reading the Windows IT Pro article Top 10, "Windows Program Startup Locations," http://www.windowsitpro.com, InstantDoc ID 27100. This article lists the top 10 autorun locations in Windows.
The most comprehensive tool I've seen to help control software that's configured to run automatically and to see from where software is starting is Sysinternals' Autoruns. You can download this freeware from http://www.sysinternals.com/ntw2k/freeware/autoruns.shtml. To fully grasp how Autoruns can help, read the .chm Help file included with Autoruns, the tool usage information on the Sysinternals site, and the Windows IT Pro article "Autoruns," http://www.windowsitpro.com, InstantDoc ID 44089.
This tool, however, might not be enough to deal with the malicious adware you describe. Although Autoruns will temporarily disable or permanently delete an item from an autorun location, the adware will add an entry back into the autorun location before the next system restart. What you need to do is instruct Windows to ignore startup locations. To get a handle on how to disable software listed in some of these startup locations, see the "Temporarily Disabling Applications and Processes" section in the Microsoft Windows XP Resource Kit (http://www.microsoft.com/resources/documentation/windows/xp/all/reskit/en-us/default.asp?url=/resources/documentation/windows/xp/all/reskit/en-us/prmc_str_kajg.asp?frame=true). Although this resource is a good start, Microsoft hasn't written a comprehensive article that documents all autorun locations and how to disable them. Further, Microsoft doesn't tell you the easiest approach to disabling these autorun locations.
The easiest approach to disabling most, if not all, autorun locations is by starting a Windows computer in Safe Mode or Safe Mode with Networking. However, in more than one instance, I've encountered computers incapable of starting usefully in Safe Mode. The most typical problem is that the video display is difficult or nearly impossible to read or navigate. In addition, Safe Mode is an all-or-nothing mode of operation, and you might not want to disable all autorun locations. So, here's a list of common autorun locations and how to most easily disable each one.
The Run keys. One approach to disabling the Run key in autorun from the HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER hives is to load the Microsoft Management Console (MMC) Group Policy Object Editor snap-in, then add policies as described in the article "Disabling Startup Programs by Using the Group Policy Snap-in" in the XP resource kit's "Temporarily Disabling Applications and Processes" section.
A simpler approach that even works on Windows OSs that don't support Group Policy is running the StartupRunControl.vbs script, which Listing 1 shows. You can download this fully commented script from the Windows Scripting Solutions Web site. Go to http://www.windowsitpro.com/windowsscripting, enter 45149 in the InstantDoc ID text box, then click the 45149.zip hotlink.
StartupRunControl disables or enables the Run subkeys by setting two system policies—DisableLocalMachineRun and DisableCurrentUserRun—in the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer subkey. The script begins by initializing four variables, as callout A in Listing 1 shows. The strComputer variable specifies the local computer as the script target. The strExplorerPolicyKey variable specifies the registry path. The other two variables specify the system policies to add and set, if they aren't present, or to set, if they are present. You must be an administrator or equivalent to add these system policies to the registry.
If you have administrative remote access to Windows Management Instrumentation (WMI)–enabled computers on a network, you can change the strComputer variable to the IP address, NetBIOS name, or DNS name of a remote computer instead. You can also customize StartupRunControl so that it runs on multiple network computers instead of just one local or remote computer. For example, you could customize the script so that it parses a file of computer names or iterates through an Active Directory (AD) container of computer names. Being able to run the script on multiple computers can be particularly useful if your network has been compromised by a program that autoruns from a Run subkey. For more information about accomplishing this customization for an entire IP subnet, see the Windows IT Pro article "Remote Administration with WMI," http://www.windowsitpro.com, InstantDoc ID 37596.
StartupRunControl takes one of two input parameters: 0 (lets programs automatically run from the Run keys) or 1 (doesn't let programs automatically run from the Run keys). Because StartupRunControl expects a command-line parameter, the code at callout B calls a subroutine to verify that the script is being run from Windows Script Host's (WSH's) CScript scripting engine. The code at callout C verifies that you've entered 0 or 1 as an input parameter.
If you enter 0 or 1 when launching StartupRunControl, the code in the Select Case statement at callout D uses the SetDword subroutine to configure the registry policies. SetDword uses the CreateKey method to create the Explorer key if it doesn't exist and the SetDWORDValue method to configure the two system policies. These two methods are contained in the StdRegProv class (aka the WMI Registry Provider) in the WMI default namespace.
You can change the strExplorerPolicyKey variable to point to the equivalent policy location in the HKEY_CURRENT_USER hive or even the HKEY_USERS hive for individual users. However, when you set these two policies to 1 in HKEY_LOCAL_MACHINE, no programs will automatically run from the Run subkey in any hive, regardless of who logs on.
The RunOnce keys. To disable programs from the RunOnce key in the HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER hives, you can adapt, then run StartupRunControl. In the code at callout A, set the strLMValueName and strCUValueName variables to the value "DisableLocalMachineRunOnce" and "DisableCurrentUserRunOnce", respectively. Optionally, you can adapt StartupRunControl to disable programs from both the Run and RunOnce subkeys. In the 45149.zip file, you'll find the ReplacementCode.txt file, which contains the replacement instructions and code.
The Program Files Startup folders. After the Run keys, the next most common startup location for malicious programs is the Program Files Startup folders. On an XP computer that hasn't been upgraded from Windows NT, the two Startup folder locations are the All Users Startup folder at %ALLUSERSPROFILE%\Start Menu\Programs\Startup and the user Startup folder at %USERPROFILE%\Start Menu\Programs\Startup. The location of these folders vary by OS version, but stopping programs from starting from the Program Files Startup folders is simply a matter of pressing the Shift key immediately after initiating a user logon or starting Windows in Safe Mode or Safe Mode with Networking. The former method is simpler and provides you with more granular control of a single type of startup location.
Pressing the Shift key during logon is a rock-solid approach to specifically disabling the Program Files Startup locations. However, it's possible for a malicious program to delete the system policy settings that StartupRunControl creates in the registry or reset their values before you have the opportunity to reboot. In that case, you can make the script start when the computer starts and when it initiates a shutdown. To use Group Policy to assign StartupRunControl as a script that executes on system startup or shutdown, use the following procedure on a computer running XP. (You can also configure Group Policy on a computer running Windows Server 2003 or Windows 2000, but the procedure will vary.)
- Create a custom MMC console. Click Start, then Run. In the Open textbox, type mmc and press Enter.
- Add the MMC Group Policy snap-in. From Console1, click the File menu, then click Add/Remove Snap-in. In the Add/Remove Snap-in dialog box, click Add. Scroll down and double-click Group Policy Object Editor. In the Select Group Policy Object dialog box, click Finish. In the Add Standalone Snap-in dialog box, click Close. In the Add/Remove Snap-in dialog box, click OK.
- Add StartupRunControl to the Startup or Shutdown policy. To add the script to the Startup policy, navigate to Local Computer Policy, Computer Configuration, Windows Settings, Scripts (Startup/Shutdown). In the Results pane, double-click Startup. In the dialog box that appears, click Add. In the Script Name text box, specify the following:
cscript filepath\StartupRunControl.vbs
where filepath is the path to StartupRunControl. In the Script Parameters text box, type 1, then click OK. In the Startup Properties dialog box, click OK.
To add the script to the Shutdown policy, follow the procedure I just described, but double-click Shutdown instead of Startup in the Results pane. While you're in the Results pane, check both the Startup and Shutdown policies to verify that no startup or shutdown scripts have been added without your knowledge. Remove scripts that you suspect are from a malicious source.
- Exit the MMC console. Note that you don't need to save the MMC custom console. Before restarting the computer, type the following at the command line to make CScript your default script engine:
cscript //h:cscript
The System.ini and Win.ini files. To disable programs starting from the System.ini and Win.ini files, you can use the System Configuration utility. You can find information about this utility in the article "Disabling Startup Programs by Using the System Configuration Utility" in the XP resource kit's "Temporarily Disabling Applications and Processes" section.
The Autoexec.nt file or the Config.nt files. The Autoexec.nt and Config.nt files, which are in the %systemroot%\system32 directory, initialize the MS-DOS environment. These two .nt files or their equivalent .bat files are unlikely attack targets for adware, but they're worth checking if the computer appears to be compromised when you launch either the Cmd or Command shell environments. For more information about how to troubleshoot problems with programs that run from this MS-DOS environment, see "Troubleshooting MS-DOS-based programs in Windows XP" (http://support.microsoft.com/kb/314106).
"Windows Program Startup Locations" lists some additional Windows startup locations that are less commonly used. If programs are still starting after you've used the StartupRunControl script or pressed the Shift key during the logon process, check the additional locations listed and use the Autoruns tool to see whether you can delete or disable programs in those locations. If all else fails, attempt to start your computer in Safe Mode and continue your system interrogation.
Viruses, worms, adware, and spyware are here to stay. Assuming that you keep your virus definitions updated, antivirus programs do an excellent job of handling most viruses and worms. Some vendor products and freeware programs also do a great job of handling most adware and spyware threats. For example, the freeware Spybot Search & Destroy (http://www.safer-networking.org/en/spybotsd/index.html) detects and removes spyware and even includes the powerful Teatimer utility to track and control registry changes. In addition, as of this writing, Microsoft has released a beta version of Microsoft AntiSpyware that you can download from http://www.microsoft.com/athome/security/spyware/software/default.mspx. You can augment these antispyware programs with Autoruns, which is fantastic for exposing what's set to autostart and deleting or disabling individual autostart applications.
Even these great programs and utilities might not be capable of dealing with malicious software that ensures its resiliency by silently adding removed autorun settings. In this instance, you can conveniently disable Windows autorun features by using StartupRunControl or a similar tool.
