Shared Process Services

Note: This blog is not intended to be deep dive into Windows Services architecture. If you'd like to really get into the weeds on services, see the Microsoft documentation (https://docs.microsoft.com/en-us/windows/win32/services/about-services).

Services Overview

In Microsoft Windows, a service is a non-interactive, process that can be configured to start on-demand or automatically independently of any user logging into the system. The Windows Service architecture provides a method for adding functionality that does not rely on user interaction. As an example, a web server will host it's content via a service so that it is able to respond to web requests automatically regardless of whether anyone is logged onto the server.

Windows Services are controlled by the Service Control Manager (SCM) and consist of a service control program (SCP) and a service application. More details about the SCM and how it orchestrates services can be found within the Microsoft documentation here: https://docs.microsoft.com/en-us/windows/win32/services/service-control-manager

Standalone vs Shared Process Services

There are seven different types of services defined by Microsoft however the two types that you most often going to interact with are Win32OwnProcess and Win32ShareProcess.

Note: The service type is specified as the type value within the service registry key. Definitions of the service types can be found here: https://docs.microsoft.com/en-us/dotnet/api/system.serviceprocess.servicetype?view=dotnet-plat-ext-6.0

Win32OwnProcess (standalone services) are service applications that can be orchestrated by the Service Controller and runs within it's own process. Standalone services specify a standalone service application as the ImagePath value within HKLM\SYSTEM\CurrentControlSet\Services\<servicename> registry key.

Win32ShareProcess (shared process services) are service applications that can share a process within another Win32 service application. Shared process services most commonly store their service application within an DLL (specified within the ServiceDLL value in the service registry key) that is loaded by Service Host (svchost.exe). It's worth noting that Microsoft has made a change to how shared process services are handled after Windows 10 Creators Update (version 1703). On systems with more than 3.5 GB of RAM, Windows will no longer group shared process services within a single Service Host process, instead Windows will run the service within a separate Service Host process (this can be disabled within the registry).

Shared process services are organized within Service Groups inside the HKLM\Software\Microsoft\Windows NT\CurrentVersion\Svchost registry key and each Service Group has varying level of access controlled by COM Security via COM runtime (OLE32.DLL). The level of access such as AuthenticationCapabilities and CoInitializeSecurityAllowLowBox are specified within the service group registry key and processed only if the value CoInitializeSecurityParam value is non-zero. Access control of Service Groups can include controlling which services are able to establish network connections or not by modifying the registry value AuthenticationCapabilities within the Service Group registry key.

Note: an easy way to identify shared vs standalone services in the registry is to look for the Type value within the Service entry under HKLM\SYSTEM\CurrentControlSet\Services\<ServiceName>. A Type of 0x20 is a shared process service and a type of 0x10 is a standalone service.

Standalone Service Reg Key

Shared Process Service Reg Key

Shared Process Service Attack Surface

Adversaries abuse shared process services in two main ways.

1. Create a new shared process service either within an existing service group or within a new service group.
2. Hijacking existing share process services.

Create a new shared process service either within an existing service group or within a new service group.

Creating a new shared process service is fairly straight forward. The most difficult part is compiling a ServiceDLL which can be done in Kali using mingw. I would provide my service template CPP but honestly there are better ones out on the Internet.

Once you have a DLL, it's just a matter of registering the new service with the SCM and making the necessary registry entries to reference the ServiceDLL and create the new service group.

After starting the service, we can see that my evil DLL has been loaded by svchost and is current running as SYSTEM.

Detection: This type of shared process execution is fairly easy to detect through Windows Event Logs or process monitoring with command line arguments and if you have access to registry key monitoring, it becomes even easier.

A System WEL 7045 will be logged upon registering the new service with the SCM and will contain a path to the newly created service group name. New service group creations are not that common of an occurrence so defenders can leverage frequency analysis for the reference Service File Name, keying in on new service groups across the enterprise.

Through process creation data, defenders can search for process execution events containing references to the ServiceDll registry value (reg.exe and powershell.exe remain the most common utilities used to modify the registry but they are not the only ways) in the command line parameter or enumerate all service host process events to anomalous activity.

parent process: service.exe
process name: svchost.exe
command line contains -k


        

Process Name :
((Command Line contains \SYSTEM\CurrentControlSet\services\ 
  AND 
Command Line contains ServiceDll)
OR
(Command Line contains HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost))*         

(Recommended) Enriching registry monitoring with process events is ideal for registry modification based detections. For example, by fusing together the process name, parent process, and target registry key, defenders can create the following detection which has been highly successful at detecting adversaries modifying the registry via a C2 framework.

RegKeyModified: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost

Process Name: reg.exe

Parent Process Name: cmd.exe

Grand Parent Process Name: rundll32.exe
         

However, there is really no need to create a new service group to execute a malicious shared process service. As mentioned before, there are existing Service Groups which are granted high levels of access by default such as netsvcs and adding a new service to a service group is extremely simple. All that is require is to append the service name to the existing service group entry within the svchost registry key.

Appending values to multi value strings within the registry is not very straightforward with the reg command but it is very simple with PowerShell. Simply read the existing values into a temporary variable, append your service name to the variable, and then write all of the values back into the original service group registry key. Voila!

Detection: Again, a System WEL 7045 will be created when the new service is registered with the SCM however since we used an existing service group, defenders will need to key in on the service name to identify anomalies. Process events enriched with registry modification data remains the recommended approach.

Hijacking existing share process services

I am by no means a true red team operator however hijacking services can become a precarious situation quickly if you aren't careful about what service you are targeting. I have had the most success identifying disabled services or services which are still registered with the SCM but the target service executable is no longer on disk.

To find potential targets, I wrote a PowerShell script that will enumerate a list of all shared process services and their corresponding service groups. With the entire shared process service list, I filter services which are disabled and do not have dependencies on other services or have a target executable which is no longer on disk.

To hijack tzautoupdate, I again can simply just make some minor registry changes to point the existing service to my malicious DLL (obviously I could overwrite the legitimate DLL as well) and modify the status of the service so it is no longer disabled. To confirm that my DLL was loaded by svchost, I dumped the loaded modules and confirm via hash value.

Detection:

In this case, there will be no System WEL 7045 event created since there was no new service registered with the SCM but a System WEL7040 will be created notifying that the Auto Time Zone Updater service has been started.

Again, registry monitoring with process enrichment would be a great place to detect this activity especially monitoring for changes to the ServiceDLL value for any (but especially for the ones that are disabled by default) existing shared process service.

Additionally, if your security stack has the ability to monitor for DDL module loads into processes you could leverage a lookup table of the default shared process services DLL filenames and monitor for shared service executions where an unsigned DLL is loaded that matches a known ServiceDLL name.

(parent process: service.ex
process name: svchost.exe
command line contains -k)
AND
(Loaded DLL Name in DefaultSeviceDllFileNamelist.csv)
AND
(Loaded DLL Sig Status: Unsigned)        

Note: I also noticed that the Auto Time Zone Updater service does not seem to run all that often in the production environments I have access to so in a pinch, just monitoring for the associated 7040 event may be ok.

If you are a responder and you do not have access to any kind of endpoint or log telemetry, I wrote a script called Shared Process Service Audit and shared it on the X-Force IR Github which will output a list of all the shared process services, their associated DLLS, Signature Status, and the hash data. (https://github.com/XForceIR/SharedProcessServiceAudit)