Windows Services are the OS mechanism used to initiate processes at system startup which provide services not tied to user interaction. Windows services consist of three components: a service application, a service control program (SCP), and the service control manager (SCM). 

 

Characteristics of a service application.  

Service applications consist of at least one executable runs as a Windows service, that conform to SCM code interface specifications to receive commands from it as well as to communicate the application’s status back to the SCM. Because most services don’t have a user interface, they are built as console programs. When you install an application that includes a service, the application’s setup program must register the service with the system. To register the service, the setup program calls the Windows CreateService function. When a setup program does this, a new registry key is created under HKLM\SYSTEM\CurrentControlSet\Services for the service. The individual keys for each service define the path of the executable image that contains the service as well as its parameters and configuration options. 

When a program calls CreateService, it must specify the number of parameters (some are required, and some are optional) describing the service’s characteristics. The characteristics include: 

  1. Start – a start type that indicates whether the service starts automatically when the system boots or manually under the direction of an SCP. 
  2. ErrorControl – an error code that indicates how the system should react if the service detects an error when starting. 
  3. Type – indicates whether the service is running in its own process, or it is a service sharing a process with other services. 
  4. Group – defines a service group. If set, the service initializes when its group is initialized. 
  5. Tag – the specified location in a group initialization order. This parameter doesn’t apply to services. 
  6. ImagePath – the location of the service’s executable image file. 
  7. DependOnGroup – the driver or service won’t load unless a driver or service from the specified group loads. 
  8. DependOnService – the service only loads after the specified service loads. 
  9. ObjectName – specifies the account in which the service will run. 
  10. DisplayName – an optional display name. 
  11. Description – A description of the service, up to 32767-bytes 
  12. FailureActions – failure actions include restarting the service process, rebooting the system, and running a specified program. 
  13. FailureCommand – the SCM reads this value only if FailureActions specifies that a program should execute upon service failure. 
  14. DelayedAutoStart – tells the SCM to start this service after a certain delay has passed since the SCM was started. This reduces the number of services starting simultaneously during startup. 
  15. PreshutdownTimeout – This value allows services to override the default preshutdown notification timeout. After this timeout, the SCM will perform shutdown actions on the service if it has not yet responded. 
  16. ServiceSidType – represents the type of service security identifier. 
  17. RequiredPrivileges – contains the list of privileges that the service requires to function. 
  18. Security – this value contains the optional security descriptor that defines who has what access to the service object created internally by the SCM. 

Two of the above characteristics, FailureActions and FailureCommand, are of particular interest, as they offer significant potential for abuse. 

These two service characteristics are optional. The SCM registers with the system in order to receive a signal when a service process exits. When a service process terminates unexpectedly, the SCM then determines which services ran in the process and initiates the recovery steps specified by their failure-related registry values. Configurable actions for the SCM include restarting the service, launching a program, and rebooting the computer. Furthermore, a service can specify failure actions for the first, second, and subsequent times the service process fails, as well as indicate a delay period for the SCM to wait before restarting the service should it ask to be restarted. Service characteristics may be changed in the following ways: 

  1. Modifying registry values on the service. 
  2. Modifying the service through Services MMC – recovery tab, which is responsible for FailureActions and FailureCommand characteristics. 
  3. Modifying the service by using sc.exe cli. 
  4. Modifying the service programmatically by using ChangeServiceConfig2 API. 

Each modification is immediately applied unless done through the registry (which is then applied only after PC restart). 

Either way, anyone with administrator privileges can modify all service characteristics, including FailureActions and FailureCommand, and the results, as we’ll demonstrate, can be quite catastrophic.  

Demonstrating the Significance of the FailureActions and FailureCommand  Exploit

We created a POC which enumerates all services and modifies their recovery characteristics, including FailureActions and FailureCommand. In our POC we set the FailureActions to “Run a Program” and FailureCommand to a Powershell command that is responsible for : 

  1. Adding C:\temp folder to defender exclusions 
  2. Unarchiving the ARCrypt ransomware previously dropped by us to C:\temp folder 
  3. Executing ARCrypt ransomware:

Figure 1 – The same service before and after executing our POC 

 

We should note that some of the services in the service list are responsible for starting system drivers. FailureActions and FailureCommand do not apply to drivers and trying to modify their recovery parameters will results in an “Access Denied” message. 

FailureCommand can execute any executable including cmd and PowerShell commands and scripts (As shown in our POC). As a process created by services.exe, it inherits all its properties including executing new processes through the failed process permissions (for example, if the failed process was executed with a “Local Service” user, the process executed in failure would then also be executed with the same user) and under Session 0. As a result, an executed process cannot directly interact with the user’s desktop, meaning that there will not be able visible window or output for the user: 

 

 Figure 2 – Running under Session Zero 

 

Failing a service is as easy as it gets, and it can be done simply by using the “taskkill /f” command. 

FailureActions, as well as FailureCommand characteristics were added to enable system administrators and service developers to define service cleanup and restore actions or send email notifications of service failures to the relevant people. However, this capability might serve (if it isn’t already) a threat actor in different stages of the attack, such as persistency, execution, exfiltration, etc. 

In our POC we modified every service we had access to, just to increase the chance of execution of our command without failing a service in purpose, which in a real attack might take days, weeks, or even months, and could give the attacker the ability to stay undetected for a very long time: 

 

Figure 3 – The folder where our cmd command supposed to create a file, before service failure and afterC:\temp folder with the dropped ransomware 

 

The real attack flows are unlimited. The threat actor could use several specific services, each for a different purpose. For example, one service might disable Windows Defender, the other would then download the next stage, and a third would collect and exfiltrate data.

The below video demonstrates how we easily manipulated this vulnerability to execute the ARCrypt Ransomware to simulate a ransomware attack. The options however for manipulation are endless.

EDRs and Windows Defender would not allude to this vulnerability.

 

Minerva’s Anti-Ransomware Specializes in Stopping Evasive Attacks

Minerva Armor’s Ransomware Protection solution specializes in preventing evasive techniques and turning them against the attacker. There are numerous techniques implemented today by attackers, specially built by attackers to bypass detection-based security systems. Minerva prevents these attacks at the earliest stages, often without even needing to detect what they are.

 

Video demonstration of how this vulnerability can be exploited

 

Disclaimer: This post is for educational purposes only and to warn the readers of the potential risks of this vulnerability.

References: 

Windows Internals book