This is the second post of a three part series in which we explore the world of svchost.exe. In Part 1, we introduced the multiple svchost.exe instances running on Microsoft operating systems; their implied usage; as well as why it is something we should understand a bit more about. I will now go into more depth on how the operating system itself makes use of this Host Process for its needs.
The under-wires of the svchost.exe
A bit of searching around on the process svchost.exe lets you know that this process is indeed legitimate and used by Microsoft. At startup the OS loads a number of services in the background. For the most part these services are executable files (*.exe); however, it is not uncommon that some services are actually dynamic link libraries (*.dll) files which get loaded by a hosting executable file which is started as a service.
In this case, the svchost.exe is the “Host Process” which Microsoft uses to load and manage one or more of its Windows services (via dll files). You also get a number of svchost.exe entries in your task manager because each one of those processes is hosting one or more Microsoft services separately. Let us explore further:
- Open command prompt (Start > Run > cmd.exe)
- Type in “tasklist /SVC /fi “imagename eq svchost.exe””
- You should get a screen similar to the one below:
The table you get shows you:
- How many svchost.exe processes you have which are actually hosting one or more services.
- How many services, as well as which, are being hosted under which svchost.exe.
o Again their names do not really help you out but hang on in there…it is not that bad.
Let’s understand what is happening by focusing on the first line:
- The first svchost.exe which I have is running under process ID 1208.
- From the task manager view with “Command Line” column enabled, I can see that the trigger is: C:\Windows\system32\svchost.exe -k DcomLaunch.
This is what Microsoft does when this process is launched as a service:
- Svchost.exe is launched with a parameter DcomLaunch.
- The Svchost.exe goes to the registry location
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost - Locates the key which matches the parameter entry DcomLaunch as specified and reads it (in this case the string is “PlugPlay DcomLaunch”. This string contains the names of the services it will load and run within the context of that svchost.exe instance.
- In this case what it means is that the SvcHost.exe host instance launched with the parameter “-k DcomLaunch” will be the process instance within which two services will be running. One service is the one with name “PlugPlay”, and the other is “Dcomlaunch”.
- Now that Windows knows the name of the services to load under that instance it needs to actually load them. The way it does it is by following the normal procedure of loading services which is to:
- Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<servicename> to find out the parameters pertinent to that service.
- For the service PlugPlay which we already established will be a dll file which will be loaded into svchost.exe context it needs to find the location of the dll file to use.
- Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PlugPlay, and you will find several of the properties pertinent to the Plug and Play service including the service context it should be running under.
- Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PlugPlay\Parameters and you will find a value named “ServiceDll” which contains the path to the dll to load.
- Voila, now Windows has all it needs to load the dll, into the right svchost.exe process.
- Windows will check if there is an svchost.exe process for the “Dcomload” group already created. If not, it will create an instance of one to handle services in the Dcomload group.
- The svchost.exe process for Dcomload will then start the service by executing the “%SystemRoot%\system32\umpnpmgr.dll”. Once the DLL has been loaded by svchost.exe the service will then be in a started state.
NOTE: Now that the PlugPlay service has been successfully started, it will move on to the second entry in the list i.e. DComLoad and repeat the process. As this time the svchost.exe instance will already exist, it will only need to attach the dll file for DcomLoad service to the existing svchost.exe which is used for the PlugPlay service initiated above.
In this segment, you have been presented with the way the operating system makes use of the svchost.exe to run critical Windows Services which are highly required by the operating system. You were also presented with a technical step by step flow, of what process the operating system goes through to load and run these service processes. Should you be interested, more information on this technical process is available from: http://support.microsoft.com/kb/314056.
In Part 1, we introduced the multiple svchost.exe instances running on Microsoft operating systems. In Part 3, we will put together a script which you will be able to run on your system, and determine whether any of those processes have anything strange, or out of the norm, which can indicate malware activity.
1 Comment