Part 1 | Part 2 | Part 3
In the first article of this series, I explained how to use the Safe Mode menu and Shift key to prevent certain Windows XP startup programs from loading. Although those techniques do work, they are not appropriate for every situation. In this article, I will continue the discussion by showing you some of the more advanced techniques for disabling annoying Windows XP startup programs.
Editing the registry
The Windows registry can be configured to launch applications at startup. In fact, adding calls to launch applications to the Windows registry is a favorite technique of malware authors. Don't assume though that just because a process is being launched from a call in the registry that the process is related to malware, because many legitimate applications are launched through the registry. This is particularly true of antivirus software and other applications that run in the background.
The most effective way to prevent an application from running on startup is to simply delete the registry key that calls it. Before you do, though, it is extremely important that you know exactly what it is that you are deleting. I will talk about identifying unknown processes in much more detail later in this series. For now, however, if you need to identify a process prior to deleting a registry key that calls it, try doing a Google search on the process' file name.
WARNING: Editing the registry is dangerous. Making an incorrect modification to the registry can destroy Windows and/or your applications. I therefore recommend making a full system backup before continuing.
With that said, Windows differentiates between processes that are only run during the next reboot and those that are configured to run every time Windows is started. Calls to processes that are run only after the next reboot can be found beneath the following registry locations:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
HKEY_Current_User\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
Finding calls to processes that run each time Windows is booted is a bit trickier. Here are the primary locations where these calls are stored:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKEY_Current_User\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
Calls can also be made on a per-user basis. The problem is that users are identified by GUID, rather than by user name. It is common for some types of malware to create a call to a malicious process for each individual user. The idea is that if one user cleans the call to the process from the machine, another user can log into the machine and cause it to become infected all over again. This is because Windows processes a registry key that is not processed when other users log in. Therefore, if you are trying to track down a malicious process, then it is a good idea to check each user account. Typically, there won't be too many accounts to sift through, and you can find calls to startup programs for individual user accounts at the following location:
HKEY_Users\user's GUID\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
Some Group Policies prevent actions at startup
Editing the registry works really well if you find yourself having to manually remove an unwanted process from one or two workstations. As we all know, though, malware infections can spread rapidly, and who wants to manually edit the registries of every workstation on your network? Fortunately, you don't have to.
Windows includes Group Policy settings that prevent the registry from launching applications on system startup. Keep in mind though that the technique I am about to show you is an all or nothing proposition. The Group Policy Object Editor isn't flexible enough to allow you to selectively enable and disable various processes. You have the option of preventing Windows from using the registry to launch processes at startup, but, by doing so, you may disable desirable processes as well as unwanted ones. You do, however, have the option of specifying the processes you want to run when a user logs in directly through the Group Policy rather than through the registry.
Since Group Policies are hierarchical in nature, in the beginning I recommend that you experiment with this technique using only the local security policy on a few workstations. If testing reveals that this technique isn't going to cause problems, then you can always implement the settings at the domain or OU level of the Group Policy hierarchy later on.
To prevent processes from being called from the registry at system startup, open the Group Policy Object Editor and navigate through the Group Policy tree to the following location:
User Configuration\Administrative Templates\System\Logon
There are three Group Policy settings of interest in this location:
Do Not Process the Run Once List
This setting prevents processes listed in the following registry locations from being launched:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
HKEY_Current_User\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
Do Not Process the Legacy Run List
This setting prevents processes listed in the following registry locations from being launched:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKEY_Current_User\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
KEY_Users\user's GUID\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
Run These Programs at User Logon
This setting allows you to specify the process that you do want to run during startup.
Calls to startup processes can be associated either with the computer or with the user account. Therefore, you will find a duplicate set of Group Policy settings beneath the Group Policy Editor's Computer Configuration container at Computer Configuration\Administrative Templates\Logon.
DISABLING STARTUP PROGRAMS IN WINDOWS XP
Using Safe Mode and the Shift key
Editing the registry and using Group Policy
The System Configuration Utility and the trouble with networks
|
| Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server, Exchange Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. He writes regularly for SearchWinComputing.com and other TechTarget sites.
|
|
